- NANOG - lists.nanog.org

Speaking of taking down the internet
by blitz 02 Jul '02

02 Jul '02

Just a FYI folks....from one of the hacker lists I'm on... >Speaking of taking down the internet > > > Extra points for only needing to affect one device and having that device > > successfully spread the payload to every other device as a part of it's > > routine network communications. Think you can't cross boundaries between > > different chipsets as implemented by different vendors (i.e. Cisco exploit > > code which wouldn't presumably work on Foundry gear)? Think again. Think > > polymorphic multi-architecture assembly. Think stuff that we were doing for > > fun in a hotel room at Defcon two years ago. > >Heh. That's fucking evil, Dan. That's completely fucking evil. I like it. >The only problem I can see with it is that it'd take a lot of space. >Routers are tight on how much you can fit into 'em, and I think you'd >stand a good chance at setting off an alarm somewhere by adding that much >code. But maybe not... you could even store the code remotely... have your >evil router 'upgrade' it's neighbors. But then you might get caught by an >IDS system. Probability is low on that happening, though. Needle in a >haystack. > >How about using the same plan, except instead of just making the routing >infrastructure go dead, how about spicing it up a little and have it go >after the root DNS servers? Thousands of devices on the backbone stuffing >a DoS down an OC192 circuit at 9.6 Gigs per second would certainly have >folks confused, I'd imagine. Especially if you spoofed the source >addresses. > >Every time they trace the attack back to the other side of yet another >router, it looks like the problem is further away. People would be >completely mystified. Traffic coming from the routers would just look like >traffic coming from something on the other side of the routers. And it >would be... each router would be generating (and routing) a huge attack. >And as pretty much all communication would be down, even if a couple folks >figured it out, they'd have no easy way to spread the word of what was >happening. Although I'm sure it would certainly hit the news. > > > Having said all of that, it's a cool (in the sense of being skillful) > > attack against the Global Data Network, but hardly the easiest. It would > > probably cost lots less overall to just crash something big or something > > that goes boom over at Verisign and/or some places in the EU. I'm sure they > > have plumbing. Computers still don't like water. > >And fiber still doesn't like tractors ;-) Hmmm...? You make the decision if this is relevant...you didn't hear it from me...

1 0

Re: Sprint peering policy
by Andrew Odlyzko 02 Jul '02

02 Jul '02

On Mon, 1 Jul 2002 21:07:06 -0400, Richard A Steenbergen wrote: > It's all so much posturing, just like the people who claim they need OC768 > now or any time in the near future, or the people who sell 1Mbps customers > on the fact that their OC192 links are important. > If there is more than ~150Gbps of traffic total (counting the traffic only > once through the system) going through the US backbones I'd be very > surprised. Several estimates floating around (*) suggest between 60 and 100 PB (petabytes) per month of US backbone traffic, which works out to 180 and 300 Gb/s average traffic. Andrew Odlyzko (*) See my papers at <http://www.dtc.umn.edu/~odlyzko/doc/networks.html>, or a recent (and about to be updated) report from RHK.

2 1

Network Security Requirements draft
by George Jones 02 Jul '02

02 Jul '02

We (UUNET) have an internal document that we've been using for a few years as the basis for tests of security features of equipment to be connected to our backbone. We're interested in making it public so that it can be improved and so that others can use it. You can view the current draft at: http://www.port111.com/docs/draft-jones-netsec-reqs-00.html (HTML) or http://www.port111.com/docs/draft-jones-netsec-reqs-00.txt (text) the overall goal is an improvement in the security features of devices implementing IP. The means that this document tries to provide is a clear definition of security requirements that consumers/operators of networking gear can point to (in RFPs) to say "see, we want security and this is what it means". The current list of requirements is skewed to the needs of large networks (consider the source), but it does provide a means of defining "profiles" for specifying subsets of requirements for different classes of devices (core, edge, ... toasters.). Most of the requirements specify features that are generally implemented today (logging, aaa), though some of the requirements specify highly desirable features that are not implemented in current products (stealthing, monitoring, sampling, etc.) What we're requesting here is feedback network operators and vendors on how to make this document useful in achieving actual improvements in security. Specifically, we're requesting feedback/discussion on: * The requirements listed * Important requirements that are missing * Document structure * How to make it useful. The next step will likely be submission of an Internet draft- c.a. July 2. Input prior to that date stands a much better chance of being included :-) Feel free to reply to me <george(a)uu.net> or reply to the list. Thanks, ---George Jones

3 4

RE: Sprint peering policy
by E.B. Dreger 02 Jul '02

02 Jul '02

