June 2001 - Test - lists.nanog.org

Re: peering requirements (Re: DDOS anecdotes)
by Paul A Vixie 26 Jun '01

26 Jun '01

> maybe if we come up with a clear statement of the technical issue at hand, > those technical folk who manage to get along with their business folk can > make some forward progress. it maybe be a bit premature to throw the baby > out with the bath-water. ok, let's try it your way. anyone who wants to seriously discuss upgrading the general minimum peering agreement in use by their network so that it can include requirements about (a) not allowing spoofed source addresses to come from their network and (b) only peering, after date $TBD, with those networks who do likewise, should send me their PGP key. if i know you or if someone i know knows you, i'll add you to a private mailing list (@vix.com, not at my day job @paix.net). if you know that the right person to discuss this isn't a NANOG reader, then please forward my note internally and be prepared to (1) teach somebody pgp and (2) sign their key. (randy, i'm betting that the number of respondants will be a single digit.)

2 1

Time to revise RFC 1771
by Sean Donelan 26 Jun '01

26 Jun '01

RFC 1771's guidance on what to do with a announcement may have been filled with good intentions, however the few times it has been executed, it seems to create excessive harm to the Internet. I propose it is time to revise RFC 1771. WHEREAS, the error handling of RFC1771 is invoked where there is a dispute between two implementations of BGP. WHEREAS, these disputes may be caused by any number of reasons, including both implementations doing what they each believe are reasonable actions. WHEREAS, the resolution of these disputes may be time consuming, RESOLVED, the error handling mechanism should be revised to reject only the portion of the announcement in dispute instead of disrupting the entire BGP session. This would result in a small number of networks, most likely those who originated the disputed announcement or are closely associated with the announcer, being disrupted. But the portion of the Internet with generally accepted announcements would not be affected. This limits the colleteral damage from these disputed announcements to the small number of networks in dispute.

2 1

Re: OT: new NANOG shirt?
by George William Herbert 26 Jun '01

26 Jun '01

Someone should set up a new mailing list for the shooting run discussion. As much as I personally am interested, we're *really* off topic by now... -george william herbert gherbert(a)retro.com [PS: anyone have a Backhoe target already or do we need to get some printed?]

2 1

Re: Global BGP - 2001-06-23 - Vendor X's statement...
by Sean Donelan 26 Jun '01

26 Jun '01

On Tue, 26 June 2001, Robert E. Seastrom wrote: > > Killing 100,000 routes because you don't like one seems a bit excessive. > > Accepting a clearly defective route that may be a bellwether for a > router that has gone completely nuts seems a little bit naive and > trusting. Why do people believe it is so simple to decide what is the "bad" route? If the sender thought it was a bad route, they wouldn't have sent it in the first place. The reason they sent it was, 1) they thought it was an Ok route, 2) they didn't check it closely, 3) it changed after they checked it. You need both sides of the equation. Conservative sending: Do not send bad routes. Liberal receive: Accept the good routes, reject only the bad ones Conservative receive: If anything is wrong, reject everything (NOT THE INTERNET WAY) You seem to be saying, if you find ANY error (or even a disagreement) reject everything because you can trust nothing. This is exactly what the Internet motto cautions against. Yes, it may be a bellweather for something, but frequently the Internet has muddled along with 99.999% of things working. ISO/OSI loved to tear down sessions when it found a single bit which one side or the other thought was set wrong. The search for perfection is long, and life is short. I agree the bad route should not have been sent. However, I do not think the appropriate error action when there is a disagreement between implementations is the BGP death penalty. I believe the appropriate error handling mechanism is to accept those routes which pass your sanity check, reject those routes that do not, and ALERT the sender and operator something is wrong with some of the routes. Other implementations do not need to fix the bad route. They should not propagate the bad route. Rejecting 100,000 other good routes, which pass their sanity checks, is not a good thing.

1 0

RE: Global BGP - 2001-06-23 - Vendor X's statement...
by Richard A. Steenbergen 26 Jun '01

26 Jun '01

On Tue, Jun 26, 2001 at 11:56:21AM -0700, Sean Donelan wrote: > > On Tue, 26 June 2001, "Chance Whaley" wrote: > > How would you like Vendor X to liberally handle the situation? There is > > a point when being too liberal causes issue - like this one. The idea is > > that if the original peer followed the spec it would of been contained > > at the source and this would of never happened. Where is the line? > > Something about GIGO comes to mind. > > I would prefer implementations (not vendors) reject the one router > which they don't like, and accept the other 100,000+ routes in the > global Internet without flapping BGP sessions. > > Killing 100,000 routes because you don't like one seems a bit > excessive. There are only two situations where you will have a route that "isn't liked", 1) The sender does something wrong, 2) The receiver incorrectly handles something that is actually right. Either way, there is a fundamental flaw in someone's BGP implementation, and that needs to get resolved immediately. Flapping between the offender and its peer is probably an acceptable way to go about finding these, flapping over the entire internet because vendor C chooses to ignore the protocol spec and vendor F does not is probably not... -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: peering requirements (Re: DDOS anecdotes)
by Paul A Vixie 26 Jun '01

26 Jun '01

