September 2002 - Test - lists.nanog.org

Re: Vulnerabilities of Interconnection
by Michael A Tomasura 16 Sep '02

16 Sep '02

> > In the event of a emergency, I would very much like to be as > > able to reach my bank via the net as walking into their offices. > > Yes, because banks are such a critical resource when there is an > emergency... > It would take years of design and implementation to have on-line banking during an emergency. It�s hard enough to get an on-line stock trade in heavy trading. Plus most Americans wouldn't use on-line banking. They don't even trust direct deposits. If there is a real emergency I think most people will go back to AM radio for information. just my 2 cents ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

1 0

RE: BGP Default Route
by Martin, Christian 16 Sep '02

16 Sep '02

> > On Sat, Sep 14, 2002 at 02:18:15PM -0400, Lupi, Guy wrote: > > > I was wondering how people tend to generate default routes to > > customers running bgp. > > Short answer: don't > > Longer answer: To solve the exact problems you mention below, > only advertise a aggregate block of your own to this customer, > say x.x.0.0/16, then the customer will configure his device > something like > > ip route 0.0.0.0 0.0.0.0 x.x.0.0 > > or > > set routing-options static route 0.0.0.0/0 next-hop x.x.0.0 resolve > > This will ensure that if the border router get's isolated, it will no > longer advertise x.x.0.0/16 to the customer, and the customer > router can > choose a backup path. What if the aggregate is local to the border router? If you want to avoid this problem, you will have to use a route that originates from somewhere away from the border. This is more work than is necessary, IMO. If your border router is isolated, you have a design problem or a failure state that is just as likely to occur(if not moreso) than the border router failing. What I will say is that a "full-table" peer should not get a default route at all. Of course, this isn't very enforcable. In any case, providing a default is not something I would say shouldn't be done, IMHO. Thanks, chris > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Senior network engineer @ AS3292, TDC Tele Danmark > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. >

2 1

Top AS Offenders causing RFC-1918 DNS traffic
by John M. Brown 15 Sep '02

15 Sep '02

Based on a recent presentation done by KC (Caida) here is a URL to the " 20 AS's case more than 50 percent of the RFC1918 PTR updates" http://www.caida.org/outreach/presentations/dns0209/mgp00025.html It would seem that folks like 4134 3352 7132 5673 5676 (top five) could mitigate this traffic with ease.

6 8

BGP Default Route
by Lupi, Guy 15 Sep '02

15 Sep '02

I was wondering how people tend to generate default routes to customers running bgp. Is it from the aggregation router that customers are directly connected to, or from one or more core/border routers? If one is using a default route to null 0 on aggregation routers that maintain a full bgp table (assuming that the full table represents all destinations on the Internet, and therefore dumping traffic to a destination not in that table), and assuming Cisco routers using the default-information originate command, then as long as the router is up and it's bgp sessions with peers are up, it is going to send the default route regardless of it's ability to forward traffic to external destinations. The same goes for the default route announced by a core/border router, if it's default is generated by the null route. Is an assumption made that with a good network design, no router will every be without valid routing information, with the exception of a complete failure of the router? Guy H. Lupi

3 2

Re: An article from the Miami Herald about the Florida MIX
by Gregory Hicks 15 Sep '02

15 Sep '02

> Date: Sat, 14 Sep 2002 21:48:18 -0700 > To: nanog(a)merit.edu > From: "Martin J. Levy" <mahtin(a)mahtin.com> > > Hello all, > > I apologize for the operational nature of the email, but I interrupt the regular threads to post something to do with peering points. > > This is from the Miami Herald. What's strange about this is... It's an example of peering converting to transit, or in this case a peering point converting into a transit network. The two are so different that I can't see the connection. > [...snip...] > >BellSouth is calling its new design the BellSouth Regional IP Backbone (BRIB). I'm quite sure they mis-spelled BRIB. It IT pronounced "bribe". As in what they 'donated' to get permission, etc? Regards, Gregory Hicks > > > >The BRIB will feature three central points of presence in Atlanta, Miami and New Orleans. > > > >Sutton said BellSouth will release more information about the BRIB within the next few weeks. > > > > --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton You can have it done good, fast, or cheap -- pick any two.

1 0

Strange internet activity
by Arie Vayner 15 Sep '02

15 Sep '02

Hi Has anyone noticed any strange internet activity in the past few hours? I have noticed lot's of client host generating a massive number of HTTP GET requests to WEB servers (like a single host sending a flood of more than 50 requests) The clients seem to be windows boxs... Arie

4 4

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 15 Sep '02

15 Sep '02

