peering requirements (Re: DDOS anecdotes)

Tue Jun 26 21:41:53 UTC 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
> basis.

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
high loads.

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.

randy