- NANOG - lists.nanog.org

RFC 1771, further thoughts
by lucifer＠lightbearer.com 27 Jun '01

27 Jun '01

In an attempt to return to an argument, rather than simple contradiction (ok, ok, it's far more polite and reasonable so far than that would imply, but I couldn't miss the cheap shot; apologies hereby tendered), perhaps we should consider *what* the RFC should say, if it should be changed? Going to the WG with a proposal in hand and a rationale to support it would seem to be the best path. So, a summary of my view on it at the moment: Assumption #1) Resetting a BGP session is 'costly'. Both in terms of the time it takes, the stability it removes, and the fact that it flaps all of your *outgoing* announcements as well as incoming ones. Assumption #2) A router that sends a malformed route is clearly doing something which it Should Not Be Doing (tm) (ok, this might be axiomatic, but should still be laid out) Assumption #3) The current practice has been shown to demonstrably increase the brittleness of the Internet, by causing severe flapping when someone only partially follows the RFC (in particular, propagating bad route data, whether or not the origional source session is reset). Assumption #4) Routing errors which are bad data, but *not* malformed routes, will not generally be caught by normal means in normal operation, until a case of human intervention to cross-check the data. Assumption #5) Any router which breaks so badly as to start spewing large amounts of validly formed but errorneous data, and is *also* spewing badly formed data, will spew noticeable amounts of said badly formed data. (This one is key, and is only a conjecture; field evidence would be of great use in validating it). Conclusion: changing the RFC from saying you MUST do a NOTIFY and ditch the session could be adjusted to stating that you MUST handle the error in one of two ways: do a NOTIFY and ditch the session (traditional), or send an ALERT and discard the badly formed route. Additionally, this alternative handling MUST NOT be enabled by default, and SHOULD have a threshhold parameter at which the session will undergo a NOTIFY/reset, under the assumption that the host sending an appreciable amount of badly formed routes is, in fact, in danger of sending correctly formed but erroneous data as well. Suitable threshold values are left as an excercise to local admins and BCP documents; I would think this could be negotiated as a capability extension to BGP4, with the fallback, of course, being to follow the traditional RFC practice. Thoughts? -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer

1 0

Re: Time to revise RFC 1771
by Sean Donelan 27 Jun '01

27 Jun '01

On Tue, 26 June 2001, Clayton Fiske wrote: > Plus, a CRC error can occur between two valid, compliant, bug-free > implementations. A bad route, by definition, can't. We're not talking > about external faults here, but broken implementations. When one side > of a protocol session simply breaks the rules, I don't think it's > reasonable to say that the other side needs to be "fixed" to accept > that breakage. Fix the broken side. Uhm, lets see what you think of this press announcement. "Pardon us, we must shutdown the Internet will we decide whose software needs to be fixed. Don't worry, as soon as it is fixed, the Internet will be rebooted." Yep, somebody's implementation was broken. One part of the response is to fix their implementation. While we waiting to get the fix, the rest of the Internet should not have been flapping.

1 0

Re: Cable Modem [really responsible engineering]
by Wojtek Zlobicki 27 Jun '01

27 Jun '01

----- Original Message ----- From: "Daniel Senie" <dts(a)senie.com> To: "Wojtek Zlobicki" <wojtekz(a)idirect.com> Sent: Tuesday, June 26, 2001 9:51 PM Subject: Re: Cable Modem [really responsible engineering] > At 09:43 PM 6/26/01, Wojtek Zlobicki wrote: > > > >----- Original Message ----- > >From: "Chris Adams" <cmadams(a)hiwaay.net> > >To: <nanog(a)merit.edu> > >Sent: Tuesday, June 26, 2001 9:20 PM > >Subject: Re: Cable Modem [really responsible engineering] > > > > > > > > > > Once upon a time, Miquel van Smoorenburg <miquels(a)cistron-office.nl> said: > > > > When the BRAS requests config info when the circuit goes up (using > > > > radius) or when it acts as a DHCP relay, it includes the VPI/VCI > > > > of the ATM channel in the request. That means that you can assign > > > > IP addresses based on the physical connection rather than the MAC > > > > address, and this is what we do [well, will do soon anyway ;)] > > > > > > Okay, but how do you keep the end user from putting a different IP in > > > their computer? We use PPPoA for our "residential" DSL, but someone > > > that works here lives outside our service area (small local telcos are > > > all over this area), and just got DSL from his local telco/ISP, which > > > uses 1483 bridging. He has multiple computers, so he just picked > > > another address, pinged it to see it wasn't in use at the moment, used > > > it, and it worked just fine. > > > >Access lists are one way to go :) You dont get out unless we say so :) > > > > > > > > Also, how do you prevent the user from trying to forge someone else's > > > IP address or even MAC address in outgoing packets? Without protecting > > > against forged packets, I don't see how to provide accountability when > > > someone attacks. > > > >How would anyone find out anothers MAC. As long as you seperate each > >customer into their own bridge group, there is no way for them to find > >anothers MAC. As for forging IP's not much you can do about that. MAC > >address access list.. do they exists ? > > Broadcast packets... DHCP DISCOVERs if nothing else. > > tcpdump -i eth0 > > on a Linux box attached to my cable modem finds all kinds of broadcast > packets from neighbors' computers (mostly Windows-related packets) as well > as ARP requests. It's possible this is just a poorly configured system, but > I'm not sure how bridge groups are going to isolate you from one another > AND block broadcasts, and still allow users to play interactive games > against one another (i.e. you still have to let them send packets around > the neighborhood). There is not much you can do about broadcast packets. This is not a grave security risk as most of this traffic is benine. It is unicast traffic that I would not want you to see (can you see any of that?). With carefull subnetting, you could prevent these from being seen. Is it plausible (I don't know the cable modem hardware well enough to comment here) to assign IP/32 to virtual interfaces ? Since a subnet in this case is only ony IP, there is no broadcast. How could one filter out MAC layer or IP layer broadcasts ? BTW , if you really want to kill a few weeks of your time, get a copy of TCPTRACE and XLOT. TCPTRACE allows you to take a tcpdump dump file (tcpdump -w dump_file_name ) and plot it. You can track RTT, windows size, throughput. XPLOT is used to display the plots created by TCPTRACE. > > > > > > > > DHCP or RADIUS (how did I know you used RADIUS :-) ) is fine for > > > assigning things, but how do you _enforce_ those assignments? I know > > > how with PPPoA, but not with a bridged network (the same thing applies > > > with cable modems). > > > > > > -- > > > Chris Adams <cmadams(a)hiwaay.net> > > > Systems and Network Administrator - HiWAAY Internet Services > > > I don't speak for anybody but myself - that's enough trouble. > > ----------------------------------------------------------------- > Daniel Senie dts(a)senie.com > Amaranth Networks Inc. http://www.amaranth.com

