June 2001 - Test - lists.nanog.org

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

26 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

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

26 Jun '01

On Tue, 26 June 2001, Andrew Partan wrote: > On Tue, Jun 26, 2001 at 11:48:29AM -0700, Sean Donelan wrote: > > 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. > > The big problem here is that it may be impossible to tell that just > this bit of <goo> is bad and that everything received after that > is fine. I'm willing to accept there are cases you can not recover, and the only acceptable alternative is to reboot (gee, Microsoft thinks that is the solution to everything). My objection is RFC 1771 does not give implementations the ability to continue when they can. Aborting the BGP session should be an option, and extreme option, but not the ONLY option. So should throwing away the bad data, alerting, and continuing with good data.

1 0

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

26 Jun '01

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. 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. -Dave On 6/26/2001 at 13:08:46 -0700, Clayton Fiske said: > The basic issue is one of scale vs integrity. However, I think this > particular case is one in which the RFC-dictated behavior is the > correct choice. The problem is that one [set of] router[s] did not > follow such behavior and thus escalated the scale of the problem > significantly. > > Given that the malformed route in question was most likely originated > from a single router, the only damage that should have been done was > a loss of routability for networks behind that one router. While of > course that could be arguably a significant number of networks, I > think it's a safe assumption that X losing its peers is pretty much > always a smaller impact than all of X's peers losing -their- peers. > If network XYZ's routers have N peers each, the RFC-dictated > behavior gives us N peering sessions lost (assuming the offending > route was advertised to all peers), instead of N^2 (or greater) > sessions as was the case. > > I think the logic of dropping the session is sound. If a router > originates one malformed route, who's to say the rest of its routes > are correct? Perhaps other routes are corrupted, but not in ways > detectable by the router's sanity checks. Since the offending route > is indeed malformed, it's not unreasonable to stop trusting the > router from which it originated. Since it's likely[1] only a single > router is originating the route, dropping sessions to that one > router controls the blast radius[2]. > > This is not to say that the issue of scale is unimportant. It most > certainly is. However, again, if the first router(s) to receive > the route had behaved properly, the scale of the problem would > have been small. The only place you'd see a flap of 100,000 > routes is if the offending router was your upstream's. Everyone > else would only see (at most) a flap of the routes originated by > and/or behind that router (in BGP topology terms). > > Perhaps a knob to control the behavior would be an acceptable > compromise for some. I think it's a bad idea for two reasons. > First, it allows bugs such as this to go unfixed, because when > it happens people just adjust the knob to keep their BGP sessions > stable. Second, it circumvents the integrity control. If a router > has many corrupted routes, but only a few trigger the sanity > checks for malformation, the session stays alive and the remaining > corrupted routes are then propagated network-wide. While this may > seem like a paranoid philosophy, a little paranoia can be good > when considering the integrity of the larger whole. > > -c > > [1] = Yes, "likely" is a relative term. I know there are plenty of > cases where the same route is originated by multiple routers, > however the odds of more than one of them corrupting a route > at the same time are probably slim compared to the odds of > a single one doing so. > > [2] = In this specific case, as I understand it, the direct peers did > in fact drop the offending BGP session, however they propagated > the offending announcement to their peers before doing so. In > this case, of course, the blast radius is not controlled. > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

2 1