June 2001 - Test - lists.nanog.org

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

27 Jun '01

This discussion has moved to NANOG ( nanog(a)merit.edu ). Please remember to trim your headers not to cross post to dhcp-server. In fact, given the quality of your comments, why don't you just respond to me privately and not waste people's time? > > 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. > > Saying something is "forgeable" is assuming that it was supposed to be > authentic in the first place. MAC addresses and IP addresses weren't > designed for that. I never said they were. However, given the design parameters, they provide useful information which should not be discarded. > > If a database was kept of client MACs, and this information was > > required before access to service was made available, you then have a > > network of known devices and have made a long step towards towards > > assigning responsibility. > > And every user would have to know the mac address of every piece of > equipment and divulge this to the ISP before they could have service? And > when they wanted to add a new computer, hook up a friend's laptop? Buy a > new NIC card? Come on. If my ISP did that to me, they'd be gone faster > than lemonaid on a hot day. Exactly. You need to supply the MAC address to bring a computer on line. Why is the more onerous that supplying a username/password? Other ISPs restrict the number of systems you can connect, the uses of those systems (no servers, etc.), block certain ports, etc. That displeases me as it reduces the value of the network and breaks end-to-end. > > > are not tied to hardware type or specific device: IP address is much more > > > useful for that, in my opinion, especially if additional information about > > > physical connections (such as port and switch numbers) is available. > > I tend to agree because: > The mac addresses of the computers in my house may change quite a bit, but > my external IP addresses will remain the same (and have to, since only > those IPs are being routed to me). Do you have any actual experience with designing or operating such a public access network? If so, please explain how to get the "port and switch number" for a user's PC on a cable network as I was unaware of this functionality. > > Please remember we are talking about large IP over Ethernet *public* > > networks (cable, Etherloop DSL, wireless) which are used by a > > completely heterogeneous population. The operator must support the > > connection of arbitrary devices. Many of the customers have very > > little knowledge of their configuration or networking. The network > > operator must support arbitrary devices and clueless customers. > > And such clueless users may have no idea what their MAC address is. They > also might have equipment that doesn't list it's MAC address readily. ...and the moon might be made of green cheese. We haven't had a problem explaining to users how to get their MAC addresses. > > 3) ARIN has sent the strong message that they expect IP over E public > > network providers to use dynamic IP allocation in order to conserve > > IPv4 addresses. > > And the intelligent public has sent an equally strong message that dynamic > IPs are not acceptible. Most people I know with DSL or similar service > make sure to use static IPs that are usable for server purposes. Wether > static or dynamic IPs are used, the same _number_ of IPs is required, we > aren't talking about dial-up here where most of the users will be offline > most of the time. I disagree with all of the above. Since it nothing more than your opinion and anecdotal evidence, mere contradiction suffices. > > accurately tracked, or that customers be accurately charged for > > their bandwidth usage. In gathering these statistics, a MAC > > I am a bit confused here. Most providers don't charge for bandwidth > usage, they charge for bandwidth availability. My ISP doesn't need to > track the traffic from my MAC address to charge me $Xx.XX for xx mbps. One needs this information in aggregate in order to model to accurately set prices. Otherwise, your company will go out of business when you charge less for the service than the service cost to provision, or you charge too much to compete with more accurate models. Say, what happened to all those DSL providers that were here just a minute ago? [ we have been in business for over seven years, and are profitable...] > > > Finally, I would not want to declare under oath that a MAC address > > > absolutely and uniquely identified a client host: it's just too easy to > > > spoof. > > Again, why even say "spoof", that makes it sound like it's _supposed_ to > be "authentic" or something. I don't thin I am "spoofing" by changing my > MAC address. It wasn't supposed to identify me, and nobody ever said it > was. In fact I have changed the MAC addresses of all of my sparcstations > (which are easily programmable in software!) to be sequential. That was pretty stupid, wasn't it? Ethernet MACs must be unique to be to work. Have you ever thought about what would happen if more than one person on the same network as you chose the same Ethernet MACs? Further, if you reprogram your MACs, and then you would not get access until you registered them. So your traffic still could be tracked. > > Total and absolute agreement. There is no question that it is easy > > for a technical sophisticated customer to spoof a MAC address. This > > fact should always be kept in mind when analysing any information. > Your forgot: > 3.) An existing MAC address that isn't currently in use is "spoofed". One > only has to watch the network for a while and get a list of MACs visible > on their net. (this is especially easy typical on cablemodem > networks). Wait until one disappears for a while (computer turned > off?). Assume that MAC address. You could even discover a pattern that a > certain MAC address is only used from X:XX to X:XX on typical days. (some > users only turn on their PCs during certain times). yawn. I didn't forget; you can't read. See the first part of my statement. Here it is again: "Total and absolute agreement. There is no question that it is easy for a technical sophisticated customer to spoof a MAC address. This fact should always be kept in mind when analysing any information." > > -- noah silva Noah, go away and don't come back until you have some real experience and something interesting to say. At least correspond with me privately. . o O (Now, where did I put that kill file?)

7 7

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

27 Jun '01

