- Test - lists.nanog.org

Re: Exodus Down
by Richard A. Steenbergen 27 Jun '01

27 Jun '01

On Sat, Jun 23, 2001 at 05:06:42PM -0800, Dee McKinney wrote: > > This from the SuSE Linux mail list may help :-) > > >>>>> Forwarded message from "Lewis E. Wolfgang" <wolfgang(a)nosc.mil> > > Something is definitely rotten here. > > Whois reports: > > Server Name: SLASHDOT.ORG.SUCKS.COMPARED.TO.JIMPHILLIPS.ORG The only thing rotten is the mellon inside your skull... This is someone playing around with domains in the whois database so that when you search for slashdot.org it comes up with that as well... Another example is from microsoft.com, one of the results is: MICROSOFT.COM.WHOIS.RESULTS.MAKE.A.GREAT.HUMOUR-LIST.COM The levels of stupidity generated when slashdot is up are bad enough, lets not try to set new records while it is down. -- 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)

19 22

Re: OT: new NANOG shirt?
by Bill Nickless 27 Jun '01

27 Jun '01

I wouldn't try a NANOG range day in Oakland CA, but we definitely could have done something like that in Scottsdale or Atlanta. Does anyone know where NANOG 24 will be held? Does Eric S Raymond ever go to NANOG? http://www.tuxedo.org/~esr/geeks-with-guns/ What happened to the ties on the NANOG shirts? :) At 08:43 PM 6/26/2001 +0000, scott w wrote: >The next shirt. A picture of a bunch of folks in NANOG T-shirts with guns >firing at backhoes... ;-) > >scott > >On Mon, 25 Jun 2001, Christian Nielsen wrote: > > > maybe there should be a nanog range day :) > > > > On Sun, 24 Jun 2001, Deepak Jain wrote: > > > > > Whoever stopped investing in guns? [oops, did I say that outloud?] > > > > > > Deepak === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov

8 8

Re: Global BGP - 2001-06-23 - Vendor X's statement...
by Richard A. Steenbergen 27 Jun '01

27 Jun '01

On Wed, Jun 27, 2001 at 01:38:28PM -0400, Joe Abley wrote: > > How about if there was a tool you could run against a BGP speaker > which sent a series of deliberately pathological and bogus updates, > and logged the behaviour of the box under test? > > I haven't heard anybody say that vendor X, Y or Z are refusing to > fix bugs when they are pointed out to them (quite the contrary). > The trick would seem to be to report the bugs before they are found > in the wild. > > What BGP acceptance tests do people currently run against prospective > vendors' hardware? QA Robot http://advanced.comms.agilent.com/qarobot/ -- 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)

3 2

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

27 Jun '01

On Tue, 26 June 2001, "Richard A. Steenbergen" wrote: > On 26 Jun 2001, Sean Donelan wrote: > > 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. > > But there there should be no room for debate, one side is right and the > other side is wrong. If there is really a grey area, the solution is to > fix the wording of the standards document, not to try and overlook the > problem. I'm not proposing we overlook the problem. However, software is very bad at deciding who is right and who is wrong. Other than malware, most vendor software does not deliberately send bad data. The software, or rather the programmer who wrote the software, thought the program was sending correct data. Later when humans looked at the data, humans decided the data was wrong and fixed the software. What do we do between the time the software makes an error, and time the humans can interven? Have the software, with no human oversight, nuke everything? The Blue Screen Of Death may be a very "safe" for software to do when it encounters an error. However, it is not a very good thing for system availability. I agree error handling is "hard." Aborting the entire BGP session makes the Internet more brittle than necessary. In the hours/days between the software sending the data, and the humans fixing it, the network was hurting a lot more than you would expect from a single bad route. The constant cycle of abort, reset, route flap was an amazing multiplier effect of one bad route. > I agree that in this case it is possible to have ignored the bad AS PATH > and drop the route without disturbing the session originating the bad > information. This is one specific example could probably have been handled > better with a non-fatal notification (with big red lights and buzzers). > However, it was unacceptable for that router to propagate the bad > information to others. I agree, you must have both sides (conservative send, and liberal receive). Sending bad data is not acceptable. Cisco should not send bad data. Crashing/aborting when you receive bad data isn't acceptable either. Bad data happens, Vendor X should not abort if it had other options. Sometimes there is no alternative besides aborting. However, the RFC makes aborting a requirement. There are errors BGP implementations could recover (with blinking red lights and loud buzzers). The RFC should give the option of continuing to implementations. I was following the standard isn't a good reason to crash. If following the standard causes the Internet to flap like a hummingbird for a day, we need to get the standard changed (as well as fix the existing implementations). These are not mutually exclusive goals. 1) Modify the standard so an error does not have as much impact worldwide 2) Fix the current implementations Yes, a pedestrian may have the right of way in the crosswalk. But proving your point by having the semi-truck flatten you isn't very smart.

