- NANOG - lists.nanog.org

RE: Service providers that NAT their whole network?
by Reeves, Rob 15 Apr '05

15 Apr '05

Back when I worked at RCN in 1999, they had begun putting cable modem customers behind NAT using 10/8 addresses. This occasionally drew complaints from customers who were expecting a public IP (probably wanted to host a server), but they weren't given much choice. Whether or not they're still NATing, I have no idea. I can see the benefits for residential services like cable modem or even dial-up when there will never be a need for multihoming. Practically unlimited IP pool, and I assume it's easier to control things like worm propogation (correct me if I'm wrong). However, I'm sure there's several compromises you'd have to make in order to operate this way. -Rob -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Philip Matthews Sent: Friday, April 15, 2005 3:40 PM To: nanog(a)merit.edu Subject: Service providers that NAT their whole network? A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. I am trying to get a handle on how common this practice is. No one that I have asked seems to know any provider that does this, and a search of a few FAQs plus about an hour of Googling hasn't turned up anything definite (but maybe I am using the wrong keywords ...). Can anyone give me some names of providers that do this? Can anyone point me at any documents that indicate how common this practice is? - Philip (*) Some IETF documents that mention this practice: - RFC 3489 - draft-ietf-sipping-nat-scenarios-00.txt (now expired, but available at http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-sipping-nat-scenari os-00.txt

1 0

New Outage Hits Comcast Subscribers
by Fergie (Paul Ferguson) 15 Apr '05

15 Apr '05

BetaNews: New Outage Hits Comcast Subscribers http://www.betanews.com/article/New_Outage_Hits_Comcast_Subscribers/1113367… - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://spaces.msn.com/members/fergdawg/

21 37

Re: AUP for NANOG?
by Gregory Hicks 15 Apr '05

15 Apr '05

> From: Per Gregers Bilse <bilse(a)networksignature.com> > Date: Fri, 15 Apr 2005 09:46:14 +0100 > > On Apr 14, 9:22am, Scott Grayban <scott(a)fctenterprises.com> wrote: > > The more bashing I hear here the less I want to ask a question here. > > I'm not stupid but I am worried that one question might spark a rash of flames back at me. > > > > This is a newbies point of view. > > Thanks for braving it.-) > > It would be interesting if we knew the newbie:bully:oldie ratio on NANOG. > As an oldie, I would rather see "clueless" newbie questions as opposed to > contentless rants and posturing, and I don't believe any kind of "edge" vs > "core" split of NANOG is good. Networking is end-to-end, and what is > needed is a "tech" vs "non-tech" split. > > In the old days we had a list called com-priv which effectively worked as > the non-tech counterpart; anything to do with domain names, law suits, > business practices, peering politics, legislation and regulation, etc, > etc, etc would go on com-priv. Many, if not most, people subscribed to > both lists, but kept things separate in their heads and in their postings. > That didn't mean NANOG was a panacea for newbies, but just getting today's > S/N ratio under control would be of great help. We HAVE such a list: nanog-offtopic(a)lists.blank.org It has been around for several years now... Unfortunately, not too much used... Regards, Gregory Hicks > > -- Per > --------------------------------------------------------------------- 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 I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

2 1

Weekly Routing Table Report
by Routing Table Analysis 15 Apr '05

15 Apr '05

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats(a)lists.apnic.net If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Routing Table Report 04:00 +10GMT Sat 16 Apr, 2005 Analysis Summary ---------------- BGP routing table entries examined: 159923 Prefixes after maximum aggregation: 93150 Unique aggregates announced to Internet: 76898 Total ASes present in the Internet Routing Table: 19422 Origin-only ASes present in the Internet Routing Table: 16899 Origin ASes announcing only one prefix: 7905 Transit ASes present in the Internet Routing Table: 2523 Transit-only ASes present in the Internet Routing Table: 68 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 23 Prefixes from unregistered ASNs in the Routing Table: 13 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 14 Number of addresses announced to Internet: 1381478720 Equivalent to 82 /8s, 87 /16s and 177 /24s Percentage of available address space announced: 37.3 Percentage of allocated address space announced: 58.5 Percentage of available address space allocated: 63.7 Total number of prefixes smaller than registry allocations: 74677 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 32657 Total APNIC prefixes after maximum aggregation: 15410 Prefixes being announced from the APNIC address blocks: 30588 Unique aggregates announced from the APNIC address blocks: 15419 APNIC Region origin ASes present in the Internet Routing Table: 2240 APNIC Region origin ASes announcing only one prefix: 652 APNIC Region transit ASes present in the Internet Routing Table: 340 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 181601920 Equivalent to 10 /8s, 211 /16s and 6 /24s Percentage of available APNIC address space announced: 67.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575 APNIC Address Blocks 58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 86956 Total ARIN prefixes after maximum aggregation: 53107 Prefixes being announced from the ARIN address blocks: 67784 Unique aggregates announced from the ARIN address blocks: 24901 ARIN Region origin ASes present in the Internet Routing Table: 9862 ARIN Region origin ASes announcing only one prefix: 3573 ARIN Region transit ASes present in the Internet Routing Table: 929 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 21 Number of ARIN addresses announced to Internet: 244720640 Equivalent to 14 /8s, 150 /16s and 36 /24s Percentage of available ARIN address space announced: 69.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks 24/8, 63/8, 64/6, 68/7, 70/6, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 30300 Total RIPE prefixes after maximum aggregation: 20946 Prefixes being announced from the RIPE address blocks: 27340 Unique aggregates announced from the RIPE address blocks: 18226 RIPE Region origin ASes present in the Internet Routing Table: 6543 RIPE Region origin ASes announcing only one prefix: 3457 RIPE Region transit ASes present in the Internet Routing Table: 1092 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 201347264 Equivalent to 12 /8s, 0 /16s and 80 /24s Percentage of available RIPE address space announced: 70.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839 RIPE Address Blocks 62/8, 80/5, 88/8, 188/8, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 8565 Total LACNIC prefixes after maximum aggregation: 2979 Prefixes being announced from the LACNIC address blocks: 6989 Unique aggregates announced from the LACNIC address blocks: 4043 LACNIC Region origin ASes present in the Internet Routing Table: 611 LACNIC Region origin ASes announcing only one prefix: 196 LACNIC Region transit ASes present in the Internet Routing Table: 115 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 18093568 Equivalent to 1 /8s, 20 /16s and 22 /24s Percentage of available LACNIC address space announced: 53.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 200/7 AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 1428 Total AfriNIC prefixes after maximum aggregation: 708 Prefixes being announced from the AfriNIC address blocks: 929 Unique aggregates announced from the AfriNIC address blocks: 738 AfriNIC Region origin ASes present in the Internet Routing Table: 101 AfriNIC Region origin ASes announcing only one prefix: 27 AfriNIC Region transit ASes present in the Internet Routing Table: 14 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 12 Number of AfriNIC addresses announced to Internet: 2205952 Equivalent to 0 /8s, 33 /16s and 169 /24s Percentage of available AfriNIC address space announced: 6.6 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 901 4845 181 CHINANET-BACKBONE 1221 775 1193 552 Telstra Pty Ltd 9583 708 52 46 Sify Limited 4766 586 3415 275 Korea Telecom (KIX) 4755 545 243 112 Videsh Sanchar Nigam Ltd. Aut 7545 484 86 70 TPG Internet Pty Ltd 17676 430 6508 72 Softbank BB Corp. 9443 369 77 75 Primus Telecommunications 9929 358 175 45 China Netcom Corp. 2907 345 1838 319 SINET Japan 17557 336 24 152 Pakistan Telecom 10036 313 28 284 C&M Communication Co. Ltd. 4808 310 251 169 CNCGROUP IP network: China169 7474 296 268 213 SingTel Optus Pty Ltd 4802 279 47 164 Wantree Development 9498 268 82 52 BHARTI BT INTERNET LTD. 2764 260 238 198 AAPT Limited 703 256 279 210 UUNET - Commercial IP service 9800 238 386 69 CHINA UNICOM 17974 238 63 12 PT TELEKOMUNIKASI INDONESIA ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1481 6530 963 AT&T WorldNet Services 174 1143 5589 974 Cogent Communications 721 1117 21747 313 DLA Systems Automation Center 4323 1093 647 220 Time Warner Telecom 701 1011 8282 859 UUNET Technologies, Inc. 1239 915 2877 662 Sprint 6197 892 384 414 BellSouth Network Solutions, 2386 842 532 623 AT&T Data Communications Serv 18566 789 224 7 Covad Communications 209 636 3442 492 Qwest 20115 604 499 313 Charter Communications 3356 588 10854 437 Level 3 Communications, LLC 3561 544 2369 417 Savvis 852 532 1095 394 Telus Advanced Communications 27364 517 43 18 Armstrong Cable Services 3602 507 121 92 Sprint Canada, Inc. 5668 489 115 25 CenturyTel Internet Holdings, 22773 477 1188 21 Cox Communications, Inc. 6198 458 380 215 BellSouth Network Solutions, 6467 438 143 35 E.Spire Communications, Inc. RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 598 2003 489 UUNET - Commercial IP service 3320 303 2993 237 Deutsche Telekom AG 3301 295 1116 285 TeliaNet Sweden 8220 278 472 271 COLT Telecommunications 680 253 2041 238 DFN-IP service G-WiN 3246 232 491 227 Song Networks 8708 227 251 208 Romania Data Systems S.A. 1257 198 695 174 SWIPnet Swedish IP Network 5515 178 778 128 Sonera Solution Autonomous Sy 786 174 1778 174 The JANET IP Service 3269 167 1472 73 TELECOM ITALIA 8866 164 21 12 Bulgarian Telecommunication C 6746 161 47 141 Dynamic Network Technologies, 719 159 340 101 LANLINK autonomous system 3300 149 184 84 AUCS Communications Services 5400 144 281 127 BT Ignite European Backbone 25186 139 137 97 France Telecom Transpac's Tra 6830 138 513 27 UPC Distribution Services 9051 128 8 34 INCONET Autonomous System 2856 127 2305 115 BTnet UK Regional network LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 351 533 145 UniNet S.A. de C.V. 16814 265 16 7 NSS, S.A. 11172 222 99 54 Servicios Alestra S.A de C.V 6147 205 102 20 Telefonica Del Peru 19632 190 14 7 Metropolis Intercom S.A. 7303 157 68 21 Telecom Argentina Stet-France 11664 153 19 23 Keytech SA 6505 131 90 88 Global One Communicaoes Ltda 22047 122 96 6 VTR PUNTO NET S.A. 14117 119 8 4 Telefonica del Sur S.A. 6503 105 146 74 AVANTEL, S.A. 18822 104 7 16 TELEFONICA MANQUEHUE 13999 103 52 9 Mega Cable S.A. de C.V. 11556 99 49 5 Cable-Wireless Panama 19169 95 6 16 Telconet 23216 89 24 23 RAMtelecom Telecomunicaciones 11311 85 8 21 Sinectis S.A. 5639 84 12 9 Telecommunications Services o 10481 82 32 7 Prima S.A. 4270 79 18 9 Red de Interconexion Universi AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 268 635 225 The Internet Solution 5536 118 15 17 Internet Egypt Network 2018 90 295 87 Tertiary Education Network 20928 90 16 2 Noor Advanced Technologies AS 2905 75 267 69 The Internetworking Company o 8452 64 20 5 TEDATA 24835 59 34 6 RAYA Telecom - Egypt 9129 43 3 3 UUNET Kenya 12455 43 7 4 Jambonet Autonomous system 5713 35 141 28 Telkom SA Ltd 6713 35 54 9 Itissalat Al-MAGHRIB 8524 24 1 4 AUCEGYPT Autonomous System 15475 23 84 4 Nile Online 16637 22 10 19 Johnnic e-Ventures 10798 19 1 11 Standard Bank of South Africa 7460 17 3 4 LIA Internet Access 12258 17 3 11 Vodacom Internet Company 15808 16 1 1 Communication Solutions Ltd i 21491 16 1 3 UTL On-line is RF broadband I 15706 15 4 2 Sudatel Internet Exchange Aut Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 0 0 65531 * 4323 1093 873 Time Warner Telecom 721 1117 804 DLA Systems Automation Center 18566 789 782 Covad Communications 4134 901 720 CHINANET-BACKBONE 9583 708 662 Sify Limited 27364 517 499 Armstrong Cable Services 6197 892 478 BellSouth Network Solutions, 5668 489 464 CenturyTel Internet Holdings, 22773 477 456 Cox Communications, Inc. 4755 545 433 Videsh Sanchar Nigam Ltd. Aut 3602 507 415 Sprint Canada, Inc. 7545 484 414 TPG Internet Pty Ltd 6467 438 403 E.Spire Communications, Inc. 17676 430 358 Softbank BB Corp. 6140 399 327 ImpSat 9929 358 313 China Netcom Corp. 4766 586 311 Korea Telecom (KIX) 9443 369 294 Primus Telecommunications 20115 604 291 Charter Communications List of Unregistered ASNs (Global) ---------------------------------- Bad AS Designation Network Transit AS Description 65503 PRIVATE 193.125.183.0/24 3217 SIMBIRSK 30999 UNALLOCATED 196.192.80.0/24 6774 BELGACOM 65004 PRIVATE 200.0.113.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.0.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.1.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.2.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.3.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.4.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.5.0/24 28477 Universidad Autonoma 65004 PRIVATE 200.4.6.0/24 28477 Universidad Autonoma 65444 PRIVATE 212.25.125.0/24 8551 Bezeq International 65529 PRIVATE 216.21.199.0/24 14697 VDot.Net 65529 PRIVATE 216.152.237.0/24 14697 VDot.Net Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 172.32.0.0/24 7011 Citizens Utilities 172.122.28.0/24 210 Utah Education Network 192.43.230.0/24 7575 Australian Academic and Rease 192.44.0.0/24 5501 Fraunhofer Gesellschaft 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.84.205.0/24 719 LANLINK autonomous system 192.119.135.0/24 270 NASA 192.135.50.0/24 7018 AT&T WorldNet Services 192.172.0.0/19 721 DLA Systems Automation Center 192.200.100.0/24 7018 AT&T WorldNet Services Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:3 /10:8 /11:15 /12:67 /13:152 /14:308 /15:578 /16:8351 /17:2518 /18:4313 /19:10199 /20:10936 /21:8802 /22:12150 /23:13219 /24:87403 /25:285 /26:263 /27:139 /28:67 /29:38 /30:63 /31:0 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 773 789 Covad Communications 6197 733 892 BellSouth Network Solutions, 7018 662 1481 AT&T WorldNet Services 2386 597 842 AT&T Data Communications Serv 9583 527 708 Sify Limited 4323 511 1093 Time Warner Telecom 27364 505 517 Armstrong Cable Services 5668 407 489 CenturyTel Internet Holdings, 4766 402 586 Korea Telecom (KIX) 1239 383 915 Sprint 702 365 598 UUNET - Commercial IP service 6198 336 458 BellSouth Network Solutions, 6467 319 438 E.Spire Communications, Inc. 10036 313 313 C&M Communication Co. Ltd. 6517 294 317 Yipes Communications, Inc. 9929 282 358 China Netcom Corp. 7011 280 329 Citizens Utilities 11456 271 318 Carolina Online, Inc. 15270 253 273 PaeTec.net -a division of Pae 174 249 1143 Cogent Communications Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:4 8:11 12:1522 13:1 15:9 16:2 17:3 18:4 20:4 24:814 32:64 33:4 38:106 40:53 44:3 47:2 52:4 55:2 56:3 57:24 58:42 59:24 60:19 61:741 62:581 63:1890 64:2670 65:2079 66:2770 67:536 68:515 69:977 70:89 71:6 72:134 80:534 81:512 82:380 83:234 84:142 85:153 128:140 129:157 130:88 131:281 132:35 133:1 134:149 135:41 136:191 137:66 138:172 139:55 140:191 141:106 142:138 143:130 144:173 145:32 146:280 147:103 148:290 149:169 150:98 151:63 152:107 153:87 154:4 155:143 156:76 157:89 158:162 159:172 160:73 161:60 162:200 163:86 164:205 165:176 166:155 167:232 168:417 169:139 170:309 171:8 172:2 192:5676 193:3149 194:2332 195:1556 196:644 198:3936 199:3276 200:4008 201:114 202:5460 203:6148 204:3818 205:2030 206:2448 207:2748 208:2091 209:3282 210:1694 211:840 212:1185 213:1273 214:270 215:31 216:3582 217:1154 218:187 219:105 220:373 221:190 222:85 End of report

1 0

AUP for NANOG?
by Matthew Black 15 Apr '05

15 Apr '05

Do we have an Acceptable Usage Policy fot this NANOG mailing list? Of late this forum has become a forum for ad hominem rather than a friendly discussion of technical issues. While I may disagree with the opinions of others, I wouldn't resort to name calling or belittling. This reminds me of the way others behaved when I entered the field some 25 years ago. Some people were very helpful and friendly. Others responded very arrogantly with the tone of "how stupid you are for asking that question." If you're so smart, feel free to share your knowledge. It's unnecessary to belittle someone for asking a question or stating an opinion. The motivation behind this post is to serve as a reminder of the purpose of the NANOG forum. Let's return some decorum here. matthew black california state university, long beach

12 12

Re: N+? redundancy
by Michael.Dillon＠radianz.com 15 Apr '05

15 Apr '05

> > And a very few population centers such as New York, > > London, Tokyo, and Cheyenne Mountain should probably > > have more than 5 paths. > > I disagree. They may need that many spare paths beyond what is > required to provide their services, but in my experience pretty much > all infrastructure services are overloaded (or at least heavily > loaded), and even if they have N+M "redundancy", eliminating just one > or two of those "M" links will be enough to overwhelm the others and > take everything down in a complete cascade failure. Now you are talking about path capacity as well as the separacy issue. Let's consider the situation where you are designing a network to serve a city of over 1 million population. According to the rule of thumb, 5 paths are enough. What does this mean in practice? First, it probably means that you need to have 5 PoPs fully meshed within the city, or perhaps a larger number of PoPs in a partial mesh, so that you can get traffic from any point in the city to one of your 5 exits. However, the rule of thumb doesn't talk about this at all. Let's further simplify and consider the city to be a node, with 5 paths radiating out from it. One path could fail and the traffic from that path would have to be distributed to the other 4. As you have pointed out, this doesn't work unless all paths are running at four fifths of a normal load. Presumably, since IP circuits cannot run at 100% capacity, the 5 circuits are at somewhat less than 80%, but for now, let's just assume that they are running at no more than 80%. This is an N+1 scenario where one link can fail and service continues. But if two links fail, then 3 links must carry all the traffic, therefore all links must be at less than 60% of capacity. This would be an N+2 scenario. In the rule of thumb, I didn't really consider what failover scenario was right because it isn't a rule of thumb if it goes into too much detail. But the numbers, 1, 2, 3, 5, were chosen because I think that the sites which close up every evening, can live with N+0, then the others can probably live with N+1 except when you get to population centers above 1 million where connectivity to the rest of the world is important enough to have N+2 overall. In the real world, at the city level, there is more than one company providing the connectivity so it becomes tricky to analyze the true connectivity. Remember, paths are not equal to circuits. Therefore, the aggregate of all circuits from all companies which connect Chicago to St. Louis should count as one path. I'd love to see someone do a serious academic analysis along these lines to see what kind of "rules of thumb" have EMERGED from the past decades of network building and consolidation. It would be interesting if this type of research compared the network's topology to the topology of villages, market towns and cities which is remarkably uniform across continents and civilizations. --Michael Dillon

1 0

RE: MD5 for TCP/BGP Sessions
by Doug Legge 15 Apr '05

15 Apr '05

I would like to take this opportunity to thank everyone at Nanog that has assisted me in the completion of this paper. It's being submitted on Monday and I will be sure to let you know how it goes Once again - THANX Doug MDC Student Kingston University London /UK -----Original Message----- From: Doug Legge Sent: 30 March 2005 16:51 To: 'nanog(a)merit.edu' Subject: MD5 for TCP/BGP Sessions NANOG, I'm currently writing a paper for submission, as part of a MSc in Data Communications, and would appreciate if anyone could update me as to the implementation of MD5 for TCP authentication in BGP. Following the alerts last year: http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml http://www.us-cert.gov/cas/techalerts/TA04-111A.html http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7 d9.shtml http://www.foundrynet.com/solutions/security/TCP_Vulnerability_v1_3.pdf http://www.kb.cert.org/vuls/id/415294 http://isc.sans.org/diary.php?date=2004-04-20 What has been the general effect in the ISP/Enterprise community following the warnings? - Have people applied MD5? - If not what other technologies were implemented (IPSec AH transport mode for BGP sessions/ACL/rate limiting etc)? - Has there been any performance impacts seen since implementation? - Has the support of the BGP environment been increased because of this implementation (What policies regards changing the MD5 keys were implemented)? - Was this seen as a valid fix or a knee-jerk reaction (Having re-read the exchanges on NANOG regards the actual mathematical probability of generating this attack, what did the ISP community actually do (compared to what the academic/vendor community were suggesting)? Whilst I've had some response from bgp-info and bgp-security, it's not really been sufficient to draw any real conclusions. From your knowledge and experience are you aware, either internally or with customers the take up of MD5 implementations and had anyone actually suffered an attack prior to implementation -------------------------------- Please do not supply confidential information or anything that would be commercially sensitive, if you want to contact me off-line or from a private account please do Yours Doug Legge MDC Student Kingston University London /UK

1 0

Postini Problems?
by Lanny Jason Godsey 15 Apr '05

15 Apr '05

I'm not able to reach Postini.com. Is anyone else having problems reaching them? Thanks! Lanny Godsey

3 2

Re: Six PCs caused BigPond problems
by Fergie (Paul Ferguson) 15 Apr '05

15 Apr '05

...which reminds me of the Spoofer Project: The Spoofer Project: State of IP Spoofing http://momo.lcs.mit.edu/spoofer/summary.php - ferg -- Bill Stewart <nonobvious(a)gmail.com> wrote: That's ok. At least six more Telstra PCs will get compromised tomorrow. I don't know if they're doing uRPF etc. to stop address spoofing, or blocking RFC1918, but if not, that may help keep the load down. I'm not a fan of using anycast as opposed to building scalable distributed configurations of DNS servers and coordinating them with the DHCP settings that tell customers what server to use, (and monitoring them to make sure they keep working :-), but it can be good for isolating some problems like this. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://spaces.msn.com/members/fergdawg/

1 0

RE: Anyone familiar with the SBC product lingo?
by Hannigan, Martin 15 Apr '05

15 Apr '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Michael.Dillon(a)radianz.com > Sent: Friday, April 15, 2005 6:34 AM > To: nanog(a)merit.edu > Subject: Re: Anyone familiar with the SBC product lingo? > > > > > you'll never get better redundancy than having more than > one carrier. > > On the contrary, you get better redundancy by sticking to > one carrier and making sure that they really provide > separacy though the entire span of the circuit. If you > have two carriers running fibre to yoiur building down > the same conduit, then you do NOT have separacy and as > a result, the redundancy is not there. Which is the case in about 99% of the commercial buildings providers serve. Unless you're designed as a carrier hotel or a colo (even some colos aren't diverse entrance facility), this is the de-facto standard. The reason why is carriers et. al. must pay for conduit access to a building and it impacts pricing, especially if you're not servicing a huge load of service to the building. From the entrace facilities, carriers typically also pay riser conduit fees. Service delivery inside of the prem is insidiously complicated unless you understand a little RE and how OSP is linked to the ISP (in side plant). > > Of course, you can get separacy with two carriers but > it is generally more work to verify that the two companies > do not share fibre or conduit or tunnels. Im a metro loop, they are almost certainly going to share the same path. It is less certain that they will share a conduit. This is standard if you have the route diversity, which is why you want the provider diversity to make it all work. Hope that helps. -M<

2 1