North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: peering requirements (Re: DDOS anecdotes)
- From: Randy Bush
- Date: Tue Jun 26 17:47:08 2001
> there are people now reading these words who are not exactly polite
> members of internet society.
i suspect that many people would number you and me among them. but
that's why we have .procmailrc and the delete key.
> i think you're assuming a lot. it's not socially reasonable. there
> are US network owners whose peering policies are set based on fear of
> the justice department rather than on any solid economic or engineering
i suspect that some larger isps see a connection between doj actions and
economic impact. ask mci old-timers. ask bernie ebers.
> my simple-minded approach to thinking about this is about interface ingress
> filtering. an interface or subinterface or link or whatever you want to call
> it on one of your routers is ingressing one of three kinds of traffic:
> 1. from a customer (not your network)
> 2. from a peer (not your network)
> 3. from some other router you own
> if all your routers handle #1 and #2 consistently and well, then #3 doesn't
> matter. (filtering by trusted proxy.) if you limit each #1 to a specific
> set of source addresses (which limits performance but CAN be done, even on
> very slow, or very fast, and/or very dense connections), and if by peering
> agreement you limit #2 (back to filtering by trusted proxy) then you're DONE
> implementing it (randy's first point, above).
i am told that a well-known and still somewhat popular router vendor
handles source filtering on the slow path, and can't handle aggregated
is the acl for large peers 2 known and loadable into routers? i am not
comfortable with the assumption that my peer must have similar agreements
with all their peers. heck, if i did, then, aside from the business
issues (you gonna force att/cw/sprint/uu/... how to coduct their peering
policy?) how does all this bootstrap?
> making #2 transitive is the big problem. let's say that woody's got
> some really old peering agreement in place with some provider who
> doesn't mind leaving the session up but would almost certainly not be
> willing/able to set it up afresh starting today. will woody drop
> peering with that provider if they refuse to agree to limit spoofage?
> Certainly Not. probably some very large/old networks could simply drag
> their feet about agreeing to limit their spoofage, and thus
> transitively make all "upgraded" peering agreements thereby toothless.
> (would i drop peering with woody just because he refused to drop it
> with some old/large network who refused to control their spoofage
> emission? Probably Not.)
yup. that's a real problem.
so we have two problems with this
o we can't tell big peers how to conduct their business
o source filtering at high bandwidth
how do we make progress on these?
> the angry teenager with a $300 openbsd machine apparently has nothing to
> fear from us.
some of them are in jail. and there are some interesting anti-ddos
tecnology developments in the works. not to belittle the problem.