It is interesting that you cite Paul Baran since his work at RAND was arguably the first to recommend a distributed network. The start of the quasi myth that the Internet was developed to withstand a nuclear attack. If my memory serves me correct that was Baran's assignment, but it was not the driving force behind the creation of ARPANET the two were non-sequitor. The point being from a structural stand point there is convincing empirical evidence that the Internet is not a distributed network. It is what physicists would call a small world or scale free network. Most of this work has been done at the router and AS level. For example the vast majority of routers have only a few connections, while a small minority has the vast majority of conections. The applied side of this I think I've posted about before, so please pardon the redundancy, is that Internet as the AS and router level is very resilent to random failures but highly susceptible to targeted failures. This has become so predominant in the literature it has left many folks asking questions along the lines of security. Just to give you a brief flavor the finding have been from Barabasi's group at Notre Dame in 2000, Cohen in Israel slightly later, and Callaway in 2001. Similat findings have been found from a spatial perspective with a group at BU's computer science department and the Notre Dame group as well. This has led a scramble to come up with new Internet topology generators - another laundry list of references and approaches - but the reported security implications have had a bumpier road. Are all these computer scientist and physicists wrong, I'm sure a good case could be made against them, but it leaves several open questions. There have been several good cases made for the resilence of the statas quo and good arguments that there could be problems. The question is how much of it is political. One side looking for problems they can point fingers at in the name of homeland security and one side denying any problem at all because it is a lot cheaper if there is no problem. ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Friday, September 13, 2002 7:49 pm Subject: Re: Vulnerbilities of Interconnection > > On Fri, 13 Sep 2002 sgorman1(a)gmu.edu wrote: > > Or you cut the lines coming into the city - i.e Chicago has > about 5 > > diverse routes for fiber into the city. No explosives required > and you > > get the same effect. > > The early ideas for the arpanet/internet never said every point > would work > under all conditions. The premise was if you destroyed (which implies > something is in fact destroyed) part of the network, the surviving > partsof the network could function. It said nothing about the > ability of the > part of the network which was destroyed to function. It may be > obviousthe destroyed portion of the network will not function, but > sales people > don't always go out of their way to explain the concept. > > The Paradox of the Secrecy About Secrecy by Paul Baran, August 1964 > [...] > The overall problem here is highly reminiscent of the atomic energy > discussions in the 1945-55 era--only those who were not cleared were > able to talk about "classified" atomic weapons. This caused security > officers to become highly discomfitured~by the ease with which > unclassified clues were being combined to deduce highly accurate > versions of material residing in the classified domain. This > points up > a commonly recurring difference of opinion (or philosophy) > between the > security officer and the technically trained observer. The more > technical training an individual possesses, the less confidence he > seems to have of the actual value of secrecy in protecting the > spread of new developments in a ripe technology. True security > does not always > equate to blanket unthinking secrecy. While the security value of > effective secrecy can be high, we must be realistic and > acknowledge the > constraints of living in a free society where effective secrecy in > peacetime is almost impossible. Avoiding a touchy subject by falling > back on edicts rather than rationality may automatically insure the > continued existence of the touchy subject. > [...] > > > >

2 1

An article from the Miami Herald about the Florida MIX
by Martin J. Levy 15 Sep '02

15 Sep '02

Hello all, I apologize for the operational nature of the email, but I interrupt the regular threads to post something to do with peering points. This is from the Miami Herald. What's strange about this is... It's an example of peering converting to transit, or in this case a peering point converting into a transit network. The two are so different that I can't see the connection. Martin ----------------- There are two articles. They are close copies of each together. http://www.miami.com/mld/miami/news/4070039.htm http://www.miami.com/mld/miami/business/4070691.htm >Posted on Fri, Sep. 13, 2002 > >BellSouth changes strategy of South Florida Internet network >BY BEATRICE E. GARCIA >bgarcia(a)herald.com > >BellSouth is changing the character and the mission of its South Florida Internet network. > >BellSouth's Florida Multimedia Internet Exchange (MIX) won't be billed as a major Internet access point. But the Internet network will expand outside South Florida and eventually move into the nine-state region serviced by BellSouth in order to capitalize on its newly gained entry into the long-distance market. > >BellSouth set up its Florida MIX last summer as a major Internet network access point, or NAP, where Internet traffic changes hands, with four connection points: downtown Miami, West Miami-Dade, Fort Lauderdale and Boca Raton. > >It was meant to compete with the NAP of the Americas, built in downtown Miami by Terremark Worldwide. > >However, sources say the Florida MIX never attracted many customers interested in exchanging Internet traffic between major networks. But it did sign carriers and business customers who used the network to transport Internet traffic within South Florida. > >Now that the Atlanta-based company has gained approval to offer long-distance service in Georgia and Louisiana and its application for Florida is pending before federal regulators, the company is setting the groundwork to take its data network services beyond state lines. Long-haul transport is a lucrative service. > >David Sutton, a company spokesman, said ''BellSouth is creating a next-generation Internet backbone,'' which is a system of networks and servers used to move Internet traffic long-distance. > >BellSouth is calling its new design the BellSouth Regional IP Backbone (BRIB). > >The BRIB will feature three central points of presence in Atlanta, Miami and New Orleans. > >Sutton said BellSouth will release more information about the BRIB within the next few weeks. >

