Re: BCP38 making it work, solving problems

[Iljitsch van Beijnum]

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.