- Test - lists.nanog.org

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

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