Re: peering requirements (Re: DDOS anecdotes)
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 something.)
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
participants (2)
-
Paul A Vixie
-
Randy Bush