|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: BCP38 making it work, solving problems
On 12-okt-04, at 7:30, Fred Baker wrote: 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.So what is our collective position on ISPs filtering their peers? Both the position that this should be done as there are too many clueless peers and the position that it shouldn't as it breaks too much legitimate stuff (especially possible future stuff such as the multiaddress multihoming for IPv6) are reasonable. We need to agree on one or the other, though: half the net doing one and the other half doing the other won't make anyone happy. 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.I would much rather see a solution where ISPs rate limit their customers except for flows for which the customer can present a token that shows the recipient actually wants to receive the traffic, or the recipient gets to send a message to shut up the flow. This should solve the (D)DoS thing very nicely, although it does require both ends to cooperate and it requires customer facing stuff to look fairly deep into packets. 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.Trusting the source when it says that its packets aren't evil might be sub-optimal. Evaluation of evilness is best left up to the receiver.
|