no ip forged-source-address

Mailman List Mirror (Read Only)
1

Hi,

I've been following the discussion on DDoS attacks over the last few weeks
and our network has also recently been the target of a sustained DDoS
attack. I'm not alone in believing that source address filters are the
simplest way to prevent the types of DDoS traffic that we have all been
seeing with increasing regularity. Reading the comments on this list have
lead me to believe that there is a lot of inertia involved in applying
what appears to me as very simple filters.

As with the smurf attacks a few years ago, best practice documents and
RFC's don't appear to be effective.

BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation.

I realise that configuring and
applying a source address filter is trivial, but not enough network admins
seem to be taking the time to lock this down. If the equipment had
sensible defaults (with the option to bypass them if required), then
perhaps this would be less of an issue.

Therefore, would it be a reasonable suggestion to ask router vendors to
source address filtering in as an option[1] on the interface and then move
it to being the default setting[2] after a period of time? This appeared
to have some success with reducing the number of networks that forwarded
broadcast packets (as with "no ip directed-broadcast").

So you're suggesting the router vendors provide default configurations which the ISPs will overwrite with their current configurations anyway? Which interface would you filter on? If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user.

For dialups, such filtering can and should be done, and should be automatic in the NAS boxes.

But the #1 question I have to ask you is, how are you going to have any more luck enforcing ingress filtering with what you propose, than what we have in the BCP on the subject?

If the government or other large buyers require network-wide ingress filtering in any supplier they buy from (something I suggested to the folks at eBay, Schwab, etc. in our phone calls after the attacks a few years ago), or if there were legal incentive, there might be a chance ISPs would find a financial motive to implement BCP 38. As it is, there's no incentive, so the path of least resistance is to do nothing.

2

BCP 38 is quite explicit in the need for all networks to do their part. The
document is quite effective provided there's cooperation.

Doesn't seem to be working.

Which interface would you filter on?

Customer ingress ports on the ISP side, which I suspect are the majority
of ports in ISP networks. Hopefully engineers on the backbone will be
clueful enough to turn it off.

If we're talking about a router at the customer premesis, the filters
should be on the link to the ISP (the customer may well have more
subnets internally). At the ISP end, doing the filtering you suggest
would not work, since it'd permit only the IP addresses of the link
between the customer and user.

The routing table of the router should be used to build up a list of
prefixes that you should see through the interface. In this way, you
could apply it to BGP customers too without having to create filters by
hand.

Regards,

Rich

3

"daniel" == Daniel Senie <dts@senie.com> writes:

If the government or other large buyers require network-wide
ingress filtering in any supplier they buy from (something I
suggested to the folks at eBay, Schwab, etc. in our phone
calls after the attacks a few years ago), or if there were
legal incentive, there might be a chance ISPs would find a
financial motive to implement BCP 38. As it is, there's no
incentive, so the path of least resistance is to do nothing.

I find it interesting that you suggest that the legal incentive should
be toward having the ISPs come up with a magic solution and not toward
having the customers do egress filtering at the edge(s) of their
network and actually perform something resembling security on the
hosts on their networks.

After all, it is not usually a security failing of the ISP that causes
a DoS or DDoS attack, but utter incompetence or neglect by someone at
the edge of the network. The problem is that it's those same people
who have the money needed to keep the ISPs in business. Unless
all ISPs decided to hold the customers responsible, they'd just move
to another ISP.

I'm not saying I don't think ISPs should filter where feasible, I'm
just saying that if we're going to hold someone responsible, it should
be the people who are responsible, not the people who are convenient.

but my opinions are probably worthless,
Michael

4

To reiterate the comment I made during the session yesterday, the places
where strict rpf will be most effective are at the very edge interfaces
without explicit management (SOHO). This also tends to be the place
where there is insufficient clue to turn it on. One hopes that in the
nanog community there is sufficient clue to recognize the case where
having it on will create a problem and turn it off.

This has been a case where money has been talking, and those with enough
clue to comment on it are saying they don't want it, while those that
really need it are not asking. If the community believes this technique
is the best tool for regaining visibility into where attacks are coming
from, there are two explicit steps to making it happen. First, demand
that all vendors make it the default. Second, be willing to turn it off
rather than simply complain that it doesn't work in the ISP network.

Tony

5

This is also an area where NAT boxes are prevalent. One would HOPE the NAT boxes would take care of rejecting bogus source addresses sinec they do have to do translation on whatever comes in. So encouraging NAT boxes in the SOHO world is perhaps not so bad...

For the SOHO cases without NAT boxes, cable, dsl and dialup from a single computer, it would make a great deal of sense for the ISP to take care of this issue (in the cable head-end router, DSLAM, or NAS).

6

"daniel" == Daniel Senie <dts@senie.com> writes:

If the government or other large buyers require network-wide
ingress filtering in any supplier they buy from (something I
suggested to the folks at eBay, Schwab, etc. in our phone
calls after the attacks a few years ago), or if there were
legal incentive, there might be a chance ISPs would find a
financial motive to implement BCP 38. As it is, there's no
incentive, so the path of least resistance is to do nothing.

I find it interesting that you suggest that the legal incentive should
be toward having the ISPs come up with a magic solution and not toward
having the customers do egress filtering at the edge(s) of their
network and actually perform something resembling security on the
hosts on their networks.

What I suggested was a financial OR legal incentive.