3 2

ARIN and RIPE
by Mike Smith 27 Jun '01

27 Jun '01

All, I have a customer that would like to setup two different sites...one in the US and one in the UK. These sites will be mutually exclusive so that they won't be load balancing between the two, the custom app that they will be running on the web servers will direct UK customers to the UK and US customers to the US. However they would like the US site to be a backup site for the UK. So that if there are any problems, the UK traffic will be routed to the US via bgp. My question is this. Can a company use the same AS globally and announce the same addresses out both Europe and the US if the ASN and NetBlocks were allocated from ARIN? They want to be able to take the addresses that they are announcing in their UK location, and announce them out of the US(in case of a disaster, for example), so that their UK customers can still get to a limited version of their site. Are there any problems with using ARIN allocated IP addresses anywhere in the world? I know this works technically, I'm just curious if any of the ISPs out there are filtering to keep European traffic limited to RIPE allocated IP addresses. And are there any problems of doing the same thing in Asia? Mike Smith __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

1 0

Is this normal?
by Larry Diffey 27 Jun '01

27 Jun '01

I've only been lurking here for a couple of days and I hope this isn't an inappropriate question for this group. No flames please if I shouldn't have posted this (or for the double negative); a good stern warning will do just fine. :-) The reason that I'm addressing this group is that I'm trying to get a perspective on provider policy and how decisions are made to do such things. If it's not a conscious decision but the result of um er human error, what mechanisms are in place; or should be in place in order to correct such issues. So here it is: I'm wondering if what I'm seeing in this trace route is normal provider behavior (I haven't seen this happen before now). My provider is @home and when ever I do a trace route I get the following results: 1 211 ms 20 ms 20 ms cr1-hfc10.alsv1.occa.home.net [24.0.216.1] 2 10 ms 20 ms 40 ms r1-ge2-0.alsv1.occa.home.net [24.1.160.1] 3 180 ms 20 ms 30 ms 10.0.242.77 4 80 ms 50 ms 20 ms 10.0.242.73 5 30 ms 291 ms 20 ms c1-pos5-0.anhmca1.home.net [24.7.74.73] ... rest of results omitted for brevity. As you can see, the third and fourth hop are advertising 10's and I wouldn't think a provider would want traffic passing through a private address space. Also, this is happening just as the traffic is leaving one facility and going to another (I don't know if that means anything). If you're interested alsv is Aliso Viejo and anhmca is Anaheim (both in Orange County, CA). I could be wrong but I'm fairly certain this has just been happening for the last few weeks. Maybe I never noticed before. I'd call @home about it but I know I'd get the run around and it would take 5 hours on the phone for someone just to tell me it's none of my business. Regards, Larry Diffey P.S. NANOG Range Day should include pictures of various vendor equipment. Pick whatever is frustrating you at the moment.

5 4

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

27 Jun '01

Having tried the utility, I guess I need to put my foot in my mouth (please disregard my previous message)... I wonder how arping is able to get around the MAC broadcast filters. Very dangerous tool !! ----- 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: 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