> But please don't forget that in this particular DDoS event > there was no IP spoofing. > > So anti-spoofing precautions, either on administrative or technical > level, would be useless in this case. > > And this case is not so untypical. that doesn't matter to me. i, and people i'm various close to, am attacked several times daily. sometimes in a hard way, sometimes in a soft way, but almost always using spoofed addresses. tracking these hop by hop using mac addresses at exchange points only works if the stream is steady. it's not. > my .002$ i was not basing my recommendation for a general peering agreement upgrade on any specific attack. it's the pattern of attacks over the last decade that's got me bugged. any angry teenager with a $300 openbsd machine can bring down any part of the internet they're angry at. with impunity.

1 0

Re: Global BGP - 2001-06-23 - Vendor X's statement...
by rs＠seastrom.com 26 Jun '01

26 Jun '01

Sean Donelan <sean(a)donelan.com> writes: > I would prefer implementations (not vendors) reject the one router which > they don't like, and accept the other 100,000+ routes in the global Internet > without flapping BGP sessions. > > Killing 100,000 routes because you don't like one seems a bit excessive. Accepting a clearly defective route that may be a bellwether for a router that has gone completely nuts seems a little bit naive and trusting. ---rob

1 0

Global BGP - 2001-06-23
by lucifer＠lightbearer.com 26 Jun '01

26 Jun '01

Out of curiosity - did anyone see a duration of significanlt instability in the global routing tables on Saturday afternoon? Without violating NDA, all I can say is that it resembled a historic event involve a bad route, Ciscos, and Bay routers (only this time, it was a bad route, Ciscos, and <X> vendor whom I cannot name but is being soundly beaten with wet noodles to resolve the issue). The bad route, and instability, were seen across all of our transit vendors (all "household" names of transit service). Anyone else see this sort of event, or further details on the cause? -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer

6 13

Re: Global BGP - 2001-06-23 - Vendor X's statement...
by rs＠seastrom.com 26 Jun '01

26 Jun '01

Sean Donelan <sean(a)donelan.com> writes: > Sigh, the motto "be liberal in what you accept and conservative in what > you send" applies to BOTH parties. Making guesses as to what is meant when one gets malformed routing updates is well beyond the scope of being "liberal in what you accept". It is only noteworthy that the bad update didn't crash the Brand "C" router because it used to be notoriously easy to kick one over by that method. > The failure of one party not to > liberally accept what is received does not excuse the sending party from > being conservative in what they send. And vice-versa. Being "conservative in what you send" refers to interpretations of the specification, backwards compatability with older specifications, requiring weird extensions to the protocol, etc. These all fall along the axis of "what might be expected in a properly functioning implementation". Output that is clearly wrong, as is the case here, is not just breaking conservatism in what one sends, it's a sign that Something is Screwed Up (tm). A convincing argument can be made for a "max-malformed-update-resets" knob such that if the peer sends bogons and gets reset more than N times in T minutes, the session is admin-downed the same way it is when it exceeds max-prefixes. Of course, if more router manufacturers were to enable clairvoyant route update divination (CRUD), Sean would get more interesting outages to write about, so at least _someone_ is ahead. :) ---Rob

1 0

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 26 Jun '01

26 Jun '01

On Mon, 25 Jun 2001 18:27:50 -0700 Ted Lemon wrote: > > I think we are in violent agreement. I don't like the > > IP->MAC->Customer mapping, it is forgeable, but it is the only one I > > know we have available. I agree with you that it is not the only > > possible mapping. If you can point me to a better existing mechanism, > > I would be greatful. > > If you are a cable modem or DSL provider, you may be able to use the > relay agent information option to get a unique ID from the cable > modem. This should uniquely identify the customer, and has the > virtue that you may have sold the customer the box, and thus may > already know its ID. Cable modem and DSL systems that support this > functionality can apparently be set up so that it's quite difficult to > spoof the modem identification. Ted; That works for the cable/dsl/wireless modem. As always, there are some unstated assumptions that come with the particular engineering sub-niche. The unstated assumption here is that the problem is not the modems, but the devices beyond the modem, the devices that the customer actually uses: PCs, routers, ip-aware toasters, web cams, etc. These are the devices that tend to cause the most problems. They have an enormous range of different manufacturers. Customers, those pesky folk, tend to add/modify/delete them constantly. Also, if the cable/dsl/wireless modem is a router, life becomes much simpler as one can just gather the necessary information via tracing. However, I am not sure requiring modems to be routers is a good thing... Let me stress in passing, it is very important that public (non-RFC 1918) IPv4 addresses not be wasted on cable/wireless/dsl modems. There is no reason for these modems to be reachable from the outside world (in an IPoE environment) and reachability is actually dangerous. If you waste public IP addresses on these devices, eventually ARIN will step on your head. > Now, in this case and also in the case of tracking the customer's MAC > address, you are still really tracking access at a customer premise > level, not at a user level, and so this couldn't be used as a reliable > way of identifying an individual user, but it *could* be used as a way > of figuring out who to contact to get more information. Exactly. It isn't an optimal solution. However, Caller-Id and username/password have the same drawbacks. In fact, I once was an expert witness on the question of whether username/password was sufficient proof beyond a reasonable doubt. regards, fletcher

2 1