- NANOG - lists.nanog.org

Re: TCP/BGP vulnerability - easier than you think
by Iljitsch van Beijnum 23 Apr '04

23 Apr '04

On 23-apr-04, at 12:03, Florian Weimer wrote: >> BTW, anyone seen anything supporting Paul Watson's claim that all it >> takes to break a session is four packets? > Where does he claim that? In several news stories, such as http://www.wired.com/news/technology/0,1282,63143,00.html? tw=wn_tophead_2 > I've browsed his paper and the packet numbers he gives are higher. Do you have a link? I haven't been able to find it so far. > Either this issue has been wildly exaggerated, or Paul Watson's paper > is not the whole story. Yes. I've never been one for conspiracy theories but now I'm tempted to become a believer... ("That whole SMNP vulnerability thing was just a trick to get us to install fixed IOSes before the real story gets out.") >> I assume he's talking about this vulnerability that was fixed in >> FreeBSD in 1998: http://ciac.llnl.gov/ciac/bulletins/j-008.shtml >> I certainly hope our collective favorite vendors didn't overlook >> this one. > Maybe they have fixed it now? This would explain most of the frenzy. I guess we have to wait a bit longer to find out.

1 0

Re: Backbone IP network Economics - peering and transit
by Tom Vest 23 Apr '04

23 Apr '04

On Apr 22, 2004, at 9:29 PM, Michel Py wrote: >> Deepak Jain wrote: >> But that structure doesn't vary vastly if you'd traffic out >> that gig via transit vs direct connect. It does vary (and >> add lots of infrastructure) if you don't aggregate your >> traffic at IXes and instead use loops to bring transit to >> you instead of going to it. (say a few 100Mb/s or OC3s in >> a few places instead of a GigE at an IX). > > Indeed. > >> Perhaps we should (for technical reasons) describe >> peering as "direct connecting". > > This makes a lot of sense to me (although I would suggest a different > name later). Since the beginning I have been trying to make the point > that "direct connecting" was typically a no-brainer in terms of money. > Peering when you have to buy the local loop is not such a slam dunk. > >> Business reasons aside, technically the difference is >> that with transit you are expecting access via indirect >> connections to networks. > > I'm not so sure about this. There are lots of people that buy transit > and are directly connected to their provider in an IX for example. > >> With peering you expect direct connections into a network. > > If "direct connecting" != peering then definitely. > > Maybe we need to say differentiate between: > - Connected transit > - Remote transit > - Connected peering > - Remote peering > > And agree that, by default, > transit ~= remote transit > peering ~= direct peering > > Michel. The kind of relative cost dynamics described in this thread leave a measurable geographic imprint on the Internet. Big network operators make deployment decisions explicitly to optimize capex/opex over a relatively short horizon, with proximate peering opportunities often justifying higher upfront costs. Conversely, there are plenty of places where lack of public IX facilities, and/or exploitive metro/regional infrastructure costs make remote interconnection not-economically-viable -- so very little peering or multihoming in general. Regions or countries fitting the latter description typically have very few autonomous networks, because there's really very little be gained from running your own network. Infrastructure (layer2, "basic telecom," etc.) was once highly regulated everywhere, and didn't/doesn't really become affordable anywhere unless/until someone in authority compels sharing or underwrites the development of competing infrastructures. I don't think it was just a coincidence that EGP was developed during the same period that Ma Bell was being broken up into regional and national "independent operating entities"... Voila: The origin and evolving structure of IDR is a product of layer 8/9. There's a time dimension to this dynamic as well, as infrastructure savings belatedly give rise to reduced transit costs; once and future operators jump into and out of the game at different points in the cycle. Anyone else notice how many "content providers" are now suddenly looking for peering coordinators? It's not because they expect other operators to come to their isolated data center(s)...they are building out, because that's what makes sense for them at this point in the cycle. Now I will go back to hunkering down until SF. Tom

1 0

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 22 Apr '04

22 Apr '04

Please forgive me if I'm naive and/or ask a stupid question, but is there any reason (besides your platform not supporting it) _not_ to MD5 your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are MD5ed (v6 not there yet). Michel. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Joe Rhett Sent: Tuesday, April 20, 2004 8:07 PM To: Rodney Joffe Cc: NANOG Subject: Re: Winstar says there is no TCP/BGP vulnerability I've left your entire message below so that one can see I've removed nothing. Winstar has made NONE of the statements you are interpreting from their response. They have simply stated that they don't support it at this moment in time. I'll grant you that they could have answered "when" or "why" or "what else". But they certainly didn't say anything you are suggesting that they have said. <joke>Should we ever meet, I'll remember to never turn down a beer. You might think I'm pro-prohibition or something...</joke> On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote: > > Perhaps we are all making too much of this... > > It appears that Winstar feels that there is no need for MD5 > authentication of peering sessions. One of our customers has just had > the following response from Winstar following a request to implement MD5 > on their OC3 connection to Winstar. My first suggestion is to locate > another upstream provider (they have 3 already). > > However, perhaps someone from Winstar would care to help us all > understand what the alternative solution is to securing the session via > MD5? I would *love* an alternative to the 5 days of work we've just gone > through. > > > -----Original Message----- > > From: Justin Crawford - NMCW Engineer [mailto:jcrawford@winstar.net] > > Sent: Tuesday, April 20, 2004 11:13 AM > > To: xxxxxx > > Subject: Re: *****SPAM***** MD5 implimentation on BGP > > > > xxxxx, > > > > Winstar does not currently run MD5 authentication with our peers. > > > > Thanks > > > > Justin > > > > Thank you for your time and business > > > > Justin Crawford > > Winstar NMCW > > Ph: 206-xxx.xxxx > > Has anyone else run in to this with Winstar? > > -- > Rodney Joffe > CenterGate Research Group, LLC. > http://www.centergate.com > "Technology so advanced, even we don't understand it!"(SM) -- Joe Rhett Chief Geek JRhett(a)Isite.Net Isite Services, Inc.

