- NANOG - lists.nanog.org

The %^&# did it!
by John Fraizer 16 May '00

16 May '00

http://www.wired.com/news/politics/0,1283,36339,00.html Time for a change in Washington. Register to throw them out...er...vote. --- John Fraizer EnterZone, Inc

4 3

Re: Private ASN suppression
by Danny McPherson 16 May '00

16 May '00

In short, see RFC 2270. Some of the primary differences are that several of the BGP attributes are preserved with confederations, versus that autonomous "look and feel" provided by dedicated ASs, not to mention that any such model would assume that the providers employ confederations as well. Also, managing it would be a nightmare. More importantly though, is that if providers allow customers to maintain sub-ASs of a confederation they're placing a considerable amount of trust in the capabilites of those customers, and errors on the customers part could impact much more than just the customers part. -danny > I'm trying to understand the problem being solved by the Cisco > private AS removal feature. In particular, what advantages does it > offer over confederations, which would seem to do the same thing when > externally advertising customer routes? Is there a performance > benefit? > > RFC1998-style multihoming with a private AS is a possible > application, I suppose, for any routes that are NOT marked with > NO-EXPORT. >

2 1

co-location/machine room facilities in germany
by Jim Mercer 16 May '00

16 May '00

can anyone recommend a goo co-location or machine room facility in germany? i need to set up 2-3 racks. - need ability to patch into one or more first tier providers - AC power with battery/deisel backup - 7x24 access - local person to do intermittent reboots preferred location is frankfurt, other cities would be considered. -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

1 0

Re: New Internet-draft on DDOS defense...
by Vipul Shah 16 May '00

16 May '00

>>> <mixter(a)newyorkoffice.com> 05/13/00 07:19PM >>> Hi, I'm sorry it took me so long to reply. I couldn't find the particular message, and there seemed to be a couple of new ones, so I'm posting my reply here... It is true that with the proposed solution, attackers can still launch smurf attacks with the broadcast of a local LAN, however they cannot use arbitrary broadcasts to commence smurf attacks. They have to get inside access on every subnet they want to smurf from, which also means they can be tracked down by looking at the broadcast replies to the victim. Also, it is true that the bandwidth of a smurf is a multiple of the attackers bandwidth, so it is relevant. But launching *smurf* attacks (not DDOS) from anything as fast as an OC-12 would simply overload the used broadcast addresses. The maximal bandwidth of each broadcast reply is the bandwidth of the subnet whose broadcast you're pinging, it is not limited only by your own bandwidth. That's also the point why only the use of *many different* broadcasts at a time can launch a devastating attack. You would have to operate from several moderately-fast boxes, e.g. smurf with 100 different broadcast addresses, each from one T1, or smurf them from a T3, cycling through the broadcast list, in order not to concentrate to much bandwith on a single broadcast, which could overload the broadcast itself (like the smurf.c programs do). Additionally, the proposed solution is obviously meant to be implemented along with ingress traffic policing. If a subnets external router uses both rfc1122 and ingress filtering rules, there is no chance for an outside or inside attacker to ever launch a broadcast amplifier flood. On Fri, 12 May 2000, Vipul Shah wrote: > Mixter, > > Currently, we have started a discussion thread on NANOG mailing list for DDoS Smurf attack solution... > http://www.merit.edu/mail.archives/nanog/ > > One of the response (attached mail) says that, such Smurf attack is not effective unless it is launched from sites with switched ethernet and OC-3 or better connectivity. Hence it is not beneficial to any attacker. > > Since I don't have experience/knowledge about which kind of sites are compromized for generating attacks, I suggest , if you can reply to the attached mail (either to me or directly to NANOG list). Like kind of networks used for launching attacks and typical number of DDoS agents. Such knowledge will help us to finalize , whether the proposed solution is useful to implement or not? > > Thanks, > Vipul >

1 0

Internet helps fire victims of Los Alamos Fire.
by John M. Brown 16 May '00

16 May '00

Its a wonderful thing to see the Internet help bond people together. Folks at ShoutCAST have a kick butt product. It allowed us to whip up a internet broadcast of the only radio station in Los Alamos and to get LIVE information to the evacuated towns people. Over 25,000 people where evac'd and are just now returning home. Folks like The New Mexico Internet Professional Assoc. put up a database to track people and to let them communicate with each other via BBS system. Folks at other ISP's around the state helped keep things glued together. Backbone provided by several companies. CW, Verio, UUNET, QWEST All ran without a hitch. The biggest thing was the ability to get informationn out to people as quickly and as correct as possible. We where able to use the power of the net to get the word out quickly about a wide range of things. I hope that other communities and the ISp's that service those areas work together as well as the folks that did here. This is really what the net is about. Bringing people together, not only locally, but regionally, nationally, and globally. People from around the world where able to help, send their prayers, etc by getting from the various web sites. Let us not forget that the net is also about: Doing Good Having Fun Local ISP's and providers that I'd like to thank for their direct or indirect support. C&W CyberMesa.com iHighway.net LosAlamos.com La-Tierra NM.NET/ORG UUNET QWEST Verio News providers: KRSN Los Alamos Radio krsn.losalamos.com ABQ Journal www.abqjournal.com The various TV (local and nantional)