And have you ever arped for an IP not on your subnet (I am really opening myself up here if I am wrong :) ? ARP broadcasts IIRC are sent to the MAC broadcast. If your data link layer broadcast domain consists of you and a router, you will not be able to get any other MAC. You will only be able to see the MAC addresses of those in the MAC broadcast domain. ----- Original Message ----- From: "PJ" <briareos(a)otherlands.net> To: "Wojtek Zlobicki" <wojtekz(a)idirect.com> Cc: <nanog(a)merit.edu> Sent: Wednesday, June 27, 2001 5:04 AM Subject: Re: Cable Modem [really responsible engineering] > On Tue, 26 Jun 2001, 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] > > > > > > > > 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 ? > > > > > > There is a neat little utility called arping that can return the MAC address of a > specified IP. Comes in handy for bypassing MAC address filters. > > PJ > > -- > Security is mostly a superstition. It does not exist in nature. > -- Helen Keller

1 0

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

27 Jun '01

> is the acl for large peers 2 known and loadable into routers? no. not now, not ever. > i am not comfortable with the assumption that my peer must have similar > agreements with all their peers. heck, if i did, then, aside from the > business issues (you gonna force att/cw/sprint/uu/... how to coduct their > peering policy?) how does all this bootstrap? that's it. you've put your finger on the knot. > so we have two problems with this > o we can't tell big peers how to conduct their business maybe, maybe not. it depends on whether the cost of not doing it outweighs the cost of doing it. big peers are big because they run successful and for the most part profitable businesses. and sure as hell the cost of not doing this is going up quickly, while the cost of doing it is coming down slowly. (have the lines crossed yet? let's find out!) > o source filtering at high bandwidth i consider this nonsoluable. some routers can already do it, but making the ownership and deployment of such routers be the minimum price of entry into the peering game is a fatal nonstarter of an idea. and the infrastructure for expressing netblock ownership in a way that could be used to build accurate and reliable filters (assuming the routers could load such filters and act on them at wire speed) isn't there. i think this way lies madness. source filtering is an edge problem, at current technology levels. but how to ensure that other people do it at THEIR edge is a separate problem from how to do it at YOUR edge. the former is social/economic, the latter is technical.

3 2

Re: Time to revise RFC 1771
by Richard A. Steenbergen 27 Jun '01

27 Jun '01

On Tue, Jun 26, 2001 at 09:32:10PM -0700, Sean Donelan wrote: > > I would prefer we try to maintain the BGP sessions. But if you think > your peer's protocol implementation is flawed, cycling the BGP session > is unlikely to fix the software. It just makes things worse as you > announce and withdrawl sections of the route table repeatedly. Shutdown > the session (and keep it down) and wait for human intervention. Well not to play Dr. Obvious, but to quote a spec people claim to be following: If a BGP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry. So if you want to see it used, get on your vendor about it... Also, RFC1771 is pretty out of date, the "least incorrect" reference currently available is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-12.txt -- 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: RFC 1771, further thoughts
by Marshall Eubanks 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). > Hello; Can "badly formed data" be reasonably clearly defined ? What tests are there for "validly formed but errorneous data" ? There are several monitoring efforts (including the one done here) which compare sets of (m)bgp routing tables over time. It seems to me that such (m)bgp pollution should be detectable with a monitoring project. BTW, what seems to be the clearest sign here of the recent flap was the dropping of 43 Autonomous Systems by UU.net for the Sat Jun 23 16:37:41 2001 status run. This is not a good enough metric to relieably detect such problems. There do seem to be a lot of weird changes in the routing table in that dump, but a simple test for this is not apparent to me at present. Regards Marshall Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)on-the-i.com http://www.on-the-i.com >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 > Marshall Eubanks tme(a)21rst-century.com

3 2

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

27 Jun '01

On Tue, 26 June 2001, Clayton Fiske wrote: > I don't object to the discussion of changing the RFC (whether I agree > or not), and I accept that Vendor [everyone else except Cisco] having > a knob for this would have prevented some routing disruptions for some > networks. But then again, static routes would have prevented that too. > It doesn't mean they're a good idea. What I object to is that people > are using this particular case as justification for said discussion. This is the third time a BGP protocol error has lead to repeated BGP flapping across the Internet due to implementations aborting the BGP session, restarting it, and aborting it over and over. GATED, Bay Networks and now Vendor X have each had issues internetworking with Cisco. The particular cause varied, but the error handling in all the cases resulted in severe route flaps across a substantial portion of the net at the time. It wasn't Cisco's fault all the time. But what was common was implementations following RFC's 1771 guidance that the proper behaivor is to abort the BGP session. If not now, when? I would prefer we try to maintain the BGP sessions. But if you think your peer's protocol implementation is flawed, cycling the BGP session is unlikely to fix the software. It just makes things worse as you announce and withdrawl sections of the route table repeatedly. Shutdown the session (and keep it down) and wait for human intervention.

2 1

Re: RFC 1771, further thoughts
by Sean Donelan 27 Jun '01

27 Jun '01

On Tue, 26 June 2001, lucifer(a)lightbearer.com wrote: > 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. One problem which makes the current practice worse in practice is the cycling of the BGP session. Once you decide a BGP peer is "insane" why start a fresh BGP session with the same peer, only to have them send the same "bad" information again, and again, and again, and again. If folks want to isolate misbehaving peers, do an ADMIN SHUTDOWN on the session.

2 1

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

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

2 1

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

26 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 26 Jun '01

26 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