1 0

Sprint BGP customer policy
by jlewis＠lewis.org 14 Sep '02

14 Sep '02

I've been trying to make use of these 6500N:XXX community strings on a Sprint BGP session with no results. After dealing with 3 different Sprint IP engineers, I'm convinced none of them understands the following info from the Sprint web site. I'd like to hear from a Sprint routing engineer who can either help me get this working or tell me it's no longer supported. All responses from bgp4-adm(a)sprint.net and phone calls to the Sprint IP NOC have been comical at best and demonstrated a complete lack of understanding of route-maps and communities at worst. I won't embarrass them by including any of their responses. If you're a Sprint customer utilizing these communities, I wouldn't mind hearing from you as well, especially if you know what hoop has to be jumped through to get Sprint to accept and act on these communities. [from http://www.sprint.net/policy/bgp.html] AS-PATH PREPENDS Sprint allows customers to use AS-path prepending to adjust route preference on the network. Such prepending will be received and passed on properly without notifiying Sprint of your change in announcments. Additionally, Sprint will prepend AS1239 to eBGP sessions with certain autonomous systems depending on a received community. String Resulting AS Path to ASXXX 65000:XXX Do not advertise to ASXXX 65001:XXX 1239 (default) ... 65002:XXX 1239 1239 ... 65003:XXX 1239 1239 1239 ... 65004:XXX 1239 1239 1239 1239 ... This is my second attempt to send this message. Majordomo seems to have either eaten my first message or bounced it to the moderator(s). ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

3 2

RE: BGP Default Route
by Lupi, Guy 14 Sep '02

14 Sep '02

Assume I am originating default for customers that only want a default route, or a default route and some portion of the full Internet routing table. You're right, if I am the only gateway then it really doesn't matter. Obviously if there is more than one provider it would be better for the customer to accept full routes, but there are some customers out there that have 2 providers and don't want to assume the cost of purchasing a router that can accept 2 providers feeding it full tables (why you would assume the cost of 2 providers and not a reasonably priced router that can handle it I don't know, but I have run into it before). I am really just curious as to how people implement this and their reasoning for selecting a particluar method. Is your method the one you stated before, default origination from the router that is directly connected to the customer? -----Original Message----- From: Mike Leber [mailto:mleber@he.net] Sent: Saturday, September 14, 2002 4:48 PM To: Lupi, Guy Cc: 'nanog(a)merit.edu' Subject: RE: BGP Default Route The answer is you can do it all sorts of ways. Why are you originating default? If you are originating default because you are the only gateway for a customer, whatever partial connectivity your router has is better than effectively turning them off if you have a network partition. If your customer has more than one upstream they really should take full views so they have the ability to make routing decisions based on that information. This fixes your concern and is the best engineering choice. A hack would be to conditionally announce default based on the presence of some specific other route. This would be doing additional work to implement a suboptimal solution which a simpler use of BGP (full views) fixes automatically. Yes, as much as you can, your routers should be meshed with more than one connection each. Mike. On Sat, 14 Sep 2002, Lupi, Guy wrote: > I see what you are saying, and I understand that the default route would be > originated per neighbor, or per peer group for all neighbors within that > peer group. My biggest concern is that if the aggregation router with this > configuration was to lose connectivity back to the routers which provide it > with external routing information, it would still announce the default to > that neighbor. Do you feel that this is an acceptable risk, taking into > consideration that the aggregation router has redundant connectivity to > those routers that provide it with it's external routing information and it > is highly unlikely that the router would lose it's view of the world? > > > -----Original Message----- > From: Mike Leber [mailto:mleber@he.net] > Sent: Saturday, September 14, 2002 4:19 PM > To: Lupi, Guy > Cc: 'nanog(a)merit.edu' > Subject: Re: BGP Default Route > > > > On Sat, 14 Sep 2002, Lupi, Guy wrote: > > I was wondering how people tend to generate default routes to customers > > running bgp. > > Typically you would only originate default via BGP to a customer that > isn't taking a full view. > > neighbor 10.10.10.2 default-originate > neighbor 10.10.10.2 filter-list 9 out > > ip as-path access-list 9 deny ^.*$ > > > Is it from the aggregation router that customers are directly > > connected to, or from one or more core/border routers? > > In the example above the default originate is done via a specific BGP > session, so it isn't router wide on either core or border routers. > > > If one is using a default route to null 0... > > I'll leave the rest of this for somebody else to answer. > > Mike. > > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ > | Mike Leber Direct Internet Connections Voice 510 580 4100 | > | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | > | mleber(a)he.net http://www.he.net | > +-----------------------------------------------------------------------+ > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +-----------------------------------------------------------------------+

3 2