1 0

SBC forcing new contract on ISPs
by Christopher A. Woodfield 26 Jun '01

26 Jun '01

http://sanfrancisco.bcentral.com/sanfrancisco/stories/2001/06/18/story3.html If I'm reading this correctly, SBC is forcing ISPs that resell SBC's DSL access to go with PPPoE over ATM, thus potentially forcing businesses to buy DSL net access from SBC directly. Am I way off base? Anyone know more about this situation who can comment? -C --------------------------- Christopher A. Woodfield rekoil(a)semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B

8 14

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

2 1

Re: Cable Modem [really more about PPPoE]
by Fletcher E Kittredge 26 Jun '01

26 Jun '01

On Mon, 25 Jun 2001 11:16:29 -0500 Chris Parker wrote: > PPPoE. Auth via radius. Same management infrastructure as used for > dialup ( in terms of radius accounting from PPPoE aggregation boxes ). 1) Auth via radius is not an advantage for the customer; only for the engineer whom has a legacy radius infrastructure to support. A key engineering skill is to be able to evolve such infrastructures economically and reliably to more modern infrastructures. Therefore, this is not much of an advantage as you should know how to replace it :) 2) To balance this one special case advantage, radius auth has a number of flaws: i) it is an older protocol designed for a different model of networking and thus is missing many features of DHCP. In particular, clean mechanisms for setting an arbitrary number of client configuration values. ii) public networks, it uses username/password authentication. This is a flawed mechanism for auth. It is insecure[1] and generates a fair amount of support traffic. > You have start/stop logs with timestamps. You know who had what IP and > when. 3) Inflicting a connection oriented access model on customers is unfair; the network should be always on. Only the legacy design of the PSTN requires a connection oriented model. Therefore, start/stop displease me. 4) DHCP also logs leases which tell you who had what IP and when. > Also, most PPPoE aggregation boxes record the client MAC address in > the 'Calling-Station-Id' radius field, so that solves your MAC problem > as well. 5) That is a good, but I don't like the cost. I already have a working model. > > Before anyone bemoans the dearth of PPPoE clients, check again. Nearly > every major consumer OS ( Windows,MacOS,Linux,*bsd ) has PPPoE support. > Or failing that, you can pick up a nice little netgear or linksys > pppoe router that does nat for ~$75. 6) I don't care about the dearth of PPPoE clients, if it exists, it will resolve itself. I do care about their bugginess, as this will be with us always. All code is buggy. Avoid adding more code (complexity) unless truely necessary. 7) NAT breaks end-to-end. NAT is evil. NAT is a sign of weakness. NAT only exists because we have failed in providing a secure network with virtually infinite addresses. NAT is a sign of shame for every self-respecting Internet Engineer. Remember what Cato said: "NAT must be destroyed". If I only knew how... a plan, I need a plan... regards, fletcher

9 22

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

26 Jun '01

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

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: > Pointless and irrelevant. Do you follow the accepted standard or not - > that is what it comes down to. Bugs are bugs and everyone has them, big > deal. However, there is a general consensus about how things are > supposed to work - interoperability is somewhat difficult in this day > and age without it. So which is it? Follow the standards - be they RFC, > STD, draft, de facto, or de jure - or roll your own and pray? > > No one has stated that closing the session is bad thing, and the general > feeling is that its a good thing. So what is it that you want? It is a bad thing, and something most other protocols do NOT do. A bad TELNET escape sequence is an error, it doesn't shutdown the TELNET session. A bad MIME encoding is an error, it doesn't shutdown a SMTP session. A bad route is an error, it SHOULD NOT shutdown a BGP session. Cisco should fix their implementation AND the RFC should be revised not to require tearing down the BGP session because of one bad route.

