nanog mailing list archives
Re: BCP38 making it work, solving problems
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Wed, 13 Oct 2004 12:01:03 +0200
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.
Current thread:
- Re: aggregation & table entries, (continued)
- Re: aggregation & table entries Iljitsch van Beijnum (Oct 14)
- Re: aggregation & table entries Paul Vixie (Oct 14)
- Re: aggregation & table entries Christopher L. Morrow (Oct 14)
- Re: aggregation & table entries Paul Vixie (Oct 15)
- Re: aggregation & table entries Christopher L. Morrow (Oct 15)
- Re: aggregation & table entries Paul Vixie (Oct 15)
- Re: aggregation & table entries Christopher L. Morrow (Oct 15)
- Re: BCP38 making it work, solving problems Joe Maimon (Oct 11)
- Re: BCP38 making it work, solving problems Iljitsch van Beijnum (Oct 13)
- Re: BCP38 making it work, solving problems Fred Baker (Oct 13)
- Re: BCP38 making it work, solving problems Michael . Dillon (Oct 14)
- Re: BCP38 making it work, solving problems bmanning (Oct 14)
- Re: BCP38 making it work, solving problems Iljitsch van Beijnum (Oct 14)
- Re: BCP38 making it work, solving problems Paul Vixie (Oct 13)
- Re: BCP38 making it work, solving problems Randy Bush (Oct 19)
- Re: BCP38 making it work, solving problems JP Velders (Oct 20)