North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: BCP38 making it work, solving problems
- From: Iljitsch van Beijnum
- Date: Wed Oct 13 06:06:04 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.