After all, it is not usually a security failing of the ISP that causes
a DoS or DDoS attack, but utter incompetence or neglect by someone at
the edge of the network.

That's a question of perspective. Arguably both the ISP and the end user are responsible. The ISP is often in the role of managing the CPE router, and thereby has control over the router where ingress/egress filtering is most easily implemented with simple access control lists.

  The problem is that it's those same people
who have the money needed to keep the ISPs in business. Unless
all ISPs decided to hold the customers responsible, they'd just move
to another ISP.

Or unless customers refuse to buy from anyone who doesn't do ingress filtering, resulting in a financial incentive for the ISP.

I'm not saying I don't think ISPs should filter where feasible, I'm
just saying that if we're going to hold someone responsible, it should
be the people who are responsible, not the people who are convenient.

I find it interesting that some ISPs have no trouble taking care of ingress filtering, while others bellyache about how hard and expensive it is. Another nanog participant commented ATT implemented this starting in 1995. A UUNet person was the most vocal opponent to the draft that became RFC 2267 (over concern that the Cisco 7000's in use then would not handle the load). Six years later, ATT's network seems to do OK. Did UUNet ever do anything about it? Buy gear sized properly to do it? UUNet gives away 2610's with leased lines. Do they come pre-configured to do ingress filtering even?

The question for the ISP is how it will defend itself when summoned to court. The ISP had the tools to ensure spoof attacks could not come from its network, yet chose not to. The customer likely would also face the negligence charge. The plaintiff would be the customer of another ISP whose business was severely injured. The question is whether you want to, in court, tell the judge "my customer was an idiot. Blame them, it's not my fault." You might even get away with it, but I suspect you would lose your customer base pretty quickly thereafter.

The S in ISP stands for SERVICE. You're providing a service to your customers. Helping those customers stay out of trouble, whether it's by selling them a firewall service, or managing their CPE router, or just providing ingress filtering, is part of what service is about.

I'm not surprised that major backbone providers still complain about ingress filtering. I am a bit surprised no lawsuits have get cited BCP 38.

7

I was trying to keep my mouth shut... but alas that was too tough ;(

First, the ip addresses used in the attack are completely disconnected
from the problem of the attack. If you get attacked, its really not
relevant what ips are used, spoofed or not someone needs to stop it for
you. The real problem that needs to be addressed is 'how to make the
attacks stop' in the first place.

Anyway, on to the comments :slight_smile:

> "daniel" == Daniel Senie <dts@senie.com> writes:
>
>> If the government or other large buyers require network-wide
>> ingress filtering in any supplier they buy from (something I
>> suggested to the folks at eBay, Schwab, etc. in our phone
>> calls after the attacks a few years ago), or if there were
>> legal incentive, there might be a chance ISPs would find a
>> financial motive to implement BCP 38. As it is, there's no
>> incentive, so the path of least resistance is to do nothing.
>
>I find it interesting that you suggest that the legal incentive should
>be toward having the ISPs come up with a magic solution and not toward
>having the customers do egress filtering at the edge(s) of their
>network and actually perform something resembling security on the
>hosts on their networks.

What I suggested was a financial OR legal incentive.

>After all, it is not usually a security failing of the ISP that causes
>a DoS or DDoS attack, but utter incompetence or neglect by someone at
>the edge of the network.

That's a question of perspective. Arguably both the ISP and the end user
are responsible. The ISP is often in the role of managing the CPE router,
and thereby has control over the router where ingress/egress filtering is
most easily implemented with simple access control lists.

Wow, this is an overreaching assumption you are making. There are quite a
few ISP's that manage a small minority of their customers. I'd think that
number at UUNET, for example, manages less than 1% of its customer CPE.
Sprint is apparently managing a bit more, given that almost all sprintlink
customers I talked to have managed cpe... ATT I don't know about for
this argument. The point here is that assuming that "all isps manage their
customer's cpe" isn't safe.

>I'm not saying I don't think ISPs should filter where feasible, I'm
>just saying that if we're going to hold someone responsible, it should
>be the people who are responsible, not the people who are convenient.

I find it interesting that some ISPs have no trouble taking care of ingress
filtering, while others bellyache about how hard and expensive it is.
Another nanog participant commented ATT implemented this starting in 1995.
A UUNet person was the most vocal opponent to the draft that became RFC
2267 (over concern that the Cisco 7000's in use then would not handle the
load). Six years later, ATT's network seems to do OK. Did UUNet ever do
anything about it? Buy gear sized properly to do it? UUNet gives away
2610's with leased lines. Do they come pre-configured to do ingress
filtering even?

Yes, this has been part of the standard customer router config for
sometime now... Technically its 'egress' not 'ingress' filters, but the
same effect is in place.

The question for the ISP is how it will defend itself when summoned to
court. The ISP had the tools to ensure spoof attacks could not come from
its network, yet chose not to. The customer likely would also face the

This is entirely NOT the case. The 'tools' being 'urpf' works in limited
cases, there are some spectacular failures though. Access-lists on INGRESS
at the ISP, except in small ISP examples are a massive scale problem.. not
to mention the functionality issues :slight_smile:

8

If anyone has contact information for someone with the security dept. of the
Army Corps of Engineers network, could they please contact me offlist? I
have tried to contact the webmster from the contact list on
http://www.usace.army.mil but all I get is someone's voicemail. The other
number listed is disconnected.

Randy