EBD> Oversimplifying the model, this works out to ~500 kbps per EBD> US citizen. Allowing for burstiness, I offer 50 GB/mo EBD> transfer as conservative for said bandwidth level. off-list> My math shows ~500bps per US citizen: off-list> Assuming 150,000,000,000 bits and 280,000,000 citizens. Thanks to he who pointed out to me that I cannot correctly work exponents. D'oh! 500 bps and 50 MB/mo using correct math. (I should have questioned any figure that put me at below-average bandwidth usage...) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

1 0

Re: Sprint peering policy
by Miquel van Smoorenburg 02 Jul '02

02 Jul '02

In article <cistron.!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA/zNkI7d3EEmn3+v5DgN/l8KAAAAQAAAADJAemGHjDECnen8+YjBFaQEAAAAA(a)isprime.com>, Phil Rosenthal <pr(a)isprime.com> wrote: >Apples and oranges. Wcom isn't talking about dropping AT&T as a peer, >they just don't want to peer with "Joe Six Pack ISP". Wcom would likely >not peer with most ISPs, and I wouldn't expect them to. They gain >absolutely nothing from it, and the small ISPs gain plenty. Wcom's >costs only increase since they need "more ports". Wcom could peer with "Joe Six Pack ISP" at an exchange if - connection cost is very low (shared ethernet) - they don't peer with Joe's upstream at the same location - they only announce regional routes to Joe - they use hot potato routing everywhere in that case, the peering would just be local/regional, probably all that Joe is after anyway Mike.

6 7

RE: Sprint peering policy (fwd)
by Ukyo Kuonji 02 Jul '02

02 Jul '02

>From: Paul A Flores <floresp10(a)cox.net> > >Since this is basically a financial issue (and not really a regulatory >issue), the only way you could make it 'fair' is to have some kind of >mandate from a government body to MAKE peering 'fair'. The only way _I_ >would buy off on that, would be to have some kind of subsidy paid from tax >dollars to the carriers in question to 'force' them to peer with people who >have no other redeeming value. You wouldn't buy the notion of reciprical billing? I think this would most likely be the fairest, but maybe the hardest to implement. It would either have to be done at the end points, or at every interconnect. In this method, if the traffic across an interconnect would truely be a 1 to 1 ratio, then the bills would cancel each other out, where the 1 to 1.6 or so would lean in towards favoring the company taking more traffic onto it's network. It's just a thought, and I am not sure how it would work world-wide. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx

8 12

Re: Sprint peering policy
by Randy Bush 02 Jul '02

02 Jul '02

>>> There is no way for a company to price transit below their peering >>> costs and make money. >> this may be true, but it's the level(3) business model. and the >> rest of the industry got suckered into dropping their drawers to >> match. kinda like a bunch of old men drinking poison to see who >> dies first. > So, what's it going to take to make everyone wise up? the large ones are. this year's strategy is to use chapter 11 to shed the stockholders and lower the debt service burden, see <http://www.thestreet.com/markets/marketfeatures/1359535.html>, or to be bought by an rboc. after kpn/quest and wcom, doing a clean chapter 11 will be seen as honest business. at the same time, the market will continue to narrow and get even more bi-modal, with a few large players and many very small ones. think of it like video stores, you think there is variety at a local level, but blockbuster owns the lion's share of the market. then prices go back up, as it is easy to make the point that then current pricing is not supportable. the large folk make money at last. the small fry, with much higher cost structures struggle along, not making real money, but making good enough statistics to keep government intervention at bay, or even better, to focus the government on protectionism, fixed profits, and/or subsidization. this is a grim picture. but i am confident that the brilliant engineering minds here can come up with an innovative technical solution to this depressing business and social problem. randy

1 0

RE: how is cold-potato done?
by Vandy Hamidi 01 Jul '02

01 Jul '02