1 0

IETF TE Interim Meeting
by Randy Bush 15 May '00

15 May '00

To: IETF-Announce: ; Subject: Interim TEWG meeting June 14, 20000 Date: Sun, 14 May 2000 12:06:32 -0400 From: Steve Coya <scoya(a)cnri.reston.va.us> An interim meeting of the Traffic Engineering Working Group (tewg_ will be held on the 14th of June, 2000 Time: 9.00AM to 1.00PM. The venue is shown below: Hyatt Regency Albuquerque Convention Center 330 Tijeras Albuquerque New Mexico 87102

1 0

Re: CIDR Report
by Danny McPherson 15 May '00

15 May '00

> None of these are big enough to justify their own backbone operations or to > buy a backbone from someone else, or there wouldn't be a problem. Paying scads > of extortion money is also problematic (cheaper to simply burn the IP addresses). > > I am NOT advocating tossing all of that out. I am simply bringing up a > problem condition. Please, don't shoot the messenger, or otherwise get > defensive (return fire is a bitch). Nope, all of these are reasonable, the ones that aren't are, for example, where folks have a single connection, or multi-home only to a single provider. > What I am bringing up here is that new, information-age companies, > as predicted in MegaTrends over 10 years ago, are now starting to > appear. They are very diffused (sparse population, over very large > areas of the globe) and have connectivity needs which are both critical, > yet very different from click-n-morter customers that the Big8 was > built up to handle (either classful or classless). The current architecture > is not handeling them very well. > > The problem is currently in it's infancy, it will get much worse. I'm not disagreeing with any of this. Actually, I see reliability and availability feeding into all these other issues as well. It just that some of the folks advocating portability and deaggregation are using "route table size doesn't matter anymore" as an argument, when it absolutely does matter, especially if we plan to make the Internet more reliable, and less vulnerable. -danny

7 8

Re: ATOMIC AGGREGATE
by Danny McPherson 15 May '00

15 May '00

> I am trying to understand the BGP ATOMIC AGGREGATE attribute from a BGP > router which receives aggregate routes. Can somebody tell me what is the > action > taken by a BGP router when it receives a aggregate route with ATOMIC > AGGREGATE. > > I understand that the ATOMIC AGGREGATE is used when there is loss of > information while aggregating the routes. But what does the receiver of > the attribute do with the information. what kind of action does it take > ? It serves as an indication to the receiver that it can't "deaggregate" the prefix per some of the granularity associated with the NLRI of that route (i.e. AS paths) may have been lost when the aggregate was created, and deaggregation could result in the introduction of loops. > If anyone can put some light on how this BGP attribute gets utilized in > the real world i would greatly appreciate. However, I don't believe many folks actually deaggregate routes in real networks (at least not intentionally :-). I've seen several implementations which don't correctly attach the attribute, though it didn't break anything at the time. In the future, queuries of this nature may be more appropriately directed to the IDR WG list (bgp(a)ans.net) -danny

1 0

[Fwd: Re: Optical Crossconnects and IP]
by Andrew Bender 15 May '00

15 May '00

Vadim Antonov wrote: > I would like to inject some sanity into the traffic engineering > discussion by reminding about some small fact of life: > > Nobody knows how to measure how what the demanded/available bandwidth > ratio is when the circuit is overloaded. I think the point of TE is to avoid overbooking in the first place, and also calculate a suitably assured protection path. (or just build for the busy hour, of course) > What it means that by and large traffic engineering is done by seat of > the pants. May be so, but at some point every business will be accountable to operating cost. This is the hallmark of a mature sector in a commodity market, in fact. > PPS Pluris core technology allows to treat traffic as a liquid - unlike simple > IP routing it works by splitting aggregated streams, which can be sent > along different paths. Not by hashing flows I hope. Otherwise, I suspect that non-Newtonian CFD per macroflow can't possibly be a time-complexity win over the "simple" MCF optimization problem... :P Regards, Andrew Bender thrupoint.net

1 0

NANOG 19
by Carol Wadsworth 15 May '00

15 May '00

Registration for NANOG 19 is now closed. A waiting list has been established. If you would like to add your name to the list, please send email to carolw(a)merit.edu and include your organization and telephone number in the message. Thanks. Carol Wadsworth Merit Network, Inc.

1 0