BCP38 making it work, solving problems
Iljitsch van Beijnum
iljitsch at muada.com
Wed Oct 13 10:01:03 UTC 2004
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
> 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.
More information about the NANOG