8 9

RE: Backbone IP network Economics - peering and transit
by Michel Py 22 Apr '04

22 Apr '04

> Patrick W.Gilmore wrote: > Unless they have cheap access to a free NAP (TorIX, SIX, etc.), > transit, even at higher prices, is probably be the best / > cheapest way to reach the Internet. This is true, but there are plenty of other opportunities for peering, such as: both parties buy DS-3 class transit from the same tier-2 or even maybe tier-3 provider in a colo (which will likely be a BFM, other problem) not a formal IX. In other words, peering in an IX does cost money, but peering at a colo might not, as these messy colos are mostly unmanaged and nobody cares about that 25ft cross-over cable :-) Michel.

11 15

TCP vulnerability
by Grant A. Kirkwood 22 Apr '04

22 Apr '04

Since no one's mentioned it yet, apparently there was a change in plans. It was just released a day early. http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_o… And the official one: http://www.uniras.gov.uk/vuls/2004/236929/index.htm Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

16 26

RE: Backbone IP network Economics - peering and transit
by Michel Py 22 Apr '04

22 Apr '04

>> where's the "lot of cost"? > Stephen J. Wilcox > This is private vs public.. Even if it's private, and assuming that you're clever enough not to peer for a modem's worth of traffic, the cost is a no-brainer, IMHO. Someone checks my math please: At $20 per megabit for transit (which I find very low, but let's go for it anyway) a GE link for peering with an average use of 10% means $24000 per year saved; pays for the xconnect. Michel.

3 2

Re: TCP/BGP vulnerability - easier than you think
by Crist Clark 22 Apr '04

22 Apr '04

David Luyer wrote: [snip] > With ipsec, you have crypto overhead before you have any opportunity > to do the basic sanity check. Minor point, but with IPsec, the 32-bit SPI and the 32-bit replay counter are very low cost ways to drop the majority of traffic from a flood of random junk with no crypto calculations. You actually have more bits with AH or ESP than with TCP. The 32-bit SPI must be an exact match like the two 16-bit port fields, and you have 32-bits of sequence number in both, but the TCP window is much larger than the IPsec window (usually 6-bit by default) leaving you more bits to check. -- Crist J. Clark crist.clark(a)globalstar.com Globalstar Communications (408) 933-4387

1 0

RE: asymmetric/peer RPF [RE: TCP/BGP vulnerability - easier than you think]
by Michel Py 22 Apr '04

22 Apr '04

From: Pekka Savola [mailto:pekkas@netcore.fi] > When discussing RPF towards peers or w/ asymmetric > paths, I'd recommend to read RFC 3704 I have, this is a very good document. > If your prefix filter stops a neighbor from > advertising a prefix, maybe you would have to > revise your prefix filtering policy (e.g., > revise it more often, get notice if the peer > sends you something you're filtering, tell to > peers not to advertise anythnig that's not > properly in the routing DB's, etc.)? This > doesn't seem so bad to me... I agree, but there are many people that think it is very bad. Trouble is, using RPF has a great potential for problems as it will drop traffic (which is the reason it's not being used in the first place). The point I was trying to make is as follows: if you don't use RPF (which is probably the case) then there is no harm in prefix-filtering peers (if you are not a tier-1) even if the prefix-filters are not perfect. Needless to say, there is no point prefix-filtering if your filters are completely messed up. Michel.

1 0

RE: Backbone IP network Economics - peering and transit
by Michel Py 22 Apr '04

22 Apr '04

> Stephen J. Wilcox wrote: > I assume Vijay meant the cost of a port for private > peering, in which case if you private with all your > peers and you have a lot of small peers thats going > to be a lot of cost for a few kbps of traffic I'm having trouble parsing this. You connect your FE or GE port to an ISL/802.11q trunk to the colo's/IX switch. Then either a)everyone is in the same broadcast domain (dumb but no config), or there's a VLAN on that trunk from/to you to your peer(s). Save for the colo's/IX administrative/xconnect fee, where's the "lot of cost"? Michel.

2 1

snmp vuln
by Mikael Abrahamsson 22 Apr '04

22 Apr '04

http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml This one seems much worse than the TCP RST problem. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

3 2