- Test - lists.nanog.org

The Cidr Report
by cidr-report＠potaroo.net 23 Apr '04

23 Apr '04

This report has been generated at Fri Apr 23 21:43:46 2004 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-04-04 133338 93532 17-04-04 133459 93509 18-04-04 133358 93567 19-04-04 133352 93577 20-04-04 133521 93727 21-04-04 133676 93739 22-04-04 133763 93752 23-04-04 133783 93829 AS Summary 16996 Number of ASes in routing system 6845 Number of ASes announcing only one prefix 1408 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 73610240 Largest address span announced by an AS (/32s) AS568 : DISOUN DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 23Apr04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 133912 93842 40070 29.9% All ASes AS4134 706 140 566 80.2% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 718 202 516 71.9% TWTC Time Warner Telecom AS7018 1408 981 427 30.3% ATTW AT&T WorldNet Services AS6197 691 305 386 55.9% BNS-14 BellSouth Network Solutions, Inc AS7843 497 112 385 77.5% ADELPH-13 Adelphia Corp. AS701 1296 932 364 28.1% UU UUNET Technologies, Inc. AS22909 384 31 353 91.9% CMCS Comcast Cable Communications, Inc. AS27364 405 70 335 82.7% ARMC Armstrong Cable Services AS6198 561 229 332 59.2% BNS-14 BellSouth Network Solutions, Inc AS9583 438 116 322 73.5% SATYAMNET-AS Satyam Infoway Ltd., AS22773 361 42 319 88.4% CXAB Cox Communications Inc. Atlanta AS9929 339 31 308 90.9% CNCNET-CN China Netcom Corp. AS1239 948 644 304 32.1% SPRN Sprint AS17676 339 37 302 89.1% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS4355 381 99 282 74.0% ERSD EARTHLINK, INC AS6140 379 105 274 72.3% IMPSA ImpSat AS6478 300 47 253 84.3% ATTW AT&T WorldNet Services AS209 759 520 239 31.5% QWEST-4 Qwest AS1221 860 628 232 27.0% ASN-TELSTRA Telstra Pty Ltd AS25844 243 16 227 93.4% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS14654 227 4 223 98.2% WAYPOR-3 Wayport AS11305 241 31 210 87.1% INTERL-80 Interland Incorporated AS4766 462 254 208 45.0% KIX Korea Internet Exchange for "96 World Internet Exposition AS3356 898 693 205 22.8% LEVEL3 Level 3 Communications AS9443 359 170 189 52.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS2386 431 244 187 43.4% ADCS-1 AT&T Data Communications Services AS6347 377 195 182 48.3% SAVV SAVVIS Communications Corporation AS6327 206 28 178 86.4% SHAWC-2 Shaw Communications Inc. AS14824 275 108 167 60.7% NCC-105 NewSouth Communications Corp. AS15270 208 42 166 79.8% PDP-14 PaeTec.net -a division of PaeTecCommunications, Inc. Total 15697 7056 8641 55.0% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 24.246.0.0/17 AS7018 ATTW AT&T WorldNet Services 24.246.128.0/18 AS7018 ATTW AT&T WorldNet Services 60.254.0.0/20 AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM 64.22.0.0/18 AS3561 CWU Cable & Wireless USA 64.46.0.0/18 AS7850 IHIGHW iHighway.net, Inc. 64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS 64.46.12.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.46.34.0/24 AS3408 64.46.60.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.46.63.0/24 AS7850 IHIGHW iHighway.net, Inc. 66.51.128.0/20 AS23401 NAC Net Access Corporation 66.51.140.0/24 AS23401 NAC Net Access Corporation 66.114.0.0/19 AS16526 BIRCHT Birch Telecom, Inc. 69.26.32.0/19 AS17307 VIRTEL-15 Virtela Communications 132.0.0.0/10 AS568 DISOUN DISO-UNRRA 137.0.0.0/13 AS568 DISOUN DISO-UNRRA 138.136.0.0/13 AS568 DISOUN DISO-UNRRA 158.0.0.0/13 AS568 DISOUN DISO-UNRRA 160.213.112.0/20 AS25440 INFONET-NESTLE Nestle European Data Center 160.213.240.0/20 AS25440 INFONET-NESTLE Nestle European Data Center 164.234.0.0/16 AS721 DNIC DoD Network Information Center 164.234.0.0/18 AS721 DNIC DoD Network Information Center 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.30.127.0/24 AS719 LANLINK Elisa Oyj 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.43.230.0/24 AS4738 SAARDNET-AS South Australian Academic Research and Development Network 192.44.0.0/19 AS702 AS702 MCI EMEA 192.81.182.0/24 AS719 LANLINK Elisa Oyj 192.81.183.0/24 AS719 LANLINK Elisa Oyj 192.81.184.0/24 AS719 LANLINK Elisa Oyj 192.119.135.0/24 AS270 NASA National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.136.71.0/24 AS719 LANLINK Elisa Oyj 192.136.79.0/24 AS719 LANLINK Elisa Oyj 192.153.144.0/21 AS568 DISOUN DISO-UNRRA 192.172.0.0/19 AS568 DISOUN DISO-UNRRA 192.188.208.0/20 AS568 DISOUN DISO-UNRRA 192.243.32.0/23 AS2044 PALINA Palin Aquisitions Inc. 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS568 DISOUN DISO-UNRRA 198.97.80.0/20 AS568 DISOUN DISO-UNRRA 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.192.0/20 AS568 DISOUN DISO-UNRRA 198.97.240.0/20 AS568 DISOUN DISO-UNRRA 198.97.247.0/24 AS3475 DEPART-52 Department of the Navy 198.101.4.0/22 AS568 DISOUN DISO-UNRRA 198.136.32.0/20 AS19329 MCBCC Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY CityNet, Inc. 198.161.87.0/24 AS6539 GTGR GT Group Telecom Services Corp. 198.161.165.0/24 AS852 AGTA Telus Advanced Communications 198.163.155.0/24 AS684 MRN Manitoba Regional Network 198.167.0.0/16 AS7456 INS-51 Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 UU UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASK SaskTel 198.232.133.0/24 AS23075 SKOTOS Skotos Tech, Inc 199.10.0.0/16 AS568 DISOUN DISO-UNRRA 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.84.0.0/16 AS701 UU UUNET Technologies, Inc. 199.114.0.0/18 AS568 DISOUN DISO-UNRRA 199.114.0.0/21 AS568 DISOUN DISO-UNRRA 199.114.128.0/18 AS568 DISOUN DISO-UNRRA 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.136.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.138.0/24 AS721 DNIC DoD Network Information Center 199.114.140.0/24 AS3544 DISAUN DISA/UNRRA 199.114.142.0/24 AS721 DNIC DoD Network Information Center 199.114.144.0/24 AS721 DNIC DoD Network Information Center 199.114.148.0/24 AS721 DNIC DoD Network Information Center 199.114.150.0/24 AS721 DNIC DoD Network Information Center 199.114.152.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.160.0/24 AS1733 ADP-41 AF DDN PMO 199.120.32.0/19 AS16582 NXLI NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS568 DISOUN DISO-UNRRA 199.123.0.0/18 AS568 DISOUN DISO-UNRRA 199.123.16.0/20 AS568 DISOUN DISO-UNRRA 199.123.80.0/21 AS568 DISOUN DISO-UNRRA 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.197.8.0/22 AS21814 PARSON-18 Parsons Corp. 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 202.2.64.0/20 AS9729 IS-AP iAdvantage Limited 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.0.0/20 AS4658 NETFRONT-AS NETFRONT I.T. LIMITED (HONG KONG) 202.70.28.0/24 AS4515 ERX-STAR Star Internet Services Ltd. 202.70.240.0/20 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.86.142.0/24 AS30362 HAWAI-1 Hawaii-Pacific Teleport 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.122.76.0/24 AS17553 TIMELESS-AP System Integration provider 202.123.96.0/20 AS9288 COMCEN-AS-AP Com-Cen Pty Ltd 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.155.243.0/24 AS4795 INDOSAT2-ID-AP INDOSATNET-ASN 202.164.224.0/19 AS7599 IPXC-AS-AP IP Exchange 203.32.4.0/23 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.132.107.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.132.108.0/24 AS10236 FOXGOLD-NET-AU-AP FOXGOLD COMMUNICATIONS 203.174.96.0/24 AS15412 FLAG-AS Flag Telecom Global Internet AS 204.69.144.0/22 AS5668 CIH-12 CenturyTel Internet Holdings, Inc. 204.154.125.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBI Exobit Networks Inc. 205.150.0.0/15 AS701 UU UUNET Technologies, Inc. 205.159.72.0/24 AS1660 ANSCOM-5 ANS Communications 206.41.32.0/19 AS14824 NCC-105 NewSouth Communications Corp. 206.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 206.167.57.0/24 AS376 RISQR-3 Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL-33 Telesat International Ltd. 206.253.190.0/23 AS8123 POLYBA Polybase 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 209.169.219.0/24 AS189 GNTY Genuity 209.169.223.0/24 AS189 GNTY Genuity 209.172.0.0/18 AS7770 TRTI Triton Technologies, Inc. 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.213.32.0/19 AS10629 INS-52 Inter-Pacific Network Services 209.213.50.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.51.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.55.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.56.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.222.137.0/24 AS27429 TIL-33 Telesat International Ltd. 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 209.251.64.0/19 AS10266 MDCN MDC, Inc. 210.213.0.0/19 AS6453 GLOBEINTERNET Teleglobe America Inc. 216.18.224.0/21 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.224.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.18.228.0/22 AS11458 IMBRIS-1 IMBRIS, INC. 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services 216.145.130.0/24 AS11937 TRXI TRX Inc. 216.145.132.0/24 AS11937 TRXI TRX Inc. 216.145.133.0/24 AS11937 TRXI TRX Inc. 216.145.134.0/24 AS11937 TRXI TRX Inc. 216.145.135.0/24 AS11937 TRXI TRX Inc. 216.145.152.0/24 AS10758 INWAVE INWave Internet, Inc 216.145.156.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.158.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.176.0/21 AS20304 JIS-32 JVLNET Internet Services 216.145.177.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.178.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.184.0/21 AS10758 INWAVE INWave Internet, Inc 216.145.200.0/21 AS20304 JIS-32 JVLNET Internet Services 216.186.151.0/24 AS3356 LEVEL3 Level 3 Communications 216.186.152.0/21 AS3356 LEVEL3 Level 3 Communications 216.186.160.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.164.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.192.0/19 AS3561 CWU Cable & Wireless USA 216.186.192.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.198.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.248.0/23 AS3356 LEVEL3 Level 3 Communications Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

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