BCP38 making it work, solving problems

Fred Baker fred at cisco.com
Tue Oct 12 05:30:34 UTC 2004


At 08:39 AM 10/12/04 +0530, Suresh Ramasubramanian wrote:
>Yes I know that multihoming customers must make sure packets going out to 
>the internet over a link match the route advertised out that link .. but 
>stupid multihoming implementations do tend to ensure that lots of people 
>will yell loudly, and yell loudly enough for several tickets to be 
>escalated well beyond tier 1 NOC support desks, for ISPs to kind of think 
>twice before they put uRPF filters in ..

You might want to take a glance at RFC 3704, which looks at a number of the 
issues that have been raised in this thread, including the routing of 
traffic to appropriate enterprise egress points.

In my heart of hearts, I would like enterprises to (as a default) match 
layer 2 and layer 3 addresses on the originating LAN, and 
quarantine-as-busted any machine that sends an address other than assigned 
on an interface. It seems that the few cases where a device legitimately 
sends multiple addresses are exception cases that can be handled 
separately. Handling it that close to the source solves the problem for 
everyone.

Practically, that is difficult. If you think getting all of the service 
providers (who wind up having to fix ddos attacks, and pay for bandwidth 
and services related to ddos attacks) to manage networks well is difficult, 
consider the prospect of getting all the edge networks to do so...

As simple solution is, as someone suggested, pose an idiot tax and bill the 
customers for doing stupid things. Egress traffic filtering in the 
enterprise is relatively simple for the average enterprise - it has at most 
a few prefixes and can write a simple ACL on its upstream router. It can 
use the ACL either to discard offending packets or to route them to the 
right egress. It is also relatively simple for the average enterprises' 
ISP: it knows what prefix(es) it agreed to accept traffic from and can 
write an ACL.

It gets a little dicier when the customer is a lower tier ISP. In that 
case, there are potentially many prefixes, and they change more frequently. 
That is the argument for something like uRPF. No, it is not a "sure fix", 
but it handles that case more readily, both in the sense of being a fast 
lookup and in the sense of maintaining the table. The problem is, of 
course, in the asymmetry of routing - it has to be used with the brain 
engaged.

 From an ISP perspective, I would think that it would be of value to offer 
*not* ingress filtering (whether by ACL or by uRPF) as a service that a 
customer pays for. Steve Bellovin wrote an April Fool's note suggesting an 
"Evil Bit" (ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt); I actually 
think that's not such a dumb idea if implemented as a "Not Evil" flag, 
using a DSCP or extending the RFC 3168 codes to include such, as Steve 
Crocker has been suggesting. Basically, a customer gets ingress filtered 
(by whatever means) and certain DSCP settings are treated as "someone not 
proven to have their act together". Should a ddos happen, such traffic is 
dumped first. But if the customer pays extra, their traffic is marked "not 
evil", protected by the above, and ingress filtering may be on or off 
according to the relevant agreement. The agreement would need to include a 
provision to the effect that once a ddos is traced in part to the customer, 
their traffic is marked as "evil" for a period of time afterwards. What the 
customer is paying for, if you will, is the ability to do their thing 
during a ddos in a remote part of the network, such as delivering a service 
to a remote peer.

Address spoofing is just one part of the ddos problem; to nail ddos, we 
also need to police a variety of application patterns. One reason I like 
the above is that it gives us a handle on what traffic might possibly be 
"not evil" - someone has done something that demonstrates that it is from a 
better managed source. 




More information about the NANOG mailing list