Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: peering requirements (Re: DDOS anecdotes)

  • From: Paul A Vixie
  • Date: Tue Jun 26 16:55:03 2001

> odd that your response to a request for a technical problem statement is a
> request to form a private clique and a pre-made value judgement on the
> meaning that nobody excspt clique groupies will want to join.  imiho, very
> few social problems have technical solutions, and vice versa.

i've had some dealings with various readers of the nanog mailing list which
have taught me quite a bit about the quality of lurker we get here (and for
that matter the quality of active participant).  don't blame me for throwing
a party but also checking credentials at the door.  there are people now
reading these words who are not exactly polite members of internet society.

> do i correctly glean that you are want peering agreements to require that
> peers not allow packets with spoofed source addresses?  this would not seem
> too socially unreasonable as long as we know that it is not technically
> unreasonable.

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.  expecting
these people to refuse to peer with anyone for reasons similar to "you're not
technically capable of operating a network that doesn't emit spoofage" is
actually the crux of this whole matter, and is my real interest in holding
discussions about it.

> to test the latter, could we please enumerate
>   o the technical means for a peer to achieve this, e.g. i suspect that
>     2827 is one piece
>   o how thoroughly we think they could achieve this
>   o how we can test that it has been achieved

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).

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.)

the angry teenager with a $300 openbsd machine apparently has nothing to
fear from us.  but let's discuss it.  privately, where the various angry
and bored twentysomethings with $3000 openbsd machines don't get to listen.
(though if i can get a signed pgp key from some of them, that could be worth

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.