robt at cymru.com
Thu Mar 2 02:09:55 UTC 2006
] BCP38bis... ??? have your upstream (bills bait&sushi)
] rate limit toward you?
Where do they enact that rate limit? At the router on which my
link terminates? At their peering points? In their core? In
other words, we're just pushing the point of pain around the
network. I have 1Gbps to them, they have a 10Gbps backbone,
and they have 622Mbps or 1Gbps peering. It's a matter of
finding the point of constriction, and hammering it.
One of the victims of the recent amplification attacks survived
with great aplomb. The miscreants then went after the upstream
routers. At no point was the bandwidth or any arbitrary limit
exceeded, but the routers failed just the same. Do we enact
similar limits on traffic to (and from) the routers? All
Based on the sordid history of DDoS, we'd need rate limits on
ICMP, UDP 53, TCP SYNs, etc.
It's pretty hard to manage a per-customer rate limit on 2000
routers (guess who that is!). :) It's a problem of scalability
Again if there is an easily deployed and managed approach to
rate limits, I know lots of folks to whom I'd refer that guide.
I'll sign up for service from Bill's bait&sushi any day. :) I
think John Kristoff has done some work in this area, so it may
be worth a ping on him.
I think we're stuck with managing each threat as it arises. We
definitely need ubiquitous adoption of BCP38, though I'm not
certain how to achieve that. Lots of folks have tried, with
seemingly limited success. Barry's work with uRPF might be a
good place to start (again). There are some real successes with
uRPF, despite some of the animus those letters generate. :)
We may be straying from the list charter a bit here, but I think
it's all related.
ASSERT(coffee != empty);
More information about the dns-operations