2 1

Re: Time to revise RFC 1771
by Dave Israel 26 Jun '01

26 Jun '01

On 6/26/2001 at 13:47:37 -0700, Clayton Fiske said: > On Tue, Jun 26, 2001 at 04:27:49PM -0400, Dave Israel wrote: > > > > This ignores three basic facts: > > > > 1) Networks tend to be homogenous in platform. > > 2) Platforms tend to accept their own implementation quirks > > 3) Networks peer at borders > > > > Therefore, under the "drop the session rule," my bad announcement > > gets to all my borders fine, and all my external peers who are not > > running forgiving/compatable implementations drop their connections > > to me and all my traffic to/from them hits the floor. > > In this case, vendor C's implementation was neither forgiving nor > compatible. It still dropped the peer(s) in question. It just had > the much more harmful quirk that it forwarded the bad route on to > its peers before doing so. In this case, a homogenous network would > not only lose its border sessions, it would lose all internal ones > through which the route was advertised. I'm certainly not defending (or attacking) either vendor's implementation; in the current environment, I believe following the RFC is the correct course. I was more concerned with future implementations of BGP, and how (I feel) they should handle problems like this, since, as we add more and more features to BGP, how we handle what appears to be a bad route (or a bad NLRI) is going to become more important. > > One CRC error does not make PPP drop. Why make one route cause > > a catastrophic loss of connectivity? Report the bad route, > > drop it, and move on; let layer 8 resolve it. > > Because, arguably, we don't know that it's just one route. We just > know that one route set off the alarm. Do you feel safe assuming that > whatever bug caused one corrupted route left all the other routes > alone? No, but I feel secure that, if it corrupted a large enough number of routes, the effect will not be worse than dropping the session. Somebody mentioned what happens if there are 100,000 bad routes and 1 good one. You keep the good one and drop the 100,000 bad ones. Dropping routes is even easier than using them. Besides, which tends to be harder on a router: dropping bad routes, or tearing down and restarting a TCP session? > Plus, a CRC error can occur between two valid, compliant, bug-free > implementations. A bad route, by definition, can't. We're not talking > about external faults here, but broken implementations. When one side > of a protocol session simply breaks the rules, I don't think it's > reasonable to say that the other side needs to be "fixed" to accept > that breakage. Fix the broken side. A "bad route" can happen whenever one implementation differs from another. Both can be valid according to some definition of the standard. Determining who is wrong, and fixing it, takes time. If you're dropping a few of my routes during that time, that's unavoidable. If every customer of mine cannot reach every customer of yours while we fight over whose implementation is wrong and who needs to change what, then who wins? And how is this fight more legitimate than the one you have with your telco provider over how they built your circuit and where your errors are coming from? > The reason this has got everyone's attention is because of the unique > way in which the breakage occurred. If all implementations were changed > to drop the single bad route and keep the sessions intact, the damage > would not have been what it was. If all implementations followed the > current specs and dropped the session with the router which first > originated the bad route, the damage would not have been what it was. > To say that one way causes massive damage and the other doesn't is > inaccurate. The damage was caused by the implementation in question > doing something resembling one but with harmful behavior thrown in. I think the issue has gone beyond what happened, and into what will happen. It's a simple design philosophy question: Do you build protocols that are robust and resilient under stress, or do you build protocols that refuse to interoperate until everything completely agrees? Ideally, I can see the beauty of the second, but realistically, I think you need to be permissive. -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

1 0

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

26 Jun '01

On Tue, 26 June 2001, "Richard A. Steenbergen" wrote: > > 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... Flapping 100,000 routes because one route has some bits set in a way one implementation (not vendor) thinks is Ok, and another implementation (not vendor) things is wrong, isn't the best solution. It should flap that one route, not the other 100,000 routes. Even if that one route is never propagate beyond that point, the flapping of the 100,000 routes will be. The RFC 1771 solution requires the flapping of *ALL* routes, not just the bad ones. There will always be cases where Vender A thinks they are correct and Vendor B thinks they are correct, and they differ. And you are correct, either the sender has done something wrong or the receiver has done something wrong, hence the Internet motto. The sender should conservatively send only "good" data. The receiver should liberally accept what it can, and only reject "bad" data. I don't think the receiver should be changed to understand the bad data, just not to reject "good" data. Under RFC 1771, the receiver is rejecting both "good" and "bad" data. It should be revised so when there are both "bad" routes and "good" routes, the receiver should accept the "good" routes and only reject the "bad" routes. If a TELNET implementation doesn't understand an escape code, it shouldn't terminate the entire TELNET session. There is a flaw in both the sender's implementation and RFC 1771's method of handling errors.

3 2