- Test - lists.nanog.org

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

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

26 Jun '01

On Tue, 26 June 2001, "Chance Whaley" wrote: > Vendor X released a limited statement to their customers describing the > issue - and their view on it. The large incumbent vendor that we all > know and love has confirmed the issue, and released a "patch" to some of > their customers. Vendor X also went on to state that at no time did > their boxes crash, mis-forward, reset, or have any issue resulting from > the events of the past weekend. Sigh, the motto "be liberal in what you accept and conservative in what you send" applies to BOTH parties. 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. Just because one vendor has issued a patch does not excuse the other vendor.

3 2

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:01:58AM -0700, Sean Donelan wrote: > > On Tue, 26 June 2001, "Chance Whaley" wrote: > > Vendor X released a limited statement to their customers describing the > > issue - and their view on it. The large incumbent vendor that we all > > know and love has confirmed the issue, and released a "patch" to some of > > their customers. Vendor X also went on to state that at no time did > > their boxes crash, mis-forward, reset, or have any issue resulting from > > the events of the past weekend. > > Sigh, the motto "be liberal in what you accept and conservative in what > you send" applies to BOTH parties. 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. > > Just because one vendor has issued a patch does not excuse the other > vendor. But in situations where there cannot be a mismatch between two parties' definition of "liberal", that is why we have standards. I'd say it is entirely the fault of the vendor who was TOO liberal in what they accepted, because they continued to propogate the bad information over the entire internet instead of stopping it where it began as the protocol intended. -- 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 Vixie 26 Jun '01

26 Jun '01

Following up on my own post: vixie(a)mfnx.net (Paul Vixie) writes: > Recommendation: upgrade your peering requirements to include language like: > ... Several folks here talked about technical implementation aspects (RPF, etc) and a few told me privately that peering was a sales/marketing activity at this stage of the game. This either means that upgrading the general level of peering agreement is not possible, or that the people I should be discussing it with don't read NANOG. This echos what I learnt at Stephen's BOF in Phoenix.

3 2