>From what I've experience on Cisco routers. The RID isn't the final deciding factor, it has been the route that was first present. I had a router peering with 10.0.0.6 and 10.0.0.7 and if I reset BGP on .6 the .7 route will stick and even though .6 comes back up the .7 route will stay. BGP resets doesn't bring .6 back up. The same applies to resetting .7 Cisco documentation that I've seen has stated the RID is the last criteria. Interesting. -=Vandy=- -----Original Message----- From: Gustavus, Wayne [mailto:wgustavus@gnilink.net] Sent: Wednesday, June 26, 2002 11:18 AM To: 'Ralph Doncaster'; Jared Mauch Cc: nanog(a)merit.edu Subject: RE: how is cold-potato done? Ultimately there won't be any ties, since BGP will eventually have to select a best path. If necessary, the decision will come down to RID. If the metrics really are the same then theoretically it doesn't matter which path it takes. If it does matter, you will have to modify your policy to make a decision based on some other criteria that you are also influencing via policy. ___________________________________________________________ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___________________________________________________________ -----Original Message----- From: Ralph Doncaster [mailto:ralph@istop.com] Sent: Wednesday, June 26, 2002 2:08 PM To: Jared Mauch Cc: nanog(a)merit.edu Subject: Re: how is cold-potato done? > > If I peer with network X in cities A and B, and receive the same route in > > both cities with an AS-path of X, how do I know which city to use for an > > exit? I can understand how if X uses communities to tag the geographic > > origin of the traffic, but I'm not aware of many networks that do > > this. Lots of networks claim to use cold-potato routing though, so how do > > they do it? > > they use the MED sent on the route (aka metric) from the > other provider to determine which exit where they both interconnect > is the "shortest". > > this can at times provide undesired results because of > aggregation. Besides aggregation, wouldn't this lead to a lot of ties? Let's say the cities are LA & Manhattan, and the route from X originates in Chicago. I would think that it would be a common occurrance for the route to have the same metric in LA & Manhattan. -Ralph

1 0

Re: Sprint peering policy
by Ukyo Kuonji 01 Jul '02

01 Jul '02

>From: dre <andre(a)operations.net> > > >You might be able to sit in a colo and buy some cheap transit from one >provider (especially if the colo isn't carrier neutral). However, if you >want diversity in your upstreams, peering quickly becomes a reality. If you have to buy an OC48 (or dark fiber) from your CO to PAIX/PE, then where is your single point of failure? What help does having redundany peers (which are not redundant anyways) at the same peering facility if you can't get to it? I think I would much rather have two circuits to two different transit providers for the same money. Also, unless you actually have all your CO equipment at the PE facilities, you will still have to have a CO (co-located or not) from which to serve your customers in that market. I don't know what PAIX charges for this ability, or if they even allow it, but... It seems that this would get real expensive real fast. Now, for joe-blow ISP, maybe it's a good deal to be there. But he probably doesn't meet the peering requirements for larger players anyways. I don't believe in free-for-all peering. Who would you sell to if you peered with everyone? >You have to look at all the advantages/disadvantages for your organization. Of course. As I have already stated, I'm not against peering. Actaully, I am all for it. It is just that I am for it for different reasons than others may be. I don't believe that it's a great cost saveings today. Maybe in a year, things will change again, and we will all start making a profit off bandwidth. Maybe 90% of the companies will be gone, and we'll be back to where we were 10 years ago. Who knows? >People have in the past and will continue in the future to use peering to >lower costs for their networks. This is a foolhearty reason to do this. If you are only looking at the financial benefit, you are opening yourself up to a whole can of worms. If you are peered with everyone, and it is costing you $x a meg to get off your network, then you should cancel all peering the minute it is seen that it will cost $x-1 for transit. I seriously doubt that this was the main reason why peering was started anyways. >how long can providers sell transit at $50/meg? Indeed. I hope that it isn't that long, but when you are only charging $3- to $50 a meg to your cable-modem/DSL subscriber, what profit are you making be paying more than that? >If you want to talk about advantages of transit vs. peering I think everyone knows the technical advantages and disadvantages of both peering and transit. I don't think it really has anything to do with this discussion. This discussion is more to do with that is cheaper at this time, peering or transit? Maybe I completely missed the boat on this one, but if we are talking about regulation so someone doesn't get cheated... We are talking about money. And since I brought it up, I'm not particularly interested in governmental regulation either. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

1 0

RE: Sprint peering policy
by Phil Rosenthal 01 Jul '02

01 Jul '02

But if you were hungrier, and they were the only place that had food, they *COULD* charge whatever they want, and you'd be willing to pay it, no? --Phil -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Schwartz Sent: Monday, July 01, 2002 12:45 PM To: vgill(a)vijaygill.com; Mike Leber Cc: nanog(a)merit.edu Subject: Re: Sprint peering policy On 29 Jun 2002 02:32:03 +0000, Vijay Gill wrote: > >Mike Leber <mleber(a)he.net> writes: > >>Sprint's peers aren't equal to Sprint or each other when considered by >>revenue, profitability, number of customers, or geographical coverage. > >A good proxy for the above is to ask the question: > >Do X and Y feel they derive equal value (for some value of equal) by >interconnecting with each other? > >If they think they do, then an interconnection is set up between X and >Y. However, if one party feels that they do NOT derive equal value by >interconnecting with the other, than that party usually balks. This doesn't make any sense at all. Why should X care how much value Y gets out of the deal at all?! This is like saying that Burger King should charge hungrier people more for a Whopper. DS

2 1