From tbt at ycrdi.com Thu May 1 08:14:05 2008 From: tbt at ycrdi.com (Tim Thompson) Date: Thu, 01 May 2008 09:14:05 -0400 Subject: [NANOG] Comcast latency Message-ID: <4819C21D.2030100@ycrdi.com> On Tue, 29 Apr 2008 23:43:46 -0500 mack wrote: > Has anyone else noticed a significant increase in latency within > Comcast's network? Here, in New England, I normally see 20% packet loss between Comcast and Level3 in NewYork using MTR. It has been as high as 60% in the past so this is an improvement. -Tim Thompson From jmkeller at houseofzen.org Thu May 1 09:25:11 2008 From: jmkeller at houseofzen.org (James Michael Keller) Date: Thu, 01 May 2008 10:25:11 -0400 Subject: [NANOG] Comcast latency In-Reply-To: <4819C21D.2030100@ycrdi.com> References: <4819C21D.2030100@ycrdi.com> Message-ID: <4819D2C7.90104@houseofzen.org> Tim Thompson wrote: > On Tue, 29 Apr 2008 23:43:46 -0500 mack wrote: > >> Has anyone else noticed a significant increase in latency within >> Comcast's network? >> > > Here, in New England, I normally see 20% packet loss between Comcast and Level3 in NewYork using MTR. It has been as high as 60% in the past so this is an improvement. > > -Tim Thompson > Remember that a number of ISP's 'core' routers are going to have ICMP rate limits in place when one of their interfaces is the target. While you may see high packet loss across an ISP link, unless you are getting similar numbers from all hops past that point you aren't looking at real packet loss, since the transit packets are getting through fine. It's just the routers themselves that are ignoring requests or discarding responses in favor of pushing routed packets. -- James Michael Keller From graeme at graemef.net Thu May 1 09:46:32 2008 From: graeme at graemef.net (Graeme Fowler) Date: Thu, 01 May 2008 15:46:32 +0100 Subject: [NANOG] attempt to capture nominet board In-Reply-To: <4810615F.604@psg.com> References: <4810615F.604@psg.com> Message-ID: <1209653192.19470.2.camel@squonk.lboro.ac.uk> On Thu, 2008-04-24 at 19:30 +0900, Randy Bush wrote: > if you are a nomintet voting member or know someone who is, i strongly > encourage you to read these two documents, Results are that of the two new board members, one was a candidate campaigning for change within the organisation (Randy used other terminology), and the specific special resolution put forward by the board in order to allow themselves to strengthen the board with non-exec directors was not passed. The fact that only 15% of the registered members voted (carrying 60% of the votes) is perhaps the single most sobering point. Graeme From mike at reachme.com Thu May 1 16:32:07 2008 From: mike at reachme.com (Mike Fedyk) Date: Thu, 1 May 2008 14:32:07 -0700 Subject: [NANOG] Comcast latency In-Reply-To: <20080430233148.GA15655@jeeves.rigozsaurus.com> Message-ID: <025901c8abd2$ceb74be0$cb998647@ws20031> > -----Original Message----- > From: John Osmon [mailto:josmon at rigozsaurus.com] > Another time, I had a VOIP conversation fall apart once with > somone on a > Comcast link. When the jitter finally fell into a reasonable > range, the call sounded *great* again -- but there was a 4 > second latency that had been introduced. It was wild. I > kept wondering -- "where was this buffered? Are we on a > satellite backup route?" We kept the conversation going for > a while just for the > sheer novelty. The delay was probably introduced by an adaptive jitter buffer on one of the VoIP end points. It is supposed to reduce the buffer as network conditions improve. When it "fell apart" the buffer was increased until it was long enough to reorder all of the packets. It would be interesting to see if a call between those same end points would reduce the size of their buffers after the network stabalized again. Mike From cidr-report at potaroo.net Fri May 2 07:00:06 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 May 2008 22:00:06 +1000 (EST) Subject: [NANOG] BGP Update Report Message-ID: <200805021200.m42C06GE053120@wattle.apnic.net> BGP Update Report Interval: 31-Mar-08 -to- 01-May-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 106482 1.2% 89.0 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - AS9583 92405 1.1% 77.8 -- SIFY-AS-IN Sify Limited 3 - AS4755 57628 0.7% 35.1 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 4 - AS10796 53548 0.6% 91.2 -- SCRR-10796 - Road Runner HoldCo LLC 5 - AS24731 53514 0.6% 644.7 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 6 - AS8151 52039 0.6% 31.5 -- Uninet S.A. de C.V. 7 - AS26829 46463 0.5% 46463.0 -- YKK-USA - YKK USA,INC 8 - AS2386 46155 0.5% 31.8 -- INS-AS - AT&T Data Communications Services 9 - AS8866 45583 0.5% 153.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - AS17974 42705 0.5% 93.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS6140 41877 0.5% 57.6 -- IMPSAT-USA - ImpSat USA, Inc. 12 - AS11060 40872 0.5% 319.3 -- NEO-RR-COM - Road Runner HoldCo LLC 13 - AS9198 38779 0.5% 83.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 14 - AS29571 37149 0.4% 302.0 -- CITelecom-AS 15 - AS7018 35929 0.4% 23.8 -- ATT-INTERNET4 - AT&T WorldNet Services 16 - AS17488 35738 0.4% 31.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 17 - AS7738 35562 0.4% 122.2 -- Telecomunicacoes da Bahia S.A. 18 - AS6389 32771 0.4% 22.8 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 19 - AS11492 32340 0.4% 26.4 -- CABLEONE - CABLE ONE 20 - AS6517 32322 0.4% 49.7 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26829 46463 0.5% 46463.0 -- YKK-USA - YKK USA,INC 2 - AS19334 15144 0.2% 15144.0 -- SPORTLINE-DBC - SPORTLINE 3 - AS19017 13414 0.1% 13414.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 4 - AS17487 13231 0.1% 13231.0 -- ICBCASIA-AP Industrial and Commercial Bank 5 - AS42787 26058 0.3% 8686.0 -- MMIP-AS MultiMedia IP Ltd. 6 - AS30929 7979 0.1% 7979.0 -- HUTCB Hidrotechnical Faculty - Technical University 7 - AS42923 5856 0.1% 5856.0 -- PLK-AS PLK AS Number 8 - AS23082 18730 0.2% 3746.0 -- MPHI - Michigan Public Health Institute 9 - AS18131 5372 0.1% 2686.0 -- IR3 NTT Communications Corporation 10 - AS11278 4674 0.1% 2337.0 -- NINTENDO - Nintendo Of America inc. 11 - AS28282 2146 0.0% 2146.0 -- DW7 CENTRO DE DADOS LTDA 12 - AS28646 2027 0.0% 2027.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 13 - AS36975 1861 0.0% 1861.0 -- CBA-AS 14 - AS44656 1761 0.0% 1761.0 -- HOLOSFIND-ROMANIA HOLOSFIND SRL 15 - AS34378 1669 0.0% 1669.0 -- RUG-AS Razgulay Group 16 - AS7257 3243 0.0% 1621.5 -- PREMIERE-GLOBAL-SERVICES-INC - Premiere Global Services, Inc. 17 - AS25799 1570 0.0% 1570.0 -- HOLMAN - Holman Enterprises 18 - AS29225 1529 0.0% 1529.0 -- TAIF-TELCOM-AS JSC TAIF-TELCOM 19 - AS20551 2899 0.0% 1449.5 -- TEIPAT Autonomous System 20 - AS23917 1382 0.0% 1382.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 125.23.208.0/20 62993 0.7% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 12.108.254.0/24 46463 0.5% AS26829 -- YKK-USA - YKK USA,INC 3 - 213.91.175.0/24 35480 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - 221.135.80.0/24 33089 0.4% AS9583 -- SIFY-AS-IN Sify Limited 5 - 193.33.184.0/23 25984 0.3% AS42787 -- MMIP-AS MultiMedia IP Ltd. 6 - 84.23.100.0/24 23982 0.3% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 7 - 221.128.192.0/18 19793 0.2% AS18231 -- EXATT-AS-AP Exatt Technologies Private Ltd. 8 - 118.95.56.0/24 15346 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 63.169.11.0/24 15144 0.2% AS19334 -- SPORTLINE-DBC - SPORTLINE 10 - 84.23.96.0/19 14565 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 11 - 63.82.84.0/24 13414 0.1% AS19017 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 12 - 220.241.83.0/24 13231 0.1% AS17487 -- ICBCASIA-AP Industrial and Commercial Bank 13 - 124.7.192.0/24 10989 0.1% AS9583 -- SIFY-AS-IN Sify Limited 14 - 203.63.26.0/24 10872 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 15 - 81.180.108.0/24 7979 0.1% AS30929 -- HUTCB Hidrotechnical Faculty - Technical University 16 - 217.22.170.0/23 7765 0.1% AS16094 -- RAS Roilcom ASN (Russia) 17 - 89.4.129.0/24 7228 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 18 - 194.8.90.0/23 6829 0.1% AS3356 -- LEVEL3 Level 3 Communications AS8220 -- COLT COLT Telecommunications 19 - 64.79.128.0/19 6315 0.1% AS23005 -- SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 20 - 208.83.117.0/24 6226 0.1% AS23082 -- MPHI - Michigan Public Health Institute Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 2 07:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 May 2008 22:00:01 +1000 (EST) Subject: [NANOG] The Cidr Report Message-ID: <200805021200.m42C01fB053104@wattle.apnic.net> This report has been generated at Fri May 2 21:17:16 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-04-08 258634 164425 26-04-08 257966 165095 27-04-08 258636 165291 28-04-08 258742 165438 29-04-08 258965 165779 30-04-08 259144 164296 01-05-08 256279 162708 02-05-08 259047 162914 AS Summary 28209 Number of ASes in routing system 11905 Number of ASes announcing only one prefix 1640 Largest number of prefixes announced by an AS AS4755 : VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 88364800 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 02May08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 259448 162954 96494 37.2% All ASes AS4755 1640 200 1440 87.8% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS6389 1451 193 1258 86.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS9498 1166 67 1099 94.3% BBIL-AP BHARTI BT INTERNET LTD. AS18566 1043 99 944 90.5% COVAD - Covad Communications Co. AS22773 948 64 884 93.2% CCINET-2 - Cox Communications Inc. AS4323 1421 675 746 52.5% TWTC - Time Warner Telecom, Inc. AS11492 1211 475 736 60.8% CABLEONE - CABLE ONE AS19262 902 166 736 81.6% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8151 1199 487 712 59.4% Uninet S.A. de C.V. AS1785 1013 317 696 68.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1061 381 680 64.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18101 680 114 566 83.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 935 389 546 58.4% ATT-INTERNET3 - AT&T WorldNet Services AS2386 1398 876 522 37.3% INS-AS - AT&T Data Communications Services AS4766 851 362 489 57.5% KIXS-AS-KR Korea Telecom AS4134 855 367 488 57.1% CHINANET-BACKBONE No.31,Jin-rong Street AS6197 988 509 479 48.5% BATI-ATL - BellSouth Network Solutions, Inc AS7011 1097 625 472 43.0% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS19916 555 99 456 82.2% ASTRUM-0001 - OLM LLC AS22047 564 126 438 77.7% VTR BANDA ANCHA S.A. AS855 578 151 427 73.9% CANET-ASN-4 - Bell Aliant AS8103 569 155 414 72.8% STATE-OF-FLA - Florida Department of Management Services - Technology Program AS7018 1424 1017 407 28.6% ATT-INTERNET4 - AT&T WorldNet Services AS6140 614 210 404 65.8% IMPSAT-USA - ImpSat USA, Inc. AS4812 490 87 403 82.2% CHINANET-SH-AP China Telecom (Group) AS17676 508 106 402 79.1% GIGAINFRA BB TECHNOLOGY Corp. AS5668 684 291 393 57.5% AS-5668 - CenturyTel Internet Holdings, Inc. AS9443 463 84 379 81.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS3602 454 79 375 82.6% AS3602-RTI - Rogers Telecom Inc. AS4808 515 141 374 72.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network Total 27277 8912 18365 67.3% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.58.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.169.0.0/17 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 70.32.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service 192.131.233.0/24 AS7891 BELLSOUTH-NET-BLK2 - Bellsouth.Net 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.45.132.0/22 AS24314 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.2.128.0/17 AS17175 NSS-UK New Skies Satellites UK AS 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS7893 BELLSOUTH-NET-BLK2 - Bellsouth.Net 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS7893 BELLSOUTH-NET-BLK2 - Bellsouth.Net 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.192.0/19 AS11881 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 208.90.32.0/21 AS40193 AS-TRIT - Trit Networks 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.119.128.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.119.131.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.119.141.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From tbt at ycrdi.com Fri May 2 07:53:29 2008 From: tbt at ycrdi.com (Tim Thompson) Date: Fri, 02 May 2008 08:53:29 -0400 Subject: [NANOG] Comcast latency Message-ID: <481B0EC9.7090900@ycrdi.com> > Tim Thompson wrote: >> Here, in New England, I normally see 20% packet loss between Comcast >> and Level3 in NewYork using MTR. It has been as high as 60% in the >> past so this is an improvement. >> James Michael Keller wrote: > Remember that a number of ISP's 'core' routers are going to have ICMP > rate limits in place when one of their interfaces is the target. While > you may see high packet loss across an ISP link, unless you are getting > similar numbers from all hops past that point you aren't looking at real > packet loss, since the transit packets are getting through fine. It's > just the routers themselves that are ignoring requests or discarding > responses in favor of pushing routed packets. Yes, the routers after Level3's edge router don't show similar packet loss, so this must be the edge router just de-prioritizing ICMP. Thank you for pointing out my mistake. -Tim From Brian.Knoll at tradingtechnologies.com Fri May 2 09:46:45 2008 From: Brian.Knoll at tradingtechnologies.com (Brian Knoll (TT)) Date: Fri, 2 May 2008 09:46:45 -0500 Subject: [NANOG] Hurrican Electric Message-ID: Is there an engineer at Hurrican Electric that could contact me off list? It looks like you may have a static route to my network that you are advertising out via AS 6939. It's preventing several customers from connecting to us. Our network is 12.41.48.0 /24 AS 21734 Brian 312-698-6017 From marc at let.de Fri May 2 11:30:34 2008 From: marc at let.de (Marc Manthey) Date: Fri, 2 May 2008 18:30:34 +0200 Subject: [NANOG] nanog list is now archived in MarkMail In-Reply-To: <1209528825.14102.34.camel@waf.brunz.org> References: <1209528825.14102.34.camel@waf.brunz.org> Message-ID: <3B411BC8-9C5B-4298-B357-AEC9D19FE076@let.de> > The company I work for, MarkLogic, sells a server that combines XML > database, search engine, and app server capabilities in a single > platform. As a demonstration of what can be done with our server, some > of our people have created MarkMail (http://www.markmail.org/) to > archive public mailing lists. So far, over 2000 lists containing over > 11M emails have been loaded. > > > http://nanog.markmail.org/ really great wayne and impressive statistics. keep the good work. regards Marc > > Enjoy. > > Wayne. From mleber at he.net Fri May 2 11:32:44 2008 From: mleber at he.net (Mike Leber) Date: Fri, 2 May 2008 09:32:44 -0700 (PDT) Subject: [NANOG] Hurrican Electric In-Reply-To: Message-ID: On Fri, 2 May 2008, Brian Knoll (TT) wrote: > Is there an engineer at Hurrican Electric that could contact me off > list? It looks like you may have a static route to my network that you > are advertising out via AS 6939. It's preventing several customers from > connecting to us. > > Our network is 12.41.48.0 /24 AS 21734 Hi, I've confirmed we don't have a static route. Here is a traceroute to that: telnet at core1.pao1.he.net>traceroute 12.41.48.1 Type Control-c to abort Tracing the route to IP node 12.41.48.1 from 1 to 30 hops 1 <1 ms <1 ms <1 ms sjo-bb1-link.telia.net [213.248.86.53] 2 47 ms 47 ms 47 ms chi-bb1-pos6-1-0-0.telia.net [213.248.80.25] 3 47 ms 47 ms 47 ms 192.205.34.197 4 53 ms 51 ms 51 ms tbr1.cgcil.ip.att.net [12.123.4.246] 5 48 ms 48 ms 59 ms gar1.chail.ip.att.net [12.123.4.69] 6 * * !H 12.119.137.54 telnet at core1.pao1.he.net> In the future, please email noc at he.net, we will be happy to help you. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric Web Hosting Colocation AS6939 | | mleber at he.net http://he.net | +-----------------------------------------------------------------------+ From Brian.Knoll at tradingtechnologies.com Fri May 2 12:31:51 2008 From: Brian.Knoll at tradingtechnologies.com (Brian Knoll (TT)) Date: Fri, 2 May 2008 12:31:51 -0500 Subject: [NANOG] Hurrican Electric In-Reply-To: References: Message-ID: Mike, I was able to get someone else from Hurricane on and they resolved the issue quickly. Thanks for the response. Brian -----Original Message----- From: Mike Leber [mailto:mleber at he.net] Sent: Friday, May 02, 2008 11:33 AM To: Brian Knoll (TT) Cc: nanog at merit.edu Subject: Re: [NANOG] Hurrican Electric On Fri, 2 May 2008, Brian Knoll (TT) wrote: > Is there an engineer at Hurrican Electric that could contact me off > list? It looks like you may have a static route to my network that you > are advertising out via AS 6939. It's preventing several customers from > connecting to us. > > Our network is 12.41.48.0 /24 AS 21734 Hi, I've confirmed we don't have a static route. Here is a traceroute to that: telnet at core1.pao1.he.net>traceroute 12.41.48.1 Type Control-c to abort Tracing the route to IP node 12.41.48.1 from 1 to 30 hops 1 <1 ms <1 ms <1 ms sjo-bb1-link.telia.net [213.248.86.53] 2 47 ms 47 ms 47 ms chi-bb1-pos6-1-0-0.telia.net [213.248.80.25] 3 47 ms 47 ms 47 ms 192.205.34.197 4 53 ms 51 ms 51 ms tbr1.cgcil.ip.att.net [12.123.4.246] 5 48 ms 48 ms 59 ms gar1.chail.ip.att.net [12.123.4.69] 6 * * !H 12.119.137.54 telnet at core1.pao1.he.net> In the future, please email noc at he.net, we will be happy to help you. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric Web Hosting Colocation AS6939 | | mleber at he.net http://he.net | +----------------------------------------------------------------------- + From cscora at apnic.net Fri May 2 13:06:35 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 May 2008 04:06:35 +1000 (EST) Subject: [NANOG] Weekly Routing Table Report Message-ID: <200805021806.m42I6ZLA011054@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 May, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 254787 Prefixes after maximum aggregation: 127004 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 123511 Total ASes present in the Internet Routing Table: 28069 Prefixes per ASN: 9.08 Origin-only ASes present in the Internet Routing Table: 24458 Origin ASes announcing only one prefix: 11398 Transit ASes present in the Internet Routing Table: 3611 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 19 Max AS path prepend of ASN (44859) 15 Prefixes from unregistered ASNs in the Routing Table: 25380 Unregistered ASNs in the Routing Table: 1890 Number of 32-bit ASNs allocated by the RIRs: 46 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 790 Number of addresses announced to Internet: 1865259040 Equivalent to 111 /8s, 45 /16s and 152 /24s Percentage of available address space announced: 50.3 Percentage of allocated address space announced: 61.8 Percentage of available address space allocated: 81.4 Percentage of address space in use by end-sites: 71.7 Total number of prefixes smaller than registry allocations: 122514 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 43073 Total APNIC prefixes after maximum aggregation: 13461 APNIC Deaggregation factor: 3.20 Prefixes being announced from the APNIC address blocks: 55456 Unique aggregates announced from the APNIC address blocks: 23561 APNIC Region origin ASes present in the Internet Routing Table: 1934 APNIC Prefixes per ASN: 28.67 APNIC Region origin ASes announcing only one prefix: 553 APNIC Region transit ASes present in the Internet Routing Table: 350 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 346760800 Equivalent to 20 /8s, 171 /16s and 38 /24s Percentage of available APNIC address space announced: 79.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 107789 Total ARIN prefixes after maximum aggregation: 59234 ARIN Deaggregation factor: 1.82 Prefixes being announced from the ARIN address blocks: 86721 Unique aggregates announced from the ARIN address blocks: 34340 ARIN Region origin ASes present in the Internet Routing Table: 11784 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4611 ARIN Region transit ASes present in the Internet Routing Table: 1044 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 358349568 Equivalent to 21 /8s, 91 /16s and 251 /24s Percentage of available ARIN address space announced: 73.7 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, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 54894 Total RIPE prefixes after maximum aggregation: 33555 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 50101 Unique aggregates announced from the RIPE address blocks: 33548 RIPE Region origin ASes present in the Internet Routing Table: 11253 RIPE Prefixes per ASN: 4.45 RIPE Region origin ASes announcing only one prefix: 5880 RIPE Region transit ASes present in the Internet Routing Table: 1720 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 355464448 Equivalent to 21 /8s, 47 /16s and 245 /24s Percentage of available RIPE address space announced: 81.5 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, 38912-39935 40960-45055, 47104 - 48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 19830 Total LACNIC prefixes after maximum aggregation: 4971 LACNIC Deaggregation factor: 3.99 Prefixes being announced from the LACNIC address blocks: 18261 Unique aggregates announced from the LACNIC address blocks: 9839 LACNIC Region origin ASes present in the Internet Routing Table: 893 LACNIC Prefixes per ASN: 20.45 LACNIC Region origin ASes announcing only one prefix: 277 LACNIC Region transit ASes present in the Internet Routing Table: 154 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 50827264 Equivalent to 3 /8s, 7 /16s and 144 /24s Percentage of available LACNIC address space announced: 50.5 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3820 Total AfriNIC prefixes after maximum aggregation: 1216 AfriNIC Deaggregation factor: 3.14 Prefixes being announced from the AfriNIC address blocks: 4152 Unique aggregates announced from the AfriNIC address blocks: 1842 AfriNIC Region origin ASes present in the Internet Routing Table: 241 AfriNIC Prefixes per ASN: 17.23 AfriNIC Region origin ASes announcing only one prefix: 77 AfriNIC Region transit ASes present in the Internet Routing Table: 48 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 11770624 Equivalent to 0 /8s, 179 /16s and 155 /24s Percentage of available AfriNIC address space announced: 35.1 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 4755 1640 387 90 Videsh Sanchar Nigam Ltd. Aut 9583 1174 140 16 Sify Limited 9498 1165 550 61 BHARTI BT INTERNET LTD. 17488 1060 70 75 Hathway IP Over Cable Interne 4134 855 12615 319 CHINANET-BACKBONE 4766 850 6006 345 Korea Telecom (KIX) 18101 680 149 54 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 544 1918 418 Telstra Pty Ltd 4808 515 829 129 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4323 1425 1014 376 Time Warner Telecom 7018 1403 5977 1000 AT&T WorldNet Services 2386 1396 642 862 AT&T Data Communications Serv 11492 1211 146 36 Cable One 7011 1098 319 626 Citizens Utilities 18566 1043 296 10 Covad Communications 1785 1014 511 106 AppliedTheory Corporation 6197 987 598 508 BellSouth Network Solutions, 174 971 6835 802 Cogent Communications 22773 948 2394 62 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 407 1788 367 TDC Tele Danmark 9198 401 74 9 Kazakhtelecom Data Network Ad 8452 356 188 7 TEDATA 3301 338 1458 306 TeliaNet Sweden 3320 324 7044 267 Deutsche Telekom AG 8866 298 78 24 Bulgarian Telecommunication C 5462 292 666 26 Telewest Broadband 8551 282 269 37 Bezeq International 3215 277 2678 89 France Telecom Transpac 680 272 2047 262 DFN-IP service G-WiN Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1201 2432 223 UniNet S.A. de C.V. 11830 601 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 455 222 60 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 416 85 46 ENTEL CHILE S.A. 11172 415 117 69 Servicios Alestra S.A de C.V 10620 388 99 76 TVCABLE BOGOTA 14117 384 25 15 Telefonica del Sur S.A. 20299 341 36 31 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 464 61 27 LINKdotNET AS number 3741 289 853 223 The Internet Solution 20858 218 34 3 EgyNet 2018 179 190 86 Tertiary Education Network 5713 150 558 120 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 116 13 8 Ci Telecom Autonomous system 33776 99 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2900 3021 117 bellsouth.net, inc. 23577 1642 34 701 Korea Telecom (ATM-MPLS) 4755 1640 387 90 Videsh Sanchar Nigam Ltd. Aut 4323 1425 1014 376 Time Warner Telecom 7018 1403 5977 1000 AT&T WorldNet Services 2386 1396 642 862 AT&T Data Communications Serv 11492 1211 146 36 Cable One 8151 1201 2432 223 UniNet S.A. de C.V. 9583 1174 140 16 Sify Limited 9498 1165 550 61 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4755 1640 1550 Videsh Sanchar Nigam Ltd. Aut 11492 1211 1175 Cable One 9583 1174 1158 Sify Limited 9498 1165 1104 BHARTI BT INTERNET LTD. 4323 1425 1049 Time Warner Telecom 18566 1043 1033 Covad Communications 17488 1060 985 Hathway IP Over Cable Interne 8151 1201 978 UniNet S.A. de C.V. 17676 1016 951 Softbank BB Corp. 23577 1642 941 Korea Telecom (ATM-MPLS) Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 14780 UNALLOCATED 4.79.181.0/24 10310 Yahoo! 12180 UNALLOCATED 4.79.248.0/24 1239 Sprint 12180 UNALLOCATED 8.10.16.0/24 3549 Global Crossing 12180 UNALLOCATED 8.10.58.0/23 3549 Global Crossing 14779 UNALLOCATED 8.12.144.0/24 10310 Yahoo! 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 1239 Sprint 15132 UNALLOCATED 12.9.150.0/24 701 UUNET Technologies, 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:16 /11:42 /12:139 /13:280 /14:506 /15:1002 /16:9886 /17:4361 /18:7292 /19:15380 /20:17794 /21:17202 /22:21610 /23:22706 /24:134198 /25:783 /26:939 /27:497 /28:108 /29:9 /30:1 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 11492 1197 1211 Cable One 2386 1096 1396 AT&T Data Communications Serv 18566 1024 1043 Covad Communications 9583 1009 1174 Sify Limited 7011 981 1098 Citizens Utilities 4755 975 1640 Videsh Sanchar Nigam Ltd. Aut 6478 934 935 AT&T Worldnet Services 6389 899 2900 bellsouth.net, inc. 17488 872 1060 Hathway IP Over Cable Interne 9498 841 1165 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:106 12:2027 13:1 15:20 16:3 17:5 18:13 20:35 24:1072 25:1 32:61 33:4 38:419 40:94 41:662 44:2 47:8 52:3 55:3 56:3 57:22 58:513 59:460 60:441 61:984 62:1109 63:1962 64:3411 65:2434 66:3629 67:1170 68:674 69:2192 70:599 71:126 72:1675 73:6 74:950 75:228 76:303 77:648 78:605 79:149 80:898 81:856 82:624 83:372 84:545 85:993 86:399 87:655 88:345 89:1278 90:11 91:1213 92:293 93:360 96:25 97:14 98:151 99:3 116:634 117:297 118:124 119:374 120:14 121:525 122:756 123:320 124:853 125:1120 128:292 129:198 130:129 131:405 132:67 133:9 134:179 135:32 136:223 137:112 138:150 139:62 140:485 141:96 142:395 143:285 144:357 145:50 146:358 147:150 148:506 149:183 150:131 151:181 152:141 153:133 154:10 155:269 156:207 157:267 158:168 159:221 160:253 161:111 162:208 163:194 164:582 165:448 166:304 167:320 168:614 169:128 170:422 171:28 172:2 189:164 190:1822 192:5773 193:4097 194:3255 195:2417 196:1057 198:3743 199:3227 200:5651 201:1447 202:7542 203:7829 204:3998 205:2090 206:2394 207:2749 208:3295 209:3444 210:2539 211:1044 212:1369 213:1634 214:445 215:51 216:4337 217:1218 218:347 219:406 220:1069 221:482 222:305 End of report From mleber at he.net Fri May 2 13:51:43 2008 From: mleber at he.net (Mike Leber) Date: Fri, 2 May 2008 11:51:43 -0700 (PDT) Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481B0EC9.7090900@ycrdi.com> Message-ID: Since nobody mentioned it yet, there are now less than 1000 days projected until IPv4 exhaustion: http://www.potaroo.net/tools/ipv4/ Do you have an IPv6 plan? How long do you think it will be until Sarbanes Oxley and SAS 70 auditors start requiring disclosure of IPv4 exhaustion as a business continuity risk, as well as the presence or lack thereof of an IPv6 plan? When do you plan on telling your customers? (afterwards?) Ahhh, you don't have any customers that have to plan to buy equipment 2 years in advance. Ok, I understand. Mike. ps. 1000 days assumes no rush, speculation, or hoarding. Do people do that? pps. Of course these are provocative comments for amusement. :) ppps. Or not if you don't have any kind of IPv6 plan. Sorry, sorry... +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | | Hurricane Electric Web Hosting Colocation AS6939 | | mleber at he.net http://he.net | +-----------------------------------------------------------------------+ From mike.lyon at gmail.com Fri May 2 15:12:52 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 2 May 2008 13:12:52 -0700 Subject: [NANOG] Introducing latency for testing? Message-ID: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> So I want to mimic some latency in a test network for DB replication. I am wondering what other's have used for this? Obviously, the best way to would be to actually have one box across the US or across the globe to actually test against but what if you don't have that? Are there any GPL software router solutions that would allow you to tweak the latency in between the two test boxes? Thanks in advance. -Mike From tate at baumrucker.org Fri May 2 15:17:59 2008 From: tate at baumrucker.org (C. Tate Baumrucker) Date: Fri, 02 May 2008 16:17:59 -0400 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: <481B76F7.4070700@baumrucker.org> setup a linux box between the systems with netem (included in most distros). http://www.linux-foundation.org/en/Net:Netem with it, you can introduce latency, loss, jitter, etc. tate Mike Lyon wrote: > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? > > Thanks in advance. > > -Mike > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From glisk1 at gmail.com Fri May 2 15:22:21 2008 From: glisk1 at gmail.com (Geoff Lisk) Date: Fri, 2 May 2008 16:22:21 -0400 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: NISTnet at http://snad.ncsl.nist.gov/nistnet/ Also, there is a commercial (reasonably priced) product called network nightmare. (http://networknightmare.net/) Cisco also has an .iso that they'll give to customers that's a NISTnet livecd. -Geoff On Fri, May 2, 2008 at 4:12 PM, Mike Lyon wrote: > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? > > Thanks in advance. > > -Mike > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From bortzmeyer at nic.fr Fri May 2 15:26:01 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 2 May 2008 22:26:01 +0200 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: <20080502202601.GA17626@sources.org> On Fri, May 02, 2008 at 01:12:52PM -0700, Mike Lyon wrote a message of 15 lines which said: > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? I use and like FreeBSD's dummynet: http://info.iet.unipi.it/~luigi/ip_dummynet/ Highly recommended. From deepak at ai.net Fri May 2 15:27:05 2008 From: deepak at ai.net (Deepak Jain) Date: Fri, 02 May 2008 16:27:05 -0400 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <481B76F7.4070700@baumrucker.org> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> <481B76F7.4070700@baumrucker.org> Message-ID: <481B7919.5060401@ai.net> Or a FreeBSD box with DUMMYNET (runs through IPFW). You can do all of that stuff. C. Tate Baumrucker wrote: > setup a linux box between the systems with netem (included in most > distros). > http://www.linux-foundation.org/en/Net:Netem > with it, you can introduce latency, loss, jitter, etc. > tate > > > Mike Lyon wrote: >> So I want to mimic some latency in a test network for DB replication. >> I am wondering what other's have used for this? Obviously, the best >> way to would be to actually have one box across the US or across the >> globe to actually test against but what if you don't have that? Are >> there any GPL software router solutions that would allow you to tweak >> the latency in between the two test boxes? >> >> Thanks in advance. >> >> -Mike >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > From mike.lyon at gmail.com Fri May 2 15:28:42 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 2 May 2008 13:28:42 -0700 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <481B7919.5060401@ai.net> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> <481B76F7.4070700@baumrucker.org> <481B7919.5060401@ai.net> Message-ID: <1b5c1c150805021328h241d25b3tb9ab61aec45bf5fb@mail.gmail.com> Thank you all for the wonderful responses! Cheers, Mike On Fri, May 2, 2008 at 1:27 PM, Deepak Jain wrote: > Or a FreeBSD box with DUMMYNET (runs through IPFW). You can do all of that > stuff. > > > > C. Tate Baumrucker wrote: > > > setup a linux box between the systems with netem (included in most > distros). http://www.linux-foundation.org/en/Net:Netem > > with it, you can introduce latency, loss, jitter, etc. > > tate > > > > > > Mike Lyon wrote: > > > > > So I want to mimic some latency in a test network for DB replication. > > > I am wondering what other's have used for this? Obviously, the best > > > way to would be to actually have one box across the US or across the > > > globe to actually test against but what if you don't have that? Are > > > there any GPL software router solutions that would allow you to tweak > > > the latency in between the two test boxes? > > > > > > Thanks in advance. > > > > > > -Mike > > > > > > _______________________________________________ > > > NANOG mailing list > > > NANOG at nanog.org > > > http://mailman.nanog.org/mailman/listinfo/nanog > > > > > > > > > > > > _______________________________________________ > > NANOG mailing list > > NANOG at nanog.org > > http://mailman.nanog.org/mailman/listinfo/nanog > > > > > > > From joelja at bogus.com Fri May 2 15:29:12 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 02 May 2008 13:29:12 -0700 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: <481B7998.9030303@bogus.com> The freebsd dummynet driver is all about latency simulation... http://www.scalabledesign.com/articles/dummynet.html linux has a netem which can do the same thing http://www.linux-foundation.org/en/Net:Netem joelja Mike Lyon wrote: > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? > > Thanks in advance. > > -Mike > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From charles at thewybles.com Fri May 2 16:06:23 2008 From: charles at thewybles.com (charles at thewybles.com) Date: Fri, 2 May 2008 21:06:23 +0000 Subject: [NANOG] Introducing latency for testing? Message-ID: <642750211-1209762399-cardhu_decombobulator_blackberry.rim.net-1889820069-@bxe164.bisx.prod.on.blackberry> Netem is a very cool tool! Thanks for mentioning it. Sent via BlackBerry from T-Mobile From regnauld at catpipe.net Fri May 2 16:17:02 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Fri, 2 May 2008 23:17:02 +0200 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <481B7998.9030303@bogus.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> <481B7998.9030303@bogus.com> Message-ID: <20080502211702.GB748@catpipe.net> Joel Jaeggli (joelja) writes: > The freebsd dummynet driver is all about latency simulation... > > http://www.scalabledesign.com/articles/dummynet.html > > linux has a netem which can do the same thing > > http://www.linux-foundation.org/en/Net:Netem dummynet is significantly easier to set up, especially for doing things like random packet reordering / packet loss (using the 'prob' rule of ipfw + delay property with pipes). ipfw pipe 42 config bw 1024Kbit/s delay 6ms ipfw pipe 666 config bw 64Kbit/s delay 350ms ipfw add 10 prob 0.05 deny ip from 1.2.3.4 to any ipfw add 10 prob 0.8 pipe 666 ip from A to B ipfw add 10 prob 0.5 pipe 42 ip from A to B ... and it runs. From j at arpa.com Fri May 2 16:40:39 2008 From: j at arpa.com (jamie) Date: Fri, 2 May 2008 16:40:39 -0500 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: <481B0EC9.7090900@ycrdi.com> Message-ID: <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> You first, mister chicken-with-his-head-cut-off. What's your plan? On Fri, May 2, 2008 at 1:51 PM, Mike Leber wrote: > > Since nobody mentioned it yet, there are now less than 1000 days projected > until IPv4 exhaustion: > > http://www.potaroo.net/tools/ipv4/ > > Do you have an IPv6 plan? > > How long do you think it will be until Sarbanes Oxley and SAS 70 auditors > start requiring disclosure of IPv4 exhaustion as a business continuity > risk, as well as the presence or lack thereof of an IPv6 plan? > > When do you plan on telling your customers? (afterwards?) > > Ahhh, you don't have any customers that have to plan to buy equipment 2 > years in advance. Ok, I understand. > > Mike. > ps. 1000 days assumes no rush, speculation, or hoarding. Do people do > that? > > pps. Of course these are provocative comments for amusement. :) > > ppps. Or not if you don't have any kind of IPv6 plan. Sorry, sorry... > > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ > | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | > | Hurricane Electric Web Hosting Colocation AS6939 | > | mleber at he.net http://he.net | > +-----------------------------------------------------------------------+ > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Would you like a little bit of legal advice? NEVER let a scientist use the words "unanticipated" and "immediate" in the same sentence. Okay? Okay. From patrick at ianai.net Fri May 2 16:47:44 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 2 May 2008 17:47:44 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> Message-ID: <7915D609-574E-4018-8C2B-375909CCAD54@ianai.net> On May 2, 2008, at 5:40 PM, jamie wrote: > You first, mister chicken-with-his-head-cut-off. > > What's your plan? Mike owns Hurricane Electric. HE.net has the most v6 routes, peering, and pretty much any other metric you can dream up. His .sig says "Wholesale IPv4 and IPv6 Transit". What do you think his plan is? More important question: Perhaps you should spend 15 seconds researching things before you send obviously ignorant comments to 10K of your not-so-close friends? -- TTFN, patrick > On Fri, May 2, 2008 at 1:51 PM, Mike Leber wrote: > >> >> Since nobody mentioned it yet, there are now less than 1000 days >> projected >> until IPv4 exhaustion: >> >> http://www.potaroo.net/tools/ipv4/ >> >> Do you have an IPv6 plan? >> >> How long do you think it will be until Sarbanes Oxley and SAS 70 >> auditors >> start requiring disclosure of IPv4 exhaustion as a business >> continuity >> risk, as well as the presence or lack thereof of an IPv6 plan? >> >> When do you plan on telling your customers? (afterwards?) >> >> Ahhh, you don't have any customers that have to plan to buy >> equipment 2 >> years in advance. Ok, I understand. >> >> Mike. >> ps. 1000 days assumes no rush, speculation, or hoarding. Do people >> do >> that? >> >> pps. Of course these are provocative comments for amusement. :) >> >> ppps. Or not if you don't have any kind of IPv6 plan. Sorry, >> sorry... >> >> +----------------- H U R R I C A N E - E L E C T R I C >> -----------------+ >> | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 >> 4100 | >> | Hurricane Electric Web Hosting Colocation >> AS6939 | >> | mleber at he.net http://he.net >> | >> + >> -----------------------------------------------------------------------+ >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > > > > -- > Would you like a little bit of legal advice? > NEVER let a scientist use the words "unanticipated" and "immediate" > in the > same sentence. > Okay? Okay. > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From sean at labrats.us Fri May 2 16:49:40 2008 From: sean at labrats.us (Sean Figgins) Date: Fri, 02 May 2008 15:49:40 -0600 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> Message-ID: <481B8C74.3080503@labrats.us> > On Fri, May 2, 2008 at 1:51 PM, Mike Leber wrote: > >> Since nobody mentioned it yet, there are now less than 1000 days projected >> until IPv4 exhaustion: No worries, the Internet is going to end in 2010, and the world ends on December 21, 2012. I don't think we'll be needing IPv6 in that case. Has anyone ever figured out how to make multi-homing of customers who only have a /64 assigned to them work? Are the routers on the going to be able to handle the billion routing prefixed that will be introduced? Are there any IP Management software packages that won't bankrupt the world's economy for IPv6 charges? Maybe the world really will end, and it's all due to IPv6! -Sean From deepak at ai.net Fri May 2 16:53:15 2008 From: deepak at ai.net (Deepak Jain) Date: Fri, 02 May 2008 17:53:15 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: Message-ID: <481B8D4B.3080304@ai.net> > > ppps. Or not if you don't have any kind of IPv6 plan. Sorry, sorry... > Does it take most network operators more than 1000 days to make an IPv6 plan and start implementing it? I suppose there is always some network running obsolete gear out somewhere, but their upstream guy may provide them something to avoid the pain (like reclaimed v4 space) or a gateway or other service. I guess another way to say it is... if you can afford for the planning and implementation to have so many layers of sign-off and buy-in it takes years, you can afford the costs, in everything else, to implement it. Not to mention, piggyback off of all the published BCPs, improved tools and software, and other things that 2 more years will provide. Deepak Jain AiNET From copraphage at gmail.com Fri May 2 16:55:48 2008 From: copraphage at gmail.com (Chris McDonald) Date: Fri, 2 May 2008 17:55:48 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> Message-ID: <25dbbe250805021455q1383e344nbc83186018c49d@mail.gmail.com> Mike and HE are all over that ipv6 On 5/2/08, jamie wrote: > You first, mister chicken-with-his-head-cut-off. > > What's your plan? > > On Fri, May 2, 2008 at 1:51 PM, Mike Leber wrote: > > > > > Since nobody mentioned it yet, there are now less than 1000 days projected > > until IPv4 exhaustion: > > > > http://www.potaroo.net/tools/ipv4/ > > > > Do you have an IPv6 plan? > > > > How long do you think it will be until Sarbanes Oxley and SAS 70 auditors > > start requiring disclosure of IPv4 exhaustion as a business continuity > > risk, as well as the presence or lack thereof of an IPv6 plan? > > > > When do you plan on telling your customers? (afterwards?) > > > > Ahhh, you don't have any customers that have to plan to buy equipment 2 > > years in advance. Ok, I understand. > > > > Mike. > > ps. 1000 days assumes no rush, speculation, or hoarding. Do people do > > that? > > > > pps. Of course these are provocative comments for amusement. :) > > > > ppps. Or not if you don't have any kind of IPv6 plan. Sorry, sorry... > > > > +----------------- H U R R I C A N E - E L E C T R I C -----------------+ > > | Mike Leber Wholesale IPv4 and IPv6 Transit 510 580 4100 | > > | Hurricane Electric Web Hosting Colocation AS6939 | > > | mleber at he.net http://he.net | > > +-----------------------------------------------------------------------+ > > > > > > _______________________________________________ > > NANOG mailing list > > NANOG at nanog.org > > http://mailman.nanog.org/mailman/listinfo/nanog > > > > > > -- > Would you like a little bit of legal advice? > NEVER let a scientist use the words "unanticipated" and "immediate" in the > same sentence. > Okay? Okay. > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Sent from Gmail for mobile | mobile.google.com From drc at virtualized.org Fri May 2 16:57:36 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 2 May 2008 14:57:36 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481B8C74.3080503@labrats.us> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> <481B8C74.3080503@labrats.us> Message-ID: <3EC47FE7-94A8-4015-A9C7-709354D66169@virtualized.org> > Has anyone ever figured out how to make multi-homing of customers who > only have a /64 assigned to them work? Same way you make multi-homing of customers who only have a IPv4 /32 assigned to them work, i.e., not well. > Maybe the world really will end, and it's all due to IPv6! Internet doomed, MPEG stalled at 11:00... :-) Regards, -drc From marc at let.de Fri May 2 17:01:33 2008 From: marc at let.de (Marc Manthey) Date: Sat, 3 May 2008 00:01:33 +0200 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> Message-ID: <9AEEF477-9768-4825-9E7D-ABD4C2BF218E@let.de> > What's your plan? some of the prefered ip4 strategies could be exclusive ipsex ;) http://www.ipv6porn.com/ or : http://www.bieringer.de/pb/lectures/PB-IPv6-SUCON-2004.pdf regards Marc P.S. > 10K > of your not-so-close friends? does this mean this list has 10.000 subscribers ? -- How do I quote correctly http://www.netmeister.org/news/learn2quote.html > On Fri, May 2, 2008 at 1:51 PM, Mike Leber wrote: >> pps. Of course these are provocative comments for amusement. :) -- "Use your imagination not to scare yourself to death but to inspire yourself to life." Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 K?ln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc at kgraff.net blog : http://www.let.de ipv6 http://www.ipsix.org xing : https://www.xing.com/profile/Marc_Manthey From joelja at bogus.com Fri May 2 17:08:22 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 02 May 2008 15:08:22 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481B8C74.3080503@labrats.us> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> <481B8C74.3080503@labrats.us> Message-ID: <481B90D6.4080607@bogus.com> Sean Figgins wrote: >> On Fri, May 2, 2008 at 1:51 PM, Mike Leber wrote: >> >>> Since nobody mentioned it yet, there are now less than 1000 days projected >>> until IPv4 exhaustion: > > No worries, the Internet is going to end in 2010, and the world ends on > December 21, 2012. I don't think we'll be needing IPv6 in that case. > > Has anyone ever figured out how to make multi-homing of customers who > only have a /64 assigned to them work? how are your /32 v4 announcements working out? longest prefix I carry in my v6 table are a /48s... There are only 28224 ASes in announced in the v4 routing system how many non-agregatable announcements will they represent if they all participate in v6 tomorrow? > Are the routers on the going to > be able to handle the billion routing prefixed that will be introduced? > Are there any IP Management software packages that won't bankrupt the > world's economy for IPv6 charges? > > Maybe the world really will end, and it's all due to IPv6! > > -Sean > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From james.cutler at consultant.com Fri May 2 17:09:25 2008 From: james.cutler at consultant.com (James R. Cutler) Date: Fri, 2 May 2008 18:09:25 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481B8D4B.3080304@ai.net> References: <481B8D4B.3080304@ai.net> Message-ID: <9FDEFA43-E45F-48DC-913E-419143B1835F@consultant.com> Yes -- spent mostly on getting management approval. On May 2, 2008, at 5:53 PM, Deepak Jain wrote: >> Does it take most network operators more than 1000 days to make an >> IPv6 > plan and start implementing it? From randy at psg.com Fri May 2 17:15:15 2008 From: randy at psg.com (Randy Bush) Date: Sat, 03 May 2008 07:15:15 +0900 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <9FDEFA43-E45F-48DC-913E-419143B1835F@consultant.com> References: <481B8D4B.3080304@ai.net> <9FDEFA43-E45F-48DC-913E-419143B1835F@consultant.com> Message-ID: <481B9273.5060106@psg.com> back office software ip and dns management software provisioning tools cpe measurement and monitoring and billing and, of course, backbone and aggregation equipment that can actually handle real ipv6 traffic flows with acls and chocolate syrup. randy From patrick at ianai.net Fri May 2 23:42:03 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 3 May 2008 00:42:03 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <9AEEF477-9768-4825-9E7D-ABD4C2BF218E@let.de> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> <9AEEF477-9768-4825-9E7D-ABD4C2BF218E@let.de> Message-ID: On May 2, 2008, at 6:01 PM, Marc Manthey wrote: >> P.S. >> 10K of your not-so-close friends? > > does this mean this list has 10.000 subscribers ? I've heard all kinds of numbers, you can probably dig something out of the archives. But my understanding is there are far greater than 10K mailboxes which receive NANOG, especially if you include exploders. Could someone from the mail admin team confirm? -- TTFN, patrick From tim at yocum.org Fri May 2 23:48:35 2008 From: tim at yocum.org (Tim Yocum) Date: Fri, 2 May 2008 23:48:35 -0500 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> <9AEEF477-9768-4825-9E7D-ABD4C2BF218E@let.de> Message-ID: <14b99b330805022148m7d41ffe6m8236a108ba0755d6@mail.gmail.com> All, Patrick is correct - the subscriber count is just north of 10k; likely far greater readership considering web archives, remailers, etc. - Tim On 5/2/08, Patrick W. Gilmore wrote: > On May 2, 2008, at 6:01 PM, Marc Manthey wrote: > > >> P.S. > >> 10K of your not-so-close friends? > > > > does this mean this list has 10.000 subscribers ? > > I've heard all kinds of numbers, you can probably dig something out of > the archives. > > But my understanding is there are far greater than 10K mailboxes which > receive NANOG, especially if you include exploders. Could someone > from the mail admin team confirm? > > -- > TTFN, > patrick > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From swmike at swm.pp.se Sat May 3 02:02:01 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 3 May 2008 09:02:01 +0200 (CEST) Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481B9273.5060106@psg.com> References: <481B8D4B.3080304@ai.net> <9FDEFA43-E45F-48DC-913E-419143B1835F@consultant.com> <481B9273.5060106@psg.com> Message-ID: On Sat, 3 May 2008, Randy Bush wrote: > back office software > ip and dns management software > provisioning tools > cpe > measurement and monitoring and billing > > and, of course, backbone and aggregation equipment that can actually > handle real ipv6 traffic flows with acls and chocolate syrup. Not to mention, you want to be able to do the regular antispoofing etc and your security devices (which might be based on L2 switches doing DHCP snooping) doesn't do IPv6, so you need to replace them (or live with lower security) and this needs serious budget. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Sat May 3 02:14:45 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 03 May 2008 00:14:45 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: <481B8D4B.3080304@ai.net> <9FDEFA43-E45F-48DC-913E-419143B1835F@consultant.com> <481B9273.5060106@psg.com> Message-ID: <481C10E5.6090909@bogus.com> Mikael Abrahamsson wrote: > On Sat, 3 May 2008, Randy Bush wrote: > >> back office software >> ip and dns management software >> provisioning tools >> cpe >> measurement and monitoring and billing >> >> and, of course, backbone and aggregation equipment that can actually >> handle real ipv6 traffic flows with acls and chocolate syrup. > > Not to mention, you want to be able to do the regular antispoofing etc and > your security devices (which might be based on L2 switches doing DHCP > snooping) doesn't do IPv6, so you need to replace them (or live with lower > security) and this needs serious budget. Or you'll have to revert to what you did before dhcp filtering switches. Which was watch for replies from rogues and then update your mac filters accordingly or drop the host onto a quarantine vlan. should work quite well for rogue RAs and rogue dhcpv6 servers. Obviously it's reactive rather than proactive but it can be quite effective if automated. From sthaug at nethelp.no Sat May 3 08:27:44 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 03 May 2008 15:27:44 +0200 (CEST) Subject: [NANOG] Did Youtube not pay their domain bill? Message-ID: <20080503.152744.74668247.sthaug@nethelp.no> Did Youtube not pay their domain bill? % dig @a.gtld-servers.net. ns yotube.com yotube.com. 2D IN NS ns1.parked.com. yotube.com. 2D IN NS ns2.parked.com. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From niels=nanog at bakker.net Sat May 3 08:29:06 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 3 May 2008 15:29:06 +0200 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <20080503.152744.74668247.sthaug@nethelp.no> References: <20080503.152744.74668247.sthaug@nethelp.no> Message-ID: <20080503132906.GZ50859@burnout.tpb.net> * sthaug at nethelp.no [Sat 03 May 2008, 15:28 CEST]: >Did Youtube not pay their domain bill? ^^ > >% dig @a.gtld-servers.net. ns yotube.com ^ Still early, Steinar? -- Niels. -- From kkibiego at jambo.co.ke Sat May 3 08:33:01 2008 From: kkibiego at jambo.co.ke (Kipkemoi Kibiego) Date: Sat, 03 May 2008 16:33:01 +0300 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <20080503.152744.74668247.sthaug@nethelp.no> References: <20080503.152744.74668247.sthaug@nethelp.no> Message-ID: <481C698D.30707@jambo.co.ke> yotube.com != youtube.com sthaug at nethelp.no wrote: > Did Youtube not pay their domain bill? > > % dig @a.gtld-servers.net. ns yotube.com > > yotube.com. 2D IN NS ns1.parked.com. > yotube.com. 2D IN NS ns2.parked.com. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > ---------------------------------------------- > This message has been scanned for viruses and > dangerous content by Jambo MailScanner, and is > believed to be clean. > --------------------------------------------- > "easy access to the world" > > From sthaug at nethelp.no Sat May 3 08:35:45 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 03 May 2008 15:35:45 +0200 (CEST) Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <20080503132906.GZ50859@burnout.tpb.net> References: <20080503.152744.74668247.sthaug@nethelp.no> <20080503132906.GZ50859@burnout.tpb.net> Message-ID: <20080503.153545.41716266.sthaug@nethelp.no> > >Did Youtube not pay their domain bill? > ^^ > > > >% dig @a.gtld-servers.net. ns yotube.com > ^ > Still early, Steinar? You're right, clearly insufficient amounts of coffee here... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From eric at spaethco.com Sat May 3 08:40:56 2008 From: eric at spaethco.com (Eric Spaeth) Date: Sat, 03 May 2008 08:40:56 -0500 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C698D.30707@jambo.co.ke> References: <20080503.152744.74668247.sthaug@nethelp.no> <481C698D.30707@jambo.co.ke> Message-ID: <481C6B68.7080602@spaethco.com> Still down either way... =================================================== ; <<>> DiG 9.2.4 <<>> dns1.sjl.youtube.com @a.gtld-servers.net ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22563 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;dns1.sjl.youtube.com. IN A ;; ADDITIONAL SECTION: dns1.sjl.youtube.com. 172800 IN A 208.65.152.201 dns2.sjl.youtube.com. 172800 IN A 208.65.152.137 =================================================== =================================================== ; <<>> DiG 9.2.4 <<>> www.youtube.com @208.65.152.201 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached ; <<>> DiG 9.2.4 <<>> www.youtube.com @208.65.152.137 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached =================================================== Kipkemoi Kibiego wrote: > yotube.com != youtube.com > > sthaug at nethelp.no wrote: > >> Did Youtube not pay their domain bill? >> >> % dig @a.gtld-servers.net. ns yotube.com >> >> yotube.com. 2D IN NS ns1.parked.com. >> yotube.com. 2D IN NS ns2.parked.com. >> >> Steinar Haug, Nethelp consulting, sthaug at nethelp.no >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> >> ---------------------------------------------- >> This message has been scanned for viruses and >> dangerous content by Jambo MailScanner, and is >> believed to be clean. >> --------------------------------------------- >> "easy access to the world" >> >> >> > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From randy at psg.com Sat May 3 08:45:57 2008 From: randy at psg.com (Randy Bush) Date: Sat, 03 May 2008 22:45:57 +0900 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C6B68.7080602@spaethco.com> References: <20080503.152744.74668247.sthaug@nethelp.no> <481C698D.30707@jambo.co.ke> <481C6B68.7080602@spaethco.com> Message-ID: <481C6C95.4060100@psg.com> > dns1.sjl.youtube.com. 172800 IN A 208.65.152.201 > dns2.sjl.youtube.com. 172800 IN A 208.65.152.137 2182 lesson again, probably. after all, microsoft/hotmail/... being borked for a day can't happen to me! randy From branto at branto.com Sat May 3 08:50:16 2008 From: branto at branto.com (Brant I. Stevens) Date: Sat, 03 May 2008 09:50:16 -0400 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C6C95.4060100@psg.com> Message-ID: Maybe that block is anycasted? On 5/3/08 9:45 AM, "Randy Bush" wrote: >> dns1.sjl.youtube.com. 172800 IN A 208.65.152.201 >> dns2.sjl.youtube.com. 172800 IN A 208.65.152.137 > > 2182 lesson again, probably. after all, microsoft/hotmail/... being > borked for a day can't happen to me! > > randy > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From branto at branto.com Sat May 3 08:53:35 2008 From: branto at branto.com (Brant I. Stevens) Date: Sat, 03 May 2008 09:53:35 -0400 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: Message-ID: Never mind. I'll go back to bed now. > Maybe that block is anycasted? > > > On 5/3/08 9:45 AM, "Randy Bush" wrote: > >>> dns1.sjl.youtube.com. 172800 IN A 208.65.152.201 >>> dns2.sjl.youtube.com. 172800 IN A 208.65.152.137 >> >> 2182 lesson again, probably. after all, microsoft/hotmail/... being >> borked for a day can't happen to me! >> >> randy >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From eric at spaethco.com Sat May 3 09:16:50 2008 From: eric at spaethco.com (Eric Spaeth) Date: Sat, 03 May 2008 09:16:50 -0500 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: References: Message-ID: <481C73D2.3010904@spaethco.com> If they were anycasted, shouldn't they be reachable from _somewhere_ ? Those servers are dead from the 4 corners of the US that I have resources to use for testing. Brant I. Stevens wrote: > Maybe that block is anycasted? > > From david at davidcoulson.net Sat May 3 09:25:42 2008 From: david at davidcoulson.net (David Coulson) Date: Sat, 03 May 2008 10:25:42 -0400 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C73D2.3010904@spaethco.com> References: <481C73D2.3010904@spaethco.com> Message-ID: <481C75E6.3060000@davidcoulson.net> Depends - It doesn't help if the DNS server is dead, but the front-end is still advertising the routes. It came back to life for me a few moments ago (via Cogent) and it looks like the routing did not change (there is a bunch of 10/8 stuff in the traceroute). Eric Spaeth wrote: > If they were anycasted, shouldn't they be reachable from _somewhere_ > ? Those servers are dead from the 4 corners of the US that I have > resources to use for testing. From tme at multicasttech.com Sat May 3 10:03:00 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 3 May 2008 11:03:00 -0400 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C75E6.3060000@davidcoulson.net> References: <481C73D2.3010904@spaethco.com> <481C75E6.3060000@davidcoulson.net> Message-ID: <07D6D5B9-9E19-42A7-B6B3-9AFAF6D22314@multicasttech.com> I received a report from a user at 9:46 EDT that they couldn't access youtube, so at least some users were affected. Regards Marshall On May 3, 2008, at 10:25 AM, David Coulson wrote: > Depends - It doesn't help if the DNS server is dead, but the front-end > is still advertising the routes. > > It came back to life for me a few moments ago (via Cogent) and it > looks > like the routing did not change (there is a bunch of 10/8 stuff in the > traceroute). > > Eric Spaeth wrote: >> If they were anycasted, shouldn't they be reachable from _somewhere_ >> ? Those servers are dead from the 4 corners of the US that I have >> resources to use for testing. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From sthaug at nethelp.no Sat May 3 10:07:36 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 03 May 2008 17:07:36 +0200 (CEST) Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C75E6.3060000@davidcoulson.net> References: <481C73D2.3010904@spaethco.com> <481C75E6.3060000@davidcoulson.net> Message-ID: <20080503.170736.74733830.sthaug@nethelp.no> > Depends - It doesn't help if the DNS server is dead, but the front-end > is still advertising the routes. > > It came back to life for me a few moments ago (via Cogent) and it looks > like the routing did not change (there is a bunch of 10/8 stuff in the > traceroute). Looks like it's back here. However, they clearly have more problems. At the moment, the two name servers that the youtube.com domain is delegated to, dns1.sjl.youtube.com. 1H IN A 208.65.152.201 dns2.sjl.youtube.com. 1H IN A 208.65.152.137 reply ok. However, they reply that the youtube.com domain is served by youtube.com. 1H IN NS dns1.sjl.youtube.com. youtube.com. 1H IN NS dns2.sjl.youtube.com. youtube.com. 1H IN NS dns3.sjl.youtube.com. youtube.com. 1H IN NS sjl-ins2.sjl.youtube.com. but reply with NXDOMAIN when asked for the A of sjl-ins2.sjl.youtube.com. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From mike at rockynet.com Sat May 3 12:27:41 2008 From: mike at rockynet.com (Mike Lewinski) Date: Sat, 03 May 2008 11:27:41 -0600 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C75E6.3060000@davidcoulson.net> References: <481C73D2.3010904@spaethco.com> <481C75E6.3060000@davidcoulson.net> Message-ID: <481CA08D.5090200@rockynet.com> David Coulson wrote: > Depends - It doesn't help if the DNS server is dead, but the front-end > is still advertising the routes. Possibly a good argument for allowing the DNS servers to originate the routes for them...? I've seen configuration where the routes were injected based on link state via crossover cable, so at least if the whole machine pukes the route is dropped. But if the resolver or OS itself is just hung then yeah... Mike From blackham at gmail.com Sat May 3 14:23:15 2008 From: blackham at gmail.com (Kevin Blackham) Date: Sat, 3 May 2008 13:23:15 -0600 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481CA08D.5090200@rockynet.com> References: <481C73D2.3010904@spaethco.com> <481C75E6.3060000@davidcoulson.net> <481CA08D.5090200@rockynet.com> Message-ID: We did that with our internally anycasted recursors at my former network. A script withdraws the routes if bind isn't answering. Works great. On 5/3/08, Mike Lewinski wrote: > David Coulson wrote: > > Depends - It doesn't help if the DNS server is dead, but the front-end > > is still advertising the routes. > > Possibly a good argument for allowing the DNS servers to originate the > routes for them...? I've seen configuration where the routes were > injected based on link state via crossover cable, so at least if the > whole machine pukes the route is dropped. But if the resolver or OS > itself is just hung then yeah... > > Mike > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From scg at gibbard.org Sat May 3 17:10:56 2008 From: scg at gibbard.org (Steve Gibbard) Date: Sat, 3 May 2008 15:10:56 -0700 (PDT) Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481CA08D.5090200@rockynet.com> References: <481C73D2.3010904@spaethco.com> <481C75E6.3060000@davidcoulson.net> <481CA08D.5090200@rockynet.com> Message-ID: <20080503145255.W10017@sprockets.gibbard.org> On Sat, 3 May 2008, Mike Lewinski wrote: > David Coulson wrote: >> Depends - It doesn't help if the DNS server is dead, but the front-end >> is still advertising the routes. > > Possibly a good argument for allowing the DNS servers to originate the > routes for them...? I've seen configuration where the routes were Running Quagga or something similar on the anycasted server to announce the routes is the standard way of setting up anycast. That way, if the server fails completely, the route goes away. A common improvement on that is to run a script on the server that checks to make sure the name server process is running and responding correctly, and kills BGP if it isn't. That covers cases where named has problems that don't take down the whole server. The first one depends heavily on the server, if it's going to fail, failing the right way. If it loses power or stops all processes, the route goes away and traffic gets redirected elsewhere. If named dies or stops responding, you're stuck. The second method solves a lot of that sort of problems, but there are still conceivable situations where the server would get into a state of partial failure and be unable to withdraw the route. Still, that's probably the best option. Another approach would be to run the monitoring script and BGP process on a separate host that would presumably be healthy even when the name server host is in trouble. That approach has issues too, in that you lose the guarantee that the route will go away if the name server box is turned off. The right solution is to design the anycast servers to be as sure as possible that the route will go away when you want it gone, but to have multiple non-interdependent anycast clouds in the NS records for each zone. If the local node in one cloud does fail improperly, something will still be responding on the other cloud's IP address. Note that any of these failure scenarios is still preferable to what you get with unicast servers. With unicast, if the server has trouble, the route always stays up, and the the traffic always ends up in a black hole. -Steve From randy at psg.com Sat May 3 17:17:08 2008 From: randy at psg.com (Randy Bush) Date: Sun, 04 May 2008 07:17:08 +0900 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <481C73D2.3010904@spaethco.com> References: <481C73D2.3010904@spaethco.com> Message-ID: <481CE464.4080205@psg.com> Eric Spaeth wrote: > If they were anycasted, shouldn't they be reachable from _somewhere_ not if routing problem with the prefix. anycasted prefixes have analogous problem to that described in 2182. need at least two separately routed prefixes or single method of failure. randy From gih at apnic.net Sat May 3 22:10:06 2008 From: gih at apnic.net (Geoff Huston) Date: Sun, 04 May 2008 13:10:06 +1000 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: Message-ID: <481D290E.6010000@apnic.net> Mike Leber wrote: > Since nobody mentioned it yet, there are now less than 1000 days projected > until IPv4 exhaustion: > > http://www.potaroo.net/tools/ipv4/ .... > ps. 1000 days assumes no rush, speculation, or hoarding. Do people do > that? > > pps. Of course these are provocative comments for amusement. :) > I keep on saying: its just a mathematical model, and the way this will play out is invariably different from our best guesses. So to say "well there's x days to go" is somewhat misleading as it appears to vest this model with some air of authority about the future, and that's not a good idea! IPv4 address allocation is a rather skewed distribution. Most address allocations are relatively small, but a small number of them are relatively large. Its the the timing of this smaller set of actors who are undertaking large deployments that will ultimately determine how this plays out. It could be a lot faster than 1000 days, or it could be slower - its very uncertain. There could be some "last minute rush." There could be a change in policies over remaining address pools as the pool diminishes, or .... So, yes, the pool is visibly draining and you now can see all the way to the bottom. And it looks like there are around 3 years to go ... but thats with an uncertainty factor of at least +/- about 1 1/2 years. regards, Geoff From hescominsoon at emmanuelcomputerconsulting.com Sat May 3 22:22:26 2008 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Sat, 03 May 2008 23:22:26 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481D290E.6010000@apnic.net> References: <481D290E.6010000@apnic.net> Message-ID: <481D2BF2.9000105@emmanuelcomputerconsulting.com> That also doesn't take into account how many /8's are being hoarded by organizations that don't need even 25% of that space. Geoff Huston wrote: > Mike Leber wrote: >> Since nobody mentioned it yet, there are now less than 1000 days projected >> until IPv4 exhaustion: >> >> http://www.potaroo.net/tools/ipv4/ > > .... > >> ps. 1000 days assumes no rush, speculation, or hoarding. Do people do >> that? >> >> pps. Of course these are provocative comments for amusement. :) >> > > > I keep on saying: its just a mathematical model, and the way this will play > out is invariably different from our best guesses. So to say "well there's > x days to go" is somewhat misleading as it appears to vest this model > with some air of authority about the future, and that's not a good idea! > > IPv4 address allocation is a rather skewed distribution. Most address > allocations are relatively small, but a small number of them are relatively > large. Its the the timing of this smaller set of actors who are undertaking > large deployments that will ultimately determine how this plays out. It > could be a lot faster than 1000 days, or it could be slower - its very > uncertain. There could be some "last minute rush." There could be a change > in policies over remaining address pools as the pool diminishes, or .... > > So, yes, the pool is visibly draining and you now can see all the way to > the bottom. And it looks like there are around 3 years to go ... > but thats with an uncertainty factor of at least +/- about 1 1/2 years. > > regards, > > Geoff > > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Registered Microsoft Partner My "Foundation" verse: Isa 54:17 From nanog at daork.net Sat May 3 22:35:59 2008 From: nanog at daork.net (Nathan Ward) Date: Sun, 4 May 2008 15:35:59 +1200 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481D2BF2.9000105@emmanuelcomputerconsulting.com> References: <481D290E.6010000@apnic.net> <481D2BF2.9000105@emmanuelcomputerconsulting.com> Message-ID: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> On 4/05/2008, at 3:22 PM, William Warren wrote: > That also doesn't take into account how many /8's are being hoarded by > organizations that don't need even 25% of that space. Unless you're expecting those organisations to be really nice and make that address space available to other organisations (ie. their RIR/ LIR, or the highest bidder on ebay), then I don't see how that's relevant - whether they've got machines on those addresses or not, from an outsider's point of view the address space is unavailable for them to use. ..or, maybe your thought is that at some point these guys will start using addresses in those /8s, and stop requesting new allocations from their RIR/LIR, which will in turn slow down IPv4 allocations? I'm not sure, but licking my finger and sticking it out the window suggests that allocations to those with little-utilised /8s is a fairly small percentage. -- Nathan Ward From joelja at bogus.com Sat May 3 22:37:28 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 03 May 2008 20:37:28 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481D2BF2.9000105@emmanuelcomputerconsulting.com> References: <481D290E.6010000@apnic.net> <481D2BF2.9000105@emmanuelcomputerconsulting.com> Message-ID: <481D2F78.6020000@bogus.com> William Warren wrote: > That also doesn't take into account how many /8's are being hoarded by > organizations that don't need even 25% of that space. which one's would those be? legacy class A address space just isn't that big... > Geoff Huston wrote: >> Mike Leber wrote: >>> Since nobody mentioned it yet, there are now less than 1000 days projected >>> until IPv4 exhaustion: >>> >>> http://www.potaroo.net/tools/ipv4/ >> .... >> >>> ps. 1000 days assumes no rush, speculation, or hoarding. Do people do >>> that? >>> >>> pps. Of course these are provocative comments for amusement. :) >>> >> >> I keep on saying: its just a mathematical model, and the way this will play >> out is invariably different from our best guesses. So to say "well there's >> x days to go" is somewhat misleading as it appears to vest this model >> with some air of authority about the future, and that's not a good idea! >> >> IPv4 address allocation is a rather skewed distribution. Most address >> allocations are relatively small, but a small number of them are relatively >> large. Its the the timing of this smaller set of actors who are undertaking >> large deployments that will ultimately determine how this plays out. It >> could be a lot faster than 1000 days, or it could be slower - its very >> uncertain. There could be some "last minute rush." There could be a change >> in policies over remaining address pools as the pool diminishes, or .... >> >> So, yes, the pool is visibly draining and you now can see all the way to >> the bottom. And it looks like there are around 3 years to go ... >> but thats with an uncertainty factor of at least +/- about 1 1/2 years. >> >> regards, >> >> Geoff >> >> >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > From ops.lists at gmail.com Sat May 3 23:53:17 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 4 May 2008 10:23:17 +0530 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481D2F78.6020000@bogus.com> References: <481D290E.6010000@apnic.net> <481D2BF2.9000105@emmanuelcomputerconsulting.com> <481D2F78.6020000@bogus.com> Message-ID: Let's think smaller. /16 shall we say? Like the /16 here. Originally the SRI / ARPANET SF Bay Packet Radio network that started back in 1977. Now controlled by a shell company belonging to a shell company belonging to a "high volume email deployer" :) http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html srs On Sun, May 4, 2008 at 9:07 AM, Joel Jaeggli wrote: > William Warren wrote: > > That also doesn't take into account how many /8's are being hoarded by > > organizations that don't need even 25% of that space. > > which one's would those be? > > legacy class A address space just isn't that big... From sharp at sharpone.net Sun May 4 00:29:57 2008 From: sharp at sharpone.net (Justin Sharp) Date: Sat, 03 May 2008 23:29:57 -0600 Subject: [NANOG] outages@isotf.org Message-ID: <481D49D5.6050302@sharpone.net> Hello, Forgive me if this has been covered previously. I have recently discovered this list and have found it a gold mine of information. I've now traded 3 hours of my life reading through archives and have even found reference to specific recent outages that my company suffered to which we never really did get a RFO from the ISP. In the archives, I have read of another list which I am interested in at outages at isotf.org. I've tried visiting the site, and subscribing at http://www.isotf.org/mailman/listinfo/outages (as mentioned in several archived messages) but it doesn't seem to exist there anymore. Also tried to search this list for information as to whether it had moved or been discontinued, etc (google site searches, etc). Has this list been discontinued? If not, is it still open to the public, and what is its new location, that I might subscribe? Regards, --Justin From ge at linuxbox.org Sun May 4 00:50:11 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 4 May 2008 00:50:11 -0500 (CDT) Subject: [NANOG] outages@isotf.org In-Reply-To: <481D49D5.6050302@sharpone.net> References: <481D49D5.6050302@sharpone.net> Message-ID: That list oaught to be working again in a matter of days. On Sat, 3 May 2008, Justin Sharp wrote: > Hello, > > Forgive me if this has been covered previously. > > I have recently discovered this list and have found it a gold mine of > information. I've now traded 3 hours of my life reading through archives > and have even found reference to specific recent outages that my company > suffered to which we never really did get a RFO from the ISP. > > In the archives, I have read of another list which I am interested in at > outages at isotf.org. I've tried visiting the site, and subscribing at > http://www.isotf.org/mailman/listinfo/outages (as mentioned in several > archived messages) but it doesn't seem to exist there anymore. Also > tried to search this list for information as to whether it had moved or > been discontinued, etc (google site searches, etc). Has this list been > discontinued? If not, is it still open to the public, and what is its > new location, that I might subscribe? > > Regards, > > --Justin > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From vixie at isc.org Sun May 4 11:19:53 2008 From: vixie at isc.org (Paul Vixie) Date: 04 May 2008 16:19:53 +0000 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: <20080503145255.W10017@sprockets.gibbard.org> References: <20080503145255.W10017@sprockets.gibbard.org> Message-ID: scg at gibbard.org (Steve Gibbard) writes: > On Sat, 3 May 2008, Mike Lewinski wrote: > > > David Coulson wrote: > >> Depends - It doesn't help if the DNS server is dead, but the front-end > >> is still advertising the routes. > > > > Possibly a good argument for allowing the DNS servers to originate the > > routes for them...? I've seen configuration where the routes were > > Running Quagga or something similar on the anycasted server to announce > the routes is the standard way of setting up anycast. That way, if the > server fails completely, the route goes away. that's what joe said to do in . > A common improvement on that is to run a script on the server that checks > to make sure the name server process is running and responding correctly, > and kills BGP if it isn't. That covers cases where named has problems > that don't take down the whole server. in ISC-TN-2004-1 [ibid], appendix D, joe suggests bringing up and down the interface BIND listens on (which presumes that it's a dedicated loopback like lo1 whose address is covered by a quagga route advertisement rule). note that joe's example brings up the interface before starting the name server program, and bringing it down if the name server program exits. this presumes that the name server will start very quickly, and that while running, it is healthy. since i've seen name server programs be unhealthy while running, and/or take a long time to start, i'm now considering an outboard shell script that runs some kind of DNS query and decides, based on the result, whether to bring the dedicated loopback interface up or down. > ... > The right solution is to design the anycast servers to be as sure as > possible that the route will go away when you want it gone, but to have > multiple non-interdependent anycast clouds in the NS records for each > zone. If the local node in one cloud does fail improperly, something will > still be responding on the other cloud's IP address. the need for multiple independent anycast clouds is an RFC 2182 topic, but joe's innovation both in ISC-TN-2004-1 and in his earlier ISC-TN-2003-1 (see is that if each anycast cluster is really several servers, each using OSPF ECMP, then you can lose a server and still have that cluster advertising the route upstream, and only when you lose all servers in a cluster will that route be withdrawn. > Note that any of these failure scenarios is still preferable to what you > get with unicast servers. With unicast, if the server has trouble, the > route always stays up, and the the traffic always ends up in a black hole. here, the real problem is the route staying up, which also blackholes anycast. the only things DNS anycast universally buys you are DDoS resilience and hot swap. anything else anycast can do (high availability, low avg. RTT, etc) can also be engineered using a unicast design, though probably at higher TCO. -- Paul Vixie From vixie at isc.org Sun May 4 11:39:17 2008 From: vixie at isc.org (Paul Vixie) Date: 04 May 2008 16:39:17 +0000 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 In-Reply-To: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> References: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> Message-ID: nanog at daork.net (Nathan Ward) writes: > > That also doesn't take into account how many /8's are being hoarded by > > organizations that don't need even 25% of that space. > > Unless you're expecting those organisations to be really nice and make > that address space available to other organisations (ie. their RIR/ > LIR, or the highest bidder on ebay), ... first, a parable: in datacenters, it used to be that the scarce resource was rack space, but then it was connectivity, and now it's power/heat/cooling. there are fallow fields of empty racks too far from fiber routes or power grids to be filled, all because the scarcity selector has moved over time. some folks who were previously close to fiber routes and/or power grids found that they could do greenfield construction and that the customers would naturally move in, since too much older datacenter capacity was unusable by modern standards. then, a recounting: michael dillon asked a while back what could happen if MIT (holding 18/8) were to go into the ISP business, offering dialup and/or tunnel/VPN access, and bundling a /24 with each connection, and allowing each customer to multihome if they so chose. nobody could think of an RIR rule, or an ISP rule, or indeed anything else that could prevent this from occurring. now, i don't think that MIT would do this, since it would be a distraction for them, and they probably don't need the money, and they're good guys, anyway. now, a prediction: but if the bottom feeding scumsuckers who saw the opportunity now known as spam, or the ones who saw the opportunity now known as NXDOMAIN remapping, or the ones who saw the opportunity now known as DDoS for hire, realize that the next great weakness in the internet's design and protocols is explosive deaggregation by virtual shill networking, then we can expect business plans whereby well suited shysters march into MIT, and HP, and so on, offering to outsource this monetization. "you get half the money but none of the distraction, all you have to do is renumber or use NAT or IPv6, we'll do the rest." nothing in recorded human history argues against this occurring. -- Paul Vixie From tomb at byrneit.net Sun May 4 13:37:11 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 4 May 2008 11:37:11 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 In-Reply-To: References: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> I'm not sure that I would tar everyone who does NXDOMAIN remapping with the same brush as SPAM and DDOS. Handled the way OpenDNS does, on an opt-in basis, it's a "good thing" IMO. I would also say that disaggregating and remarketing dark address space, assuming it's handled above board and in a way that doesn't break the 'net, could be a "very good thing". The artifact of MIT and others having /8s while the entire Indian subcontinent scrapes for /29s, can hardly be considered optimal or right. It's time for the supposedly altruistic good guys to do the right thing, and give back the resources they are not using, that are sorely needed. How about they resell it and use the money to make getting an education affordable? The routing prefix problem, OTOH, is an artificial shortage caused by (mostly one) commercial entities maximizing their bottom line by producing products that were obviously underpowered at the time they were designed, so as to minimize component costs, and ensure users upgraded due to planned obsolescence. Can you give me a good technical reason, in this day of 128 bit network processors that can handle 10GigE, why remapping the entire IPv4 address space into /27s and propagating all the prefixes is a real engineering problem? Especially if those end-points are relatively stable as to connectivity, the allocations are non-portable, and you aggregate. How is fork-lifting the existing garbage for better IPv4 routers any worse than migrating to IPv6? At least with an IPv4 infrastructure overhaul, it's relatively transparent to the end user. It's not either/or anyway. Ideally you would have an IPv6 capable router that could do IPv4 without being babied as to prefix table size or update rate. IPv4 has enough addresses for every computer on Earth, and then some. That having been said, I think going to IPv6 has a lot of other benefits that make it worthwhile. YMMV, IANAL, yadda yadda yadda > -----Original Message----- > From: Paul Vixie [mailto:vixie at isc.org] > Sent: Sunday, May 04, 2008 9:39 AM > To: nanog at merit.edu > Subject: Re: [NANOG] fair warning: less than 1000 days left to IPv4 > > nanog at daork.net (Nathan Ward) writes: > > > > That also doesn't take into account how many /8's are > being hoarded > > > by organizations that don't need even 25% of that space. > > > > Unless you're expecting those organisations to be really > nice and make > > that address space available to other organisations (ie. their RIR/ > > LIR, or the highest bidder on ebay), ... > > first, a parable: > > in datacenters, it used to be that the scarce resource was > rack space, but then it was connectivity, and now it's > power/heat/cooling. there are fallow fields of empty racks > too far from fiber routes or power grids to be filled, all > because the scarcity selector has moved over time. some > folks who were previously close to fiber routes and/or power > grids found that they could do greenfield construction and > that the customers would naturally move in, since too much > older datacenter capacity was unusable by modern standards. > > then, a recounting: > > michael dillon asked a while back what could happen if MIT > (holding 18/8) were to go into the ISP business, offering > dialup and/or tunnel/VPN access, and bundling a /24 with each > connection, and allowing each customer to multihome if they > so chose. nobody could think of an RIR rule, or an ISP rule, > or indeed anything else that could prevent this from > occurring. now, i don't think that MIT would do this, since > it would be a distraction for them, and they probably don't > need the money, and they're good guys, anyway. > > now, a prediction: > > but if the bottom feeding scumsuckers who saw the opportunity > now known as spam, or the ones who saw the opportunity now > known as NXDOMAIN remapping, or the ones who saw the > opportunity now known as DDoS for hire, realize that the next > great weakness in the internet's design and protocols is > explosive deaggregation by virtual shill networking, then we > can expect business plans whereby well suited shysters march > into MIT, and HP, and so on, offering to outsource this > monetization. "you get half the money but none of the > distraction, all you have to do is renumber or use NAT or > IPv6, we'll do the rest." nothing in recorded human history > argues against this occurring. > -- > Paul Vixie > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From virendra.rode at gmail.com Sun May 4 13:48:00 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Sun, 04 May 2008 11:48:00 -0700 Subject: [NANOG] [Fwd: Re: outages@isotf.org] Message-ID: <481E04E0.2090600@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We are on the final stages of getting the host operational that has taken longer than we expected. This was a combination of application / hardware related issue that caused a prolonged outage. We deeply regret the delay and we should have outages mailing operational soon. The goal is to pull the host out of operation without affecting the service in the future. Thanks all for your patience during this prolonged delay. regards, /virendra - -------- Original Message -------- Subject: Re: [NANOG] outages at isotf.org Date: Sun, 4 May 2008 00:50:11 -0500 (CDT) From: Gadi Evron To: justin at sharpone.net CC: nanog at nanog.org References: <481D49D5.6050302 at sharpone.net> That list oaught to be working again in a matter of days. On Sat, 3 May 2008, Justin Sharp wrote: > Hello, > > Forgive me if this has been covered previously. > > I have recently discovered this list and have found it a gold mine of > information. I've now traded 3 hours of my life reading through archives > and have even found reference to specific recent outages that my company > suffered to which we never really did get a RFO from the ISP. > > In the archives, I have read of another list which I am interested in at > outages at isotf.org. I've tried visiting the site, and subscribing at > http://www.isotf.org/mailman/listinfo/outages (as mentioned in several > archived messages) but it doesn't seem to exist there anymore. Also > tried to search this list for information as to whether it had moved or > been discontinued, etc (google site searches, etc). Has this list been > discontinued? If not, is it still open to the public, and what is its > new location, that I might subscribe? > > Regards, > > --Justin > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHgTgpbZvCIJx1bcRAmzBAJoCtjUyQ4sFAwRlKv9q+HF5wtmGbACfXXCl JP9n+9Hb5gb9G43MQrjzkC0= =9kiY -----END PGP SIGNATURE----- From paul at vix.com Sun May 4 14:08:31 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 04 May 2008 19:08:31 +0000 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 In-Reply-To: Your message of "Sun, 04 May 2008 11:37:11 MST." <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> References: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> Message-ID: <4034.1209928111@sa.vix.com> > I'm not sure that I would tar everyone who does NXDOMAIN remapping with > the same brush as SPAM and DDOS. Handled the way OpenDNS does, on an > opt-in basis, it's a "good thing" IMO. i agree, and i'm on record as saying that since opendns doesn't affect the people who do not knowingly sign up for it, and that it's free even to folks who opt out of the remapping, it is not an example of inappropriate trust monetization (as it would be if your hotel or ISP did it do you without your consent, or, offered you no alternative, or, offered you no opt-out.) > I would also say that disaggregating and remarketing dark address space, > assuming it's handled above board and in a way that doesn't break the > 'net, could be a "very good thing". that's a "very big if". > The routing prefix problem, OTOH, is an artificial shortage caused by > (mostly one) commercial entities maximizing their bottom line by > producing products that were obviously underpowered at the time they > were designed, so as to minimize component costs, and ensure users > upgraded due to planned obsolescence. i completely disagree, but, assuming you were right, what do you propose do do about it, or propose that we all do about it, to avoid having it lead to some kind of global meltdown if new prefixes start appearing "too fast"? > Can you give me a good technical reason, in this day of 128 bit network > processors that can handle 10GigE, why remapping the entire IPv4 address > space into /27s and propagating all the prefixes is a real engineering > problem? Especially if those end-points are relatively stable as to > connectivity, the allocations are non-portable, and you aggregate. you almost had me there. i was going to quote some stuff i remember tony li saying about routing physics at the denver ARIN meeting, and i was going to explain three year depreciation cycles, global footprints, training, release trains, and some graph theory stuff like number of edges, number of nodes, size of edge, natural instability. couldn't been fun, especially since many people on this mailing list know the topic better than i do and we could've gone all week with folks correcting eachother in the ways they corrected me. but the endpoints aren't "stable" at all, not even "relatively." and the allocations are naturally "portable". and "aggregation" won't be occurring. so, rather than answer your "technical reason" question, i'll say, we're in a same planet different worlds scenario here. we don't share assumptions that would make a joint knowledge quest fruitful. > How is fork-lifting the existing garbage for better IPv4 routers any > worse than migrating to IPv6? At least with an IPv4 infrastructure > overhaul, it's relatively transparent to the end user. It's not > either/or anyway. Ideally you would have an IPv6 capable router that > could do IPv4 without being babied as to prefix table size or update > rate. forklifting in routers that can speak ipv6 means that when we're done, the new best-known limiting factor to internet growth will be something other than the size of the address space. and noting that the lesser-known factor that's actually much more real and much more important is number of prefixes, there is some hope that the resulting ipv6 table won't have quite as much nearly-pure crap in it as the current ipv4 has. eventually we will of course fill it with TE, but by the time that can happen, routing physics will have improved some. my hope is that by the time a midlevel third tier multihomed ISP needs a dozen two-megaroute dual stack 500Gbit/sec routers to keep up with other people's TE routes, then, such things will be available on e-bay. everything about IP is transparent to the end user. they just want to click on stuff and get action at a distance. dual stack ipv4/ipv6 does that pretty well already, for those running macos, vista, linux, or bsd, whose providers and SOHO boxes are offering dual-stack. there's reason to expect that end users will continue to neither know nor care what kind of IP they are using, whether ipv6 takes off, or doesn't. > IPv4 has enough addresses for every computer on Earth, and then some. if only we didn't need IP addresses for every coffee cup, light switch, door knob, power outlet, TV remote control, cell phone, and so on, then we could almost certainly live with IPv4 and NAT. however, i'd like to stay on track toward digitizing everything, wiring most stuff, unwiring the rest, and otherwise making a true internet of everything in the real world, and not just the world's computers. > That having been said, I think going to IPv6 has a lot of other benefits > that make it worthwhile. me too. From joelja at bogus.com Sun May 4 14:12:48 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 04 May 2008 12:12:48 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 In-Reply-To: <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> References: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> Message-ID: <481E0AB0.6090606@bogus.com> Tomas L. Byrnes wrote: > IPv4 has enough addresses for every computer on Earth, and then some. There are approximately 3.4 billion or a little less usable ip addresses. there are 3.3 billion mobile phone users buying approximately 400,000 ip capable devices a day. That's a single industy, notwithstanding how the are presently employed what do you think those deployments are going to look like in 5 years? in 10? How many ip addresses do you need to nat 100 million customers? how much state do you have to carry to do port demux for their traffic? I guess making it all scale is someone else's problem... > That having been said, I think going to IPv6 has a lot of other benefits > that make it worthwhile. > > YMMV, IANAL, yadda yadda yadda > > > >> -----Original Message----- >> From: Paul Vixie [mailto:vixie at isc.org] >> Sent: Sunday, May 04, 2008 9:39 AM >> To: nanog at merit.edu >> Subject: Re: [NANOG] fair warning: less than 1000 days left to IPv4 >> >> nanog at daork.net (Nathan Ward) writes: >> >>>> That also doesn't take into account how many /8's are >> being hoarded >>>> by organizations that don't need even 25% of that space. >>> Unless you're expecting those organisations to be really >> nice and make >>> that address space available to other organisations (ie. their RIR/ >>> LIR, or the highest bidder on ebay), ... >> first, a parable: >> >> in datacenters, it used to be that the scarce resource was >> rack space, but then it was connectivity, and now it's >> power/heat/cooling. there are fallow fields of empty racks >> too far from fiber routes or power grids to be filled, all >> because the scarcity selector has moved over time. some >> folks who were previously close to fiber routes and/or power >> grids found that they could do greenfield construction and >> that the customers would naturally move in, since too much >> older datacenter capacity was unusable by modern standards. >> >> then, a recounting: >> >> michael dillon asked a while back what could happen if MIT >> (holding 18/8) were to go into the ISP business, offering >> dialup and/or tunnel/VPN access, and bundling a /24 with each >> connection, and allowing each customer to multihome if they >> so chose. nobody could think of an RIR rule, or an ISP rule, >> or indeed anything else that could prevent this from >> occurring. now, i don't think that MIT would do this, since >> it would be a distraction for them, and they probably don't >> need the money, and they're good guys, anyway. >> >> now, a prediction: >> >> but if the bottom feeding scumsuckers who saw the opportunity >> now known as spam, or the ones who saw the opportunity now >> known as NXDOMAIN remapping, or the ones who saw the >> opportunity now known as DDoS for hire, realize that the next >> great weakness in the internet's design and protocols is >> explosive deaggregation by virtual shill networking, then we >> can expect business plans whereby well suited shysters march >> into MIT, and HP, and so on, offering to outsource this >> monetization. "you get half the money but none of the >> distraction, all you have to do is renumber or use NAT or >> IPv6, we'll do the rest." nothing in recorded human history >> argues against this occurring. >> -- >> Paul Vixie >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From jlloret at dcom.upv.es Sun May 4 14:55:40 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Sun, 4 May 2008 21:55:40 +0200 Subject: [NANOG] Deadline Extension UBICOMM 2008, September 29 - October 4, Valencia, Spain Message-ID: <1209930940.481e14bcd19b3@webmail.upv.es> Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Apologies for cross-postings. ============== UBICOMM 2008 Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS UBICOMM 2008, The Second International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies September 29 - October 4, Valencia, Spain General page: http://www.iaria.org/conferences2008/UBICOMM08.html Call for Papers: http://www.iaria.org/conferences2008/CfPUBICOMM08.html Important deadlines: Submission deadline May 15, 2008 Notification June 15, 2008 Registration and camera ready July 20, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. UBICOMM 2008 Special Area Tracks (details in the CfP on site): Fundamentals Semantics of ubiquity; Ubiquitous knowledge; Knowledge discovery mechanisms; Profiling ubiquitous environments; Ubiquitous technologies for education, learning, and training Mobility Ubiquitous computing; Wearable computing; Mobile computing; Nomadic computing; Mobile commerce; Mobile learning Information Ubiquity Ubiquitous information appliances; Information retrieval and filtering; Context awareness; Control of ubiquitous data; Data management and processing; Data replication, migration and dissemination Ubiquitous Multimedia Systems and Processing Multimedia content recognition, indexing and search; Mobile graphics, games and entertainment; Ubiquitous multimedia applications and systems; Streaming mobile multimedia; Mobile media management; Multimedia ubiquitous platforms; Multimedia Indexing and Compression; Image and Signal Processing; Virtual reality in ubiquitous systems Wireless Technologies Bluetooth; 802.11.x; 802.15.x; ZigBee; WiMax Web Services Web 2.0; Semantic web; Web services; Ontology; Web Services evolution; Web Services applications Ubiquitous networks Ubiquitous networks; Network management; Network performance evaluation; Networks and technology convergence; Internet access in ubiquitous systems; Ubiquitous mesh, ad hoc and sensor networks; RFID; Reconfigurability and personalization of ubiquitous networks Ubiquitous devices and operative systems Design of devices for ubiquitous systems; Mobile devices; Wearable devices; Embedded systems; Operative systems for ubiquitous devices; Real-time operating systems and scheduling Ubiquitous mobile services and protocols Frameworks, architectures, and languages for ubiquitous services; Queries, transactions and workflows in mobile and ubiquitous Networks; Algorithms for ubiquitous systems; SLA/QoS in ubiquitous services; Ontology based services; Location-based services; Protocols and interaction mechanisms for ubiquitous services; Mobile services and service convergence; Service discovery mechanisms; Tracking in ubiquitous environments; Measurement, control, and management of ubiquitous services; Design and development of ubiquitous services; Wireless/mobile service delivery Ubiquitous software and security Ambient components; Agent technologies; Software for spontaneous interoperation; Dependability guarantees; Security; Key Management and Authentication; Trust; Privacy; Fault-tolerance; Multimedia Information Security Collaborative ubiquitous systems Cooperative networks for ubiquitous systems; Cooperative applications for ubiquitous networks; Handheld and wearable systems for interaction in collaborative groups and communities; Ad hoc collaboration in ubiquitous computing environments; Awareness of collaboration and of work environment; Inherently mobile collaborative work User and applications Mobile user interfaces; Ubiquitous user-generated content (weblogs, wikis, etc.); Mobile and ubiquitous computing support for collaborative learning; User modeling and personalization; Context- and location-aware applications; Toolkits, testbeds, development environments; Tools and techniques for designing, implementing, & evaluating ubiquitous systems; Constructing, deploying and prototyping of ubiquitous applications; Evaluation of user models for ubiquitous environments; On-line analytical techniques; Human-computer interaction in ubiquitous computing environments; Ubiquitous e-Development (business, science, health, etc.); Case Studies; Emerging industrial/business/scientific ubiquitous scenarios; Ambient intelligence; Social issues and implications of ubiquitous system ================================ UBICOMM 2008 Chairs General Chair Jaime Lloret Mauri, Polytechnic University of Valencia, Spain Program Committee Chairs Narc?s Cardona, Polytechnic University of Valencia, Spain Kwang-Cheng Chen, Taiwan National University, Taiwan Steering Committee Chair Petre Dini, Cisco Systems, Inc. / Concordia University, Canada =============================================== -- From jlloret at dcom.upv.es Sun May 4 14:56:54 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Sun, 4 May 2008 21:56:54 +0200 Subject: [NANOG] Deadline Extension UBICOMM 2008, September 29 - October 4, Valencia, Spain Message-ID: <1209931014.481e15067c288@webmail.upv.es> Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Apologies for cross-postings. ============== UBICOMM 2008 Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS UBICOMM 2008, The Second International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies September 29 - October 4, Valencia, Spain General page: http://www.iaria.org/conferences2008/UBICOMM08.html Call for Papers: http://www.iaria.org/conferences2008/CfPUBICOMM08.html Important deadlines: Submission deadline May 15, 2008 Notification June 15, 2008 Registration and camera ready July 20, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. UBICOMM 2008 Special Area Tracks (details in the CfP on site): Fundamentals Semantics of ubiquity; Ubiquitous knowledge; Knowledge discovery mechanisms; Profiling ubiquitous environments; Ubiquitous technologies for education, learning, and training Mobility Ubiquitous computing; Wearable computing; Mobile computing; Nomadic computing; Mobile commerce; Mobile learning Information Ubiquity Ubiquitous information appliances; Information retrieval and filtering; Context awareness; Control of ubiquitous data; Data management and processing; Data replication, migration and dissemination Ubiquitous Multimedia Systems and Processing Multimedia content recognition, indexing and search; Mobile graphics, games and entertainment; Ubiquitous multimedia applications and systems; Streaming mobile multimedia; Mobile media management; Multimedia ubiquitous platforms; Multimedia Indexing and Compression; Image and Signal Processing; Virtual reality in ubiquitous systems Wireless Technologies Bluetooth; 802.11.x; 802.15.x; ZigBee; WiMax Web Services Web 2.0; Semantic web; Web services; Ontology; Web Services evolution; Web Services applications Ubiquitous networks Ubiquitous networks; Network management; Network performance evaluation; Networks and technology convergence; Internet access in ubiquitous systems; Ubiquitous mesh, ad hoc and sensor networks; RFID; Reconfigurability and personalization of ubiquitous networks Ubiquitous devices and operative systems Design of devices for ubiquitous systems; Mobile devices; Wearable devices; Embedded systems; Operative systems for ubiquitous devices; Real-time operating systems and scheduling Ubiquitous mobile services and protocols Frameworks, architectures, and languages for ubiquitous services; Queries, transactions and workflows in mobile and ubiquitous Networks; Algorithms for ubiquitous systems; SLA/QoS in ubiquitous services; Ontology based services; Location-based services; Protocols and interaction mechanisms for ubiquitous services; Mobile services and service convergence; Service discovery mechanisms; Tracking in ubiquitous environments; Measurement, control, and management of ubiquitous services; Design and development of ubiquitous services; Wireless/mobile service delivery Ubiquitous software and security Ambient components; Agent technologies; Software for spontaneous interoperation; Dependability guarantees; Security; Key Management and Authentication; Trust; Privacy; Fault-tolerance; Multimedia Information Security Collaborative ubiquitous systems Cooperative networks for ubiquitous systems; Cooperative applications for ubiquitous networks; Handheld and wearable systems for interaction in collaborative groups and communities; Ad hoc collaboration in ubiquitous computing environments; Awareness of collaboration and of work environment; Inherently mobile collaborative work User and applications Mobile user interfaces; Ubiquitous user-generated content (weblogs, wikis, etc.); Mobile and ubiquitous computing support for collaborative learning; User modeling and personalization; Context- and location-aware applications; Toolkits, testbeds, development environments; Tools and techniques for designing, implementing, & evaluating ubiquitous systems; Constructing, deploying and prototyping of ubiquitous applications; Evaluation of user models for ubiquitous environments; On-line analytical techniques; Human-computer interaction in ubiquitous computing environments; Ubiquitous e-Development (business, science, health, etc.); Case Studies; Emerging industrial/business/scientific ubiquitous scenarios; Ambient intelligence; Social issues and implications of ubiquitous system ================================ UBICOMM 2008 Chairs General Chair Jaime Lloret Mauri, Polytechnic University of Valencia, Spain Program Committee Chairs Narc?s Cardona, Polytechnic University of Valencia, Spain Kwang-Cheng Chen, Taiwan National University, Taiwan Steering Committee Chair Petre Dini, Cisco Systems, Inc. / Concordia University, Canada =============================================== -- From marc at let.de Sun May 4 17:34:51 2008 From: marc at let.de (Marc Manthey) Date: Mon, 5 May 2008 00:34:51 +0200 Subject: [NANOG] would ip6 help us safeing energy ? In-Reply-To: <481501E0.3020104@bogus.com> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> Message-ID: <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> evening all , found an related article about the power consumtion saving in ip6. - Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6? http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/ http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf still interested in other links and publications regards Marc -- "Use your imagination not to scare yourself to death but to inspire yourself to life." Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 K?ln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc at kgraff.net blog : http://www.let.de ipv6 http://www.ipsix.org xing : https://www.xing.com/profile/Marc_Manthey From adrian at creative.net.au Sun May 4 17:57:36 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 5 May 2008 06:57:36 +0800 Subject: [NANOG] would ip6 help us safeing energy ? In-Reply-To: <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> Message-ID: <20080504225736.GA21681@skywalker.creative.net.au> On Mon, May 05, 2008, Marc Manthey wrote: > evening all , > > found an related article about the power consumtion saving in ip6. > > - > > Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6? > > http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/ > > http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf I'd seriously be looking at making current -software- run more efficiently before counting ipv6-related power savings. Adrian From joelja at bogus.com Sun May 4 19:59:19 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 04 May 2008 17:59:19 -0700 Subject: [NANOG] would ip6 help us safeing energy ? In-Reply-To: <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> Message-ID: <481E5BE7.5010908@bogus.com> Notwithstanding that fact that keepalives are a huge issue for tiny battery powered devices. There's a false economy in assuming those packets wouldn't have to be sent with IPV6... Marc Manthey wrote: > evening all , > > found an related article about the power consumtion saving in ip6. > > - > > Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6? > > http://www.circleid.com/posts/81072_megawatts_keepalive_ipv6/ > > http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf > > > still interested in other links and publications > > > regards > > Marc > > -- > "Use your imagination not to scare yourself to death > but to inspire yourself to life." > > Les enfants teribbles - research and deployment > Marc Manthey - head of research and innovation > Hildeboldplatz 1a D - 50672 K?ln - Germany > Tel.:0049-221-3558032 > Mobil:0049-1577-3329231 > jabber :marc at kgraff.net > blog : http://www.let.de > ipv6 http://www.ipsix.org > xing : https://www.xing.com/profile/Marc_Manthey > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From randy at psg.com Sun May 4 20:47:49 2008 From: randy at psg.com (Randy Bush) Date: Mon, 05 May 2008 03:47:49 +0200 Subject: [NANOG] would ip6 help us safeing energy ? In-Reply-To: <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> Message-ID: <481E6745.4090007@psg.com> > found an related article about the power consumtion saving in ip6. no, you found an article about bad nat design in a market lacking the ability to stanardize on a clean one. if you look, you can also find statements by the same folk explaining how ipv6 will help prevent car accidents involving falling rocks. yes, i am serious. note that i work very hard on ipv6 deployment. i just don't encourage or support marketing insanity. randy From randy at psg.com Sun May 4 22:00:32 2008 From: randy at psg.com (Randy Bush) Date: Mon, 05 May 2008 05:00:32 +0200 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 In-Reply-To: References: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> Message-ID: <481E7850.6010505@psg.com> > but if the bottom feeding scumsuckers who saw the opportunity now known as > spam, or the ones who saw the opportunity now known as NXDOMAIN remapping, > or the ones who saw the opportunity now known as DDoS for hire, realize that > the next great weakness in the internet's design and protocols is explosive > deaggregation by virtual shill networking, then we can expect business plans > whereby well suited shysters march into MIT, and HP, and so on, offering to > outsource this monetization. "you get half the money but none of the > distraction, all you have to do is renumber or use NAT or IPv6, we'll do > the rest." nothing in recorded human history argues against this occurring. paul, this is not the spanish inquisition or the great crusades. nothing in human history argues against a lot of fantasies and black helicopters. and yes, some of them actually come true, c.f. iraq. but i have a business to run, not a religious crusade. there is no news at eleven, just more work to do. some time back what we now call legacy space was given out under policies which seemed like a good idea at the time. [ interestingly, these policies were similar to the policies being used or considered for ipv6 allocations today, what we later think of as large chunks that may or may not be really well utilized. have you seen the proposal in ripe to give everyone with v4 space a big chunk of v6 space whether they want it or not? ] the people who gave those allocations and the people (or organizations) who received them were not evil, stupid, or greedy. they were just early adopters, incurring the risks and occasional benefits. maybe it benefits arin's desperate search for a post-ipv4-free-pool era business model to cast these allocation holders as evil (see the video of arin's lawyer at nanog and some silly messages on the arin ppml list), with the fantasy that there is enough legacy space that arin can survive with its old business model for an extra year or two. i think of this as analogous to the record companies sending the lawyers out instead of joining the 21st century and getting on the front of the wave. i hope that the result in arin's case is not analogously tragic. arin's legacy registration agreement is quite lopsided, as has been pointed out multiple times. the holder grants and gives up rights and gains little they do not already have. but i am sure there will be some who will sign it. heck, some people click on phishing links. i suggest we focus on how to roll out v6 or give up and get massive natting to work well (yuchhh!) and not waste our time rearranging the deck chairs [0] or characterizing those with chairs as evil. randy --- [0] my wife used to admonish folk to think about those fools on the titanic who declined dessert. From drc at virtualized.org Sun May 4 22:01:09 2008 From: drc at virtualized.org (David Conrad) Date: Sun, 4 May 2008 20:01:09 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481D2F78.6020000@bogus.com> References: <481D290E.6010000@apnic.net> <481D2BF2.9000105@emmanuelcomputerconsulting.com> <481D2F78.6020000@bogus.com> Message-ID: On May 3, 2008, at 8:37 PM, Joel Jaeggli wrote: > William Warren wrote: >> That also doesn't take into account how many /8's are being hoarded >> by >> organizations that don't need even 25% of that space. > which one's would those be? While I wouldn't call it hoarding, can any single (non-ISP) organization actually justify a /8? How many students does MIT have again? > legacy class A address space just isn't that big... There is more legacy space (IANA_Registry + VARIOUS, using Geoff's labels) than all space allocated by the RIRs combined. Regards, -drc From drc at virtualized.org Sun May 4 22:21:28 2008 From: drc at virtualized.org (David Conrad) Date: Sun, 4 May 2008 20:21:28 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 In-Reply-To: <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> References: <1E92AEC6-D120-4FCD-9E94-8B6D4DA4BD8E@daork.net> <70D072392E56884193E3D2DE09C097A9F125@pascal.zaphodb.org> Message-ID: <625578F1-8A82-467A-9E91-6DD9C02F4FC5@virtualized.org> On May 4, 2008, at 11:37 AM, Tomas L. Byrnes wrote: > The artifact of MIT and others > having /8s while the entire Indian subcontinent scrapes for /29s, can > hardly be considered optimal or right. While perhaps intended as hyperbole, this sort of statement annoys me as it demonstrates an ignorance of how address allocation mechanisms work. It may be the case that organizations in India (usually people cite China, but whatever) might "scrape for /29s", but that is not because of a lack of address space at APNIC, but rather policies imposed by the carrier(s)/PTT/government. > It's time for the supposedly > altruistic good guys to do the right thing, and give back the > resources > they are not using, that are sorely needed. "For the good of the Internet" died some while back. There is currently no incentive for anyone with more address space than they need to return that address space. > How about they resell it and > use the money to make getting an education affordable? If you believe this appropriate, I suggest you raise it on ppml at arin.net and see what sort of reaction you get. > The routing prefix problem, OTOH, is an artificial shortage caused by > (mostly one) commercial entities maximizing their bottom line > [...] > Especially if those end-points are relatively stable as to > connectivity, the allocations are non-portable, and you aggregate. A free market doesn't work like that, prefixes aren't stable, and the problem is that you can't aggregate. If you're actually interested in this topic, I might suggest looking at the IRTF RRG working group archives. > IPv4 has enough addresses for every computer on Earth, and then some. Unless you NAT out every bodily orifice, not even close. Regards, -drc From patrick at ianai.net Sun May 4 22:22:19 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 4 May 2008 23:22:19 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: <481D290E.6010000@apnic.net> <481D2BF2.9000105@emmanuelcomputerconsulting.com> <481D2F78.6020000@bogus.com> Message-ID: <71E38CA3-D338-418F-AA1A-721F2836567F@ianai.net> On May 4, 2008, at 11:01 PM, David Conrad wrote: > On May 3, 2008, at 8:37 PM, Joel Jaeggli wrote: >> William Warren wrote: >>> That also doesn't take into account how many /8's are being hoarded >>> by >>> organizations that don't need even 25% of that space. >> which one's would those be? > > While I wouldn't call it hoarding, can any single (non-ISP) > organization actually justify a /8? How many students does MIT have > again? MIT enrolls more graduate students (approximately 6,000 in total) than undergraduates (approximately 4,000). Let's assume 2 staff/faculty per student (don't we wish :). So that would be 30K total. Let's further assume 100 IP addresses per student to deal with laptops, server, other computers, routers, etc. We're now at 330K. That's no where near 25% of the /8 they have. Good thing they are announcing a /15, /16, and a /24* originated from their ASN too. Just so we are clear, I have no idea how many servers, computers, or other things MIT might have to justify a /8, /15, /16, and /24. I'm just pointing out the number of students alone clearly doesn't justify their IP space. UCLA, where the Internet was invented, only has 5x/16 + 2x/24. Obviously they're so much smarter they can utilize IP space better. (No, I'm not saying that just 'cause I went to UCLA. :) -- TTFN, patrick * 18.0.0.0 * 128.30.0.0/15 * 128.52.0.0 * 192.233.33.0 >> legacy class A address space just isn't that big... > > There is more legacy space (IANA_Registry + VARIOUS, using Geoff's > labels) than all space allocated by the RIRs combined. > > Regards, > -drc > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From deepak at ai.net Sun May 4 23:32:35 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 05 May 2008 00:32:35 -0400 Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: References: <20080503145255.W10017@sprockets.gibbard.org> Message-ID: <481E8DE3.3030409@ai.net> > note that joe's example brings up the interface before starting the name > server program, and bringing it down if the name server program exits. > this presumes that the name server will start very quickly, and that while > running, it is healthy. since i've seen name server programs be unhealthy > while running, and/or take a long time to start, i'm now considering an > outboard shell script that runs some kind of DNS query and decides, based > on the result, whether to bring the dedicated loopback interface up or down. All deference to this model, we've all seen these kinds of problems with name servers. We *can* be certain that bringing a loopback interface up or down takes almost no time (with the implied effect to a speaker like Quagga). There is *no* reason with a sufficiently deep name server depth (depends on your load) that your monitoring script should *need* to hurry to test this condition. Every 5-10 or even 15 minutes to see if its eligible to bring up, more frequently to see if its eligible to take down. This also reduces oscillation. This means, bring up/kill off your name server in one cronjob (automatically taking the interface down at the end or after a kill), and monitor/talk to the interface in another (up function and sometimes the down). You'll be much happier. Deepak Jain AiNET From iljitsch at muada.com Mon May 5 03:07:12 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 5 May 2008 10:07:12 +0200 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: <20080504225736.GA21681@skywalker.creative.net.au> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> <20080504225736.GA21681@skywalker.creative.net.au> Message-ID: On 5 mei 2008, at 0:57, Adrian Chadd wrote: > I'd seriously be looking at making current -software- run more > efficiently > before counting ipv6-related power savings. Good luck with that. Obviously there is a lot to be gained at that end, but that doesn't mean we should ignore power use in the network. One thing that could help here is to increase the average packet size. Whenever I've looked, this has always hovered around 500 bytes for internet traffic. If we can get jumboframes widely deployed, it should be doable to double that. Since most work in routers and switches is per-packet rather than per-bit, this has the potential to save a good amount of power. Now obviously this only works in practice if routers and switches actually use less power when there are fewer packets, which is not a given. It helps even more if the maximum throughput isn't based on 64- byte packets. Why do people demand that, anyway? The only thing I can think of is DoS attacks. But that can be solved by only allowing end- users to send an average packet size of 500 (or 250, or whatever) bytes. So if you have a 10 Mbps connection you don't get to send 14000 64-byte packets per second, but a maximum of 2500 packets per second. So with 64-byte packets you only get to use 1.25 Mbps. I'm guessing having a 4x10Gbps line card that "only" does 14 Mpps total rather than 14 Mpps per port would be a good deal cheaper. Obviously if you're a service provider with a customer that sends 10 Gbps worth of VoIP you can only use one of those 4 ports but somehow, I'm thinking few people use 10 Gbps worth of VoIP... Iljitsch PS. Am I the only one who is annoyed by the reduction in usable subject space by the superfluous [NANOG]? From iljitsch at muada.com Mon May 5 03:55:31 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 5 May 2008 10:55:31 +0200 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: Message-ID: On 2 mei 2008, at 20:51, Mike Leber wrote: > Since nobody mentioned it yet, there are now less than 1000 days > projected > until IPv4 exhaustion: > http://www.potaroo.net/tools/ipv4/ Unfortunately that won't load for me over IPv6, path MTU black hole... > ps. 1000 days assumes no rush, speculation, or hoarding. Do people do > that? Since the only people who can get really large blocks of IP addresses are the people who already have really large blocks of IP addresses, the eventual distribution of large blocks won't differ much depending on whether there will be a rush or not. Obviously the 99% of requests that use up only 17% of the space each year are of no importance in the grand scheme of things. I was about to write that 1000 days is too optimistic/pessimistic, but (after trying to compensate for ARIN's strange book keeping practices) it looks like in 2006, 163 million addresses were given out, 196 in 2007. If the next few years also see an increase of 20% in yearly address use, then 1000 days sounds about right. That means we'd have to use up 235 million addresses this year, while so far we're at 73 million, which puts us on track for 219 million. So maybe it will be 1050 days (which leaves us exactly a million addresses per day). BTW, about the India thing: they should take their cue from China, which only had a few million addresses at the turn of the century but is now in the number two spot at ~ 150 million addresses. (Comparison: the US holds 1.4 billion, India 15 million, just behind Sweden which has 17 million.) China is now the biggest user of new address space. http://www.bgpexpert.com/addressespercountry.php http://www.bgpexpert.com/ianaglobalpool.php http://www.bgpexpert.com/addrspace2007.php (Make it "www.ipv4.bgpexpert..." if you have trouble reaching the site over v6.) From scg at gibbard.org Mon May 5 05:25:51 2008 From: scg at gibbard.org (Steve Gibbard) Date: Mon, 5 May 2008 03:25:51 -0700 (PDT) Subject: [NANOG] Did Youtube not pay their domain bill? In-Reply-To: References: <20080503145255.W10017@sprockets.gibbard.org> Message-ID: <20080505031359.R92749@sprockets.gibbard.org> On Sun, 4 May 2008, Paul Vixie wrote: > scg at gibbard.org (Steve Gibbard) writes: >> The right solution is to design the anycast servers to be as sure as >> possible that the route will go away when you want it gone, but to have >> multiple non-interdependent anycast clouds in the NS records for each >> zone. If the local node in one cloud does fail improperly, something will >> still be responding on the other cloud's IP address. > > the need for multiple independent anycast clouds is an RFC 2182 topic, but > joe's innovation both in ISC-TN-2004-1 and in his earlier ISC-TN-2003-1 (see > is that if each anycast cluster > is really several servers, each using OSPF ECMP, then you can lose a server > and still have that cluster advertising the route upstream, and only when you > lose all servers in a cluster will that route be withdrawn. This is getting into minutia, but using multipath BGP will also accomplish this without having to get the route from OSPF to BGP. This simplifies things a bit, and makes it safer to have the servers and routers under independent control. But yes, Joe's ISC TechNote is an excellent document, and was a big help in figuring out how to set this up a few years ago. -Steve From vixie at isc.org Mon May 5 11:07:03 2008 From: vixie at isc.org (Paul Vixie) Date: 05 May 2008 16:07:03 +0000 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <20080505031359.R92749@sprockets.gibbard.org> References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: scg at gibbard.org (Steve Gibbard) writes: > > ... if each anycast cluster is really several servers, each using OSPF > > ECMP, then you can lose a server and still have that cluster advertising > > the route upstream, and only when you lose all servers in a cluster will > > that route be withdrawn. > > This is getting into minutia, but using multipath BGP will also accomplish > this without having to get the route from OSPF to BGP. This simplifies > things a bit, and makes it safer to have the servers and routers under > independent control. i think the minutia is good, especially after a long weekend of layer 9 threads. my limited understanding of multipath bgp is that it's a global config knob for routers, not a per peer knob, and that it has disasterous consequences if the router is also carrying a full table and has many peers. also, in OSPF, ECMP is not optional, even though most BSD-based software routers don't implement it yet (since multipath routing is very new.) so, we have been using OSPF for this, it just works out better. i dearly do wish that something like a "service advertisement protocol" existed, that did what OSPF ECMP did, without a router operator effectively giving every customer the ability to inject other customer routes, or default routes. in that sense, i agree with your "safer... independent control" assertion. > But yes, Joe's ISC TechNote is an excellent document, and was a big help > in figuring out how to set this up a few years ago. and now for something completely different -- where in the interpipes could a document like that have been published, vs. ISC's web site? the amount of red tape and delay involved in Usenix or IETF or IEEE or ACM are vastly more than most smart ops people are willing to put in. where is the light / middle weight class, or is every organization or person who wants to publish this kind of thing going to continue to have the exclusive and bad choice of "blog it, or write an article for ;login:/ACM-Queue/Circle-ID, or write an academic paper and wait ten months"? isn't this a job for... NANOG? -- Paul Vixie From iljitsch at muada.com Mon May 5 11:22:54 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 5 May 2008 18:22:54 +0200 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: <31989.1210000443@turing-police.cc.vt.edu> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> <20080504225736.GA21681@skywalker.creative.net.au> <31989.1210000443@turing-police.cc.vt.edu> Message-ID: <6DC81747-86D4-47EF-9339-B7FDFB7A2BB1@muada.com> On 5 mei 2008, at 17:14, Valdis.Kletnieks at vt.edu wrote: >> Obviously there is a lot to be gained at that end, but that doesn't >> mean we should ignore power use in the network. One thing that could >> help here is to increase the average packet size. Whenever I've >> looked, this has always hovered around 500 bytes for internet >> traffic. >> If we can get jumboframes widely deployed, > You don't need jumboframes, you just need to have working Path MTU > Discovery. > Or hand-nail your MSS to 1400 or something. But if you don't do > either of > those, you basically need to assume that the minimum MTU is 512 or so. ??? Very few people out there use an MTU significantly below 1500 bytes. A 1500-byte MTU will give you an _average_ packet size of ~1000 on long- lived TCP flows because there is one tiny ACK for every two full size data segments. (In the other direction, but let's not make things too complicated right now.) The reason that the average is more like half that is that on short interactions the last packet is shorter, and of course there's stuff like gaming, VoIP, DNS that simply uses small packets. >> Now obviously this only works in practice if routers and switches >> actually use less power when there are fewer packets, which is not a >> given. It helps even more if the maximum throughput isn't based on >> 64- >> byte packets. Why do people demand that, anyway? > Max throughput, or max packets/sec? Max data throughput happens at > the > *other* end, with 9K mobygrams... Right, with 9k packets you only need to send around 13 kpps to fill up 1 Gbps, with 1500 bytes it's some 83 kpps. Helps in overhead, TCP performance and (potentially) power use. But someone who is sending a 200 byte packet today isn't going to send something larger when her MTU is increased from 1500 to 9000 so the _average_ won't increase by a factor 6. >> PS. Am I the only one who is annoyed by the reduction in usable >> subject space by the superfluous [NANOG]? > Those of us who are *really* annoyed by stuff like that usually cook > up a procmail recipe to strip it out.. :) I got my procmail set up so it mostly does what I need right now, better not mess with it... From babydr at baby-dragons.com Mon May 5 12:01:07 2008 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Mon, 5 May 2008 09:01:07 -0800 (AKDT) Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: Hello All , On Mon, 5 May 2008, Paul Vixie wrote: > scg at gibbard.org (Steve Gibbard) writes: ...snip... >> But yes, Joe's ISC TechNote is an excellent document, and was a big help >> in figuring out how to set this up a few years ago. > > and now for something completely different -- where in the interpipes could > a document like that have been published, vs. ISC's web site? the amount > of red tape and delay involved in Usenix or IETF or IEEE or ACM are vastly > more than most smart ops people are willing to put in. where is the light / > middle weight class, or is every organization or person who wants to publish > this kind of thing going to continue to have the exclusive and bad choice of > "blog it, or write an article for ;login:/ACM-Queue/Circle-ID, or write an > academic paper and wait ten months"? isn't this a job for... NANOG? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hear , Hear ! I second the motion . Sorry about the 1-2 line response , But I beleive it was needed . Twyl , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ From dga at cs.cmu.edu Mon May 5 12:16:29 2008 From: dga at cs.cmu.edu (David Andersen) Date: Mon, 5 May 2008 13:16:29 -0400 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: <01D1836E-D3B2-411E-A7FC-8C04CE053897@cs.cmu.edu> On May 5, 2008, at 12:07 PM, Paul Vixie wrote: > >> But yes, Joe's ISC TechNote is an excellent document, and was a big >> help >> in figuring out how to set this up a few years ago. > > and now for something completely different -- where in the > interpipes could > a document like that have been published, vs. ISC's web site? the > amount > of red tape and delay involved in Usenix or IETF or IEEE or ACM are > vastly > more than most smart ops people are willing to put in. where is the > light / > middle weight class, or is every organization or person who wants to > publish > this kind of thing going to continue to have the exclusive and bad > choice of > "blog it, or write an article for ;login:/ACM-Queue/Circle-ID, or > write an > academic paper and wait ten months"? isn't this a job for... NANOG? If you're asking seriously: arXiv.org is a pretty reasonable candidate for less-formal but more-public publication of things like Joe's TechNote. It's taken off seriously in physics, but I don't know anyone who uses it seriously for computer science stuff. Probably because our conferences have much faster turnaround than most discipline's journals do. But arXiv exists, it'll probably be around for a while, and it provides a reasonable starting point for hosting and citing the documents... -Dave From cgrundemann at gmail.com Mon May 5 12:18:56 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 5 May 2008 11:18:56 -0600 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: <443de7ad0805051018y57e7e009y2e8ed65bb5b9fd80@mail.gmail.com> On Mon, May 5, 2008 at 10:07 AM, Paul Vixie wrote: > scg at gibbard.org (Steve Gibbard) writes: > > > > ... if each anycast cluster is really several servers, each using OSPF > > > ECMP, then you can lose a server and still have that cluster advertising > > > the route upstream, and only when you lose all servers in a cluster will > > > that route be withdrawn. > > > > This is getting into minutia, but using multipath BGP will also accomplish > > this without having to get the route from OSPF to BGP. This simplifies > > things a bit, and makes it safer to have the servers and routers under > > independent control. > > i think the minutia is good, especially after a long weekend of layer 9 > threads. my limited understanding of multipath bgp is that it's a global > config knob for routers, not a per peer knob, and that it has disasterous > consequences if the router is also carrying a full table and has many peers. I am not sure what routers specifically are being discussed here, but in JunOS you can enable multipath on a global, group or single neighbor level, possibly eliminating your concern... > also, in OSPF, ECMP is not optional, even though most BSD-based software > routers don't implement it yet (since multipath routing is very new.) so, > we have been using OSPF for this, it just works out better. i dearly do > wish that something like a "service advertisement protocol" existed, that > did what OSPF ECMP did, without a router operator effectively giving every > customer the ability to inject other customer routes, or default routes. > in that sense, i agree with your "safer... independent control" assertion. > > > But yes, Joe's ISC TechNote is an excellent document, and was a big help > > in figuring out how to set this up a few years ago. > > and now for something completely different -- where in the interpipes could > a document like that have been published, vs. ISC's web site? the amount > of red tape and delay involved in Usenix or IETF or IEEE or ACM are vastly > more than most smart ops people are willing to put in. where is the light / > middle weight class, or is every organization or person who wants to publish > this kind of thing going to continue to have the exclusive and bad choice of > "blog it, or write an article for ;login:/ACM-Queue/Circle-ID, or write an > academic paper and wait ten months"? isn't this a job for... NANOG? > -- > Paul Vixie > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Chris Grundemann www.linkedin.com/in/cgrundemann From tme at multicasttech.com Mon May 5 12:21:49 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 5 May 2008 13:21:49 -0400 Subject: [NANOG] Was Burma off the air due to the Cyclone ? Message-ID: After a request, I can confirm that Burma / Myanmar dropped off the BGP tables here over the weekend : bgp.sum.May_2_00:07:00_EDT_2008: AS 9988 MPT- AP | 3 hops | as path 174 2914 9988 bgp.sum.May_2_00:07:00_EDT_2008: AS 18399 BAGAN-TRANSIT- AS | 4 hops | as path 174 2914 9988 18399 bgp.sum.May_2_06:07:01_EDT_2008: AS 9988 MPT- AP | 3 hops | as path 174 2914 9988 bgp.sum.May_2_06:07:01_EDT_2008: AS 18399 BAGAN-TRANSIT- AS | 4 hops | as path 174 2914 9988 18399 bgp.sum.May_2_12:07:00_EDT_2008: AS 9988 MPT- AP | 3 hops | as path 174 2914 9988 bgp.sum.May_2_12:07:00_EDT_2008: AS 18399 BAGAN-TRANSIT- AS | 4 hops | as path 174 2914 9988 18399 bgp.sum.May_2_18:07:00_EDT_2008: AS 9988 MPT- AP | 5 hops | as path 174 7473 7700 9881 9988 bgp.sum.May_5_00:07:00_EDT_2008: AS 9988 MPT- AP | 4 hops | as path 174 2914 9304 9988 bgp.sum.May_5_06:07:01_EDT_2008: AS 9988 MPT- AP | 4 hops | as path 174 2914 9304 9988 bgp.sum.May_5_06:07:01_EDT_2008: AS 18399 BAGAN-TRANSIT- AS | 5 hops | as path 174 2914 9304 9988 18399 bgp.sum.May_5_10:37:42_EDT_2008: AS 9988 MPT- AP | 4 hops | as path 174 2914 9304 9988 bgp.sum.May_5_10:37:42_EDT_2008: AS 18399 BAGAN-TRANSIT- AS | 5 hops | as path 174 2914 9304 9988 18399 bgp.sum.May_5_12:07:01_EDT_2008: AS 9988 MPT- AP | 4 hops | as path 174 2914 9304 9988 bgp.sum.May_5_12:07:01_EDT_2008: AS 18399 BAGAN-TRANSIT- AS | 5 hops | as path 174 2914 9304 9988 18399 and was missing totally on May 3 and 4. Note that the path has changed, with 7700 SINGTEL-DVBIP-AS-AP [NSK1-AP] {Singapore 588397, SG} SINGAPORE TELECOMMUNICATIONS LTD 9304 HUTCHISON-AS-AP [IH17-AP] {HONG KONG, HK} Hutchison Telecom (HK) - Mobile, pager, fixed network now being involved. Is it possible that the Cyclone on Saturday took Burma off of the air ? http://news.bbc.co.uk/2/hi/asia-pacific/7384041.stm Regards Marshall From tme at multicasttech.com Mon May 5 12:28:49 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 5 May 2008 13:28:49 -0400 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <01D1836E-D3B2-411E-A7FC-8C04CE053897@cs.cmu.edu> References: <20080505031359.R92749@sprockets.gibbard.org> <01D1836E-D3B2-411E-A7FC-8C04CE053897@cs.cmu.edu> Message-ID: <75F96A37-6777-4358-AAF3-0E772B56E48D@multicasttech.com> On May 5, 2008, at 1:16 PM, David Andersen wrote: > On May 5, 2008, at 12:07 PM, Paul Vixie wrote: >> >>> But yes, Joe's ISC TechNote is an excellent document, and was a big >>> help >>> in figuring out how to set this up a few years ago. >> >> and now for something completely different -- where in the >> interpipes could >> a document like that have been published, vs. ISC's web site? the >> amount >> of red tape and delay involved in Usenix or IETF or IEEE or ACM are >> vastly >> more than most smart ops people are willing to put in. where is the >> light / >> middle weight class, or is every organization or person who wants to >> publish >> this kind of thing going to continue to have the exclusive and bad >> choice of >> "blog it, or write an article for ;login:/ACM-Queue/Circle-ID, or >> write an >> academic paper and wait ten months"? isn't this a job for... NANOG? > > If you're asking seriously: arXiv.org is a pretty reasonable > candidate for less-formal but more-public publication of things like > Joe's TechNote. > > It's taken off seriously in physics, but I don't know anyone who uses > it seriously for computer science stuff. There are certain types of networking problems where arxiv gets decent traffic; I get about 1 paper per day on networking and cryptography. At any rate, I would encourage people to use it and this seems like a possible appropriate paper for it. Regards Marshall > Probably because our > conferences have much faster turnaround than most discipline's > journals do. But arXiv exists, it'll probably be around for a while, > and it provides a reasonable starting point for hosting and citing the > documents... > > -Dave > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From smb at cs.columbia.edu Mon May 5 12:59:20 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 5 May 2008 17:59:20 +0000 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: <20080505175920.13e015b9@cs.columbia.edu> On 05 May 2008 16:07:03 +0000 Paul Vixie wrote: > > > But yes, Joe's ISC TechNote is an excellent document, and was a big > > help in figuring out how to set this up a few years ago. > > and now for something completely different -- where in the interpipes > could a document like that have been published, vs. ISC's web site? > the amount of red tape and delay involved in Usenix or IETF or IEEE > or ACM are vastly more than most smart ops people are willing to put > in. where is the light / middle weight class, or is every > organization or person who wants to publish this kind of thing going > to continue to have the exclusive and bad choice of "blog it, or > write an article for ;login:/ACM-Queue/Circle-ID, or write an > academic paper and wait ten months"? isn't this a job for... NANOG? I did some checking on this topic a few years ago. The consensus among the people I talked to was that NANOG itself seemed to generate too little that was publishable in a formal way to warrant a specific mechanism. A web site like arxiv is good for some stuff. But -- should there be a link from nanog.org to operational content? Should nanog.org have its own archive? Should there be a peer review process? If not, what should the criteria be for an "official" note of the paper? --Steve Bellovin, http://www.cs.columbia.edu/~smb From rand at meridian-enviro.com Mon May 5 13:08:05 2008 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Mon, 05 May 2008 13:08:05 -0500 Subject: [NANOG] Strange network behaviour Message-ID: <8763ts1v5m.wl%rand@meridian-enviro.com> We had a very strange problem today. Two of our hosts could not reach a server, but only those two hosts. All of our other hosts could reach those servers fine. (OK, I didn't try ALL of our IPs, but the half dozen I did try worked fine.) I checked all of our firewalls and routers, and everywhere I looked all of the traffic was exiting our network just fine. I saw on our edge routers the traffic going out, just no traffic back to the two hosts in question. (We had good bidirectional traffic to all of our other hosts.) And the two hosts in question were only having problems connecting to ftp.agnewsonline.com. Lets start with a traceroute from a working host, the orginating host is 12.192.92.14: [~]% traceroute -I ftp.agnewsonline.com traceroute to agnewsonline.com (64.46.45.226), 64 hops max, 60 byte packets 1 12.192.92.3 (12.192.92.3) 0.257 ms 0.171 ms 0.163 ms 2 pluto-0 (12.192.93.13) 0.401 ms 0.296 ms 0.294 ms 3 ixion-att (12.192.93.244) 1.260 ms 0.463 ms 1.116 ms 4 12.87.125.249 (12.87.125.249) 14.838 ms 9.314 ms 9.755 ms 5 tbr2.cgcil.ip.att.net (12.122.99.122) 24.528 ms 24.788 ms 23.009 ms 6 ggr2.cgcil.ip.att.net (12.123.6.69) 22.362 ms 23.410 ms 22.335 ms 7 192.205.33.186 (192.205.33.186) 23.448 ms 24.074 ms 29.405 ms 8 ae-31-53.ebr1.Chicago1.Level3.net (4.68.101.94) 22.800 ms 32.598 ms 36.093 ms 9 ae-68.ebr3.Chicago1.Level3.net (4.69.134.58) 23.446 ms 21.599 ms 34.060 ms 10 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 61.517 ms 57.482 ms 56.606 ms 11 ae-2.ebr2.Seattle1.Level3.net (4.69.132.53) 96.484 ms 114.264 ms 96.984 ms 12 ae-23-52.car3.Seattle1.Level3.net (4.68.105.36) 91.295 ms 88.700 ms 89.705 ms 13 BIG-PIPE-IN.car3.Seattle1.Level3.net (4.71.152.26) 90.053 ms 90.511 ms 92.072 ms 14 rc1wh-pos14-0.vc.shawcable.net (66.163.76.1) 90.062 ms 93.489 ms 90.757 ms 15 rc2wh-pos0-15-2-0.vc.shawcable.net (66.163.69.181) 96.527 ms 91.743 ms 97.254 ms 16 rd1ht-tge1-1-1.ok.shawcable.net (66.163.77.18) 101.412 ms 114.160 ms 100.530 ms 17 ra1ht-ge3-1.ok.shawcable.net (66.163.72.134) 105.651 ms 101.336 ms 101.628 ms 18 rx0ht-rack-force-2.ok.bigpipeinc.com (64.251.64.50) 111.960 ms 101.535 ms 116.136 ms 19 rf1.01.rackforce.net (69.10.128.198) 583.192 ms 491.170 ms 598.406 ms 20 64.46.45.226 (64.46.45.226) 110.207 ms 108.718 ms 107.279 ms A traceroute from one of the hosts that doesn't work would reach ae-3.ebr2.Denver1.Level3.net but go no further. I then tried pinging the routers I couldn't reach. I could not ping: ae-3.ebr2.Denver1.Level3.net (4.69.132.61) ae-2.ebr2.Seattle1.Level3.net (4.69.132.53) ae-23-52.car3.Seattle1.Level3.net (4.68.105.36) BIG-PIPE-IN.car3.Seattle1.Level3.net (4.71.152.26) but when I started pinging rc1wh-pos14-0.vc.shawcable.net (66.163.76.1) not only did I start getting responses, but everything started working to ftp.agnewsonline.com too, but just from that host. It really seemed that pinging that router some how fixed my problem. Well, I'm not sure I really believed that, but I still had another host that couldn't reach ftp.agnewsonline.com, so on that host I started a ping. I'll add my comments to describe what I was doing in another window in /* */: [~]% ping ftp.agnewsonline.com PING agnewsonline.com (64.46.45.226): 56 data bytes /* At this point in another window I started a nother ping: */ /* ping 66.163.76.1 and immediately this ping started working ... */ 64 bytes from 64.46.45.226: icmp_seq=18 ttl=108 time=104.617 ms 64 bytes from 64.46.45.226: icmp_seq=19 ttl=108 time=105.775 ms 64 bytes from 64.46.45.226: icmp_seq=20 ttl=108 time=101.569 ms --- agnewsonline.com ping statistics --- 22 packets transmitted, 3 packets received, 86% packet loss round-trip min/avg/max/stddev = 101.569/103.987/105.775/1.774 ms It was like I threw a switch. The single outbound ICMP packet to rc1wh-pos14-0.vc.shawcable.net (66.163.76.1) fixed everything for that host. I was wondering if anybody has any clue what might be going on. I've never experienced a problem like this before. From stu at spacehopper.org Mon May 5 13:15:17 2008 From: stu at spacehopper.org (Stuart Henderson) Date: Mon, 5 May 2008 18:15:17 +0000 (UTC) Subject: [NANOG] OSPF minutia, and, technote publication venues References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: On 2008-05-05, Paul Vixie wrote: > also, in OSPF, ECMP is not optional, even though most BSD-based software > routers don't implement it yet (since multipath routing is very new.) Some readers might be interested to know the exception to "most" here; the OpenBSD kernel has supported ECMP for the last couple of releases (activated by setting a sysctl); in the most recent release ECMP support was also added to ospfd. From rdobbins at cisco.com Mon May 5 13:19:36 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 6 May 2008 01:19:36 +0700 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <20080505175920.13e015b9@cs.columbia.edu> References: <20080505031359.R92749@sprockets.gibbard.org> <20080505175920.13e015b9@cs.columbia.edu> Message-ID: <9E9DAF7A-5F78-4B5F-B5E5-8782443CDFDC@cisco.com> On May 6, 2008, at 12:59 AM, Steven M. Bellovin wrote: > If not, what should the criteria be for an "official" note of the > paper? Perhaps it's an oversimplification, but can't those who wish to publish such information simply deliver their papers at a NANOG meeting (after acceptance by the Program Committee, which acts as a gate), and then the NANOG folks post the documents along with any slides and the VoDs of their presentations, in the usual fashion? ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From smb at cs.columbia.edu Mon May 5 13:38:07 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 5 May 2008 18:38:07 +0000 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <9E9DAF7A-5F78-4B5F-B5E5-8782443CDFDC@cisco.com> References: <20080505031359.R92749@sprockets.gibbard.org> <20080505175920.13e015b9@cs.columbia.edu> <9E9DAF7A-5F78-4B5F-B5E5-8782443CDFDC@cisco.com> Message-ID: <20080505183807.6738f844@cs.columbia.edu> On Tue, 6 May 2008 01:19:36 +0700 Roland Dobbins wrote: > > On May 6, 2008, at 12:59 AM, Steven M. Bellovin wrote: > > > If not, what should the criteria be for an "official" note of the > > paper? > > > Perhaps it's an oversimplification, but can't those who wish to > publish such information simply deliver their papers at a NANOG > meeting (after acceptance by the Program Committee, which acts as a > gate), and then the NANOG folks post the documents along with any > slides and the VoDs of their presentations, in the usual fashion? > That's certainly one very good answer. Are there others? --Steve Bellovin, http://www.cs.columbia.edu/~smb From rand at meridian-enviro.com Mon May 5 14:28:03 2008 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Mon, 05 May 2008 14:28:03 -0500 Subject: [NANOG] Strange network behaviour In-Reply-To: <8763ts1v5m.wl%rand@meridian-enviro.com> References: <8763ts1v5m.wl%rand@meridian-enviro.com> Message-ID: <87ve1szh30.wl%rand@meridian-enviro.com> In the popular tradition of replying to my own post ... It seems that this problem started right around the time I changed our BGP configuration. I did: config term route-map att_out permit 9999 set as-path prepend 19317 19317 exit clear ip bgp 12.87.125.249 out This change was to increase our prepending of our own AS path from 1 to two. It was: set as-path prepend 19317 And we /could/ have had another host with a similar problem but with a different end point, this time in Canada, and the (outbound) route to our Canadian server does not transit either Level3 or Shaw cable. We did not identify exactly when it started working again, we were poking around this problem and then happened to check and it was working. It is *possible*, but by no means confirmed, that a traceroute allowed to go through all its timeouts to the Canadian server may have also switched that problem off too. Doug "Still searching for answers" Rand. From deepak at ai.net Mon May 5 14:37:23 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 05 May 2008 15:37:23 -0400 Subject: [NANOG] Strange network behaviour In-Reply-To: <87ve1szh30.wl%rand@meridian-enviro.com> References: <8763ts1v5m.wl%rand@meridian-enviro.com> <87ve1szh30.wl%rand@meridian-enviro.com> Message-ID: <481F61F3.4050903@ai.net> Did your inbound path change as a result? Sounds like a path asymmetry issue might be involved. Douglas K. Rand wrote: > In the popular tradition of replying to my own post ... > > It seems that this problem started right around the time I changed our > BGP configuration. I did: > > config term > route-map att_out permit 9999 > set as-path prepend 19317 19317 > exit > clear ip bgp 12.87.125.249 out > > This change was to increase our prepending of our own AS path from 1 > to two. It was: set as-path prepend 19317 > > And we /could/ have had another host with a similar problem but with a > different end point, this time in Canada, and the (outbound) route to > our Canadian server does not transit either Level3 or Shaw cable. > > We did not identify exactly when it started working again, we were > poking around this problem and then happened to check and it was > working. It is *possible*, but by no means confirmed, that a > traceroute allowed to go through all its timeouts to the Canadian > server may have also switched that problem off too. > > > Doug "Still searching for answers" Rand. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > From paul at vix.com Mon May 5 14:43:29 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 05 May 2008 19:43:29 +0000 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: Your message of "Mon, 05 May 2008 17:59:20 GMT." <20080505175920.13e015b9@cs.columbia.edu> References: <20080505031359.R92749@sprockets.gibbard.org> <20080505175920.13e015b9@cs.columbia.edu> Message-ID: <35812.1210016609@sa.vix.com> > ... > A web site like arxiv is good for some stuff. But -- should there be a > link from nanog.org to operational content? Should nanog.org have > its own archive? Should there be a peer review process? If not, what > should the criteria be for an "official" note of the paper? > > --Steve Bellovin, http://www.cs.columbia.edu/~smb i wouldn't want to see a full academia-style peer review process, since that problem is pretty well solved elsewhere, and we're not having that problem. but a nanog-style peer review process, where the nanog-pc acts as the judge of how a technote was received by the mailing list, might work. such that if nanog-pc puts their stamp of approval on it, the connotation would be "more than one set of eyes has been laid on this, and it's not totally worthless." i say nanog-like because it's a new trail to blaze based on nanog's culture which, while often hard to cope with, has some innovative, genuine strengths. From vixie at isc.org Mon May 5 14:52:03 2008 From: vixie at isc.org (Paul Vixie) Date: 05 May 2008 19:52:03 +0000 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <20080505183807.6738f844@cs.columbia.edu> References: <20080505183807.6738f844@cs.columbia.edu> Message-ID: smb at cs.columbia.edu ("Steven M. Bellovin") writes: > > > If not, what should the criteria be for an "official" note of the paper? > > > > Perhaps it's an oversimplification, but can't those who wish to publish > > such information simply deliver their papers at a NANOG meeting (after > > acceptance by the Program Committee, which acts as a gate), and then > > the NANOG folks post the documents along with any slides and the VoDs > > of their presentations, in the usual fashion? > > That's certainly one very good answer. Are there others? > > --Steve Bellovin, http://www.cs.columbia.edu/~smb i think that's a good first tier, but there's still delay and congestion in that path. delay, because nanog meetings only happen N times per year, so an idea may have to wait months before it's widely circulated. congestion, because nanog meetings are of fixed duration and there is, and has to be, competition for the slots, to make the meeting interesting, keep quality high. as a second tier, if a technote draft could be sent to nanog-pc at any time, and the readable ones sent to nanog@ (at a maximum of one per week, so there would still be some quality-control related congestion, and rate limiting), and if the nanog-pc could then use mailing list feedback to judge whether the technote deserved to be given a number and put on www.nanog.org somewhere, we could be doing something really interesting with the expertise assembled here. -- Paul Vixie From mike at reachme.com Mon May 5 14:56:38 2008 From: mike at reachme.com (Mike Fedyk) Date: Mon, 5 May 2008 12:56:38 -0700 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: Message-ID: <036801c8aeea$2166e1b0$cb998647@ws20031> > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] > think of is DoS attacks. But that can be solved by only allowing end- > users to send an average packet size of 500 (or 250, or whatever) > bytes. So if you have a 10 Mbps connection you don't get to > send 14000 > 64-byte packets per second, but a maximum of 2500 packets per > second. > So with 64-byte packets you only get to use 1.25 Mbps. You have just cut out the VoIP industry, TCP setup, IM or most types of real-time services on the Internet. > PS. Am I the only one who is annoyed by the reduction in usable > subject space by the superfluous [NANOG]? > Yes you are the only one. ;) From iljitsch at muada.com Mon May 5 15:02:54 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 5 May 2008 22:02:54 +0200 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: <036801c8aeea$2166e1b0$cb998647@ws20031> References: <036801c8aeea$2166e1b0$cb998647@ws20031> Message-ID: On 5 mei 2008, at 21:56, Mike Fedyk wrote: >> So if you have a 10 Mbps connection you don't get to >> send 14000 64-byte packets per second, but a maximum of 2500 >> packets per >> second. So with 64-byte packets you only get to use 1.25 Mbps. > You have just cut out the VoIP industry, TCP setup, IM or most types > of > real-time services on the Internet. Of course not. Like I said, as an average end-user with 10 Mbps you get to send a maximum of 2500 packets per second. That's plenty to do VoIP, set up TCP sessions or do IM. You just don't get to send the full 10 Mbps at this size. From rand at meridian-enviro.com Mon May 5 15:23:25 2008 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Mon, 05 May 2008 15:23:25 -0500 Subject: [NANOG] Strange network behaviour In-Reply-To: <481F61F3.4050903@ai.net> References: <8763ts1v5m.wl%rand@meridian-enviro.com> <87ve1szh30.wl%rand@meridian-enviro.com> <481F61F3.4050903@ai.net> Message-ID: <87tzhczeiq.wl%rand@meridian-enviro.com> > Did your inbound path change as a result? Yes, I was trying to re-balance our inbound traffic a bit better. The route-map change resulted in about 30% of our traffic coming in via our other provider. The change was made around 16:00 (CDT) last Friday, about 72 hours before this problem was brought to my attention. > Sounds like a path asymmetry issue might be involved. But why would the problem last almost 72 hours and be solved by a single ICMP packet to a particular router? And why would only two of our hosts be affected while all of our other systems work just fine? I don't mean to whine, really! And I really don't mean to disagree, I'm no expert in this stuff. I just don't understand what seems like a very fine grained problem. From niels=nanog at bakker.net Mon May 5 17:57:40 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Tue, 6 May 2008 00:57:40 +0200 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: <6DC81747-86D4-47EF-9339-B7FDFB7A2BB1@muada.com> References: <3A9B94EE-053E-48F2-ADB1-AFAD13BDBD86@let.de> <481501E0.3020104@bogus.com> <0C545E8C-0D94-45AC-8FAF-7941440E4D52@let.de> <20080504225736.GA21681@skywalker.creative.net.au> <31989.1210000443@turing-police.cc.vt.edu> <6DC81747-86D4-47EF-9339-B7FDFB7A2BB1@muada.com> Message-ID: <20080505225740.GC3285@burnout.tpb.net> * iljitsch at muada.com (Iljitsch van Beijnum) [Mon 05 May 2008, 10:09 CEST]: > PS. Am I the only one who is annoyed by the reduction in usable > subject space by the superfluous [NANOG]? No, and I'm just as annoyed by the (non-McQ) footer with superfluous information attached to each mail. On 5 mei 2008, at 17:14, Valdis.Kletnieks at vt.edu wrote: > Those of us who are *really* annoyed by stuff like that usually cook > up a procmail recipe to strip it out.. :) That will only lead to duplicates of "Re: " (before and after the tag) in the Subject, I'm afraid. -- Niels. -- From nanog at daork.net Mon May 5 19:07:13 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 6 May 2008 12:07:13 +1200 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: References: <036801c8aeea$2166e1b0$cb998647@ws20031> Message-ID: On 6/05/2008, at 8:02 AM, Iljitsch van Beijnum wrote: > Of course not. Like I said, as an average end-user with 10 Mbps you > get to send a maximum of 2500 packets per second. That's plenty to do > VoIP, set up TCP sessions or do IM. You just don't get to send the > full 10 Mbps at this size. Hmm, I see value in that. But, good luck trying to convince customers to take a pps limitation in addition to a Mbps limitation, whether they ever exceed that pps or not. You /might/ convince them to take a pps limitation only - but if they want to do 30Mbit (ie 2500pps @ 1500b) then your product needs to support that. Maybe you just start calling "10Mbps" "10Mbps, assuming a 500b average packet size." Anyway, nice idea in theory - putting more real world limitations in to sold product limitations - but I don't see it working out with marketing people, etc. unless someone has been doing it for years already. It'd be good if the world were all engineers though, huh? -- Nathan Ward From nanog at daork.net Mon May 5 19:50:08 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 6 May 2008 12:50:08 +1200 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: On 6/05/2008, at 4:07 AM, Paul Vixie wrote: > i dearly do > wish that something like a "service advertisement protocol" existed, > that > did what OSPF ECMP did, without a router operator effectively giving > every > customer the ability to inject other customer routes, or default > routes. This stuff about customers and things sounds too hard. Steve, have you actually had to do anycast without having control of the routing hop in front of your service providing hosts, or is this getting unnecessarily complicated? I'd imagine that the ability to install routing equipment would be a pre-requisite for any anycast service deployment.. Perhaps what would make more sense here is Foundry (F5, etc.) building an anycast feature - anycast prefixes are withdrawn when a cluster relying on that anycast prefix goes below a threshold. These load balancing switches already do all this service health check stuff and have done for years, so why are we re-inventing the wheel? -- Nathan Ward ps. I'm amused that your message that started with "i think the minutia is good, especially after a long weekend of layer 9 threads." ended with a paragraph of L9 :-) From rdobbins at cisco.com Mon May 5 20:06:07 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Tue, 6 May 2008 08:06:07 +0700 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505183807.6738f844@cs.columbia.edu> Message-ID: <419F99BD-AAB1-40FD-BCBF-7611FF849DB7@cisco.com> On May 6, 2008, at 2:52 AM, Paul Vixie wrote: > delay, because nanog meetings only happen N times per year, so > an idea may have to wait months before it's widely circulated. > congestion, > because nanog meetings are of fixed duration and there is, and has > to be, > competition for the slots, to make the meeting interesting, keep > quality high. From one standpoint, these aren't necessarily unalloyed negatives, as they act as a filter to keep the noise-level down, somewhat. Are we convinced that there's a glut of useful technical/operational information which folks have both the time and inclination to write up, but which they don't due to the perceived lack of an appropriate review/publication mechanism utilized by their intended audience? ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From jabley at ca.afilias.info Mon May 5 20:21:13 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Mon, 5 May 2008 21:21:13 -0400 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: <77F4D75F-6FF0-466E-88A9-7607E95FF6BC@ca.afilias.info> On 5 May 2008, at 20:50, Nathan Ward wrote: > Perhaps what would make more sense here is Foundry (F5, etc.) building > an anycast feature - anycast prefixes are withdrawn when a cluster > relying on that anycast prefix goes below a threshold. I'm not sure exactly what feature is required, here. f5s of my acquaintance are already very capable of making OSPF LSAs based on virtual servers' pools being non-empty. Do it on more than one f5 in the same area, and you're anycasting service availability with the current feature set. The general reason why people prefer to find alternative solutions rather than use dedicated load-balancers are that the dedicated load- balancers are hellishly more expensive than the $5 gigabit switch you probably already have in your garage. Joe From nanog at daork.net Mon May 5 20:24:35 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 6 May 2008 13:24:35 +1200 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <20080506011920.4df599e8@cs.columbia.edu> References: <20080505031359.R92749@sprockets.gibbard.org> <20080506011920.4df599e8@cs.columbia.edu> Message-ID: On 6/05/2008, at 1:19 PM, Steven M. Bellovin wrote: > "Steve"? I assume you meant "Paul".... No, Steve Gibbard referred to not having control of routers, Paul referred to customers. -- Nathan Ward From smb at cs.columbia.edu Mon May 5 20:36:57 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 6 May 2008 01:36:57 +0000 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> <20080506011920.4df599e8@cs.columbia.edu> Message-ID: <20080506013657.3a679c83@cs.columbia.edu> On Tue, 6 May 2008 13:24:35 +1200 Nathan Ward wrote: > On 6/05/2008, at 1:19 PM, Steven M. Bellovin wrote: > > > "Steve"? I assume you meant "Paul".... > > No, Steve Gibbard referred to not having control of routers, Paul > referred to customers. > Ah. As has often been noted, "Steve is a multicast address". --Steve Bellovin, http://www.cs.columbia.edu/~smb From nanog at daork.net Mon May 5 20:49:39 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 6 May 2008 13:49:39 +1200 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <77F4D75F-6FF0-466E-88A9-7607E95FF6BC@ca.afilias.info> References: <20080505031359.R92749@sprockets.gibbard.org> <77F4D75F-6FF0-466E-88A9-7607E95FF6BC@ca.afilias.info> Message-ID: <851FA29F-56CD-424C-A65F-51FC80863F94@daork.net> On 6/05/2008, at 1:21 PM, Joe Abley wrote: > On 5 May 2008, at 20:50, Nathan Ward wrote: > >> Perhaps what would make more sense here is Foundry (F5, etc.) >> building >> an anycast feature - anycast prefixes are withdrawn when a cluster >> relying on that anycast prefix goes below a threshold. > > I'm not sure exactly what feature is required, here. f5s of my > acquaintance are already very capable of making OSPF LSAs based on > virtual servers' pools being non-empty. Do it on more than one f5 in > the same area, and you're anycasting service availability with the > current feature set. Can they do it with BGP for Internet anycast? > The general reason why people prefer to find alternative solutions > rather than use dedicated load-balancers are that the dedicated load- > balancers are hellishly more expensive than the $5 gigabit switch > you probably already have in your garage. The dedicated load balancers also talk BGP (well, ones I've played with), so that does away with the need for a BGP speaking router. -- Nathan Ward From adrian at creative.net.au Mon May 5 20:58:46 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 6 May 2008 09:58:46 +0800 Subject: [NANOG] Larger packets to save power, was: Re: would ip6 help us safeing energy ? In-Reply-To: References: <036801c8aeea$2166e1b0$cb998647@ws20031> Message-ID: <20080506015846.GC2572@skywalker.creative.net.au> On Tue, May 06, 2008, Nathan Ward wrote: > Maybe you just start calling "10Mbps" "10Mbps, assuming a 500b average > packet size." > > Anyway, nice idea in theory - putting more real world limitations in > to sold product limitations - but I don't see it working out with > marketing people, etc. unless someone has been doing it for years > already. It'd be good if the world were all engineers though, huh? NPE-XXX, anyone? Adrian From jabley at ca.afilias.info Mon May 5 21:03:30 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Mon, 5 May 2008 22:03:30 -0400 Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: <851FA29F-56CD-424C-A65F-51FC80863F94@daork.net> References: <20080505031359.R92749@sprockets.gibbard.org> <77F4D75F-6FF0-466E-88A9-7607E95FF6BC@ca.afilias.info> <851FA29F-56CD-424C-A65F-51FC80863F94@daork.net> Message-ID: <1024C6E7-FE42-403F-9A0B-7E0F8BA37AFA@ca.afilias.info> On 5 May 2008, at 21:49, Nathan Ward wrote: > On 6/05/2008, at 1:21 PM, Joe Abley wrote: > >> On 5 May 2008, at 20:50, Nathan Ward wrote: >> >>> Perhaps what would make more sense here is Foundry (F5, etc.) >>> building >>> an anycast feature - anycast prefixes are withdrawn when a cluster >>> relying on that anycast prefix goes below a threshold. >> >> I'm not sure exactly what feature is required, here. f5s of my >> acquaintance are already very capable of making OSPF LSAs based on >> virtual servers' pools being non-empty. Do it on more than one f5 in >> the same area, and you're anycasting service availability with the >> current feature set. > > Can they do it with BGP for Internet anycast? They run ZebOS for routing stuff, so I would say so, although I haven't tried. In our application the covering supernets are synthesised as aggregates based on the presence of the OSPF /32. >> The general reason why people prefer to find alternative solutions >> rather than use dedicated load-balancers are that the dedicated load- >> balancers are hellishly more expensive than the $5 gigabit switch >> you probably already have in your garage. > > The dedicated load balancers also talk BGP (well, ones I've played > with), so that does away with the need for a BGP speaking router. There is a certain keenness to keep the peering edge free of multi- function boxes in some sandboxes I have played in. I can't say I would be tremendously enthusiastic about the idea of using an (say) f5 BigIP 6800 as a peering router (not that I've tried and failed, or anything; for all I know it would work just fine). But perhaps some of that religion has just rubbed off on me. Joe From scg at gibbard.org Tue May 6 05:09:43 2008 From: scg at gibbard.org (Steve Gibbard) Date: Tue, 6 May 2008 03:09:43 -0700 (PDT) Subject: [NANOG] OSPF minutia, and, technote publication venues In-Reply-To: References: <20080505031359.R92749@sprockets.gibbard.org> Message-ID: <20080506024457.K16536@sprockets.gibbard.org> On Tue, 6 May 2008, Nathan Ward wrote: > This stuff about customers and things sounds too hard. > > Steve, have you actually had to do anycast without having control of > the routing hop in front of your service providing hosts, or is this > getting unnecessarily complicated? I'd imagine that the ability to > install routing equipment would be a pre-requisite for any anycast > service deployment.. Yes I have. Or rather, I've done the network infrastructure for anycast services without having administrative control of the anycasted servers. PCH's anycast platform hosts some blade servers for some other DNS infrastructure operators (in addition to the name servers PCH operates itself). Those operators operate their own servers. PCH operates the routing infrastructure. There is filtering in place to limit the routing announcements from the servers. But also, most of the larger organizations I've worked for have had separate systems and network engineering groups. In general, the network groups haven't wanted to let the systems engineers configure the routers, and the systems groups haven't wanted to let network engineers configure the servers (with good reason). Filtering of routing announcements from anycast servers would be useful in that environment too. To address Paul's point about multipath BGP, I never saw Cisco's implementation of it causing a problem even with full routing tables. I haven't used any other implementations. In the Cisco version (and at least for EBGP; I haven't looked at this with IBGP), it only applies to otherwise identical AS paths. Multiple directly-connected DNS servers sourcing the same announcement with the same AS path and other BGP attributes get load balanced between. Paths learned from different peers had different AS paths and do not get balanced between. I suppose there probably is load balancing in cases where there are multiple sessions with the same peer at the same exchange. That's a relatively rare case in this implementation, and using hash based rather than per-packet load balancing makes it not really matter. -Steve From nathana at fsr.com Tue May 6 14:07:05 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Tue, 06 May 2008 12:07:05 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? Message-ID: <4820AC59.1020909@fsr.com> Hello, Has anyone else here seen problems with microsoft/msn/hotmail/live.com sites not performing PMTUD correctly? We have, for a while now, had people on our network complain of poor microsoft.com reachability, and discovered we can work around the issue by changing MSS on all TCP SYN as they go out of our network. I recently watched the whole conversation between msn.com and a host on our network (with the MSS rewrite disabled), and if I'm reading it right, we are following PMTUD protocol correctly by sending back ICMP type 3 code 4, but all Microsoft hosts seem to ignore this and continue to send packets back to our host with an MSS that is too large. I hope I'm wrong and that it is we who are doing something stupid, but after cruising Google for a while, I found a multitude of other complaints from people connected to other ISPs specifically about not being able to reach Microsoft web sites. It seems crazy that MS could have PMTUD broken for so long with nobody ever raising a complaint to them directly, though, which makes me wonder if there is another answer here that I'm missing. I sent the following message to a couple of addresses that I gleaned from ARIN WHOIS for the IP block in question and threw hostmaster in there just in case it went somewhere, but noc at microsoft.com appears to be defunct. I have yet to receive acknowledgment of receipt from the other address. Are there any microsoft.com admins that hang out here that can comment on this or get in touch with me, or is there perhaps someone on here with connections to the Microsoft NOC? (BTW, I stripped the referenced libpcap attachment off of this message to the list just so that I wouldn't accidentally incur the wrath of NANOG...if y'all want to see it, I'm happy to post it.) Thanks, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -------- Original Message -------- Subject: Microsoft/MSN/Live!/Hotmail behind blackhole router? Date: Thu, 01 May 2008 19:00:46 -0700 From: Nathan Anderson/FSR To: hostmoaster at microsoft.com, noc at microsoft.com, iprrms at microsoft.com To microsoft.com NOC admins: I work for a regional ISP in the inland pacific northwest. May of our customers' connections have MTUs of less than 1500, and we get routine complaints from them that they have trouble reaching web sites that are under your administration. Usually we can fix the problem by "mangling" the TCP SYNs originating from our customers and headed to the world to reflect a lower value; however, we would rather not have to do that. The fact that we are REQUIRED to do this in order for your sites to be reachable by our customers strongly suggests that either the servers that respond to HTTP requests sent to www.microsoft/msn/hotmail/live.com are behind routers that are blocking ALL ICMP traffic sent their way -- even ICMP type 3 code 4 (packet too large, DF set), which is necessary in order for Path MTU Discovery to work -- or the servers themselves are not listening to the ICMP messages that we are sending their way when our routers are forced to drop a packet sent by you which is too large to be forwarded to a customer of ours. I set up a test connection "on the bench" so to speak, and had our router capture a copy of the conversation between our test client and www.msnbc.msn.com and forward that conversation encapsulated in TZSP to the same test client over a different interface. The capture clearly shows our test client establishing the TCP connection with MSNBC (SYN/SYN+ACK/ACK), and then goes on to show MSNBC send ethernet MTU-sized packets our way that an intermediate router of ours drops and responds with "packet too big, DF set." Despite this, MSNBC continues to retrasmit the original packet with the same payload and the same size back to us. We continue to respond "packet too big, DF set," but the MSNBC server never seems to get the message (literally). We see the same behavior with all sites across the board contained within the 207.46.0.0/16 space, regardless of actual hostname/FQDN. We also find this ironic considering that Microsoft published a Technet article a few years back on black hole routers and the problems they pose, found at http://technet.microsoft.com/en-us/library/bb878081.aspx (which we can't read/access unless we are mangling the MSS). We would appreciate it if Microsoft NOC admins would please look into the matter and take the appropriate corrective action: allowing ICMP type 3 code 4 messages through your routers/firewalls, and making sure that your servers respond to them appropriately as defined in RFC 1191. I have attached the capture we made of the conversation to this e-mail message in libpcap format for your analysis. The test client itself had a 1500 MTU to a desktop router, which in turn had an MTU of 1492 on its uplink to us. I am available to answer any additional clarifying questions you may have. Thank you for your time and attention to this matter. Regards, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From brandon at rd.bbc.co.uk Tue May 6 14:58:38 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 6 May 2008 20:58:38 +0100 (BST) Subject: [NANOG] Microsoft.com PMTUD black hole? Message-ID: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> > Has anyone else here seen problems with microsoft/msn/hotmail/live.com > sites not performing PMTUD correctly? I used to see it a lot when hosting on windows was popular and people realised they needed a firewall or decided to add a load balancer but broke PMTUD by leaving it enabled on the servers. I've not heard of it for some time so those people got a clue or moved to something else (or everyone worked around them) brandon From iljitsch at muada.com Tue May 6 15:26:46 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Tue, 6 May 2008 22:26:46 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> Message-ID: <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> On 6 mei 2008, at 21:58, Brandon Butterworth wrote: >> Has anyone else here seen problems with microsoft/msn/hotmail/ >> live.com >> sites not performing PMTUD correctly? > I used to see it a lot when hosting on windows was popular and people > realised they needed a firewall or decided to add a load balancer > but broke PMTUD by leaving it enabled on the servers. > I've not heard of it for some time so those people got > a clue or moved to something else (or everyone worked around them) Many years ago I had occasion to terminate dial-up service over L2TP from modem pools operated by a service provider who shall remain nameless to protect the guilty. This service had the unfortunate tendency to drap all packets larger than 576 bytes. So we needed to negotiate a 576-byte MTU over PPP. We then got many complaints from users who dialed in using ISDN routers (yes this was a while ago) because of broken path MTU discovery. The behavior that Microsoft exhibits was EXTREMELY common in those days, and I have no reason to assume it's any less common today. (I also see it regularly with IPv6.) What I did was clear the DF bit on packets going out to the L2TP virtual interfaces so the packets could be fragmented. A more common approach is to rewrite the MSS option in all TCP SYNs with a smaller value so there won't be TCP segments large enough to trigger the problem. AFAIK, all boxes that do PPPoE do this. All of this even went so far that the IETF came up with RFC 4821, which will do path MTU discovery by correlating lost packets with packet sizes to determine the path MTU rather than depend on ICMP messages. From nathana at fsr.com Tue May 6 15:57:28 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Tue, 06 May 2008 13:57:28 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> Message-ID: <4820C638.6040704@fsr.com> Brandon Butterworth wrote: > I used to see it a lot when hosting on windows was popular and people > realised they needed a firewall or decided to add a load balancer > but broke PMTUD by leaving it enabled on the servers. Yeah, but this is Microsoft's OWN server farm we are talking about here, not some small podunk IIS-based hosting provider. ...well, you may be right. I am probably giving MS too much credit here. On another note, someone pointed out to me off-list that I apparently tyop'd "hostmaster" when I sent the e-mail to MS. I have since re-sent it to the properly-spelled address and again promptly received a "User unknown" bounceback. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Tue May 6 16:29:03 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Tue, 06 May 2008 14:29:03 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> Message-ID: <4820CD9F.1020308@fsr.com> Iljitsch van Beijnum wrote: > A more common approach is to rewrite the MSS option in all TCP SYNs [snip] Yeah, we do this now, but the software that we have been using for PPPoE termination as well as for a huge portion of our clients (MikroTik RouterOS) doesn't do it correctly in my estimation when you flip on the automatic "change-tcp-mss" option...it rewrites the MSS in ALL SYNs passing through it, either coming OR going. This has the effect of breaking communication with other hosts that actually have a SMALLER MSS than our PPPoE customers since our client will get a SYN+ACK from the remote host that we have rewritten to reflect a larger MSS than the remote host is capable of dealing with. Because MikroTik rewrote both the SYNs generated by us as well as received by us, our customer's host is now under the impression that the lowest MSS between the two hosts matches its own. At least that's the best theory I've come up with. We can write (and have written) custom IP manglers on the MikroTik boxes that only touch SYNs generated by our clients, and only when the MSS is larger than a certain value (in order to honor MSSes even lower than that allowed by their PPPoE gateway). But it's a PITA to deal with. I'd just rather everyone follow protocol. :-P Although we can't always expect everyone to do it by the book, I don't think it is too much to ask that those who operate sizable networks that nearly everyone is required to interact with on a daily basis (read: Microsoft) act responsibly. > All of this even went so far that the IETF came up with RFC 4821, > which will do path MTU discovery by correlating lost packets with > packet sizes to determine the path MTU rather than depend on ICMP > messages. What's funny is that I ran my tests from a Windows XP host with the recently-released Service Pack 3 installed, which is supposed to activate Microsoft's "PMTUD Black Hole Router Detection" by default (available pre-SP3 but apparently not turned on without a registry change). I haven't read up on exactly how it's supposed to work, but I think the basic idea is that if the TCP connection is negotiated properly but it doesn't get a response beyond that, it will try lower and lower MSSes until it does. However it works (or doesn't as the case may be), it didn't make a lick of difference. I waited and waited for content to be delivered to me until eventually Microsoft's end sent me a TCP RST. While I was poking at this, though, I had a thought...most IP stacks I believe keep a path MTU cache of some sort. I know Windows does: if I send an ICMP packet with DF set that is larger than the PPPoE gateway can handle, I get something similar to the following: C:\Documents and Settings\nathana>ping 64.126.160.1 -f -l 1472 Pinging 64.126.160.1 with 1472 bytes of data: Reply from 64.126.142.249: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. [...] Next time that I try the same thing, Windows doesn't even bother trying to send the packet. It looks at its PMTU table for that IP, and already KNOWS it is too big: C:\Documents and Settings\nathana>ping 64.126.160.1 -f -l 1472 Pinging 64.126.160.1 with 1472 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. [...] However, even when trying this with www.msnbc.msn.com, and with the MSNBC entry in its PMTU cache (and its IP set statically in my 'hosts' file so that Akamai/MS round-robin DNS doesn't screw with me during the test), when I tried to build a TCP connection to MSNBC from this same host, Windows told the remote host it had a 1460 MSS. Now, although that makes sense, in order to avoid issues like the one we are facing with Microsoft, would it not make _more_ sense for the stack to look at the PMTU cache first, and then adjust its own MSS just for connections to that one host? Maybe even send out an MTU - 40 ICMP packet to the host that we want to build a TCP connection with FIRST to get an ICMP type 3 code 4 response from the router in-between with the smaller MTU? That would put the burden of PMTUD on the host requesting the TCP session rather than on the one responding, but if hosts were "smarter" like this it seems to me it might smooth out some of these issues. The remote end could be "broken" with respect to PMTUD but it wouldn't matter. Thoughts? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Tue May 6 16:32:48 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Tue, 06 May 2008 14:32:48 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4820CD9F.1020308@fsr.com> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> <4820CD9F.1020308@fsr.com> Message-ID: <4820CE80.6060606@fsr.com> Nathan Anderson/FSR wrote: [...] > connections to that one host? Maybe even send out an MTU - 40 ICMP :s/40/sized. Brain fart. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From bonomi at mail.r-bonomi.com Tue May 6 17:53:58 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 6 May 2008 17:53:58 -0500 (CDT) Subject: [NANOG] Microsoft.com PMTUD black hole? Message-ID: <200805062253.m46MrwS1025720@mail.r-bonomi.com> ` > Date: Tue, 06 May 2008 14:29:03 -0700 > From: Nathan Anderson/FSR > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > > Now, although that makes sense, in order to avoid issues like the one we > are facing with Microsoft, would it not make _more_ sense for the stack > to look at the PMTU cache first, and then adjust its own MSS just for > connections to that one host? This _is_ Microsoft we're talking about, remember. 'sense' and 'Microsoft' are, at a =minimum= orthogonal to each other -- and may not even inhabit the same address-space. As for standards, it is official Microsoft policy to "embrace and extend", not to implement in a way compatible with the rest of the world. *sigh* I -don't- believe the rumor that "PMTUD/Vista Ultimate" sends incrementally increasing-size packets, and uses the first one that -doesn't- get through as the size limit. From tomb at byrneit.net Tue May 6 19:51:44 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 6 May 2008 17:51:44 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <200805062253.m46MrwS1025720@mail.r-bonomi.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F133@pascal.zaphodb.org> Interestingly, Windows XP, Sp3, released today, describes changes in PMTUD behavior. Black Hole Router detection is now on by default: http://download.microsoft.com/download/6/8/7/687484ed-8174-496d-8db9-f02 b40c12982/Overview%20of%20Windows%20XP%20Service%20Pack%203.pdf > -----Original Message----- > From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] > Sent: Tuesday, May 06, 2008 3:54 PM > To: nanog at merit.edu > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > ` > > > Date: Tue, 06 May 2008 14:29:03 -0700 > > From: Nathan Anderson/FSR > > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > > > > > Now, although that makes sense, in order to avoid issues > like the one > > we are facing with Microsoft, would it not make _more_ > sense for the > > stack to look at the PMTU cache first, and then adjust its own MSS > > just for connections to that one host? > > This _is_ Microsoft we're talking about, remember. 'sense' > and 'Microsoft' > are, at a =minimum= orthogonal to each other -- and may not > even inhabit the same address-space. > > As for standards, it is official Microsoft policy to "embrace > and extend", > not to implement in a way compatible with the rest of the > world. *sigh* > > I -don't- believe the rumor that "PMTUD/Vista Ultimate" sends > incrementally increasing-size packets, and uses the first one > that -doesn't- get through > as the size limit. > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From tme at multicasttech.com Tue May 6 20:06:18 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 6 May 2008 21:06:18 -0400 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F133@pascal.zaphodb.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <70D072392E56884193E3D2DE09C097A9F133@pascal.zaphodb.org> Message-ID: <736F0C43-3636-4252-9AB0-F1A347030772@multicasttech.com> On May 6, 2008, at 8:51 PM, Tomas L. Byrnes wrote: > Interestingly, Windows XP, Sp3, released today, describes changes in > PMTUD behavior. > > Black Hole Router detection is now on by default: > > http://download.microsoft.com/download/6/8/7/687484ed-8174-496d-8db9-f02 > b40c12982/Overview%20of%20Windows%20XP%20Service%20Pack%203.pdf > or http://tinyurl.com/323xb Regards > >> -----Original Message----- >> From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] >> Sent: Tuesday, May 06, 2008 3:54 PM >> To: nanog at merit.edu >> Subject: Re: [NANOG] Microsoft.com PMTUD black hole? >> >> ` >> >>> Date: Tue, 06 May 2008 14:29:03 -0700 >>> From: Nathan Anderson/FSR >>> Subject: Re: [NANOG] Microsoft.com PMTUD black hole? >>> >>> >>> Now, although that makes sense, in order to avoid issues >> like the one >>> we are facing with Microsoft, would it not make _more_ >> sense for the >>> stack to look at the PMTU cache first, and then adjust its own MSS >>> just for connections to that one host? >> >> This _is_ Microsoft we're talking about, remember. 'sense' >> and 'Microsoft' >> are, at a =minimum= orthogonal to each other -- and may not >> even inhabit the same address-space. >> >> As for standards, it is official Microsoft policy to "embrace >> and extend", >> not to implement in a way compatible with the rest of the >> world. *sigh* >> >> I -don't- believe the rumor that "PMTUD/Vista Ultimate" sends >> incrementally increasing-size packets, and uses the first one >> that -doesn't- get through >> as the size limit. >> >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From nathana at fsr.com Tue May 6 20:12:42 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Tue, 06 May 2008 18:12:42 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <200805062253.m46MrwS1025720@mail.r-bonomi.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> Message-ID: <4821020A.7050003@fsr.com> All, A member of Microsoft's GNS network escalations team saw my postings on NANOG about this issue and took offense at my use of this forum to raise this issue with them, and criticized me as being unprofessional and lacking in business acumen. Therefore, I would like to publicly apologize for my actions here. It was not my intention to "humiliate" Microsoft into compliance but rather to find a means of effective contact with them since none was to be found before today. However, I recognize that I did step over the line, especially with regards to one comment I made in an earlier post about "giving Microsoft too much credit." I apologize for this and retract this, and ask their forgiveness. As I promised, I will not be posting any more to this list regarding this issue unless it is to report the final verdict that I receive from my now-open ticket with Microsoft (thanks to this list, I found an effective contact), or to discuss the mechanics of PMTUD in general. Regards, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Tue May 6 20:18:08 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Tue, 06 May 2008 18:18:08 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F133@pascal.zaphodb.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <70D072392E56884193E3D2DE09C097A9F133@pascal.zaphodb.org> Message-ID: <48210350.6030308@fsr.com> Tomas L. Byrnes wrote: > Interestingly, Windows XP, Sp3, released today, describes changes in > PMTUD behavior. > > Black Hole Router detection is now on by default: As I pointed out in my post earlier today timestamped at 2:29PM, I was using an XP SP3 host to perform my tests with, and it made no difference. I also used BBR's DrTCP application to make sure that black hole router detection was, in fact, enabled on my XP box before commencing my packet captures. I cannot explain why it made no difference, but at the same time I don't know enough about how WinNT's black hole router detection works to begin speculating at this point. I do plan on looking into it, however. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From iljitsch at muada.com Wed May 7 00:22:21 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 May 2008 07:22:21 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <14153.1210110501@turing-police.cc.vt.edu> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> <14153.1210110501@turing-police.cc.vt.edu> Message-ID: On 6 mei 2008, at 23:48, Valdis.Kletnieks at vt.edu wrote: >> A more common approach is to rewrite the MSS option in all TCP SYNs >> with a smaller value so there won't be TCP segments large enough to >> trigger the problem. AFAIK, all boxes that do PPPoE do this. > And just the other day, you were saying: >> Very few people out there use an MTU significantly below 1500 >> bytes. A >> 1500-byte MTU will give you an _average_ packet size of ~1000 on >> long- >> lived TCP flows because there is one tiny ACK for every two full size >> data segments. Right. Why is that noteworthy? I have a lot more to say about MTU issues in this draft about negotating MTUs between two hosts/routers on a subnet so jumboframes can be deployed without manual configuration: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-02.txt > Apparently, there's a *reason* why RFC1122, section 3.3.3 says: > It is generally desirable to avoid local fragmentation and to > choose EMTU_S low enough to avoid fragmentation in any gateway > along the path. In the absence of actual knowledge of the > minimum MTU along the path, the IP layer SHOULD use > EMTU_S <= 576 whenever the destination address is not on a > connected network, and otherwise use the connected network's > MTU. Tell it to Microsoft and their ICMP-filtering friends... From iljitsch at muada.com Wed May 7 00:29:41 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 May 2008 07:29:41 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4820CD9F.1020308@fsr.com> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> <4820CD9F.1020308@fsr.com> Message-ID: <600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com> On 6 mei 2008, at 23:29, Nathan Anderson/FSR wrote: > Now, although that makes sense, in order to avoid issues like the > one we > are facing with Microsoft, would it not make _more_ sense for the > stack > to look at the PMTU cache first, and then adjust its own MSS just for > connections to that one host? Maybe even send out an MTU - 40 ICMP > packet to the host that we want to build a TCP connection with FIRST > to > get an ICMP type 3 code 4 response from the router in-between with the > smaller MTU? No. This would add significant delay because you'd have to give the other side enough time to respond to the large packet (also sending a large packet on something like GPRS/EDGE is a waste of bandwidth and battery power) while if there is ICMP filtering, there won't be a response, which is exactly the reason why we're in this bind in the first place (along with the stupid idea that DF should be set for ALL packets rather than just once in a while). And adjusting the MSS based on ephemeral information is the wrong thing to do in the first place. The path MTU can vary. Once you've advertised a small MSS you can never increase it. It is incredibly unprofessional that people enable PMTUD, then break it and require the rest of the world to implement workarounds. Either use PMTUD properly by accepting the ICMP messages or turn PMTUD off. From randy at psg.com Wed May 7 00:44:06 2008 From: randy at psg.com (Randy Bush) Date: Wed, 07 May 2008 07:44:06 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4821020A.7050003@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> Message-ID: <482141A6.50106@psg.com> > A member of Microsoft's GNS network escalations team saw my postings on > NANOG about this issue and took offense at my use of this forum to raise > this issue with them, and criticized me as being unprofessional and > lacking in business acumen. they try that intimidation every time a vulnerability or bug is revealed. laugh and post their overly-aggressive message on a public web site. randy From gdt at gdt.id.au Wed May 7 02:12:45 2008 From: gdt at gdt.id.au (Glen Turner) Date: Wed, 07 May 2008 16:42:45 +0930 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4821020A.7050003@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> Message-ID: <4821566D.5080501@gdt.id.au> Nathan Anderson/FSR wrote: > A member of Microsoft's GNS network escalations team saw my postings on > NANOG about this issue and took offense at my use of this forum to raise > this issue with them, and criticized me as being unprofessional and > lacking in business acumen. Hang on a tick. Aren't you one of their customers...... > As I pointed out in my post earlier today timestamped at 2:29PM, I was > using an XP SP3 host to perform my tests with... ...why yes, you are. I can't think of any other supplier that would be so unprofessional and so lacking in business acumen as to say that their customer was UALIBI. Amazing. A fine case study of a person in customer contact undoing the work of millions of dollars in PR. Whatever you say about Steve Ballmer he's a great sales person at heart. He must despair at some of his staff. -- Glen Turner From newton at internode.com.au Wed May 7 03:05:59 2008 From: newton at internode.com.au (Mark Newton) Date: Wed, 7 May 2008 17:35:59 +0930 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4821566D.5080501@gdt.id.au> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <4821566D.5080501@gdt.id.au> Message-ID: On 07/05/2008, at 4:42 PM, Glen Turner wrote: > Amazing. A fine case study of a person in customer contact undoing the > work of millions of dollars in PR. I wouldn't worry too much about it, Glen. My observation is that the millions of dollars in PR isn't working very well either :-) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From bjorn at mork.no Wed May 7 03:10:35 2008 From: bjorn at mork.no (=?iso-8859-1?Q?Bj=F8rn_Mork?=) Date: Wed, 07 May 2008 10:10:35 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> (Iljitsch van Beijnum's message of "Tue, 6 May 2008 22:26:46 +0200") References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> Message-ID: <87lk2m4jr8.fsf@obelix.mork.no> Iljitsch van Beijnum writes: > Many years ago I had occasion to terminate dial-up service over L2TP > from modem pools operated by a service provider who shall remain > nameless to protect the guilty. This service had the unfortunate > tendency to drap all packets larger than 576 bytes. So we needed to > negotiate a 576-byte MTU over PPP. > > We then got many complaints from users who dialed in using ISDN > routers (yes this was a while ago) because of broken path MTU > discovery. The behavior that Microsoft exhibits was EXTREMELY common > in those days, and I have no reason to assume it's any less common > today. (I also see it regularly with IPv6.) What I did was clear the > DF bit on packets going out to the L2TP virtual interfaces so the > packets could be fragmented. Right. I once stumbled across a SOHO-router doing just that. I never understood why, but now you've given at least one explanation how it could appear to be a good idea. I can also provide the reason why we found it to be an extremely bad idea at the time: Some (most? all?) systems won't set both the DF flag and the identification field at the same time. If you clear the DF flag without changing the identification field, you might end up with fragmented packets that are impossible to reassemble. Which was why I stumbled across the DF-clearing SOHO-router in the first place. The random problems it generated were extremely difficult to debug, and when we started we truly believed that we had a problem with a layer 4 load balancing switch. Note: There are solutions that will both clear the DF flag and generate a new id. E.g. http://www.openbsd.org/faq/pf/scrub.html This is the proper way to clear DF, if you must. Never just clear it. Bj?rn From bob.crooks at sasktel.sk.ca Wed May 7 07:30:13 2008 From: bob.crooks at sasktel.sk.ca (Bob Crooks) Date: Wed, 7 May 2008 06:30:13 -0600 Subject: [NANOG] Bob Crooks/SaskTel/CA is out of the office. Message-ID: I will be out of the office starting 05/07/2008 and will not return until 05/12/2008. From rsk at gsp.org Wed May 7 08:45:07 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 7 May 2008 09:45:07 -0400 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4821020A.7050003@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> Message-ID: <20080507134507.GA23142@gsp.org> On Tue, May 06, 2008 at 06:12:42PM -0700, Nathan Anderson/FSR wrote: > A member of Microsoft's GNS network escalations team saw my postings on > NANOG about this issue and took offense at my use of this forum to raise > this issue with them, and criticized me as being unprofessional and > lacking in business acumen. This is a typical Microsoft reaction: blame the messenger for their own incompetence, laziness, stupidity, and greed. I think you should post their assinine message so that it can receive the public ridicule it surely deserves. ---Rsk From patrick at zill.net Wed May 7 08:49:15 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 07 May 2008 09:49:15 -0400 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4821566D.5080501@gdt.id.au> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <4821566D.5080501@gdt.id.au> Message-ID: <4821B35B.7000408@zill.net> Glen Turner wrote: > Amazing. A fine case study of a person in customer contact undoing the > work of millions of dollars in PR. Whatever you say about Steve Ballmer > he's a great sales person at heart. He must despair at some of his staff. > The rest of us however, despair at having to support their crap. Patrick Giagnocavo patrick at zill.net From ThorsonSR at ldschurch.org Wed May 7 09:43:16 2008 From: ThorsonSR at ldschurch.org (Shane Thorson) Date: Wed, 07 May 2008 08:43:16 -0600 Subject: [NANOG] Google Contact Message-ID: <48216BA4020000DE0000894D@inet-wh2.gmhwh.org> All; I am having a bit of difficulty resolving a Google matter. I am hoping to get pointed in the right direction by someone from Google. Thanks ---------------------------------------------------------------------- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. From stephen at sprunk.org Wed May 7 11:32:23 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 7 May 2008 11:32:23 -0500 Subject: [NANOG] Microsoft.com PMTUD black hole? References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> Message-ID: Thus spake "Nathan Anderson/FSR" > A member of Microsoft's GNS network escalations team saw my > postings on NANOG about this issue and took offense at my use > of this forum to raise this issue with them, and criticized me as > being unprofessional and lacking in business acumen. First, it's "unprofessional and lacking in business acumen" for someone to criticize their customers to their face. As one manager taught me, "The customer may not always be right, but they're never wrong." Second, it's their own damn fault for not maintaining their contact information properly in public databases. If the only option they leave you is to post to NANOG, because they don't respond to (or even accept) direct requests to the listed contacts, then that's what you have to do. Many companies are guilty of the latter, and we all get the benefit of seeing the state of their customer service for reference when making future buying decisions. Very few are arrogant enough to do the former, though. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From nathana at fsr.com Wed May 7 13:50:34 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 11:50:34 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> <4820CD9F.1020308@fsr.com> <600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com> Message-ID: <4821F9FA.4020306@fsr.com> Iljitsch van Beijnum wrote: > No. This would add significant delay because you'd have to give the > other side enough time to respond to the large packet (also sending a > large packet on something like GPRS/EDGE is a waste of bandwidth and > battery power) while if there is ICMP filtering, there won't be a > response, which is exactly the reason why we're in this bind in the > first place I admit the idea needs tweaking (at best), and it was just a stray thought :-), but 1) even if there is ICMP filtering happening way at the other end, I (the TCP initiator) will still get a response from the router in the middle (RITM) that is reducing the total path MTU if I try to send a packet through it larger than the actual path MTU, and 2) if I don't get a response to my single large packet (either from a RITM or the other end) in a timely fashion (less than a second?), then the client/initiator may just assume that path MTU == local MTU and will set its MSS accordingly (which is no different than what is happening now), until it has a reason to think differently. Also, if there is already something in the local PMTU cache for a single host address, I'm not sure I follow why it would be a bad idea for the TCP initiator to consult that cache when preparing the SYN. Although, on second thought, I suppose it is possible (and, in more than a few cases, likely) that in instances of route path asymmetry, the PMTU of the path from the initiator to the server may be different than the PMTU of the path back from the server to the client. Hmmm. Okay, scratch that idea then. :-P -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Wed May 7 14:24:57 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 12:24:57 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <20080507134507.GA23142@gsp.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> Message-ID: <48220209.8000407@fsr.com> Here is a brief update on the situation: I have been in contact with someone at Microsoft's service operations center, who has confirmed for me that MS does in fact block _all_ ICMP at the edge of their network, that they are aware that this will in fact break PMTUD, and that they have no current plans to change this practice which they have implemented in the interest of security. Nevertheless, the person I have been in contact with is naturally not the final decision-maker on this issue and is going to continue to pass the issue on up the chain of command for me. So although this issue is not over and I do not have a final verdict from MS yet, I felt that, given that I don't know how much time to expect to pass between now and when that final verdict is rendered, it would be appropriate to let everybody here know what I have learned thus far. Hopefully public dissemination of this information factoid will prevent others in a position similar to mine from having to helplessly beat their heads into their keyboards. I, naturally, voiced my strong objection over this security policy, and attempted to make a reasoned argument with the contact I have over there. We will see what comes of this. Some have asked me to post copies of my private communication with my Microsoft contact here. I don't think it is appropriate for me to post copies of private communication without the other party's consent, so I will have to decline unless he first gives me said consent. Others have asked for valid contact information for the Microsoft NOC, since the ARIN records for their 207.46.0.0/16 do not appear to be up to date. I eventually found a working e-mail address from somebody off-list who pointed to the WHOIS lookup from TUCOWS for microsoft.comosoft.com (which I'm still not clear on what exactly this is...). The e-mail address that was gleaned from this lookup was msnhst at microsoft.com, which goes to the Microsoft Corporate Domains Team. They, in turn, forwarded my message on to msnalerts at microsoft.com, which generated a ticket # for me and is, as I understand it, the e-mail address I was looking for in the first place (leads to their network/system people). I hope this is helpful to others. Regards, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Wed May 7 14:38:32 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 12:38:32 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <30937.1210187359@turing-police.cc.vt.edu> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> <4820CD9F.1020308@fsr.com> <600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com> <4821F9FA.4020306@fsr.com> <30937.1210187359@turing-police.cc.vt.edu> Message-ID: <48220538.1070005@fsr.com> Valdis.Kletnieks at vt.edu wrote: > The usual case where you get screwed over is when the router trying to toss > the ICMP FRAG NEEDED is *behind* the ICMP-munching firewall. And in case (2), > you still can't assume that path MTU == local MTU, because your local MTU is > likely 1500, and the fragging router often trying to stuff your 1500 byte > packet down an PPPoE tunnel that's got an MTU of 1492.... Yes, but my point was precisely that one OR the other side (server OR client) is going to NOT have the ICMP-munching firewall in between itself and the "RITM" as I have affectionately been calling it (although it is definitely possible that there are two ICMP-munchers on either side of the RITM). And case #2 is exactly what is occurring right now _anyway_: hosts assume that path MTU == local MTU even if there is already an active PMTU cache entry from a recent earlier communication with the remote host. So I don't see how making that assumption _after_ making an honest attempt at actively determining whether or not it is actually the case is any more broken than they way things are already being done. The problem is that, as I realized at the end of the message you quoted, there are potentially multiple paths between the same two hosts, and the path that the packet takes in one direction is not guaranteed to be the same path that the packet takes in the opposite direction. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From tomb at byrneit.net Wed May 7 14:43:49 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 7 May 2008 12:43:49 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <48220538.1070005@fsr.com> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk><3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com><4820CD9F.1020308@fsr.com><600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com><4821F9FA.4020306@fsr.com><30937.1210187359@turing-police.cc.vt.edu> <48220538.1070005@fsr.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F135@pascal.zaphodb.org> I'm not sure what the issue is here. Just about every modern firewall I've used has an option to enable PMTU on interfaces, while blocking all other ICMP. Is MS not running something manufactured in the last 10 years at their perimeter? > -----Original Message----- > From: Nathan Anderson/FSR [mailto:nathana at fsr.com] > Sent: Wednesday, May 07, 2008 12:39 PM > To: Valdis.Kletnieks at vt.edu > Cc: nanog at merit.edu > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > Valdis.Kletnieks at vt.edu wrote: > > > The usual case where you get screwed over is when the > router trying to > > toss the ICMP FRAG NEEDED is *behind* the ICMP-munching > firewall. And > > in case (2), you still can't assume that path MTU == local MTU, > > because your local MTU is likely 1500, and the fragging > router often > > trying to stuff your 1500 byte packet down an PPPoE tunnel > that's got an MTU of 1492.... > > Yes, but my point was precisely that one OR the other side (server OR > client) is going to NOT have the ICMP-munching firewall in > between itself and the "RITM" as I have affectionately been > calling it (although it is definitely possible that there are > two ICMP-munchers on either side of the RITM). > > And case #2 is exactly what is occurring right now _anyway_: > hosts assume that path MTU == local MTU even if there is > already an active PMTU cache entry from a recent earlier > communication with the remote host. So I don't see how > making that assumption _after_ making an honest attempt at > actively determining whether or not it is actually the case > is any more broken than they way things are already being done. > > The problem is that, as I realized at the end of the message > you quoted, there are potentially multiple paths between the > same two hosts, and the path that the packet takes in one > direction is not guaranteed to be the same path that the > packet takes in the opposite direction. > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From michael at rancid.berkeley.edu Wed May 7 14:46:06 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 07 May 2008 12:46:06 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <48220209.8000407@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> Message-ID: <482206FE.3030000@rancid.berkeley.edu> Nathan Anderson/FSR wrote: > Here is a brief update on the situation: > > I have been in contact with someone at Microsoft's service operations > center, who has confirmed for me that MS does in fact block _all_ ICMP > at the edge of their network, that they are aware that this will in fact > break PMTUD, and that they have no current plans to change this practice > which they have implemented in the interest of security. Although the need for your previous apology has already been questioned in this forum, the confirmation that they block not only certain ICMP types, but all ICMP, further vacates the need for any apology for criticizing this behavior in a pubic forum. It is disheartening for those of us who use and support MSFT's products to learn that their understanding of security lacks even the basic nuance to know not to block an entire--critical--portion of the Internet Protocol. Perhaps they should also block _all_ TCP and UDP as well, and then we can move on. I agree with Iljitsch that it happens frequently, but I think I am justified in expecting more than that from Microsoft. Anything less would be unprofessional. *Speaking for myself only, of course!* michael From iljitsch at muada.com Wed May 7 15:35:14 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 May 2008 22:35:14 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <482206FE.3030000@rancid.berkeley.edu> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> Message-ID: <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> On 7 mei 2008, at 21:46, Michael Sinatra wrote: >> MS does in fact block _all_ ICMP >> at the edge of their network, that they are aware that this will in >> fact >> break PMTUD, and that they have no current plans to change this >> practice >> which they have implemented in the interest of security. > Perhaps > they should also block _all_ TCP and UDP as well, and then we can > move on. > I agree with Iljitsch that it happens frequently, but I think I am > justified in expecting more than that from Microsoft. Anything less > would be unprofessional. Right. Now Microsoft is also the company that built the OS that could be crashed by a maliciously crafted fragmented IP packet, so maybe there's something to this security policy. (One hopes that this bug and others like it are now fixed.) However, in that case the only workable course of action would be TO DISABLE PATH MTU DISCOVERY! You can't have your cake and eat it too. From tomb at byrneit.net Wed May 7 15:42:15 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 7 May 2008 13:42:15 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> The remedy you have below is NOT the only one, and is, in fact, a non-sequitur in this case. PMTUD uses the DF (for Don't_Fragment) bit, and works by getting an ICMP Fragmentation needed response from the hop on the path where the packet is too large, not a fragmentation and forward, so the union of PMTUD packets and fragmented ones is 0. The network-level solution to ping of death is to BLOCK fragmented packets, and the way to ensure this doesn't self-deny-service is to perform PMTUD and Black-Hole Router discovery. > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] > Sent: Wednesday, May 07, 2008 1:35 PM > To: Michael Sinatra > Cc: nanog at merit.edu > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > On 7 mei 2008, at 21:46, Michael Sinatra wrote: > > >> MS does in fact block _all_ ICMP > >> at the edge of their network, that they are aware that > this will in > >> fact break PMTUD, and that they have no current plans to > change this > >> practice which they have implemented in the interest of security. > > > Perhaps > > they should also block _all_ TCP and UDP as well, and then > we can move > > on. > > > I agree with Iljitsch that it happens frequently, but I think I am > > justified in expecting more than that from Microsoft. > Anything less > > would be unprofessional. > > Right. > > Now Microsoft is also the company that built the OS that > could be crashed by a maliciously crafted fragmented IP > packet, so maybe there's something to this security policy. > (One hopes that this bug and others like it are now fixed.) > > However, in that case the only workable course of action > would be TO DISABLE PATH MTU DISCOVERY! > > You can't have your cake and eat it too. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From tomb at byrneit.net Wed May 7 15:43:35 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 7 May 2008 13:43:35 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F138@pascal.zaphodb.org> Some Edumacation on the topic is here: http://www.netheaven.com/pmtu.html > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] > Sent: Wednesday, May 07, 2008 1:35 PM > To: Michael Sinatra > Cc: nanog at merit.edu > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > On 7 mei 2008, at 21:46, Michael Sinatra wrote: > > >> MS does in fact block _all_ ICMP > >> at the edge of their network, that they are aware that > this will in > >> fact break PMTUD, and that they have no current plans to > change this > >> practice which they have implemented in the interest of security. > > > Perhaps > > they should also block _all_ TCP and UDP as well, and then > we can move > > on. > > > I agree with Iljitsch that it happens frequently, but I think I am > > justified in expecting more than that from Microsoft. > Anything less > > would be unprofessional. > > Right. > > Now Microsoft is also the company that built the OS that > could be crashed by a maliciously crafted fragmented IP > packet, so maybe there's something to this security policy. > (One hopes that this bug and others like it are now fixed.) > > However, in that case the only workable course of action > would be TO DISABLE PATH MTU DISCOVERY! > > You can't have your cake and eat it too. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From nathana at fsr.com Wed May 7 16:00:27 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 14:00:27 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F135@pascal.zaphodb.org> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk><3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com><4820CD9F.1020308@fsr.com><600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com><4821F9FA.4020306@fsr.com><30937.1210187359@turing-police.cc.vt.edu> <48220538.1070005@fsr.com> <70D072392E56884193E3D2DE09C097A9F135@pascal.zaphodb.org> Message-ID: <4822186B.1080006@fsr.com> Tomas L. Byrnes wrote: > I'm not sure what the issue is here. > > Just about every modern firewall I've used has an option to enable PMTU > on interfaces, while blocking all other ICMP. > > Is MS not running something manufactured in the last 10 years at their > perimeter? Not sure, but you actually entered in here to a subthread of the original conversation, this one about other possible ways of dealing with black hole "ICMP-munchers" in a pre-emptive fashion. I had a brainstorm that I thought would be workable, which is what we were discussing here. Apparently, it turns out my idea was no good. ;-) The original discussion about MS blocking ICMP to their own servers, which is the discussion it sounds like you are looking for, is over that-a-way... *points* -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From auser at mind.net Wed May 7 16:05:22 2008 From: auser at mind.net (S. Ryan) Date: Wed, 07 May 2008 14:05:22 -0700 Subject: [NANOG] Charter - Southern Oregon routing issues Message-ID: <48221992.3030500@mind.net> I've called Charter and they deny they have an issue. I'm looking to speak to a Charter engineer who can specifically help with issues in the Southern Oregon service area. Multiple customers cannot check mail on 110 or use port 25 or 587. Looks like a loop: traceroute to 204.16.46.136 (204.16.46.136), 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 2.143 ms 1.168 ms 0.849 ms 2 10.218.0.1 (10.218.0.1) 8.523 ms 8.551 ms 14.098 ms 3 ge5-2.cr01.mdfd.or.charter.com (68.185.17.113) 31.033 ms 10.993 ms 9.398 ms 4 68-116-79-133.or.charter.com (68.116.79.133) 11.145 ms 18.148 ms 10.23 ms 5 68-116-79-134.or.charter.com (68.116.79.134) 19.288 ms 9.768 ms 14.054 ms 6 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.881 ms 12.468 ms 10.898 ms 7 68-116-79-134.or.charter.com (68.116.79.134) 16.426 ms 10.631 ms 11.4 ms 8 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.317 ms 10.047 ms 9.315 ms 9 68-116-79-134.or.charter.com (68.116.79.134) 11.117 ms 9.992 ms * 10 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.928 ms 20.391 ms 9.513 ms 11 68-116-79-134.or.charter.com (68.116.79.134) 11.349 ms 10.413 ms 10.222 ms 12 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 20.722 ms 9.746 ms 9.99 ms 13 68-116-79-134.or.charter.com (68.116.79.134) 10.682 ms 11.198 ms 11.253 ms 14 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.376 ms 21.943 ms 10.914 ms 15 68-116-79-134.or.charter.com (68.116.79.134) 11.039 ms 9.778 ms 17.995 ms 16 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 13.068 ms 10.622 ms 13.206 ms 17 68-116-79-134.or.charter.com (68.116.79.134) 11.783 ms 11.17 ms 9.351 ms 18 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 15.859 ms 13.637 ms 18.188 ms 19 68-116-79-134.or.charter.com (68.116.79.134) 9.532 ms 14.751 ms 16.703 ms 20 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.073 ms 11.547 ms 10.913 ms 21 68-116-79-134.or.charter.com (68.116.79.134) 18.878 ms 9.844 ms 17.044 ms 22 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 17.192 ms 12.964 ms 10.855 ms 23 68-116-79-134.or.charter.com (68.116.79.134) 9.931 ms 13.66 ms 17.299 ms 24 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.794 ms 11.108 ms 16.129 ms 25 68-116-79-134.or.charter.com (68.116.79.134) 17.288 ms 14.043 ms 12.522 ms 26 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 11.771 ms 14.531 ms 11.148 ms 27 68-116-79-134.or.charter.com (68.116.79.134) 11.697 ms 10.318 ms 9.069 ms 28 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.885 ms 15.104 ms 13.287 ms 29 68-116-79-134.or.charter.com (68.116.79.134) 21.404 ms 12.868 ms 10.294 ms 30 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.807 ms 11.742 ms 12.197 ms Thank you for any assistance. I've even contacted Tier III at Charter and they're unwilling to help at all. I'm shocked they have a customer base still. Regards, Steve Ryan 541-842-8207 From nathana at fsr.com Wed May 7 16:08:22 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 14:08:22 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> <70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> Message-ID: <48221A46.80708@fsr.com> Tomas L. Byrnes wrote: > The remedy you have below is NOT the only one, and is, in fact, a > non-sequitur in this case. How so? Iljitsch is suggesting that ICMP blockers originate packets without DF set if they are going to block the ICMP messages that PMTUD needs in order to work in the first place. That's what (I think) he means by "disabling path MTU discovery." > The network-level solution to ping of death is to BLOCK fragmented > packets, and the way to ensure this doesn't self-deny-service is to > perform PMTUD and Black-Hole Router discovery. Which end are you talking about here, the servers or the client? If the servers, how do you expect them to do PMTUD if they _can't hear the ICMP messages_? Also, for some reason, as I pointed out before, XP black hole router discovery doesn't seem to be working for me for whatever reason. Does anybody have any clue why that might be the case? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Wed May 7 16:16:35 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 14:16:35 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F138@pascal.zaphodb.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> <70D072392E56884193E3D2DE09C097A9F138@pascal.zaphodb.org> Message-ID: <48221C33.9050006@fsr.com> Tomas L. Byrnes wrote: > Some Edumacation on the topic is here: You do know who it is that you are responding to, right? :) http://www.oreillynet.com/pub/au/970 -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From michael at rancid.berkeley.edu Wed May 7 16:16:50 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 07 May 2008 14:16:50 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <20080507195932.5B75845010@ptavv.es.net> References: <20080507195932.5B75845010@ptavv.es.net> Message-ID: <48221C42.4020804@rancid.berkeley.edu> Kevin Oberman wrote: >> I agree with Iljitsch that it happens frequently, but I think I am >> justified in expecting more than that from Microsoft. Anything less >> would be unprofessional. > > And you would consider an organization that threatens someone who > complains publicly about its obvious incompetence "professional"? Absolutely not. That was actually the point of my statement, although I admit that it wasn't clear. > Many of Microsoft's people are highly professional, but the corporation, > as a whole, has been found to be large scale law breakers on two > continents and frequently incapable of even the most basic of technical > operations. I'm afraid that I don't see them as at all "professional". I > quit expecting any such behavior from them over a decade ago, probably > closer to two. And mentioning security and Microsoft is inviting bad > jokes and shudders. > > * Speaking only for myself * Agreed. michael From iljitsch at muada.com Wed May 7 16:19:59 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 May 2008 23:19:59 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <48221A46.80708@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> <70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> <48221A46.80708@fsr.com> Message-ID: On 7 mei 2008, at 23:08, Nathan Anderson/FSR wrote: > How so? Iljitsch is suggesting that ICMP blockers originate packets > without DF set if they are going to block the ICMP messages that PMTUD > needs in order to work in the first place. That's what (I think) he > means by "disabling path MTU discovery." Yes. > Also, for some reason, as I pointed out before, XP black hole router > discovery doesn't seem to be working for me for whatever reason. Does > anybody have any clue why that might be the case? The problem is in the direction from M$ to you, so you can't fix that from your end. I wonder if they've installed SP3 on their servers... From tomb at byrneit.net Wed May 7 16:20:55 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 7 May 2008 14:20:55 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <48221A46.80708@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com><70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> <48221A46.80708@fsr.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F13A@pascal.zaphodb.org> I was responding to his post that blocking or disabling PMTUD was the way to avoid the ping of death, which is False, nothing more, nothing less. As far as who Iljitsch is, everyone misspeaks from time to time. Even those of us who have been at this for nearly 3 decades. > -----Original Message----- > From: Nathan Anderson/FSR [mailto:nathana at fsr.com] > Sent: Wednesday, May 07, 2008 2:08 PM > To: nanog at merit.edu > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > Tomas L. Byrnes wrote: > > > The remedy you have below is NOT the only one, and is, in fact, a > > non-sequitur in this case. > > How so? Iljitsch is suggesting that ICMP blockers originate > packets without DF set if they are going to block the ICMP > messages that PMTUD needs in order to work in the first > place. That's what (I think) he means by "disabling path MTU > discovery." > > > The network-level solution to ping of death is to BLOCK fragmented > > packets, and the way to ensure this doesn't self-deny-service is to > > perform PMTUD and Black-Hole Router discovery. > > Which end are you talking about here, the servers or the > client? If the servers, how do you expect them to do PMTUD > if they _can't hear the ICMP messages_? > > Also, for some reason, as I pointed out before, XP black hole > router discovery doesn't seem to be working for me for > whatever reason. Does anybody have any clue why that might > be the case? > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From auser at mind.net Wed May 7 16:30:41 2008 From: auser at mind.net (S. Ryan) Date: Wed, 07 May 2008 14:30:41 -0700 Subject: [NANOG] Charter - Southern Oregon routing issues In-Reply-To: <48221992.3030500@mind.net> References: <48221992.3030500@mind.net> Message-ID: <48221F81.9090504@mind.net> This issue is now resolved for the time being. It went on for 2+ hours. Sorry for the noise. Regards, Steve S. Ryan wroteth on 5/7/2008 2:05 PM: > I've called Charter and they deny they have an issue. I'm looking to > speak to a Charter engineer who can specifically help with issues in the > Southern Oregon service area. > > Multiple customers cannot check mail on 110 or use port 25 or 587. > > Looks like a loop: > > traceroute to 204.16.46.136 (204.16.46.136), 30 hops max, 40 byte packets > 1 192.168.1.1 (192.168.1.1) 2.143 ms 1.168 ms 0.849 ms > 2 10.218.0.1 (10.218.0.1) 8.523 ms 8.551 ms 14.098 ms > 3 ge5-2.cr01.mdfd.or.charter.com (68.185.17.113) 31.033 ms 10.993 ms > 9.398 ms > 4 68-116-79-133.or.charter.com (68.116.79.133) 11.145 ms 18.148 ms > 10.23 ms > 5 68-116-79-134.or.charter.com (68.116.79.134) 19.288 ms 9.768 ms > 14.054 ms > 6 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.881 ms 12.468 ms > 10.898 ms > 7 68-116-79-134.or.charter.com (68.116.79.134) 16.426 ms 10.631 ms > 11.4 > ms > 8 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.317 ms 10.047 ms 9.315 > ms > 9 68-116-79-134.or.charter.com (68.116.79.134) 11.117 ms 9.992 ms * > 10 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.928 ms 20.391 ms 9.513 > ms > 11 68-116-79-134.or.charter.com (68.116.79.134) 11.349 ms 10.413 ms > 10.222 ms > 12 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 20.722 ms 9.746 ms 9.99 > ms > 13 68-116-79-134.or.charter.com (68.116.79.134) 10.682 ms 11.198 ms > 11.253 ms > 14 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.376 ms 21.943 ms > 10.914 ms > 15 68-116-79-134.or.charter.com (68.116.79.134) 11.039 ms 9.778 ms > 17.995 ms > 16 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 13.068 ms 10.622 ms > 13.206 ms > 17 68-116-79-134.or.charter.com (68.116.79.134) 11.783 ms 11.17 ms 9.351 > ms > 18 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 15.859 ms 13.637 ms > 18.188 ms > 19 68-116-79-134.or.charter.com (68.116.79.134) 9.532 ms 14.751 ms > 16.703 ms > 20 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.073 ms 11.547 ms > 10.913 ms > 21 68-116-79-134.or.charter.com (68.116.79.134) 18.878 ms 9.844 ms > 17.044 ms > 22 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 17.192 ms 12.964 ms > 10.855 ms > 23 68-116-79-134.or.charter.com (68.116.79.134) 9.931 ms 13.66 ms 17.299 > ms > 24 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 21.794 ms 11.108 ms > 16.129 ms > 25 68-116-79-134.or.charter.com (68.116.79.134) 17.288 ms 14.043 ms > 12.522 ms > 26 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 11.771 ms 14.531 ms > 11.148 ms > 27 68-116-79-134.or.charter.com (68.116.79.134) 11.697 ms 10.318 ms > 9.069 ms > 28 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 9.885 ms 15.104 ms 13.287 > ms > 29 68-116-79-134.or.charter.com (68.116.79.134) 21.404 ms 12.868 ms > 10.294 ms > 30 g1-0.er01.mdfd.or.charter.com (68.116.79.1) 10.807 ms 11.742 ms > 12.197 ms > > Thank you for any assistance. I've even contacted Tier III at Charter > and they're unwilling to help at all. I'm shocked they have a customer > base still. > > Regards, > > Steve Ryan > 541-842-8207 > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From iljitsch at muada.com Wed May 7 16:40:02 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 7 May 2008 23:40:02 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F13A@pascal.zaphodb.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com><70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> <48221A46.80708@fsr.com> <70D072392E56884193E3D2DE09C097A9F13A@pascal.zaphodb.org> Message-ID: <3B6C6D35-226C-47EA-A5DE-EC2B16AC82E9@muada.com> On 7 mei 2008, at 23:20, Tomas L. Byrnes wrote: > I was responding to his post that blocking or disabling PMTUD was the > way to avoid the ping of death, which is False, nothing more, nothing > less. I never said that disabling PMTUD will get rid of the ping of death, what I said was that if your system is susceptible to a ping of death you may be tempted to filter ICMP but if you do that then you need to disable PMTUD because PMTUD + ICMP filtering = breakage. > As far as who Iljitsch is, everyone misspeaks from time to time. Even > those of us who have been at this for nearly 3 decades. After making the jump to academia I often feel a bit long in the tooth between all these students. But considering that (apparently) some people have been posting flames on NANOG for 30 years makes me feel young in comparison. :-) From tomb at byrneit.net Wed May 7 16:45:51 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 7 May 2008 14:45:51 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <3B6C6D35-226C-47EA-A5DE-EC2B16AC82E9@muada.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com><70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> <48221A46.80708@fsr.com> <70D072392E56884193E3D2DE09C097A9F13A@pascal.zaphodb.org> <3B6C6D35-226C-47EA-A5DE-EC2B16AC82E9@muada.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F13B@pascal.zaphodb.org> Sorry if I misunderstood what you were saying. I thought you said that they couldn't have their cake and eat it too, as in protect against Ping of death, AND do PMTUD. As for those flames, well, that was a long time ago, in a valley not too far from here ;-). Can we have the 'net before the endless September back? > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] > Sent: Wednesday, May 07, 2008 2:40 PM > To: Tomas L. Byrnes > Cc: nanog at merit.edu > Subject: Re: [NANOG] Microsoft.com PMTUD black hole? > > On 7 mei 2008, at 23:20, Tomas L. Byrnes wrote: > > > I was responding to his post that blocking or disabling > PMTUD was the > > way to avoid the ping of death, which is False, nothing > more, nothing > > less. > > I never said that disabling PMTUD will get rid of the ping of > death, what I said was that if your system is susceptible to > a ping of death you may be tempted to filter ICMP but if you > do that then you need to disable PMTUD because PMTUD + ICMP > filtering = breakage. > > > As far as who Iljitsch is, everyone misspeaks from time to > time. Even > > those of us who have been at this for nearly 3 decades. > > After making the jump to academia I often feel a bit long in > the tooth between all these students. But considering that > (apparently) some people have been posting flames on NANOG > for 30 years makes me feel young in comparison. :-) > From nathana at fsr.com Wed May 7 16:47:13 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 14:47:13 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> <70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> <48221A46.80708@fsr.com> Message-ID: <48222361.8030506@fsr.com> Iljitsch van Beijnum wrote: > The problem is in the direction from M$ to you, so you can't fix that > from your end. I wonder if they've installed SP3 on their servers... Ah, you are right. I re-read the section on black-hole detection in http://technet.microsoft.com/en-us/library/bb878081.aspx more closely this time, and found that, yes, it only helps if the host trying to send the large packets has the feature enabled: "When PMTU black hole router detection is enabled, TCP tries to send segments with the DF flag set to 0 after several retransmissions of a segment are not acknowledged. If a segment with the DF flag set to 0 is acknowledged, the MSS is decreased and the DF flag is set to 1 in subsequent segments on the connection. Enabling PMTU black hole detection increases the maximum number of retransmissions that are performed for a given segment, and therefore has an effect on overall performance." I for some reason interpreted the advertisement of the black hole detection feature as being a help to clients impacted by the inability of the server to perform PMTUD. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From nathana at fsr.com Wed May 7 16:50:12 2008 From: nathana at fsr.com (Nathan Anderson/FSR) Date: Wed, 07 May 2008 14:50:12 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F13A@pascal.zaphodb.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org><48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com><70D072392E56884193E3D2DE09C097A9F137@pascal.zaphodb.org> <48221A46.80708@fsr.com> <70D072392E56884193E3D2DE09C097A9F13A@pascal.zaphodb.org> Message-ID: <48222414.7090201@fsr.com> Tomas L. Byrnes wrote: > As far as who Iljitsch is, everyone misspeaks from time to time. Even > those of us who have been at this for nearly 3 decades. I was simply LOLing at the fact that you found it necessary to give him a link to the NetHeaven article is all. ;-) -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From deepak at ai.net Wed May 7 17:07:06 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 07 May 2008 18:07:06 -0400 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <48220209.8000407@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> Message-ID: <4822280A.2030506@ai.net> Nathan Anderson/FSR wrote: > Nevertheless, the person I have been in contact with is naturally not > the final decision-maker on this issue and is going to continue to pass > the issue on up the chain of command for me. So although this issue is > not over and I do not have a final verdict from MS yet, I felt that, > given that I don't know how much time to expect to pass between now and > when that final verdict is rendered, it would be appropriate to let > everybody here know what I have learned thus far. Hopefully public > dissemination of this information factoid will prevent others in a > position similar to mine from having to helplessly beat their heads into > their keyboards. Let's also not ignore the generally overworked IT administrator at any small or medium sized enterprise. He/she may not be (as many folks I've run into are) of the mistaken impression that ICMP *is* bad and leaves you vulnerable to all sorts of things like SMURF. There are even tools out there that "test" your vulnerability by "pinging" you and do other investigations. I know of a tool that a major financial institution uses when certifying your networks security -- that scrapes the version number from your ESTMP banner to decide whether you comply or not (and other banners). (Rather than actually testing for a specific vulnerability). Simply blocking all of these packets from their test host gives you a high passing score; possibly a perfect one. [Irony and humor aside...] Many non-SP IT folks think they understand TCP, grudgingly accept UDP for DNS from external sources and think everything else is bollocks. Many *might* have a fit if they saw Microsoft accepting ICMPs because that seems inconsistent with their knowledge of turn-the-knob network security. To their view, their Linksys/Netgear/whathaveyou COTS firewalls block everything too. I don't think I'm exaggerating here. Just a thought, not saying its a good one or whose fault it is... Deepak Jain AiNET From sml at lordsargon.com Wed May 7 17:18:51 2008 From: sml at lordsargon.com (SML) Date: Wed, 7 May 2008 17:18:51 -0500 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4822280A.2030506@ai.net> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <4822280A.2030506@ai.net> Message-ID: On 7-May-2008, at 17:07:06, Deepak Jain wrote: > Many non-SP IT folks think they understand TCP, grudgingly accept > UDP for DNS from external sources and think everything else is > bollocks. Many *might* have a fit if they saw Microsoft accepting > ICMPs because that seems inconsistent with their knowledge of turn- > the-knob network security. To their view, their Linksys/Netgear/ > whathaveyou COTS firewalls block everything too. > > I don't think I'm exaggerating here. No, you are not. I have seen the same from "firewall engineers" at large companies, people who, supposedly, have done "network security" for years. Even after showing them numerous Web sites detailing current best practices, especially Rob Thomas's fine site, these folks would not change their practices. Some days it is hard to not give in to the "I give up" feelings. From rs at seastrom.com Wed May 7 19:22:06 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 07 May 2008 20:22:06 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <481B9273.5060106@psg.com> (Randy Bush's message of "Sat, 03 May 2008 07:15:15 +0900") References: <481B8D4B.3080304@ai.net> <9FDEFA43-E45F-48DC-913E-419143B1835F@consultant.com> <481B9273.5060106@psg.com> Message-ID: <86wsm54pch.fsf@seastrom.com> Randy Bush writes: > back office software > ip and dns management software > provisioning tools > cpe > measurement and monitoring and billing > > and, of course, backbone and aggregation equipment that can actually > handle real ipv6 traffic flows with acls and chocolate syrup. chiming in late here... the situation on the edge (been looking at a lot of gpon gear lately) is pretty dismal. i won't bother mentioning the vendor who claimed their igmp implementation supported ipv6 "just fine - we're a layer 2 device; it's plug-and-play". srsly. ---rob From bjorn at mork.no Thu May 8 02:00:19 2008 From: bjorn at mork.no (=?iso-8859-1?Q?Bj=F8rn_Mork?=) Date: Thu, 08 May 2008 09:00:19 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> (Iljitsch van Beijnum's message of "Wed, 7 May 2008 22:35:14 +0200") References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> Message-ID: <87iqxp2scc.fsf@obelix.mork.no> Iljitsch van Beijnum writes: > Now Microsoft is also the company that built the OS that could be > crashed by a maliciously crafted fragmented IP packet, so maybe > there's something to this security policy. (One hopes that this bug > and others like it are now fixed.) Although the fact that Microsoft block all icmp makes me wonder which unfixed icmp related security holes they know about... I am not saying that there are any such holes in current Windows versions, but I will certainly not use a Windows server in an environment where I could receive icmp after learning that Microsoft themselves don't trust Windows' icmp handling. After all, Microsoft must have a reason to block all icmp. Or? > However, in that case the only workable course of action would be TO > DISABLE PATH MTU DISCOVERY! > > You can't have your cake and eat it too. But maybe the death of icmp is worth some sort of ceremony? Cake or not. Bj?rn From joelja at bogus.com Thu May 8 02:53:23 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 08 May 2008 00:53:23 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <87iqxp2scc.fsf@obelix.mork.no> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> <87iqxp2scc.fsf@obelix.mork.no> Message-ID: <4822B173.3070001@bogus.com> Bj?rn Mork wrote: > Iljitsch van Beijnum writes: > After all, Microsoft must have a reason to block all icmp. Or? > >> However, in that case the only workable course of action would be TO >> DISABLE PATH MTU DISCOVERY! >> >> You can't have your cake and eat it too. > > But maybe the death of icmp is worth some sort of ceremony? Cake or > not. Oddly enough there is a draft on the subject of icmp filtering recomendations is making the rounds. http://tools.ietf.org/wg/opsec/draft-gont-opsec-icmp-filtering-00.txt The opsec working group (opsec at ietf.org) and the authors would appreciate feedback from operators on the subject. thanks joelja > Bj?rn > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From gbromley at intstar.com Thu May 8 04:16:11 2008 From: gbromley at intstar.com (gbromley at intstar.com) Date: Thu, 08 May 2008 10:16:11 +0100 Subject: [NANOG] Looking for Flickr contacts Message-ID: I am having a bit of difficulty resolving a Flickr issue. Can someone point me to contact in Flickr? Cheers Gareth From iljitsch at muada.com Thu May 8 04:24:17 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 8 May 2008 11:24:17 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4822B173.3070001@bogus.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com> <87iqxp2scc.fsf@obelix.mork.no> <4822B173.3070001@bogus.com> Message-ID: <1A7291F3-532F-4596-8E25-0082DC9A9660@muada.com> On 8 mei 2008, at 9:53, Joel Jaeggli wrote: > Oddly enough there is a draft on the subject of icmp filtering > recomendations is making the rounds. > http://tools.ietf.org/wg/opsec/draft-gont-opsec-icmp-filtering-00.txt > The opsec working group (opsec at ietf.org) and the authors would > appreciate feedback from operators on the subject. Speaking as someone who isn't interested in reading an explanation of what happens when the message is filtered for every ICMP message known to man, I find this a completely useless document: I can't find the recommendations. Either they're there but impossible to find by looking at the table of contents or searching for "recommend", or they're not there in which case the title is EXTREMELY misleading. Also: 2.1.1.5.4. Operational/interoperability impact if blocked Filtering this error message breaks the Path-MTU Discovery mechansim described in [RFC1191]. This is completely insufficient because it doesn't mention that 99% of all TCP traffic on today's internet uses PMTUD and filtering these messages leads to broken connectivity towards destinations that have an MTU lower than the source (lower than 1500 in practice). Please spell check and five levels of numbering is considered bad style. From dot at dotat.at Thu May 8 07:54:41 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 8 May 2008 13:54:41 +0100 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <4822280A.2030506@ai.net> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <4822280A.2030506@ai.net> Message-ID: On Wed, 7 May 2008, Deepak Jain wrote: > > I know of a tool that a major financial institution uses when certifying > your networks security -- that scrapes the version number from your > ESTMP banner to decide whether you comply or not (and other banners). > (Rather than actually testing for a specific vulnerability). Simply > blocking all of these packets from their test host gives you a high > passing score; possibly a perfect one. [Irony and humor aside...] Cisco PIX/ASA firewalls in SMTP fuxup mode are so incredibly broken. Possibly the worst SMTP implementation ever. Tony. -- f.anthony.n.finch http://dotat.at/ FISHER GERMAN BIGHT: VARIABLE 3, BUT EASTERLY 4 OR 5 IN SOUTH GERMAN BIGHT. SLIGHT. FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From netsecguy at gmail.com Thu May 8 08:25:06 2008 From: netsecguy at gmail.com (NetSecGuy) Date: Thu, 8 May 2008 09:25:06 -0400 Subject: [NANOG] PCH BGP Archive down? Message-ID: <2ed0bc680805080625x9f19a33le47d5cfd231cbb01@mail.gmail.com> Anyone else not able to access the PCH BGP Archive? http://www.pch.net/resources/data/routing-tables/archive/ I'm getting a 403 Forbidden. From woody at pch.net Thu May 8 09:27:26 2008 From: woody at pch.net (Bill Woodcock) Date: Thu, 8 May 2008 07:27:26 -0700 (PDT) Subject: [NANOG] PCH BGP Archive down? In-Reply-To: <2ed0bc680805080625x9f19a33le47d5cfd231cbb01@mail.gmail.com> References: <2ed0bc680805080625x9f19a33le47d5cfd231cbb01@mail.gmail.com> Message-ID: On Thu, 8 May 2008, NetSecGuy wrote: > Anyone else not able to access the PCH BGP Archive? > http://www.pch.net/resources/data/routing-tables/archive/ > I'm getting a 403 Forbidden. Oop, you're right, I just replicated the problem, about to take a look at fixing it. Our apologies. You're always welcome to open a ticket with email to noc at pch.net when we're not doing the right thing, of course, with respect to this or any of the other tools we support. -Bill From woody at pch.net Thu May 8 10:33:40 2008 From: woody at pch.net (Bill Woodcock) Date: Thu, 8 May 2008 08:33:40 -0700 (PDT) Subject: [NANOG] PCH BGP Archive down? In-Reply-To: <2ed0bc680805080625x9f19a33le47d5cfd231cbb01@mail.gmail.com> References: <2ed0bc680805080625x9f19a33le47d5cfd231cbb01@mail.gmail.com> Message-ID: On Thu, 8 May 2008, NetSecGuy wrote: > Anyone else not able to access the PCH BGP Archive? > http://www.pch.net/resources/data/routing-tables/archive/ > I'm getting a 403 Forbidden. Fixed again now. The front-end web server was having trouble with its connection to the back-end database. Our apologies. -Bill From blaine at blaines.net Thu May 8 11:27:49 2008 From: blaine at blaines.net (Blaine Christian) Date: Thu, 8 May 2008 09:27:49 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <4822280A.2030506@ai.net> Message-ID: <000001c8b128$8041e730$80c5b590$@net> First of all I would like to thank everyone for their support and concern. We certainly have a lot of things to "fix" at Microsoft. In fact, I can tell you that we have several brand new positions open (working on my team and for teams near mine) and could use more hands at the tiller. My apologies to the moderators for posting a help wanted but I figure since folks are expressing concerns with Microsoft networking they should have the opportunity to come over and help. We have an INCREDIBLE amount of interesting work ahead of us. I can't really speak to it directly but I can tell you that this is a really good place to be if you think big. We have a very interesting playbook for the next few years. Keep in mind that this is one of the few spots where thinking big can actually result in action. The current positions... Principal Network Engineer 204091 Senior Network Engineer 185014 SR PM 220793 IT/Ops PM 2 220797 Network Engineer 3 226032 Group Manager, Core Engineering 227621 Senior Network Engineer 229347 BOSD Network Engineer 231413 BOSD Senior Network Engineer 231414 If you think you have what it takes go check out these positions at http://www.microsoft.com/careers and apply (the numbers to the right are the job codes). Microsoft is an incredible place to work if you truly enjoy what you do. To be honest I don't read as much NANOG as I did a number of years ago. I had a couple friends point this thread out to me. I hope you are all doing well. Regards, Blaine From Donald.Smith at qwest.com Thu May 8 12:19:41 2008 From: Donald.Smith at qwest.com (Smith, Donald) Date: Thu, 8 May 2008 11:19:41 -0600 Subject: [NANOG] [OPSEC] Microsoft.com PMTUD black hole? In-Reply-To: <1A7291F3-532F-4596-8E25-0082DC9A9660@muada.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com><20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com><482206FE.3030000@rancid.berkeley.edu> <6536F6AA-0810-4255-8116-510FBB9D24A4@muada.com><87iqxp2scc.fsf@obelix.mork.no> <4822B173.3070001@bogus.com> <1A7291F3-532F-4596-8E25-0082DC9A9660@muada.com> Message-ID: A few comments on your comments below. RM=for(1) {manage_risk(identify_risk(product[i++]) && (identify_threat[product[i++]))} Donald.Smith at qwest.com giac > -----Original Message----- > From: opsec-bounces at ietf.org [mailto:opsec-bounces at ietf.org] > On Behalf Of Iljitsch van Beijnum > Sent: Thursday, May 08, 2008 3:24 AM > To: Joel Jaeggli > Cc: guillermo at gont.com.ar; opsec at ietf.org; NANOG list > Subject: Re: [OPSEC] [NANOG] Microsoft.com PMTUD black hole? > > On 8 mei 2008, at 9:53, Joel Jaeggli wrote: > > > Oddly enough there is a draft on the subject of icmp filtering > > recomendations is making the rounds. > > > > http://tools.ietf.org/wg/opsec/draft-gont-opsec-icmp-filtering-00.txt > > > The opsec working group (opsec at ietf.org) and the authors would > > appreciate feedback from operators on the subject. > > Speaking as someone who isn't interested in reading an > explanation of > what happens when the message is filtered for every ICMP > message known > to man, I find this a completely useless document: I can't find the > recommendations. Either they're there but impossible to find by > looking at the table of contents or searching for "recommend", or > they're not there in which case the title is EXTREMELY misleading. I believe a table of what to filter where was recommended. I hope that table includes filtering and ratelimiting from, through, and to. However blindly accepting recommendations without understanding the possibly ramifications such filtering can have on your network is not wise. > > Also: > > 2.1.1.5.4. Operational/interoperability impact if blocked Filtering > this error message breaks the Path-MTU Discovery mechansim described > in [RFC1191]. > > This is completely insufficient because it doesn't mention > that 99% of > all TCP traffic on today's internet uses PMTUD and filtering these > messages leads to broken connectivity towards destinations that have > an MTU lower than the source (lower than 1500 in practice). I suspect your statistics. I don't believe the number is anywhere near 99% but haven't seen a study that would support any actual % numbers of traffic that relies on PMTUD. If your aware of such a study/research I would be interested in reviewing the results. Again filtering THROUGH a device is probably not advisable filtering TO your device might be advisable. > > Please spell check and five levels of numbering is considered > bad style. > _______________________________________________ > OPSEC mailing list > OPSEC at ietf.org > https://www.ietf.org/mailman/listinfo/opsec > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From surfer at mauigateway.com Thu May 8 13:21:57 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 8 May 2008 11:21:57 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? Message-ID: <20080508112157.C109CD13@resin17.mta.everyone.net> ---------- blaine at blaines.net wrote: --------------- First of all I would like to thank everyone for their support and concern. We certainly have a lot of things to "fix" at Microsoft. In fact, I can tell you that we have several brand new positions open (working on my team and for teams near mine) and could use more hands at the tiller. My apologies to the moderators for posting a help wanted but I figure since folks are expressing concerns with Microsoft networking they should have the opportunity to come over and help. --------------------------------------------------- Not support. Concern about M$ on soooo many levels. Your apologies should go to the other 10,000 folks that had to endure your improper email: http://www.nanog.org/listfaq.html#nocjobs -------------------------------------------- BOSD Network Engineer 231413 BOSD Senior Network Engineer 231414 -------------------------------------------- heh, you mean BSOD engineer? ;-) scott ---------------------------- From hank at efes.iucc.ac.il Thu May 8 16:10:12 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 9 May 2008 00:10:12 +0300 (IDT) Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <482206FE.3030000@rancid.berkeley.edu> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <482206FE.3030000@rancid.berkeley.edu> Message-ID: On Wed, 7 May 2008, Michael Sinatra wrote: > Nathan Anderson/FSR wrote: >> Here is a brief update on the situation: >> >> I have been in contact with someone at Microsoft's service operations >> center, who has confirmed for me that MS does in fact block _all_ ICMP >> at the edge of their network, that they are aware that this will in fact >> break PMTUD, and that they have no current plans to change this practice >> which they have implemented in the interest of security. > > Although the need for your previous apology has already been questioned > in this forum, the confirmation that they block not only certain ICMP > types, but all ICMP, further vacates the need for any apology for > criticizing this behavior in a pubic forum. It is disheartening for > those of us who use and support MSFT's products to learn that their > understanding of security lacks even the basic nuance to know not to > block an entire--critical--portion of the Internet Protocol. Perhaps > they should also block _all_ TCP and UDP as well, and then we can move on. > > I agree with Iljitsch that it happens frequently, but I think I am > justified in expecting more than that from Microsoft. Anything less > would be unprofessional. I wonder if MS knows about: ICMP Packet Filtering v1.2 from 2003: http://www.cymru.com/Documents/icmp-messages.html Only been around 5 years or so. Hopefully MS people reading this email will take note, read the entire page and implement what everyone else has been doing for a number of years. -Hank From netgeek at bgp4.net Thu May 8 16:35:03 2008 From: netgeek at bgp4.net (Janet Sullivan) Date: Thu, 08 May 2008 14:35:03 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? (working with Microsoft on issues) In-Reply-To: <4820AC59.1020909@fsr.com> References: <4820AC59.1020909@fsr.com> Message-ID: <48237207.8090202@bgp4.net> I thought I'd post a few constructive comments on this thread. (Full disclosure: I am an ex-Microsoft employee. I do not speak for the company, I'm just trying to help out the network community.) 1) Yes, Microsoft blocks ICMP for the most part, which will break Path MTU Discovery. This is a known issue. If you run into it, its most likely because the servers you are trying to talk to in MS-land don't have black hole router detection turned on. 2) Instead of trying to get all the various ACLs and firewalls in Microsoft fixed to allow PMTUD, you are more likely to experience joy if you can contact the server owners. Ask if they have black hole router detection turned on, and if not, if they can do so. 3) So how do you get in contact with the server owners or MSN's networking people? msnalert at microsoft.com is your best bet. That's the email address monitored by the basic Tier 1 "Service Operations Center". They cut tickets, follow scripts, and do very basic front line work. They probably won't be able to fix the problem for you, but they CAN get you in touch with the right people. 4) FINDING the right people can be a challenge, even internally. Microsoft is a very big company, and its far from centralized. Be specific in what URLs and IPs you are having trouble with, and be prepared to bounce around a bit. The people who run microsoft.com's servers aren't the same group that does hotmail, etc. Have patience, and try to get ticket numbers for tracking at much as possible. 5) Try to give a realistic estimate of how many users are being impacted by the problem. Your problem will be triaged as it moves through various groups, and yes, the response time may not be what you want. Your problem is one fire among many, and there aren't enough firefighters. 6) Be nice. Seriously. People love to hate Microsoft, and sometimes take it out on the poor overworked geeks who are trying to actually make things better. Every vulnerability, BSOD, or Vista delay is not the fault of the network or systems engineer you get in touch with. ;-) From niels=nanog at bakker.net Thu May 8 17:44:34 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 9 May 2008 00:44:34 +0200 Subject: [NANOG] Microsoft.com PMTUD black hole? (working with Microsoft on issues) In-Reply-To: <48237207.8090202@bgp4.net> References: <4820AC59.1020909@fsr.com> <48237207.8090202@bgp4.net> Message-ID: <20080508224434.GG3285@burnout.tpb.net> * netgeek at bgp4.net (Janet Sullivan) [Thu 08 May 2008, 23:35 CEST]: >1) Yes, Microsoft blocks ICMP for the most part, which will break Path >MTU Discovery. This is a known issue. If you run into it, its most >likely because the servers you are trying to talk to in MS-land don't >have black hole router detection turned on. I find it hilarious that one part of the company had to come up with a hack to work around the inability of another part of the company to understand how TCP/IP works -- Niels. -- From mitigator at gmail.com Thu May 8 22:04:06 2008 From: mitigator at gmail.com (jamie rishaw) Date: Thu, 8 May 2008 22:04:06 -0500 Subject: [NANOG] auth00/auth100.ns.uu.net down ? Message-ID: <6ff30abd0805082004v640617e2n8d14cff8d6ce012@mail.gmail.com> Anyone seeing the same? VZN engineer : pls contact off list, sev-0 ; <<>> DiG 9.3.3 <<>> cunamutual.com ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32159 From j at arpa.com Thu May 8 22:07:54 2008 From: j at arpa.com (jamie) Date: Thu, 8 May 2008 22:07:54 -0500 Subject: [NANOG] auth*.ns.uu.net Message-ID: <6ff30abd0805082007w5e49cec6hea93fddf851971b8@mail.gmail.com> Anyone seeing the same? Summary : Multiple sites primary'd by auth*.uu.net nses being served SERVFAILs for queries. Implications are obvious VZN : pls contact off list. Meanwhile, we'll be lighting up some phone lines... *nog : TIA, jamie ; <<>> DiG 9.3.3 <<>> cunamutual.com ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32159 From david at davidcoulson.net Thu May 8 22:11:00 2008 From: david at davidcoulson.net (David Coulson) Date: Thu, 08 May 2008 23:11:00 -0400 Subject: [NANOG] auth*.ns.uu.net In-Reply-To: <6ff30abd0805082007w5e49cec6hea93fddf851971b8@mail.gmail.com> References: <6ff30abd0805082007w5e49cec6hea93fddf851971b8@mail.gmail.com> Message-ID: <4823C0C4.1010300@davidcoulson.net> jamie wrote: > Anyone seeing the same? Yep. When you try to dig a domain on their NS, it refers back to the root-servers. Nice. cr1:~# dig cunamutual.com @198.6.1.202 ; <<>> DiG 9.3.4 <<>> cunamutual.com @198.6.1.202 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22286 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;cunamutual.com. IN A ;; AUTHORITY SECTION: . 3600000 IN NS A.ROOT-SERVERS.NET. . 3600000 IN NS B.ROOT-SERVERS.NET. . 3600000 IN NS C.ROOT-SERVERS.NET. . 3600000 IN NS D.ROOT-SERVERS.NET. . 3600000 IN NS E.ROOT-SERVERS.NET. . 3600000 IN NS F.ROOT-SERVERS.NET. . 3600000 IN NS G.ROOT-SERVERS.NET. . 3600000 IN NS H.ROOT-SERVERS.NET. . 3600000 IN NS I.ROOT-SERVERS.NET. . 3600000 IN NS J.ROOT-SERVERS.NET. . 3600000 IN NS K.ROOT-SERVERS.NET. . 3600000 IN NS L.ROOT-SERVERS.NET. . 3600000 IN NS M.ROOT-SERVERS.NET. ;; Query time: 52 msec ;; SERVER: 198.6.1.202#53(198.6.1.202) ;; WHEN: Thu May 8 23:10:02 2008 ;; MSG SIZE rcvd: 243 From cidr-report at potaroo.net Fri May 9 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 May 2008 22:00:05 +1000 (EST) Subject: [NANOG] BGP Update Report Message-ID: <200805091200.m49C05fm075318@wattle.apnic.net> BGP Update Report Interval: 07-Apr-08 -to- 08-May-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 117200 1.1% 97.3 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - AS9583 89594 0.8% 73.6 -- SIFY-AS-IN Sify Limited 3 - AS17974 68961 0.6% 149.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 4 - AS2386 66713 0.6% 46.4 -- INS-AS - AT&T Data Communications Services 5 - AS4755 64377 0.6% 39.0 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 6 - AS10796 59101 0.5% 100.7 -- SCRR-10796 - Road Runner HoldCo LLC 7 - AS29571 58230 0.5% 404.4 -- CITelecom-AS 8 - AS8151 54783 0.5% 44.7 -- Uninet S.A. de C.V. 9 - AS24731 50807 0.5% 635.1 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 10 - AS6389 49981 0.5% 32.9 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS6140 48690 0.5% 68.9 -- IMPSAT-USA - ImpSat USA, Inc. 12 - AS26829 47801 0.4% 47801.0 -- YKK-USA - YKK USA,INC 13 - AS17488 47323 0.4% 41.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS7018 46863 0.4% 31.1 -- ATT-INTERNET4 - AT&T WorldNet Services 15 - AS6517 46290 0.4% 68.5 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 16 - AS9198 46186 0.4% 92.9 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 17 - AS11492 45922 0.4% 37.6 -- CABLEONE - CABLE ONE 18 - AS11060 41950 0.4% 320.2 -- NEO-RR-COM - Road Runner HoldCo LLC 19 - AS6478 39832 0.4% 42.0 -- ATT-INTERNET3 - AT&T WorldNet Services 20 - AS4538 37632 0.3% 7.7 -- ERX-CERNET-BKB China Education and Research Network Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26829 47801 0.4% 47801.0 -- YKK-USA - YKK USA,INC 2 - AS19334 9808 0.1% 9808.0 -- SPORTLINE-DBC - SPORTLINE 3 - AS19017 9036 0.1% 9036.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 4 - AS42787 26451 0.2% 8817.0 -- MMIP-AS MultiMedia IP Ltd. 5 - AS30929 7316 0.1% 7316.0 -- HUTCB Hidrotechnical Faculty - Technical University 6 - AS42923 5857 0.1% 5857.0 -- PLK-AS PLK AS Number 7 - AS17487 5533 0.1% 5533.0 -- ICBCASIA-AP Industrial and Commercial Bank 8 - AS28646 4710 0.0% 4710.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 9 - AS29910 4165 0.0% 4165.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 10 - AS40359 4089 0.0% 4089.0 -- SOUTHEASTERNMILLS-ROME - Southeastern Mills, Inc. 11 - AS23082 18505 0.2% 3701.0 -- MPHI - Michigan Public Health Institute 12 - AS18609 6505 0.1% 3252.5 -- SOLUNET - Solunet, Inc 13 - AS9122 3034 0.0% 3034.0 -- TECHNOELECTROSERVIS-AS Technoelektroservis Ltd. 14 - AS18131 5874 0.1% 2937.0 -- IR3 NTT Communications Corporation 15 - AS11278 4682 0.0% 2341.0 -- NINTENDO - Nintendo Of America inc. 16 - AS32996 2165 0.0% 2165.0 -- AGRIBANK-STPAUL - AgriBank, FCB 17 - AS28282 2154 0.0% 2154.0 -- DW7 CENTRO DE DADOS LTDA 18 - AS36975 1849 0.0% 1849.0 -- CBA-AS 19 - AS34378 1720 0.0% 1720.0 -- RUG-AS Razgulay Group 20 - AS27892 6615 0.1% 1653.8 -- Universidad del Zulia TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 125.23.208.0/20 63479 0.6% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 12.108.254.0/24 47801 0.4% AS26829 -- YKK-USA - YKK USA,INC 3 - 193.33.184.0/23 26359 0.2% AS42787 -- MMIP-AS MultiMedia IP Ltd. 4 - 213.91.175.0/24 25979 0.2% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.135.80.0/24 25967 0.2% AS9583 -- SIFY-AS-IN Sify Limited 6 - 84.23.100.0/24 25481 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 7 - 221.128.192.0/18 24109 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 8 - 118.95.56.0/24 17101 0.1% AS9583 -- SIFY-AS-IN Sify Limited 9 - 203.63.26.0/24 10586 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 10 - 63.169.11.0/24 9808 0.1% AS19334 -- SPORTLINE-DBC - SPORTLINE 11 - 63.82.84.0/24 9036 0.1% AS19017 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 12 - 217.22.170.0/23 8023 0.1% AS16094 -- RAS Roilcom ASN (Russia) 13 - 89.4.129.0/24 7922 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 14 - 81.180.108.0/24 7316 0.1% AS30929 -- HUTCB Hidrotechnical Faculty - Technical University 15 - 84.23.96.0/19 6891 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 16 - 194.8.90.0/23 6830 0.1% AS3356 -- LEVEL3 Level 3 Communications AS8220 -- COLT COLT Telecommunications 17 - 207.43.99.0/24 6472 0.1% AS18609 -- SOLUNET - Solunet, Inc 18 - 208.83.118.0/24 6134 0.1% AS23082 -- MPHI - Michigan Public Health Institute 19 - 208.83.117.0/24 6132 0.1% AS23082 -- MPHI - Michigan Public Health Institute 20 - 208.83.119.0/24 6102 0.1% AS23082 -- MPHI - Michigan Public Health Institute Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 9 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 May 2008 22:00:03 +1000 (EST) Subject: [NANOG] The Cidr Report Message-ID: <200805091200.m49C03Vk075313@wattle.apnic.net> This report has been generated at Fri May 9 21:14:45 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-05-08 259047 163008 03-05-08 259475 164080 04-05-08 264284 164007 05-05-08 264395 164381 06-05-08 264579 165532 07-05-08 265032 166677 08-05-08 265959 166633 09-05-08 265828 167094 AS Summary 28272 Number of ASes in routing system 11893 Number of ASes announcing only one prefix 4873 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88360704 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 09May08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 265937 167031 98906 37.2% All ASes AS4538 4873 864 4009 82.3% ERX-CERNET-BKB China Education and Research Network Center AS4755 1633 227 1406 86.1% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS9498 1172 68 1104 94.2% BBIL-AP BHARTI BT INTERNET LTD. AS6389 1550 480 1070 69.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS22773 950 82 868 91.4% CCINET-2 - Cox Communications Inc. AS11492 1212 478 734 60.6% CABLEONE - CABLE ONE AS19262 900 173 727 80.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS1785 1018 321 697 68.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS4323 1420 727 693 48.8% TWTC - Time Warner Telecom, Inc. AS8151 1201 509 692 57.6% Uninet S.A. de C.V. AS17488 1065 383 682 64.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1044 371 673 64.5% COVAD - Covad Communications Co. AS18101 679 136 543 80.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 941 399 542 57.6% ATT-INTERNET3 - AT&T WorldNet Services AS2386 1396 879 517 37.0% INS-AS - AT&T Data Communications Services AS4766 878 386 492 56.0% KIXS-AS-KR Korea Telecom AS4134 853 386 467 54.7% CHINANET-BACKBONE No.31,Jin-rong Street AS7011 1095 637 458 41.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS19916 555 99 456 82.2% ASTRUM-0001 - OLM LLC AS6197 987 549 438 44.4% BATI-ATL - BellSouth Network Solutions, Inc AS22047 566 128 438 77.4% VTR BANDA ANCHA S.A. AS17676 508 74 434 85.4% GIGAINFRA BB TECHNOLOGY Corp. AS855 580 157 423 72.9% CANET-ASN-4 - Bell Aliant AS7018 1420 1012 408 28.7% ATT-INTERNET4 - AT&T WorldNet Services AS6140 614 210 404 65.8% IMPSAT-USA - ImpSat USA, Inc. AS4668 671 269 402 59.9% LGNET-AS-KR LG CNS AS7545 499 121 378 75.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 462 84 378 81.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS3602 455 81 374 82.2% AS3602-RTI - Rogers Telecom Inc. AS4808 520 147 373 71.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network Total 31717 10437 21280 67.1% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.58.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.169.0.0/17 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service 192.131.233.0/24 AS7891 BELLSOUTH-NET-BLK2 - Bellsouth.Net 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 195.246.108.0/23 AS44403 BRISTOL-CITY-COUNCIL Bristol City Council 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.45.132.0/22 AS24314 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS7893 BELLSOUTH-NET-BLK2 - Bellsouth.Net 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS7893 BELLSOUTH-NET-BLK2 - Bellsouth.Net 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.192.0/19 AS11881 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.119.128.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.119.131.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.119.141.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.201.80.0/20 AS22384 NATIONALNET-1 - NationalNet 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.239.160.0/19 AS16402 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog at farrokhi.net Fri May 9 04:00:44 2008 From: nanog at farrokhi.net (Babak Farrokhi) Date: Fri, 9 May 2008 13:30:44 +0430 Subject: [NANOG] Cachefly Contact Message-ID: <1B63901F-9196-4825-ADDF-FC13B05F4311@farrokhi.net> Hi, Can someone from Cachefly contact me off-list please? Cheers, Babak From justin at justinshore.com Fri May 9 11:05:20 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 09 May 2008 11:05:20 -0500 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: References: <481D290E.6010000@apnic.net> <481D2BF2.9000105@emmanuelcomputerconsulting.com> <481D2F78.6020000@bogus.com> Message-ID: <48247640.4060802@justinshore.com> Suresh Ramasubramanian wrote: > Let's think smaller. /16 shall we say? > > Like the /16 here. Originally the SRI / ARPANET SF Bay Packet Radio > network that started back in 1977. Now controlled by a shell company > belonging to a shell company belonging to a "high volume email > deployer" :) > > http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html Which leads me to ask an OT but slightly related question. How do other SPs handle the blacklisting of ASNs (not prefixes but entire ASNs). The /16 that Suresh mentioned here is being originated by a well-known spam factory. All prefixes originating from that AS could safely be assumed to be undesirable IMHO and can be dropped. A little Googling for that /16 brings up a lot of good info including: http://groups.google.com/group/news.admin.net-abuse.email/msg/5d3e3f89bb148a4c Does anyone have any good tricks for filtering on AS path that they'd like to share? I already have my RTBH set up so setting the next-hop for all routes originating from a given ASN to one of my blackhole routes (to null0, a sinkhole or srubber) would be ideal. Not accepting the route period and letting uRPF drop traffic would be ok too. Justin From khunt at huntbrothers.com Fri May 9 11:23:00 2008 From: khunt at huntbrothers.com (W. Kevin Hunt) Date: Fri, 09 May 2008 11:23:00 -0500 Subject: [NANOG] Looking for Yahoo-SOC contact Message-ID: <48247A64.50309@huntbrothers.com> If anyone cluefull at Yahoo SOC regarding BGP peering on the West Coast is out there I'd appreciate an email. Normal escalation of a latency issue between you and one of your peers used for return traffic to my network simply isn't working. From cscora at apnic.net Fri May 9 13:06:29 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 May 2008 04:06:29 +1000 (EST) Subject: [NANOG] Weekly Routing Table Report Message-ID: <200805091806.m49I6TJp013115@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 May, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 255385 Prefixes after maximum aggregation: 127091 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 123930 Total ASes present in the Internet Routing Table: 28142 Prefixes per ASN: 9.07 Origin-only ASes present in the Internet Routing Table: 24541 Origin ASes announcing only one prefix: 11411 Transit ASes present in the Internet Routing Table: 3601 Transit-only ASes present in the Internet Routing Table: 76 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN (44859) 15 Prefixes from unregistered ASNs in the Routing Table: 25412 Unregistered ASNs in the Routing Table: 1885 Number of 32-bit ASNs allocated by the RIRs: 46 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 789 Number of addresses announced to Internet: 1849281216 Equivalent to 110 /8s, 57 /16s and 202 /24s Percentage of available address space announced: 49.9 Percentage of allocated address space announced: 61.3 Percentage of available address space allocated: 81.4 Percentage of address space in use by end-sites: 71.7 Total number of prefixes smaller than registry allocations: 122983 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 43145 Total APNIC prefixes after maximum aggregation: 13462 APNIC Deaggregation factor: 3.20 Prefixes being announced from the APNIC address blocks: 55558 Unique aggregates announced from the APNIC address blocks: 23715 APNIC Region origin ASes present in the Internet Routing Table: 1932 APNIC Prefixes per ASN: 28.76 APNIC Region origin ASes announcing only one prefix: 544 APNIC Region transit ASes present in the Internet Routing Table: 346 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 14 Number of APNIC addresses announced to Internet: 347251424 Equivalent to 20 /8s, 178 /16s and 162 /24s Percentage of available APNIC address space announced: 79.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 107798 Total ARIN prefixes after maximum aggregation: 59250 ARIN Deaggregation factor: 1.82 Prefixes being announced from the ARIN address blocks: 86847 Unique aggregates announced from the ARIN address blocks: 34386 ARIN Region origin ASes present in the Internet Routing Table: 11802 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4607 ARIN Region transit ASes present in the Internet Routing Table: 1037 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 358258080 Equivalent to 21 /8s, 90 /16s and 149 /24s Percentage of available ARIN address space announced: 73.6 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, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 55300 Total RIPE prefixes after maximum aggregation: 33687 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 50506 Unique aggregates announced from the RIPE address blocks: 33769 RIPE Region origin ASes present in the Internet Routing Table: 11311 RIPE Prefixes per ASN: 4.47 RIPE Region origin ASes announcing only one prefix: 5905 RIPE Region transit ASes present in the Internet Routing Table: 1720 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 356375680 Equivalent to 21 /8s, 61 /16s and 220 /24s Percentage of available RIPE address space announced: 81.7 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, 38912-39935 40960-45055, 47104 - 48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 19926 Total LACNIC prefixes after maximum aggregation: 4988 LACNIC Deaggregation factor: 3.99 Prefixes being announced from the LACNIC address blocks: 18385 Unique aggregates announced from the LACNIC address blocks: 9882 LACNIC Region origin ASes present in the Internet Routing Table: 898 LACNIC Prefixes per ASN: 20.47 LACNIC Region origin ASes announcing only one prefix: 278 LACNIC Region transit ASes present in the Internet Routing Table: 153 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 51034112 Equivalent to 3 /8s, 10 /16s and 184 /24s Percentage of available LACNIC address space announced: 50.7 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3803 Total AfriNIC prefixes after maximum aggregation: 1177 AfriNIC Deaggregation factor: 3.23 Prefixes being announced from the AfriNIC address blocks: 4161 Unique aggregates announced from the AfriNIC address blocks: 1849 AfriNIC Region origin ASes present in the Internet Routing Table: 240 AfriNIC Prefixes per ASN: 17.34 AfriNIC Region origin ASes announcing only one prefix: 77 AfriNIC Region transit ASes present in the Internet Routing Table: 49 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12183552 Equivalent to 0 /8s, 185 /16s and 232 /24s Percentage of available AfriNIC address space announced: 36.3 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 4755 1633 387 91 Videsh Sanchar Nigam Ltd. Aut 9583 1180 140 15 Sify Limited 9498 1171 550 61 BHARTI BT INTERNET LTD. 17488 1063 70 82 Hathway IP Over Cable Interne 4134 853 12613 317 CHINANET-BACKBONE 4766 848 6006 343 Korea Telecom (KIX) 18101 678 149 53 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 548 1919 421 Telstra Pty Ltd 4808 520 837 132 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4323 1424 1014 378 Time Warner Telecom 2386 1400 643 866 AT&T Data Communications Serv 7018 1399 5976 995 AT&T WorldNet Services 11492 1212 146 33 Cable One 7011 1095 319 624 Citizens Utilities 18566 1044 296 10 Covad Communications 6197 1028 630 543 BellSouth Network Solutions, 1785 1018 511 106 AppliedTheory Corporation 174 974 6836 803 Cogent Communications 22773 950 2394 62 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 9198 428 74 9 Kazakhtelecom Data Network Ad 3292 409 1788 369 TDC Tele Danmark 8452 356 188 7 TEDATA 3301 338 1458 306 TeliaNet Sweden 3320 324 7044 267 Deutsche Telekom AG 8866 298 78 24 Bulgarian Telecommunication C 5462 292 666 26 Telewest Broadband 8551 282 269 37 Bezeq International 3215 278 2686 90 France Telecom Transpac 680 272 2047 262 DFN-IP service G-WiN Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1201 2432 227 UniNet S.A. de C.V. 11830 600 299 14 Instituto Costarricense de El 22047 566 270 14 VTR PUNTO NET S.A. 7303 456 223 62 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 416 85 46 ENTEL CHILE S.A. 11172 413 117 69 Servicios Alestra S.A de C.V 10620 390 99 69 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 343 36 31 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 463 61 27 LINKdotNET AS number 3741 289 853 223 The Internet Solution 20858 220 34 3 EgyNet 5713 172 575 108 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 2018 136 140 68 Tertiary Education Network 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 116 13 8 Ci Telecom Autonomous system 33776 99 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3098 3037 123 bellsouth.net, inc. 23577 1642 34 701 Korea Telecom (ATM-MPLS) 4755 1633 387 91 Videsh Sanchar Nigam Ltd. Aut 4323 1424 1014 378 Time Warner Telecom 2386 1400 643 866 AT&T Data Communications Serv 7018 1399 5976 995 AT&T WorldNet Services 11492 1212 146 33 Cable One 8151 1201 2432 227 UniNet S.A. de C.V. 9583 1180 140 15 Sify Limited 9498 1171 550 61 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4755 1633 1542 Videsh Sanchar Nigam Ltd. Aut 11492 1212 1179 Cable One 9583 1180 1165 Sify Limited 9498 1171 1110 BHARTI BT INTERNET LTD. 4323 1424 1046 Time Warner Telecom 18566 1044 1034 Covad Communications 17488 1063 981 Hathway IP Over Cable Interne 8151 1201 974 UniNet S.A. de C.V. 17676 1016 951 Softbank BB Corp. 23577 1642 941 Korea Telecom (ATM-MPLS) Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 14780 UNALLOCATED 4.79.181.0/24 10310 Yahoo! 12180 UNALLOCATED 4.79.248.0/24 1239 Sprint 12180 UNALLOCATED 8.10.16.0/24 3549 Global Crossing 12180 UNALLOCATED 8.10.58.0/23 3549 Global Crossing 14779 UNALLOCATED 8.12.144.0/24 10310 Yahoo! 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 1239 Sprint 15132 UNALLOCATED 12.9.150.0/24 701 UUNET Technologies, 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA 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:9 /10:16 /11:40 /12:139 /13:280 /14:507 /15:1000 /16:9894 /17:4365 /18:7282 /19:15392 /20:17810 /21:17222 /22:21693 /23:22787 /24:134651 /25:773 /26:921 /27:486 /28:82 /29:9 /30:1 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 11492 1198 1212 Cable One 2386 1100 1400 AT&T Data Communications Serv 18566 1025 1044 Covad Communications 9583 1016 1180 Sify Limited 4755 979 1633 Videsh Sanchar Nigam Ltd. Aut 7011 978 1095 Citizens Utilities 6389 966 3098 bellsouth.net, inc. 6478 940 941 AT&T Worldnet Services 17488 876 1063 Hathway IP Over Cable Interne 9498 846 1171 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:108 12:2034 13:1 15:20 16:3 17:5 18:13 20:35 24:1069 25:1 32:61 33:3 38:420 40:94 41:661 44:2 47:9 52:3 55:3 56:3 57:22 58:517 59:459 60:441 61:980 62:1128 63:1959 64:3414 65:2435 66:3646 67:1183 68:664 69:2212 70:599 71:121 72:1681 73:6 74:957 75:227 76:306 77:650 78:610 79:151 80:904 81:865 82:628 83:386 84:561 85:1001 86:403 87:667 88:346 89:1300 90:11 91:1205 92:299 93:443 96:28 97:14 98:152 99:3 114:2 116:641 117:305 118:133 119:388 120:29 121:524 122:764 123:331 124:850 125:1125 128:323 129:197 130:129 131:404 132:67 133:9 134:180 135:31 136:222 137:112 138:144 139:66 140:491 141:96 142:397 143:280 144:349 145:50 146:360 147:152 148:502 149:183 150:131 151:181 152:141 153:133 154:10 155:260 156:173 157:267 158:165 159:222 160:254 161:111 162:213 163:197 164:520 165:447 166:305 167:319 168:606 169:131 170:426 171:28 172:2 189:196 190:1864 192:5765 193:4102 194:3258 195:2428 196:1065 198:3728 199:3238 200:5674 201:1454 202:7614 203:7808 204:3980 205:2080 206:2393 207:2743 208:3322 209:3431 210:2526 211:1048 212:1387 213:1654 214:454 215:50 216:4335 217:1225 218:349 219:407 220:1069 221:480 222:305 End of report From source_route at yahoo.com Fri May 9 13:31:27 2008 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 9 May 2008 11:31:27 -0700 (PDT) Subject: [NANOG] BGP issues qwest in Burbank, CA Message-ID: <378490.8314.qm@web30804.mail.mud.yahoo.com> anybody no of any issues at 11:00 PST? ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From jeffrey.lyon at blacklotus.net Fri May 9 17:44:13 2008 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 9 May 2008 18:44:13 -0400 Subject: [NANOG] Request for discussion: Akrino, Inc. Message-ID: <16720fe00805091544o617975f1g7793b9b954ccad04@mail.gmail.com> All, What do you know about "Akrino, Inc." My guess is going to be absolutely nothing since the network seems to be owned by a shill offshore corporation (as does it's upstream "Anders Business Group," see also http://www.cidr-report.org/cgi-bin/as-report?as=AS44571 ). I'm genuinely interested and concerned about this network as i've been told by other unnamed security professionals that the organization is almost certainly connected to the Russian Business Network as almost everything (if not everything) on it is purely black hat. Has anyone ever heard of this? They seem to be selling DDoS protection (is this even remotely possible on an obscure single peer network?) from the host ddoswiz.com . -- Jeffrey Lyon, President Level III Information Systems Technician jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. The lower the latitude, the better my attitude. From eddy+public+spam at noc.everquick.net Fri May 9 23:02:49 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Sat, 10 May 2008 04:02:49 +0000 (GMT) Subject: [NANOG] FUS for IP space fragmentation (Re: fair warning: less than 1000 days left to IPv4 exhaustion) Message-ID: Talk of IPv6 space hoarding and fragmentation. Ughh. Perhaps we can avoid repeating IPv4 mistakes with IPv6. Exponential problems need linear solutions. The method for handing out blocks is flawed. There's no need for linear stride-N allocations, assuming that a highly-sparse array is acceptable. Allocate thus: 1. At start of 0b/1 2. At start of 1b/1 3. At start of 01b/2 4. At start of 11b/2 5. At start of 001b/3 6. At start of 101b/3 7. At start of 011b/3 8. At start of 111b/3 (and so forth) Allocate on /1 boundaries as many times as possible... then /2... followed by /3... next /4... et cetera. Let each allocation be long enough to contain sufficient address space; the space to the right is reserved for growth. Different networks will grow at different speeds. That is handled by allocating from "largest available /N" instead of "next /N in sequence", and tends to keep new allocations away from rapidly-growing ones. Fragmentation is drastically reduced. Allocating more space is a simple matter of "grow right", reducing the "hoard as much as possible because new space is a pain" mentality. Wait... we've had this discussion before: http://www.merit.edu/mail.archives/nanog/2006-03/msg00183.html Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From drc at virtualized.org Fri May 9 23:16:35 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 9 May 2008 21:16:35 -0700 Subject: [NANOG] FUS for IP space fragmentation (Re: fair warning: less than 1000 days left to IPv4 exhaustion) In-Reply-To: References: Message-ID: Hi, On May 9, 2008, at 9:02 PM, Edward B. DREGER wrote: > Talk of IPv6 space hoarding and fragmentation. Ughh. Perhaps we can > avoid repeating IPv4 mistakes with IPv6. Would be nice, but alas, it seems we're doomed to repeat most past mistakes. > Let each allocation be long > enough to contain sufficient address space; the space to the right is > reserved for growth. If I understand what you're suggesting, this is the rationale for the RIR's receiving /12s from the IANA. The theory was that the RIRs needed /12s in order for them to allocate address space via a bisection methodology, which would allow for growth in any of the allocations made. However, last I checked (which was a while ago), only APNIC had actually carried through on this -- all the other RIRs (if they were allocating out of the /12 blocks at all), were still allocating sequentially. Things might have changed (haven't been following what the RIRs do so closely anymore)... Regards, -drc From eddy+public+spam at noc.everquick.net Fri May 9 23:45:07 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Sat, 10 May 2008 04:45:07 +0000 (GMT) Subject: [NANOG] leave the deck chairs alone (Re: fair warning: less than 1000 days left to IPv4) Message-ID: RB> Date: Mon, 05 May 2008 05:00:32 +0200 RB> From: Randy Bush RB> i suggest we focus on how to roll out v6 Bingo. Or, I begin to wonder if door #2 might actually have merit: RB> or give up and get massive natting to work well (yuchhh!) For massive NATting to work well, one would need to specify "IP address behind the NAT device". Suddenly, we've invented a variable-length addressing scheme, with 32 bits per level. Under the current model, levels 2+ (where "level" is 1-based) are restricted to a teeny portion of all possible addresses; this could change. Wait... this smells a lot like: 1. OSI addressing; 2. Phone numbers having variable length depending on country code or area code; 3. ASN.1 OID allocation. i.e., we can learn from existing implementations that deal with very similar problems. RB> and not waste our time rearranging the deck chairs [0] or RB> characterizing those with chairs as evil. Quite so, particularly when the deck chairs will put up a fight. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From eddy+public+spam at noc.everquick.net Sat May 10 01:30:50 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Sat, 10 May 2008 06:30:50 +0000 (GMT) Subject: [NANOG] FUS for IP space fragmentation (Re: fair warning: less than 1000 days left to IPv4 exhaustion) In-Reply-To: References: Message-ID: EBD> Date: Sat, 10 May 2008 04:02:49 +0000 (GMT) EBD> From: Edward B. DREGER EBD> Exponential problems need linear solutions. Uhhhh.... that should read: Exponential problems need logarithmic solutions. (Activate... brain... before... engaging... fingers...) Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From jbaldwin at antinode.net Mon May 12 10:19:29 2008 From: jbaldwin at antinode.net (James Baldwin) Date: Mon, 12 May 2008 10:19:29 -0500 Subject: [NANOG] Nortel Core Switching Experience Message-ID: <4d668a580805120819m2d74d5aao8d2619f298b9643b@mail.gmail.com> Would anyone be willing to share their experience with Nortel as a core switch platform off list? I am building out a small campus core and have received proposal with dual ERS 8300s at the core but I have no experience, anecdotal or otherwise, with Nortel in a switching capacity. I'll be happy to provide more information regarding our environment and other systems we're looking into. Thanks James Baldwin From mpetach at netflight.com Mon May 12 11:19:06 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 12 May 2008 09:19:06 -0700 Subject: [NANOG] Microsoft.com PMTUD black hole? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F135@pascal.zaphodb.org> References: <200805061958.UAA07264@sunf10.rd.bbc.co.uk> <3027F949-FD01-4753-88BD-0B6D0DA449E4@muada.com> <4820CD9F.1020308@fsr.com> <600402FF-DE0C-4BAD-B1FE-081DE07724C6@muada.com> <4821F9FA.4020306@fsr.com> <30937.1210187359@turing-police.cc.vt.edu> <48220538.1070005@fsr.com> <70D072392E56884193E3D2DE09C097A9F135@pascal.zaphodb.org> Message-ID: <63ac96a50805120919w73e042f7x6053ab58d73e5880@mail.gmail.com> On 5/7/08, Tomas L. Byrnes wrote: > I'm not sure what the issue is here. > > Just about every modern firewall I've used has an option to enable PMTU > on interfaces, while blocking all other ICMP. > > Is MS not running something manufactured in the last 10 years at their > perimeter? Unless things have changed drastically since we parted ways, it's a simple ACL applied on all edge interfaces. It should be possible for them to modify it to allow the list of ICMP subtypes listed at http://www.cymru.com/Documents/icmp-messages.html It would *certainly* make troubleshooting easier for the poor folks at Microsoft, since one side effect of the edge filter being set that way meant we couldn't traceroute outside the network; the port unreachable messages never made it back, so everything outside the edge routers was all just stars. Of course, that was in a former lifetime, so it's entirely possible and probable things have changed considerably since then. ^_^;; Matt (speaking only for myself, not for my current employer, and most certainly not for my previous employer who I'm still somewhat bitter at, not having gotten any of my hardware back yet...) From owen at delong.com Mon May 12 11:45:13 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 12 May 2008 09:45:13 -0700 Subject: [NANOG] Lofgren has introduced Net Neutrality bill Message-ID: <015444FE-8425-42FD-8BDB-B4CDB0A99783@delong.com> http://thomas.loc.gov/cgi-bin/query/z?c110:H.R.5994: Overall, I think it's actually pretty good. Paragraph 28(a)(2) and especially when combined with 28(d)(2) have some interesting potential unintended consequences, but, overall, it's short, to the point, and, well written legislation in my opinion. Owen From owen at delong.com Mon May 12 12:11:32 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 12 May 2008 10:11:32 -0700 Subject: [NANOG] Broken Link Message-ID: <8BE595AA-CCD1-4E35-B4A1-E7984E6F6A2D@delong.com> Apparently Thomas doesn't let you just publish a link to bills... The link I published doesn't work. There is also another net neutrality bill which would create a major FCC process around the idea of evaluating net neutrality. Both bills probably have some merit. To best read them, I suggest going to the link I sent, then, click "Thomas Home". From there, search for Bill Number. The bill number I sent earlier was H.R. 5994. The other bill is H.R. 5353. Owen From alan at halachmi.net Mon May 12 12:18:51 2008 From: alan at halachmi.net (Alan Halachmi) Date: Mon, 12 May 2008 13:18:51 -0400 (EDT) Subject: [NANOG] Sprintlink ATL->MCO? Message-ID: I'm seeing a significant slowdown between Atlanta and Orlando. Anyone else? 1 ... 2 ... 3 ... 4 ... 5 ... 6 POS5-1.GW4.NYC4.ALTER.NET (157.130.14.177) 10 ms 15 ms 33 ms 7 146.at-2-0-0.XR3.NYC4.ALTER.NET (152.63.25.98) 26 ms 4 ms 4 ms 8 0.so-4-0-2.XL3.NYC4.ALTER.NET (152.63.17.29) 3 ms 3 ms 3 ms 9 0.ge-6-1-0.BR3.NYC4.ALTER.NET (152.63.3.166) 4 ms 3 ms 4 ms 10 sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237) 4 ms 23 ms 17 ms 11 sl-crs1-pen-0-4-5-0.sprintlink.net (144.232.20.142) 21 ms 27 ms 23 ms 12 sl-bb21-rly-15-0.sprintlink.net (144.232.20.208) 25 ms 24 ms 17 ms 13 sl-bb21-dc-5-0-0.sprintlink.net (144.232.8.164) 31 ms 33 ms 28 ms 14 sl-crs1-dc-0-4-0-0.sprintlink.net (144.232.15.13) 45 ms 54 ms 50 ms 15 sl-crs1-atl-0-8-0-1.sprintlink.net (144.232.8.146) 291 ms 283 ms 285 ms 16 sl-bb21-orl-2-0.sprintlink.net (144.232.20.87) 500 ms 525 ms * 17 sl-bb20-orl-15-0.sprintlink.net (144.232.0.98) 489 ms 489 ms 489 ms 18 sl-gw12-orl-8-0.sprintlink.net (144.232.2.178) 487 ms 486 ms 486 ms Best, Alan From Thiago.Modelli at intervoice.com Mon May 12 12:30:34 2008 From: Thiago.Modelli at intervoice.com (Thiago Modelli) Date: Mon, 12 May 2008 12:30:34 -0500 Subject: [NANOG] Sprintlink ATL->MCO? Message-ID: <97DB97ECB0D87A4EB8A1262815576DF10C7D214353@srv-ex01-dal.intervoice.int> Yes, there's a fiber cut that sprint is trying to route arround. We are being impacted too. --T ----- Original Message ----- From: Alan Halachmi To: nanog at nanog.org Sent: Mon May 12 12:18:51 2008 Subject: [NANOG] Sprintlink ATL->MCO? I'm seeing a significant slowdown between Atlanta and Orlando. Anyone else? 1 ... 2 ... 3 ... 4 ... 5 ... 6 POS5-1.GW4.NYC4.ALTER.NET (157.130.14.177) 10 ms 15 ms 33 ms 7 146.at-2-0-0.XR3.NYC4.ALTER.NET (152.63.25.98) 26 ms 4 ms 4 ms 8 0.so-4-0-2.XL3.NYC4.ALTER.NET (152.63.17.29) 3 ms 3 ms 3 ms 9 0.ge-6-1-0.BR3.NYC4.ALTER.NET (152.63.3.166) 4 ms 3 ms 4 ms 10 sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237) 4 ms 23 ms 17 ms 11 sl-crs1-pen-0-4-5-0.sprintlink.net (144.232.20.142) 21 ms 27 ms 23 ms 12 sl-bb21-rly-15-0.sprintlink.net (144.232.20.208) 25 ms 24 ms 17 ms 13 sl-bb21-dc-5-0-0.sprintlink.net (144.232.8.164) 31 ms 33 ms 28 ms 14 sl-crs1-dc-0-4-0-0.sprintlink.net (144.232.15.13) 45 ms 54 ms 50 ms 15 sl-crs1-atl-0-8-0-1.sprintlink.net (144.232.8.146) 291 ms 283 ms 285 ms 16 sl-bb21-orl-2-0.sprintlink.net (144.232.20.87) 500 ms 525 ms * 17 sl-bb20-orl-15-0.sprintlink.net (144.232.0.98) 489 ms 489 ms 489 ms 18 sl-gw12-orl-8-0.sprintlink.net (144.232.2.178) 487 ms 486 ms 486 ms Best, Alan _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are the intended recipient, you must treat the information in confidence and in accordance with all laws related to the privacy and confidentiality of such information. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies of this email, including all attachments. Intervoice, Inc. 17811 Waterview Parkway Dallas, TX 75252 USA Intervoice Limited, Registered in England and Wales with number 2601740, 50 Park Road, Gatley, Cheshire, SK8 4HZ. VAT Number: 560421375 Intervoice GmbH, Hagenauer Stra?e 55, 65203 Wiesbaden, Sitz der Gesellschaft: Wiesbaden, Handelsregister: HRB 8186 (Amtsgericht Wiesbaden), Gesch?ftsf?hrer: Wayne Barclay, Steffen Selbmann From jeff at ocjtech.us Mon May 12 12:30:46 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 12 May 2008 12:30:46 -0500 Subject: [NANOG] Broken Link In-Reply-To: <8BE595AA-CCD1-4E35-B4A1-E7984E6F6A2D@delong.com> References: <8BE595AA-CCD1-4E35-B4A1-E7984E6F6A2D@delong.com> Message-ID: <935ead450805121030o5d6f653dt4bb777b0876a6e14@mail.gmail.com> On Mon, May 12, 2008 at 12:11 PM, Owen DeLong wrote: > Apparently Thomas doesn't let you just publish a link to bills... > > The link I published doesn't work. That's because the automatic link detection in most readers doesn't consider the trailing ":" as part of the link. Be sure to copy the trailing ":" when loading the link in your web browser. > The other bill is H.R. 5353. Same thing: Jeff From william.allen.simpson at gmail.com Mon May 12 12:31:26 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 12 May 2008 13:31:26 -0400 Subject: [NANOG] Conyers and Lofgren have introduced Net Neutrality bill In-Reply-To: <015444FE-8425-42FD-8BDB-B4CDB0A99783@delong.com> References: <015444FE-8425-42FD-8BDB-B4CDB0A99783@delong.com> Message-ID: <48287EEE.5050707@gmail.com> Owen DeLong wrote: > http://thomas.loc.gov/cgi-bin/query/z?c110:H.R.5994: > > Overall, I think it's actually pretty good. Paragraph 28(a)(2) and > especially when combined with 28(d)(2) have some interesting > potential unintended consequences, but, overall, it's short, to > the point, and, well written legislation in my opinion. > Thanks, Owen! Speaking from Michigan, that's Conyers and Lofgren ;-) It still makes me shudder to see the word "broadband" misused so badly.... From mlockhart at stayonline.net Mon May 12 13:58:00 2008 From: mlockhart at stayonline.net (Mike Lockhart) Date: Mon, 12 May 2008 14:58:00 -0400 Subject: [NANOG] Fire at 250 Williams St. in Atlanta Message-ID: Just got this from InterNAP: Hello, This is notification of a fire in progress in the ACS building at 250 Williams Street in Atlanta. The building is currently being evacuated. The fire is not in the datacenter and will have no impact on services or equipment in the datacenter. Internap ticket 274786 If you have any questions or concerns please contact us at noc at internap.com or call 877-843-4662. Thanks, Ryan Luetkenhoelter NOC Customer Care Associate Internap Network Operations Center NOC at Internap.com 1-877-THE-INOC(843-4662) US 00800-468-37627 UK From kraig.beahn at gmail.com Mon May 12 16:20:05 2008 From: kraig.beahn at gmail.com (Kraig Beahn) Date: Mon, 12 May 2008 17:20:05 -0400 Subject: [NANOG] Sprintlink ATL->MCO? In-Reply-To: References: Message-ID: New to the list, however there is a master ticket open w/Sprint (TK#2172676) for a fiber cut in DC. Verizon was dispatched to the site, in which they supposedly had to gain authorization from the Railroad to even work on the facilities with an on-site time of Noon Central. Sprint did not provide an ETA and stated they would be unable to do so until Verizon reported back. All of their Miami traffic was in turn routed via Orlando to Atlanta, etc. We have two DS3's in Tallahassee (Fed from Orlando), Florida and a Gigabit connection in Atlanta and all of the above have been and are still affected by the transition. This apparently affected their DC <-> Miami operations. Hope this helps! Kraig On 5/12/08, Alan Halachmi wrote: > > I'm seeing a significant slowdown between Atlanta and Orlando. Anyone > else? > > 1 ... > 2 ... > 3 ... > 4 ... > 5 ... > 6 POS5-1.GW4.NYC4.ALTER.NET (157.130.14.177) 10 ms 15 ms 33 ms > 7 146.at-2-0-0.XR3.NYC4.ALTER.NET (152.63.25.98) 26 ms 4 ms 4 ms > 8 0.so-4-0-2.XL3.NYC4.ALTER.NET (152.63.17.29) 3 ms 3 ms 3 ms > 9 0.ge-6-1-0.BR3.NYC4.ALTER.NET (152.63.3.166) 4 ms 3 ms 4 ms > 10 sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237) 4 ms 23 ms 17 > ms > 11 sl-crs1-pen-0-4-5-0.sprintlink.net (144.232.20.142) 21 ms 27 ms 23 > ms > 12 sl-bb21-rly-15-0.sprintlink.net (144.232.20.208) 25 ms 24 ms 17 ms > 13 sl-bb21-dc-5-0-0.sprintlink.net (144.232.8.164) 31 ms 33 ms 28 ms > 14 sl-crs1-dc-0-4-0-0.sprintlink.net (144.232.15.13) 45 ms 54 ms 50 ms > 15 sl-crs1-atl-0-8-0-1.sprintlink.net (144.232.8.146) 291 ms 283 > ms 285 > ms > 16 sl-bb21-orl-2-0.sprintlink.net (144.232.20.87) 500 ms 525 ms * > 17 sl-bb20-orl-15-0.sprintlink.net (144.232.0.98) 489 ms 489 ms 489 ms > 18 sl-gw12-orl-8-0.sprintlink.net (144.232.2.178) 487 ms 486 ms 486 ms > > Best, > Alan > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From pfs at cisco.com Tue May 13 03:07:32 2008 From: pfs at cisco.com (Philip Smith) Date: Tue, 13 May 2008 18:07:32 +1000 Subject: [NANOG] [NANOG-announce] Mail List Committee announcement Message-ID: <48294C44.3040708@cisco.com> Dear all, The Steering Committee has unanimously agreed to start afresh with the composition of the Mail List Committee. There has been a long term, and ongoing, conflict within the MLC that had made it essentially dysfunctional. The SC would be derelict in our duty to allow this to continue any longer. The Merit representative on the MLC, Sue Joiner, will continue on the team, with Steve Feldman (the SC rep to the MLC) providing interim support pending appointment of the new MLC. The call for volunteers for the new MLC will be sent out tomorrow, Wednesday 14th, with the new MLC being appointed by Friday 30th. Best wishes, philip (for the SC) -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From snyder at fusion-networks.com Tue May 13 12:16:18 2008 From: snyder at fusion-networks.com (Dan Snyder) Date: Tue, 13 May 2008 13:16:18 -0400 Subject: [NANOG] Alcatel Message-ID: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> Anyone use Alcatel switches in their network...like the 6850 omniswitch? What are your thoughts on them? What about Alcatel's MPLS edge routers like the 7x50 products that came from Timetra...anyone have any experience with them? Are they a good product? Thanks, Dan From surfer at mauigateway.com Tue May 13 13:22:49 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 May 2008 11:22:49 -0700 Subject: [NANOG] Alcatel Message-ID: <20080513112249.C1033E73@resin09.mta.everyone.net> --- snyder at fusion-networks.com wrote: From: "Dan Snyder" Anyone use Alcatel switches in their network...like the 6850 omniswitch? What are your thoughts on them? What about Alcatel's MPLS edge routers like the 7x50 products that came from Timetra...anyone have any experience with them? Are they a good product? -------------------------------------------------- We're using the 7x50s for the core and 7710s for border routers. I'd be happy to discuss. However, there is a list for Alcatel: puck.nether.net/mailman/listinfo/juniper-nsp I've been on it for a couple of months, but I have yet to see an email from it. I have been wanting to get discussion going there, so let's take the conversation there. scott ------------------------------------------------ From lists05 at equinephotoart.com Tue May 13 13:25:37 2008 From: lists05 at equinephotoart.com (JC Dill) Date: Tue, 13 May 2008 11:25:37 -0700 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <14b99b330805022148m7d41ffe6m8236a108ba0755d6@mail.gmail.com> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> <9AEEF477-9768-4825-9E7D-ABD4C2BF218E@let.de> <14b99b330805022148m7d41ffe6m8236a108ba0755d6@mail.gmail.com> Message-ID: <4829DD21.30304@equinephotoart.com> Tim Yocum wrote: > Patrick is correct - the subscriber count is just north of 10k; likely > far greater readership considering web archives, remailers, etc. However... subscribership != readership. There are always many subscribers who don't actively read every post, or every day. (I'm just now catching up on 10 days of unread posts - it would be easy to declare email bankruptcy and just mark it all read...) All you have to do is post an important announcement (such as "the mailing list is moving to a new server") and then notice how few read it to prove the truth of this fact. :-) Also, note how few read the list's welcome message, read the FAQ, etc. jc From neil at domino.org Tue May 13 13:25:53 2008 From: neil at domino.org (Neil J. McRae) Date: Tue, 13 May 2008 19:25:53 +0100 Subject: [NANOG] Alcatel Message-ID: <20080513182544.48A64A6C8C@defiant.domino.org> The Alcatel 7750 is the best MPLS edge box period. It blows away the traditional competition by a country mile. The quality of the product is really superb. Imagine life is a software release when on completion of your own type approval the software does what it says on the tin? Not even minor bugs -> no bugs nada ziltch negatory nien etc. That life starts when you buy the 7750. The former Timetra team (and the new ALU people) are an excellent bunch of guys to work with. They listen and act but at the same time won't sacrafice the quality of the platform. And if you are still unsure I strongly recommend this box. Neil. -----Original Message----- From: Dan Snyder Sent: 13 May 2008 18:16 To: nanog at nanog.org Subject: [NANOG] Alcatel Anyone use Alcatel switches in their network...like the 6850 omniswitch? What are your thoughts on them? What about Alcatel's MPLS edge routers like the 7x50 products that came from Timetra...anyone have any experience with them? Are they a good product? Thanks, Dan _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From jabley at ca.afilias.info Tue May 13 13:28:28 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Tue, 13 May 2008 14:28:28 -0400 Subject: [NANOG] Alcatel In-Reply-To: <20080513112249.C1033E73@resin09.mta.everyone.net> References: <20080513112249.C1033E73@resin09.mta.everyone.net> Message-ID: <6208D62E-30C2-414E-AA48-DC8531304CC2@ca.afilias.info> On 13 May 2008, at 14:22, Scott Weeks wrote: > puck.nether.net/mailman/listinfo/juniper-nsp , I think. There are some archives, but it's not what I would call a busy list. Joe From patrick at ianai.net Tue May 13 13:36:33 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 13 May 2008 14:36:33 -0400 Subject: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion In-Reply-To: <4829DD21.30304@equinephotoart.com> References: <481B0EC9.7090900@ycrdi.com> <6ff30abd0805021440t5c8367ebwc11260712f07247@mail.gmail.com> <9AEEF477-9768-4825-9E7D-ABD4C2BF218E@let.de> <14b99b330805022148m7d41ffe6m8236a108ba0755d6@mail.gmail.com> <4829DD21.30304@equinephotoart.com> Message-ID: On May 13, 2008, at 2:25 PM, JC Dill wrote: > Tim Yocum wrote: > >> Patrick is correct - the subscriber count is just north of 10k; >> likely >> far greater readership considering web archives, remailers, etc. > > However... subscribership != readership. There are always many > subscribers who don't actively read every post, or every day. And there are "subscribers" which are actually exploders with many people (mailboxes?) behind them. Either way, it's not a small number of people / mailboxes. -- TTFN, patrick From neil at domino.org Tue May 13 13:42:25 2008 From: neil at domino.org (Neil J. McRae) Date: Tue, 13 May 2008 19:42:25 +0100 Subject: [NANOG] Alcatel Message-ID: <20080513184214.473E1A6C8C@defiant.domino.org> Not many problems to talk about :) -----Original Message----- From: Joe Abley Sent: 13 May 2008 19:28 To: surfer at mauigateway.com Cc: nanog at merit.edu Subject: Re: [NANOG] Alcatel On 13 May 2008, at 14:22, Scott Weeks wrote: > puck.nether.net/mailman/listinfo/juniper-nsp , I think. There are some archives, but it's not what I would call a busy list. Joe _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From nantoniello at antel.net.uy Tue May 13 13:41:20 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Tue, 13 May 2008 15:41:20 -0300 Subject: [NANOG] Alcatel In-Reply-To: <20080513182544.48A64A6C8C@defiant.domino.org> References: <20080513182544.48A64A6C8C@defiant.domino.org> Message-ID: <4829E0D0.5010901@antel.net.uy> Hi, I'd rather say that 7750 (routing) & 7450 (L3 switching) are good boxes, very good for MPLS and even better if you also build a core and get the 5620 SAM application (for management in case of MPLS services network), non major failures... but it has bugs, who doesn't ? Nic. Neil J. McRae wrote: > The Alcatel 7750 is the best MPLS edge box period. It blows away the traditional competition by a country mile. The quality of the product is really superb. Imagine life is a software release when on completion of your own type approval the software does what it says on the tin? Not even minor bugs -> no bugs nada ziltch negatory nien etc. > > That life starts when you buy the 7750. The former Timetra team (and the new ALU people) are an excellent bunch of guys to work with. They listen and act but at the same time won't sacrafice the quality of the platform. And if you are still unsure I strongly recommend this box. > > Neil. > > -----Original Message----- > From: Dan Snyder > Sent: 13 May 2008 18:16 > To: nanog at nanog.org > Subject: [NANOG] Alcatel > > Anyone use Alcatel switches in their network...like the 6850 > omniswitch? What are your thoughts on them? > > What about Alcatel's MPLS edge routers like the 7x50 products that > came from Timetra...anyone have any experience with them? Are they a > good product? > > Thanks, > Dan > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From rs at seastrom.com Tue May 13 13:44:00 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 13 May 2008 14:44:00 -0400 Subject: [NANOG] Alcatel In-Reply-To: <6208D62E-30C2-414E-AA48-DC8531304CC2@ca.afilias.info> (Joe Abley's message of "Tue, 13 May 2008 14:28:28 -0400") References: <20080513112249.C1033E73@resin09.mta.everyone.net> <6208D62E-30C2-414E-AA48-DC8531304CC2@ca.afilias.info> Message-ID: <86prrqyrgv.fsf@seastrom.com> Joe Abley writes: > On 13 May 2008, at 14:22, Scott Weeks wrote: > >> puck.nether.net/mailman/listinfo/juniper-nsp > > , I think. There > are some archives, but it's not what I would call a busy list. Having recently dealt with some other ALU kit, I interpreted Scott's message as meta-humor. ---rob From surfer at mauigateway.com Tue May 13 13:55:16 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 May 2008 11:55:16 -0700 Subject: [NANOG] Alcatel Message-ID: <20080513115516.C103301F@resin09.mta.everyone.net> ------ neil at domino.org wrote: ------- ...Not even minor bugs -> no bugs nada ziltch negatory nien etc. -------------------------------------- I could not agree with this statement. I recall a bug or two, but we've not been using them for over a year, so I can't speak to the long term. --------------------------------------- That life starts when you buy the 7750. The former Timetra team (and the new ALU people) are an excellent bunch of guys to work with. They listen and act but at the same time won't sacrafice the quality of the platform.... --------------------------------------- I CAN agree that most of the ALU guys are a great bunch, but like anywhere else, some are only mediocre. scott ---------------------------------- From surfer at mauigateway.com Tue May 13 13:58:09 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 May 2008 11:58:09 -0700 Subject: [NANOG] Alcatel Message-ID: <20080513115809.C1033158@resin09.mta.everyone.net> -----Original Message----- From: Joe Abley On 13 May 2008, at 14:22, Scott Weeks wrote: > puck.nether.net/mailman/listinfo/juniper-nsp , I think. There are some archives, but it's not what I would call a busy list. --------------------------------- --- neil at domino.org wrote: From: "Neil J. McRae" Not many problems to talk about :) ------------------------------------ Not problems, rather strange things I see in the logs and other different things. I'll post over there as soon as things slow down a bit at work. scott ------------------------------- From toddb at fuse.net Tue May 13 14:35:58 2008 From: toddb at fuse.net (Todd Baumgartner) Date: Tue, 13 May 2008 15:35:58 -0400 Subject: [NANOG] Alcatel In-Reply-To: <4829E0D0.5010901@antel.net.uy> References: <20080513182544.48A64A6C8C@defiant.domino.org> <4829E0D0.5010901@antel.net.uy> Message-ID: <4829ED9E.3060405@fuse.net> I can't agree with this any more strongly. The 7750/7450 product line are some of the best boxes I've ever worked with. We use the 7450 for a good size MetroE network, and they have been rock solid. The 6850 OmniSwitches are solid performers. We have been using them as CPE for our higher end customers, and have been very pleased. The 6850 command line does take some getting used to, however. Thanks, Todd Nicolas Antoniello wrote: > Hi, > > I'd rather say that 7750 (routing) & 7450 (L3 switching) are good boxes, very good for > MPLS and even better if you also build a core and get the 5620 SAM application (for > management in case of MPLS services network), non major failures... but it has bugs, who > doesn't ? > > Nic. > > > Neil J. McRae wrote: >> The Alcatel 7750 is the best MPLS edge box period. It blows away the traditional competition by a country mile. The quality of the product is really superb. Imagine life is a software release when on completion of your own type approval the software does what it says on the tin? Not even minor bugs -> no bugs nada ziltch negatory nien etc. >> >> That life starts when you buy the 7750. The former Timetra team (and the new ALU people) are an excellent bunch of guys to work with. They listen and act but at the same time won't sacrafice the quality of the platform. And if you are still unsure I strongly recommend this box. >> >> Neil. >> >> -----Original Message----- >> From: Dan Snyder >> Sent: 13 May 2008 18:16 >> To: nanog at nanog.org >> Subject: [NANOG] Alcatel >> >> Anyone use Alcatel switches in their network...like the 6850 >> omniswitch? What are your thoughts on them? >> >> What about Alcatel's MPLS edge routers like the 7x50 products that >> came from Timetra...anyone have any experience with them? Are they a >> good product? >> >> Thanks, >> Dan >> > -- Todd Baumgartner, CCIE #8692 Sr. Network Engineer - Advanced Data Engineering Cincinnati Bell Telephone toddb at fuse.net From bedard.phil at gmail.com Tue May 13 17:37:51 2008 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 13 May 2008 18:37:51 -0400 Subject: [NANOG] Alcatel In-Reply-To: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> Message-ID: <81DFECD1-D0CA-4B21-B06F-76AB291A8434@gmail.com> I'll chime in and say that the 7450/7750 are very nice boxes. Their non-stop routing feature is something that other vendors are barely starting to support, years after they started doing it. Now they are onto features like cross-chassis 802.3ad, etc. that no one else is doing in a SP router platform. The 7450 which is priced against switch-like devices like the C76xx and the JMXxxx is a decent competitor to those platforms. The 5260 is actually a decent NMS which is something I never thought I'd say about a NMS, although the pricing model isn't very good. Phil On May 13, 2008, at 1:16 PM, Dan Snyder wrote: > Anyone use Alcatel switches in their network...like the 6850 > omniswitch? What are your thoughts on them? > > What about Alcatel's MPLS edge routers like the 7x50 products that > came from Timetra...anyone have any experience with them? Are they a > good product? > > Thanks, > Dan > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From surfer at mauigateway.com Tue May 13 18:00:54 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 May 2008 16:00:54 -0700 Subject: [NANOG] Alcatel Message-ID: <20080513160054.C1036D7E@resin09.mta.everyone.net> --- bedard.phil at gmail.com wrote: I'll chime in and say that the 7450/7750 are very nice boxes. Their non-stop routing feature is something that other vendors are barely starting to support, years after they started doing it. Now they are ----------------------------------------------- This IS a very nice feature and works well. A cisco terminal server was sending lots of random data (well not so random, it looked like it was sending a MOTD) to the console on a couple of 7x50s, which caused the CPMs to reset repeatedly, but still no packets were lost. Very cool! scott --------------------------- From nanog at daork.net Tue May 13 19:02:19 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 14 May 2008 12:02:19 +1200 Subject: [NANOG] Alcatel-Lucent In-Reply-To: <81DFECD1-D0CA-4B21-B06F-76AB291A8434@gmail.com> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> <81DFECD1-D0CA-4B21-B06F-76AB291A8434@gmail.com> Message-ID: <3D34E767-7FF2-4990-8E7B-DDC4FD8094E2@daork.net> On 14/05/2008, at 10:37 AM, Phil Bedard wrote: > The 5260 is actually a decent NMS > which is something I never thought I'd say about a NMS, although the > pricing model isn't very good. Yeah, I'll agree with that. I've raved about the 5620SAM (not to be confused with the 5620NM, which manage ATM etc. boxes) for a while. It's the only NMS I've seen [1] that exposes /everything/ to the end user. If someone updates stuff on the CLI, a trap is send, and the graphical display updates within seconds, even for what you'd think were really obscure things. The dev work for these products is done in parallel I believe, instead of as a separate product line. As with most vendor specific NMSs, you want to use 7x50 boxes exclusively for a certain function. I.e. 7x50 only boxes on the edge. The 7x50's have some kinda weird ways of doing things, and you really want to do a training course to understand how they work - they are quite a big paradigm change, and you'll end up doing things sub- optimally unless you understand how they're supposed to function. The major thing is the config is service oriented. I.e. on a traditional box, you configure a bunch of parameters all over the place, and a certain service pops out. With these Alcatel-Lucent boxes, you configure a service, and the parameters are implied somewhat. Interop is fine, but you'll find that many of the knobs are called different things to what you're used to - mostly as a function of that paradigm change. Ask for a v6 roadmap. Last time I looked (~ a year ago) there were some strange limitations, for example, a surprisingly small max v6 routing table. -- Nathan Ward [1] Admittedly, my experience with other NMS's is heavily tarnished by Dorado RMC. Please hold while I hug myself and rock back and forward in my chair for a bit. From surfer at mauigateway.com Tue May 13 21:15:53 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 May 2008 19:15:53 -0700 Subject: [NANOG] Alcatel-Lucent Message-ID: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> --- nanog at daork.net wrote: From: Nathan Ward Ask for a v6 roadmap. Last time I looked (~ a year ago) there were some strange limitations, for example, a surprisingly small max v6 routing table. ----------------------------------- Hopefully... ;-) I want to be able to carry IPv6 in a VPRN without having to pay an order of magnitude more for an IOM. scott ------------------------------- From kbillings at infoave.net Tue May 13 21:38:23 2008 From: kbillings at infoave.net (Kevin Billings) Date: Tue, 13 May 2008 22:38:23 -0400 Subject: [NANOG] Alcatel In-Reply-To: <20080513160054.C1036D7E@resin09.mta.everyone.net> References: <20080513160054.C1036D7E@resin09.mta.everyone.net> Message-ID: <003f01c8b56b$95ad4d70$c107e850$@net> We have been using 7750's and 5620Sam since 2004. I believe we were one of the first US companies to deploy in a production environment. As with most vendors we have seen a few bug's, but TAC has always been there to help and provide a solution very quickly. The box have been stable and what I like most is that I have not had to upgrade any of the hardware, Just add cards as needed to increase capacity. When a new feature comes out I only have to upgrade the code and not the hardware. We run our network a like different in that we use our 7750's both as edge and core routers providing MPLS and Internet services to our customers. Works great for us... -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Tuesday, May 13, 2008 7:01 PM To: nanog at nanog.org Subject: Re: [NANOG] Alcatel --- bedard.phil at gmail.com wrote: I'll chime in and say that the 7450/7750 are very nice boxes. Their non-stop routing feature is something that other vendors are barely starting to support, years after they started doing it. Now they are ----------------------------------------------- This IS a very nice feature and works well. A cisco terminal server was sending lots of random data (well not so random, it looked like it was sending a MOTD) to the console on a couple of 7x50s, which caused the CPMs to reset repeatedly, but still no packets were lost. Very cool! scott --------------------------- _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From kbillings at infoave.net Tue May 13 21:59:52 2008 From: kbillings at infoave.net (Kevin Billings) Date: Tue, 13 May 2008 22:59:52 -0400 Subject: [NANOG] Alcatel-Lucent In-Reply-To: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> References: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> Message-ID: <004401c8b56e$95cc18b0$c1644a10$@net> To run IPV6 on a 7750 you will need the new IOM 2 cards. They do cost a few $$$ more... -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Tuesday, May 13, 2008 10:16 PM To: nanog at merit.edu Subject: Re: [NANOG] Alcatel-Lucent --- nanog at daork.net wrote: From: Nathan Ward Ask for a v6 roadmap. Last time I looked (~ a year ago) there were some strange limitations, for example, a surprisingly small max v6 routing table. ----------------------------------- Hopefully... ;-) I want to be able to carry IPv6 in a VPRN without having to pay an order of magnitude more for an IOM. scott ------------------------------- _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From fbako at africaonline.co.ke Wed May 14 00:53:40 2008 From: fbako at africaonline.co.ke (Felix Bako) Date: Wed, 14 May 2008 08:53:40 +0300 Subject: [NANOG] Linkedin Message-ID: <482A7E64.5060900@africaonline.co.ke> Hi Guyz, anyone from linkedin please contact me off list as we have not been able to open the website www.linkedin.com for sometime now!! Thanks -- Regards, Felix Bako *Team Leader, Networks* Africa Online, Kenya Tel: +254 (20) 27 92 245 Fax: +254 (20) 27 100 10 Email: fbako at africaonline.co.ke AIM: felixbako * * A member of the Telkom South Africa Group* * *Africa Online Disclaimer and Confidentiality Note * This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Africa Online Holdings (Kenya) Limited and / or its subsidiaries ("the Group"). It is confidential and intended for the addressee only. Should you not be the addressee and have received this e-mail by mistake, kindly notify the sender, delete this e-mail immediately and do not disclose or use the same in any manner whatsoever. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or damages, however incurred, resulting from the use of this e-mail or its attachments. The Group does not warrant the integrity of this e-mail, nor that it is free of errors, viruses, interception or interference. For more information about Africa Online, please visit our website at www.africaonline.co.ke From Oriana.Palivan at fibrelac.com Wed May 14 03:04:34 2008 From: Oriana.Palivan at fibrelac.com (Oriana Palivan) Date: Wed, 14 May 2008 10:04:34 +0200 Subject: [NANOG] =?iso-8859-1?q?RE=A0=3A__Alcatel-Lucent?= References: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> <004401c8b56e$95cc18b0$c1644a10$@net> Message-ID: Hi, I've just changed my IP/MPLS bakcbone with Alcatel ESSs and SRs. Where can I check on the SR 7750 the version of the IOM, to see if I have the IOM2 by any chance? Thanks. Regards, Oriana ________________________________ De: Kevin Billings [mailto:kbillings at infoave.net] Date: mer. 14.05.2008 04:59 ?: nanog at merit.edu Objet : Re: [NANOG] Alcatel-Lucent To run IPV6 on a 7750 you will need the new IOM 2 cards. They do cost a few $$$ more... -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Tuesday, May 13, 2008 10:16 PM To: nanog at merit.edu Subject: Re: [NANOG] Alcatel-Lucent --- nanog at daork.net wrote: From: Nathan Ward Ask for a v6 roadmap. Last time I looked (~ a year ago) there were some strange limitations, for example, a surprisingly small max v6 routing table. ----------------------------------- Hopefully... ;-) I want to be able to carry IPv6 in a VPRN without having to pay an order of magnitude more for an IOM. scott ------------------------------- _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From michael.dillon at bt.com Wed May 14 05:03:15 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 May 2008 11:03:15 +0100 Subject: [NANOG] Alcatel-Lucent In-Reply-To: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> References: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> Message-ID: > Hopefully... ;-) Not likely! This is a motley crew of people who like to jabber, not a forum for your favorite vendor's customer support. > I want to be able to carry IPv6 in a VPRN without having to > pay an order of magnitude more for an IOM. May I suggest that you will make much more impact on your vendor's radar if you explicitly ask your vendor rep for this feature, in writing. And then proceed to try setting up IPv6 in a VPRN as a lab experiment, then raise cases with your vendor's TAC when you run across problems. Tell them that you are doing the lab work as the first phase to commercial introduction of IPv6 services. One reason that IPv6 support is in a sorry state is that people try something, find it doesn't work, and then suffer in silence. Please do not suffer in silence! Please do explicitly tell people about the specific issues that you encounter and please do name names. Tell us which vendor, which device, which software release, etc. etc. yadda yadda boom! The more talk there is about IPv6, the more it gets on vendor radar and the quicker they will fix problems and improve support. And don't forget all those vendors of NMS and OSS software. --Michael Dillon From blakjak at blakjak.net Wed May 14 05:41:22 2008 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 14 May 2008 10:41:22 -0000 Subject: [NANOG] Researchers ping through first full 'Internet census' in 25 years In-Reply-To: <2656.87.84.237.90.1192198910.squirrel@webmail-test.pelican.org> References: <2656.87.84.237.90.1192198910.squirrel@webmail-test.pelican.org> Message-ID: On Fri, 12 Oct 2007, Tim Franklin wrote: > > On Fri, October 12, 2007 2:49 pm, Justin M. Streiner wrote: > >> "HOST x.x.x.x ON YOUR NETWORK PINGED ME!!!! I TAKE MY SECURITY >> SERIOUSLY!! I'M CALLING THE FBI!!!" > > That I can *sort* of understand - it's the flaming zealotry of "ALL ICMP > IS EEEVIL!" trickling down from 99% of firewall admins working in > enterprises to end users who just heard it from "someone in IT". > > It's the "Your server www.whatever.com is attacking me from port 80!" ones > that leave me torn between laughing, crying, and seriously thinking about > a cull... > Its all very well for those that know better to carry on like this, but I would suggest that those sortsa complaints only come from people who don't know better. They don't know how to interpret their Firewall warnings. And they don't know whats genuine and whats not. Heck, I remember being a little like that myself, back in the days of Windows + Conseal PC Firewall being the best security solution affordably available to home users - and from being DoS'd offline at 14400... (And i've only been working in the industry for 10 years.) Suggest that rather than knocking those who genuinely think that its a warzone out there (and isn't it?) efforts of ISPs to educate clients as to what is genuine abuse (and what isn't) should be rewarded. (If some random dynamic IP host on the other side of the world started hitting my firewall for no apparent reason, i'd be raising my eyebrows too. Of course, these days, I have a much better idea of what is genuinely threatening and what isn't.) Mark. [Sorry, but sometimes I get the distinct impression that Network Operators sometimes forget that the vast majority of people simply aren't anywhere near their level.] From ops.lists at gmail.com Wed May 14 06:40:54 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 14 May 2008 17:10:54 +0530 Subject: [NANOG] Linkedin In-Reply-To: <482A7E64.5060900@africaonline.co.ke> References: <482A7E64.5060900@africaonline.co.ke> Message-ID: On Wed, May 14, 2008 at 11:23 AM, Felix Bako wrote: > Hi Guyz, anyone from linkedin please contact me off list as we have not > been able to open the website www.linkedin.com for sometime now!! Hi, have you tried to curb 419 spam sent over http/https from your IP space (through linkedin among other services)? Perhaps that would go quite far towards reducing the occurence of such blocks. From blakjak at blakjak.net Wed May 14 06:50:55 2008 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 14 May 2008 11:50:55 -0000 Subject: [NANOG] Researchers ping through first full 'Internet census' in 25 years In-Reply-To: <2656.87.84.237.90.1192198910.squirrel@webmail-test.pelican.org> References: <2656.87.84.237.90.1192198910.squirrel@webmail-test.pelican.org> Message-ID: On Fri, 12 Oct 2007, Tim Franklin wrote: > > On Fri, October 12, 2007 2:49 pm, Justin M. Streiner wrote: > >> "HOST x.x.x.x ON YOUR NETWORK PINGED ME!!!! I TAKE MY SECURITY >> SERIOUSLY!! I'M CALLING THE FBI!!!" > > That I can *sort* of understand - it's the flaming zealotry of "ALL ICMP > IS EEEVIL!" trickling down from 99% of firewall admins working in > enterprises to end users who just heard it from "someone in IT". > > It's the "Your server www.whatever.com is attacking me from port 80!" ones > that leave me torn between laughing, crying, and seriously thinking about > a cull... > Its all very well for those that know better to carry on like this, but I would suggest that those sortsa complaints only come from people who don't know better. They don't know how to interpret their Firewall warnings. And they don't know whats genuine and whats not. Heck, I remember being a little like that myself, back in the days of Windows + Conseal PC Firewall being the best security solution affordably available to home users - and from being DoS'd offline at 14400... (And i've only been working in the industry for 10 years.) Suggest that rather than knocking those who genuinely think that its a warzone out there (and isn't it?) efforts of ISPs to educate clients as to what is genuine abuse (and what isn't) should be rewarded. (If some random dynamic IP host on the other side of the world started hitting my firewall for no apparent reason, i'd be raising my eyebrows too. Of course, these days, I have a much better idea of what is genuinely threatening and what isn't.) Mark. [Sorry, but sometimes I get the distinct impression that Network Operators sometimes forget that the vast majority of people simply aren't anywhere near their level.] From nantoniello at antel.net.uy Wed May 14 07:00:49 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Wed, 14 May 2008 09:00:49 -0300 Subject: [NANOG] IPv6 Alcatel-Lucent 7750 + Cisco 6509 In-Reply-To: References: <20080513191553.C0FFC3D3@resin11.mta.everyone.net> Message-ID: <482AD471.6080804@antel.net.uy> By the way, to add some IPv6 technical noise: Have you ever tried to set up MD5 auth. in a BGP over IPv6 session between an Alcatel 7750SR and a Cisco 6500... I keep getting a log message (Cisco) exposing some issue with the MD5 digest from the Alcatel. The funny thing is that Cisco <---> Cisco goes Fine, and Alcatel <---> Alcatel goes fine (as obviously expected)... so may be you know something about any difference in the implementation. Even more "funny" is the fact that BGP MD5 auth. Cisco <---> Alcatel goes perfect over IPv4. I'm also looking at some kind of issue like changes in TCP sequence numbers after MD5 hash or such things, but I found nothing yet... I've talk to Alcatel, but no answer yet... Thx, Nic. michael.dillon at bt.com wrote: >> Hopefully... ;-) > > Not likely! This is a motley crew of people who like to jabber, > not a forum for your favorite vendor's customer support. > >> I want to be able to carry IPv6 in a VPRN without having to >> pay an order of magnitude more for an IOM. > > May I suggest that you will make much more impact on your vendor's > radar if you explicitly ask your vendor rep for this feature, in > writing. And then proceed to try setting up IPv6 in a VPRN as > a lab experiment, then raise cases with your vendor's TAC when you > run across problems. Tell them that you are doing the lab work as > the first phase to commercial introduction of IPv6 services. > > One reason that IPv6 support is in a sorry state is that people > try something, find it doesn't work, and then suffer in silence. > Please do not suffer in silence! Please do explicitly tell people > about the specific issues that you encounter and please do name > names. Tell us which vendor, which device, which software release, > etc. etc. yadda yadda boom! > > The more talk there is about IPv6, the more it gets on vendor radar > and the quicker they will fix problems and improve support. And don't > forget all those vendors of NMS and OSS software. > > --Michael Dillon > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From pfs at cisco.com Wed May 14 03:25:40 2008 From: pfs at cisco.com (Philip Smith) Date: Wed, 14 May 2008 18:25:40 +1000 Subject: [NANOG] [NANOG-announce] Call for Volunteers for the NANOG Mailing List Committee Message-ID: <482AA204.8050306@cisco.com> Hello everyone, The NANOG Mailing List Committee is a group of individuals from the NANOG community who collectively are responsible for ensuring the functioning of the NANOG mailing list as an effective resource for the operations community. The Steering Committee would like to hear from people who are interested in joining the team, volunteering their time and energy to help make the NANOG mailing list better. We are looking for people who care about the NANOG mailing list, who are keen readers of the list, and who have a thorough understanding of NANOG culture. If this sounds like you, we would like to encourage you to volunteer to serve on the committee. As per 7.1.2 of the Charter, the Mailing List Committee must have a minimum of four members. Therefore four positions are available, two positions with terms up for renewal at the end of NANOG 44 in October 2008, and two positions with terms up for renewal at the end of NANOG 47 in October 2009. To volunteer, please send your expression of interest to containing a brief summary of how you think the NANOG list could be better, how you think you could help make a difference, and which term length you'd like to serve. The deadline for responses is by the end of 23rd May 2008, and we plan to select the new Mailing List Committee by the end of the following week. Many thanks! philip (for the SC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From pauldotwall at gmail.com Wed May 14 10:57:03 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 14 May 2008 11:57:03 -0400 Subject: [NANOG] Alcatel In-Reply-To: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> Message-ID: <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> On Tue, May 13, 2008 at 1:16 PM, Dan Snyder wrote: > What about Alcatel's MPLS edge routers like the 7x50 products that > came from Timetra...anyone have any experience with them? Are they a > good product? Garbage, the 7750/7450 are complete junk boxes. Here is why... - For fun, view a 7750/7540 router configuration file and grep for the word "exit". Count how many times you see that word. To sum it up, the CLI is kind of annoying. Lets just say the 7x50 rivals a Bay Annex CLI for uselessness. - They attempted to mimic the Juniper style of policy-statements, but they still fall short of it. Whats up with the pseudo-commit crap? - The majority of ALU folks supporting the 7x50 are all from former failed router vendors (caspian, nexabit, etc). When you deal with such teams, keep your operator hat on and realize that some of the stuff being suggested are from people who've never worked in production. - 7x50 is about 1-2 years behind Cisco and Juniper on any feature functionality on the boxes. - The ALU business unit has no comprehension why users want to interface with the box via CLI as opposed to their SAM EMS junk. The BU and the former Newbridge developers think folks run their network from a Sparc via a GUI. Times have changed...NETCONF what? - If you haven't run into any BGP scaling issues yet, you will, soon. - Limited RSVP-TE support...nothing compared to Juniper. There are plenty of other better options like the Cisco 6500/7600 as well as the Juniper MX. Why settle for sub-standard CLI, weak features and a business unit who has no operational experience and their only claim to fame was gobbling up companies and exploiting their long-time industry friendships to seal massive deals. I know some will reply to talk about their great failover is and this and that, whatever. To get the box where it is today a lot of pain was endured by plenty of customers who had to deal with a not-so-nice Alcatel. The box pricing is not that great and for the same money you can find better elsewhere. From nantoniello at antel.net.uy Wed May 14 11:52:57 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Wed, 14 May 2008 13:52:57 -0300 Subject: [NANOG] Alcatel In-Reply-To: <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> Message-ID: <482B18E9.6080908@antel.net.uy> I think we should keep this list as much neutral as we may regarding individual preferences. Why some of you keep writing offensive mails to those who write neutral ones or to those who know less than what you THINK you know. Have you heard about: "All we are ignorants, the thing is that we ignore different things"? So my recommendation for life is: try to be more modest 'cos as some one say somewhere: life is like a box of chocolates, you never know what you're going to get. By the way, I'm not related to any vendor, nor any manufacturer company... oh, even not from USA... so this is as much neutral as may get! Nic. Paul Wall wrote: > On Tue, May 13, 2008 at 1:16 PM, Dan Snyder wrote: >> What about Alcatel's MPLS edge routers like the 7x50 products that >> came from Timetra...anyone have any experience with them? Are they a >> good product? > > Garbage, the 7750/7450 are complete junk boxes. Here is why... > > - For fun, view a 7750/7540 router configuration file and grep for > the word "exit". Count how many times you see that word. To sum it up, > the CLI is kind of annoying. Lets just say the 7x50 rivals a Bay Annex > CLI for uselessness. > > - They attempted to mimic the Juniper style of policy-statements, but > they still fall short of it. Whats up with the pseudo-commit crap? > > - The majority of ALU folks supporting the 7x50 are all from former > failed router vendors (caspian, nexabit, etc). When you deal with such > teams, keep your operator hat on and realize that some of the stuff > being suggested are from people who've never worked in production. > > - 7x50 is about 1-2 years behind Cisco and Juniper on any feature > functionality on the boxes. > > - The ALU business unit has no comprehension why users want to > interface with the box via CLI as opposed to their SAM EMS junk. The > BU and the former Newbridge developers think folks run their network > from a Sparc via a GUI. Times have changed...NETCONF what? > > - If you haven't run into any BGP scaling issues yet, you will, soon. > > - Limited RSVP-TE support...nothing compared to Juniper. > > There are plenty of other better options like the Cisco 6500/7600 as > well as the Juniper MX. Why settle for sub-standard CLI, weak features > and a business unit who has no operational experience and their only > claim to fame was gobbling up companies and exploiting their long-time > industry friendships to seal massive deals. > > I know some will reply to talk about their great failover is and this > and that, whatever. To get the box where it is today a lot of pain was > endured by plenty of customers who had to deal with a not-so-nice > Alcatel. The box pricing is not that great and for the same money you > can find better elsewhere. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From tims at donet.com Wed May 14 13:05:09 2008 From: tims at donet.com (Tim Sanderson) Date: Wed, 14 May 2008 14:05:09 -0400 Subject: [NANOG] Alcatel In-Reply-To: <482B18E9.6080908@antel.net.uy> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> <482B18E9.6080908@antel.net.uy> Message-ID: Why be neutral? If something is better, then it is better. Whenever I have tried a vendor other than Cisco for a routing or switching solution, I regretted it. Now I use Cisco equipment exclusively except where they do not make that product I need [such as FatPipe MPVPN]. Tim -----Original Message----- From: Nicolas Antoniello [mailto:nantoniello at antel.net.uy] Sent: Wednesday, May 14, 2008 12:53 PM To: Paul Wall Cc: Dan Snyder; nanog at nanog.org Subject: Re: [NANOG] Alcatel I think we should keep this list as much neutral as we may regarding individual preferences. Why some of you keep writing offensive mails to those who write neutral ones or to those who know less than what you THINK you know. Have you heard about: "All we are ignorants, the thing is that we ignore different things"? So my recommendation for life is: try to be more modest 'cos as some one say somewhere: life is like a box of chocolates, you never know what you're going to get. By the way, I'm not related to any vendor, nor any manufacturer company... oh, even not from USA... so this is as much neutral as may get! Nic. Paul Wall wrote: > On Tue, May 13, 2008 at 1:16 PM, Dan Snyder wrote: >> What about Alcatel's MPLS edge routers like the 7x50 products that >> came from Timetra...anyone have any experience with them? Are they a >> good product? > > Garbage, the 7750/7450 are complete junk boxes. Here is why... > > - For fun, view a 7750/7540 router configuration file and grep for > the word "exit". Count how many times you see that word. To sum it up, > the CLI is kind of annoying. Lets just say the 7x50 rivals a Bay Annex > CLI for uselessness. > > - They attempted to mimic the Juniper style of policy-statements, but > they still fall short of it. Whats up with the pseudo-commit crap? > > - The majority of ALU folks supporting the 7x50 are all from former > failed router vendors (caspian, nexabit, etc). When you deal with such > teams, keep your operator hat on and realize that some of the stuff > being suggested are from people who've never worked in production. > > - 7x50 is about 1-2 years behind Cisco and Juniper on any feature > functionality on the boxes. > > - The ALU business unit has no comprehension why users want to > interface with the box via CLI as opposed to their SAM EMS junk. The > BU and the former Newbridge developers think folks run their network > from a Sparc via a GUI. Times have changed...NETCONF what? > > - If you haven't run into any BGP scaling issues yet, you will, soon. > > - Limited RSVP-TE support...nothing compared to Juniper. > > There are plenty of other better options like the Cisco 6500/7600 as > well as the Juniper MX. Why settle for sub-standard CLI, weak features > and a business unit who has no operational experience and their only > claim to fame was gobbling up companies and exploiting their long-time > industry friendships to seal massive deals. > > I know some will reply to talk about their great failover is and this > and that, whatever. To get the box where it is today a lot of pain was > endured by plenty of customers who had to deal with a not-so-nice > Alcatel. The box pricing is not that great and for the same money you > can find better elsewhere. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From nantoniello at antel.net.uy Wed May 14 13:11:29 2008 From: nantoniello at antel.net.uy (Nicolas Antoniello) Date: Wed, 14 May 2008 15:11:29 -0300 Subject: [NANOG] Alcatel In-Reply-To: References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> <482B18E9.6080908@antel.net.uy> Message-ID: <482B2B51.2010909@antel.net.uy> Ok, I agree with you, may be I didn't explain myself clear: I meant "neutral" in the sense of relation with each other (i.e. Not being hostile). Nic. Tim Sanderson wrote: > Why be neutral? If something is better, then it is better. Whenever I have tried a vendor other than Cisco for a routing or switching solution, I regretted it. Now I use Cisco equipment exclusively except where they do not make that product I need [such as FatPipe MPVPN]. > > Tim > > -----Original Message----- > From: Nicolas Antoniello [mailto:nantoniello at antel.net.uy] > Sent: Wednesday, May 14, 2008 12:53 PM > To: Paul Wall > Cc: Dan Snyder; nanog at nanog.org > Subject: Re: [NANOG] Alcatel > > I think we should keep this list as much neutral as we may regarding individual preferences. > > Why some of you keep writing offensive mails to those who write neutral ones or to those > who know less than what you THINK you know. > > Have you heard about: "All we are ignorants, the thing is that we ignore different things"? > > So my recommendation for life is: try to be more modest 'cos as some one say somewhere: > life is like a box of chocolates, you never know what you're going to get. > > By the way, I'm not related to any vendor, nor any manufacturer company... oh, even not > from USA... so this is as much neutral as may get! > > Nic. > > > > > Paul Wall wrote: >> On Tue, May 13, 2008 at 1:16 PM, Dan Snyder wrote: >>> What about Alcatel's MPLS edge routers like the 7x50 products that >>> came from Timetra...anyone have any experience with them? Are they a >>> good product? >> Garbage, the 7750/7450 are complete junk boxes. Here is why... >> >> - For fun, view a 7750/7540 router configuration file and grep for >> the word "exit". Count how many times you see that word. To sum it up, >> the CLI is kind of annoying. Lets just say the 7x50 rivals a Bay Annex >> CLI for uselessness. >> >> - They attempted to mimic the Juniper style of policy-statements, but >> they still fall short of it. Whats up with the pseudo-commit crap? >> >> - The majority of ALU folks supporting the 7x50 are all from former >> failed router vendors (caspian, nexabit, etc). When you deal with such >> teams, keep your operator hat on and realize that some of the stuff >> being suggested are from people who've never worked in production. >> >> - 7x50 is about 1-2 years behind Cisco and Juniper on any feature >> functionality on the boxes. >> >> - The ALU business unit has no comprehension why users want to >> interface with the box via CLI as opposed to their SAM EMS junk. The >> BU and the former Newbridge developers think folks run their network >> from a Sparc via a GUI. Times have changed...NETCONF what? >> >> - If you haven't run into any BGP scaling issues yet, you will, soon. >> >> - Limited RSVP-TE support...nothing compared to Juniper. >> >> There are plenty of other better options like the Cisco 6500/7600 as >> well as the Juniper MX. Why settle for sub-standard CLI, weak features >> and a business unit who has no operational experience and their only >> claim to fame was gobbling up companies and exploiting their long-time >> industry friendships to seal massive deals. >> >> I know some will reply to talk about their great failover is and this >> and that, whatever. To get the box where it is today a lot of pain was >> endured by plenty of customers who had to deal with a not-so-nice >> Alcatel. The box pricing is not that great and for the same money you >> can find better elsewhere. >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From joelja at bogus.com Wed May 14 13:34:33 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 14 May 2008 11:34:33 -0700 Subject: [NANOG] NANOG 43 PGP signing party. Message-ID: <482B30B9.4090409@bogus.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick note, The thrice annual nanog pgp key signing party will be making an appearance at NANOG 43. The keysigning sessions are going to be during the morning breaks during the general session, and will be location TDB. Monday June 2nd 11:00-11:30 Tuesday June 3rd 11:00-11:30 If you plan to participate, please add your key to the keyring at: http://biglumber.com/x/web?ev=19916 And come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. While printouts will probably be available at the sessions, feel free to add your key to the keyring right up to the time of the last keysigning event. thanks joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIKzC58AA1q7Z/VrIRAjJ7AJ9XesqRDS+G/rvALv8C6Qvz09m1TQCdGXm4 DI7hvWVm7c4Q5YiAY8sAbS4= =9OmY -----END PGP SIGNATURE----- From jmatthews at cia.com Wed May 14 15:31:57 2008 From: jmatthews at cia.com (Jake Matthews) Date: Wed, 14 May 2008 16:31:57 -0400 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? Message-ID: <482B4C3D.7000209@cia.com> Apparently Charter is going to packetsniff its users and use that for commercial purposes. Looks like the only way to somewhat opt out is by getting a cookie set at the below link - which is not only a dumb idea, but still - not even https. http://connect.charter.com/cas/portal/settings/privacyoptout.aspx Anyones thoughts on this? -j From jmp at witbe.net Wed May 14 15:47:12 2008 From: jmp at witbe.net (Jean-Michel Planche) Date: Wed, 14 May 2008 22:47:12 +0200 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <482B4C3D.7000209@cia.com> References: <482B4C3D.7000209@cia.com> Message-ID: <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> In same spirit, something worst I think ... If you are in some airport with a GSM/Wifi phone, you are going to receive a mail, from local Wifi provider to explain you how to reach his (local wifi) network. Tested in Roissy / France, with iPhone. iPhone will switch from edge to wifi connection. I think that some application try to reach their server (like mail) and local provider sniff differents things (user name / mail sure but what about passwd ??) to send you back an email. Interesting ... ----------------------------- Jean-Michel Planche blog: http://www.jmp.net Chairman and co-founder Witbe web : http://www.witbe.net Follow me http://www.twitter.com/jmplanche ------------------------------------------- 2.0 Monitoring : relevant End to End monitoring for critical app. and carrier class services Le 14 mai 08 ? 22:31, Jake Matthews a ?crit : > Apparently Charter is going to packetsniff its users and use that for > commercial purposes. > > Looks like the only way to somewhat opt out is by getting a cookie set > at the below link - which is not only a dumb idea, but still - not > even > https. > http://connect.charter.com/cas/portal/settings/privacyoptout.aspx > > Anyones thoughts on this? > > -j > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From msa at latt.net Wed May 14 15:49:49 2008 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 14 May 2008 13:49:49 -0700 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <482B4C3D.7000209@cia.com> References: <482B4C3D.7000209@cia.com> Message-ID: <20080514204949.GA91321@puck.nether.net> On Wed, May 14, 2008 at 04:31:57PM -0400, Jake Matthews wrote: > Apparently Charter is going to packetsniff its users and use that for > commercial purposes. I think you'd find they'd run pretty far afoul of 18 USC 2511 for that, without prior consent (18 USC 2511 2) (c)). I looked at that page, and as far as I can tell, they are just referring to web ads, likely placed on their consumer portal site. Where do you get the notion that they are intercepting traffic? Everything I see refers to a third party ad network, with no subscriber data provided by charter. i.e. a typical advertisers tracking cookie. Using another cookie to opt out of the first cookie isn't unusual, since it's the same mechanism that would be involved in the first place. In any case, trying to correlate captured traffic to a cookie that would only be exposed in web traffic and to the site that set it, would not be reliably possible. --msa From jmatthews at cia.com Wed May 14 16:19:26 2008 From: jmatthews at cia.com (Jake Matthews) Date: Wed, 14 May 2008 17:19:26 -0400 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <20080514204949.GA91321@puck.nether.net> References: <482B4C3D.7000209@cia.com> <20080514204949.GA91321@puck.nether.net> Message-ID: <482B575E.9080002@cia.com> Majdi S. Abbas wrote: > On Wed, May 14, 2008 at 04:31:57PM -0400, Jake Matthews wrote: > >> Apparently Charter is going to packetsniff its users and use that for >> commercial purposes. >> > > I think you'd find they'd run pretty far afoul of 18 USC 2511 > for that, without prior consent (18 USC 2511 2) (c)). > > I looked at that page, and as far as I can tell, they are just > referring to web ads, likely placed on their consumer portal site. > > Where do you get the notion that they are intercepting traffic? > Everything I see refers to a third party ad network, with no subscriber > data provided by charter. i.e. a typical advertisers tracking > cookie. > > Using another cookie to opt out of the first cookie isn't > unusual, since it's the same mechanism that would be involved in the > first place. > > In any case, trying to correlate captured traffic to a > cookie that would only be exposed in web traffic and to the site that > set it, would not be reliably possible. > > --msa > > http://www.dslreports.com/forum/r20461817-HSI-Charter-to-monitor-surfing-insert-its-own-targeted-ads Apparently, not just their portal. From aaron.glenn at gmail.com Wed May 14 17:19:31 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Wed, 14 May 2008 15:19:31 -0700 Subject: [NANOG] Alcatel In-Reply-To: <482B2B51.2010909@antel.net.uy> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> <482B18E9.6080908@antel.net.uy> <482B2B51.2010909@antel.net.uy> Message-ID: <18f601940805141519q46ac2695w8f485ee6458a2c46@mail.gmail.com> On Wed, May 14, 2008 at 11:11 AM, Nicolas Antoniello wrote: > Ok, I agree with you, may be I didn't explain myself clear: I meant "neutral" in the sense > of relation with each other (i.e. Not being hostile). hopefully we're all big boys and girls and can identify a strong opinion when we see one. are we supposed to be afraid of speaking our mind because it might hurt a vendors feelings? I mean, I could take offense to the fact you mentioned you're not from the US -- implying that all US citizens are generally hostile in their opinions; but I don't. Tim's simply giving his opinion as the OP requested -- in a much more mature manner than a few other posts on this list in the past... From onewingaengel at gmail.com Wed May 14 17:19:34 2008 From: onewingaengel at gmail.com (John Menerick) Date: Wed, 14 May 2008 15:19:34 -0700 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <482B575E.9080002@cia.com> References: <482B4C3D.7000209@cia.com> <20080514204949.GA91321@puck.nether.net> <482B575E.9080002@cia.com> Message-ID: <66174ca60805141519p1dfe8a54t767da575c9091601@mail.gmail.com> Something Jon Devree and I were thinking about: How would they handle cookies the size of 1 MB or larger? Scary as it sounds, looks like a simple DOS attack waiting to happen :\ JOhn Menerick On Wed, May 14, 2008 at 2:19 PM, Jake Matthews wrote: > Majdi S. Abbas wrote: > > On Wed, May 14, 2008 at 04:31:57PM -0400, Jake Matthews wrote: > > > >> Apparently Charter is going to packetsniff its users and use that for > >> commercial purposes. > >> > > > > I think you'd find they'd run pretty far afoul of 18 USC 2511 > > for that, without prior consent (18 USC 2511 2) (c)). > > > > I looked at that page, and as far as I can tell, they are just > > referring to web ads, likely placed on their consumer portal site. > > > > Where do you get the notion that they are intercepting traffic? > > Everything I see refers to a third party ad network, with no subscriber > > data provided by charter. i.e. a typical advertisers tracking > > cookie. > > > > Using another cookie to opt out of the first cookie isn't > > unusual, since it's the same mechanism that would be involved in the > > first place. > > > > In any case, trying to correlate captured traffic to a > > cookie that would only be exposed in web traffic and to the site that > > set it, would not be reliably possible. > > > > --msa > > > > > > http://www.dslreports.com/forum/r20461817-HSI-Charter-to-monitor-surfing-insert-its-own-targeted-ads > > Apparently, not just their portal. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From onewingaengel at gmail.com Wed May 14 17:23:28 2008 From: onewingaengel at gmail.com (John Menerick) Date: Wed, 14 May 2008 15:23:28 -0700 Subject: [NANOG] Alcatel In-Reply-To: <18f601940805141519q46ac2695w8f485ee6458a2c46@mail.gmail.com> References: <1c2d53bb0805131016y2e0ca57bwfead1e96efb004ee@mail.gmail.com> <620fd17c0805140857k6da38cb2qf75a14114c12eb57@mail.gmail.com> <482B18E9.6080908@antel.net.uy> <482B2B51.2010909@antel.net.uy> <18f601940805141519q46ac2695w8f485ee6458a2c46@mail.gmail.com> Message-ID: <66174ca60805141523l2c9c2192u614e7adbd51d2356@mail.gmail.com> I have been using the 7750/7450 in a couple of my production environments. I have to say this: AMAZING. I have had very little problems with these machines. Their support has been amazing. I would recommend these machines to anyone. Beware of the price though. You def. get what you pay for with the 7750. John Menerick On Wed, May 14, 2008 at 3:19 PM, Aaron Glenn wrote: > On Wed, May 14, 2008 at 11:11 AM, Nicolas Antoniello > wrote: > > Ok, I agree with you, may be I didn't explain myself clear: I meant > "neutral" in the sense > > of relation with each other (i.e. Not being hostile). > > hopefully we're all big boys and girls and can identify a strong > opinion when we see one. are we supposed to be afraid of speaking our > mind because it might hurt a vendors feelings? I mean, I could take > offense to the fact you mentioned you're not from the US -- implying > that all US citizens are generally hostile in their opinions; but I > don't. > > Tim's simply giving his opinion as the OP requested -- in a much more > mature manner than a few other posts on this list in the past... > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From deepak at ai.net Wed May 14 17:30:42 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 14 May 2008 18:30:42 -0400 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <482B575E.9080002@cia.com> References: <482B4C3D.7000209@cia.com> <20080514204949.GA91321@puck.nether.net> <482B575E.9080002@cia.com> Message-ID: <482B6812.6060707@ai.net> > http://www.dslreports.com/forum/r20461817-HSI-Charter-to-monitor-surfing-insert-its-own-targeted-ads > This is definitely taking the position that its "their" pipe and not the *Internet*. I can only imagine the issues that will get wrangled around in the courts over this. (ahem, Google, ahem). This is not fundamentally different than a TV station digitally inserting their own ads on the stadium instead of whatever is there you might see in person. This *seems* like a problem because most people only have 1 connectivity provider at a time and often few options around it. Regulation could address this, a differentiated service could address this, but this smacks of paying for a service to then get additional ads sent to you. (like everytime you dialed a number into your Skype for Pizza Delivery, they sent you to their paid-Pizza Delivery provider instead). Depending on how invasive (or effective) this gets, it has wild common-carrier implications. Deepak Jain AiNET From patrick at chegg.com Wed May 14 17:40:42 2008 From: patrick at chegg.com (Patrick Clochesy) Date: Wed, 14 May 2008 15:40:42 -0700 (PDT) Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <482B6812.6060707@ai.net> Message-ID: <17015706.94721210804842427.JavaMail.root@protozoa> I think that a TV station cannot just digitally insert an ad into copyrighted material, as it would be considered a derivative work. .. they have approval and pay to do that. I wonder what the legal implications for a web page would be, I would almost assume they would be the same. -Patrick ----- Original Message ----- From: "Deepak Jain" To: "Jake Matthews" Cc: nanog at nanog.org Sent: Wednesday, May 14, 2008 3:30:42 PM (GMT-0800) America/Los_Angeles Subject: Re: [NANOG] Charter Communications going to sniff traffic for advertising? > http://www.dslreports.com/forum/r20461817-HSI-Charter-to-monitor-surfing-insert-its-own-targeted-ads > This is definitely taking the position that its "their" pipe and not the *Internet*. I can only imagine the issues that will get wrangled around in the courts over this. (ahem, Google, ahem). This is not fundamentally different than a TV station digitally inserting their own ads on the stadium instead of whatever is there you might see in person. This *seems* like a problem because most people only have 1 connectivity provider at a time and often few options around it. Regulation could address this, a differentiated service could address this, but this smacks of paying for a service to then get additional ads sent to you. (like everytime you dialed a number into your Skype for Pizza Delivery, they sent you to their paid-Pizza Delivery provider instead). Depending on how invasive (or effective) this gets, it has wild common-carrier implications. Deepak Jain AiNET _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From tony at swalter.com Wed May 14 17:46:00 2008 From: tony at swalter.com (Tony Patti) Date: Wed, 14 May 2008 22:46:00 +0000 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? Message-ID: <20080514224653.D1D1C1F8056@smtp01.swalter.com> deepak at ai.net wrote: > Regulation could address this, a differentiated service could address > this, but this smacks of paying for a service to then get additional ads > sent to you. (like everytime you dialed a number into your Skype for > Pizza Delivery, they sent you to their paid-Pizza Delivery provider > instead). Maybe history does repeat itself. The paragraph above reminds me of the origin of the Strowger Switch: http://en.wikipedia.org/wiki/Strowger_switch "According to legend, Almon Strowger was motivated to invent an automatic telephone exchange after having difficulties with the local telephone operators. He was said to be convinced that the local manual telephone exchange operators were sending calls to a competing undertaker business." Tony Patti CIO S. Walter Packaging Corp. From simon at slimey.org Wed May 14 17:47:22 2008 From: simon at slimey.org (Simon Lockhart) Date: Wed, 14 May 2008 23:47:22 +0100 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <482B4C3D.7000209@cia.com> References: <482B4C3D.7000209@cia.com> Message-ID: <20080514224722.GZ10920@virtual.bogons.net> On Wed May 14, 2008 at 04:31:57PM -0400, Jake Matthews wrote: > Apparently Charter is going to packetsniff its users and use that for > commercial purposes. > Anyones thoughts on this? There's a company called Phorm (www.phorm.com) trying to do this in the UK, running some trials with some of the large broadband providers. It hasn't gone down well at all... http://www.theregister.co.uk/2008/02/29/phorm_roundup/ Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From surfer at mauigateway.com Wed May 14 18:05:52 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 14 May 2008 16:05:52 -0700 Subject: [NANOG] Alcatel Message-ID: <20080514160552.C1021A7B@resin17.mta.everyone.net> Top posting due to lengthy email... In my experience from the last year on Alcatel (several years on E and M Juniper before that) you couldn't be more wrong. As far as looking at the config, I back them up to a UNIX box nightly. ":1,$ s/exit//" Not one of the support guys has ever mentioned SAM when trying to figure something with them out on the CLI, but I do have to agree SAM suks compared to self-written .pl code. scott --- pauldotwall at gmail.com wrote: From: "Paul Wall" To: "Dan Snyder" Cc: nanog at nanog.org Subject: Re: [NANOG] Alcatel Date: Wed, 14 May 2008 11:57:03 -0400 On Tue, May 13, 2008 at 1:16 PM, Dan Snyder wrote: > What about Alcatel's MPLS edge routers like the 7x50 products that > came from Timetra...anyone have any experience with them? Are they a > good product? Garbage, the 7750/7450 are complete junk boxes. Here is why... - For fun, view a 7750/7540 router configuration file and grep for the word "exit". Count how many times you see that word. To sum it up, the CLI is kind of annoying. Lets just say the 7x50 rivals a Bay Annex CLI for uselessness. - They attempted to mimic the Juniper style of policy-statements, but they still fall short of it. Whats up with the pseudo-commit crap? - The majority of ALU folks supporting the 7x50 are all from former failed router vendors (caspian, nexabit, etc). When you deal with such teams, keep your operator hat on and realize that some of the stuff being suggested are from people who've never worked in production. - 7x50 is about 1-2 years behind Cisco and Juniper on any feature functionality on the boxes. - The ALU business unit has no comprehension why users want to interface with the box via CLI as opposed to their SAM EMS junk. The BU and the former Newbridge developers think folks run their network from a Sparc via a GUI. Times have changed...NETCONF what? - If you haven't run into any BGP scaling issues yet, you will, soon. - Limited RSVP-TE support...nothing compared to Juniper. There are plenty of other better options like the Cisco 6500/7600 as well as the Juniper MX. Why settle for sub-standard CLI, weak features and a business unit who has no operational experience and their only claim to fame was gobbling up companies and exploiting their long-time industry friendships to seal massive deals. I know some will reply to talk about their great failover is and this and that, whatever. To get the box where it is today a lot of pain was endured by plenty of customers who had to deal with a not-so-nice Alcatel. The box pricing is not that great and for the same money you can find better elsewhere. _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From nanog at nanog.org Thu May 15 01:57:54 2008 From: nanog at nanog.org (nanog at nanog.org) Date: Thu, 15 May 2008 06:57:54 -0000 Subject: [NANOG] Tired of overpaying for meds at your local pharm store? Here is the one stop solution for yo Message-ID: <20080515115823.3103.qmail@ao-smmm> Tired of overpaying for meds at your local pharm store? Here is the one stop solution for you: Housing the world's largest selection of items in one online store, you can purchase meds from the comfort of your home. Hundreds of presc. meds available at just a click for all your health needs - no troublesome visits to the doc, and no exorbitant prices to pay. Recommended by healthcare professionals and thousands of satisfied customers worldwide - visit us today. http://successnetworks.org/images/busts/ From fergdawg at netzero.net Thu May 15 02:09:16 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 15 May 2008 07:09:16 GMT Subject: [NANOG] Tired of overpaying for meds at your local pharm store? He re is the one stop solution for yo Message-ID: <20080515.000916.27049.3@webmail08.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- wrote: >Tired of overpaying for meds at your local pharm store? Here is the one >stop solution for you: > Wow. How timely. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIK+GYq1pz9mNUZTMRAgbtAKCqkDMbwLRwiQQD2qscDKoEaiF8BwCfYnnl v3A1pAFUKAcj5KExdSvjawg= =hb/k -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From eh at profzone.ch Thu May 15 02:38:04 2008 From: eh at profzone.ch (Erich Hohermuth) Date: Thu, 15 May 2008 09:38:04 +0200 Subject: [NANOG] Installation troubles with GlobalCrossing Message-ID: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> Dear members, I just want to ask if anyone else have major troubles to install new or upgrade services with Global Crossing ? The story: Last year on December we ordered two layer2 point to point connections based on gigabit ethernet connections. The main idea was to directly connect to the peering point. After waiting 3 months and lots of mails they get the right hardware in place but now 6 months later we still don't have a running service, because they just implement something with tagged interfaces on one the peering point site without asking. Regards Eric From bpfankuch at cpgreeley.com Thu May 15 07:31:59 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Thu, 15 May 2008 06:31:59 -0600 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> Message-ID: <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> I noticed this as well with a windows mobile device and activesync over the ail. Enforcing SSL communication seems to have fixed it, as I no longer get these after doing that. Of course this assumes that your mail server does not need plain text authentication. I noticed this a lot when I was flying back and forth from Houston and DFW out of Denver. Never identified the culprit of who was harvesting but.... -----Original Message----- From: Jean-Michel Planche [mailto:jmp at witbe.net] Sent: Wednesday, May 14, 2008 2:47 PM To: Jake Matthews Cc: nanog at nanog.org Subject: Re: [NANOG] Charter Communications going to sniff traffic foradvertising? In same spirit, something worst I think ... If you are in some airport with a GSM/Wifi phone, you are going to receive a mail, from local Wifi provider to explain you how to reach his (local wifi) network. Tested in Roissy / France, with iPhone. iPhone will switch from edge to wifi connection. I think that some application try to reach their server (like mail) and local provider sniff differents things (user name / mail sure but what about passwd ??) to send you back an email. Interesting ... ----------------------------- Jean-Michel Planche blog: http://www.jmp.net Chairman and co-founder Witbe web : http://www.witbe.net Follow me http://www.twitter.com/jmplanche ------------------------------------------- 2.0 Monitoring : relevant End to End monitoring for critical app. and carrier class services Le 14 mai 08 ? 22:31, Jake Matthews a ?crit : > Apparently Charter is going to packetsniff its users and use that for > commercial purposes. > > Looks like the only way to somewhat opt out is by getting a cookie set > at the below link - which is not only a dumb idea, but still - not > even > https. > http://connect.charter.com/cas/portal/settings/privacyoptout.aspx > > Anyones thoughts on this? > > -j > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From rsk at gsp.org Thu May 15 07:59:03 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 15 May 2008 08:59:03 -0400 Subject: [NANOG] Charter Communications going to sniff traffic for advertising? In-Reply-To: <20080514224722.GZ10920@virtual.bogons.net> References: <482B4C3D.7000209@cia.com> <20080514224722.GZ10920@virtual.bogons.net> Message-ID: <20080515125903.GA12430@gsp.org> On Wed, May 14, 2008 at 11:47:22PM +0100, Simon Lockhart wrote: > There's a company called Phorm (www.phorm.com) trying to do this in the UK, > running some trials with some of the large broadband providers. Phorm has been linked to the Russian Business Network (RBN), which is unsurprising given that Phorm is in the spyware/adware business. For a particular insightful writeup, please see: Some notes from the Phorm sales pitch http://yro.slashdot.org/comments.pl?sid=489948&cid=22777122 ---Rsk From owen at delong.com Thu May 15 08:34:25 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 15 May 2008 06:34:25 -0700 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> Message-ID: I've found that using SSL for all my SMTP and IMAP transactions and not entering personally identifying information into non-SSL web pages greatly reduces the amount of harvesting results I see. As to Charter, I opt out by simply not purchasing anything from them. It seems to work far better than bothering with their silly cookie process. Owen On May 15, 2008, at 5:31 AM, Blake Pfankuch wrote: > I noticed this as well with a windows mobile device and activesync > over the ail. Enforcing SSL communication seems to have fixed it, > as I no longer get these after doing that. Of course this assumes > that your mail server does not need plain text authentication. I > noticed this a lot when I was flying back and forth from Houston and > DFW out of Denver. Never identified the culprit of who was > harvesting but.... > > -----Original Message----- > From: Jean-Michel Planche [mailto:jmp at witbe.net] > Sent: Wednesday, May 14, 2008 2:47 PM > To: Jake Matthews > Cc: nanog at nanog.org > Subject: Re: [NANOG] Charter Communications going to sniff traffic > foradvertising? > > In same spirit, something worst I think ... > If you are in some airport with a GSM/Wifi phone, you are going to > receive a mail, from local Wifi provider to explain you how to reach > his (local wifi) network. > Tested in Roissy / France, with iPhone. iPhone will switch from edge > to wifi connection. I think that some application try to reach their > server (like mail) and local provider sniff differents things (user > name / mail sure but what about passwd ??) to send you back an email. > Interesting ... > > > > ----------------------------- > Jean-Michel Planche blog: http://www.jmp.net > Chairman and co-founder Witbe web : http://www.witbe.net > Follow me http://www.twitter.com/jmplanche > ------------------------------------------- > 2.0 Monitoring : relevant End to End monitoring for critical app. and > carrier class services > > > > Le 14 mai 08 ? 22:31, Jake Matthews a ?crit : > >> Apparently Charter is going to packetsniff its users and use that for >> commercial purposes. >> >> Looks like the only way to somewhat opt out is by getting a cookie >> set >> at the below link - which is not only a dumb idea, but still - not >> even >> https. >> http://connect.charter.com/cas/portal/settings/privacyoptout.aspx >> >> Anyones thoughts on this? >> >> -j >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From jared at puck.nether.net Thu May 15 08:46:05 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 15 May 2008 09:46:05 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> Message-ID: On May 15, 2008, at 9:34 AM, Owen DeLong wrote: > I've found that using SSL for all my SMTP and IMAP transactions > and not entering personally identifying information into non-SSL > web pages greatly reduces the amount of harvesting results I see. > > As to Charter, I opt out by simply not purchasing anything from them. > It seems to work far better than bothering with their silly cookie > process. I think that's fine and all, but there are people where choice doesn't exist. I would chose FIOS (or a fios-like service) for my home internet. That choice does not exist. Verizon has not built that infrastructure in my state, nor does it appear they have any plans to. Where choice does not exist, and there is no high-speed duopoly to choose between, what would you do? Build your own infrastructure a few miles at a cost of $2-50+/foot? - Jared From smb at cs.columbia.edu Thu May 15 08:58:23 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 15 May 2008 09:58:23 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> Message-ID: <20080515095823.4dc6f49b@cs.columbia.edu> On Thu, 15 May 2008 09:46:05 -0400 Jared Mauch wrote: > > On May 15, 2008, at 9:34 AM, Owen DeLong wrote: > > > I've found that using SSL for all my SMTP and IMAP transactions > > and not entering personally identifying information into non-SSL > > web pages greatly reduces the amount of harvesting results I see. > > > > As to Charter, I opt out by simply not purchasing anything from > > them. It seems to work far better than bothering with their silly > > cookie process. > > I think that's fine and all, but there are people where choice > doesn't exist. > > I would chose FIOS (or a fios-like service) for my home internet. > That choice does not exist. > > Verizon has not built that infrastructure in my state, nor does it > appear they have any plans to. > > Where choice does not exist, and there is no high-speed duopoly to > choose between, what would you do? Build your own infrastructure a > few miles at a cost of $2-50+/foot? > The other day, the Wall Street Journal ran a brief piece on VPN providers... The threat they had in mind was wireless hotspots, but any sort of on-link evil can be dealt with that way. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jay at west.net Thu May 15 10:23:59 2008 From: jay at west.net (Jay Hennigan) Date: Thu, 15 May 2008 08:23:59 -0700 Subject: [NANOG] Tired of ... In-Reply-To: <20080515115823.3103.qmail@ao-smmm> References: <20080515115823.3103.qmail@ao-smmm> Message-ID: <482C558F.2070100@west.net> Someone via nanog at nanog.org spammed: > Tired of [snip] Can anyone suggest a faster way to get yourself blackholed than to spam this list? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From simonw at zynet.net Thu May 15 11:35:18 2008 From: simonw at zynet.net (Simon Waters) Date: Thu, 15 May 2008 17:35:18 +0100 Subject: [NANOG] Tired of ... In-Reply-To: <482C558F.2070100@west.net> References: <20080515115823.3103.qmail@ao-smmm> <482C558F.2070100@west.net> Message-ID: <200805151735.19419.simonw@zynet.net> On Thursday 15 May 2008 16:23, Jay Hennigan wrote: > Someone via nanog at nanog.org spammed: > > Tired of > > [snip] > > Can anyone suggest a faster way to get yourself blackholed than to spam > this list? Spammers still spam our abuse address, that might do it. From eddy at fasteddy.org Thu May 15 12:13:22 2008 From: eddy at fasteddy.org (Eddy Martinez) Date: Thu, 15 May 2008 10:13:22 -0700 Subject: [NANOG] Installation troubles with GlobalCrossing In-Reply-To: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> References: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> Message-ID: <5E3B118E-7F80-4AC9-890D-D78A7A171936@fasteddy.org> On May 15, 2008, at 12:38 AM, Erich Hohermuth wrote: > Dear members, > > I just want to ask if anyone else have major troubles to install new > or > upgrade services with Global Crossing ? > > The story: > > Last year on December we ordered two layer2 point to point connections > based on gigabit ethernet connections. The main idea was to directly > connect to the peering point. After waiting 3 months and lots of mails > they get the right hardware in place but now 6 months later we still > don't have a running service, because they just implement something > with > tagged interfaces on one the peering point site without asking. > > Regards > Eric > Hi Eric, I had a similar problem with Time Warner in Souther California. The point to point was office <-> data center. The issue turned out to be the tagged packet for our tunnel were too large for the current layer two network. They increased the packet size and all was good. It also took 6 months to get this line up and running as promised. This required a change to the config and a reboot of some gear along the path. Our CFO and an attorney sent a letter stating that if the line was not up by X date, the contract would be considered null and void. They delivered. Hope this helps, Eddy From morrowc.lists at gmail.com Thu May 15 12:30:52 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 May 2008 13:30:52 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: <20080515095823.4dc6f49b@cs.columbia.edu> References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> <20080515095823.4dc6f49b@cs.columbia.edu> Message-ID: <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> On Thu, May 15, 2008 at 9:58 AM, Steven M. Bellovin wrote: > On Thu, 15 May 2008 09:46:05 -0400 > The other day, the Wall Street Journal ran a brief piece on VPN > providers... The threat they had in mind was wireless hotspots, but > any sort of on-link evil can be dealt with that way. sure would be nice if some vendor would partner with a CDN-type group (or a vendor that had enough 'local presence') to offer this sort of thing... It doesnt' neessarily have to be IPSEC or SSL I bet... though longer term SSL or IPSEC seem like better options (since phorm/blah will quickly start poking into PPTP/gre tunnels as well). Oh, how do you know you can trust the VPN folks anymore than the cable-modem folks though? eventually the same cost issues are going to arise for the VPN folks as did for cable-modem/dsl folks (downward pressure on pricing and infra/opex/capex costs going up/not-decreasing). -Chris From lsc at prgmr.com Thu May 15 13:14:31 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 15 May 2008 14:14:31 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> <20080515095823.4dc6f49b@cs.columbia.edu> <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> Message-ID: "Christopher Morrow" writes: > Oh, how do you know you can trust the VPN folks anymore than the > cable-modem folks though? eventually the same cost issues are going to > arise for the VPN folks as did for cable-modem/dsl folks (downward > pressure on pricing and infra/opex/capex costs going > up/not-decreasing). Unlike running fiber to your door, renting a VPS and setting up a vpn server is quite inexpensive to do yourself. From smb at cs.columbia.edu Thu May 15 13:22:43 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 15 May 2008 14:22:43 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> <20080515095823.4dc6f49b@cs.columbia.edu> <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> Message-ID: <20080515142243.40052545@cs.columbia.edu> On Thu, 15 May 2008 13:30:52 -0400 "Christopher Morrow" wrote: > > Oh, how do you know you can trust the VPN folks anymore than the > cable-modem folks though? eventually the same cost issues are going to > arise for the VPN folks as did for cable-modem/dsl folks (downward > pressure on pricing and infra/opex/capex costs going > up/not-decreasing). > They're not more trustworthy, but since they don't require widespread local physical infrastructure it's potentially a more competitive market. --Steve Bellovin, http://www.cs.columbia.edu/~smb From morrowc.lists at gmail.com Thu May 15 14:01:41 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 May 2008 15:01:41 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> <20080515095823.4dc6f49b@cs.columbia.edu> <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> Message-ID: <75cb24520805151201x5c563fa9y1eedf56e41d32627@mail.gmail.com> On Thu, May 15, 2008 at 2:14 PM, Luke S Crawford wrote: > "Christopher Morrow" writes: >> Oh, how do you know you can trust the VPN folks anymore than the >> cable-modem folks though? eventually the same cost issues are going to >> arise for the VPN folks as did for cable-modem/dsl folks (downward >> pressure on pricing and infra/opex/capex costs going >> up/not-decreasing). > > Unlike running fiber to your door, renting a VPS and setting up a > vpn server is quite inexpensive to do yourself. note the 'close to the user' part of the plan ... limit addtional latency and user experience hit. but other than that sure. From morrowc.lists at gmail.com Thu May 15 14:07:35 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 May 2008 15:07:35 -0400 Subject: [NANOG] Charter Communications going to sniff traffic foradvertising? In-Reply-To: <20080515142243.40052545@cs.columbia.edu> References: <482B4C3D.7000209@cia.com> <0175611B-7DBF-42F6-8A40-D2BE95F47AA0@witbe.net> <97E08945C0C1024FA818C68D6F252D650206B646@exserver.cpgreeley.com> <20080515095823.4dc6f49b@cs.columbia.edu> <75cb24520805151030h1a14be48w69b4ccc969883d9a@mail.gmail.com> <20080515142243.40052545@cs.columbia.edu> Message-ID: <75cb24520805151207g67279779sdaed2aba7ad89648@mail.gmail.com> On Thu, May 15, 2008 at 2:22 PM, Steven M. Bellovin wrote: > On Thu, 15 May 2008 13:30:52 -0400 > "Christopher Morrow" wrote: > >> >> Oh, how do you know you can trust the VPN folks anymore than the >> cable-modem folks though? eventually the same cost issues are going to >> arise for the VPN folks as did for cable-modem/dsl folks (downward >> pressure on pricing and infra/opex/capex costs going >> up/not-decreasing). >> > They're not more trustworthy, but since they don't require widespread > local physical infrastructure it's potentially a more competitive > market. right, so not 'today' not 'tomorrow' if this becomes a service that is percieved as valuable and useful more providers will pop in this market (like cable vs dsl vs dialup), pricing pressure will start, profit margins will shrink... then ... Oh look! If I give my user meta data to CompanyX I'll get profit without any real capex expenditure! Yea, free money!!! So, how long until that happens? Hopefully when that happens there will be enough other vpn provider options so it won't matter as much as it does in the current US Duopoly... I mean 'competitive local landscape'. -Chris From deepak at ai.net Thu May 15 16:21:30 2008 From: deepak at ai.net (Deepak Jain) Date: Thu, 15 May 2008 17:21:30 -0400 Subject: [NANOG] BCP Muni WiFI? Message-ID: <482CA95A.9070905@ai.net> Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? Thanks in advance, DJ From ops.lists at gmail.com Thu May 15 21:04:29 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 16 May 2008 07:34:29 +0530 Subject: [NANOG] BCP Muni WiFI? In-Reply-To: <482CA95A.9070905@ai.net> References: <482CA95A.9070905@ai.net> Message-ID: On Fri, May 16, 2008 at 2:51 AM, Deepak Jain wrote: > > Are there any good (published) BCPs for building out Municipal WiFi > networks? Particularly in the security/authentication/scaling areas? > Ask Earthlink, they just announced pulling out of Philly .. and I guess they had a working deployment going by the time they pulled out (and the reasons for that pullout would do for a great white paper all by themselves, I expect...) -- Suresh Ramasubramanian (ops.lists at gmail.com) From yuan_zhihui at venustech.com.cn Thu May 15 21:28:07 2008 From: yuan_zhihui at venustech.com.cn (=?gb2312?B?1KzWx7vU?=) Date: Fri, 16 May 2008 10:28:07 +0800 Subject: [NANOG] Questions about NETCONF In-Reply-To: <482CA95A.9070905@ai.net> Message-ID: <20080516023256.DE82236C006@mail.venustech.com.cn> How is the state of arts of NETCONF (RFC 4741) protocol? Is there any Network Management System Deployed which is base on NETCONF? Do you think security products (like Firewall, IDS/IPS and Security Operation Centre) can benefit from NETCONF? Thanks in advance, Devin From john at sackheads.org Fri May 16 06:18:44 2008 From: john at sackheads.org (John Payne) Date: Fri, 16 May 2008 07:18:44 -0400 Subject: [NANOG] Questions about NETCONF In-Reply-To: <20080516023256.DE82236C006@mail.venustech.com.cn> References: <20080516023256.DE82236C006@mail.venustech.com.cn> Message-ID: <9219BF27-1533-406B-8D7D-95255E6A7774@sackheads.org> On May 15, 2008, at 10:28 PM, ??? wrote: > > How is the state of arts of NETCONF (RFC 4741) protocol? > > Is there any Network Management System Deployed which is base on > NETCONF? I've personally been waiting for the data modeling to be standardized. Yes, it's great and wonderful to have a consistent method of talking to network devices, but I also want a standard data model along with it. > > Do you think security products (like Firewall, IDS/IPS and Security > Operation Centre) can benefit from NETCONF? I believe any network device can benefit from netconf. From randy at psg.com Fri May 16 06:22:20 2008 From: randy at psg.com (Randy Bush) Date: Fri, 16 May 2008 13:22:20 +0200 Subject: [NANOG] Questions about NETCONF In-Reply-To: <9219BF27-1533-406B-8D7D-95255E6A7774@sackheads.org> References: <20080516023256.DE82236C006@mail.venustech.com.cn> <9219BF27-1533-406B-8D7D-95255E6A7774@sackheads.org> Message-ID: <482D6E6C.2030805@psg.com> > I've personally been waiting for the data modeling to be > standardized. Yes, it's great and wonderful to have a consistent > method of talking to network devices, but I also want a standard data > model along with it. does this not imply that all devices would need to be semantically congruent? if so, is this realistic? randy From cidr-report at potaroo.net Fri May 16 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 May 2008 22:00:04 +1000 (EST) Subject: [NANOG] BGP Update Report Message-ID: <200805161200.m4GC04VN076717@wattle.apnic.net> BGP Update Report Interval: 14-Apr-08 -to- 15-May-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 111266 1.1% 92.0 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - AS9583 79859 0.8% 65.6 -- SIFY-AS-IN Sify Limited 3 - AS6140 67771 0.7% 98.5 -- IMPSAT-USA - ImpSat USA, Inc. 4 - AS17974 64466 0.6% 141.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS10796 59308 0.6% 77.1 -- SCRR-10796 - Road Runner HoldCo LLC 6 - AS2386 59219 0.6% 41.3 -- INS-AS - AT&T Data Communications Services 7 - AS29571 58039 0.6% 397.5 -- CITelecom-AS 8 - AS4755 53254 0.5% 32.2 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 9 - AS8151 51646 0.5% 41.6 -- Uninet S.A. de C.V. 10 - AS26829 49478 0.5% 49478.0 -- YKK-USA - YKK USA,INC 11 - AS6517 47810 0.5% 71.4 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 12 - AS4538 46765 0.5% 9.6 -- ERX-CERNET-BKB China Education and Research Network Center 13 - AS24731 46456 0.5% 573.5 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 14 - AS17488 46283 0.5% 40.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 15 - AS6389 45657 0.5% 28.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 16 - AS9198 44710 0.4% 90.0 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 17 - AS7018 42522 0.4% 28.7 -- ATT-INTERNET4 - AT&T WorldNet Services 18 - AS11060 41810 0.4% 319.2 -- NEO-RR-COM - Road Runner HoldCo LLC 19 - AS11492 39948 0.4% 32.6 -- CABLEONE - CABLE ONE 20 - AS6478 38498 0.4% 40.0 -- ATT-INTERNET3 - AT&T WorldNet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26829 49478 0.5% 49478.0 -- YKK-USA - YKK USA,INC 2 - AS42787 28944 0.3% 9648.0 -- MMIP-AS MultiMedia IP Ltd. 3 - AS28646 7633 0.1% 7633.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 4 - AS30929 6586 0.1% 6586.0 -- HUTCB Hidrotechnical Faculty - Technical University 5 - AS42923 5848 0.1% 5848.0 -- PLK-AS PLK AS Number 6 - AS19017 4606 0.0% 4606.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 7 - AS19334 4250 0.0% 4250.0 -- SPORTLINE-DBC - SPORTLINE 8 - AS40359 4036 0.0% 4036.0 -- SOUTHEASTERNMILLS-ROME - Southeastern Mills, Inc. 9 - AS23082 18344 0.2% 3668.8 -- MPHI - Michigan Public Health Institute 10 - AS16466 17912 0.2% 3582.4 -- AVAYA AVAYA 11 - AS32996 3575 0.0% 3575.0 -- AGRIBANK-STPAUL - AgriBank, FCB 12 - AS29910 3572 0.0% 3572.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 13 - AS35324 3570 0.0% 3570.0 -- ECH-WILL-AS E.C.H. Will 14 - AS18131 6230 0.1% 3115.0 -- IR3 NTT Communications Corporation 15 - AS9122 3022 0.0% 3022.0 -- TECHNOELECTROSERVIS-AS Technoelektroservis Ltd. 16 - AS11278 4675 0.1% 2337.5 -- NINTENDO - Nintendo Of America inc. 17 - AS44730 2278 0.0% 2278.0 -- ALFAGOMMA Alfa Gomma s.p.a. 18 - AS34378 2202 0.0% 2202.0 -- RUG-AS Razgulay Group 19 - AS36975 1883 0.0% 1883.0 -- CBA-AS 20 - AS27892 6976 0.1% 1744.0 -- Universidad del Zulia TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 125.23.208.0/20 63377 0.6% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 12.108.254.0/24 49478 0.5% AS26829 -- YKK-USA - YKK USA,INC 3 - 193.33.184.0/23 28860 0.3% AS42787 -- MMIP-AS MultiMedia IP Ltd. 4 - 221.128.192.0/18 26161 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 5 - 84.23.100.0/24 22302 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 6 - 221.135.80.0/24 17595 0.2% AS9583 -- SIFY-AS-IN Sify Limited 7 - 118.95.56.0/24 17095 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 213.91.175.0/24 15855 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 9 - 203.63.26.0/24 10131 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 10 - 201.77.80.0/20 7633 0.1% AS28646 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 11 - 89.4.131.0/24 7148 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 12 - 64.201.128.0/20 7026 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 13 - 135.10.4.0/24 6849 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 14 - 135.10.5.0/24 6847 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 15 - 194.8.90.0/23 6827 0.1% AS3356 -- LEVEL3 Level 3 Communications AS8220 -- COLT COLT Telecommunications 16 - 217.22.170.0/23 6604 0.1% AS16094 -- RAS Roilcom ASN (Russia) 17 - 81.180.108.0/24 6586 0.1% AS30929 -- HUTCB Hidrotechnical Faculty - Technical University 18 - 89.4.129.0/24 6325 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 19 - 65.189.229.0/24 6093 0.1% AS10796 -- SCRR-10796 - Road Runner HoldCo LLC 20 - 208.83.118.0/24 6061 0.1% AS23082 -- MPHI - Michigan Public Health Institute Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 16 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 May 2008 22:00:02 +1000 (EST) Subject: [NANOG] The Cidr Report Message-ID: <200805161200.m4GC02Du076700@wattle.apnic.net> This report has been generated at Fri May 16 21:14:57 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-05-08 265828 167071 10-05-08 266024 167271 11-05-08 265860 167432 12-05-08 265840 167382 13-05-08 266035 167641 14-05-08 266197 44301 15-05-08 71701 168206 16-05-08 265972 166150 AS Summary 28316 Number of ASes in routing system 11925 Number of ASes announcing only one prefix 4885 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88359936 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 16May08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 265829 166211 99618 37.5% All ASes AS4538 4885 868 4017 82.2% ERX-CERNET-BKB China Education and Research Network Center AS4755 1636 260 1376 84.1% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS6389 1857 590 1267 68.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS9498 1162 69 1093 94.1% BBIL-AP BHARTI BT INTERNET LTD. AS4323 1421 571 850 59.8% TWTC - Time Warner Telecom, Inc. AS22773 949 139 810 85.4% CCINET-2 - Cox Communications Inc. AS11492 1218 470 748 61.4% CABLEONE - CABLE ONE AS19262 903 168 735 81.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8151 1215 490 725 59.7% Uninet S.A. de C.V. AS1785 1017 316 701 68.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1064 376 688 64.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18101 679 123 556 81.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 945 397 548 58.0% ATT-INTERNET3 - AT&T WorldNet Services AS2386 1418 890 528 37.2% INS-AS - AT&T Data Communications Services AS7011 1086 617 469 43.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS18566 1044 584 460 44.1% COVAD - Covad Communications Co. AS4766 877 420 457 52.1% KIXS-AS-KR Korea Telecom AS22047 566 128 438 77.4% VTR BANDA ANCHA S.A. AS17676 508 74 434 85.4% GIGAINFRA BB TECHNOLOGY Corp. AS6197 1029 610 419 40.7% BATI-ATL - BellSouth Network Solutions, Inc AS855 577 168 409 70.9% CANET-ASN-4 - Bell Aliant AS7018 1417 1013 404 28.5% ATT-INTERNET4 - AT&T WorldNet Services AS6140 610 209 401 65.7% IMPSAT-USA - ImpSat USA, Inc. AS4668 668 268 400 59.9% LGNET-AS-KR LG CNS AS8103 580 183 397 68.4% STATE-OF-FLA - Florida Department of Management Services - Technology Program AS7545 497 117 380 76.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 462 84 378 81.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS3602 455 79 376 82.6% AS3602-RTI - Rogers Telecom Inc. AS4808 519 158 361 69.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4134 855 497 358 41.9% CHINANET-BACKBONE No.31,Jin-rong Street Total 32119 10936 21183 66.0% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.197.0.0/18 AS25761 STAMINUS-COMM - Staminus Communications 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.5.0.0/24 AS28175 172.6.0.0/24 AS28175 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 172.14.0.0/24 AS28175 172.15.1.0/24 AS28175 172.15.2.0/24 AS28175 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS7891 BELLSOUTH-NET-BLK2 - Bellsouth.Net 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.45.132.0/22 AS24314 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.192.0/19 AS11881 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.75.128.0/20 AS16285 ASN-UMN Ural-TransTeleCom Autonomous System 212.77.128.0/20 AS33894 RIKT-AS JSC "RITC" 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.119.128.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.119.131.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.119.141.0/24 AS14345 CRESCENT-TECH - Crescent Technology 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.239.160.0/19 AS16402 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From carolw at merit.edu Thu May 15 13:58:51 2008 From: carolw at merit.edu (Carol Wadsworth) Date: Thu, 15 May 2008 14:58:51 -0400 Subject: [NANOG] [NANOG-announce] NANOG Room Block @ Marriott Brooklyn Bridge In-Reply-To: <021991F9937C2C9E709EA55F@tulip.merit.edu> References: <021991F9937C2C9E709EA55F@tulip.merit.edu> Message-ID: <15685344A7EFE4BF424E29C0@tulip.merit.edu> NANOG 43 Meeting Attendees, Re: NANOG Room Block @ Marriott Brooklyn Bridge If you are holding a reservation at the group rate and need to cancel, please let me know. I would like to take over any cancelled reservation so the room can be reassigned to another meeting attendee, and not go back into the hotel's general inventory for resale at the prevailing rate. If you need a room, please send me your check in/check out dates and phone number. I will let you know if a cancelled room becomes available. Carol Wadsworth NANOG/Merit Network _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From devangnp at gmail.com Fri May 16 09:16:07 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 16 May 2008 09:16:07 -0500 Subject: [NANOG] Routing table for BGP Message-ID: Hi, I would like to know what route should i accept from internet full or partial? if Partial then what routes should i accept? and how many route does my router have if i will go for Partial routing table? actually I am trying to understand it by concept... my organization is small but I want to know if it is large organization or small provider then what kind of routes do i need in my routing table? regards Devang Patel From jgreco at ns.sol.net Fri May 16 09:34:15 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 16 May 2008 09:34:15 -0500 (CDT) Subject: [NANOG] Routing table for BGP In-Reply-To: from "devang patel" at May 16, 2008 09:16:07 AM Message-ID: <200805161434.m4GEYF6t050817@aurora.sol.net> > Hi, > > I would like to know what route should i accept from internet full or > partial? > if Partial then what routes should i accept? and how many route does my > router have if i will go for Partial routing table? > > actually I am trying to understand it by concept... my organization is small > but I want to know if it is large organization or small provider then what > kind of routes do i need in my routing table? If you don't know, then you should probably ask your upstream to send you a default and leave it at that. Full routes means that you get a routing entry for every network connected to the Internet. There's some two hundred thousand (plus) of them. This can be stressful on both routers and inexperienced administrators, and is probably not all that useful unless you have multiple connections to the Internet. A default gets you just about the same thing. "Partial" doesn't make too much sense, unless you really don't want to talk to certain parts of the Internet, or you're supplementing it with a default route. You could potentially do this if you had, for example, a T1 to two different providers, and wanted some outgoing traffic to go over each link. In that case, most people would prefer to get full tables from each upstream and make local decisions. This requires properly resourcing your router; the "Cidr Report" that is frequently posted here will give you an idea about /current/ requirements in terms of table size, but it is not unreasonable to look for something that can handle 30-50% growth, plus IPv6 concerns. If you've got an existing router that can't hack it, but still need to balance over two connections, that's one scenario for "partial" routes. By definition, partial would be any number between 1 and the current number of available route prefixes, and would be determined by your choice of configurations. There are some really quite excellent books on routing on the Internet available, as well as extensive information in this list's archive. Avi also has some historical documents that are probably still good. Look around http://www.freedman.net/ ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From r.engehausen at gmail.com Fri May 16 09:43:32 2008 From: r.engehausen at gmail.com (Roy) Date: Fri, 16 May 2008 07:43:32 -0700 Subject: [NANOG] Routing table for BGP In-Reply-To: References: Message-ID: <482D9D94.2050402@gmail.com> devang patel wrote: > Hi, > > > I would like to know what route should i accept from internet full or > partial? > if Partial then what routes should i accept? and how many route does my > router have if i will go for Partial routing table? > > actually I am trying to understand it by concept... my organization is small > but I want to know if it is large organization or small provider then what > kind of routes do i need in my routing table? > > regards > Devang Patel > > For small companies, I advise asking for "customer" routes. These are people directly connected to the upstream. Other than that, the default suffices. Roy From sharp at sharpone.net Fri May 16 09:45:28 2008 From: sharp at sharpone.net (Justin Sharp) Date: Fri, 16 May 2008 08:45:28 -0600 Subject: [NANOG] Routing table for BGP In-Reply-To: References: Message-ID: <482D9E08.2090506@sharpone.net> Your questions depend on several details specific to your organization, which you haven't really devulged. There are several decent books on the subject which I recommend that you invest in. see: * ISBN-10:* 0321127005 *ISBN-10:* 0596002548 http://www.oreilly.com/catalog/bgp/chapter/ch06.html -- this is a chapter from the second book which should wet your appetite a bit. Regards, --Justin devang patel wrote: > Hi, > > > I would like to know what route should i accept from internet full or > partial? > if Partial then what routes should i accept? and how many route does my > router have if i will go for Partial routing table? > > actually I am trying to understand it by concept... my organization is small > but I want to know if it is large organization or small provider then what > kind of routes do i need in my routing table? > > regards > Devang Patel > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From simon.leinen at switch.ch Fri May 16 09:46:03 2008 From: simon.leinen at switch.ch (Simon Leinen) Date: Fri, 16 May 2008 16:46:03 +0200 Subject: [NANOG] Questions about NETCONF In-Reply-To: <482D6E6C.2030805@psg.com> (Randy Bush's message of "Fri, 16 May 2008 13:22:20 +0200") References: <20080516023256.DE82236C006@mail.venustech.com.cn> <9219BF27-1533-406B-8D7D-95255E6A7774@sackheads.org> <482D6E6C.2030805@psg.com> Message-ID: Randy Bush writes: [in response to John Payne :] >> I've personally been waiting for the data modeling to be >> standardized. Yes, it's great and wonderful to have a consistent >> method of talking to network devices, but I also want a standard >> data model along with it. > does this not imply that all devices would need to be semantically > congruent? if so, is this realistic? Personally I don't think it is. The way that configuration is structured is something that at least some vendors use to differentiate themselves from each other. (Though other vendors make a point of being compatible with some "industry standard CLI".) So if you think that configurations in NETCONF should be similar to the "native" configuration language, that doesn't bode well for industry-wide standardization of a NETCONF configuration data model. It might still be possible to have a common NETCONF data model, but then that would probably be quite different from the (all) "native" configuration languages; much in the same way as SNMP MIBs are (structurally) different from how information is presented at the CLI. Personally I'm not sure that this would be a very useful outcome, because there would necessarily be a large lag between when features are implemented (with a "native" CLI to configure them of course) and when they can be configured through NETCONF. Maybe the best we can shoot for is this: * A common language to describe parts of NETCONF configuration. The newly chartered IETF NETMOD working group[1] is working on this. Vendors can then describe their specific NETCONF data models using this language, and tool writers can use these descriptions to generate code for applications that want to manipulate device configurations. * Common data models for certain well-understood parts of NETCONF configuration. This could include simple "atomic" things such as how to write an IP address or a prefix in (NETCONF) XML, or configuration of standardized protocols such as OSPF, IPFIX etc. The problem is how well will this support migration from vendor-specific configuration to standardized configuration - which, as I said, is always bound to lag far behind. And even if/when an aspect of a configuration model (let's say for OSPF) is standardized, vendors are bound to extend that model to support not-yet-standardized extensions (e.g. sub-second timers, BFD). This will be another challenge to support. (But there are smart people working on this :-) -- Simon. [1] http://www.ietf.org/html.charters/netmod-charter.html From ml at t-b-o-h.net Fri May 16 09:59:15 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Fri, 16 May 2008 10:59:15 -0400 (EDT) Subject: [NANOG] Routing table for BGP In-Reply-To: from "devang patel" at May 16, 2008 09:16:07 AM Message-ID: <200805161459.m4GExGOk046222@vjofn.tucs-beachin-obx-house.com> > > Hi, > > > I would like to know what route should i accept from internet full or > partial? > if Partial then what routes should i accept? and how many route does my > router have if i will go for Partial routing table? > > actually I am trying to understand it by concept... my organization is small > but I want to know if it is large organization or small provider then what > kind of routes do i need in my routing table? > Hi, If its only 1 provider, then probably taking just "default route" is necessary. If you have 2, then it depends on your setup. I prefer to always take full routes from upstreams, as long as there are good communities within that feed. This way I can vary what I accept or don't accept without the need to constantly contact the upstream. If not, then I have to fiddle more on my end, but I always keep the control. I personally run 2 routers (Ok, switches with routing code, so my memory footprint is severely limited) each with a link to a provider. I ask for full routes PLUS default route. Internally, I discard /24's on both links, and pref up the communities like customer and send them over to the other router with the default route. Saves me alot of memory, plus gives me alot of control. Tuc/TBOH From bgreene at senki.org Fri May 16 10:00:52 2008 From: bgreene at senki.org (Barry Raveendran Greene) Date: Fri, 16 May 2008 08:00:52 -0700 Subject: [NANOG] Routing table for BGP In-Reply-To: References: Message-ID: <006501c8b765$a2eba030$6a14a8c0@jnpr.net> The nice thing about NANOG is that we have YEARS of on-line Video training to help you get up to speed. 1. Go to http://www.nanog.org/subjects.html (Index of Talks) 2. Look for materials on BGP. 3. Have fun learning from the best. My suggestion would be to watch last NANOG's BGP Tutorial. The nice thing about this is that you can E-mail the speaker to get clarifications. TO NANOG Community - We should really be pointed these FAQs to the resources/tools we've invested in building. I don't know whose idea it was to VOD everything, but it is an vast untapped store house of knowledge. > -----Original Message----- > From: devang patel [mailto:devangnp at gmail.com] > Sent: Friday, May 16, 2008 7:16 AM > To: nanog at merit.edu > Subject: [NANOG] Routing table for BGP > > Hi, > > > I would like to know what route should i accept from internet > full or partial? > if Partial then what routes should i accept? and how many > route does my router have if i will go for Partial routing table? > > actually I am trying to understand it by concept... my > organization is small but I want to know if it is large > organization or small provider then what kind of routes do i > need in my routing table? > > regards > Devang Patel > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > From kch670 at eecs.northwestern.edu Fri May 16 10:09:50 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Fri, 16 May 2008 10:09:50 -0500 Subject: [NANOG] peering between ASes Message-ID: Hi, here is a quick question. 1. Beside public peering in IXP and private peering between two dedicated ASes, are there any other interconnection models in the current Internet? 2. How does private peering implement, just a router from each AS and a link inbetween? Do they have multi-access in one peering location? I mean one router from an AS peer with two/more routers from another AS? Cheers, From morrowc.lists at gmail.com Fri May 16 10:25:52 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 May 2008 11:25:52 -0400 Subject: [NANOG] Routing table for BGP In-Reply-To: <006501c8b765$a2eba030$6a14a8c0@jnpr.net> References: <006501c8b765$a2eba030$6a14a8c0@jnpr.net> Message-ID: <75cb24520805160825y553de5ddy49332eff8868c601@mail.gmail.com> On Fri, May 16, 2008 at 11:00 AM, Barry Raveendran Greene wrote: > > The nice thing about NANOG is that we have YEARS of on-line Video training > to help you get up to speed. > > 1. Go to http://www.nanog.org/subjects.html (Index of Talks) > > 2. Look for materials on BGP. > > 3. Have fun learning from the best. > > My suggestion would be to watch last NANOG's BGP Tutorial. The nice thing > about this is that you can E-mail the speaker to get clarifications. > > TO NANOG Community - We should really be pointed these FAQs to the > resources/tools we've invested in building. I don't know whose idea it was > to VOD everything, but it is an vast untapped store house of knowledge. I think there is a nanog-wiki that Lynda was poking at last even?? Maybe making sure there's a searchable form thingy there for the VOD catalog? -Chris From joelja at bogus.com Fri May 16 10:31:16 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 May 2008 08:31:16 -0700 Subject: [NANOG] peering between ASes In-Reply-To: References: Message-ID: <482DA8C4.50405@bogus.com> Kai Chen wrote: > Hi, here is a quick question. > 1. Beside public peering in IXP and private peering between two dedicated > ASes, are there any other interconnection models in the current Internet? There is the model where all partcipants peer through agency of 3rd party. That tends to be looked on as an extremely bad idea, but some regulatory environments encourage or enforce that sort of behavior particularly around the monopoly PTT. > 2. How does private peering implement, just a router from each AS and a link > inbetween? Do they have multi-access in one peering location? I mean one > router from an AS peer with two/more routers from another AS? you'll find that the details vary between entities. some bi-lateral relationships are going to require peering in more than one location, require a minimum ammount of redundancy etc. depends on how business critical the relationship is, how much traffic is being exchanged, the sized of the networks involved etc. > Cheers, > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From dsiegel at siegelie.com Fri May 16 10:46:54 2008 From: dsiegel at siegelie.com (Dave Siegel) Date: Fri, 16 May 2008 08:46:54 -0700 Subject: [NANOG] Installation troubles with GlobalCrossing In-Reply-To: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> References: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> Message-ID: <20080516154654.GB68714@siegelie.com> Hi Eric, Sorry you're having troubles. If you send me an email with your customer information or give me a call I'll look into this and get you sorted out. Dave Siegel VP Global IP/Data Services Product Management 716-408-2608 On Thu, May 15, 2008 at 09:38:04AM +0200, Erich Hohermuth reportedly typed: > Dear members, > > I just want to ask if anyone else have major troubles to install new or > upgrade services with Global Crossing ? > > The story: > > Last year on December we ordered two layer2 point to point connections > based on gigabit ethernet connections. The main idea was to directly > connect to the peering point. After waiting 3 months and lots of mails > they get the right hardware in place but now 6 months later we still > don't have a running service, because they just implement something with > tagged interfaces on one the peering point site without asking. > > Regards > Eric > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog -- Dave Siegel http://www.siegelie.com/blog/ have you read my blogs today? http://blogs.globalcrossing.com/dsiegel/ From kch670 at eecs.northwestern.edu Fri May 16 10:52:47 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Fri, 16 May 2008 10:52:47 -0500 Subject: [NANOG] peering between ASes In-Reply-To: <482DA8C4.50405@bogus.com> References: <482DA8C4.50405@bogus.com> Message-ID: 2008/5/16 Joel Jaeggli : > Kai Chen wrote: > >> Hi, here is a quick question. >> 1. Beside public peering in IXP and private peering between two dedicated >> ASes, are there any other interconnection models in the current Internet? >> > > There is the model where all partcipants peer through agency of 3rd party. > That tends to be looked on as an extremely bad idea, but some regulatory > environments encourage or enforce that sort of behavior particularly around > the monopoly PTT. I don't know if the 3rd party you mentioned is the IXP? > > > 2. How does private peering implement, just a router from each AS and a >> link >> inbetween? Do they have multi-access in one peering location? I mean one >> router from an AS peer with two/more routers from another AS? >> > > you'll find that the details vary between entities. some bi-lateral > relationships are going to require peering in more than one location, > require a minimum ammount of redundancy etc. depends on how business > critical the relationship is, how much traffic is being exchanged, the sized > of the networks involved etc. Sure, two ASs may peer with each other at multiple locations, I do want to know in each of these peering location, if there exist multi-access between these two ASes. > > > Cheers, >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> >> > From mormis at caro.net Fri May 16 10:58:20 2008 From: mormis at caro.net (Morgan Miskell) Date: Fri, 16 May 2008 11:58:20 -0400 Subject: [NANOG] Fixed Orbit Message-ID: <1210953500.9324.91.camel@mormis.caro.net> Anyone have any contacts at Fixed Orbit or know anything about their setup? We have one peer that doesn't show in Fixed Orbit's tables. The peer has been online for 5 months so I doubt that the lack of reflection is due to staleness. I've emailed Fixed Orbit but received no response. -- Morgan A. Miskell Carolina Internet 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From randy at psg.com Fri May 16 11:20:14 2008 From: randy at psg.com (Randy Bush) Date: Fri, 16 May 2008 18:20:14 +0200 Subject: [NANOG] df upload Message-ID: <482DB43E.5060306@psg.com> have someone trying to get files to me from mexico d.f. their home site can not survive the uploads (a few tens of megabytes). anyone know someone in df with reliable bandwidth they could share a bit? randy From charles at thewybles.com Fri May 16 11:24:37 2008 From: charles at thewybles.com (charles at thewybles.com) Date: Fri, 16 May 2008 16:24:37 +0000 Subject: [NANOG] BCP Muni WiFI? Message-ID: <704346423-1210955098-cardhu_decombobulator_blackberry.rim.net-1759282302-@bxe164.bisx.prod.on.blackberry> Deepak, Excellent question. I'm currently deploying a test environment for a large scale wifi network. You can see more project info at wiki.socalwifi.org and at socalwifi.blogspot.com. I am documenting everything we are doing and will have a Blog post up soon regarding our kerberos/radius/VPN deployment and how we load test/scale it. i have yet to see any existing information on the back end components specifically related to muni wifi. I would imagine standard documentation/white papers related to scaling a large enterprise wifi network apply. Charles ------Original Message------ From: Deepak Jain To: nanog list ReplyTo: deepak at ai.net Sent: May 15, 2008 2:21 PM Subject: [NANOG] BCP Muni WiFI? Are there any good (published) BCPs for building out Municipal WiFi networks? Particularly in the security/authentication/scaling areas? Thanks in advance, DJ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog Sent via BlackBerry from T-Mobile From jeroen at unfix.org Fri May 16 12:09:48 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 16 May 2008 19:09:48 +0200 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) Message-ID: <482DBFDC.2020303@spaghetti.zurich.ibm.com> Hi folks, As everybody is a big fan of securing their networks against foreign attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that is, not IPv4, they all come from a single IPv6 /13 though, which is what they apparently asked for in the beginning, at least that was the rumor, well they got what they wanted. I've recorded it into GRH as a single /13 though, as that is what it is, and I am not going to bother whois'ing and entering the 14 separate entries there, as that is useless, especially as they will most likely never appear in the global routing tables anyway. Depending on your love for the US, you might want to add special rules in your network to be able to easily detect Cyber Attacks and other such things towards that address space, to be able to better serve your country, may that be the US or any other country for that matter. I am of course wondering why ARIN gave 1 organization 14 separate /22's, even though they are recorded exactly the same, just different prefixes and netnames and it is effectively one huge /13. They could easily have been recorded as that one /13, it is not like eg Canada (no other countries that fall under ARIN now is there) will get a couple of the chunks of remaining space in between there. By assigning them separate /22's, they effectively are stating that it is good to fragment the address space and by having them recorded in whois, also that announcing more specifics from that /13 is just fine. The other fun question is of course what a single organization has to do with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which cover 2.251.799.813.685.248 /64's which is a number that I can't even pronounce. According to Wikipedia the US only has a mere population of 304,080,000, that means that every US citizen can get a 1000+ /48's from their DoD, thus maybe every nuclear warhead and every bullet is getting their own /48 or something to be able to justify for that amount of address space. At least this gives the opportunity to hardcode that block out of hardware if you want to avoid it being ever used by the publicly known part of the US DoD. I wouldn't mind seeing the request form that can justify this amount of address space though, must be a lot of fun. Now back to your regular NANOG schedule.... Greets, Jeroen (who will hide himself in a nice Swiss nuclear bunker till the flames are all gone ;) 1) http://en.wikipedia.org/wiki/United_States which points to: http://www.census.gov/population/www/popclockus.html From pauldotwall at gmail.com Fri May 16 12:23:09 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 16 May 2008 12:23:09 -0500 Subject: [NANOG] BCP Muni WiFI? In-Reply-To: <482CA95A.9070905@ai.net> References: <482CA95A.9070905@ai.net> Message-ID: <620fd17c0805161023n26b94d20j5b4cc47180dfe0ae@mail.gmail.com> On Thu, May 15, 2008 at 4:21 PM, Deepak Jain wrote: > > Are there any good (published) BCPs for building out Municipal WiFi > networks? Particularly in the security/authentication/scaling areas? BCP #58,271,432--which basically states "Don't," comes highly recommended. Instead, investigate your nearest .16e or evdo rev. A reseller. In the case of .16e, most available APN's are built around user and transport/transit abstractions, assuming shared-facilities, virtual providers, etc. The equipment used in both is a far cry from anything 802.11. p. From keith at pando.com Fri May 16 12:36:57 2008 From: keith at pando.com (Keith O'Neill) Date: Fri, 16 May 2008 13:36:57 -0400 Subject: [NANOG] Fixed Orbit In-Reply-To: <1210953500.9324.91.camel@mormis.caro.net> References: <1210953500.9324.91.camel@mormis.caro.net> Message-ID: <482DC639.5040404@pando.com> Morgan, Fixed Orbit is broken, I doubt it has ever worked and I wouldn't use it for anything meaningful. Keith O'Neill Pando Networks Morgan Miskell wrote: > Anyone have any contacts at Fixed Orbit or know anything about their > setup? We have one peer that doesn't show in Fixed Orbit's tables. > > The peer has been online for 5 months so I doubt that the lack of > reflection is due to staleness. > > I've emailed Fixed Orbit but received no response. > From dhetzel at gmail.com Fri May 16 12:58:58 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 16 May 2008 13:58:58 -0400 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) In-Reply-To: <482DBFDC.2020303@spaghetti.zurich.ibm.com> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> Message-ID: <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> Perhaps it is an attempt to make their address space so sparsely populated that it's close to impossible to find a host without knowing it's address in the first place? On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar wrote: > Hi folks, > > As everybody is a big fan of securing their networks against foreign > attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that > is, not IPv4, they all come from a single IPv6 /13 though, which is what > they apparently asked for in the beginning, at least that was the rumor, > well they got what they wanted. > > I've recorded it into GRH as a single /13 though, as that is what it is, > and I am not going to bother whois'ing and entering the 14 separate > entries there, as that is useless, especially as they will most likely > never appear in the global routing tables anyway. > > Depending on your love for the US, you might want to add special rules > in your network to be able to easily detect Cyber Attacks and other such > things towards that address space, to be able to better serve your > country, may that be the US or any other country for that matter. > > I am of course wondering why ARIN gave 1 organization 14 separate /22's, > even though they are recorded exactly the same, just different prefixes > and netnames and it is effectively one huge /13. They could easily have > been recorded as that one /13, it is not like eg Canada (no other > countries that fall under ARIN now is there) will get a couple of the > chunks of remaining space in between there. By assigning them separate > /22's, they effectively are stating that it is good to fragment the > address space and by having them recorded in whois, also that announcing > more specifics from that /13 is just fine. > > The other fun question is of course what a single organization has to do > with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which > cover 2.251.799.813.685.248 /64's which is a number that I can't even > pronounce. According to Wikipedia the US only has a mere population of > 304,080,000, that means that every US citizen can get a 1000+ /48's from > their DoD, thus maybe every nuclear warhead and every bullet is getting > their own /48 or something to be able to justify for that amount of > address space. At least this gives the opportunity to hardcode that > block out of hardware if you want to avoid it being ever used by the > publicly known part of the US DoD. I wouldn't mind seeing the request > form that can justify this amount of address space though, must be a lot > of fun. > > Now back to your regular NANOG schedule.... > > Greets, > Jeroen > > (who will hide himself in a nice Swiss nuclear bunker till the flames > are all gone ;) > > 1) http://en.wikipedia.org/wiki/United_States > which points to: http://www.census.gov/population/www/popclockus.html > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From cdl at asgaard.org Fri May 16 13:03:39 2008 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Fri, 16 May 2008 11:03:39 -0700 Subject: [NANOG] BCP Muni WiFI? In-Reply-To: <620fd17c0805161023n26b94d20j5b4cc47180dfe0ae@mail.gmail.com> References: <482CA95A.9070905@ai.net> <620fd17c0805161023n26b94d20j5b4cc47180dfe0ae@mail.gmail.com> Message-ID: <770B760D-D0A5-4DDA-BD65-59581E640468@asgaard.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Interesting comment Paul. However, 16e and evdo are a "bit" heavy with infrastructure to support mobility. Before giving that answer, you may want to ask Deepak if he NEEDS mobility.... Chris On 16 May 2008, at 10.23, Paul Wall wrote: > On Thu, May 15, 2008 at 4:21 PM, Deepak Jain wrote: >> >> Are there any good (published) BCPs for building out Municipal WiFi >> networks? Particularly in the security/authentication/scaling areas? > > BCP #58,271,432--which basically states "Don't," comes highly > recommended. > > Instead, investigate your nearest .16e or evdo rev. A reseller. In the > case of .16e, most available APN's are built around user and > transport/transit abstractions, assuming shared-facilities, virtual > providers, etc. The equipment used in both is a far cry from anything > 802.11. > > p. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJILcx7AAoJEGmx2Mt/+Iw/20UIAJjNOQ7JSbE8/iqGbuFZPEVX AvQ/eRPHT6BhLXNSg5WZiL4aQcDeLhkMYwhpJTMkslHg5hveQHN/pUQB9pkMeqCZ jffRbiKDzypaDf8q/Rx1vORO/bnQ4R27AfeKDc75Z07YewdBa9PKZz2EgsjVHQmp FNDq9dVDWAI+scK3BFNge+QNeXatYUf0gP+LnRmNaPu+KZBThjD+Wmd6FWlfmuRa GxvTOrESrbhRxrnF128B5RXa/GBohduiql1jrU0phb6w2a/NJbd+a4yvHANZpBHk fwU3BrZKLixRtOOM3uA4ZPgliTUO/lD4tpW8SEWnvluhRe1tTIrmgf4qjxit5gA= =z83n -----END PGP SIGNATURE----- From cscora at apnic.net Fri May 16 13:07:26 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 May 2008 04:07:26 +1000 (EST) Subject: [NANOG] Weekly Routing Table Report Message-ID: <200805161807.m4GI7Q3t023824@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 May, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 255996 Prefixes after maximum aggregation: 127048 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 124142 Total ASes present in the Internet Routing Table: 28207 Prefixes per ASN: 9.08 Origin-only ASes present in the Internet Routing Table: 24602 Origin ASes announcing only one prefix: 11444 Transit ASes present in the Internet Routing Table: 3605 Transit-only ASes present in the Internet Routing Table: 80 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (39375) 13 Prefixes from unregistered ASNs in the Routing Table: 25568 Unregistered ASNs in the Routing Table: 1888 Number of 32-bit ASNs allocated by the RIRs: 47 Prefixes from 32-bit ASNs in the Routing Table: 10 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 787 Number of addresses announced to Internet: 1852593056 Equivalent to 110 /8s, 108 /16s and 83 /24s Percentage of available address space announced: 50.0 Percentage of allocated address space announced: 61.4 Percentage of available address space allocated: 81.4 Percentage of address space in use by end-sites: 71.9 Total number of prefixes smaller than registry allocations: 123367 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 43195 Total APNIC prefixes after maximum aggregation: 13464 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 55719 Unique aggregates announced from the APNIC address blocks: 23792 APNIC Region origin ASes present in the Internet Routing Table: 1944 APNIC Prefixes per ASN: 28.66 APNIC Region origin ASes announcing only one prefix: 547 APNIC Region transit ASes present in the Internet Routing Table: 354 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 349020128 Equivalent to 20 /8s, 205 /16s and 159 /24s Percentage of available APNIC address space announced: 80.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 107932 Total ARIN prefixes after maximum aggregation: 59258 ARIN Deaggregation factor: 1.82 Prefixes being announced from the ARIN address blocks: 86932 Unique aggregates announced from the ARIN address blocks: 34225 ARIN Region origin ASes present in the Internet Routing Table: 11816 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4615 ARIN Region transit ASes present in the Internet Routing Table: 1043 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 358062720 Equivalent to 21 /8s, 87 /16s and 154 /24s Percentage of available ARIN address space announced: 73.6 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, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 55366 Total RIPE prefixes after maximum aggregation: 33712 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 50562 Unique aggregates announced from the RIPE address blocks: 33804 RIPE Region origin ASes present in the Internet Routing Table: 11339 RIPE Prefixes per ASN: 4.46 RIPE Region origin ASes announcing only one prefix: 5926 RIPE Region transit ASes present in the Internet Routing Table: 1711 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 357182592 Equivalent to 21 /8s, 74 /16s and 44 /24s Percentage of available RIPE address space announced: 81.9 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, 38912-39935 40960-45055, 47104 - 48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20096 Total LACNIC prefixes after maximum aggregation: 5006 LACNIC Deaggregation factor: 4.01 Prefixes being announced from the LACNIC address blocks: 18551 Unique aggregates announced from the LACNIC address blocks: 10046 LACNIC Region origin ASes present in the Internet Routing Table: 902 LACNIC Prefixes per ASN: 20.57 LACNIC Region origin ASes announcing only one prefix: 279 LACNIC Region transit ASes present in the Internet Routing Table: 156 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 16 Number of LACNIC addresses announced to Internet: 51284736 Equivalent to 3 /8s, 14 /16s and 139 /24s Percentage of available LACNIC address space announced: 50.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3839 Total AfriNIC prefixes after maximum aggregation: 1178 AfriNIC Deaggregation factor: 3.26 Prefixes being announced from the AfriNIC address blocks: 4201 Unique aggregates announced from the AfriNIC address blocks: 1862 AfriNIC Region origin ASes present in the Internet Routing Table: 241 AfriNIC Prefixes per ASN: 17.43 AfriNIC Region origin ASes announcing only one prefix: 77 AfriNIC Region transit ASes present in the Internet Routing Table: 48 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12207616 Equivalent to 0 /8s, 186 /16s and 70 /24s Percentage of available AfriNIC address space announced: 36.4 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 4755 1639 387 91 Videsh Sanchar Nigam Ltd. Aut 9498 1170 550 61 BHARTI BT INTERNET LTD. 9583 1150 140 15 Sify Limited 17488 1064 70 76 Hathway IP Over Cable Interne 4134 855 12661 319 CHINANET-BACKBONE 4766 848 6006 343 Korea Telecom (KIX) 18101 679 149 51 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 545 1918 419 Telstra Pty Ltd 4808 521 837 132 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4323 1425 1030 379 Time Warner Telecom 2386 1403 643 874 AT&T Data Communications Serv 7018 1395 5975 996 AT&T WorldNet Services 11492 1218 148 13 Cable One 7011 1086 318 617 Citizens Utilities 18566 1044 296 10 Covad Communications 6197 1028 630 542 BellSouth Network Solutions, 1785 1017 510 105 AppliedTheory Corporation 174 975 6836 804 Cogent Communications 22773 949 2394 62 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 9198 428 74 9 Kazakhtelecom Data Network Ad 3292 410 1789 370 TDC Tele Danmark 8452 356 188 7 TEDATA 3301 338 1458 306 TeliaNet Sweden 3320 317 7044 266 Deutsche Telekom AG 8866 298 77 22 Bulgarian Telecommunication C 5462 292 666 26 Telewest Broadband 8551 282 269 37 Bezeq International 3215 279 2686 90 France Telecom Transpac 680 274 2045 264 DFN-IP service G-WiN Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1219 2464 229 UniNet S.A. de C.V. 11830 601 299 9 Instituto Costarricense de El 22047 566 270 14 VTR PUNTO NET S.A. 7303 460 225 66 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 419 85 46 ENTEL CHILE S.A. 11172 412 117 67 Servicios Alestra S.A de C.V 10620 390 99 69 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 330 36 31 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 471 61 28 LINKdotNET AS number 3741 286 853 223 The Internet Solution 20858 222 34 3 EgyNet 5713 174 575 108 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 2018 140 141 70 Tertiary Education Network 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 116 13 8 Ci Telecom Autonomous system 33776 99 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3714 3045 168 bellsouth.net, inc. 23577 1644 34 702 Korea Telecom (ATM-MPLS) 4755 1639 387 91 Videsh Sanchar Nigam Ltd. Aut 4323 1425 1030 379 Time Warner Telecom 2386 1403 643 874 AT&T Data Communications Serv 7018 1395 5975 996 AT&T WorldNet Services 8151 1219 2464 229 UniNet S.A. de C.V. 11492 1218 148 13 Cable One 9498 1170 550 61 BHARTI BT INTERNET LTD. 9583 1150 140 15 Sify Limited Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4755 1639 1548 Videsh Sanchar Nigam Ltd. Aut 11492 1218 1205 Cable One 9583 1150 1135 Sify Limited 9498 1170 1109 BHARTI BT INTERNET LTD. 4323 1425 1046 Time Warner Telecom 18566 1044 1034 Covad Communications 8151 1219 990 UniNet S.A. de C.V. 17488 1064 988 Hathway IP Over Cable Interne 17676 1016 951 Softbank BB Corp. 23577 1644 942 Korea Telecom (ATM-MPLS) Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 14780 UNALLOCATED 4.79.181.0/24 10310 Yahoo! 12180 UNALLOCATED 4.79.248.0/24 1239 Sprint 12180 UNALLOCATED 8.10.16.0/24 3549 Global Crossing 12180 UNALLOCATED 8.10.58.0/23 3549 Global Crossing 14779 UNALLOCATED 8.12.144.0/24 10310 Yahoo! 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA 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:9 /10:16 /11:42 /12:140 /13:281 /14:512 /15:1007 /16:9925 /17:4363 /18:7295 /19:15434 /20:17896 /21:17297 /22:21736 /23:22825 /24:134902 /25:782 /26:927 /27:490 /28:80 /29:9 /30:1 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 11492 1201 1218 Cable One 6389 1144 3714 bellsouth.net, inc. 2386 1103 1403 AT&T Data Communications Serv 18566 1025 1044 Covad Communications 9583 988 1150 Sify Limited 4755 985 1639 Videsh Sanchar Nigam Ltd. Aut 7011 969 1086 Citizens Utilities 6478 944 945 AT&T Worldnet Services 17488 877 1064 Hathway IP Over Cable Interne 9498 844 1170 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:108 12:2045 13:1 15:20 16:3 17:5 18:13 20:35 24:1069 25:1 32:61 33:3 38:421 40:93 41:673 44:2 47:12 52:3 55:3 56:3 57:23 58:510 59:461 60:442 61:981 62:1104 63:1959 64:3397 65:2427 66:3654 67:1187 68:657 69:2220 70:605 71:121 72:1671 73:5 74:965 75:226 76:307 77:666 78:612 79:151 80:899 81:865 82:618 83:389 84:559 85:1009 86:411 87:658 88:339 89:1301 90:11 91:1231 92:274 93:447 96:32 97:14 98:154 99:3 114:4 116:642 117:327 118:134 119:395 120:39 121:536 122:760 123:348 124:849 125:1133 128:314 129:201 130:132 131:405 132:66 133:9 134:180 135:33 136:221 137:116 138:145 139:64 140:492 141:95 142:390 143:280 144:349 145:50 146:363 147:152 148:493 149:183 150:131 151:183 152:141 153:134 154:10 155:265 156:174 157:270 158:163 159:221 160:255 161:111 162:215 163:199 164:522 165:446 166:304 167:320 168:611 169:131 170:426 171:28 172:22 189:166 190:1996 192:5772 193:4105 194:3260 195:2433 196:1064 198:3729 199:3246 200:5671 201:1461 202:7560 203:7825 204:4000 205:2074 206:2394 207:2746 208:3337 209:3432 210:2535 211:1041 212:1385 213:1654 214:458 215:49 216:4356 217:1204 218:355 219:411 220:1075 221:470 222:308 End of report From cdl at asgaard.org Fri May 16 13:15:17 2008 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Fri, 16 May 2008 11:15:17 -0700 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) In-Reply-To: <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> Message-ID: <5BDFB474-4B72-44E7-B94E-E233AEA07ECC@asgaard.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Not to address the political issues here (which are deep, wide, and WAY too much of a black-hole), remember, that the DoD is not a single organization from a networking perspective. There are a number of different organizations within that structure, all of which may, or may not, want to announce separately, maintain their own external links, etc. Those boundaries can be on a service level (USAF vs USN), geographical level (Southern Command vs. Northern Command), etc. My guess is that they don't want to be tied to only announcing a single /13. Each of those organizations is bigger than a lot of service providers out there... As for why so many addresses - consider a networked ship (where everything has an address), soldier (each soldier having one or more addresses), battlefield sensors, etc. With stateless autoconf, that can add up fairly quickly (depending on network topology). Lastly, If you honestly think that any entity (government or non- government) would launch an offensive cyber-attack from their own address space... never mind.... Chris On 16 May 2008, at 10.58, Dorn Hetzel wrote: > Perhaps it is an attempt to make their address space so sparsely > populated > that it's close to impossible to find a host without knowing it's > address in > the first place? > > On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar > wrote: > >> Hi folks, >> >> As everybody is a big fan of securing their networks against foreign >> attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 >> that >> is, not IPv4, they all come from a single IPv6 /13 though, which is >> what >> they apparently asked for in the beginning, at least that was the >> rumor, >> well they got what they wanted. >> >> I've recorded it into GRH as a single /13 though, as that is what >> it is, >> and I am not going to bother whois'ing and entering the 14 separate >> entries there, as that is useless, especially as they will most >> likely >> never appear in the global routing tables anyway. >> >> Depending on your love for the US, you might want to add special >> rules >> in your network to be able to easily detect Cyber Attacks and other >> such >> things towards that address space, to be able to better serve your >> country, may that be the US or any other country for that matter. >> >> I am of course wondering why ARIN gave 1 organization 14 separate / >> 22's, >> even though they are recorded exactly the same, just different >> prefixes >> and netnames and it is effectively one huge /13. They could easily >> have >> been recorded as that one /13, it is not like eg Canada (no other >> countries that fall under ARIN now is there) will get a couple of the >> chunks of remaining space in between there. By assigning them >> separate >> /22's, they effectively are stating that it is good to fragment the >> address space and by having them recorded in whois, also that >> announcing >> more specifics from that /13 is just fine. >> >> The other fun question is of course what a single organization has >> to do >> with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which >> cover 2.251.799.813.685.248 /64's which is a number that I can't even >> pronounce. According to Wikipedia the US only has a mere population >> of >> 304,080,000, that means that every US citizen can get a 1000+ /48's >> from >> their DoD, thus maybe every nuclear warhead and every bullet is >> getting >> their own /48 or something to be able to justify for that amount of >> address space. At least this gives the opportunity to hardcode that >> block out of hardware if you want to avoid it being ever used by the >> publicly known part of the US DoD. I wouldn't mind seeing the request >> form that can justify this amount of address space though, must be >> a lot >> of fun. >> >> Now back to your regular NANOG schedule.... >> >> Greets, >> Jeroen >> >> (who will hide himself in a nice Swiss nuclear bunker till the flames >> are all gone ;) >> >> 1) http://en.wikipedia.org/wiki/United_States >> which points to: http://www.census.gov/population/www/popclockus.html >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJILc81AAoJEGmx2Mt/+Iw/0HEH/1HZmv1nsNRpz1sqjMJwy0kr O68VCagg7tNfRLq/ErY8lOkxcVsAp0R6urZN8kJwt59MBcd1Yat8BxqayfXcbrx4 m/y361FKjEt8HpBBcS5EiHftjojD2aWczlinJuGL97koDw390ozuZhXLvui27JsE Zh2LHdLrya2ZKMkfL2/mLc7J1C0CiuMvflDVCURG8c+aG17O+aH8csTbxHzStoH4 U0lbxH6hvOHVtQdaHa4JKtZD6zdUIn4quZnwnyPO7mop9005h/W4GRIqB4fUQMGB Jk+8bo5ArTxIlceunhLhbUhMAphF7RaABNKBxsUrgc4nqQVVCV8fOCbyvOr6rTA= =z0uG -----END PGP SIGNATURE----- From robert at ufl.edu Fri May 16 13:15:35 2008 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 16 May 2008 14:15:35 -0400 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but nottotally consecutive) In-Reply-To: <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> Message-ID: <028c01c8b780$d6a60300$72d4e30a@Robert> OH, You mean like putting a sniper in a bunch of trees. They know that tactic well. :) Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 -----Original Message----- From: Dorn Hetzel [mailto:dhetzel at gmail.com] Sent: Friday, May 16, 2008 1:59 PM To: Jeroen Massar Cc: NANOG list Subject: Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but nottotally consecutive) Perhaps it is an attempt to make their address space so sparsely populated that it's close to impossible to find a host without knowing it's address in the first place? On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar wrote: > Hi folks, > > As everybody is a big fan of securing their networks against foreign > attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that > is, not IPv4, they all come from a single IPv6 /13 though, which is what > they apparently asked for in the beginning, at least that was the rumor, > well they got what they wanted. > > I've recorded it into GRH as a single /13 though, as that is what it is, > and I am not going to bother whois'ing and entering the 14 separate > entries there, as that is useless, especially as they will most likely > never appear in the global routing tables anyway. > > Depending on your love for the US, you might want to add special rules > in your network to be able to easily detect Cyber Attacks and other such > things towards that address space, to be able to better serve your > country, may that be the US or any other country for that matter. > > I am of course wondering why ARIN gave 1 organization 14 separate /22's, > even though they are recorded exactly the same, just different prefixes > and netnames and it is effectively one huge /13. They could easily have > been recorded as that one /13, it is not like eg Canada (no other > countries that fall under ARIN now is there) will get a couple of the > chunks of remaining space in between there. By assigning them separate > /22's, they effectively are stating that it is good to fragment the > address space and by having them recorded in whois, also that announcing > more specifics from that /13 is just fine. > > The other fun question is of course what a single organization has to do > with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which > cover 2.251.799.813.685.248 /64's which is a number that I can't even > pronounce. According to Wikipedia the US only has a mere population of > 304,080,000, that means that every US citizen can get a 1000+ /48's from > their DoD, thus maybe every nuclear warhead and every bullet is getting > their own /48 or something to be able to justify for that amount of > address space. At least this gives the opportunity to hardcode that > block out of hardware if you want to avoid it being ever used by the > publicly known part of the US DoD. I wouldn't mind seeing the request > form that can justify this amount of address space though, must be a lot > of fun. > > Now back to your regular NANOG schedule.... > > Greets, > Jeroen > > (who will hide himself in a nice Swiss nuclear bunker till the flames > are all gone ;) > > 1) http://en.wikipedia.org/wiki/United_States > which points to: http://www.census.gov/population/www/popclockus.html > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From tme at multicasttech.com Fri May 16 13:27:11 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 16 May 2008 14:27:11 -0400 Subject: [NANOG] BCP Muni WiFI? In-Reply-To: <704346423-1210955098-cardhu_decombobulator_blackberry.rim.net-1759282302-@bxe164.bisx.prod.on.blackberry> References: <704346423-1210955098-cardhu_decombobulator_blackberry.rim.net-1759282302-@bxe164.bisx.prod.on.blackberry> Message-ID: <68F7E865-861F-493B-9FA2-E977DB11673F@multicasttech.com> I thought that I had seen an "open source muni wifi cookbook" somewhere, but I haven't been able to find it. This might be useful to drill down into. Regards Marshall On May 16, 2008, at 12:24 PM, charles at thewybles.com wrote: > Deepak, > > > Excellent question. I'm currently deploying a test environment for a > large scale wifi network. > > You can see more project info at wiki.socalwifi.org and at > socalwifi.blogspot.com. > > I am documenting everything we are doing and will have a Blog post > up soon regarding our kerberos/radius/VPN deployment and how we load > test/scale it. > > i have yet to see any existing information on the back end > components specifically related to muni wifi. > > I would imagine standard documentation/white papers related to > scaling a large enterprise wifi network apply. > > > Charles > > > ------Original Message------ > From: Deepak Jain > To: nanog list > ReplyTo: deepak at ai.net > Sent: May 15, 2008 2:21 PM > Subject: [NANOG] BCP Muni WiFI? > > > Are there any good (published) BCPs for building out Municipal WiFi > networks? Particularly in the security/authentication/scaling areas? > > Thanks in advance, > > DJ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > > > Sent via BlackBerry from T-Mobile > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From warren at kumari.net Fri May 16 13:41:43 2008 From: warren at kumari.net (Warren Kumari) Date: Fri, 16 May 2008 14:41:43 -0400 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but nottotally consecutive) In-Reply-To: <028c01c8b780$d6a60300$72d4e30a@Robert> References: <028c01c8b780$d6a60300$72d4e30a@Robert> Message-ID: On May 16, 2008, at 2:15 PM, Robert D. Scott wrote: > OH, You mean like putting a sniper in a bunch of trees. They know that > tactic well. :) Yup -- http://www.youtube.com/watch?v=ltmMJntSfQI W > > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Receptionist > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 > > > -----Original Message----- > From: Dorn Hetzel [mailto:dhetzel at gmail.com] > Sent: Friday, May 16, 2008 1:59 PM > To: Jeroen Massar > Cc: NANOG list > Subject: Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but > nottotally consecutive) > > > Perhaps it is an attempt to make their address space so sparsely > populated > that it's close to impossible to find a host without knowing it's > address in > the first place? > > On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar > wrote: > >> Hi folks, >> >> As everybody is a big fan of securing their networks against foreign >> attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 >> that >> is, not IPv4, they all come from a single IPv6 /13 though, which is >> what >> they apparently asked for in the beginning, at least that was the >> rumor, >> well they got what they wanted. >> >> I've recorded it into GRH as a single /13 though, as that is what >> it is, >> and I am not going to bother whois'ing and entering the 14 separate >> entries there, as that is useless, especially as they will most >> likely >> never appear in the global routing tables anyway. >> >> Depending on your love for the US, you might want to add special >> rules >> in your network to be able to easily detect Cyber Attacks and other >> such >> things towards that address space, to be able to better serve your >> country, may that be the US or any other country for that matter. >> >> I am of course wondering why ARIN gave 1 organization 14 separate / >> 22's, >> even though they are recorded exactly the same, just different >> prefixes >> and netnames and it is effectively one huge /13. They could easily >> have >> been recorded as that one /13, it is not like eg Canada (no other >> countries that fall under ARIN now is there) will get a couple of the >> chunks of remaining space in between there. By assigning them >> separate >> /22's, they effectively are stating that it is good to fragment the >> address space and by having them recorded in whois, also that >> announcing >> more specifics from that /13 is just fine. >> >> The other fun question is of course what a single organization has >> to do >> with (2^(48-13)=) 34.359.738.368, yes indeed, 34 billion /48's which >> cover 2.251.799.813.685.248 /64's which is a number that I can't even >> pronounce. According to Wikipedia the US only has a mere population >> of >> 304,080,000, that means that every US citizen can get a 1000+ /48's >> from >> their DoD, thus maybe every nuclear warhead and every bullet is >> getting >> their own /48 or something to be able to justify for that amount of >> address space. At least this gives the opportunity to hardcode that >> block out of hardware if you want to avoid it being ever used by the >> publicly known part of the US DoD. I wouldn't mind seeing the request >> form that can justify this amount of address space though, must be >> a lot >> of fun. >> >> Now back to your regular NANOG schedule.... >> >> Greets, >> Jeroen >> >> (who will hide himself in a nice Swiss nuclear bunker till the flames >> are all gone ;) >> >> 1) http://en.wikipedia.org/wiki/United_States >> which points to: http://www.census.gov/population/www/popclockus.html >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Hope is not a strategy. -- Ben Treynor, Google From morrowc.lists at gmail.com Fri May 16 14:22:54 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 May 2008 15:22:54 -0400 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) In-Reply-To: <482DBFDC.2020303@spaghetti.zurich.ibm.com> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> Message-ID: <75cb24520805161222x62e18ff9q96193aebaa9cfc77@mail.gmail.com> Please keep the political rhetoric off-list, thanks. On Fri, May 16, 2008 at 1:09 PM, Jeroen Massar wrote: > Hi folks, > > As everybody is a big fan of securing their networks against foreign > attacks, be aware that the US DoD has been assigned 14 /22's, IPv6 that > is, not IPv4, they all come from a single IPv6 /13 though, which is what > they apparently asked for in the beginning, at least that was the rumor, > well they got what they wanted. > So, someone else pointed out that the DoD isn't one org, really. There are several groups/orgs under DoD, there are several groups nested under each of those groups, and depending upon the network architecture/topology used it's fully possible that one route announcement isn't practical for this Org. What I think we should worry about is a larger portion of that Org with a large enough part of one of the /22's doing something silly like: "redistribute connected" ... (which they could, of course, have done with any/all of their /8's -> /16's in ipv4 as well...) -Chris From karnaugh at karnaugh.za.net Fri May 16 14:51:46 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 16 May 2008 21:51:46 +0200 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) In-Reply-To: <5BDFB474-4B72-44E7-B94E-E233AEA07ECC@asgaard.org> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> <5BDFB474-4B72-44E7-B94E-E233AEA07ECC@asgaard.org> Message-ID: <482DE5D2.6060609@karnaugh.za.net> On 16/05/2008 20:15 Christopher LILJENSTOLPE wrote: > My guess is that they don't want to be tied to only announcing a > single /13. Each of those organizations is bigger than a lot of > service providers out there... Since when do you have to announce only the same size prefix as your allocation? -- Colin Alston ~ http://www.karnaugh.za.net/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From joelja at bogus.com Fri May 16 14:55:25 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 May 2008 12:55:25 -0700 Subject: [NANOG] BCP Muni WiFI? In-Reply-To: <482CA95A.9070905@ai.net> References: <482CA95A.9070905@ai.net> Message-ID: <482DE6AD.9060003@bogus.com> Deepak Jain wrote: > Are there any good (published) BCPs for building out Municipal WiFi > networks? Particularly in the security/authentication/scaling areas? http://wndw.net/ > Thanks in advance, > > DJ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From deepak at ai.net Fri May 16 17:01:53 2008 From: deepak at ai.net (Deepak Jain) Date: Fri, 16 May 2008 18:01:53 -0400 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totallyconsecutive) In-Reply-To: <2ee691ff0805161409o5c07e3d9v1657f64c36500266@mail.gmail.com> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> <482DF71C.5010508@ai.net> <2ee691ff0805161409o5c07e3d9v1657f64c36500266@mail.gmail.com> Message-ID: <482E0451.9020502@ai.net> :_) Another concept that might be useful with *that* much address space is the concept of modeling your ENEMIES' networks inside of unique space (persistently, forever). I'm sure we aren't far from the days where boxen will be set up to emulate the interaction between hundreds of other nodes, latency, jitter and packet loss included. It might be a fun project to be asked to pursue. There really isn't a platform in current address space to do that (once you add persistently and multiple enemies) to the equation. :) Deepak Dorn Hetzel wrote: > Brings a whole new meaning to packet fragmentation :) > > On Fri, May 16, 2008 at 5:05 PM, Deepak Jain > wrote: > > > > Perhaps next each round of ammo will have its own IPv6 address. > > > > Perhaps every round will (or anti-personnel) mine will be stamped with > its V6 address so you can track its shrapnel for all time? IPv6 ensures > uniqueness, there is no requirement for universal, perpetual > connectivity. > > DJ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > From pauldotwall at gmail.com Fri May 16 17:12:12 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 16 May 2008 18:12:12 -0400 Subject: [NANOG] Hibernia Atlantic Outage Message-ID: <620fd17c0805161512r545beaf5ja1bdec03290d9de8@mail.gmail.com> I'm hearing reports of a Hibernia outage on one of their fiber paths, with downtime approaching a week. Does anybody know what's going on there, and when they expect to have service restored? Which provider(s) are impacted? Was their diverse path impacted as well (as with prior Hibernia outages), or just this path? Paul From j at arpa.com Fri May 16 18:51:34 2008 From: j at arpa.com (jamie) Date: Fri, 16 May 2008 18:51:34 -0500 Subject: [NANOG] AIM security Message-ID: <6ff30abd0805161651w36280d64m28eefbb6a87a75aa@mail.gmail.com> #include An AIM security engineer/admin is requested. Please contact off-list. (*) I'll settle for an AOL security type with a buddy who works in AIM. It's all good at this point. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri May 16 19:50:06 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 17 May 2008 10:20:06 +0930 Subject: [NANOG] msnalerts@microsoft.com invalid now (Was Re: Microsoft.com PMTUD black hole?) In-Reply-To: <48220209.8000407@fsr.com> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> Message-ID: <20080517102006.06b91967.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Wed, 07 May 2008 12:24:57 -0700 Nathan Anderson/FSR wrote: > Here is a brief update on the situation: > > Team. They, in turn, forwarded my message on to > msnalerts at microsoft.com, which generated a ticket # for me and is, as I > understand it, the e-mail address I was looking for in the first place > (leads to their network/system people). > Doesn't look like it unfortunately. I've just tried to use this email address to advise them of some routing issues we're having with new APNIC IP ranges (114/8 specifically), and I've just got: -- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: msnalerts at microsoft.com SMTP error from remote mail server after RCPT TO:: host mailb.microsoft.com [131.107.115.215]: 550 5.1.1 User unknown -- Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From jra at baylink.com Fri May 16 19:51:18 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 16 May 2008 20:51:18 -0400 Subject: [NANOG] BCP Muni WiFI? In-Reply-To: <770B760D-D0A5-4DDA-BD65-59581E640468@asgaard.org> References: <482CA95A.9070905@ai.net> <620fd17c0805161023n26b94d20j5b4cc47180dfe0ae@mail.gmail.com> <770B760D-D0A5-4DDA-BD65-59581E640468@asgaard.org> Message-ID: <20080517005118.GA1147@cgi.jachomes.com> On Fri, May 16, 2008 at 11:03:39AM -0700, Christopher LILJENSTOLPE wrote: > Interesting comment Paul. However, 16e and evdo are a "bit" heavy > with infrastructure to support mobility. Before giving that answer, > you may want to ask Deepak if he NEEDS mobility.... He needs mobility. If he doesn't know that, it means he hasn't done his due diligence properly. Cheers, -- jra > On 16 May 2008, at 10.23, Paul Wall wrote: > > > On Thu, May 15, 2008 at 4:21 PM, Deepak Jain wrote: > >> > >> Are there any good (published) BCPs for building out Municipal WiFi > >> networks? Particularly in the security/authentication/scaling areas? > > > > BCP #58,271,432--which basically states "Don't," comes highly > > recommended. > > > > Instead, investigate your nearest .16e or evdo rev. A reseller. In the > > case of .16e, most available APN's are built around user and > > transport/transit abstractions, assuming shared-facilities, virtual > > providers, etc. The equipment used in both is a far cry from anything > > 802.11. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From damin at nacs.net Fri May 16 20:02:39 2008 From: damin at nacs.net (Gregory Boehnlein) Date: Fri, 16 May 2008 21:02:39 -0400 Subject: [NANOG] RackMount DC to AC Inverters Message-ID: <00e401c8b7b9$b3db0fd0$1b912f70$@net> Hello all, I have some equipment going into a Telco Co which only offers battery backup on it's DC power plant. Most of the equipment that is already moving into that facility is AC powered, so I am looking for advice on rackmount DC inverters. Looking for something that can accommodate inverting enough power to load a 30 AMP 110 circuit, preferably something that has N+1 redundancy.. I'm not finding a lot of options on Google, so I figured that I would ask here... From ge at linuxbox.org Fri May 16 20:06:29 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 16 May 2008 20:06:29 -0500 (CDT) Subject: [NANOG] IOS rootkits Message-ID: At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS rootkit. skip below for the news item itself. We've had discussions on this before, here and elsewhere. I've been heavily attacked on the subject of considering router security as an issue when compared to routing security. I have a lot to say about this, looking into this threat for a few years now and having engaged different organizations within Cisco on the subject in the past. Due to what I refer to as an "NDA of honour" I will just relay the following until it is "officially" public, then consider what should be made public, including: 1. Current defense startegies possible with Cisco gear 2. Third party defense strategies (yes, they now exist) 2. Cisco response (no names or exact quotes will likely be given) 3. A bet on when such a rootkit would be public, and who won it (participants are.. "relevant people"). From: http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html "A security researcher has developed malicious rootkit software for Cisco's routers, a development that has placed increasing scrutiny on the routers that carry the majority of the Internet's traffic. Sebastian Muniz, a researcher with Core Security Technologies, developed the software, which he will unveil on May 22 at the EuSecWest conference in London. " Gadi Evron. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri May 16 20:12:05 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 17 May 2008 10:42:05 +0930 Subject: [NANOG] msnalert@microsoft.com valid (was Re: msnalerts@microsoft.com invalid now) In-Reply-To: <20080517102006.06b91967.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <200805062253.m46MrwS1025720@mail.r-bonomi.com> <4821020A.7050003@fsr.com> <20080507134507.GA23142@gsp.org> <48220209.8000407@fsr.com> <20080517102006.06b91967.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <20080517104205.17d3f135.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Hi, On Sat, 17 May 2008 10:20:06 +0930 Mark Smith wrote: > On Wed, 07 May 2008 12:24:57 -0700 > Nathan Anderson/FSR wrote: > > -- > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > msnalerts at microsoft.com > SMTP error from remote mail server after RCPT TO:: > host mailb.microsoft.com [131.107.115.215]: 550 5.1.1 User unknown > -- Somebody from Microsoft kindly contacted me off list, the email address is msnalert at microsoft.com - note the removed "s". Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From pauldotwall at gmail.com Fri May 16 20:13:46 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 16 May 2008 21:13:46 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: References: Message-ID: <620fd17c0805161813h7af6118bgeb097dd139d73d7d@mail.gmail.com> Gadi, Please try to keep the self-promotion to a minimum, and come back when you have meaningful data to share with operators. Examples would include a list of affected platforms and code revisions, as well as preventative measures. Thank you, Paul On Fri, May 16, 2008 at 9:06 PM, Gadi Evron wrote: > At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS > rootkit. skip below for the news item itself. > > We've had discussions on this before, here and elsewhere. I've been > heavily attacked on the subject of considering router security as an issue > when compared to routing security. > > I have a lot to say about this, looking into this threat for a > few years now and having engaged different organizations within Cisco on > the subject in the past. Due to what I refer to as an "NDA of > honour" I will just relay the following until it is "officially" public, > then consider what should be made public, including: > > 1. Current defense startegies possible with Cisco gear > 2. Third party defense strategies (yes, they now exist) > 2. Cisco response (no names or exact quotes will likely be given) > 3. A bet on when such a rootkit would be public, and who won it > (participants are.. "relevant people"). > > From: > http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html > > "A security researcher has developed malicious rootkit software for > Cisco's routers, a development that has placed increasing scrutiny on the > routers that carry the majority of the Internet's traffic. > > Sebastian Muniz, a researcher with Core Security Technologies, developed > the software, which he will unveil on May 22 at the EuSecWest conference > in London. " > > Gadi Evron. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From ge at linuxbox.org Fri May 16 20:19:20 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 16 May 2008 20:19:20 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <620fd17c0805161813h7af6118bgeb097dd139d73d7d@mail.gmail.com> References: <620fd17c0805161813h7af6118bgeb097dd139d73d7d@mail.gmail.com> Message-ID: On Fri, 16 May 2008, Paul Wall wrote: > Gadi, > > Please try to keep the self-promotion to a minimum, and come back when > you have meaningful data to share with operators. > > Examples would include a list of affected platforms and code > revisions, as well as preventative measures. Name on the door, money to be sent via paypal. I will sign my playgirl cover for 5 USD each. This is operational, and it is about me saying "na na na na na, na na na na na na" to a discussion from two years ago. I have every intention to gloat, but I will keep it to a minimum. Yes? Gadi. > On Fri, May 16, 2008 at 9:06 PM, Gadi Evron wrote: >> At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS >> rootkit. skip below for the news item itself. >> >> We've had discussions on this before, here and elsewhere. I've been >> heavily attacked on the subject of considering router security as an issue >> when compared to routing security. >> >> I have a lot to say about this, looking into this threat for a >> few years now and having engaged different organizations within Cisco on >> the subject in the past. Due to what I refer to as an "NDA of >> honour" I will just relay the following until it is "officially" public, >> then consider what should be made public, including: >> >> 1. Current defense startegies possible with Cisco gear >> 2. Third party defense strategies (yes, they now exist) >> 2. Cisco response (no names or exact quotes will likely be given) >> 3. A bet on when such a rootkit would be public, and who won it >> (participants are.. "relevant people"). >> >> From: >> http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html >> >> "A security researcher has developed malicious rootkit software for >> Cisco's routers, a development that has placed increasing scrutiny on the >> routers that carry the majority of the Internet's traffic. >> >> Sebastian Muniz, a researcher with Core Security Technologies, developed >> the software, which he will unveil on May 22 at the EuSecWest conference >> in London. " >> >> Gadi Evron. >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> > From nanog at daork.net Fri May 16 22:07:20 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 17 May 2008 15:07:20 +1200 Subject: [NANOG] peering between ASes In-Reply-To: References: <482DA8C4.50405@bogus.com> Message-ID: <23BEDABB-2767-4B1C-8024-59074FFB4E11@daork.net> On 17/05/2008, at 3:52 AM, Kai Chen wrote: > Sure, two ASs may peer with each other at multiple locations, I do > want to > know in each of these peering location, if there exist multi-access > between > these two ASes. If you're looking for some rules about how this must work, you won't find them - all these things are optional and dynamic. Multiple accesses between two ASes at a single physical location is possible, yes. It's probably a good idea in most cases - whether it happens or not is usually a matter of whether the cost (both capital and opex) is worth it, I imagine. RE. your original question (2) - yes a single router in each AS and a link between them is the simplest. Add more routers and more links as required to meet capacity and resiliency requirements, where cost permits. -- Nathan Ward From dr at kyx.net Fri May 16 22:29:07 2008 From: dr at kyx.net (Dragos Ruiu) Date: Fri, 16 May 2008 20:29:07 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: References: Message-ID: <3260A110-46FE-42E6-BB2B-1287476EF3C4@kyx.net> The question this presentation begs for me... is how many of the folks on this list do integrity checking on their routers? You can no longer say this isn't necessary :-). I know FX and a few others are working on toolsets for this... I'll probably have other comments after I see the presentation. This development has all sort of implications for binary signing requirements, etc... cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques London, U.K. May 21/22 - 2008 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From fergdawg at netzero.net Fri May 16 23:00:00 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sat, 17 May 2008 04:00:00 GMT Subject: [NANOG] IOS rootkits Message-ID: <20080516.210000.6055.0@webmail15.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Dragos Ruiu wrote: >The question this presentation begs for me... is how many of the folks >on this list do integrity checking on their routers? > >You can no longer say this isn't necessary :-). > >I know FX and a few others are working on toolsets for this... > >I'll probably have other comments after I see the presentation. >This development has all sort of implications for binary signing >requirements, etc... Yep -- I'd say just wait for the presentation (assuming Cisco doesn't go after this guy like they did Mike Lynn) and then determine the level of seriousness. It would appear to have people very nervous, however. Including Cisco. It will be interesting to see what develops. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFILlgzq1pz9mNUZTMRAtmoAKC3bQLSqJzFDZklPMfdnkBX7fyccwCeN5mc K1QQ9JnTqLmSfcNuj5JZ6Z8= =W5F0 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From tvarriale at comcast.net Fri May 16 22:57:34 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 16 May 2008 22:57:34 -0500 Subject: [NANOG] IOS rootkits References: Message-ID: <002201c8b7d2$2380adf0$f211a8c0@flamwsugsmul5v> IIRC, the toolkit(s) can only be installed once having priv 15 on the device. If this is the case, the practicality of this is...well...not that significant. I do think the significance is that we are getting closer and closer to treating infrastructure devices as end stations with respect to susceptibility. Looking forward to seeing all the details. Gadi, have fun :) tv ----- Original Message ----- From: "Gadi Evron" To: Sent: Friday, May 16, 2008 8:06 PM Subject: [NANOG] IOS rootkits > At the upcoming EusecWest Sebastian Muniz will apparently unveil an IOS > rootkit. skip below for the news item itself. > > We've had discussions on this before, here and elsewhere. I've been > heavily attacked on the subject of considering router security as an issue > when compared to routing security. > > I have a lot to say about this, looking into this threat for a > few years now and having engaged different organizations within Cisco on > the subject in the past. Due to what I refer to as an "NDA of > honour" I will just relay the following until it is "officially" public, > then consider what should be made public, including: > > 1. Current defense startegies possible with Cisco gear > 2. Third party defense strategies (yes, they now exist) > 2. Cisco response (no names or exact quotes will likely be given) > 3. A bet on when such a rootkit would be public, and who won it > (participants are.. "relevant people"). > > From: > http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html > > "A security researcher has developed malicious rootkit software for > Cisco's routers, a development that has placed increasing scrutiny on the > routers that carry the majority of the Internet's traffic. > > Sebastian Muniz, a researcher with Core Security Technologies, developed > the software, which he will unveil on May 22 at the EuSecWest conference > in London. " > > Gadi Evron. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From mmc at internode.com.au Sat May 17 00:05:17 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 14:35:17 +0930 Subject: [NANOG] peering between ASes In-Reply-To: References: <482DA8C4.50405@bogus.com> Message-ID: <482E678D.6030206@internode.com.au> Kai Chen wrote: > >> There is the model where all partcipants peer through agency of 3rd party. >> That tends to be looked on as an extremely bad idea, but some regulatory >> environments encourage or enforce that sort of behavior particularly around >> the monopoly PTT. >> > > > I don't know if the 3rd party you mentioned is the IXP? > Some IXPs have MLPA (MultiLateral Peering Agreements) where some or all of the participants agree to connect to a route server (usually with it's own AS) and exchange routes this way. It's reasonably common around AsiaPac - all the peering fabrics in Australia are MLPA for example, but I can think of optional examples in the USA (eg. Any2) that have it as an option or places like HKIX which have an MPLA which is mandatory for Hong Kong prefixes. This doesn't stop you doing bilateral as well across the same fabrics. MLPA works well in certain environments, especially where the major IP transit providers in a country won't peer, but rivalries tend to mean that a neutral (or fairly neutral) 3rd party can provide the routing part (this is pretty much what happened in Australia). It's convienient for content providers - they can "hook up" to one route server and often pickup half of the people on the exchange without having to spend ages negotiating with small networks who often don't have the technical know how or don't have the BGP experience, or indeed the smaller networks themselves as they can connect to an exchange and at least guarantee enough data to justify doing so. It gets more complex as some networks then become bigger and become transit providers and don't like customers sending routes to them via a peering fabric etc. Which is why, with a much more diverse range of networks and no one player dominating people the transit game (eg. in the USA, Western Europe) that MLPA isn't common. Some MLPAs give you some control over routing (eg. don't send my prefixes to ASxxxx), but a lot don't. Regards, Matthew From nanog at daork.net Sat May 17 00:18:29 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 17 May 2008 17:18:29 +1200 Subject: [NANOG] peering between ASes In-Reply-To: <482E678D.6030206@internode.com.au> References: <482DA8C4.50405@bogus.com> <482E678D.6030206@internode.com.au> Message-ID: <38BA44BA-B201-4C3C-B1A9-7CBB514C8C71@daork.net> On 17/05/2008, at 5:05 PM, Matthew Moyle-Croft wrote: > Some MLPAs give you some control over routing (eg. don't send my > prefixes to ASxxxx), but a lot don't. If you really need to, you can get a similar effect by using ASPATH poisoning; just prepend your AS paths with the ASes you don't want those prefixes hitting. Similar, not identical, so may not work for you how you want. Googling around finds some explanation of it here: http://ispcolumn.isoc.org/2005-08/as1.html Nothing really about how it works in a MLPA IXP though. -- Nathan Ward From mmc at internode.com.au Sat May 17 00:30:16 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 15:00:16 +0930 Subject: [NANOG] peering between ASes In-Reply-To: <38BA44BA-B201-4C3C-B1A9-7CBB514C8C71@daork.net> References: <482DA8C4.50405@bogus.com> <482E678D.6030206@internode.com.au> <38BA44BA-B201-4C3C-B1A9-7CBB514C8C71@daork.net> Message-ID: <482E6D68.9040204@internode.com.au> > If you really need to, you can get a similar effect by using ASPATH > poisoning; just prepend your AS paths with the ASes you don't want > those prefixes hitting. > > .. > > Nothing really about how it works in a MLPA IXP though. > It'd work, but it's a pretty evil thing to do and it's a fairly easy to get around surely (neighbor 1.1.1.1 allowas-in on IOS). MMC From nanog at daork.net Sat May 17 00:36:20 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 17 May 2008 17:36:20 +1200 Subject: [NANOG] peering between ASes In-Reply-To: <482E6D68.9040204@internode.com.au> References: <482DA8C4.50405@bogus.com> <482E678D.6030206@internode.com.au> <38BA44BA-B201-4C3C-B1A9-7CBB514C8C71@daork.net> <482E6D68.9040204@internode.com.au> Message-ID: On 17/05/2008, at 5:30 PM, Matthew Moyle-Croft wrote: >> If you really need to, you can get a similar effect by using >> ASPATH poisoning; just prepend your AS paths with the ASes you >> don't want those prefixes hitting. >> >> .. >> Nothing really about how it works in a MLPA IXP though. >> > It'd work, but it's a pretty evil thing to do and it's a fairly easy > to get around surely (neighbor 1.1.1.1 allowas-in on IOS). "If you really need to". Geoff's thing also says "controversial". If the foreign AS really wants to send you routes that way, they can do it regardless of how you stop your advertisements being accepted by/ reaching them. We're hardly talking high security here. ip route 1.1.1.1 works a treat. -- Nathan Ward From mmc at internode.com.au Sat May 17 00:53:02 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 15:23:02 +0930 Subject: [NANOG] peering between ASes In-Reply-To: References: <482DA8C4.50405@bogus.com> <482E678D.6030206@internode.com.au> <38BA44BA-B201-4C3C-B1A9-7CBB514C8C71@daork.net> <482E6D68.9040204@internode.com.au> Message-ID: <482E72BE.70001@internode.com.au> Nathan Ward wrote: > If the foreign AS really wants to send you routes that way, they can > do it regardless of how you stop your advertisements being accepted by/ > reaching them. We're hardly talking high security here. > > ip route 1.1.1.1 works a treat. > I'm not quite sure of your point Nathan. That'd stop connectivity which isn't usually the point - especially if the issue is point (2) below. MLPAs are disliked for two main reasons that I've been able to discern. (1) Lack of control Because of the lack of direct relationships with the other networks you can get some fairly odd routing behaviours which gives suboptimal performance when you meet at multiple MLPAs in a theatre - leading to difficulty in doing traffic engineering. From traffic flows, to wierdness caused by people advertising prefixes inconsistently to transit and peering and blaming IOS bugs for it . (2) Transit customers using an MLPA to "not pay" for traffic to your network A fair point - but, if they weren't a customer then you might be paying to get their traffic or they would be sending it that way anyway. MMC From pauldotwall at gmail.com Sat May 17 01:57:08 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Sat, 17 May 2008 02:57:08 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: <20080516.210000.6055.0@webmail15.vgs.untd.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> Message-ID: <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> What if some good comes from this "root kit"? For instance, what if it lets us fix things like DOM on non-Cisco XENPAKs and SFPs? Or lets us un-cripple our 6500 chassis to run the code we want? Of course, given the messenger, I'm sure it's just hype to help bolster Gadi's security practice, and will prove to be no big deal. Paul From mmc at internode.com.au Sat May 17 02:17:02 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 16:47:02 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> Message-ID: <482E866E.8000000@internode.com.au> Paul Wall wrote: > What if some good comes from this "root kit"? > I'm sure it'll be good for a number of security providers to hawk their wares. If the way of running this isn't out in the wild and it's actually dangerous then a pox on anyone who releases it, especially to gain publicity at the expensive of network operators sleep and well being. May you never find a reliable route ever again. MMC From simon at slimey.org Sat May 17 02:34:52 2008 From: simon at slimey.org (Simon Lockhart) Date: Sat, 17 May 2008 08:34:52 +0100 Subject: [NANOG] IOS rootkits In-Reply-To: <482E866E.8000000@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: <20080517073451.GI10920@virtual.bogons.net> On Sat May 17, 2008 at 04:47:02PM +0930, Matthew Moyle-Croft wrote: > Paul Wall wrote: > > What if some good comes from this "root kit"? > > > I'm sure it'll be good for a number of security providers to hawk their > wares. How long before we need to install Anti-virus / Anti-root-kit software on our routers? Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From mmc at internode.com.au Sat May 17 02:50:51 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 17:20:51 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: <20080517073451.GI10920@virtual.bogons.net> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> Message-ID: <482E8E5B.2090508@internode.com.au> Simon Lockhart wrote: > > How long before we need to install Anti-virus / Anti-root-kit software on > our routers? > Nah - we'll just replace them all with Macs. They don't need anti-virus ... :-) MMC > Simon > From nanog at daork.net Sat May 17 03:13:12 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 17 May 2008 20:13:12 +1200 Subject: [NANOG] peering between ASes In-Reply-To: <482E72BE.70001@internode.com.au> References: <482DA8C4.50405@bogus.com> <482E678D.6030206@internode.com.au> <38BA44BA-B201-4C3C-B1A9-7CBB514C8C71@daork.net> <482E6D68.9040204@internode.com.au> <482E72BE.70001@internode.com.au> Message-ID: On 17/05/2008, at 5:53 PM, Matthew Moyle-Croft wrote: > Nathan Ward wrote: >> If the foreign AS really wants to send you routes that way, they >> can do it regardless of how you stop your advertisements being >> accepted by/ reaching them. We're hardly talking high security here. >> >> ip route 1.1.1.1 works a treat. >> > I'm not quite sure of your point Nathan. That'd stop connectivity > which isn't usually the point - especially if the issue is point (2) > below. If a foreign AS wants to work around things put in place by you/others so they don't get your prefixes (be it ASPATH poisoning, route filtering by the MLPA route-server operator, etc.) they can do so easily by putting a static route in to their equipment. My point is that none of these techniques are bulletproof. I think I meant to say "packets" where I said "routes" where you quoted me above, also, that ip route blah was something that the foreign AS would stuff in to their router. I hope that's a bit more clear. > MLPAs are disliked for two main reasons that I've been able to > discern. I'm not debating for/against MLPAs, that doesn't really go anywhere productive. I'm giving info that some people might find useful if they've got a network condition they need to work around with a dirty hack. -- Nathan Ward From cdl at asgaard.org Sat May 17 04:31:31 2008 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Sat, 17 May 2008 02:31:31 -0700 Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) In-Reply-To: <482DE5D2.6060609@karnaugh.za.net> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> <5BDFB474-4B72-44E7-B94E-E233AEA07ECC@asgaard.org> <482DE5D2.6060609@karnaugh.za.net> Message-ID: <20E454BE-D589-4F7C-9A78-75F705218C34@asgaard.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You certainly don't have to. However, as other folks have indicated here, that is the way that some folks read it. My guess is that this was purely for network topology and administrative reasons. Chris On 16 May 2008, at 12.51, Colin Alston wrote: > On 16/05/2008 20:15 Christopher LILJENSTOLPE wrote: >> My guess is that they don't want to be tied to only announcing a >> single /13. Each of those organizations is bigger than a lot of >> service providers out there... > > Since when do you have to announce only the same size prefix as your > allocation? > > -- > Colin Alston ~ http://www.karnaugh.za.net/ > "To the world you may be one person, to one person you may be the > world" ~ Rachel Ann Nunes. > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJILqXzAAoJEGmx2Mt/+Iw/UxkH/25h7CPcpr50ontu5y/sYFav dXron7uvLtCEFPyT/mEemYn31hekjsd37xy6bLMeAaqwo6/Eh66nZxKLhKLgtR+q f+PBAUj5znQ58/NITvJzIq3fFN3A1ll3x96cqOVSmiqa1DZo6ChquX1CW2sIRBWw aVQaFatrVnvlGx7cDR6IFiwertrEftcK/7POm9wgljYUCfS9pZhv3hy66yNUdEe9 4MWIB6K9lK36WBHz+ZnKLRbmw3QALFAbTWwzVC9qc0EFY7Yr3b3BZuba0UGyin0d HcL0cupzJ3UutINwVjUlmujbwaYot8pyVcr3FrQ9YbZ2mGLDvvMTVjipuWtqmOU= =wh07 -----END PGP SIGNATURE----- From ge at linuxbox.org Sat May 17 04:38:11 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 04:38:11 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> Message-ID: On Sat, 17 May 2008, Paul Wall wrote: > What if some good comes from this "root kit"? > > For instance, what if it lets us fix things like DOM on non-Cisco > XENPAKs and SFPs? Or lets us un-cripple our 6500 chassis to run the > code we want? > > Of course, given the messenger, I'm sure it's just hype to help > bolster Gadi's security practice, and will prove to be no big deal. A signed issue is now 25 bucks FOR YOU, Mister. > Paul > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From ops.lists at gmail.com Sat May 17 05:12:02 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 17 May 2008 15:42:02 +0530 Subject: [NANOG] IOS rootkits In-Reply-To: <482E866E.8000000@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: On Sat, May 17, 2008 at 12:47 PM, Matthew Moyle-Croft wrote: > If the way of running this isn't out in the wild and it's actually > dangerous then a pox on anyone who releases it, especially to gain > publicity at the expensive of network operators sleep and well being. > May you never find a reliable route ever again. This needs fixing. It doesnt need publicity at security conferences till after cisco gets presented this stuff first and asked to release an emergency patch. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From Jon.Kibler at aset.com Sat May 17 05:23:45 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Sat, 17 May 2008 06:23:45 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: <482EB231.10607@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Suresh Ramasubramanian wrote: > On Sat, May 17, 2008 at 12:47 PM, Matthew Moyle-Croft > wrote: >> If the way of running this isn't out in the wild and it's actually >> dangerous then a pox on anyone who releases it, especially to gain >> publicity at the expensive of network operators sleep and well being. >> May you never find a reliable route ever again. > > This needs fixing. It doesnt need publicity at security conferences > till after cisco gets presented this stuff first and asked to release > an emergency patch. > > --srs According to Cisco, there is nothing to patch: http://www.cisco.com/warp/public/707/cisco-sr-20080516-rootkits.shtml Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgusjEACgkQUVxQRc85QlO5kACfaZtij86HqIH540xeH+Uh/NyI ccQAnjiRCMFnLxk/Ew9EuUKDzdLN6HQZ =BCdw -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From xploitable at gmail.com Sat May 17 06:08:30 2008 From: xploitable at gmail.com (n3td3v) Date: Sat, 17 May 2008 12:08:30 +0100 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: <4b6ee9310805170408x6fa206c9uc4e3943d80560e3b@mail.gmail.com> On Sat, May 17, 2008 at 11:12 AM, Suresh Ramasubramanian wrote: > On Sat, May 17, 2008 at 12:47 PM, Matthew Moyle-Croft > wrote: >> If the way of running this isn't out in the wild and it's actually >> dangerous then a pox on anyone who releases it, especially to gain >> publicity at the expensive of network operators sleep and well being. >> May you never find a reliable route ever again. > > This needs fixing. It doesnt need publicity at security conferences > till after cisco gets presented this stuff first and asked to release > an emergency patch. Agreed, You've got to remember though that a security conference is a commercial venture, it makes business sense for this to be publically announced at this security conference. I think security conferences have become something that sucks as its all become money making oriented and the people who run these things don't really have security in mind, just the ? signs reflecting on their eye balls. > --srs > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > All the best, n3td3v From ge at linuxbox.org Sat May 17 06:10:23 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 06:10:23 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: On Sat, 17 May 2008, Suresh Ramasubramanian wrote: > On Sat, May 17, 2008 at 12:47 PM, Matthew Moyle-Croft > wrote: >> If the way of running this isn't out in the wild and it's actually >> dangerous then a pox on anyone who releases it, especially to gain >> publicity at the expensive of network operators sleep and well being. >> May you never find a reliable route ever again. > > This needs fixing. It doesnt need publicity at security conferences > till after cisco gets presented this stuff first and asked to release > an emergency patch. I'd like to discuss: 1. What is it we are talking about. 2. Why it is serious. 3. What we can do to defend ourselves. I'll be brief as this is not a briefing. You are absolutely right on the sentiment, but miss the point on this particular issue. I agree with you that in most cases, software vulnerability issues should be resolved with the vendor first, especially where critical infrastructure is involved. This is not only about exploiting a vulnerability. In this case it the the very realization that these issues exist (namely being able to run Trojan horses on IOS systems AND/or hiding their presense) is what we are discussing. Router security as far as most operators are concerned includes the following issues: software version (now update), configuration, ACL and authentication (password) security. I include subjects such as BGP MD5 in configuration. These issues are indeed important and very neglected, after all, how many "0wned" routers can be found that respond to cisco/cisco? The main difference here is that we are now at a cross-roads where the face of router security changes, It is that the realization that: 1. A router is not an hardware device, it is an embedded device with a software operating system. As such it is as vulnerable to malware (wide-spreading--worm, or targeted--Trojan horse) as a Windows machine is.) 2. There are no real tools today for us to be able to detect such malicious activity on a router, listing processes doesn't cut it. 3. What tools exist, which I hope to secure permission to discuss later on, are only from third parties. This is not about fear mongering, it's about facing reality how about how Cisco handles security threats to their customer base before such an issue becomes a public concern--namely, ignoring its very existence, at least as far as the public can see. The point is, I don't want to rely on third parties for my router's security, even if I trust the said third party. Gadi. From ge at linuxbox.org Sat May 17 06:41:45 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 06:41:45 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <20080517073451.GI10920@virtual.bogons.net> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> Message-ID: On Sat, 17 May 2008, Simon Lockhart wrote: > On Sat May 17, 2008 at 04:47:02PM +0930, Matthew Moyle-Croft wrote: >> Paul Wall wrote: >>> What if some good comes from this "root kit"? >>> >> I'm sure it'll be good for a number of security providers to hawk their >> wares. > > How long before we need to install Anti-virus / Anti-root-kit software on > our routers? Very astute. Sadly, this is already being done by a few people I know. No AV vendor has such a tool to offer you, so don't bother asking them. The question is, can you afford not to? The answer may be yes, you can afford for your router to be a spying machine for the enemy/competitor, and you can afford for it to be a bot participating in DDoS (as currently, for example, many *nix routers are known to be). The question is who can't afford for these things to happen... Gadi. > Simon > -- > Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * > Director | * Domain & Web Hosting * Internet Consultancy * > Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From mmc at internode.com.au Sat May 17 06:54:59 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 21:24:59 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> Message-ID: <482EC793.7010800@internode.com.au> > The question is who can't afford for these things to happen... > > Gadi. > > I can't help but feel you're pushing fear to further some other interest here Gadi. Do you actually have live examples of this or able to demonstrate it or are you just theorising about it all? MMC From ge at linuxbox.org Sat May 17 07:03:58 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 07:03:58 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <482EC793.7010800@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> Message-ID: On Sat, 17 May 2008, Matthew Moyle-Croft wrote: > >> The question is who can't afford for these things to happen... >> >> Gadi. >> >> > I can't help but feel you're pushing fear to further some other interest here > Gadi. It is alright to have feelings. Gadi. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat May 17 07:11:29 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 17 May 2008 21:41:29 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> Message-ID: <20080517214129.4cab7558.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sat, 17 May 2008 07:03:58 -0500 (CDT) Gadi Evron wrote: > On Sat, 17 May 2008, Matthew Moyle-Croft wrote: > > > >> The question is who can't afford for these things to happen... > >> > >> Gadi. > >> > >> > > I can't help but feel you're pushing fear to further some other interest here > > Gadi. > > It is alright to have feelings. > The rational thing to do is to move beyond fear. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From mmc at internode.com.au Sat May 17 07:10:55 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 21:40:55 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> Message-ID: <482ECB4F.9010807@internode.com.au> > > It is alright to have feelings. > > Gadi. So I ask again, expecting nothing but another flippant answer: Do you actually have live examples of this or able to demonstrate it or are you just theorising about it all? MMC From mmc at internode.com.au Sat May 17 08:16:48 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 17 May 2008 22:46:48 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: <73053.1211028185@turing-police.cc.vt.edu> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <73053.1211028185@turing-police.cc.vt.edu> Message-ID: <482EDAC0.5000801@internode.com.au> > I'd love to know what magical mystical protection your routers have that will > enable them to avoid the same fate as every other device and operating system > has. There's only one thing up there that doesn't have known rootkits > in the wild. Yet. > The question isn't IF routers have security vunerabilities, but whether Gadi has an example he can demonstrate now of installing a root kit on an IOS router NOW or not. MMC From ml at t-b-o-h.net Sat May 17 08:36:57 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Sat, 17 May 2008 09:36:57 -0400 (EDT) Subject: [NANOG] IOS rootkits In-Reply-To: <482EDAC0.5000801@internode.com.au> Message-ID: <200805171336.m4HDavLI037185@himinbjorg.tucs-beachin-obx-house.com> > > > > I'd love to know what magical mystical protection your routers have that will > > enable them to avoid the same fate as every other device and operating system > > has. There's only one thing up there that doesn't have known rootkits > > in the wild. Yet. > > > The question isn't IF routers have security vunerabilities, but whether > Gadi has an example he can demonstrate now of installing a root kit on > an IOS router NOW or not. > Rootkit for 2500, 3000 and 4000...... Load this onto your router and you'll have root and much more. http://tinyurl.com/29duah Tuc/TBOH From ge at linuxbox.org Sat May 17 08:41:13 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 08:41:13 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <482ECB4F.9010807@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <482ECB4F.9010807@internode.com.au> Message-ID: On Sat, 17 May 2008, Matthew Moyle-Croft wrote: > >> >> It is alright to have feelings. >> >> Gadi. > So I ask again, expecting nothing but another flippant answer: I will honour you flame-bait, but only once. > Do you actually have live examples of this or able to demonstrate it or are > you just theorising about it all? Your question is irrelevant to our discussion, as I obviously base myself on the first email in this thread discussing the poc (?) about to be released, and my own statements from that first email in which I mention I will not discuss my own experience on the subject of rootkit risks and solutions until said poc (?) is released due to matters of honour. > > MMC > > From ge at linuxbox.org Sat May 17 08:45:06 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 08:45:06 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <482EDAC0.5000801@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <73053.1211028185@turing-police.cc.vt.edu> <482EDAC0.5000801@internode.com.au> Message-ID: On Sat, 17 May 2008, Matthew Moyle-Croft wrote: > >> I'd love to know what magical mystical protection your routers have that >> will >> enable them to avoid the same fate as every other device and operating >> system >> has. There's only one thing up there that doesn't have known rootkits >> in the wild. Yet. >> > The question isn't IF routers have security vunerabilities Nope, the question is not about if routers have security vulnerabilities. The question is how operators and organizations can defend their routers against rootkits, and cisco's practices. > > MMC > From jackson.tim at gmail.com Sat May 17 09:13:57 2008 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 17 May 2008 09:13:57 -0500 Subject: [NANOG] RackMount DC to AC Inverters In-Reply-To: <00e401c8b7b9$b3db0fd0$1b912f70$@net> References: <00e401c8b7b9$b3db0fd0$1b912f70$@net> Message-ID: <4407932e0805170713h356a8300x83ff9e65d2984f75@mail.gmail.com> Check out Unipower. They make a stackable N-1 setup that does 30+ amps (redundantly) of 110 in 2U. Just remember to wire up their sync cable if you parallel 2 or more shelves. -- Tim On 5/16/08, Gregory Boehnlein wrote: > Hello all, > I have some equipment going into a Telco Co which only offers > battery backup on it's DC power plant. Most of the equipment that is already > moving into that facility is AC powered, so I am looking for advice on > rackmount DC inverters. Looking for something that can accommodate inverting > enough power to load a 30 AMP 110 circuit, preferably something that has N+1 > redundancy.. I'm not finding a lot of options on Google, so I figured that I > would ask here... > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Sent from Gmail for mobile | mobile.google.com From travis+ml-nanog at subspacefield.org Sat May 17 09:34:19 2008 From: travis+ml-nanog at subspacefield.org (travis+ml-nanog at subspacefield.org) Date: Sat, 17 May 2008 09:34:19 -0500 Subject: [NANOG] IOS rootkits In-Reply-To: <482E866E.8000000@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: <20080517143419.GQ5193@subspacefield.org> On Sat, May 17, 2008 at 04:47:02PM +0930, Matthew Moyle-Croft wrote: > I'm sure it'll be good for a number of security providers to hawk their > wares. > > If the way of running this isn't out in the wild and it's actually > dangerous then a pox on anyone who releases it, especially to gain > publicity at the expensive of network operators sleep and well being. > May you never find a reliable route ever again. I personally like Gadi's work, but not as much as I like getting my packets to their destination. I personally don't quite understand why netops keep buying proprietary, closed technology for routers, but I'm not and have never been a netop so I'm sure there's good reasons. To me it seems that if you need reliable router hardware, you can buy that from a vendor, but in theory I don't see why the software for routers couldn't be much more open. When I can, I reflash my WAPs with DD-WRT, because at least then I understand the system (and you can't secure what you don't understand), but I am not saying that's much of a comparison. So, speaking of hawking wares... ;-) Since I see some disclosure discussions brewing here, so I thought I'd mention that I have a free online book on security, and I'm trying to capture all the arguments about disclosure policies so that they don't ever have to be rehashed. Instead, we can just point someone to it, and move on. Here's the section on disclosure: http://www.subspacefield.org/security/security_concepts.html#tth_sEc25.1 I'm numbering them for your convenience, so that if for some reason you want to state a particular argument, you can compress the conversation by simply giving its index. ;-) HHOS, Travis -- Crypto ergo sum. https://www.subspacefield.org/~travis/ If you are a spammer, please email john at subspacefield.org to get blacklisted. From zitibake at yahoo.com Sat May 17 09:41:30 2008 From: zitibake at yahoo.com (Zitibake) Date: Sat, 17 May 2008 07:41:30 -0700 (PDT) Subject: [NANOG] financing IRU purchase Message-ID: <471248.65084.qm@web45302.mail.sp1.yahoo.com> I'm looking for financing sources to help with the purchase of an IRU within my metro area. I'd be interested in hearing suggestions of how to describe the asset to potential lenders; or in hearing of lenders that are already familiar with IRUs as "attachable assets". From joelja at bogus.com Sat May 17 09:48:23 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 17 May 2008 07:48:23 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <73053.1211028185@turing-police.cc.vt.edu> <482EDAC0.5000801@internode.com.au> Message-ID: <482EF037.1050205@bogus.com> Gadi Evron wrote: >> The question isn't IF routers have security vunerabilities > > Nope, the question is not about if routers have security vulnerabilities. > The question is how operators and organizations can defend their routers > against rootkits, and cisco's practices. > The existence proof of a root kit does little if anything to change how one protects and secures the control plane. From jcurran at mail.com Sat May 17 10:24:57 2008 From: jcurran at mail.com (John Curran) Date: Sat, 17 May 2008 11:24:57 -0400 Subject: [NANOG] financing IRU purchase In-Reply-To: <471248.65084.qm@web45302.mail.sp1.yahoo.com> References: <471248.65084.qm@web45302.mail.sp1.yahoo.com> Message-ID: At 7:41 AM -0700 5/17/08, Zitibake wrote: >I'm looking for financing sources to help with the purchase of an IRU within my metro area. I'd be interested in hearing suggestions of how to describe the asset to potential lenders; or in hearing of lenders that are already familiar with IRUs as "attachable assets". Financing an IRU poses challenges to lenders, since it's a fixed location asset which they need to remarket in case of business failure. Heavy equipment (e.g. routers, generators, chillers) can be moved to where the demand is, but a building or IRU must have value inherent to the location. Lenders can tap an entire field of people experienced in providing market demand & valuation for buildings, but don't have the same available to assist in determining the inherent value of an IRU in a given location. I'm not saying it's not possible, just providing some perspective into the lenders side of the equation. If you've got an existing operating business, you might have better luck with financing for business expansion and using the proceeds for the IRU and related expansion needs. Business valuation for existing firms with customers and revenue is much lower risk from the lenders perspective. In any case, I believe you'll have better chances of success with finance firms familiar with the telecomm / ISP / CLEC market; contact me offlist with the general region that you're in, and I'll send some typical folks for that area. /John p.s. Also note that right now is not a great time in the financial markets, and you may need to modulate or time your plans accordingly. From fw at deneb.enyo.de Sat May 17 16:03:12 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 17 May 2008 23:03:12 +0200 Subject: [NANOG] IOS rootkits In-Reply-To: <482EF037.1050205@bogus.com> (Joel Jaeggli's message of "Sat, 17 May 2008 07:48:23 -0700") References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <73053.1211028185@turing-police.cc.vt.edu> <482EDAC0.5000801@internode.com.au> <482EF037.1050205@bogus.com> Message-ID: <87fxsgk5in.fsf@mid.deneb.enyo.de> * Joel Jaeggli: > The existence proof of a root kit does little if anything to change how > one protects and secures the control plane. | Network administrators are not able to observe Lawful Intercept is | enabled. No Lawful Intercept program messages or error messages are ever | displayed on the console. This is a Sony-style rootkit, but it certainly demonstrate that the concept is feasible (surprise). From michael.dillon at bt.com Sat May 17 16:45:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 17 May 2008 22:45:10 +0100 Subject: [NANOG] IOS rootkits In-Reply-To: <482EDAC0.5000801@internode.com.au> References: <20080516.210000.6055.0@webmail15.vgs.untd.com><620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com><482E866E.8000000@internode.com.au><20080517073451.GI10920@virtual.bogons.net><482EC793.7010800@internode.com.au><73053.1211028185@turing-police.cc.vt.edu> <482EDAC0.5000801@internode.com.au> Message-ID: > The question isn't IF routers have security vunerabilities, > but whether Gadi has an example he can demonstrate now of > installing a root kit on an IOS router NOW or not. That's not really the question. In fact, there are two questions. First, are routers really embedded devices running a software operating system? Secondly who can you trust in regards to security of your routers. On the first question, I don't think anyone will argue that routers are not capable of being compromised by software. Some may argue that compromising the software from the public Internet is virtually impossible and statistically unlikely, but most organizations now realize that hard shell security is a fantasy. The real danger is an insider who has enable on the router and who takes money to install a trojan, or the reseller who sells you a router with trojans already installed. Let's face it, if the NSA now believes there is a serious risk of counterfeit hardware that has been modified to contain hardware trojans, then the much easier to achieve software trojans should be a greater risk, and therefore worthy of attention. But the second question is the more interesting one in the context of NANOG. Can we trust Gadi? Can we trust the people who pop up and try to smear Gadi in some way? I haven't a clear answer here except to say that Gadi is a well-known person whose biases and possible motives (consultancy work) are well known. Same thing could be said about Cisco or Microsoft and this may make Gadi (or Cisco) more trustable about some things and less trustable about others. But everybody on this list deals with certainties like this every day. It's the people who pop up and smear Gadi that I really wonder about. There seems to be no good reason for this, unless possibly they are blackhats of some sort. I remember a few years ago when William Leibzon posted about his work which eventually became completewhois.com and several blackhats popped up and tried to smear him. So when people attack Gadi or anyone else with no substantive facts to justify those attacks, I always assume that they are part of the criminal gangs who drive network abuse in the 21st century. Of course they may just be harmless fools who think that they will become better network operators if they can become part of the in group. Who knows... Personally, I am not particularly disturbed that security vulnerabilities are announced with few substantive details. That's just the way things are normally done in the real world. --Michael Dillon From ge at linuxbox.org Sat May 17 18:39:01 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 18:39:01 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <20080517175150.e00b3b69.fx@recurity-labs.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517175150.e00b3b69.fx@recurity-labs.com> Message-ID: On Sat, 17 May 2008, Felix 'FX' Lindner wrote: > > But I don't see a reason for panic and Cisco is at least partially > right with their response > ( http://www.cisco.com/en/US/products/products_security_response09186a0080997783.html ) > to the whole issue: someone still needs a privilege level 15 VTY on > your router and no matter what press is currently making of the > rootkit, this prerequisite step is non-trivial (or should be, > depending on your configuration). On this rootkit and IOS security and how it works FX's word is of the most qualified. > > cheers > FX > > -- > Recurity Labs GmbH | Felix 'FX' Lindner > http://www.recurity-labs.com | fx at recurity-labs.com > Wrangelstrasse 4 | Fon: +49 30 69539993-0 > 10997 Berlin | PGP: A740 DE51 9891 19DF 0D05 > Germany | 13B3 1759 C388 C92D 6BBB > HRB 105213 B, Amtsgericht Charlottenburg, GF Felix Lindner > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat May 17 18:59:47 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 18 May 2008 09:29:47 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: <20080517143419.GQ5193@subspacefield.org> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517143419.GQ5193@subspacefield.org> Message-ID: <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sat, 17 May 2008 09:34:19 -0500 travis+ml-nanog at subspacefield.org wrote: > On Sat, May 17, 2008 at 04:47:02PM +0930, Matthew Moyle-Croft wrote: > > I'm sure it'll be good for a number of security providers to hawk their > > wares. > > > > If the way of running this isn't out in the wild and it's actually > > dangerous then a pox on anyone who releases it, especially to gain > > publicity at the expensive of network operators sleep and well being. > > May you never find a reliable route ever again. > > I personally like Gadi's work, but not as much as I like getting my > packets to their destination. I personally don't quite understand why > netops keep buying proprietary, closed technology for routers, but I'm > not and have never been a netop so I'm sure there's good reasons. To > me it seems that if you need reliable router hardware, you can buy > that from a vendor, but in theory I don't see why the software for > routers couldn't be much more open. When I can, I reflash my WAPs > with DD-WRT, because at least then I understand the system (and you > can't secure what you don't understand), but I am not saying that's > much of a comparison. > Have you read and security validated every line of open code you're running? Even if you've only read and security validated 99% of it, you're still trusting that the other 1% doesn't have any vulnerabilities in it. Then again, even if you have audited every line of code, and it is 100% "secure", who's to say the compiler used to compile it is ... so you'll have to audit that too. "Reflections on Trusting Trust" http://cm.bell-labs.com/who/ken/trust.html And then, even if you trust your build environment because you've audited it, who's to say that the CPU itself doesn't have a vulnerability in its microcode (accidental or intentionally), or the harddrive, or the TOE network card (that can probably establish TCP connections completely transparent to the OS it's working fo) or the keyboard doesn't have a built in key sniffer, inserted by the chip manufacturer when the designers outsourced it. (The TOE card is an interesting one - they'd commonly be used on high performance servers, and typically those are holding or have access to the organisation's most sensitive data ...) So the only way you can be absolutely sure is to build everything or audit everything yourself, from the transistor level up through the layers OSI RM. And even then, you're battling your own human frailty - how can you be sure you haven't missed something? As the cliche goes, "If you want something done properly, you have to do it yourself." If you can't do it (all) yourself, because you don't have the time and the expertise, then inherently you have to place a level of trust in other people. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From ge at linuxbox.org Sat May 17 18:59:37 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 17 May 2008 18:59:37 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517143419.GQ5193@subspacefield.org> <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: On Sun, 18 May 2008, Mark Smith wrote: > > "Reflections on Trusting Trust" > http://cm.bell-labs.com/who/ken/trust.html That is the #1 paper on security anyone can read, and reading your email I was about to ask if you ever read it. It certainly is my fav. Thanks for reminding us all of the url. Gadi. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat May 17 19:04:14 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 18 May 2008 09:34:14 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517143419.GQ5193@subspacefield.org> <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <20080518093414.f3355c28.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sun, 18 May 2008 09:29:47 +0930 Mark Smith wrote: > On Sat, 17 May 2008 09:34:19 -0500 > travis+ml-nanog at subspacefield.org wrote: > > > On Sat, May 17, 2008 at 04:47:02PM +0930, Matthew Moyle-Croft wrote: > > > I'm sure it'll be good for a number of security providers to hawk their > > > wares. > > > > > > If the way of running this isn't out in the wild and it's actually > > > dangerous then a pox on anyone who releases it, especially to gain > > > publicity at the expensive of network operators sleep and well being. > > > May you never find a reliable route ever again. > > > > I personally like Gadi's work, but not as much as I like getting my > > packets to their destination. I personally don't quite understand why > > netops keep buying proprietary, closed technology for routers, but I'm > > not and have never been a netop so I'm sure there's good reasons. To > > me it seems that if you need reliable router hardware, you can buy > > that from a vendor, but in theory I don't see why the software for > > routers couldn't be much more open. When I can, I reflash my WAPs > > with DD-WRT, because at least then I understand the system (and you > > can't secure what you don't understand), but I am not saying that's > > much of a comparison. > > > > > As the cliche goes, "If you want something done properly, you have to > do it yourself." If you can't do it (all) yourself, because you don't > have the time and the expertise, then inherently you have to place a should have been "have the time and/or the expertise" > level of trust in other people. > > Regards, > Mark. > > -- > > "Sheep are slow and tasty, and therefore must remain constantly > alert." > - Bruce Schneier, "Beyond Fear" > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From drew.weaver at thenap.com Sat May 17 22:53:00 2008 From: drew.weaver at thenap.com (Drew Weaver) Date: Sat, 17 May 2008 23:53:00 -0400 Subject: [NANOG] Limiting ICMP Message-ID: Hi there, I'm wondering if anyone else has run into this/has heard of/(is responsible for)/knows the reason behind large IP providers limiting ICMP on outbound connections to the same amounts regardless of the size of the circuit? Apparently after one of our upstream providers switched to Juniper for some of their equipment their engineers recommended that they limit ICMP on all customer facing connections to 5mbps. I understand that preventing DDoS is important but why A) would they apply the same rule to our OC-48 that they apply to someone else's T1/DS-3 and B) why is that a requirement for Juniper gear? (do people still DDoS with ICMP these days? I see a lot of what looks like udp.pl and hardly any ICMP attack traffic anymore) Sorry as usual if i'm off-topic. -Drew From kgasso-lists at visp.net Sun May 18 00:12:52 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Sat, 17 May 2008 22:12:52 -0700 Subject: [NANOG] Limiting ICMP In-Reply-To: References: Message-ID: <482FBAD4.6060508@visp.net> Drew Weaver wrote: > (do people still DDoS with ICMP these days? I see a lot of what looks like udp.pl and hardly any ICMP attack traffic anymore) We saw a small attempted attack using ICMP a few weeks ago, but as you've mentioned I've mostly been seeing UDP floods (and the occasional TCP SYNflood still). I do feel the need to comment that more and more lately I've been running into extremely frustrating situations where useful ICMP and UDP traffic was being filtered bidirectionally, not just rate-limited. I think my favorite incident so far of this was a host that returned an ICMP UNREACHABLE (with a "filtered" code) in response to an ECHO REQUEST to itself. Cheers, --Kameron From devangnp at gmail.com Sun May 18 01:28:58 2008 From: devangnp at gmail.com (devang patel) Date: Sun, 18 May 2008 01:28:58 -0500 Subject: [NANOG] Routing table for BGP In-Reply-To: <75cb24520805160825y553de5ddy49332eff8868c601@mail.gmail.com> References: <006501c8b765$a2eba030$6a14a8c0@jnpr.net> <75cb24520805160825y553de5ddy49332eff8868c601@mail.gmail.com> Message-ID: hello All, Yeah NANOG knowledge base is really great... thanks to all of you for your help... regards Devang Patel On Fri, May 16, 2008 at 10:25 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Fri, May 16, 2008 at 11:00 AM, Barry Raveendran Greene > wrote: > > > > The nice thing about NANOG is that we have YEARS of on-line Video > training > > to help you get up to speed. > > > > 1. Go to http://www.nanog.org/subjects.html (Index of Talks) > > > > 2. Look for materials on BGP. > > > > 3. Have fun learning from the best. > > > > My suggestion would be to watch last NANOG's BGP Tutorial. The nice thing > > about this is that you can E-mail the speaker to get clarifications. > > > > TO NANOG Community - We should really be pointed these FAQs to the > > resources/tools we've invested in building. I don't know whose idea it > was > > to VOD everything, but it is an vast untapped store house of knowledge. > > I think there is a nanog-wiki that Lynda was poking at last even?? > Maybe making sure there's a searchable form thingy there for the VOD > catalog? > > -Chris > From joelja at bogus.com Sun May 18 01:45:36 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 17 May 2008 23:45:36 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517143419.GQ5193@subspacefield.org> <20080518092947.776e7aa4.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <482FD090.9060809@bogus.com> Mark Smith wrote: > On Sat, 17 May 2008 09:34:19 -0500 > travis+ml-nanog at subspacefield.org wrote: > >> On Sat, May 17, 2008 at 04:47:02PM +0930, Matthew Moyle-Croft wrote: >>> I'm sure it'll be good for a number of security providers to hawk their >>> wares. >>> >>> If the way of running this isn't out in the wild and it's actually >>> dangerous then a pox on anyone who releases it, especially to gain >>> publicity at the expensive of network operators sleep and well being. >>> May you never find a reliable route ever again. >> I personally like Gadi's work, but not as much as I like getting my >> packets to their destination. I personally don't quite understand why >> netops keep buying proprietary, closed technology for routers, but I'm >> not and have never been a netop so I'm sure there's good reasons. To >> me it seems that if you need reliable router hardware, you can buy >> that from a vendor, but in theory I don't see why the software for >> routers couldn't be much more open. When I can, I reflash my WAPs >> with DD-WRT, because at least then I understand the system (and you >> can't secure what you don't understand), but I am not saying that's >> much of a comparison. >> > > Have you read and security validated every line of open code you're > running? Even if you've only read and security validated 99% of it, > you're still trusting that the other 1% doesn't have any > vulnerabilities in it. There are people who routinely deal in absolutes. we generally call them mathematicians... The rest of us have to operate on a certain amount of uncertainty. Ken's goal I think in 1985 was to open people's eyes to an area of uncertainty which was then relatively poorly understood. It was infeasible in 1985 and certainly remains so outside the confines of some really narrowly focused areas to audit a significant percentage of the code you run. > Then again, even if you have audited every line of code, and it is > 100% "secure", who's to say the compiler used to compile it is ... so you'll > have to audit that too. > From joelja at bogus.com Sun May 18 02:18:20 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 18 May 2008 00:18:20 -0700 Subject: [NANOG] Routing Tools BOF at NANOG tuesday June 3rd Message-ID: <482FD83C.9090702@bogus.com> We've got some interesting material already lined up that should be appearing on the agenda shortly. I wonder however if there's anyone in the community interested in discussing their personal operational experience with tools for black-hole automation, or prefix hijacking detection? I'm sure your colleagues would appreciate a view from the the trenches on what tools get used. Thanks Joel From dr at kyx.net Sun May 18 08:57:03 2008 From: dr at kyx.net (Dragos Ruiu) Date: Sun, 18 May 2008 06:57:03 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: On 17-May-08, at 3:12 AM, Suresh Ramasubramanian wrote: > On Sat, May 17, 2008 at 12:47 PM, Matthew Moyle-Croft > wrote: >> If the way of running this isn't out in the wild and it's actually >> dangerous then a pox on anyone who releases it, especially to gain >> publicity at the expensive of network operators sleep and well being. >> May you never find a reliable route ever again. > > This needs fixing. It doesnt need publicity at security conferences > till after cisco gets presented this stuff first and asked to release > an emergency patch. Bullshit. There is nothing to patch. It needs to be presented at conferences, exactly because people will play ostrich and stick their heads in the sand and pretend it can't happen to them, and do nothing about it until someone shows them, "yes it can happen" and here is how.... Which is exactly why we've accepted this talk. We've all known this is a possibility for years, but I haven't seen significant motion forward on this until we announced this talk. So in a fashion, this has already helped make people more realistic about their infrastructure devices. And the discussions, and idea interchange that will happen between the smart folks at the conference will undoubtedly usher forth other related issues and creative solutions. Problems don't get fixed until you talk about them. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques London, U.K. May 21/22 - 2008 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From ops.lists at gmail.com Sun May 18 09:11:01 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 18 May 2008 19:41:01 +0530 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: Let's put it this way. 1. Yes there's nothing to patch, as such 2. It can be prevented by what's widely regarded as BCP on router security, and has been covered at *nog, in cisco training material, etc etc for quite some time now. I am much less concerned about security conferences discussing this than about the (highly uninformed) publicity that accompanies these conferences. Yes, this sounds a lot more like the bugtraq v/s full disclosure discussion than I'm comfortable with, but I still think this could have been handled a lot better. --srs On Sun, May 18, 2008 at 7:27 PM, Dragos Ruiu wrote: > Bullshit. > There is nothing to patch. > It needs to be presented at conferences, exactly because people will play > ostrich and stick their heads in the sand and pretend it can't happen to > them, and do nothing about it until someone shows them, "yes it can happen" > and here is how.... > Which is exactly why we've accepted this talk. We've all known this is a > possibility for years, but I haven't seen significant motion forward on this > until we announced this talk. So in a fashion, this has already helped make > people more realistic about their infrastructure devices. And the > discussions, and idea interchange that will happen between the smart folks > at the conference will undoubtedly usher forth other related issues and > creative solutions. Problems don't get fixed until you talk about them. > cheers, > --dr From pekkas at netcore.fi Sun May 18 09:25:48 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 18 May 2008 17:25:48 +0300 (EEST) Subject: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive) In-Reply-To: <482DE5D2.6060609@karnaugh.za.net> References: <482DBFDC.2020303@spaghetti.zurich.ibm.com> <2ee691ff0805161058p1bf0b676u2238f4717d1223e2@mail.gmail.com> <5BDFB474-4B72-44E7-B94E-E233AEA07ECC@asgaard.org> <482DE5D2.6060609@karnaugh.za.net> Message-ID: On Fri, 16 May 2008, Colin Alston wrote: > On 16/05/2008 20:15 Christopher LILJENSTOLPE wrote: >> My guess is that they don't want to be tied to only announcing a >> single /13. Each of those organizations is bigger than a lot of >> service providers out there... > > Since when do you have to announce only the same size prefix as your > allocation? http://www.arin.net/policy/nrpm.html#six511 reads: "c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation;" Other regions have, or have had, similar requirements. I'm not a native speaker, but I guess "single aggregated address allocation" could be read to imply either 1) "one superblock [and nothing else]", or 2) "at least one superblock that covers everything" (with no implied statement on the more specifics). Even if the interpretation is the second, the "benefit" of multiple allocations is that they wouldn't need to route between all the suballocations at least in one location in case someone is building route filters so that it would reject more specifics. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ge at linuxbox.org Sun May 18 09:48:25 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 18 May 2008 09:48:25 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: On Sun, 18 May 2008, Dragos Ruiu wrote: > > On 17-May-08, at 3:12 AM, Suresh Ramasubramanian wrote: > >> On Sat, May 17, 2008 at 12:47 PM, Matthew Moyle-Croft >> wrote: >>> If the way of running this isn't out in the wild and it's actually >>> dangerous then a pox on anyone who releases it, especially to gain >>> publicity at the expensive of network operators sleep and well being. >>> May you never find a reliable route ever again. >> >> This needs fixing. It doesnt need publicity at security conferences >> till after cisco gets presented this stuff first and asked to release >> an emergency patch. > > Bullshit. > > There is nothing to patch. > > It needs to be presented at conferences, exactly because people will > play ostrich and stick their heads in the sand and pretend it can't > happen to them, and do nothing about it until someone shows them, "yes > it can happen" and here is how.... > > Which is exactly why we've accepted this talk. We've all known this is > a possibility for years, but I haven't seen significant motion forward > on this until we announced this talk. So in a fashion, this has > already helped make people more realistic about their infrastructure > devices. And the discussions, and idea interchange that will happen > between the smart folks at the conference will undoubtedly usher forth > other related issues and creative solutions. Problems don't get fixed > until you talk about them. Dragus, while I hold full disclosure very close and it is dear to my heart, I admit the fact that it can be harmful. Let me link that to network operations. People forget history. A few years back I had a chat with Aleph1 on the first days of bugtraq. He reminded me how things are not always black and white. Full disclosure, while preferable in my ideology, is not the best solution for all. One of the reasons bugtraq was created is because vendors did not care about security, not to mention have a capability to handle security issues, or avoid them to begin with. Full disclosure made a lot of progress for us, and while still a useful tool, with some vendors it has become far more useful to report to them and let them provide with a solution first. In the case of routers which are used for infrastructure as well as critical infrastructure, it is my strong belief that full disclosure is, at least at face value, a bad idea. I'd like to think Cisco, which has shown capability in the past, is as responsible as it should be on these issues. Experience tells me they have a ways to go yet even if they do have good processes in place with good people to employ them. I'd also like to think tier-1 and tier-2 providers get patches first before such releases. This used to somewhat be the case, last I checked it no longer is -- for legitimate concerns by Cisco. has this changed? So, if we don't patch the infrastructure up first, and clients don't know of problems until they are public "for their own security" (an argument that holds water only so much) perhaps it is the time for full disclosure to be considered a viable alternative. All that aside, this is a rootkit, not a vulnerability. There is no inherent vulnerability to patch (unless it is very local). There is the vulnerability of operators who don't so far even consider trojan horses as a threat, and the fact tools don't exist for them to do something once they do. Gadi. > cheers, > --dr > > > > -- > World Security Pros. Cutting Edge Training, Tools, and Techniques > London, U.K. May 21/22 - 2008 http://cansecwest.com > pgpkey http://dragos.com/ kyxpgp > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From ge at linuxbox.org Sun May 18 09:50:00 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 18 May 2008 09:50:00 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: On Sun, 18 May 2008, Suresh Ramasubramanian wrote: > Let's put it this way. > > 1. Yes there's nothing to patch, as such > > 2. It can be prevented by what's widely regarded as BCP on router > security, and has been covered at *nog, in cisco training material, > etc etc for quite some time now. > > I am much less concerned about security conferences discussing this > than about the (highly uninformed) publicity that accompanies these > conferences. > > Yes, this sounds a lot more like the bugtraq v/s full disclosure > discussion than I'm comfortable with, but I still think this could > have been handled a lot better. It's easy to blame researchers for doing their studies, but the fact is, if one whitehat researcher has done work on it, it is already exploited in the wild. Gadi. > > --srs > > On Sun, May 18, 2008 at 7:27 PM, Dragos Ruiu wrote: > >> Bullshit. >> There is nothing to patch. >> It needs to be presented at conferences, exactly because people will play >> ostrich and stick their heads in the sand and pretend it can't happen to >> them, and do nothing about it until someone shows them, "yes it can happen" >> and here is how.... >> Which is exactly why we've accepted this talk. We've all known this is a >> possibility for years, but I haven't seen significant motion forward on this >> until we announced this talk. So in a fashion, this has already helped make >> people more realistic about their infrastructure devices. And the >> discussions, and idea interchange that will happen between the smart folks >> at the conference will undoubtedly usher forth other related issues and >> creative solutions. Problems don't get fixed until you talk about them. >> cheers, >> --dr > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From dr at kyx.net Sun May 18 15:33:53 2008 From: dr at kyx.net (Dragos Ruiu) Date: Sun, 18 May 2008 13:33:53 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> Message-ID: <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> On 18-May-08, at 7:11 AM, Suresh Ramasubramanian wrote: > 2. It can be prevented by what's widely regarded as BCP on router > security, and has been covered at *nog, in cisco training material, > etc etc for quite some time now. > > I am much less concerned about security conferences discussing this > than about the (highly uninformed) publicity that accompanies these > conferences. I'm not going to touch the disclosure or not debate... it's been done. But I will agree to disagree with you about the above two points. First of all about prevention, I'm not at all sure about this being covered by existing router security planning / BCP. I don't believe most operators reflash their routers periodically, nor check existing images (particularly because the tools for this integrity verification don't even exist). If I'm wrong about this I would love to be corrected with pointers to the tools. Regarding the second point, I also lament the often liberal doses of alarmism/FUD that get plastered over the popular media whenever complicated technical issues are discussed - but unless we have some have the discussions, and information dispersal, then the misconceptions have no chance of being dispelled. The threat of misinformed press does not seem to be sufficient to justify censuring open discussion of the issues imho. One of the thing I truly enjoy about the conferences we organize, is seeing the synergism that occurs when multiple minds focus on these security issues at the conferences. When the analysis is parallelized over multiple brains, inevitably the creative solutions that occur from the congregation of different viewpoints and ideas is pleasantly surprising, and powerful. I've seen numerous examples of this: even just last April I had a chance to be a fly on the wall at a discussion between Jacob Appelbaum and Theo DeRaadt talking about the cold memory attacks research Jacob started - the result of which was that during the discussion it was realized that with the addition of about 30 lines of code in the power fail interrupt handler a large segment of those attacks could be nullified, as they are now on OpenBSD. If the discussion hadn't happened, the creative solution to it would have never arisen. These kinds of "out of the box" solutions frequently arise out of multi-person debate and free association that follows discussions of serious issues - no-one has the whole picture and adding other's viewpoints often brings superior solutions to problems up. So in my opinion the benefits of discussing serious issues at conferences far outweigh the potential drawbacks of misguided media coverage of them. What I infer from your post is that you are of the opinion that issues such as this rootkit prototype should be reported to CSIRT and then shuffled under a carpet. To which I respond that that kind of attitude has led to what I currently consider to be an inappropriate level of concern and awareness amongst service providers of the seriousness of this threat. Cisco has some great guys, but surely discussion of this threat amongst the wider security community will lead to more and better solutions than Cisco operating in a vacuum. And more importantly this issue is not a Cisco issue - the basic threat vector should be a concern to other infrastructure equipment manufacturers too. Until we talk about it, we cannot find the right responses to the problem, and experts talking about it usually leads to better and more comprehensive solutions than single persons or smaller groups working in isolation. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques London, U.K. May 21/22 - 2008 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From joelja at bogus.com Sun May 18 16:14:17 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 18 May 2008 14:14:17 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> Message-ID: <48309C29.70700@bogus.com> Dragos Ruiu wrote: > First of all about prevention, I'm not at all sure about this being > covered by existing router security planning / BCP. > I don't believe most operators reflash their routers periodically, nor > check existing images (particularly because the tools for this > integrity verification don't even exist). If I'm wrong about this I > would love to be corrected with pointers to the tools. I have 6 years worth of rancid logs for every time the reported number of blocks in use on my flash changes, I imagine others do as well. That's hardly the silver bullet however. We as I imagine others do expended a fair amount of cycles monitoring who it is that our routers are talking to and protecting the integrity of the communications channels that they use (bgp, ospf, ssh, tftp etc), If a router has a tcp connection to someplace it shouldn't we'll probably know about it. If it's announcing a prefix it shouldn't be, we'll probably know about it, those are the easy ones though. There are some things one might consider adding in terms of auditing, comparing the running image more closely to the one in flash for example, peroidic checksum of the on onflash image, after downloading to another host would be another. I'm not sure that I'd trust the later given the rooted box can I suppose hand you an unmodified version of the subverted image. In the end if you subvert a router, presumably you're doing it for a purpose and given what the device does, that purpose is probably detectable in a well instrumented network. It is desirable I expect to insure that any locally stored security credentials that might be subverted not be usable when connecting to another router, that applies in a absence of root kits however. > Regarding the second point, I also lament the often liberal doses of > alarmism/FUD that get plastered over the popular media whenever > complicated technical issues are discussed - but unless we have some > have the discussions, and information dispersal, then the > misconceptions have no chance of being dispelled. > The threat of misinformed press does not seem to be sufficient to > justify censuring open discussion of the issues imho. > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun May 18 16:53:12 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 19 May 2008 07:23:12 +0930 Subject: [NANOG] IOS rootkits In-Reply-To: <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> Message-ID: <20080519072312.28481f0c.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Sun, 18 May 2008 13:33:53 -0700 Dragos Ruiu wrote: > > On 18-May-08, at 7:11 AM, Suresh Ramasubramanian wrote: > > 2. It can be prevented by what's widely regarded as BCP on router > > security, and has been covered at *nog, in cisco training material, > > etc etc for quite some time now. > > > > I am much less concerned about security conferences discussing this > > than about the (highly uninformed) publicity that accompanies these > > conferences. > > > I'm not going to touch the disclosure or not debate... it's been done. > > But I will agree to disagree with you about the above two points. > > First of all about prevention, I'm not at all sure about this being > covered by existing router security planning / BCP. > I don't believe most operators reflash their routers periodically, nor > check existing images (particularly because the tools for this > integrity verification don't even exist). If I'm wrong about this I > would love to be corrected with pointers to the tools. > Cisco publish an MD5 sum (and BSD 'sum' IIRC) for the IOS image just before you hit the download page, which you can record and then verify after downloading (although they could make this a *lot* easier to do by posting it after, or before and after the download). There is also a /md5 option for the IOS verify command which can be used to generate an MD5 sum for an IOS image stored on a router. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From ge at linuxbox.org Sun May 18 17:54:51 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 18 May 2008 17:54:51 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <48309C29.70700@bogus.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> Message-ID: On Sun, 18 May 2008, Joel Jaeggli wrote: > Dragos Ruiu wrote: > >> First of all about prevention, I'm not at all sure about this being >> covered by existing router security planning / BCP. >> I don't believe most operators reflash their routers periodically, nor >> check existing images (particularly because the tools for this >> integrity verification don't even exist). If I'm wrong about this I >> would love to be corrected with pointers to the tools. > > I have 6 years worth of rancid logs for every time the reported number > of blocks in use on my flash changes, I imagine others do as well. > That's hardly the silver bullet however. > > We as I imagine others do expended a fair amount of cycles monitoring > who it is that our routers are talking to and protecting the integrity > of the communications channels that they use (bgp, ospf, ssh, tftp etc), > If a router has a tcp connection to someplace it shouldn't we'll > probably know about it. If it's announcing a prefix it shouldn't be, > we'll probably know about it, those are the easy ones though. I am very happy to hear you do these... very useful and will catch quite a bit. > There are some things one might consider adding in terms of auditing, > comparing the running image more closely to the one in flash for > example, peroidic checksum of the on onflash image, after downloading to > another host would be another. I'm not sure that I'd trust the later > given the rooted box can I suppose hand you an unmodified version of the > subverted image. The result from your check can easily be modified, first thing I would have changed is the checker. Say you did this from a usb stick--I'd just hide the rootkit in memory. > In the end if you subvert a router, presumably you're doing it for a > purpose and given what the device does, that purpose is probably > detectable in a well instrumented network. Subversion may not be the goal. A router is perfect for faking outgoing traffic. This traffic can contain stolen sniffed or relayed data. > It is desirable I expect to insure that any locally stored security > credentials that might be subverted not be usable when connecting to > another router, that applies in a absence of root kits however. From joelja at bogus.com Sun May 18 19:54:27 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 18 May 2008 17:54:27 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> Message-ID: <4830CFC3.9040401@bogus.com> Gadi Evron wrote: > On Sun, 18 May 2008, Joel Jaeggli wrote: >> Dragos Ruiu wrote: >> >>> First of all about prevention, I'm not at all sure about this being >>> covered by existing router security planning / BCP. >>> I don't believe most operators reflash their routers periodically, nor >>> check existing images (particularly because the tools for this >>> integrity verification don't even exist). If I'm wrong about this I >>> would love to be corrected with pointers to the tools. >> >> I have 6 years worth of rancid logs for every time the reported number >> of blocks in use on my flash changes, I imagine others do as well. >> That's hardly the silver bullet however. >> >> We as I imagine others do expended a fair amount of cycles monitoring >> who it is that our routers are talking to and protecting the integrity >> of the communications channels that they use (bgp, ospf, ssh, tftp etc), >> If a router has a tcp connection to someplace it shouldn't we'll >> probably know about it. If it's announcing a prefix it shouldn't be, >> we'll probably know about it, those are the easy ones though. > > I am very happy to hear you do these... very useful and will catch quite > a bit. > >> There are some things one might consider adding in terms of auditing, >> comparing the running image more closely to the one in flash for >> example, peroidic checksum of the on onflash image, after downloading to >> another host would be another. I'm not sure that I'd trust the later >> given the rooted box can I suppose hand you an unmodified version of the >> subverted image. > > The result from your check can easily be modified, first thing I would > have changed is the checker. That is a normal thing to do with rootkits (return bogus results). Which is part of the reason I suggested that method I did. Short of pulling the flash you're not going to get a fully unbiased view of what's it on it thusly the audit process has some limitations. A TCPA style boot process would be a better approach. It's certainly not a quick fix since it in general can't be retrofited to existing products. > Say you did this from a usb stick--I'd just > hide the rootkit in memory. > >> In the end if you subvert a router, presumably you're doing it for a >> purpose and given what the device does, that purpose is probably >> detectable in a well instrumented network. > > Subversion may not be the goal. A router is perfect for faking outgoing > traffic. This traffic can contain stolen sniffed or relayed data. If my device is now taking marching orders from a third party then by definition it is subverted, regardless of agency or activity. sub verte - turn from under From ge at linuxbox.org Sun May 18 22:30:01 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 18 May 2008 22:30:01 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <4830CFC3.9040401@bogus.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> <4830CFC3.9040401@bogus.com> Message-ID: On Sun, 18 May 2008, Joel Jaeggli wrote: >> >> The result from your check can easily be modified, first thing I would have >> changed is the checker. > > That is a normal thing to do with rootkits (return bogus results). Which is > part of the reason I suggested that method I did. Short of pulling the flash > you're not going to get a fully unbiased view of what's it on it thusly the > audit process has some limitations. > > A TCPA style boot process would be a better approach. It's certainly not a > quick fix since it in general can't be retrofited to existing products. EuSecWest released this interview about the rootkit with its creator, Sebastian Muniz of Core Security, it also mentions a third party product to detect some of these issues. Thank whatever diety we like for FX's work, as obviously Cisco isn't there yet. http://eusecwest.com/sebastian-muniz-da-ios-rootkit.html >> Say you did this from a usb stick--I'd just hide the rootkit in memory. >> >>> In the end if you subvert a router, presumably you're doing it for a >>> purpose and given what the device does, that purpose is probably >>> detectable in a well instrumented network. >> >> Subversion may not be the goal. A router is perfect for faking outgoing >> traffic. This traffic can contain stolen sniffed or relayed data. > > If my device is now taking marching orders from a third party then by > definition it is subverted, regardless of agency or activity. > > sub verte - turn from under > From marc at let.de Sun May 18 22:53:01 2008 From: marc at let.de (Marc Manthey) Date: Mon, 19 May 2008 05:53:01 +0200 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> <4830CFC3.9040401@bogus.com> Message-ID: <312F43F9-C62B-4581-824E-DF15658F8C79@let.de> > > http://eusecwest.com/sebastian-muniz-da-ios-rootkit.html its worth a digg... regards -- "Use your imagination not to scare yourself to death but to inspire yourself to life." Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 K?ln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc at kgraff.net blog : http://www.let.de ipv6 http://www.ipsix.org xing : https://www.xing.com/profile/Marc_Manthey From ops.lists at gmail.com Sun May 18 22:57:49 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 19 May 2008 09:27:49 +0530 Subject: [NANOG] IOS rootkits In-Reply-To: <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> Message-ID: On Mon, May 19, 2008 at 2:03 AM, Dragos Ruiu wrote: > So in my opinion the benefits of discussing serious issues at conferences > far outweigh the potential drawbacks of misguided media coverage of them. > What I infer from your post is that you are of the opinion that issues such Well, there are any number of closed, no media, relevant people only conferences, or communities like nsp-sec, that come in useful Report to CSIRT by all means but that doesnt imply "brush it under the carpet". Getting releases out and fixes (if only router management bcp like in Joel Jaeggli's post) without various people spreading FUD about it should certainly be an achievable goal? srs From hb-nanog at bsws.de Mon May 19 01:00:07 2008 From: hb-nanog at bsws.de (Henning Brauer) Date: Mon, 19 May 2008 08:00:07 +0200 Subject: [NANOG] 10GE router resource In-Reply-To: <4116134.186351206494157370.JavaMail.root@protozoa> References: <20080326010203.GK31583@skywalker.creative.net.au> <4116134.186351206494157370.JavaMail.root@protozoa> Message-ID: <20080519060005.GA7809@nudo.bsws.de> * Patrick Clochesy [2008-03-26 02:26]: > I also had to switch to OpenBSD congrats > AFAIK pf/forwarding only takes place on one core and wouldn't take > advantage of the other 3 cores, correct? for the moment, yes. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam From hb-nanog at bsws.de Mon May 19 01:03:52 2008 From: hb-nanog at bsws.de (Henning Brauer) Date: Mon, 19 May 2008 08:03:52 +0200 Subject: [NANOG] 10GE router resource In-Reply-To: <18f601940803251913t280bf39ehd527ca69fe1ee3b9@mail.gmail.com> References: <20080326010203.GK31583@skywalker.creative.net.au> <4116134.186351206494157370.JavaMail.root@protozoa> <18f601940803251913t280bf39ehd527ca69fe1ee3b9@mail.gmail.com> Message-ID: <20080519060352.GB7809@nudo.bsws.de> * Aaron Glenn [2008-03-26 03:14]: > > On Tue, Mar 25, 2008 at 6:15 PM, Patrick Clochesy wrote: > > Very interesting study I had not seen, and a bummer. That really puts a > > cramp in my advocation of our CARP+pf load balancers/firewalls/gateways. > > Than again, what's a PIX box capable of? > > I'd rather tweak a whitebox than pay through the nose for a PIX. > > > I also had to switch to OpenBSD as there was a fatal crash with the bridge > > device in FreeBSD when used with my paticular OpenVPN/CARP/pf combination. > > > > AFAIK pf/forwarding only takes place on one core and wouldn't take advantage > > of the other 3 cores, correct? > > Correct. There has been some great speed and efficiency improvements > in pf and other networking parts of OpenBSD; though from anecdotal > evidence, 10GbE is not ready for 'primetime' (for certain definitions > of 'primetime'). > > actually I'll just skip making an ass out of myself and hope henning@ > chimes in, since I believe he reads NANOG as well. occasionally. as with all other OSes constructed benchmarks would show 10GE to work at wirespeed with reasonable hardware. I would not use it (yet) if I truly need 10 GBit/s forwarding rate, and that goes for any OS. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam From eh at profzone.ch Mon May 19 06:29:39 2008 From: eh at profzone.ch (Erich Hohermuth) Date: Mon, 19 May 2008 13:29:39 +0200 Subject: [NANOG] Installation troubles with GlobalCrossing In-Reply-To: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> References: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> Message-ID: <1211196580.32179.5.camel@matrix.mlan.solnet.ch> Dear list, Thanks to everyone who has respond to me by privat mails. > I just want to ask if anyone else have major troubles to install new or > upgrade services with Global Crossing ? It seems that I'm not the only one who has troubles with installations and trouble tickets in the past 12 months. I also get some offers from competitors which promise to bring up a point two point link within 10 days. Thanks Eric From jbates at brightok.net Mon May 19 10:07:48 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 19 May 2008 10:07:48 -0500 Subject: [NANOG] IOS rootkits In-Reply-To: <87fxsgk5in.fsf@mid.deneb.enyo.de> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <73053.1211028185@turing-police.cc.vt.edu> <482EDAC0.5000801@internode.com.au> <482EF037.1050205@bogus.com> <87fxsgk5in.fsf@mid.deneb.enyo.de> Message-ID: <483197C4.10902@brightok.net> Florian Weimer wrote: > > | Network administrators are not able to observe Lawful Intercept is > | enabled. No Lawful Intercept program messages or error messages are ever > | displayed on the console. > > > > This is a Sony-style rootkit, but it certainly demonstrate that the > concept is feasible (surprise). > Eh, it's a little misleading. Every Net admin knows when Lawful Intercept is activated on their router. The processor utilization takes a major spike. What it's doing might not be known, though umm, even intercept traffic itself can be intercepted or redirected through portions of the network where it can be intercepted. ;) Jack From bonomi at mail.r-bonomi.com Mon May 19 12:57:09 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 19 May 2008 12:57:09 -0500 (CDT) Subject: [NANOG] Installation troubles with GlobalCrossing Message-ID: <200805191757.m4JHv9qH000793@mail.r-bonomi.com> > From nanog-bounces at nanog.org Mon May 19 06:30:15 2008 > From: Erich Hohermuth > To: nanog at nanog.org > Date: Mon, 19 May 2008 13:29:39 +0200 > Subject: Re: [NANOG] Installation troubles with GlobalCrossing > > Dear list, > > Thanks to everyone who has respond to me by privat mails. > > > I just want to ask if anyone else have major troubles to install new or > > upgrade services with Global Crossing ? > > It seems that I'm not the only one who has troubles with installations > and trouble tickets in the past 12 months. I also get some offers from > competitors which promise to bring up a point two point link within 10 > days. Easy way to find out if the competitors mean it, or are just more marketing smoke -- see if they'll sign a contract with the fixed turn-up date, *AND* a, say, 500 Euro/day penalty (payable in cash, not just a service credit) for each day they miss the promised date. If they won't sign that contract, ask "why not?" The non-answers for that can be really entertaining. From pauldotwall at gmail.com Mon May 19 13:29:14 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 19 May 2008 14:29:14 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <20080517073451.GI10920@virtual.bogons.net> <482EC793.7010800@internode.com.au> <73053.1211028185@turing-police.cc.vt.edu> <482EDAC0.5000801@internode.com.au> Message-ID: <620fd17c0805191129m5985db05p9ca790294b274787@mail.gmail.com> On Sat, May 17, 2008 at 5:45 PM, wrote: > It's the people who pop up and smear Gadi that I really wonder > about. There seems to be no good reason for this, unless possibly > they are blackhats of some sort. I remember a few years ago > when William Leibzon posted about his work which eventually > became completewhois.com and several blackhats popped up and > tried to smear him. So when people attack Gadi or anyone else > with no substantive facts to justify those attacks, I always > assume that they are part of the criminal gangs who drive network > abuse in the 21st century. Of course they may just be harmless > fools who think that they will become better network operators > if they can become part of the in group. Who knows... Actually, Michael, folks who have problems with Gadi, William, and certain other offenders are mainly annoyed with the quantity (high) and quality (low) of their posts. That you seem to have a blind spot in the direction of this particular explanation is dismaying but not surprising. Paul From williamsjj at digitar.com Mon May 19 13:43:18 2008 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Mon, 19 May 2008 12:43:18 -0600 Subject: [NANOG] Earthlink Relayed Spam Increase Message-ID: Hey Y'all, We're seeing a marked increase of spam originating from Earthlink mail servers over the past week and a half. Is anyone else seeing a spike localized to Earthlink as well? Thank you in advance. Best Regards, Jason --- Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com E: williamsjj at digitar.com V: 208-343-8520 M: 208-863-0727 F: 208-322-8520 XMPP: williamsjj at digitar.com From deepak at ai.net Mon May 19 14:10:38 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 19 May 2008 15:10:38 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: <3260A110-46FE-42E6-BB2B-1287476EF3C4@kyx.net> References: <3260A110-46FE-42E6-BB2B-1287476EF3C4@kyx.net> Message-ID: <4831D0AE.8050400@ai.net> Wouldn't this level of verification/authentication of running code be a pretty trivial function via RANCID or similar tool? I understand *why* we are worried about rootkits on individual servers. On essentially "closed" platforms this isn't going to be rocket science. It may seem odd by today's BCPs, but booting up from "golden" images via write-protected hardware or TFTP or similar is pretty straightforward -- especially for those of us who run large server farms. A POP or node could certainly keep a few servers around that are a permanent repository of these items for all the devices that get images. If you can't trust the boot rom, well, that's an entirely separate matter. I think the issue with rootkits whether server or embedded device is more about infection vector than the maliciousness that could be caused AFTER a compromise has occurred. Deepak Jain Dragos Ruiu wrote: > The question this presentation begs for me... is how many of the folks > on this list do integrity checking on their routers? > > You can no longer say this isn't necessary :-). > > I know FX and a few others are working on toolsets for this... > > I'll probably have other comments after I see the presentation. > This development has all sort of implications for binary signing > requirements, etc... > > cheers, > --dr > > -- > World Security Pros. Cutting Edge Training, Tools, and Techniques > London, U.K. May 21/22 - 2008 http://cansecwest.com > pgpkey http://dragos.com/ kyxpgp > > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > From gtb at slac.stanford.edu Mon May 19 14:41:04 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Mon, 19 May 2008 12:41:04 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: <4831D0AE.8050400@ai.net> References: <3260A110-46FE-42E6-BB2B-1287476EF3C4@kyx.net> <4831D0AE.8050400@ai.net> Message-ID: > I understand *why* we are worried about rootkits on > individual servers. > On essentially "closed" platforms this isn't going to be > rocket science. > It may seem odd by today's BCPs, but booting up from "golden" > images via > write-protected hardware or TFTP or similar is pretty > straightforward Since todays bootstrap codes are in EEPROM (or equivalent), if you get "root" once, you can have "root" forever. Faking file system content (and real time replacing of code) is the core of any current (good) Linux/Mac/Windows rootkit. Cisco/Juniper/Force10/whatever is just another platform to do the same if you can replace the bootstrap. Modular IOS might even make it easier to do dynamic code insertion. There are platforms (Xbox?, Tivo?, etc.) that try to do cryptographic validation of the code they are loading. Network devices are not yet doing a true cryptograhic validation as far as I know, although one could imagine that that might be a next step to protect against that specific threat (although I seem to recall that bypassing the Xbox validations only took a few months, so it is harder than it first appears to get right). Gary From deepak at ai.net Mon May 19 14:55:42 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 19 May 2008 15:55:42 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: References: <3260A110-46FE-42E6-BB2B-1287476EF3C4@kyx.net> <4831D0AE.8050400@ai.net> Message-ID: <4831DB3E.7080108@ai.net> Buhrmaster, Gary wrote: >> I understand *why* we are worried about rootkits on >> individual servers. >> On essentially "closed" platforms this isn't going to be >> rocket science. >> It may seem odd by today's BCPs, but booting up from "golden" >> images via >> write-protected hardware or TFTP or similar is pretty >> straightforward > > Since todays bootstrap codes are in EEPROM (or > equivalent), if you get "root" once, you can > have "root" forever. Faking file system content > (and real time replacing of code) is the core > of any current (good) Linux/Mac/Windows rootkit. > Cisco/Juniper/Force10/whatever is just another > platform to do the same if you can replace the > bootstrap. Modular IOS might even make it > easier to do dynamic code insertion. > > There are platforms (Xbox?, Tivo?, etc.) that try > to do cryptographic validation of the code they > are loading. Network devices are not yet doing > a true cryptograhic validation as far as I know, > although one could imagine that that might be a > next step to protect against that specific threat > (although I seem to recall that bypassing the Xbox > validations only took a few months, so it is harder > than it first appears to get right). > I think that is exactly the point. Once a box has been thoroughly compromised, its almost impossible to bring it back to a "known, good" state without a complete (reformat). In the case of embedded HW, that may include wiping/rewriting the EEPROMs to a known good state. I don't think this is going to be outside of the purview of Network Operators for very long, no matter what the case. Anti-virii and such are somewhat interesting in the end-system model, but when downtimes need to be scheduled significantly in advance for network operations you either a) prevent infection by much tighter controls at the get-go or b) provide a high-trust way to keep the systems in a known good-state. This, of course, assumes true "bugs" are kept to a minimum. It does raise significant security concerns for those networks that have employees/contractors/etc with turn-over that could leave a parting "gift" in their respective networks. Changing passwords isn't really sufficient anymore. DJ From kgasso-lists at visp.net Mon May 19 15:23:34 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Mon, 19 May 2008 13:23:34 -0700 Subject: [NANOG] Earthlink Relayed Spam Increase In-Reply-To: References: Message-ID: <4831E1C6.5010500@visp.net> Jason J. W. Williams wrote: > We're seeing a marked increase of spam originating from Earthlink mail > servers over the past week and a half. Is anyone else seeing a spike > localized to Earthlink as well? We've seen a fair amount lately. Additionally, a couple of people I assist with administration were having issues due to their use of SORBS and several of Earthlink's mail servers being listed for several days. -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From drew.weaver at thenap.com Mon May 19 15:35:17 2008 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 19 May 2008 16:35:17 -0400 Subject: [NANOG] Installation troubles with GlobalCrossing In-Reply-To: <1211196580.32179.5.camel@matrix.mlan.solnet.ch> References: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> <1211196580.32179.5.camel@matrix.mlan.solnet.ch> Message-ID: The only issue I had with them recently was the aforementioned 5Mbps ICMP rate-limiting on an inappropriately sized circuit and not understanding why I thought it was inappropriate to apply that filter to circuits of any size without any thought to how it would (to a lesser extent things like network performance monitoring systems made by companies such as Avaya (RS) and InterNAP) if the 5Mbps filled up and they began dropping ICMP. (for no reason). -Drew -----Original Message----- From: Erich Hohermuth [mailto:eh at profzone.ch] Sent: Monday, May 19, 2008 7:30 AM To: nanog at nanog.org Subject: Re: [NANOG] Installation troubles with GlobalCrossing Dear list, Thanks to everyone who has respond to me by privat mails. > I just want to ask if anyone else have major troubles to install new or > upgrade services with Global Crossing ? It seems that I'm not the only one who has troubles with installations and trouble tickets in the past 12 months. I also get some offers from competitors which promise to bring up a point two point link within 10 days. Thanks Eric _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From williamsjj at digitar.com Mon May 19 15:37:54 2008 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Mon, 19 May 2008 14:37:54 -0600 Subject: [NANOG] Earthlink Relayed Spam Increase In-Reply-To: <4831E1C6.5010500@visp.net> References: <4831E1C6.5010500@visp.net> Message-ID: I believe it. We generate our own list with temporary (6 hour blocks), and Earthlinks servers seem to be rolling on and off regularly. -J --- Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com E: williamsjj at digitar.com V: 208-343-8520 M: 208-863-0727 F: 208-322-8520 XMPP: williamsjj at digitar.com -----Original Message----- From: Kameron Gasso [mailto:kgasso-lists at visp.net] Sent: Monday, May 19, 2008 2:24 PM To: Jason J. W. Williams Cc: nanog at merit.edu Subject: Re: [NANOG] Earthlink Relayed Spam Increase Jason J. W. Williams wrote: > We're seeing a marked increase of spam originating from Earthlink mail > servers over the past week and a half. Is anyone else seeing a spike > localized to Earthlink as well? We've seen a fair amount lately. Additionally, a couple of people I assist with administration were having issues due to their use of SORBS and several of Earthlink's mail servers being listed for several days. -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 !SIG:4831e28e71591368614419! From pauldotwall at gmail.com Mon May 19 17:03:25 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 19 May 2008 18:03:25 -0400 Subject: [NANOG] Installation troubles with GlobalCrossing In-Reply-To: References: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> <1211196580.32179.5.camel@matrix.mlan.solnet.ch> Message-ID: <620fd17c0805191503t728fdc5p7f82950e9ec0eb93@mail.gmail.com> 5mb limit ingressing/traversing their backbone? Or 5mb limit to their router's control plane? Important to differentiate between the two. I'd call the former totally unacceptable, and actionable per SLA 'till resolved (besides, whoever got taken down by a multi-gigabit PING FLOOD?); the latter is a concerned provider appropriately covering their base (I'd police random ICMP to even less, say 128kb). Paul On 5/19/08, Drew Weaver wrote: > The only issue I had with them recently was the aforementioned 5Mbps > ICMP rate-limiting on an inappropriately sized circuit and not understanding > why I thought it was inappropriate to apply that filter to circuits of any > size without any thought to how it would (to a lesser extent things like > network performance monitoring systems made by companies such as Avaya (RS) > and InterNAP) if the 5Mbps filled up and they began dropping ICMP. (for no > reason). > > -Drew > > -----Original Message----- > From: Erich Hohermuth [mailto:eh at profzone.ch] > Sent: Monday, May 19, 2008 7:30 AM > To: nanog at nanog.org > Subject: Re: [NANOG] Installation troubles with GlobalCrossing > > Dear list, > > Thanks to everyone who has respond to me by privat mails. > >> I just want to ask if anyone else have major troubles to install new or >> upgrade services with Global Crossing ? > > It seems that I'm not the only one who has troubles with installations > and trouble tickets in the past 12 months. I also get some offers from > competitors which promise to bring up a point two point link within 10 > days. > > Thanks > Eric > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > -- Sent from Gmail for mobile | mobile.google.com From morrowc.lists at gmail.com Mon May 19 20:05:37 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 19 May 2008 21:05:37 -0400 Subject: [NANOG] Installation troubles with GlobalCrossing In-Reply-To: <620fd17c0805191503t728fdc5p7f82950e9ec0eb93@mail.gmail.com> References: <1210837085.24740.22.camel@matrix.mlan.solnet.ch> <1211196580.32179.5.camel@matrix.mlan.solnet.ch> <620fd17c0805191503t728fdc5p7f82950e9ec0eb93@mail.gmail.com> Message-ID: <75cb24520805191805x461c21fax9dfcebc16ddc553d@mail.gmail.com> On Mon, May 19, 2008 at 6:03 PM, Paul Wall wrote: > 5mb limit ingressing/traversing their backbone? > > Or 5mb limit to their router's control plane? > > Important to differentiate between the two. I'd call the former > totally unacceptable, and actionable per SLA 'till resolved (besides, > whoever got taken down by a multi-gigabit PING FLOOD?); the latter is seen them.. they can be painful :( a former customer got some large/fragmented icmp flood during a may-day event as I recall. > a concerned provider appropriately covering their base (I'd police > random ICMP to even less, say 128kb). > at 1mbps rate-limited customers complained that 'your link is dropping packets' (when they do a rapid-ping off their edge device with 4000 byte packets... which went over the 1mbps policer). There's certainly some limit to be used, somewhere between 128k -> 2-4mbps. Also, it highly depends on edge platform of course :( -Chris From ge at linuxbox.org Tue May 20 02:31:00 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 20 May 2008 02:31:00 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <4831D0AE.8050400@ai.net> References: <3260A110-46FE-42E6-BB2B-1287476EF3C4@kyx.net> <4831D0AE.8050400@ai.net> Message-ID: On Mon, 19 May 2008, Deepak Jain wrote: > > Wouldn't this level of verification/authentication of running code be a > pretty trivial function via RANCID or similar tool? Absolutely, and it actually makes sense. The problem though is that it is one again an escalation war and counter-inventions keep happening. RANCID will connect remotely and use the local tools to get results, these local tools or their esults can be altered. > I understand *why* we are worried about rootkits on individual servers. On > essentially "closed" platforms this isn't going to be rocket science. > It may seem odd by today's BCPs, but booting up from "golden" images via > write-protected hardware or TFTP or similar is pretty straightforward -- > especially for those of us who run large server farms. That is a neat idea, you mean something like a magic card? Well, the rootkit could still hide in memory, or heck, on the video card if it likes. While XR is not implemented your best bet is reflashing with an updated version, screws up the memory allocations which is apparently a difficult problem to overcome. > A POP or node could certainly keep a few servers around that are a permanent > repository of these items for all the devices that get images. > > If you can't trust the boot rom, well, that's an entirely separate matter. > > I think the issue with rootkits whether server or embedded device is more > about infection vector than the maliciousness that could be caused AFTER a > compromise has occurred. Here is very much disagree with you. Imagine what you can do with a Trojan horse on a computer, say a server. You could, in effective terms, use it as your own. You'd own it. The same is true for a router. You could sniff the network, steal traffic, use it as a bridge to connect to potnetially any part of your network, hide traffic, etc. The potential for attackrs is almosy "cool". Gadi. > > Deepak Jain > > > Dragos Ruiu wrote: >> The question this presentation begs for me... is how many of the folks on >> this list do integrity checking on their routers? >> >> You can no longer say this isn't necessary :-). >> >> I know FX and a few others are working on toolsets for this... >> >> I'll probably have other comments after I see the presentation. >> This development has all sort of implications for binary signing >> requirements, etc... >> >> cheers, >> --dr >> >> -- >> World Security Pros. Cutting Edge Training, Tools, and Techniques >> London, U.K. May 21/22 - 2008 http://cansecwest.com >> pgpkey http://dragos.com/ kyxpgp >> >> >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> >> > From rblayzor.bulk at inoc.net Tue May 20 04:33:55 2008 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Tue, 20 May 2008 05:33:55 -0400 Subject: [NANOG] Fiber Cut at 60 Hudson Message-ID: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> Does anyone know of any NY fiber cuts going on near/around 60 Hudson Street? I have a Level3 DIA Gig-E that's been out for almost 36 hours and each time I call them I get a different answer on what the problem is and exactly how much longer this is going to take to be resolved. We noticed this go down around 7pm EDT on Sunday and the following morning the dark fiber we have going through 60 Hudson took a hit for about an hour on one side of our DWDM ring... Anyone know whats up? -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From michal at krsek.cz Tue May 20 06:06:35 2008 From: michal at krsek.cz (Michal Krsek) Date: Tue, 20 May 2008 13:06:35 +0200 Subject: [NANOG] Unique v6 (video) content References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> Message-ID: <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> Hello, several months ago we have had a discussion about IPv6 content. There has been a proposal that having some adult content IPv6 only should be a good idea. I'm not p0rn hoster, but I'm very close to IP content delivery network for Czech public TV. They have news channel (unfortunatelly for most of you in czech language) running round the clock. So we made available their content over IPv6 and made available TV resolution for IPv6 only. So if you have IPv6, you will get video content at http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). If you have old IP only, you will see this content only in 320x240 (bitrate ~400 Kb/s). This service is experimental, and if you have any ideas, complains or questions, please contact me off the list. Regards Michal From president at ukraine.su Tue May 20 06:52:24 2008 From: president at ukraine.su (Max Tulyev) Date: Tue, 20 May 2008 14:52:24 +0300 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> Message-ID: <4832BB78.50100@ukraine.su> Hello Michael, I'm getting the permanent error message: maxtul at greentheatre ~/temp $ mplayer http://master.nacevi.cz/ct24v6.asp MPlayer dev-SVN-rUNKNOWN-4.1.2 (C) 2000-2008 MPlayer Team CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (Family: 6, Model: 15, Stepping: 13) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Playing http://master.nacevi.cz/ct24v6.asp. Resolving master.nacevi.cz for AF_INET6... Connecting to server master.nacevi.cz[2a02:1d0:1:0:217:a4ff:feaa:e6f3]: 80... STREAM_ASF, URL: http://master.nacevi.cz/ct24v6.asp Resolving master.nacevi.cz for AF_INET6... Connecting to server master.nacevi.cz[2a02:1d0:1:0:217:a4ff:feaa:e6f3]: 80... size_confirm mismatch!: 30835 28271 Error while parsing chunk header Failed, exiting. Resolving master.nacevi.cz for AF_INET6... Connecting to server master.nacevi.cz[2a02:1d0:1:0:217:a4ff:feaa:e6f3]: 80... Cache size set to 320 KBytes Cache fill: 0.10% (323 bytes) Exiting... (End of file) maxtul at greentheatre ~/temp $ links -dump http://master.nacevi.cz/ct24v6.asp Ceska televize (c) 2007 Ceska televize (c) 2007 I'm trying from 2a01:d0:9:0:21c:c0ff:fe23:793f. Michal Krsek wrote: > Hello, > several months ago we have had a discussion about IPv6 content. There has > been a proposal that having some adult content IPv6 only should be a good > idea. > > I'm not p0rn hoster, but I'm very close to IP content delivery network for > Czech public TV. They have news channel (unfortunatelly for most of you in > czech language) running round the clock. > > So we made available their content over IPv6 and made available TV > resolution for IPv6 only. So if you have IPv6, you will get video content at > http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). If you > have old IP only, you will see this content only in 320x240 (bitrate ~400 > Kb/s). > > This service is experimental, and if you have any ideas, complains or > questions, please contact me off the list. > > Regards > Michal > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From rs at seastrom.com Tue May 20 06:56:53 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 20 May 2008 07:56:53 -0400 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> (Michal Krsek's message of "Tue, 20 May 2008 13:06:35 +0200") References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> Message-ID: <86prrhxk6y.fsf@seastrom.com> "Michal Krsek" writes: > Hello, > several months ago we have had a discussion about IPv6 content. There has > been a proposal that having some adult content IPv6 only should be a good > idea. > > I'm not p0rn hoster, but I'm very close to IP content delivery network for > Czech public TV. They have news channel (unfortunatelly for most of you in > czech language) running round the clock. > > So we made available their content over IPv6 and made available TV > resolution for IPv6 only. So if you have IPv6, you will get video content at > http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). If you > have old IP only, you will see this content only in 320x240 (bitrate ~400 > Kb/s). > > This service is experimental, and if you have any ideas, complains or > questions, please contact me off the list. So, we've been native v6 here for a number of years. Figured I'd give this a shot, only to be greeted with: The application VLC quit unexpectedly Mac OS X and other applications are not affected. As long as we're doing forward-looking, brave-new-world stuff, would it be asking too much to say "use h.264 or something else 'standard' for the video"? Best, ---Rob From nanog at daork.net Tue May 20 07:01:55 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 21 May 2008 00:01:55 +1200 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <86prrhxk6y.fsf@seastrom.com> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <86prrhxk6y.fsf@seastrom.com> Message-ID: <84B89070-B40D-4077-BAFD-64880686CBE7@daork.net> On 20/05/2008, at 11:56 PM, Robert E. Seastrom wrote: > "Michal Krsek" writes: > >> Hello, >> several months ago we have had a discussion about IPv6 content. >> There has >> been a proposal that having some adult content IPv6 only should be >> a good >> idea. >> >> I'm not p0rn hoster, but I'm very close to IP content delivery >> network for >> Czech public TV. They have news channel (unfortunatelly for most of >> you in >> czech language) running round the clock. >> >> So we made available their content over IPv6 and made available TV >> resolution for IPv6 only. So if you have IPv6, you will get video >> content at >> http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). >> If you >> have old IP only, you will see this content only in 320x240 >> (bitrate ~400 >> Kb/s). >> >> This service is experimental, and if you have any ideas, complains or >> questions, please contact me off the list. > > So, we've been native v6 here for a number of years. Figured I'd give > this a shot, only to be greeted with: > > The application VLC quit unexpectedly > > Mac OS X and other applications are not affected. Works fine on VLC/OS X for me - but not with flip4mac - flip4mac does IPv4 only it seems. -- Nathan Ward From giulianocm at uol.com.br Tue May 20 07:02:58 2008 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Tue, 20 May 2008 09:02:58 -0300 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> Message-ID: <4832BDF2.4000505@uol.com.br> Michal, I can see the video here from Brazil. The quality is very good, but I am using the Go6 Tunnel to watch it. Sometimes we have some interruption, but in general it is ok. Thanks, Giuliano > Hello, > several months ago we have had a discussion about IPv6 content. There has > been a proposal that having some adult content IPv6 only should be a good > idea. > > I'm not p0rn hoster, but I'm very close to IP content delivery network for > Czech public TV. They have news channel (unfortunatelly for most of you in > czech language) running round the clock. > > So we made available their content over IPv6 and made available TV > resolution for IPv6 only. So if you have IPv6, you will get video content at > http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). If you > have old IP only, you will see this content only in 320x240 (bitrate ~400 > Kb/s). > > This service is experimental, and if you have any ideas, complains or > questions, please contact me off the list. > > Regards > Michal > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 3113 (20080520) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > From marc at let.de Tue May 20 08:19:01 2008 From: marc at let.de (Marc Manthey) Date: Tue, 20 May 2008 15:19:01 +0200 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <4832BDF2.4000505@uol.com.br> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BDF2.4000505@uol.com.br> Message-ID: <305AECEB-F6E0-4AFD-B6AC-41726FC32479@let.de> hello, works on videolan osx leopard , just a few seconds then it stops , because my connections is not good enough 15:12:25.779523 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: S 613680145:613680145(0) win 65535 15:12:25.852420 IP6 fe80::20f:66ff:fea7:2d48 > ff02::1:ff79:f1e: ICMP6, neighbor solicitation, who has mini.stattfernsehen.com, length 32 15:12:25.852549 IP6 mini.local > fe80::20f:66ff:fea7:2d48: ICMP6, neighbor advertisement, tgt is mini.stattfernsehen.com, length 32 15:12:25.853012 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > mini.stattfernsehen.com.55362: S 963848731:963848731(0) ack 613680146 win 16384 15:12:25.853115 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 1 win 65535 15:12:25.855914 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 1:217(216) ack 1 win 65535 15:12:25.932982 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > mini.stattfernsehen.com.55362: P 1:145(144) ack 217 win 16864 15:12:25.933132 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 145 win 65535 15:12:25.933552 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 217:329(112) ack 145 win 65535 15:12:26.009816 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > mini.stattfernsehen.com.55362: P 145:241(96) ack 329 win 16752 15:12:26.009943 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 241 win 65535 15:12:26.010238 IP6 mini.stattfernsehen.com.55362 > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 329:433(104) ack 241 win 65535 first time that i ever saw a ipv6 stream by the way !!!! thank you very much !!! Marc >> http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). >> If you >> have old IP only, you will see this content only in 320x240 >> (bitrate ~400 >> Kb/s). -- "Use your imagination not to scare yourself to death but to inspire yourself to life." Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 K?ln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc at kgraff.net blog : http://www.let.de ipv6 http://www.stattfernsehen.com xing : https://www.xing.com/profile/Marc_Manthey From michal at krsek.cz Tue May 20 09:22:09 2008 From: michal at krsek.cz (Michal Krsek) Date: Tue, 20 May 2008 16:22:09 +0200 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <305AECEB-F6E0-4AFD-B6AC-41726FC32479@let.de> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BDF2.4000505@uol.com.br> <305AECEB-F6E0-4AFD-B6AC-41726FC32479@let.de> Message-ID: <4832DE91.3020508@krsek.cz> Dear Marc, if you (or other users) have not enough capacity for watching 1.5 Mb/s stream, you can use lower (comodity) bitrate. You can use comodity URLs: http://master.nacevi.cz/asx/ct24livewh.asx (400 Kb/s) http://master.nacevi.cz/asx/ct24livewl.asx (225 Kb/s) Regards Michal P.S: Replacing "master" with "master6" will drive you to IPv6 only streams. P.P.S: Last three RIPE meetings have been broadcasted via IPv6 as well. > hello, > > works on videolan osx leopard , just a few seconds then it stops , > because my connections is not good enough > > 15:12:25.779523 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: S 613680145:613680145(0) > win 65535 [|tcp]> > 15:12:25.852420 IP6 fe80::20f:66ff:fea7:2d48 > ff02::1:ff79:f1e: > ICMP6, neighbor solicitation, who has mini.stattfernsehen.com, length 32 > 15:12:25.852549 IP6 mini.local > fe80::20f:66ff:fea7:2d48: ICMP6, > neighbor advertisement, tgt is mini.stattfernsehen.com, length 32 > 15:12:25.853012 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > > mini.stattfernsehen.com.55362: S 963848731:963848731(0) ack 613680146 > win 16384 > 15:12:25.853115 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 1 win 65535 > 15:12:25.855914 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 1:217(216) ack 1 win > 65535 > 15:12:25.932982 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > > mini.stattfernsehen.com.55362: P 1:145(144) ack 217 win 16864 > 15:12:25.933132 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 145 win 65535 > 15:12:25.933552 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 217:329(112) ack 145 > win 65535 > 15:12:26.009816 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > > mini.stattfernsehen.com.55362: P 145:241(96) ack 329 win 16752 > 15:12:26.009943 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 241 win 65535 > 15:12:26.010238 IP6 mini.stattfernsehen.com.55362 > > 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 329:433(104) ack 241 > win 65535 > > first time that i ever saw a ipv6 stream by the way !!!! > > thank you very much !!! > > Marc > > >>> http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/s). >>> If you >>> have old IP only, you will see this content only in 320x240 >>> (bitrate ~400 >>> Kb/s). >>> > > -- > "Use your imagination not to scare yourself to death > but to inspire yourself to life." > Les enfants teribbles - research and deployment > Marc Manthey - head of research and innovation > Hildeboldplatz 1a D - 50672 K?ln - Germany > Tel.:0049-221-3558032 > Mobil:0049-1577-3329231 > jabber :marc at kgraff.net > blog : http://www.let.de > ipv6 http://www.stattfernsehen.com > xing : https://www.xing.com/profile/Marc_Manthey > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > From ge at linuxbox.org Tue May 20 09:27:39 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 20 May 2008 09:27:39 -0500 (CDT) Subject: [NANOG] An account of the Estonian Internet War Message-ID: About a year ago after coming back from Estonia I promised I'd send in an account of the Estonian "war". The postmortem analysis and recommendations I later wrote for the Estonian CERT are not yet public. A few months ago I wrote an article for the Georgetown Journal of International Affairs, covering the story of what happened there, in depth. The journal owns the copyright so I had no way of sending that along either. I wasn't about to email saying "go buy a copy". Mostly silly articles kept popping up with misguided to wrong information about what happened in Estonia, and when an Estonian student was arrested for participating, some in our community even jumped up to say "it was just some student". Ridiculous. This is the "war" that made politicians aware of cyber security and entire countries scared, NATO to "respond" and the US to send in "help". It deserved a better understanding for that alone, whatever actually happened there. I was there to help, but I just deliver the account. The heroes of the story are the Estonian ISP and banking security professionals and the CERT (Hillar Aarelaid and Aivar Jaakson). Apparently the Journal made my article available in PDF form by a third party: Battling Botnets and Online Mobs Estonia's Defense Efforts during the Internet War URL: http://www.ciaonet.org/journals/gjia/v9i1/0000699.pdf It is not technical, I hope you find it useful. Gadi Evron. From virendra.rode at gmail.com Tue May 20 10:19:14 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Tue, 20 May 2008 08:19:14 -0700 Subject: [NANOG] Fiber Cut at 60 Hudson In-Reply-To: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> Message-ID: <4832EBF2.80404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Robert Blayzor wrote: > Does anyone know of any NY fiber cuts going on near/around 60 Hudson > Street? I have a Level3 DIA Gig-E that's been out for almost 36 hours > and each time I call them I get a different answer on what the problem > is and exactly how much longer this is going to take to be resolved. > We noticed this go down around 7pm EDT on Sunday and the following > morning the dark fiber we have going through 60 Hudson took a hit for > about an hour on one side of our DWDM ring... > > Anyone know whats up? > - --------------------------- Possible bad module / fiber. Techs are in route back to Albany site. ETA 1 hr. On a different note, outages mailing list (outages at isotf.org) should be up / running by this week at the latest. We are finishing up on the last pieces (hw/software). regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMuvypbZvCIJx1bcRAoiSAJwK7wptXgTAxtokgKosCPC3L6fHTwCgjt6u HKREsGqHELOS0XAmzOMjjuA= =6kAb -----END PGP SIGNATURE----- From kamal.mehta at us.ibm.com Tue May 20 11:01:29 2008 From: kamal.mehta at us.ibm.com (Kamal Mehta) Date: Tue, 20 May 2008 10:01:29 -0600 Subject: [NANOG] AUTO: Kamal Mehta is on vacation (returning 05/21/2008) Message-ID: I am out of the office until 05/21/2008. I am on vacation and will not have access to e-mail. I will try to reply to your message on my return. If you need immediate assistance, please call the IBM AOD Service Center at 877-737-3700. Note: This is an automated response to your message "NANOG Digest, Vol 4, Issue 49" sent on 5/20/08 6:00:02. This is the only notification you will receive while this person is away. From kamal.mehta at us.ibm.com Tue May 20 11:05:38 2008 From: kamal.mehta at us.ibm.com (Kamal Mehta) Date: Tue, 20 May 2008 10:05:38 -0600 Subject: [NANOG] AUTO: Kamal Mehta is on vacation (returning 05/21/2008) Message-ID: I am out of the office until 05/21/2008. I am on vacation and will not have access to e-mail. I will try to reply to your message on my return. If you need immediate assistance, please call the IBM AOD Service Center at 877-737-3700. Note: This is an automated response to your message "NANOG Digest, Vol 4, Issue 49" sent on 5/20/08 6:00:02. This is the only notification you will receive while this person is away. From herrin-nanog at dirtside.com Tue May 20 14:07:17 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 20 May 2008 15:07:17 -0400 Subject: [NANOG] Multihoming for small frys? Message-ID: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Hi folks, An administrative question about multihoming: I have a client who needs to multihome with multiple vendors for reliability purposes, currently in the Northern Virginia area and later on with a fail-over site, probably in Hawaii. They have only a very modest need for bandwidth and addresses (think: T1's and a few dozen servers) but they have to have BGP multihoming and can afford to pay for it. The last I heard, the way to make this happen was: Find a service provider with IP blocks available in ARIN's set of /8's that permit /24 announcements (networks 199, 204-207), buy a circuit and request a /24 for multihoming. Then buy circuits from other providers using that ISP's /24 and an AS# from ARIN. Is that still the way to make it happen? Are there alternate approaches (besides DNS games) that I should consider? Who should I talk to? Certain well-known companies seem incapable of discussing service that isn't cookie-cutter. Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drais at icantclick.org Tue May 20 14:32:00 2008 From: drais at icantclick.org (david raistrick) Date: Tue, 20 May 2008 19:32:00 +0000 (UTC) Subject: [NANOG] Multihoming for small frys? In-Reply-To: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Message-ID: On Tue, 20 May 2008, William Herrin wrote: > The last I heard, the way to make this happen was: Find a service > provider with IP blocks available in ARIN's set of /8's that permit ....that part isn't required. Generally any /24 will do in my experience except for specific cases. Other than that, you've got it about right. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From dholmes at mwdh2o.com Tue May 20 15:28:59 2008 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 20 May 2008 13:28:59 -0700 Subject: [NANOG] Multihoming for small frys? In-Reply-To: References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E06D2B476@usmsxt104.mwd.h2o> If the same /24 is announced from 2 different sites, the problem we have run into is that using the longest prefix method is the only way to guarantee that some ISPs will not use some method such as private peering to cause asymmetric routing back to the small fry. -----Original Message----- From: david raistrick [mailto:drais at icantclick.org] Sent: Tuesday, May 20, 2008 12:32 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: [NANOG] Multihoming for small frys? On Tue, 20 May 2008, William Herrin wrote: > The last I heard, the way to make this happen was: Find a service > provider with IP blocks available in ARIN's set of /8's that permit ....that part isn't required. Generally any /24 will do in my experience except for specific cases. Other than that, you've got it about right. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From marc at let.de Tue May 20 17:18:44 2008 From: marc at let.de (Marc Manthey) Date: Wed, 21 May 2008 00:18:44 +0200 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <4832DE91.3020508@krsek.cz> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BDF2.4000505@uol.com.br> <305AECEB-F6E0-4AFD-B6AC-41726FC32479@let.de> <4832DE91.3020508@krsek.cz> Message-ID: <9C0BE801-573B-49A3-8B7E-5F8327CAA08F@let.de> Am 20.05.2008 um 16:22 schrieb Michal Krsek: > Dear Marc, > if you (or other users) have not enough capacity for watching 1.5 Mb/ > s stream, you can use lower (comodity) bitrate. You can use comodity > URLs: > > http://master.nacevi.cz/asx/ct24livewh.asx (400 Kb/s) > > http://master.nacevi.cz/asx/ct24livewl.asx (225 Kb/s) > > Regards > Michal exellent Michal is this multicasted ? what server software you use for ipv6 streaming ? is there a way to stream via rtp/ rtsp over ipv6 aswell ;) ? > P.S: Replacing "master" with "master6" will drive you to IPv6 only > streams. > > P.P.S: Last three RIPE meetings have been broadcasted via IPv6 as > well. cheers Marc >> hello, >> >> works on videolan osx leopard , just a few seconds then it stops , >> because my connections is not good enough >> >> 15:12:25.779523 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: S >> 613680145:613680145(0) win 65535 > 2,nop,nop,timestamp 603390695 0,sackOK, [|tcp]> >> 15:12:25.852420 IP6 fe80::20f:66ff:fea7:2d48 > ff02::1:ff79:f1e: >> ICMP6, neighbor solicitation, who has mini.stattfernsehen.com, >> length 32 >> 15:12:25.852549 IP6 mini.local > fe80::20f:66ff:fea7:2d48: ICMP6, >> neighbor advertisement, tgt is mini.stattfernsehen.com, length 32 >> 15:12:25.853012 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > >> mini.stattfernsehen.com.55362: S 963848731:963848731(0) ack >> 613680146 win 16384 >> 15:12:25.853115 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 1 win 65535 >> 15:12:25.855914 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 1:217(216) ack 1 >> win 65535 >> 15:12:25.932982 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > >> mini.stattfernsehen.com.55362: P 1:145(144) ack 217 win 16864 >> 15:12:25.933132 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 145 win 65535 >> 15:12:25.933552 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 217:329(112) ack >> 145 win 65535 >> 15:12:26.009816 IP6 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming > >> mini.stattfernsehen.com.55362: P 145:241(96) ack 329 win 16752 >> 15:12:26.009943 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: . ack 241 win 65535 >> 15:12:26.010238 IP6 mini.stattfernsehen.com.55362 > >> 2a02:1d0:2::217:a4ff:feaa:e6e7.ms-streaming: P 329:433(104) ack >> 241 win 65535 >> >> first time that i ever saw a ipv6 stream by the way !!!! >> >> thank you very much !!! >> >> Marc >> >> >>>> http://master.nacevi.cz/ct24v6.asp in 720x576 (bitrate ~1.5 Mb/ >>>> s). If you >>>> have old IP only, you will see this content only in 320x240 >>>> (bitrate ~400 >>>> Kb/s). >>>> >> >> -- >> "Use your imagination not to scare yourself to death >> but to inspire yourself to life." >> Les enfants teribbles - research and deployment >> Marc Manthey - head of research and innovation >> Hildeboldplatz 1a D - 50672 K?ln - Germany >> Tel.:0049-221-3558032 >> Mobil:0049-1577-3329231 >> jabber :marc at kgraff.net >> blog : http://www.let.de >> ipv6 http://www.stattfernsehen.com >> xing : https://www.xing.com/profile/Marc_Manthey >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog >> From robert at ufl.edu Tue May 20 17:36:13 2008 From: robert at ufl.edu (Robert D. Scott) Date: Tue, 20 May 2008 18:36:13 -0400 Subject: [NANOG] Multihoming for small frys? In-Reply-To: References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Message-ID: <000b01c8bac9$e9279f60$01d4e40a@orlinter.net> The /24 address block has to be portable, an assignment, or the owner needs to grant the secondary advertiser an LOA to readvertise that block. The LOA is pretty common, but some ISPs may require you to renumber to get into address space they will permit you to use and multihome. As always your mileage may vary. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Receptionist University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 -----Original Message----- From: david raistrick [mailto:drais at icantclick.org] Sent: Tuesday, May 20, 2008 3:32 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: [NANOG] Multihoming for small frys? On Tue, 20 May 2008, William Herrin wrote: > The last I heard, the way to make this happen was: Find a service > provider with IP blocks available in ARIN's set of /8's that permit ....that part isn't required. Generally any /24 will do in my experience except for specific cases. Other than that, you've got it about right. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From andy at xecu.net Tue May 20 23:05:05 2008 From: andy at xecu.net (Andy Dills) Date: Wed, 21 May 2008 00:05:05 -0400 (EDT) Subject: [NANOG] Multihoming for small frys? In-Reply-To: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Message-ID: <20080520233017.H55620@shell.xecu.net> On Tue, 20 May 2008, William Herrin wrote: > Hi folks, > > An administrative question about multihoming: > > I have a client who needs to multihome with multiple vendors for > reliability purposes, currently in the Northern Virginia area and > later on with a fail-over site, probably in Hawaii. They have only a > very modest need for bandwidth and addresses (think: T1's and a few > dozen servers) but they have to have BGP multihoming and can afford to > pay for it. > > The last I heard, the way to make this happen was: Find a service > provider with IP blocks available in ARIN's set of /8's that permit > /24 announcements (networks 199, 204-207), buy a circuit and request a > /24 for multihoming. Then buy circuits from other providers using that > ISP's /24 and an AS# from ARIN. > > Is that still the way to make it happen? Are there alternate > approaches (besides DNS games) that I should consider? They should just get their own /22 from ARIN. If the future fail-over site doesn't help them show a /23's worth of justification, break out the ultimate fudge factor: SSL. Yes, I know, some would argue this isn't responsible usage of community resources. However, if I was representing the interests of a company whose existence relies on working connectivity, my biggest concern would be provider independance. Altruism is something I encourage my competitors to indulge in. In fact, the increasing value and decreasing pool of prefixes should motivate any proper capitalist to air on the side of being greedy: just as they aren't making any more land, they aren't making any more IP(v4) space. My gut instinct has been telling me for half a decade that prefixes will get commoditized long before IPv6 settles in, and if I was representing the interests of a company who was in the situation you describe, I would certainly want to prepare for that possibility. ARIN really should allow direct allocation of /24s to multi-homed organizations. It wouldn't increase the table size, and it would reduce the wasteful (best common) practice I describe above. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- From tvarriale at comcast.net Tue May 20 23:31:45 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Tue, 20 May 2008 23:31:45 -0500 Subject: [NANOG] Multihoming for small frys? References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> Message-ID: <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> AFAIK, ARIN doesn't give out /22s anymore. Last time I went to the well...it's was a /20 or better. tv ----- Original Message ----- From: "Andy Dills" To: "William Herrin" Cc: Sent: Tuesday, May 20, 2008 11:05 PM Subject: Re: [NANOG] Multihoming for small frys? > On Tue, 20 May 2008, William Herrin wrote: > >> Hi folks, >> >> An administrative question about multihoming: >> >> I have a client who needs to multihome with multiple vendors for >> reliability purposes, currently in the Northern Virginia area and >> later on with a fail-over site, probably in Hawaii. They have only a >> very modest need for bandwidth and addresses (think: T1's and a few >> dozen servers) but they have to have BGP multihoming and can afford to >> pay for it. >> >> The last I heard, the way to make this happen was: Find a service >> provider with IP blocks available in ARIN's set of /8's that permit >> /24 announcements (networks 199, 204-207), buy a circuit and request a >> /24 for multihoming. Then buy circuits from other providers using that >> ISP's /24 and an AS# from ARIN. >> >> Is that still the way to make it happen? Are there alternate >> approaches (besides DNS games) that I should consider? > > They should just get their own /22 from ARIN. > > If the future fail-over site doesn't help them show a /23's worth of > justification, break out the ultimate fudge factor: SSL. > > Yes, I know, some would argue this isn't responsible usage of community > resources. > > However, if I was representing the interests of a company whose existence > relies on working connectivity, my biggest concern would be provider > independance. Altruism is something I encourage my competitors to indulge > in. In fact, the increasing value and decreasing pool of prefixes should > motivate any proper capitalist to air on the side of being greedy: just as > they aren't making any more land, they aren't making any more IP(v4) > space. > > My gut instinct has been telling me for half a decade that prefixes will > get commoditized long before IPv6 settles in, and if I was representing > the interests of a company who was in the situation you describe, I would > certainly want to prepare for that possibility. > > ARIN really should allow direct allocation of /24s to multi-homed > organizations. It wouldn't increase the table size, and it would reduce > the wasteful (best common) practice I describe above. > > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog From nanog at daork.net Tue May 20 23:42:00 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 21 May 2008 16:42:00 +1200 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> Message-ID: <83E1E636-FE3F-404F-8547-D4267031E218@daork.net> On 21/05/2008, at 4:31 PM, Tony Varriale wrote: > AFAIK, ARIN doesn't give out /22s anymore. > > Last time I went to the well...it's was a /20 or better. Interesting.. I've had /24s for customers before, with APNIC's multi-homing assignments. http://www.apnic.net/info/faq/multihoming_faq.html There is no absolute maximum or minimum assignment size, but please note that APNIC cannot guarantee the routability of any assignment it makes. Assignments less than /24 are not practical and will generally be filtered. If you are close to meeting the minimum allocation size (/ 21), you may find it more economical to become an APNIC member and apply for a portable allocation using the APNIC IPv4 ISP request form. Note that you must be the end user of the space, as it is assigned not allocated. -- Nathan Ward From michal at krsek.cz Wed May 21 01:02:51 2008 From: michal at krsek.cz (Michal Krsek) Date: Wed, 21 May 2008 08:02:51 +0200 Subject: [NANOG] Unique v6 (video) content References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BDF2.4000505@uol.com.br><305AECEB-F6E0-4AFD-B6AC-41726FC32479@let.de><4832DE91.3020508@krsek.cz> <9C0BE801-573B-49A3-8B7E-5F8327CAA08F@let.de> Message-ID: <004301c8bb09$7f76efe0$6401a8c0@w2lan.cesnet.cz> Hi Marc, > > if you (or other users) have not enough capacity for watching 1.5 Mb/ > > s stream, you can use lower (comodity) bitrate. You can use comodity > > URLs: > > > > http://master.nacevi.cz/asx/ct24livewh.asx (400 Kb/s) > > > > http://master.nacevi.cz/asx/ct24livewl.asx (225 Kb/s) > > exellent Michal > > is this multicasted ? No it is not. I have no reliable access to mbone and multicast penetration on public Internet here in central europe is "not very wide". So it makes no sense to deal with multicast. Rather I'm investing my time to support IPv6, this looks like it has more perspective :-) > what server software you use for ipv6 streaming ? Windows Media Server on top of POS (Picture Operating System - WM 2003 server). > is there a way to stream via rtp/ rtsp over ipv6 aswell ;) ? WM is serving data over rtsp as well as over http. ASX file is only pointer to the stream. As I understand the technology, server will negotiate with your client and they try to use ports in following order 1775 (mms) -> 554 (rtsp) -> 80 (http). Regards Michal From andy at xecu.net Wed May 21 01:53:27 2008 From: andy at xecu.net (Andy Dills) Date: Wed, 21 May 2008 02:53:27 -0400 (EDT) Subject: [NANOG] Multihoming for small frys? In-Reply-To: <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> Message-ID: <20080521025010.N55620@shell.xecu.net> On Tue, 20 May 2008, Tony Varriale wrote: > AFAIK, ARIN doesn't give out /22s anymore. > > Last time I went to the well...it's was a /20 or better. Nah, it's /22 for multi-homed networks, /20 for single-homed. http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html 4.3.2.2 Multihomed Connection For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /22. If assignments smaller than a /22 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose. Are there really networks who can justify a /20 that aren't multi-homed? The mind boggles. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- From stas at FreeBSD.org Wed May 21 06:59:45 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Wed, 21 May 2008 15:59:45 +0400 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <4832BB78.50100@ukraine.su> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BB78.50100@ukraine.su> Message-ID: <20080521155945.797210ba.stas@FreeBSD.org> On Tue, 20 May 2008 14:52:24 +0300 Max Tulyev mentioned: > Hello Michael, > > I'm getting the permanent error message: > Works fine here. You should try different URL. The page you're requesting contains an actual URL to the video, http://cdn4.nacevi.cz//CT24-PAL in IPv6 case. -- Stanislav Sedov ST4096-RIPE From michal at krsek.cz Wed May 21 08:52:38 2008 From: michal at krsek.cz (Michal Krsek) Date: Wed, 21 May 2008 15:52:38 +0200 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <20080521155945.797210ba.stas@FreeBSD.org> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BB78.50100@ukraine.su> <20080521155945.797210ba.stas@FreeBSD.org> Message-ID: <48342926.3050704@krsek.cz> >> Hello Michael, >> >> I'm getting the permanent error message: >> > > Works fine here. You should try different URL. The page you're > requesting contains an actual URL to the video, > http://cdn4.nacevi.cz//CT24-PAL in IPv6 case. > > Server name is generated dynamically - depends on your IP/IPv6 address. Not a rocket science behind :-) Regards Michal From sdhillon at decarta.com Wed May 21 10:56:37 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Wed, 21 May 2008 08:56:37 -0700 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <48342926.3050704@krsek.cz> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BB78.50100@ukraine.su> <20080521155945.797210ba.stas@FreeBSD.org> <48342926.3050704@krsek.cz> Message-ID: <48344635.7040309@decarta.com> I wonder when IPv6porn.com is coming online. We're all waiting on Kevin Day @ Your.org. The latest mailing list updated was positive [This morning 5 AM PST8PDT]. Seems DNS has dissapeared for it though. It should give a decent boost to IPv6 traffic. We're all going to have a fun time dealing with this once Your.org breaks out IPv6. :-) Michal Krsek wrote: > >>> Hello Michael, >>> >>> I'm getting the permanent error message: >>> >> >> Works fine here. You should try different URL. The page you're >> requesting contains an actual URL to the video, >> http://cdn4.nacevi.cz//CT24-PAL in IPv6 case. >> >> > > Server name is generated dynamically - depends on your IP/IPv6 address. > > Not a rocket science behind :-) > > Regards > Michal > > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From toasty at dragondata.com Wed May 21 11:11:56 2008 From: toasty at dragondata.com (Kevin Day) Date: Wed, 21 May 2008 11:11:56 -0500 Subject: [NANOG] Unique v6 (video) content In-Reply-To: <48344635.7040309@decarta.com> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <00a101c8ba69$9e883c40$4701a8c0@w2lan.cesnet.cz> <4832BB78.50100@ukraine.su> <20080521155945.797210ba.stas@FreeBSD.org> <48342926.3050704@krsek.cz> <48344635.7040309@decarta.com> Message-ID: <8A63866A-D054-4CA9-BBA7-4D2CB205114C@dragondata.com> On May 21, 2008, at 10:56 AM, Sargun Dhillon wrote: > I wonder when IPv6porn.com is coming online. We're all waiting on > Kevin > Day @ Your.org. It honestly is coming soon! :) As I mentioned on the mailing list ( http://mail.your.org/pipermail/v6test/2008-May/000065.html ), there are some copyright clearance issues causing a bit of a delay. Once that's resolved, we'll do a bit of testing with those willing to help, then launch. > The latest mailing list updated was positive [This > morning 5 AM PST8PDT]. Seems DNS has dissapeared for it though. In preparation for launch, all the "real" domains are being moved to their correct IPs. Info about the project itself is still available at http://www.ipv6experiment.com . > It should give a decent boost to IPv6 traffic. If you want advance warning of a decent amount (many gbps) of v6 traffic being dumped on the world, sign up for the mailing list for the countdown. We've got some major mainstream media exposure going to happen after we're live that should bring a lot of public attention to v6. > We're all going to have a > fun time dealing with this once Your.org breaks out IPv6. :-) -- Kevin From psirt at cisco.com Wed May 21 11:00:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 21 May 2008 18:00:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Secure Shell Denial of Service Message-ID: <200805211801.ssh@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Secure Shell Denial of Service Vulnerabilities Advisory ID: cisco-sa-20080521-ssh http://www.cisco.com/warp/public/707/cisco-sa-20080521-ssh.shtml Revision 1.0 For Public Release 2008 May 21 1600 UTC (GMT) +-------------------------------------------------------------------- Summary ======= The Secure Shell server (SSH) implementation in Cisco IOS contains multiple vulnerabilities that allow unauthenticated users the ability to generate a spurious memory access error or, in certain cases, reload the device. The IOS SSH server is an optional service that is disabled by default, but its use is highly recommended as a security best practice for management of Cisco IOS devices. SSH can be configured as part of the AutoSecure feature in the initial configuration of IOS devices, AutoSecure run after initial configuration, or manually. Devices that are not configured to accept SSH connections are not affected by these vulnerabilities. Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-1159 has been assigned to this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080521-ssh.shtm Affected Products ================= Vulnerable Products +------------------ Cisco devices running certain 12.4-based IOS releases and configured to be managed via SSH may be affected by this issue. The IOS secure shell server is disabled by default. To determine if SSH is enabled, use the show ip ssh command. Router#show ip ssh SSH Enabled - version 2.0 Authentication timeout: 120 secs; Authentication retries: 3 The previous output shows that SSH is enabled on this device and that the SSH protocol major version that is being supported is 2.0. If the text "SSH Disabled" is displayed, the device is not vulnerable. Possible values for the SSH protocol version reported by IOS are: * 1.5: only SSH protocol version 1 is enabled * 1.99: SSH protocol version 2 with SSH protocol version 1 compatibility enabled * 2.0: only SSH protocol version 2 is enabled For more information about SSH versions in IOS, please check the following URL: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_ssh2.html The SSH server is not available in all IOS images. Devices that do not support SSH are not vulnerable. Please consult the table of fixed software in the Software Version and Fixes section for the specific 12.4-based IOS releases that are affected. To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". The image name will be displayed between parentheses on the next line of output followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running IOS release 12.4(17): Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(17), RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Fri 07-Sep-07 16:05 by prod_rel_team ROM: System Bootstrap, Version 12.2(8r) [cmong 8r], RELEASE SOFTWARE (fc1) Router uptime is 1 week, 5 hours, 5 minutes System returned to ROM by power-on System image file is "flash:c2600-adventerprisek9-mz.124-17.bin" Additional information about Cisco IOS release naming is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Cisco devices that do not run IOS are not affected. Cisco IOS devices that do not have the SSH server feature enabled are not affected. IOS-XR images are not affected. The following IOS release trains are not affected: * 10-based releases * 11-based releases * 12.0-based releases * 12.1-based releases * 12.2-based releases * 12.3-based releases IOS releases prior to 12.4(7), 12.4(13d)JA, and 12.4(9)T are not affected by this vulnerability. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= Secure shell (SSH) was developed as a secure replacement for the telnet, ftp, rlogin, rsh, and rcp protocols, which allow for the remote access of devices. The main difference between SSH and older protocols is that SSH provides strong authentication, guarantees confidentiality, and uses encrypted transactions. The server side of the SSH implementation in Cisco IOS contains multiple vulnerabilities that allow an unauthenticated user to generate a spurious memory access or, in certain cases, reload the device. If the attacker is able to reload the device, these vulnerabilities could be repeatedly exploited to cause an extended Denial of Service (DoS) condition. A device with the SSH server enabled is vulnerable. These vulnerabilities are documented in Cisco Bug IDs: * CSCsk42419 ( registered customers only) * CSCsk60020 ( registered customers only) * CSCsh51293 ( registered customers only) Vulnerability Scoring Details ============================= Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss * CSCsk42419 - SSHv2 spurious memory access CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCsk60020 - SSHv2 spurious memory access CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCsh51293 - Spurious memory access when SSH packets received CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of these vulnerabilities may result in a spurious memory access or, in certain cases, reload the device potentially resulting in a DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild" and "Maintenance" columns. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label). For more information on the terms "Rebuild" and "Maintenance," consult the following URL: http://www.cisco.com/warp/public/620/1.html IOS releases prior to 12.4(7), 12.4(13d)JA, and 12.4(9)T are not affected by this vulnerability. +----------------------------------------+ | Major | Availability of Repaired | | Release | Releases | |------------+---------------------------| | Affected | First Fixed | Recommended | | 12.0-Based | Release | Release | | Releases | | | |----------------------------------------| | There are no affected 12.0 based | | releases | |----------------------------------------| | Affected | First Fixed | Recommended | | 12.1-Based | Release | Release | | Releases | | | |----------------------------------------| | There are no affected 12.1 based | | releases | |----------------------------------------| | Affected | First Fixed | Recommended | | 12.2-Based | Release | Release | | Releases | | | |----------------------------------------| | There are no affected 12.2 based | | releases | |----------------------------------------| | Affected | First Fixed | Recommended | | 12.3-Based | Release | Release | | Releases | | | |----------------------------------------| | There are no affected 12.3 based | | releases | |----------------------------------------| | Affected | First Fixed | Recommended | | 12.4-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | 12.4(13f) | | | | | | | | 12.4(16b) | | | 12.4 | | 12.4(18b) | | | 12.4(17a) | | | | | | | | 12.4(18) | | |------------+-------------+-------------| | | Only 12.4 | | | | (13d)JA and | | | | 12.4(13d) | | | | JA1 are | | | 12.4JA | vulnerable, | 12.4(16b) | | | all other | JA3 | | | 12.4JA | | | | releases | | | | are not | | | | affected. | | |------------+-------------+-------------| | 12.4JK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4MD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4MR | 12.4(16)MR2 | 12.4(16)MR | |------------+-------------+-------------| | 12.4SW | 12.4(15)SW1 | 12.4(15)SW1 | |------------+-------------+-------------| | | 12.4(9)T6 | | | | | | | | 12.4(11)T4 | | | 12.4T | | 12.4(15)T5 | | | 12.4(15)T2 | | | | | | | | 12.4(20)T | | |------------+-------------+-------------| | 12.4XA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XD | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.4XE | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.4XF | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | 12.4XG | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.4XJ | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.4XK | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | 12.4XL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XM | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XN | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XT | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XV | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.4XW | 12.4(11)XW6 | 12.4(11)XW6 | |------------+-------------+-------------| | 12.4XY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XZ | Not | | | | Vulnerable | | +----------------------------------------+ Workarounds =========== If disabling the IOS SSH Server is not feasible, the following workarounds may be useful to some customers in their environments. Telnet +----- Telnet is not vulnerable to the issue described in this advisory and may be used as an insecure alternative to SSH. Telnet does not encrypt the authentication information or data; therefore, it should only be enabled for trusted local networks. VTY Access Class +--------------- It is possible to limit the exposure of the Cisco device by applying a VTY access class to allow only known, trusted hosts to connect to the device via SSH. For more information on restricting traffic to VTYs, please consult: http://cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a00800873c8.html#wp1017389 The following example permits access to VTYs from the 192.168.1.0/24 netblock and the single IP address 172.16.1.2 while denying access from anywhere else: Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255 Router(config)# access-list 1 permit host 172.16.1.2 Router(config)# line vty 0 4 Router(config-line)# access-class 1 in Different Cisco platforms support different numbers of terminal lines. Check your device's configuration to determine the correct number of terminal lines for your platform. Infrastructure ACLs (iACL) +------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic that should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The ACL example shown below should be included as part of the deployed infrastructure access-list, which will protect all devices with IP addresses in the infrastructure IP address range. A sample access list for devices running Cisco IOS is below: !--- Permit SSH services from trusted hosts destined !--- to infrastructure addresses. access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 22 !--- Deny SSH packets from all other sources destined to infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES MASK eq 22 !--- Permit all other traffic to transit the device. access-list 150 permit IP any any interface serial 2/0 ip access-group 150 in The white paper titled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Control Plane Policing (CoPP) +---------------------------- The Control Plane Policing (CoPP) feature may be used to mitigate these vulnerabilities. In the following example, only SSH traffic from trusted hosts and with 'receive' destination IP addresses is permitted to reach the route processor (RP). Note: Dropping traffic from unknown or untrusted IP addresses may affect hosts with dynamically assigned IP addresses from connecting to the Cisco IOS device. access-list 152 deny tcp TRUSTED_ADDRESSES MASK any eq 22 access-list 152 permit tcp any any eq 22 ! class-map match-all COPP-KNOWN-UNDESIRABLE match access-group 152 ! ! policy-map COPP-INPUT-POLICY class COPP-KNOWN-UNDESIRABLE drop ! control-plane service-policy input COPP-INPUT-POLICY In the above CoPP example, the ACL entries that match the exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action are not affected by the policy-map drop function. CoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T. Additional information on the configuration and use of the CoPP feature can be found at the following URL: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html Obtaining Fixed Software ======================== Cisco has made free software available to address this vulnerability for affected customers. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact either "psirt at cisco.com" or "security-alert at cisco.com" for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third-party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered by Cisco internal testing and customer service requests. Status of This Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20080521-ssh.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-teams at first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2008-May-21 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkg0RSMACgkQ86n/Gc8U/uCX8QCaA9y2y/y0uC1DPonlJwMGR1Kd jaMAnAz/4J+L7nxWxhppehcJsr0bGmsA =WzxB -----END PGP SIGNATURE----- From heather.schiller at verizonbusiness.com Wed May 21 12:08:06 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 21 May 2008 13:08:06 -0400 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Message-ID: <483456F6.4000506@verizonbusiness.com> William Herrin wrote: > Hi folks, > > An administrative question about multihoming: > > I have a client who needs to multihome with multiple vendors for > reliability purposes, currently in the Northern Virginia area and > later on with a fail-over site, probably in Hawaii. They have only a > very modest need for bandwidth and addresses (think: T1's and a few > dozen servers) but they have to have BGP multihoming and can afford to > pay for it. > > The last I heard, the way to make this happen was: Find a service > provider with IP blocks available in ARIN's set of /8's that permit > /24 announcements (networks 199, 204-207), buy a circuit and request a > /24 for multihoming. Then buy circuits from other providers using that > ISP's /24 and an AS# from ARIN. Yes, but the order is wrong.. - Order service from 2 providers - Request an ASN from ARIN, show them your documentation that you are getting service from 2 providers to justify your need for an ASN - If you don't meet the utilization requirements for getting a /24, request a /24 for multihoming under ARIN 4.2.3.6. from ONE of your providers (not both). At UUnet/VZB we ask customers to provide their ASN as documentation that they have demonstrated their intent to multihome. If you have existing IP space, and it's less than /24 don't be surprised if someone asks you to renumber. If you have existing IP space /24 or larger, don't be surprised if someone turns you down under the multihoming policy. http://www.arin.net/policy/nrpm.html#four236 4.2.3.6. Reassignments to multihomed downstream customers Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050. Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt. This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24. The ISP will then verify the customer's multihoming requirement and may assign the customer a /24, based on this policy. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer. This information may be requested by ARIN staff when reviewing an ISP's utilization during their request for additional IP addresses space. > > Is that still the way to make it happen? Are there alternate > approaches (besides DNS games) that I should consider? > > Who should I talk to? Certain well-known companies seem incapable of > discussing service that isn't cookie-cutter. > It's really pretty straightforward and common actually... but I wouldn't be surprised if sales folks don't know ARIN and/or routing policy. > Thanks, > Bill Herrin > -- ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ From secadmin at netsecdesign.com Wed May 21 13:16:26 2008 From: secadmin at netsecdesign.com (Security Admin (NetSec)) Date: Wed, 21 May 2008 11:16:26 -0700 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> Message-ID: <8D870AB38C30EC4C848A11A3F83D20D809459A78D0@exchange2007.mmicmanhomenet.local> I got a /22 from ARIN last year; ASN 36516. Is the /20 only rule relatively new? Not multi-homed yet because my 2nd provider does not support it yet. Best Regards, Edward Ray -----Original Message----- From: Tony Varriale [mailto:tvarriale at comcast.net] Sent: Tuesday, May 20, 2008 9:32 PM To: Andy Dills Cc: nanog at nanog.org Subject: Re: [NANOG] Multihoming for small frys? AFAIK, ARIN doesn't give out /22s anymore. Last time I went to the well...it's was a /20 or better. tv ----- Original Message ----- From: "Andy Dills" To: "William Herrin" Cc: Sent: Tuesday, May 20, 2008 11:05 PM Subject: Re: [NANOG] Multihoming for small frys? > On Tue, 20 May 2008, William Herrin wrote: > >> Hi folks, >> >> An administrative question about multihoming: >> >> I have a client who needs to multihome with multiple vendors for >> reliability purposes, currently in the Northern Virginia area and >> later on with a fail-over site, probably in Hawaii. They have only a >> very modest need for bandwidth and addresses (think: T1's and a few >> dozen servers) but they have to have BGP multihoming and can afford to >> pay for it. >> >> The last I heard, the way to make this happen was: Find a service >> provider with IP blocks available in ARIN's set of /8's that permit >> /24 announcements (networks 199, 204-207), buy a circuit and request a >> /24 for multihoming. Then buy circuits from other providers using that >> ISP's /24 and an AS# from ARIN. >> >> Is that still the way to make it happen? Are there alternate >> approaches (besides DNS games) that I should consider? > > They should just get their own /22 from ARIN. > > If the future fail-over site doesn't help them show a /23's worth of > justification, break out the ultimate fudge factor: SSL. > > Yes, I know, some would argue this isn't responsible usage of community > resources. > > However, if I was representing the interests of a company whose existence > relies on working connectivity, my biggest concern would be provider > independance. Altruism is something I encourage my competitors to indulge > in. In fact, the increasing value and decreasing pool of prefixes should > motivate any proper capitalist to air on the side of being greedy: just as > they aren't making any more land, they aren't making any more IP(v4) > space. > > My gut instinct has been telling me for half a decade that prefixes will > get commoditized long before IPv6 settles in, and if I was representing > the interests of a company who was in the situation you describe, I would > certainly want to prepare for that possibility. > > ARIN really should allow direct allocation of /24s to multi-homed > organizations. It wouldn't increase the table size, and it would reduce > the wasteful (best common) practice I describe above. > > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog -- This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com -- This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.co From drais at icantclick.org Wed May 21 13:27:43 2008 From: drais at icantclick.org (david raistrick) Date: Wed, 21 May 2008 18:27:43 +0000 (UTC) Subject: [NANOG] Multihoming for small frys? In-Reply-To: <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> Message-ID: On Tue, 20 May 2008, Tony Varriale wrote: > AFAIK, ARIN doesn't give out /22s anymore. It's a recent change in the past couple of years. Still current: "However, for multi-homed organizations, the minimum allocation size is a /22" http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html Now, if you're not multihomed you still have the /20 as the longest prefix. --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From owen at delong.com Wed May 21 14:08:32 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 21 May 2008 12:08:32 -0700 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <8D870AB38C30EC4C848A11A3F83D20D809459A78D0@exchange2007.mmicmanhomenet.local> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <8D870AB38C30EC4C848A11A3F83D20D809459A78D0@exchange2007.mmicmanhomenet.local> Message-ID: <2C801DAD-2E14-4591-A8F4-F0C11CC66FDB@delong.com> For multihomed, /22 is still the rule. Owen DeLong ARIN AC On May 21, 2008, at 11:16 AM, Security Admin (NetSec) wrote: > I got a /22 from ARIN last year; ASN 36516. Is the /20 only rule > relatively new? > > Not multi-homed yet because my 2nd provider does not support it yet. > > Best Regards, > > Edward Ray > > -----Original Message----- > From: Tony Varriale [mailto:tvarriale at comcast.net] > Sent: Tuesday, May 20, 2008 9:32 PM > To: Andy Dills > Cc: nanog at nanog.org > Subject: Re: [NANOG] Multihoming for small frys? > > AFAIK, ARIN doesn't give out /22s anymore. > > Last time I went to the well...it's was a /20 or better. > > tv > ----- Original Message ----- > From: "Andy Dills" > To: "William Herrin" > Cc: > Sent: Tuesday, May 20, 2008 11:05 PM > Subject: Re: [NANOG] Multihoming for small frys? > > >> On Tue, 20 May 2008, William Herrin wrote: >> >>> Hi folks, >>> >>> An administrative question about multihoming: >>> >>> I have a client who needs to multihome with multiple vendors for >>> reliability purposes, currently in the Northern Virginia area and >>> later on with a fail-over site, probably in Hawaii. They have only a >>> very modest need for bandwidth and addresses (think: T1's and a few >>> dozen servers) but they have to have BGP multihoming and can >>> afford to >>> pay for it. >>> >>> The last I heard, the way to make this happen was: Find a service >>> provider with IP blocks available in ARIN's set of /8's that permit >>> /24 announcements (networks 199, 204-207), buy a circuit and >>> request a >>> /24 for multihoming. Then buy circuits from other providers using >>> that >>> ISP's /24 and an AS# from ARIN. >>> >>> Is that still the way to make it happen? Are there alternate >>> approaches (besides DNS games) that I should consider? >> >> They should just get their own /22 from ARIN. >> >> If the future fail-over site doesn't help them show a /23's worth of >> justification, break out the ultimate fudge factor: SSL. >> >> Yes, I know, some would argue this isn't responsible usage of >> community >> resources. >> >> However, if I was representing the interests of a company whose >> existence >> relies on working connectivity, my biggest concern would be provider >> independance. Altruism is something I encourage my competitors to >> indulge >> in. In fact, the increasing value and decreasing pool of prefixes >> should >> motivate any proper capitalist to air on the side of being greedy: >> just as >> they aren't making any more land, they aren't making any more IP(v4) >> space. >> >> My gut instinct has been telling me for half a decade that prefixes >> will >> get commoditized long before IPv6 settles in, and if I was >> representing >> the interests of a company who was in the situation you describe, I >> would >> certainly want to prepare for that possibility. >> >> ARIN really should allow direct allocation of /24s to multi-homed >> organizations. It wouldn't increase the table size, and it would >> reduce >> the wasteful (best common) practice I describe above. >> >> Andy >> >> --- >> Andy Dills >> Xecunet, Inc. >> www.xecu.net >> 301-682-9972 >> --- >> >> _______________________________________________ >> NANOG mailing list >> NANOG at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog > > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > -- > This mail was scanned by BitDefender > For more informations please visit http://www.bitdefender.com > > > -- > This mail was scanned by BitDefender > For more informations please visit http://www.bitdefender.co > From tvarriale at comcast.net Wed May 21 14:02:54 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 21 May 2008 14:02:54 -0500 Subject: [NANOG] Multihoming for small frys? References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> Message-ID: <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> Thanks for the info. We needed larger than /22 anyways. I am a bit surprised that they will hand out a small allocaiton for multihomers. These days it's very easy to do. And, could be a easy way to horde some v4. Notice the caveats: To qualify under the IPv4 Multi-homing policy, your organization must prove an intent to multi-home, demonstrate utilization for at least a /23-worth of IP addresses assigned by upstream providers, and provide 3-, 6-, and 12-month utilization projections. In addition, your organization must agree to use the requested IPv4 address space to renumber out of your current address space, and to return the original address space to your upstream provider(s) once the renumbering is complete. Additional space will not be allocated until this is completed. Organizations that qualify under this policy may also qualify and request space under ARIN's general IPv4 allocation policy. Of course, this could be smoke and mirrors. Not sure. tv ----- Original Message ----- From: "Andy Dills" To: "Tony Varriale" Cc: Sent: Wednesday, May 21, 2008 1:53 AM Subject: Re: [NANOG] Multihoming for small frys? > On Tue, 20 May 2008, Tony Varriale wrote: > >> AFAIK, ARIN doesn't give out /22s anymore. >> >> Last time I went to the well...it's was a /20 or better. > > Nah, it's /22 for multi-homed networks, /20 for single-homed. > > > http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html > > 4.3.2.2 Multihomed Connection > For end-users who demonstrate an intent to announce the requested space in > a multihomed fashion, the minimum block of IP address space assigned is a > /22. If assignments smaller than a /22 are needed, multihomed end-users > should contact their upstream providers. When prefixes are assigned which > are longer than /20, they will be from a block reserved for that purpose. > > > > > Are there really networks who can justify a /20 that aren't multi-homed? > The mind boggles. > > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- From deepak at ai.net Wed May 21 15:08:48 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 21 May 2008 16:08:48 -0400 Subject: Renumbering, was: [NANOG] Multihoming for small frys? In-Reply-To: <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> Message-ID: <48348150.4020504@ai.net> Can we all agree that while renumbering sucks, a /24 (or less) is a pretty low-pain thing to renumber (vs. say, renumbering a /20 or shorter prefix?) In an ideal world, you never have to renumber because your allocations were perfect from the get-go. We've all been to the other, more realistic place, no? While we all feel pain for folks who have to do renumbers, even if EVERY single host in there is a MAJOR dns server (which is my personal worst case) for MAJOR sites, even *that* has become much easier to address than it used to be. This is probably rhetorical, but I feel like some threshold of materiality should be roughly described so Operators don't get whipsawed over variable length renumbers longer than a certain length. DJ From david at davidcoulson.net Wed May 21 15:15:17 2008 From: david at davidcoulson.net (David Coulson) Date: Wed, 21 May 2008 16:15:17 -0400 Subject: Renumbering, was: [NANOG] Multihoming for small frys? In-Reply-To: <48348150.4020504@ai.net> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <48348150.4020504@ai.net> Message-ID: <483482D5.9010006@davidcoulson.net> Deepak Jain wrote: > Can we all agree that while renumbering sucks, a /24 (or less) is a > pretty low-pain thing to renumber (vs. say, renumbering a /20 or > shorter prefix?) In an ideal world, you never have to renumber because > your allocations were perfect from the get-go. Depends - If you're an Enterprise where 90% of the equipment is managed by people who work in the same building, it's not horrible. I renumbered a bunch of /20s onto a /18 where 75% of the equipment was not in my (or the company's) control. That sucked big time. David From sean at labrats.us Wed May 21 15:29:28 2008 From: sean at labrats.us (Sean Figgins) Date: Wed, 21 May 2008 14:29:28 -0600 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> Message-ID: <48348628.9070400@labrats.us> William Herrin wrote: > I have a client who needs to multihome with multiple vendors for > reliability purposes, currently in the Northern Virginia area and > later on with a fail-over site, probably in Hawaii. They have only a > very modest need for bandwidth and addresses (think: T1's and a few > dozen servers) but they have to have BGP multihoming and can afford to > pay for it. Now, I have a question about this... Is the customer using the sites for redundancy, and will have both upstream providers in each site? Honestly, a small operation like this may be better served by multiple connections to the same provider. Such a setup can usually be done to multiple routers, through redundant circuit paths, and done at substantially less cost that two different providers. And, in my experience, using one provider can often be more reliable than multiple providers, given how many providers transport facilities ride the same fiber path, and sometimes the same bundle. -Sean From jbates at brightok.net Wed May 21 15:31:57 2008 From: jbates at brightok.net (Jack Bates) Date: Wed, 21 May 2008 15:31:57 -0500 Subject: Renumbering, was: [NANOG] Multihoming for small frys? In-Reply-To: <483482D5.9010006@davidcoulson.net> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <48348150.4020504@ai.net> <483482D5.9010006@davidcoulson.net> Message-ID: <483486BD.7070001@brightok.net> David Coulson wrote: > Depends - If you're an Enterprise where 90% of the equipment is managed > by people who work in the same building, it's not horrible. I renumbered > a bunch of /20s onto a /18 where 75% of the equipment was not in my (or > the company's) control. That sucked big time. I had the same issue. Add to that recursive DNS servers and the support issues of everything that depends on them in and not in your direct control. While mostly taken care of within a year, I've seen small side effects of the renumber over 5 years later. Small things that work under normal conditions but still have mention of the old IPs which cause problems when rare conditions occur (ie, outages under specific circumstances). Jack Bates From petelists at templin.org Wed May 21 15:32:30 2008 From: petelists at templin.org (Pete Templin) Date: Wed, 21 May 2008 15:32:30 -0500 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> Message-ID: <483486DE.3090208@templin.org> Tony Varriale wrote: > Thanks for the info. We needed larger than /22 anyways. > > I am a bit surprised that they will hand out a small allocaiton for > multihomers. These days it's very easy to do. And, could be a easy way > to horde some v4. Nope, you can horde a /24 for a single device, but it's provider-assigned. If you can't justify a /23 -now-, you don't qualify for an ARIN multihomers' /22. pt From deepak at ai.net Wed May 21 15:38:14 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 21 May 2008 16:38:14 -0400 Subject: Renumbering, was: [NANOG] Multihoming for small frys? In-Reply-To: <483482D5.9010006@davidcoulson.net> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <48348150.4020504@ai.net> <483482D5.9010006@davidcoulson.net> Message-ID: <48348836.9070008@ai.net> David Coulson wrote: > Deepak Jain wrote: >> Can we all agree that while renumbering sucks, a /24 (or less) is a >> pretty low-pain thing to renumber (vs. say, renumbering a /20 or >> shorter prefix?) In an ideal world, you never have to renumber because >> your allocations were perfect from the get-go. > Depends - If you're an Enterprise where 90% of the equipment is managed > by people who work in the same building, it's not horrible. I renumbered > a bunch of /20s onto a /18 where 75% of the equipment was not in my (or > the company's) control. That sucked big time. > Right, but a /20 is a /lot/ more space than a /24. I think I'd say that shorter than a /21 is certainly a decent threshold of pain (personally). Even if its all in-house. There are ways to make it less painful and special painless cases (an all NAT space), but as a shot-in-the-dark, that's a pretty good bet [you almost certainly have a decent mix of network and server gear, different authorities, different topologies, etc] DJ From david at davidcoulson.net Wed May 21 15:39:45 2008 From: david at davidcoulson.net (David Coulson) Date: Wed, 21 May 2008 16:39:45 -0400 Subject: Renumbering, was: [NANOG] Multihoming for small frys? In-Reply-To: <483486BD.7070001@brightok.net> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <48348150.4020504@ai.net> <483482D5.9010006@davidcoulson.net> <483486BD.7070001@brightok.net> Message-ID: <48348891.8030604@davidcoulson.net> Jack Bates wrote: > I had the same issue. Add to that recursive DNS servers and the > support issues of everything that depends on them in and not in your > direct control. Indeed. I recall Proxy ARP and a lot of NAT was involved :) At least you can keep track of the people who didn't update their configs, even though they said they did. David From sethm at rollernet.us Wed May 21 15:40:50 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 21 May 2008 13:40:50 -0700 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <48348628.9070400@labrats.us> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <48348628.9070400@labrats.us> Message-ID: <483488D2.4090002@rollernet.us> Sean Figgins wrote: > > Now, I have a question about this... Is the customer using the sites > for redundancy, and will have both upstream providers in each site? > > Honestly, a small operation like this may be better served by multiple > connections to the same provider. Such a setup can usually be done to > multiple routers, through redundant circuit paths, and done at > substantially less cost that two different providers. And, in my > experience, using one provider can often be more reliable than multiple > providers, given how many providers transport facilities ride the same > fiber path, and sometimes the same bundle. I have to disagree... About two years ago, maybe less, Sprint was doing some maintenance in California and was moving stuff through an alternate path in Arizona. However, while the CA path was off, someone took a backhoe to the AZ path. Neither the planned outage, the cut, nor myself were in the same state (I'm in Nevada). It didn't matter how many circuits I had with Sprint, because none of them worked, including my Sprint cell phone. However, I was still on the air because my other providers were unaffected. Locally, yeah, the path in the ground are probably the same. But beyond that, it can matter, and I strongly recommend multihoming if the story above is something their organization would like to be protected from. ~Seth From brett at wrl.org Wed May 21 16:01:24 2008 From: brett at wrl.org (Brett Charbeneau) Date: Wed, 21 May 2008 17:01:24 -0400 (EDT) Subject: Nortel 4450T switches and QoS? Message-ID: Does anyone have any experience with switches of this ilk - and how well they do throttling P2P traffic? The sales material purports that these switches "filter" at L2 which sounds groovy and all, but I'd really like to hear from someone who has used these for this purpose. And how well that actually worked for them. -- ******************************************************************** Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax) brett at wrl.org ******************************************************************** From jtk at centergate.net Wed May 21 16:15:37 2008 From: jtk at centergate.net (John Kristoff) Date: Wed, 21 May 2008 16:15:37 -0500 Subject: [NANOG] Limiting ICMP In-Reply-To: References: Message-ID: <200805212115.m4LLFcBJ016955@larry.centergate.com> On Sat, 17 May 2008 23:53:00 -0400 Drew Weaver wrote: > I'm wondering if anyone else has run into this/has heard of/(is responsible for)/knows the reason behind large IP providers limiting ICMP on outbound connections to the same amounts regardless of the size of the circuit? > I might be partially responsible for furthering some of that activity. I've done this sort of thing on initial ingress facing links (e.g. LAN segments with client-oriented systems) and it was me who provided the sample configs for the cymru junos template for limiting udp and icmp. Perhaps I mentioned it on a mailing list or in some internal documentation somewhere, but the way I've done it is typically to limit those two IP protocols (and sometimes other things like multicast) to some fraction of a percent on a edge LAN ingress link speed, which is not in the template. Egress, aggregate and peering/Internet facing links shouldn't have these limits (yes, kind of a pain to manage if you're not good at router config management). Unfortunately I didn't provide all that detail to the cymru folks at the time and as I'm sure they are aware those templates are quite a bit outdated now and could easily take some heavy revisioning. In the environments where I've done this, my experience was that it was an acceptable practice at the time and in a couple cases it did help the net upstream when something went wrong (e.g. this did stop some real DoS traffic for me more than once). I made use of protocol counters or some monitoring tools to ensure they were not unnecessarily dropping valid packets. Your mileage may vary of course, as it apparently does? John From robt at cymru.com Wed May 21 16:18:36 2008 From: robt at cymru.com (Rob Thomas) Date: Wed, 21 May 2008 16:18:36 -0500 Subject: [NANOG] Limiting ICMP In-Reply-To: <200805212115.m4LLFcBJ016955@larry.centergate.com> References: <200805212115.m4LLFcBJ016955@larry.centergate.com> Message-ID: <483491AC.3020009@cymru.com> Yep, agreed, we need to update those docs. The basic ICMP filtering guide still resides here, and comments are welcome: John Kristoff wrote: > On Sat, 17 May 2008 23:53:00 -0400 > Drew Weaver wrote: > >> I'm wondering if anyone else has run into this/has heard of/(is responsible for)/knows the reason behind large IP providers limiting ICMP on outbound connections to the same amounts regardless of the size of the circuit? >> > > I might be partially responsible for furthering some of that activity. > I've done this sort of thing on initial ingress facing links (e.g. LAN > segments with client-oriented systems) and it was me who provided the > sample configs for the cymru junos template for limiting udp and icmp. > > Perhaps I mentioned it on a mailing list or in some internal documentation > somewhere, but the way I've done it is typically to limit those two IP > protocols (and sometimes other things like multicast) to some fraction > of a percent on a edge LAN ingress link speed, which is not in the > template. Egress, aggregate and peering/Internet facing links shouldn't > have these limits (yes, kind of a pain to manage if you're not good at > router config management). Unfortunately I didn't provide all that > detail to the cymru folks at the time and as I'm sure they are aware > those templates are quite a bit outdated now and could easily take some > heavy revisioning. > > In the environments where I've done this, my experience was that it was > an acceptable practice at the time and in a couple cases it did help the > net upstream when something went wrong (e.g. this did stop some real > DoS traffic for me more than once). I made use of protocol counters or > some monitoring tools to ensure they were not unnecessarily dropping > valid packets. Your mileage may vary of course, as it apparently does? > > John > -- Rob Thomas Team Cymru The WHO and WHY team http://www.team-cymru.org/ From todd-nanog at renesys.com Wed May 21 13:32:52 2008 From: todd-nanog at renesys.com (Todd Underwood) Date: Wed, 21 May 2008 18:32:52 +0000 Subject: [NANOG-announce] Lightning Talk submissions open for NANOG42 Message-ID: <20080521183252.GJ6212@renesys.com> /me dons the NANOG PC Chair hat again Lightning talk submissions for NANOG42 are now open: http://nanogpc.org/lightning/ Lightning talks are short talks of interest to the audience in line with the rest of the program. They are strictly limited to 10 minutes (including questions). Lightning talks are selected by the program committee during the conference but we will probably select the first round of lightning talks just prior to the start of the conference. Get your submissions in. /me takes off the hat and wipes his brow -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From todd-nanog at renesys.com Wed May 21 13:30:27 2008 From: todd-nanog at renesys.com (Todd Underwood) Date: Wed, 21 May 2008 18:30:27 +0000 Subject: [NANOG-announce] New socials for NANOG 42 Brooklyn -- Register Message-ID: <20080521183027.GI6212@renesys.com> howdy, NANOG42 will take place in brooklyn, NY in about a week and a half. there are two new socials (you can read "socials" as "free drinks and snacks") that have been added to the agenda at http://nanog.org/mtg-0806/agenda.html * equinix is sponsoring a social on tuesday evening: http://nanog.org/mtg-0806/invitation.html * and our host, Telx is sponsoring an event on wednesday evening: http://nanog.org/mtg-0806/invitation2.html both events are open to all nanog attendees. if you have not yet registered for NANOG42, please do so now. the hotel rooms at good rates are all gone, but the registration numbers indicate that many of you are waiting until the last minute to register. please take a minute to do so now so that we can have a more accurate count of the number of expected attendees: https://nanog.merit.edu/registration/ thanks, todd -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From todd-nanog at renesys.com Wed May 21 13:58:10 2008 From: todd-nanog at renesys.com (Todd Underwood) Date: Wed, 21 May 2008 18:58:10 +0000 Subject: [NANOG-announce] Program Committee Vacancy Call for Volunteers Extension Message-ID: <20080521185810.GL6212@renesys.com> . o O ( i'm thinking about just leaving this program committee chair hat on) the call for volunteers to the nanog program committee (originally sent: http://mailman.nanog.org/pipermail/nanog/2008-April/000153.html ) has been extended through the end of the weekend (to sunday, 25 may 2008). there were some miscommunications among nominators and the program committee that means that a number of nominations and solicitations did not take place in a timely fashion. i believe the fair thing to do is to extend the time frame for several days to make it possible for everyone who is interested in this seat to offer their name. so if you're interested, review the call for volunteers and submit your name promptly, please. thanks, todd -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From sean at labrats.us Wed May 21 16:51:54 2008 From: sean at labrats.us (Sean Figgins) Date: Wed, 21 May 2008 15:51:54 -0600 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <483488D2.4090002@rollernet.us> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <48348628.9070400@labrats.us> <483488D2.4090002@rollernet.us> Message-ID: <4834997A.3070508@labrats.us> Seth Mattinen wrote: > About two years ago, maybe less, Sprint was doing some maintenance in > California and was moving stuff through an alternate path in Arizona. > However, while the CA path was off, someone took a backhoe to the AZ > path. Neither the planned outage, the cut, nor myself were in the same > state (I'm in Nevada). It didn't matter how many circuits I had with > Sprint, because none of them worked, including my Sprint cell phone. > However, I was still on the air because my other providers were unaffected. I've been in a situation before where circuits with two different providers were both taken out by the same fiber cut. These were large long-haul circuits. I've had another situation where two circuits out of Charlotte, NC ended up in the same bundle in Virginia, even though they were one was going to Atlanta, and another was headed to DC, through two different providers. One provider bought the bundle from someone, and leased part of it to another company, who sublet it to another company, that provided service to the the carrier that provided us the service. Kicker was that I think it was originally our fiber. Of course, these are circuits, not internet traffic. With todays' large networks, it's really hard to completely isolate any given city. Oh sure, it can happen, and some cities are unpopular, and don't hardly qualify for IP service, so diversity is hard to justify, but most cities have at least two, if not three or more paths out. -Sean From tvarriale at comcast.net Wed May 21 18:18:42 2008 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 21 May 2008 18:18:42 -0500 Subject: [NANOG] Multihoming for small frys? References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <483486DE.3090208@templin.org> Message-ID: <003d01c8bb99$0404c130$f211a8c0@flamwsugsmul5v> Yup. You can horde. You can easily justify a /23 these days and not be multihomed still get a /22. tv ----- Original Message ----- From: "Pete Templin" To: "Tony Varriale" Cc: Sent: Wednesday, May 21, 2008 3:32 PM Subject: Re: [NANOG] Multihoming for small frys? > Tony Varriale wrote: >> Thanks for the info. We needed larger than /22 anyways. >> >> I am a bit surprised that they will hand out a small allocaiton for >> multihomers. These days it's very easy to do. And, could be a easy way >> to horde some v4. > > Nope, you can horde a /24 for a single device, but it's provider-assigned. > If you can't justify a /23 -now-, you don't qualify for an ARIN > multihomers' /22. > > pt From JMcMasters at atlanticbb.com Wed May 21 20:17:44 2008 From: JMcMasters at atlanticbb.com (McMasters, Jeremy) Date: Wed, 21 May 2008 21:17:44 -0400 Subject: Renumbering, was: [NANOG] Multihoming for small frys? In-Reply-To: <48348150.4020504@ai.net> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net><003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <48348150.4020504@ai.net> Message-ID: <6E52E4E1B15ADE41BD0EACCAD6864C0A09FAAC36@ABBEX01.abb.msad> I worked for an ISP that was bought by another ISP and had to assign all new IP's roughly a /16 worth. Good times. Only one ASN thank goodness -----Original Message----- From: Deepak Jain [mailto:deepak at ai.net] Sent: Wednesday, May 21, 2008 4:09 PM To: nanog list Subject: Re: Renumbering, was: [NANOG] Multihoming for small frys? Can we all agree that while renumbering sucks, a /24 (or less) is a pretty low-pain thing to renumber (vs. say, renumbering a /20 or shorter prefix?) In an ideal world, you never have to renumber because your allocations were perfect from the get-go. We've all been to the other, more realistic place, no? While we all feel pain for folks who have to do renumbers, even if EVERY single host in there is a MAJOR dns server (which is my personal worst case) for MAJOR sites, even *that* has become much easier to address than it used to be. This is probably rhetorical, but I feel like some threshold of materiality should be roughly described so Operators don't get whipsawed over variable length renumbers longer than a certain length. DJ From rs at seastrom.com Wed May 21 21:24:52 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 21 May 2008 22:24:52 -0400 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <003d01c8bb99$0404c130$f211a8c0@flamwsugsmul5v> (Tony Varriale's message of "Wed, 21 May 2008 18:18:42 -0500") References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> <483486DE.3090208@templin.org> <003d01c8bb99$0404c130$f211a8c0@flamwsugsmul5v> Message-ID: <86iqx7gjnv.fsf@seastrom.com> It's always been possible to get resources by lying or committing fraud - the common law crime of obtaining property by false pretenses predates the Internet by a substantial margin. ---rob "Tony Varriale" writes: > Yup. You can horde. > > You can easily justify a /23 these days and not be multihomed still > get a /22. > > tv > ----- Original Message ----- > From: "Pete Templin" > To: "Tony Varriale" > Cc: > Sent: Wednesday, May 21, 2008 3:32 PM > Subject: Re: [NANOG] Multihoming for small frys? > > >> Tony Varriale wrote: >>> Thanks for the info. We needed larger than /22 anyways. >>> >>> I am a bit surprised that they will hand out a small allocaiton for >>> multihomers. These days it's very easy to do. And, could be a >>> easy way to horde some v4. >> >> Nope, you can horde a /24 for a single device, but it's >> provider-assigned. If you can't justify a /23 -now-, you don't >> qualify for an ARIN multihomers' /22. >> >> pt From wmullaney at annese.com Wed May 21 21:34:25 2008 From: wmullaney at annese.com (William Mullaney) Date: Wed, 21 May 2008 22:34:25 -0400 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com><20080520233017.H55620@shell.xecu.net><000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v><20080521025010.N55620@shell.xecu.net> <003601c8bb75$46d856d0$f211a8c0@flamwsugsmul5v> Message-ID: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> I got a /22 in January, and was told by someone from ARIN that the policy below only applied to allocations to ISP's, not to assignments for end customers. At the time, they said an end user must show at least 25% immediate usage (so a /24) and that there was no requirement for future usage. In my experience, if you can show you have some semblance of ability, two real peers, and an existing and established business, you should be able to get the request through easily in about a week, start to finish. When you're ready, fill out the request form, the worst that can happen is they reject you or defer you until you can provide more info. If you have questions for/about ARIN, call them (number is on the website) and talk to one of their people, they've been pretty knowledgeable, friendly, and helpful in my experience. -Will -----Original Message----- From: Tony Varriale [mailto:tvarriale at comcast.net] Sent: Wednesday, May 21, 2008 3:03 PM To: Andy Dills Cc: nanog at nanog.org Subject: Re: [NANOG] Multihoming for small frys? Thanks for the info. We needed larger than /22 anyways. I am a bit surprised that they will hand out a small allocaiton for multihomers. These days it's very easy to do. And, could be a easy way to horde some v4. Notice the caveats: To qualify under the IPv4 Multi-homing policy, your organization must prove an intent to multi-home, demonstrate utilization for at least a /23-worth of IP addresses assigned by upstream providers, and provide 3-, 6-, and 12-month utilization projections. In addition, your organization must agree to use the requested IPv4 address space to renumber out of your current address space, and to return the original address space to your upstream provider(s) once the renumbering is complete. Additional space will not be allocated until this is completed. Organizations that qualify under this policy may also qualify and request space under ARIN's general IPv4 allocation policy. Of course, this could be smoke and mirrors. Not sure. tv ----- Original Message ----- From: "Andy Dills" To: "Tony Varriale" Cc: Sent: Wednesday, May 21, 2008 1:53 AM Subject: Re: [NANOG] Multihoming for small frys? > On Tue, 20 May 2008, Tony Varriale wrote: > >> AFAIK, ARIN doesn't give out /22s anymore. >> >> Last time I went to the well...it's was a /20 or better. > > Nah, it's /22 for multi-homed networks, /20 for single-homed. > > > http://www.arin.net/registration/guidelines/ipv4_initial_alloc.html > > 4.3.2.2 Multihomed Connection > For end-users who demonstrate an intent to announce the requested space in > a multihomed fashion, the minimum block of IP address space assigned is a > /22. If assignments smaller than a /22 are needed, multihomed end-users > should contact their upstream providers. When prefixes are assigned which > are longer than /20, they will be from a block reserved for that purpose. > > > > > Are there really networks who can justify a /20 that aren't multi-homed? > The mind boggles. > > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- From joe at hole-in-the.net Thu May 22 09:25:44 2008 From: joe at hole-in-the.net (Joe Warren-Meeks) Date: Thu, 22 May 2008 15:25:44 +0100 Subject: [NANOG] Multihoming for small frys? In-Reply-To: <2C801DAD-2E14-4591-A8F4-F0C11CC66FDB@delong.com> References: <3c3e3fca0805201207p524ee7a1n91a0f8079a8387fb@mail.gmail.com> <20080520233017.H55620@shell.xecu.net> <000c01c8bafb$9f06f4d0$f211a8c0@flamwsugsmul5v> <8D870AB38C30EC4C848A11A3F83D20D809459A78D0@exchange2007.mmicmanhomenet.local> <2C801DAD-2E14-4591-A8F4-F0C11CC66FDB@delong.com> Message-ID: <20080522142544.GA22387@black.hole-in-the.net> On Wed, May 21, 2008 at 12:08:32PM -0700, Owen DeLong wrote: > For multihomed, /22 is still the rule. Over here in RIPE-land, I just got a /23 for AS44947, announced as two /24's. Seems to work fine. -- joe. From jblanchard at uplogon.com Thu May 22 09:37:59 2008 From: jblanchard at uplogon.com (Joe Blanchard) Date: Thu, 22 May 2008 10:37:59 -0400 Subject: Hughes Network In-Reply-To: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> Message-ID: <004601c8bc19$72d81ff0$1401a8c0@E520> Pardon the request, Is their anyone on the NANOG list from Hughesnet? I'm facing an issue with reverse DNS (RFC1912) that is difficult at best to resolve in India. ;) Please contact me off list. Regards, Joe Blanchard From rar at syssrc.com Thu May 22 11:04:21 2008 From: rar at syssrc.com (rar) Date: Thu, 22 May 2008 12:04:21 -0400 Subject: Hughes Network In-Reply-To: <004601c8bc19$72d81ff0$1401a8c0@E520> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> Message-ID: <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> I have tried everything I can think of to get good technical support from Hughesnet. I sent a Fed Ex package outlining a problem to the President. Never heard a word. The people in India where a nightmare. I worked with one of their sales reps and no satisfaction. If you find anyone who can help with technical issues, and they are willing to help another soon to be ex-customer with an issue in Haiti, let me know. Bob Roswell System Source broswell at syssrc.com (410) 771-5544 ext 4336 -----Original Message----- From: Joe Blanchard [mailto:jblanchard at uplogon.com] Sent: Thursday, May 22, 2008 10:38 AM To: nanog at nanog.org Subject: Hughes Network Pardon the request, Is their anyone on the NANOG list from Hughesnet? I'm facing an issue with reverse DNS (RFC1912) that is difficult at best to resolve in India. ;) Please contact me off list. Regards, Joe Blanchard From jkelty at pandora.com Thu May 22 11:38:32 2008 From: jkelty at pandora.com (James Kelty) Date: Thu, 22 May 2008 09:38:32 -0700 Subject: Splitting ARIN assignment Message-ID: <4835A188.2000302@pandora.com> Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James From swm at emanon.com Thu May 22 11:49:14 2008 From: swm at emanon.com (Scott Morris) Date: Thu, 22 May 2008 12:49:14 -0400 Subject: Splitting ARIN assignment In-Reply-To: <4835A188.2000302@pandora.com> References: <4835A188.2000302@pandora.com> Message-ID: <055101c8bc2b$c4fb2c70$800610ac@scott66ed7b03d> As long as your upstreams/partners are cool with that, there is no related designation between how addresses are allocated versus how they are announced. In other words, TECHNICALLY you could advertise a whole bunch of /30's.... You just run the risk of being filtered and/or ridiculed along the way. :) But splitting the /22's from the same announcing AS shouldn't cause any problems as long as you design your connectivity ok. Scott -----Original Message----- From: James Kelty [mailto:jkelty at pandora.com] Sent: Thursday, May 22, 2008 12:39 PM To: nanog at nanog.org Subject: Splitting ARIN assignment Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James From ben.butler at c2internet.net Thu May 22 12:02:49 2008 From: ben.butler at c2internet.net (Ben Butler) Date: Thu, 22 May 2008 18:02:49 +0100 Subject: Splitting ARIN assignment References: <4835A188.2000302@pandora.com> <055101c8bc2b$c4fb2c70$800610ac@scott66ed7b03d> Message-ID: Hi, I do appreciate real life is often more complex than high flying ideals. But aggregation and general good practice would mean in an ideal world you would invest in the internal infrastructure to connect your data centres together with a network and run an IGP+iBGP plus advertise the /21 eBGP at both sites to upstreams. It could be argued that the cost of building the network to run your AS is part and parcel of the expense of opening new datacenter - rather than this ever increasing route table growth. Plus if you de-aggregate as intended you can not announce a covering route for the /21 due to no internal connectivity and if this puts the /22 under the minimum allocation size for the RIR block your IP space comes from then don't be surprised when it gets filtered out and people end up having to accept no routing to your network at all or, sum optimal via a default. But life is rarely as simple as ideals. My 2e Ben -----Original Message----- From: Scott Morris [mailto:swm at emanon.com] Sent: 22 May 2008 17:49 To: 'James Kelty'; nanog at nanog.org Subject: RE: Splitting ARIN assignment As long as your upstreams/partners are cool with that, there is no related designation between how addresses are allocated versus how they are announced. In other words, TECHNICALLY you could advertise a whole bunch of /30's.... You just run the risk of being filtered and/or ridiculed along the way. :) But splitting the /22's from the same announcing AS shouldn't cause any problems as long as you design your connectivity ok. Scott -----Original Message----- From: James Kelty [mailto:jkelty at pandora.com] Sent: Thursday, May 22, 2008 12:39 PM To: nanog at nanog.org Subject: Splitting ARIN assignment Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James From jmaimon at ttec.com Thu May 22 12:02:29 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 May 2008 13:02:29 -0400 Subject: Splitting ARIN assignment In-Reply-To: <4835A188.2000302@pandora.com> References: <4835A188.2000302@pandora.com> Message-ID: <4835A725.9090404@ttec.com> James Kelty wrote: > Hey all, > > I'm looking for an opinion from the group. I have an ARIN /21 assignment > and a new requirement for a second data center. Rather than ask for > another assignment, I would like to advertise one /22 from one location > and the other /22 from the second location both with the same asn. My > apps will work that way, so I don't have an issue internally, but I'm > looking for a broader base opinion on that. > > Thanks a lot! > > -James You should attempt to advertise the /21 at each site along with the site's /22 If you dont have dedicated interconnectivity between the sites, tunneling *carefully* should do the trick. This will ensure that if/when those who filter on strict allocation boundaries dont hear your /22, there will still be reachability, even if suboptimal, to your sites. From jmaimon at ttec.com Thu May 22 12:07:00 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 May 2008 13:07:00 -0400 Subject: Hauling gear around a NANOG meeting Message-ID: <4835A834.4040303@ttec.com> Looking for some advice for a first-timer. What are your recommendation regarding gear? - laptop and charger only - laptop with small bag - the whole normal kit&caboodle, wheeled backpack thing Thanks, Joe From streiner at cluebyfour.org Thu May 22 11:46:29 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 22 May 2008 12:46:29 -0400 (EDT) Subject: Splitting ARIN assignment In-Reply-To: <4835A188.2000302@pandora.com> References: <4835A188.2000302@pandora.com> Message-ID: On Thu, 22 May 2008, James Kelty wrote: > I'm looking for an opinion from the group. I have an ARIN /21 assignment and > a new requirement for a second data center. Rather than ask for another > assignment, I would like to advertise one /22 from one location and the other > /22 from the second location both with the same asn. My apps will work that > way, so I don't have an issue internally, but I'm looking for a broader base > opinion on that. You can do this and it shouldn't be much of an issue. Note tht if you change your routing policy in the future and opt to announce the full /21 from both data centers, you will need to make provisions for connectivity between the two sites since both sites would be advertising reachability for the full block. jms From williamsjj at digitar.com Thu May 22 12:39:15 2008 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Thu, 22 May 2008 11:39:15 -0600 Subject: Hughes Network In-Reply-To: <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local><004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> Message-ID: Has anyone else noticed that the [NANOG] prefix has been missing intermittently from the list traffic over the last couple of days? -J --- Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com E: williamsjj at digitar.com V: 208-343-8520 M: 208-863-0727 F: 208-322-8520 XMPP: williamsjj at digitar.com -----Original Message----- From: rar [mailto:rar at syssrc.com] Sent: Thursday, May 22, 2008 10:04 AM To: Joe Blanchard; nanog at nanog.org Subject: RE: Hughes Network I have tried everything I can think of to get good technical support from Hughesnet. I sent a Fed Ex package outlining a problem to the President. Never heard a word. The people in India where a nightmare. I worked with one of their sales reps and no satisfaction. If you find anyone who can help with technical issues, and they are willing to help another soon to be ex-customer with an issue in Haiti, let me know. Bob Roswell System Source broswell at syssrc.com (410) 771-5544 ext 4336 -----Original Message----- From: Joe Blanchard [mailto:jblanchard at uplogon.com] Sent: Thursday, May 22, 2008 10:38 AM To: nanog at nanog.org Subject: Hughes Network Pardon the request, Is their anyone on the NANOG list from Hughesnet? I'm facing an issue with reverse DNS (RFC1912) that is difficult at best to resolve in India. ;) Please contact me off list. Regards, Joe Blanchard !SIG:48359a1571591351813437! From r.hyunseog at ieee.org Thu May 22 12:45:47 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Thu, 22 May 2008 12:45:47 -0500 Subject: Splitting ARIN assignment In-Reply-To: <4835A188.2000302@pandora.com> References: <4835A188.2000302@pandora.com> Message-ID: <4835B14B.9000901@ieee.org> I I were you, I will advertise as following. /21 Original ARIN allocation /22 First half of ARIN allocation /22 second half of ARIN allocation In this case, you will have backup /21 route just in case of filtering or something like that. But in normal case, traffic will be routed based on more specific routes, which are /22s. In some case, upstream ISPs may filter based on strict filtering, which means all BGP prefix announcement should be matched with registered CIDR info including subnet size. In most case, upstream ISP will accept any subnet size between registered size (/21) and /24 size. Because of load sharing and traffic engineering requirement, it is easy to handle those situation with /22 size. Make sure that your two location is inter-connected directly, and have enough capacity when each of location upstream connection goes down. Hyun ames Kelty wrote: > Hey all, > > I'm looking for an opinion from the group. I have an ARIN /21 > assignment and a new requirement for a second data center. Rather than > ask for another assignment, I would like to advertise one /22 from one > location and the other /22 from the second location both with the same > asn. My apps will work that way, so I don't have an issue internally, > but I'm looking for a broader base opinion on that. > > Thanks a lot! > > -James > > > > From michael.holstein at csuohio.edu Thu May 22 12:58:03 2008 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 22 May 2008 13:58:03 -0400 Subject: Hughes Network In-Reply-To: References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local><004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> Message-ID: <4835B42B.3010601@csuohio.edu> > Has anyone else noticed that the [NANOG] prefix has been missing > intermittently from the list traffic over the last couple of days? > Different SMTP servers, it appears (looks like they might have been using an Ironport box to do anti-spam, and it was probably doing the subject re-writes as well) With the [NANOG] in subject : received: from linuxbox.org ([24.155.83.21]) by thor.merit.edu with ESMTP; 20 May 2008 10:27:41 -0400 Without the subject tag : Received: from nameserver2.ttec.com ([64.95.32.37] helo=smtp.ttec.com) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JzEFp-0006tP-1S for nanog at nanog.org; Thu, 22 May 2008 17:07:01 +0000 Cheers, Michael Holstein Cleveland State University From shrdlu at deaddrop.org Thu May 22 13:01:00 2008 From: shrdlu at deaddrop.org (Lynda) Date: Thu, 22 May 2008 11:01:00 -0700 Subject: Hauling gear around a NANOG meeting In-Reply-To: <4835A834.4040303@ttec.com> References: <4835A834.4040303@ttec.com> Message-ID: <4835B4DC.7080702@deaddrop.org> Joe Maimon wrote: > Looking for some advice for a first-timer. > > What are your recommendation regarding gear? [snippy] > - the whole normal kit&caboodle, wheeled backpack thing Personally, I'd go with the latter. I've done it all, from backpack (that'll start to be a nuisance, trust me) to laptop only, to a small square cart thing (I don't remember what they're called) that I could dump the laptop and various stuffs in. My current bag is swiss army (I *love* it), can hold two laptops if necessary (and I've been there), and whatever else I think I might need, depending on the conference/meeting/work assignment that I'm involved with. I even carry a tool set, for stuffing in checked luggage when flying, and patch cables, but for you, that's probably overkill. One of the things that makes me popular is that I carry a PowerSquid (one of the best inventions *evaire*), just in case. The case is easier on your back, has nice handles, and even a shoulder strap, if you need them, has pockets and compartments forever, and fits in the overhead. I think it's called a Victorinox. -- Die Gedanken sind frei From pauldotwall at gmail.com Thu May 22 13:07:48 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 22 May 2008 14:07:48 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <4835A834.4040303@ttec.com> References: <4835A834.4040303@ttec.com> Message-ID: <620fd17c0805221107t3b75ef4bta06b9e58da205d24@mail.gmail.com> I've not been to the conference myself, but I hear laptop and charger is a good plan. Following the advice of our host, David Diaz (Telx), care should be exercised to make sure your laptop bag does not have the text "LAPTOP" printed on it, as that would make it a target for thieves. Additionally, don't wear white iPod earbuds, as that will likely lead to you getting mugged on the subway, or zapped by lightning in Central Park. Paul On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: > Looking for some advice for a first-timer. > > What are your recommendation regarding gear? > > - laptop and charger only > > - laptop with small bag > > - the whole normal kit&caboodle, wheeled backpack thing > > Thanks, > > Joe > > From r.hyunseog at ieee.org Thu May 22 13:19:59 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Thu, 22 May 2008 13:19:59 -0500 Subject: Hauling gear around a NANOG meeting In-Reply-To: <4835A834.4040303@ttec.com> References: <4835A834.4040303@ttec.com> Message-ID: <4835B94F.6030004@ieee.org> Third option. ^.^ You may need to have notepad, pens, and other stuffs. Also when you collect brochure or something like that, it is easy to carry around. Hyun Joe Maimon wrote: > Looking for some advice for a first-timer. > > What are your recommendation regarding gear? > > - laptop and charger only > > - laptop with small bag > > - the whole normal kit&caboodle, wheeled backpack thing > > Thanks, > > Joe > > > From Charles.Yamasaki at move.com Thu May 22 13:30:42 2008 From: Charles.Yamasaki at move.com (Yamasaki, Charles) Date: Thu, 22 May 2008 11:30:42 -0700 Subject: Splitting ARIN assignment In-Reply-To: <4835B14B.9000901@ieee.org> Message-ID: > Make sure that your two location is inter-connected directly, Why is this required? If you put static routes to point the remote /21 to the upstream provider on each side wouldn't that take care of the origin AS loop? On 5/22/08 10:45 AM, "Hyunseog Ryu" wrote: > I I were you, I will advertise as following. > > /21 Original ARIN allocation > /22 First half of ARIN allocation > /22 second half of ARIN allocation > > In this case, you will have backup /21 route just in case of filtering > or something like that. > But in normal case, traffic will be routed based on more specific > routes, which are /22s. > > In some case, upstream ISPs may filter based on strict filtering, which > means all BGP prefix announcement should be matched with registered CIDR > info including subnet size. > In most case, upstream ISP will accept any subnet size between > registered size (/21) and /24 size. > > Because of load sharing and traffic engineering requirement, it is easy > to handle those situation with /22 size. > > Make sure that your two location is inter-connected directly, and have > enough capacity when each of location upstream connection goes down. > > > Hyun > > > ames Kelty wrote: >> Hey all, >> >> I'm looking for an opinion from the group. I have an ARIN /21 >> assignment and a new requirement for a second data center. Rather than >> ask for another assignment, I would like to advertise one /22 from one >> location and the other /22 from the second location both with the same >> asn. My apps will work that way, so I don't have an issue internally, >> but I'm looking for a broader base opinion on that. >> >> Thanks a lot! >> >> -James >> >> >> >> > > Charles Yamasaki Manager Network Engineering Move Inc. 30700 Russell Ranch Rd Westlake Village, CA 91362 O: 805.557.3829 M: 805.603.6492 F: 805.557.3870 From r.hyunseog at ieee.org Thu May 22 13:41:47 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Thu, 22 May 2008 13:41:47 -0500 Subject: Splitting ARIN assignment In-Reply-To: References: Message-ID: <4835BE6B.7030801@ieee.org> What if upstream connection - Internet - goes down? If you have fully redundant system implemented from both locations, so you don't need another site for operation, that will be fine. But in normal situation, there is some dependency. Also, if you have massive backup and/or data transaction between two location, it may good to have inter-connection - private link - between both location. Origin AS loop can be resolved by BGP configuration feature, or putting default route back to upstream connection. So probably that's not an issue at all. Real issue will be data/operation dependency between two locations such as DNS server IP address and things like that. If you are 100% sure about that there is no dependency between two locations, you may omit the requirement for inter-connection between two locations. Hyun Yamasaki, Charles wrote: >> Make sure that your two location is inter-connected directly, >> > > Why is this required? If you put static routes to point the remote /21 to > the upstream provider on each side wouldn't that take care of the origin AS > loop? > > > > On 5/22/08 10:45 AM, "Hyunseog Ryu" wrote: > > >> I I were you, I will advertise as following. >> >> /21 Original ARIN allocation >> /22 First half of ARIN allocation >> /22 second half of ARIN allocation >> >> In this case, you will have backup /21 route just in case of filtering >> or something like that. >> But in normal case, traffic will be routed based on more specific >> routes, which are /22s. >> >> In some case, upstream ISPs may filter based on strict filtering, which >> means all BGP prefix announcement should be matched with registered CIDR >> info including subnet size. >> In most case, upstream ISP will accept any subnet size between >> registered size (/21) and /24 size. >> >> Because of load sharing and traffic engineering requirement, it is easy >> to handle those situation with /22 size. >> >> Make sure that your two location is inter-connected directly, and have >> enough capacity when each of location upstream connection goes down. >> >> >> Hyun >> >> >> ames Kelty wrote: >> >>> Hey all, >>> >>> I'm looking for an opinion from the group. I have an ARIN /21 >>> assignment and a new requirement for a second data center. Rather than >>> ask for another assignment, I would like to advertise one /22 from one >>> location and the other /22 from the second location both with the same >>> asn. My apps will work that way, so I don't have an issue internally, >>> but I'm looking for a broader base opinion on that. >>> >>> Thanks a lot! >>> >>> -James >>> >>> >>> >>> >>> >> > > Charles Yamasaki > Manager Network Engineering > Move Inc. > 30700 Russell Ranch Rd > Westlake Village, CA 91362 > O: 805.557.3829 > M: 805.603.6492 > F: 805.557.3870 > > > > > From joly at punkcast.com Thu May 22 13:42:04 2008 From: joly at punkcast.com (WWWhatsup) Date: Thu, 22 May 2008 14:42:04 -0400 Subject: Internet Week NY Jun 2 - Jun 9 In-Reply-To: <620fd17c0805221107t3b75ef4bta06b9e58da205d24@mail.gmail.co m> References: <4835A834.4040303@ttec.com> <620fd17c0805221107t3b75ef4bta06b9e58da205d24@mail.gmail.com> Message-ID: <20080522184206.AD896163A12@spunkymail-a10.g.dreamhost.com> > Please note that Internet Week NY coincides with the NANOG meet. Some events may be of interest: http://www.internetweekny.com/schedule/list Joly MacFie http://isoc-ny.org From jmaimon at ttec.com Thu May 22 13:45:17 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 22 May 2008 14:45:17 -0400 Subject: Splitting ARIN assignment In-Reply-To: References: Message-ID: <4835BF3D.7040902@ttec.com> Yamasaki, Charles wrote: >> Make sure that your two location is inter-connected directly, > > Why is this required? If you put static routes to point the remote /21 to > the upstream provider on each side wouldn't that take care of the origin AS > loop? Origin AS is easily handled by the allow-as-in neighbor command and better replaced with more flexible as-path and prefix-lists in route-maps. The interconnection is required to be able to advertise the entire space as a "covering" prefix at both sites. Doing that without interconnectivity and using your static route idea would generate routing loops. From Charles.Yamasaki at move.com Thu May 22 13:50:09 2008 From: Charles.Yamasaki at move.com (Yamasaki, Charles) Date: Thu, 22 May 2008 11:50:09 -0700 Subject: Splitting ARIN assignment In-Reply-To: <4835BF3D.7040902@ttec.com> Message-ID: Sorry, typo'd the /21. He wants to carve into /22. On 5/22/08 11:45 AM, "Joe Maimon" wrote: > > > Yamasaki, Charles wrote: >>> Make sure that your two location is inter-connected directly, >> >> Why is this required? If you put static routes to point the remote /21 to >> the upstream provider on each side wouldn't that take care of the origin AS >> loop? > > Origin AS is easily handled by the allow-as-in neighbor command and > better replaced with more flexible as-path and prefix-lists in route-maps. > > The interconnection is required to be able to advertise the entire space > as a "covering" prefix at both sites. > > Doing that without interconnectivity and using your static route idea > would generate routing loops. Charles Yamasaki Manager Network Engineering Move Inc. 30700 Russell Ranch Rd Westlake Village, CA 91362 O: 805.557.3829 M: 805.603.6492 F: 805.557.3870 From oberman at es.net Thu May 22 13:56:35 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 22 May 2008 11:56:35 -0700 Subject: Hauling gear around a NANOG meeting In-Reply-To: Your message of "Thu, 22 May 2008 14:07:48 EDT." <620fd17c0805221107t3b75ef4bta06b9e58da205d24@mail.gmail.com> Message-ID: <20080522185635.E1C9E45019@ptavv.es.net> > Date: Thu, 22 May 2008 14:07:48 -0400 > From: "Paul Wall" > > I've not been to the conference myself, but I hear laptop and charger > is a good plan. > > Following the advice of our host, David Diaz (Telx), care should be > exercised to make sure your laptop bag does not have the text "LAPTOP" > printed on it, as that would make it a target for thieves. > Additionally, don't wear white iPod earbuds, as that will likely lead > to you getting mugged on the subway, or zapped by lightning in Central > Park. I think some of this is seriously exaggerated. The white earbud thing is pretty silly these days as about half the folks on the subway seem to be wearing them. (Watch out if you have fancy Bose buds, though.) Leaving a backpack unattended ANYWHERE is a really bad idea. A lock is of limited value, but, in a room full of laptops, it makes yours less attractive. If you are just going between your room and te meeting in the hotel, off-load as much as possible. The backpack gets heavy after a while. Don't take it to lunch. Drop it in your room. Marriott has always provided pads and pens at the meeting, although I prefer my own pen and keep most notes on my laptop. As far as safety, the parts in lower Manhattan and Brooklyn Heights where we will mostly be is safer than some other places NANOG has met. (I won't get specific as I don't want to inspire people from those places to fill my mailbox with defenses.) Be careful. Don't wander alone after dark. Common sense, an uncommon thing, is your best guide. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Paul > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: > > Looking for some advice for a first-timer. > > > > What are your recommendation regarding gear? > > > > - laptop and charger only > > > > - laptop with small bag > > > > - the whole normal kit&caboodle, wheeled backpack thing > > > > Thanks, > > > > Joe > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From hannigan at verneglobal.com Thu May 22 14:57:55 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 22 May 2008 19:57:55 -0000 Subject: Hauling gear around a NANOG meeting Message-ID: We're in the Marriot, not a crack house. And it's NYC, not Sao Paolo. I think my friend Dave needs to actually spend some time in New York City. :). Don't buy any bridges. And if you're driving, stay off the cross Bronx Expresseway. It's moidah during rush hour. -M< ----- Original Message ----- From: Paul Wall To: Joe Maimon Cc: nanog at nanog.org Sent: Thu May 22 18:07:48 2008 Subject: Re: Hauling gear around a NANOG meeting I've not been to the conference myself, but I hear laptop and charger is a good plan. Following the advice of our host, David Diaz (Telx), care should be exercised to make sure your laptop bag does not have the text "LAPTOP" printed on it, as that would make it a target for thieves. Additionally, don't wear white iPod earbuds, as that will likely lead to you getting mugged on the subway, or zapped by lightning in Central Park. Paul On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: > Looking for some advice for a first-timer. > > What are your recommendation regarding gear? > > - laptop and charger only > > - laptop with small bag > > - the whole normal kit&caboodle, wheeled backpack thing > > Thanks, > > Joe > > From davediaz at gmail.com Thu May 22 15:13:29 2008 From: davediaz at gmail.com (David Diaz) Date: Thu, 22 May 2008 16:13:29 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: References: Message-ID: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> Dave as in David D has spent TOO much time in NY. I gave basic smart tips for any big city. Just wear a Telx hat and you are safe. That is like the crips there in NY. Lots of respect from the gangs. Otherwise no one can make bets with their bookie, fo'get 'about it.... Enjoy your travels everyone! Come early, stay long, network with all! David The Host of Nanog43 in The City! On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > > We're in the Marriot, not a crack house. And it's NYC, not Sao > Paolo. I think my friend Dave needs to actually spend some time in > New York City. :). > > Don't buy any bridges. And if you're driving, stay off the cross > Bronx Expresseway. It's moidah during rush hour. > > -M< > > > > ----- Original Message ----- > From: Paul Wall > To: Joe Maimon > Cc: nanog at nanog.org > Sent: Thu May 22 18:07:48 2008 > Subject: Re: Hauling gear around a NANOG meeting > > I've not been to the conference myself, but I hear laptop and charger > is a good plan. > > Following the advice of our host, David Diaz (Telx), care should be > exercised to make sure your laptop bag does not have the text "LAPTOP" > printed on it, as that would make it a target for thieves. > Additionally, don't wear white iPod earbuds, as that will likely lead > to you getting mugged on the subway, or zapped by lightning in Central > Park. > > Paul > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: >> Looking for some advice for a first-timer. >> >> What are your recommendation regarding gear? >> >> - laptop and charger only >> >> - laptop with small bag >> >> - the whole normal kit&caboodle, wheeled backpack thing >> >> Thanks, >> >> Joe >> >> > From Rod.Beck at hiberniaatlantic.com Thu May 22 15:43:37 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 22 May 2008 21:43:37 +0100 Subject: Hauling gear around a NANOG meeting References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> Message-ID: <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> I hate to break the news to the New York bashers, but New York is one of the safest American cities. This is not a controversial statement. New York has a lower incidence of crime than Miami, Detroit, Seattle, Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. http://www.baruch.cuny.edu/nycdata/chapter09_files/sheet002.htm I refuse to go to NANOG events in Florida - now there is a dangerous place as well as a foreign country ... Roderick S. Beck Director of European Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. Landline: 33-1-4346-3209. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: David Diaz [mailto:davediaz at gmail.com] Sent: Thu 5/22/2008 9:13 PM To: Martin Hannigan Cc: nanog at nanog.org Subject: Re: Hauling gear around a NANOG meeting Dave as in David D has spent TOO much time in NY. I gave basic smart tips for any big city. Just wear a Telx hat and you are safe. That is like the crips there in NY. Lots of respect from the gangs. Otherwise no one can make bets with their bookie, fo'get 'about it.... Enjoy your travels everyone! Come early, stay long, network with all! David The Host of Nanog43 in The City! On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > > We're in the Marriot, not a crack house. And it's NYC, not Sao > Paolo. I think my friend Dave needs to actually spend some time in > New York City. :). > > Don't buy any bridges. And if you're driving, stay off the cross > Bronx Expresseway. It's moidah during rush hour. > > -M< > > > > ----- Original Message ----- > From: Paul Wall > To: Joe Maimon > Cc: nanog at nanog.org > Sent: Thu May 22 18:07:48 2008 > Subject: Re: Hauling gear around a NANOG meeting > > I've not been to the conference myself, but I hear laptop and charger > is a good plan. > > Following the advice of our host, David Diaz (Telx), care should be > exercised to make sure your laptop bag does not have the text "LAPTOP" > printed on it, as that would make it a target for thieves. > Additionally, don't wear white iPod earbuds, as that will likely lead > to you getting mugged on the subway, or zapped by lightning in Central > Park. > > Paul > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: >> Looking for some advice for a first-timer. >> >> What are your recommendation regarding gear? >> >> - laptop and charger only >> >> - laptop with small bag >> >> - the whole normal kit&caboodle, wheeled backpack thing >> >> Thanks, >> >> Joe >> >> > From hannigan at verneglobal.com Thu May 22 15:53:16 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 22 May 2008 20:53:16 -0000 Subject: Hauling gear around a NANOG meeting Message-ID: Heheh. Good tip. Where do we get our shields on Sunday? :) ----- Original Message ----- From: David Diaz To: Martin Hannigan Cc: jmaimon at ttec.com ; nanog at nanog.org Sent: Thu May 22 20:13:29 2008 Subject: Re: Hauling gear around a NANOG meeting Dave as in David D has spent TOO much time in NY. I gave basic smart tips for any big city. Just wear a Telx hat and you are safe. That is like the crips there in NY. Lots of respect from the gangs. Otherwise no one can make bets with their bookie, fo'get 'about it.... Enjoy your travels everyone! Come early, stay long, network with all! David The Host of Nanog43 in The City! On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > > We're in the Marriot, not a crack house. And it's NYC, not Sao > Paolo. I think my friend Dave needs to actually spend some time in > New York City. :). > > Don't buy any bridges. And if you're driving, stay off the cross > Bronx Expresseway. It's moidah during rush hour. > > -M< > > > > ----- Original Message ----- > From: Paul Wall > To: Joe Maimon > Cc: nanog at nanog.org > Sent: Thu May 22 18:07:48 2008 > Subject: Re: Hauling gear around a NANOG meeting > > I've not been to the conference myself, but I hear laptop and charger > is a good plan. > > Following the advice of our host, David Diaz (Telx), care should be > exercised to make sure your laptop bag does not have the text "LAPTOP" > printed on it, as that would make it a target for thieves. > Additionally, don't wear white iPod earbuds, as that will likely lead > to you getting mugged on the subway, or zapped by lightning in Central > Park. > > Paul > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: >> Looking for some advice for a first-timer. >> >> What are your recommendation regarding gear? >> >> - laptop and charger only >> >> - laptop with small bag >> >> - the whole normal kit&caboodle, wheeled backpack thing >> >> Thanks, >> >> Joe >> >> > From copraphage at gmail.com Thu May 22 16:00:15 2008 From: copraphage at gmail.com (Chris McDonald) Date: Thu, 22 May 2008 17:00:15 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: References: Message-ID: <25dbbe250805221400s2babcadel42d161175fb9873c@mail.gmail.com> a glock 27 takes the same magazine as a glock 22. that's good nyc knowledge. On Thu, May 22, 2008 at 4:53 PM, Martin Hannigan wrote: > > > Heheh. Good tip. Where do we get our shields on Sunday? :) > > > > > ----- Original Message ----- > From: David Diaz > To: Martin Hannigan > Cc: jmaimon at ttec.com ; nanog at nanog.org > Sent: Thu May 22 20:13:29 2008 > Subject: Re: Hauling gear around a NANOG meeting > > Dave as in David D has spent TOO much time in NY. > > I gave basic smart tips for any big city. Just wear a Telx hat and > you are safe. That is like the crips there in NY. Lots of respect from > the gangs. Otherwise no one can make bets with their bookie, fo'get > 'about it.... > > > Enjoy your travels everyone! Come early, stay long, network with all! > > David > The Host of Nanog43 in The City! > > > > On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > > > > > We're in the Marriot, not a crack house. And it's NYC, not Sao > > Paolo. I think my friend Dave needs to actually spend some time in > > New York City. :). > > > > Don't buy any bridges. And if you're driving, stay off the cross > > Bronx Expresseway. It's moidah during rush hour. > > > > -M< > > > > > > > > ----- Original Message ----- > > From: Paul Wall > > To: Joe Maimon > > Cc: nanog at nanog.org > > Sent: Thu May 22 18:07:48 2008 > > Subject: Re: Hauling gear around a NANOG meeting > > > > I've not been to the conference myself, but I hear laptop and charger > > is a good plan. > > > > Following the advice of our host, David Diaz (Telx), care should be > > exercised to make sure your laptop bag does not have the text "LAPTOP" > > printed on it, as that would make it a target for thieves. > > Additionally, don't wear white iPod earbuds, as that will likely lead > > to you getting mugged on the subway, or zapped by lightning in Central > > Park. > > > > Paul > > > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: > >> Looking for some advice for a first-timer. > >> > >> What are your recommendation regarding gear? > >> > >> - laptop and charger only > >> > >> - laptop with small bag > >> > >> - the whole normal kit&caboodle, wheeled backpack thing > >> > >> Thanks, > >> > >> Joe > >> > >> > > > > From sil at infiltrated.net Thu May 22 16:03:40 2008 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 22 May 2008 17:03:40 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <25dbbe250805221400s2babcadel42d161175fb9873c@mail.gmail.com> References: <25dbbe250805221400s2babcadel42d161175fb9873c@mail.gmail.com> Message-ID: <4835DFAC.9060706@infiltrated.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris McDonald wrote: | a glock 27 takes the same magazine as a glock 22. that's good nyc knowledge. |> Heheh. Good tip. Where do we get our shields on Sunday? :) Nothing to be afraid of in NYC especially with NANOG coming to town http://www.infiltrated.net/spx/swat-team-posing.jpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSDXfq4OeOV2sx4+mAQK6WhAArpa+RCNZ/STP89zxzUsOHUedy8TbqbjA uOZaSKZtqX06I69/aRFnlHc9jt16QG91DFJlzXwgWh6I4d6KaQYv1dvFPZm3z6L4 Fg613r8l3W2+9evDM2oK9ZYv6YoOqIwkqohAuQlw9kERZfhZNanBl/Qv6BJXumCy A9/JYrOvPbrU9Zrep/9Sg+/6Vd59Bp7bSQWSYto1WTyemv5TCIxbyBXnOH0Yhr5G aaPEz/nKOs4gUfg08uxCQw6Qm0SLHZdoZQ7n/lMTRQbnZIfaKk8znYQg48SiiX0q deBxcInXXpOI8hsvS+tqB2++sba5iF9Clbwp1h1iV/Ze1c8BCKtgZL8u2HMw9HqZ 4V+Pjny0Rbpw7sPujBH6XouxdiotDJfENdROlNbHCXaEdlT/3uhDPo77/h8YsKe8 W+Fs+na1PkLm1QoPrTucFN16Pr/hQT0v9h2fzsVS0tj/r1Xb7n+XoCgBrfGaczuc oGAszQY0WGiY+gJSdMgwowDNU1EzzM+Nca2GgN+JLjTuHYEoI5K6xzOYp8YJAHfK bi7LttjUnjHtpsdVCiXAStSsn0j22R17bjQ8qfUXueU9KJ6GTRoJwcnPlN2MjObY MUJSmqL3C5fwiVyBNrlhw0UrBluxfLWOnP6PP83IIjxWvTtEx8Sbjkpob5Lp/4r6 Blh1g2VrM4g= =kt0x -----END PGP SIGNATURE----- From Rod.Beck at hiberniaatlantic.com Thu May 22 16:08:06 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 22 May 2008 22:08:06 +0100 Subject: Hauling gear around a NANOG meeting References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> Message-ID: <71CB284A12EDA54880FF588A8BAC0BE221FEBB@ernie.HiberniaAtlantic.local> There is no disagreement between Mr. Rubenstein and myself. :) Roderick S. Beck Director of European Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. Landline: 33-1-4346-3209. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. -----Original Message----- From: Alex Rubenstein [mailto:alex at corp.nac.net] Sent: Thu 5/22/2008 10:06 PM To: Rod Beck; David Diaz; Martin Hannigan Cc: nanog at nanog.org Subject: RE: Hauling gear around a NANOG meeting > I hate to break the news to the New York bashers, but New York is one of > the safest American cities. This is not a controversial statement. While I generally agree with what Rod is saying, saying "NYC is safe" is like saying "all routers are cisco" There are safe areas, and there are not safe areas. I don't know how the Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be overly concerned. And, since people going to NANOG tend to have a herding instinct, there shouldn't be a problem. > New York has a lower incidence of crime than Miami, Detroit, Seattle, > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. Yes, but in at least most of those locations, my Florida or Utah CCW is valid. From alex at corp.nac.net Thu May 22 16:10:29 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 22 May 2008 17:10:29 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> Message-ID: <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> > I hate to break the news to the New York bashers, but New York is one of > the safest American cities. This is not a controversial statement. While I generally agree with what Rod is saying, saying "NYC is safe" is like saying "all routers are cisco" There are safe areas, and there are not safe areas. I don't know how the Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be overly concerned. And, since people going to NANOG tend to have a herding instinct, there shouldn't be a problem. > New York has a lower incidence of crime than Miami, Detroit, Seattle, > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. Yes, but in at least most of those locations, my Florida or Utah CCW is valid. From cmarshall at dyndns.com Thu May 22 16:15:36 2008 From: cmarshall at dyndns.com (Chip Marshall) Date: Thu, 22 May 2008 17:15:36 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> Message-ID: <20080522211536.GA4218@dyndns.com> On May 22, 2008, Rod Beck sent me the following: > I hate to break the news to the New York bashers, but New York is one > of the safest American cities. This is not a controversial statement. > > New York has a lower incidence of crime than Miami, Detroit, Seattle, > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. > > http://www.baruch.cuny.edu/nycdata/chapter09_files/sheet002.htm > > I refuse to go to NANOG events in Florida - now there is a dangerous > place as well as a foreign country ... Interesting data, but potentially skewed due to population differences. New York City's metropolitan area population is 18,818,536, whereas Miami is only 5,919,036. Miami: 7116.2 per 100,000 = 0.071162 crimes per person 0.071162 * 5919036 = 421,210.44 crimes NYC: 2771.0 per 100,000 = 0.02771 crimes per person 0.02771 * 18818536 = 521,461.63 crimes So it's not really that there is less crime, there's just less chance of a particular person being the perpetrator or victim. Also, my population numbers are based on 2006 data provided by Wikipedia, and therefore are not to be trusted. -- Chip Marshall System Administrator Dynamic Network Services, Inc. http://www.dyndns.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From hannigan at verneglobal.com Thu May 22 16:16:15 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 22 May 2008 21:16:15 -0000 Subject: Hauling gear around a NANOG meeting Message-ID: Seriously, Dave was taken out of context by the usual suspects. Brooklyn / NYC is pretty OK. Oh, ObOp! Thanks a ton, Telx! ----- Original Message ----- From: Chris McDonald To: Martin Hannigan Cc: davediaz at gmail.com ; nanog at nanog.org Sent: Thu May 22 21:00:15 2008 Subject: Re: Hauling gear around a NANOG meeting a glock 27 takes the same magazine as a glock 22. that's good nyc knowledge. On Thu, May 22, 2008 at 4:53 PM, Martin Hannigan wrote: Heheh. Good tip. Where do we get our shields on Sunday? :) ----- Original Message ----- From: David Diaz To: Martin Hannigan Cc: jmaimon at ttec.com ; nanog at nanog.org Sent: Thu May 22 20:13:29 2008 Subject: Re: Hauling gear around a NANOG meeting Dave as in David D has spent TOO much time in NY. I gave basic smart tips for any big city. Just wear a Telx hat and you are safe. That is like the crips there in NY. Lots of respect from the gangs. Otherwise no one can make bets with their bookie, fo'get 'about it.... Enjoy your travels everyone! Come early, stay long, network with all! David The Host of Nanog43 in The City! On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > > We're in the Marriot, not a crack house. And it's NYC, not Sao > Paolo. I think my friend Dave needs to actually spend some time in > New York City. :). > > Don't buy any bridges. And if you're driving, stay off the cross > Bronx Expresseway. It's moidah during rush hour. > > -M< > > > > ----- Original Message ----- > From: Paul Wall > To: Joe Maimon > Cc: nanog at nanog.org > Sent: Thu May 22 18:07:48 2008 > Subject: Re: Hauling gear around a NANOG meeting > > I've not been to the conference myself, but I hear laptop and charger > is a good plan. > > Following the advice of our host, David Diaz (Telx), care should be > exercised to make sure your laptop bag does not have the text "LAPTOP" > printed on it, as that would make it a target for thieves. > Additionally, don't wear white iPod earbuds, as that will likely lead > to you getting mugged on the subway, or zapped by lightning in Central > Park. > > Paul > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: >> Looking for some advice for a first-timer. >> >> What are your recommendation regarding gear? >> >> - laptop and charger only >> >> - laptop with small bag >> >> - the whole normal kit&caboodle, wheeled backpack thing >> >> Thanks, >> >> Joe >> >> > From jra at baylink.com Thu May 22 16:16:32 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 22 May 2008 17:16:32 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <4835B4DC.7080702@deaddrop.org> References: <4835A834.4040303@ttec.com> <4835B4DC.7080702@deaddrop.org> Message-ID: <20080522211632.GT436@cgi.jachomes.com> On Thu, May 22, 2008 at 11:01:00AM -0700, Lynda wrote: > One of the things that makes me popular is that I carry a PowerSquid > (one of the best inventions *evaire*), just in case. They're nice, but the little 8-outlet (5 + 3-transformer) yellow and black thing from Walmart is just as useful, and only 8 bucks. With cable management. -- j -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From christian at visr.org Thu May 22 16:18:09 2008 From: christian at visr.org (Christian) Date: Thu, 22 May 2008 17:18:09 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> Message-ID: <9b62cf2f0805221418q53fd5f86qb45a4fe2d2cb4c87@mail.gmail.com> the area in BKLYN where the Mariott is fine, its a one of the better neighborhoods - i believe its Brooklyn Heights, though can be confused with DUMBO and downtown brooklyn as they are all adjacent /christian On Thu, May 22, 2008 at 5:10 PM, Alex Rubenstein wrote: > > I hate to break the news to the New York bashers, but New York is one of > > the safest American cities. This is not a controversial statement. > > While I generally agree with what Rod is saying, saying "NYC is safe" is > like saying "all routers are cisco" > > There are safe areas, and there are not safe areas. I don't know how the > Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be overly > concerned. And, since people going to NANOG tend to have a herding > instinct, > there shouldn't be a problem. > > > > New York has a lower incidence of crime than Miami, Detroit, Seattle, > > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. > > Yes, but in at least most of those locations, my Florida or Utah CCW is > valid. > > > > From Valdis.Kletnieks at vt.edu Thu May 22 16:18:42 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 May 2008 17:18:42 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: Your message of "Thu, 22 May 2008 17:10:29 EDT." <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> Message-ID: <26293.1211491122@turing-police.cc.vt.edu> On Thu, 22 May 2008 17:10:29 EDT, Alex Rubenstein said: > Yes, but in at least most of those locations, my Florida or Utah CCW is > valid. That's not a router. Now *that's* a router... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Rod.Beck at hiberniaatlantic.com Thu May 22 16:17:32 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 22 May 2008 22:17:32 +0100 Subject: Hauling gear around a NANOG meeting References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> Message-ID: <71CB284A12EDA54880FF588A8BAC0BE221FEBD@ernie.HiberniaAtlantic.local> Now that we have television shows like Miami Vice (which are available here in Paris in French), I expect the American public to be less biased in their views of New York. It is all a question of what cities are used as the background for the crime shows. :) Roderick S. Beck From r.hyunseog at ieee.org Thu May 22 16:19:16 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Thu, 22 May 2008 16:19:16 -0500 Subject: Hauling gear around a NANOG meeting In-Reply-To: <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> <005501c8bc50$4359e6f0$ca0db4d0$@nac.net> Message-ID: <4835E354.2080107@ieee.org> Probably if you stick to common sense, it will be o.k. If you see broken windows and/or lots of graffiti in the wall, probably I wouldn't go there. ^>^ Since you will be seeing more people in NYC area, you may get some stress to see lots of people, but overall it's not that bad. Just stick to your instinct, and common sense. Hyun Alex Rubenstein wrote: >> I hate to break the news to the New York bashers, but New York is one of >> the safest American cities. This is not a controversial statement. >> > > While I generally agree with what Rod is saying, saying "NYC is safe" is > like saying "all routers are cisco" > > There are safe areas, and there are not safe areas. I don't know how the > Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be overly > concerned. And, since people going to NANOG tend to have a herding instinct, > there shouldn't be a problem. > > > >> New York has a lower incidence of crime than Miami, Detroit, Seattle, >> Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. >> > > Yes, but in at least most of those locations, my Florida or Utah CCW is > valid. > > > > > > From andrewy at webair.com Thu May 22 16:25:48 2008 From: andrewy at webair.com (andrew young) Date: Thu, 22 May 2008 17:25:48 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: References: Message-ID: <1211491548.11420.10.camel@andrewy-desktop> Once you all get there, you will realize how awesome this place is. There is nothing to be afraid. Just remember, carry around an unlimited metrocard and a subway map. Taking cabs everything can get expensive. for those that are planning to spend the weekend in NYC, be sure to check out http://www.bigapplebbq.org/ its huge every year. - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy at webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare at webair.com ------------------------------------- On Thu, 2008-05-22 at 21:16 +0000, Martin Hannigan wrote: > Seriously, Dave was taken out of context by the usual suspects. Brooklyn / NYC is pretty OK. > > Oh, ObOp! Thanks a ton, Telx! > > > > ----- Original Message ----- > From: Chris McDonald > To: Martin Hannigan > Cc: davediaz at gmail.com ; nanog at nanog.org > Sent: Thu May 22 21:00:15 2008 > Subject: Re: Hauling gear around a NANOG meeting > > a glock 27 takes the same magazine as a glock 22. that's good nyc knowledge. > > > > > > > > > On Thu, May 22, 2008 at 4:53 PM, Martin Hannigan wrote: > > > > > Heheh. Good tip. Where do we get our shields on Sunday? :) > > > > > ----- Original Message ----- > From: David Diaz > To: Martin Hannigan > Cc: jmaimon at ttec.com ; nanog at nanog.org > Sent: Thu May 22 20:13:29 2008 > Subject: Re: Hauling gear around a NANOG meeting > > Dave as in David D has spent TOO much time in NY. > > I gave basic smart tips for any big city. Just wear a Telx hat and > you are safe. That is like the crips there in NY. Lots of respect from > the gangs. Otherwise no one can make bets with their bookie, fo'get > 'about it.... > > > Enjoy your travels everyone! Come early, stay long, network with all! > > David > The Host of Nanog43 in The City! > > > > On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > > > > > We're in the Marriot, not a crack house. And it's NYC, not Sao > > Paolo. I think my friend Dave needs to actually spend some time in > > New York City. :). > > > > Don't buy any bridges. And if you're driving, stay off the cross > > Bronx Expresseway. It's moidah during rush hour. > > > > -M< > > > > > > > > ----- Original Message ----- > > From: Paul Wall > > To: Joe Maimon > > Cc: nanog at nanog.org > > Sent: Thu May 22 18:07:48 2008 > > Subject: Re: Hauling gear around a NANOG meeting > > > > I've not been to the conference myself, but I hear laptop and charger > > is a good plan. > > > > Following the advice of our host, David Diaz (Telx), care should be > > exercised to make sure your laptop bag does not have the text "LAPTOP" > > printed on it, as that would make it a target for thieves. > > Additionally, don't wear white iPod earbuds, as that will likely lead > > to you getting mugged on the subway, or zapped by lightning in Central > > Park. > > > > Paul > > > > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: > >> Looking for some advice for a first-timer. > >> > >> What are your recommendation regarding gear? > >> > >> - laptop and charger only > >> > >> - laptop with small bag > >> > >> - the whole normal kit&caboodle, wheeled backpack thing > >> > >> Thanks, > >> > >> Joe > >> > >> > > > > > > From r.hyunseog at ieee.org Thu May 22 16:41:43 2008 From: r.hyunseog at ieee.org (Hyunseog Ryu) Date: Thu, 22 May 2008 16:41:43 -0500 Subject: Hauling gear around a NANOG meeting In-Reply-To: <1211491548.11420.10.camel@andrewy-desktop> References: <1211491548.11420.10.camel@andrewy-desktop> Message-ID: <4835E897.1010801@ieee.org> One more thing... Rent-car may be not a good idea. Sometimes it's hard to find the parking spot. ^.^ As Andrew said, it will be better to use public transportations such as cab, bus, and sub-way. It may take more time, but sometimes the driving style of New Yorker may be a little bit offensive, and finding parking lot may be a challenge. :-) If you are one of owls, there are plenty of places you can visit in night/early morning when you are not in the mood for sleeping ^>^ Hyun andrew young wrote: > Once you all get there, you will realize how awesome this place is. > There is nothing to be afraid. Just remember, carry around an unlimited > metrocard and a subway map. Taking cabs everything can get expensive. > > for those that are planning to spend the weekend in NYC, be sure to > check out http://www.bigapplebbq.org/ its huge every year. > - > ------------------------------------ > Andrew Young > Webair Internet Development, Inc > Phone: 1 866 WEBAIR 1 > FAX: 516.938.5100 > http://www.webair.com > andrewy at webair.com > ------------------------------------- > We are interested in any feedback you might have about the service > you received. Please contact our technical support consumer care manager > directly at 1.866.WEBAIR1 or e-mail customercare at webair.com > ------------------------------------- > > > On Thu, 2008-05-22 at 21:16 +0000, Martin Hannigan wrote: > > >> Seriously, Dave was taken out of context by the usual suspects. Brooklyn / NYC is pretty OK. >> >> Oh, ObOp! Thanks a ton, Telx! >> >> >> >> ----- Original Message ----- >> From: Chris McDonald >> To: Martin Hannigan >> Cc: davediaz at gmail.com ; nanog at nanog.org >> Sent: Thu May 22 21:00:15 2008 >> Subject: Re: Hauling gear around a NANOG meeting >> >> a glock 27 takes the same magazine as a glock 22. that's good nyc knowledge. >> >> >> >> >> >> >> >> >> On Thu, May 22, 2008 at 4:53 PM, Martin Hannigan wrote: >> >> >> >> >> Heheh. Good tip. Where do we get our shields on Sunday? :) >> >> >> >> >> ----- Original Message ----- >> From: David Diaz >> To: Martin Hannigan >> Cc: jmaimon at ttec.com ; nanog at nanog.org >> Sent: Thu May 22 20:13:29 2008 >> Subject: Re: Hauling gear around a NANOG meeting >> >> Dave as in David D has spent TOO much time in NY. >> >> I gave basic smart tips for any big city. Just wear a Telx hat and >> you are safe. That is like the crips there in NY. Lots of respect from >> the gangs. Otherwise no one can make bets with their bookie, fo'get >> 'about it.... >> >> >> Enjoy your travels everyone! Come early, stay long, network with all! >> >> David >> The Host of Nanog43 in The City! >> >> >> >> On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: >> >> > >> > We're in the Marriot, not a crack house. And it's NYC, not Sao >> > Paolo. I think my friend Dave needs to actually spend some time in >> > New York City. :). >> > >> > Don't buy any bridges. And if you're driving, stay off the cross >> > Bronx Expresseway. It's moidah during rush hour. >> > >> > -M< >> > >> > >> > >> > ----- Original Message ----- >> > From: Paul Wall >> > To: Joe Maimon >> > Cc: nanog at nanog.org >> > Sent: Thu May 22 18:07:48 2008 >> > Subject: Re: Hauling gear around a NANOG meeting >> > >> > I've not been to the conference myself, but I hear laptop and charger >> > is a good plan. >> > >> > Following the advice of our host, David Diaz (Telx), care should be >> > exercised to make sure your laptop bag does not have the text "LAPTOP" >> > printed on it, as that would make it a target for thieves. >> > Additionally, don't wear white iPod earbuds, as that will likely lead >> > to you getting mugged on the subway, or zapped by lightning in Central >> > Park. >> > >> > Paul >> > >> > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: >> >> Looking for some advice for a first-timer. >> >> >> >> What are your recommendation regarding gear? >> >> >> >> - laptop and charger only >> >> >> >> - laptop with small bag >> >> >> >> - the whole normal kit&caboodle, wheeled backpack thing >> >> >> >> Thanks, >> >> >> >> Joe >> >> >> >> >> > >> >> >> >> >> > > > From yahoo at jimpop.com Thu May 22 16:46:50 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 22 May 2008 17:46:50 -0400 Subject: Hughes Network In-Reply-To: References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> Message-ID: <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> On Thu, May 22, 2008 at 1:39 PM, Jason J. W. Williams wrote: > Has anyone else noticed that the [NANOG] prefix has been missing > intermittently from the list traffic over the last couple of days? This was planned, and then announced approx 5 days ago. You are subscribed to nanog-announce, right? ;-) -Jim P. From andrewy at webair.com Thu May 22 16:49:21 2008 From: andrewy at webair.com (andrew young) Date: Thu, 22 May 2008 17:49:21 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <4835E897.1010801@ieee.org> References: <1211491548.11420.10.camel@andrewy-desktop> <4835E897.1010801@ieee.org> Message-ID: <1211492961.11420.17.camel@andrewy-desktop> some useful links for getting around NYC using public transportation: http://www.hopstop.com/ http://www.mta.info/mta/maps.htm http://tripplanner.mta.info/ - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy at webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare at webair.com ------------------------------------- On Thu, 2008-05-22 at 16:41 -0500, Hyunseog Ryu wrote: > One more thing... > Rent-car may be not a good idea. > Sometimes it's hard to find the parking spot. ^.^ > As Andrew said, it will be better to use public transportations such as > cab, bus, and sub-way. > It may take more time, but sometimes the driving style of New Yorker may > be a little bit offensive, and finding parking lot may be a challenge. :-) > If you are one of owls, there are plenty of places you can visit in > night/early morning when you are not in the mood for sleeping ^>^ > > Hyun > > > andrew young wrote: > > Once you all get there, you will realize how awesome this place is. > > There is nothing to be afraid. Just remember, carry around an unlimited > > metrocard and a subway map. Taking cabs everything can get expensive. > > > > for those that are planning to spend the weekend in NYC, be sure to > > check out http://www.bigapplebbq.org/ its huge every year. > > - > > ------------------------------------ > > Andrew Young > > Webair Internet Development, Inc > > Phone: 1 866 WEBAIR 1 > > FAX: 516.938.5100 > > http://www.webair.com > > andrewy at webair.com > > ------------------------------------- > > We are interested in any feedback you might have about the service > > you received. Please contact our technical support consumer care manager > > directly at 1.866.WEBAIR1 or e-mail customercare at webair.com > > ------------------------------------- > > > > > > On Thu, 2008-05-22 at 21:16 +0000, Martin Hannigan wrote: > > > > > >> Seriously, Dave was taken out of context by the usual suspects. Brooklyn / NYC is pretty OK. > >> > >> Oh, ObOp! Thanks a ton, Telx! > >> > >> > >> > >> ----- Original Message ----- > >> From: Chris McDonald > >> To: Martin Hannigan > >> Cc: davediaz at gmail.com ; nanog at nanog.org > >> Sent: Thu May 22 21:00:15 2008 > >> Subject: Re: Hauling gear around a NANOG meeting > >> > >> a glock 27 takes the same magazine as a glock 22. that's good nyc knowledge. > >> > >> > >> > >> > >> > >> > >> > >> > >> On Thu, May 22, 2008 at 4:53 PM, Martin Hannigan wrote: > >> > >> > >> > >> > >> Heheh. Good tip. Where do we get our shields on Sunday? :) > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: David Diaz > >> To: Martin Hannigan > >> Cc: jmaimon at ttec.com ; nanog at nanog.org > >> Sent: Thu May 22 20:13:29 2008 > >> Subject: Re: Hauling gear around a NANOG meeting > >> > >> Dave as in David D has spent TOO much time in NY. > >> > >> I gave basic smart tips for any big city. Just wear a Telx hat and > >> you are safe. That is like the crips there in NY. Lots of respect from > >> the gangs. Otherwise no one can make bets with their bookie, fo'get > >> 'about it.... > >> > >> > >> Enjoy your travels everyone! Come early, stay long, network with all! > >> > >> David > >> The Host of Nanog43 in The City! > >> > >> > >> > >> On May 22, 2008, at 3:57 PM, Martin Hannigan wrote: > >> > >> > > >> > We're in the Marriot, not a crack house. And it's NYC, not Sao > >> > Paolo. I think my friend Dave needs to actually spend some time in > >> > New York City. :). > >> > > >> > Don't buy any bridges. And if you're driving, stay off the cross > >> > Bronx Expresseway. It's moidah during rush hour. > >> > > >> > -M< > >> > > >> > > >> > > >> > ----- Original Message ----- > >> > From: Paul Wall > >> > To: Joe Maimon > >> > Cc: nanog at nanog.org > >> > Sent: Thu May 22 18:07:48 2008 > >> > Subject: Re: Hauling gear around a NANOG meeting > >> > > >> > I've not been to the conference myself, but I hear laptop and charger > >> > is a good plan. > >> > > >> > Following the advice of our host, David Diaz (Telx), care should be > >> > exercised to make sure your laptop bag does not have the text "LAPTOP" > >> > printed on it, as that would make it a target for thieves. > >> > Additionally, don't wear white iPod earbuds, as that will likely lead > >> > to you getting mugged on the subway, or zapped by lightning in Central > >> > Park. > >> > > >> > Paul > >> > > >> > On Thu, May 22, 2008 at 1:07 PM, Joe Maimon wrote: > >> >> Looking for some advice for a first-timer. > >> >> > >> >> What are your recommendation regarding gear? > >> >> > >> >> - laptop and charger only > >> >> > >> >> - laptop with small bag > >> >> > >> >> - the whole normal kit&caboodle, wheeled backpack thing > >> >> > >> >> Thanks, > >> >> > >> >> Joe > >> >> > >> >> > >> > > >> > >> > >> > >> > >> > > > > > > From williamsjj at digitar.com Thu May 22 16:50:34 2008 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Thu, 22 May 2008 15:50:34 -0600 Subject: Hughes Network In-Reply-To: <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local><004601c8bc19$72d81ff0$1401a8c0@E520><15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> Message-ID: Guess I missed it. I remember the announcement for the move from merit.edu to nanog.org. -J --- Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com E: williamsjj at digitar.com V: 208-343-8520 M: 208-863-0727 F: 208-322-8520 XMPP: williamsjj at digitar.com -----Original Message----- From: Jim Popovitch [mailto:yahoo at jimpop.com] Sent: Thursday, May 22, 2008 3:47 PM To: nanog Subject: Re: Hughes Network On Thu, May 22, 2008 at 1:39 PM, Jason J. W. Williams wrote: > Has anyone else noticed that the [NANOG] prefix has been missing > intermittently from the list traffic over the last couple of days? This was planned, and then announced approx 5 days ago. You are subscribed to nanog-announce, right? ;-) -Jim P. !SIG:4835ea2f71591632796761! From williamsjj at digitar.com Thu May 22 16:51:56 2008 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Thu, 22 May 2008 15:51:56 -0600 Subject: Hughes Network In-Reply-To: <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local><004601c8bc19$72d81ff0$1401a8c0@E520><15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> Message-ID: Actually, I'm not subscribed to nanog-announce. -J --- Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com E: williamsjj at digitar.com V: 208-343-8520 M: 208-863-0727 F: 208-322-8520 XMPP: williamsjj at digitar.com -----Original Message----- From: Jim Popovitch [mailto:yahoo at jimpop.com] Sent: Thursday, May 22, 2008 3:47 PM To: nanog Subject: Re: Hughes Network On Thu, May 22, 2008 at 1:39 PM, Jason J. W. Williams wrote: > Has anyone else noticed that the [NANOG] prefix has been missing > intermittently from the list traffic over the last couple of days? This was planned, and then announced approx 5 days ago. You are subscribed to nanog-announce, right? ;-) -Jim P. !SIG:4835ea2f71591632796761! From surfer at mauigateway.com Thu May 22 19:03:45 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 22 May 2008 17:03:45 -0700 Subject: Hauling gear around a NANOG meeting Message-ID: <20080522170345.8F3B5AD@resin18.mta.everyone.net> --- Rod.Beck at hiberniaatlantic.com wrote: From: "Rod Beck" Now that we have television shows like Miami Vice (which are available here in Paris in French), I expect the American public to be less biased in their views of New York. It is all a question of what cities are used as the background for the crime shows. :) --------------------------------------------------- Then Honolulu must seem as a crime infested city to the rest of the world. There have been a gazillion shows like that here. (Hawaii 5-0, Magnum PI, etc.) BTW, it's not. :-) scott From yahoo at jimpop.com Thu May 22 21:45:32 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 22 May 2008 22:45:32 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <48361F59.4010800@deaddrop.org> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> Message-ID: <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> On Thu, May 22, 2008 at 9:35 PM, someone wrote: > Add me to the list of never-saw-that. In addition, I just checked the > nanog archives, and there isn't an announcement of that type in the > archives. Below is the full email, with headers, from Monday. Hopefully it will put this issue to rest.... but somehow I doubt that. ;-) -Jim P. Received: by 10.90.53.15 with SMTP id b15cs245753aga; Mon, 19 May 2008 16:02:48 -0700 (PDT) Received: by 10.35.10.13 with SMTP id n13mr12798008pyi.30.1211238167720; Mon, 19 May 2008 16:02:47 -0700 (PDT) Return-Path: Received: from s0.nanog.org (s0.nanog.org [198.108.95.20]) by mx.google.com with ESMTP id s59si4779396pyh.13.2008.05.19.16.02.47; Mon, 19 May 2008 16:02:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of nanog-announce-bounces at nanog.org designates 198.108.95.20 as permitted sender) client-ip=198.108.95.20; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of nanog-announce-bounces at nanog.org designates 198.108.95.20 as permitted sender) smtp.mail=nanog-announce-bounces at nanog.org Received: from localhost ([127.0.0.1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JyENK-0006V5-UV; Mon, 19 May 2008 23:02:38 +0000 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JyENI-0006UC-1L for nanog-announce at nanog.org; Mon, 19 May 2008 23:02:36 +0000 X-IronPort-AV: E=Sophos;i="4.27,512,1204482600"; d="scan'208";a="107943185" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 20 May 2008 04:32:33 +0530 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4JN2XlM012133 for ; Tue, 20 May 2008 07:02:33 +0800 Received: from Philip-PB.local (sin-vpn-client-20-47.cisco.com [10.68.20.47]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4JN2WVp007247 for ; Mon, 19 May 2008 23:02:32 GMT Message-ID: <48320722.70807 at cisco.com> Date: Tue, 20 May 2008 09:02:58 +1000 From: Philip Smith Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: nanog-announce at nanog.org X-Enigmail-Version: 0.95.6 Authentication-Results: hkg-dkim-1; header.From=pfs at cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Subject: [NANOG-announce] email subject tags and footers X-BeenThere: nanog-announce at nanog.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: NANOG-Announce List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: nanog-announce-bounces at nanog.org Hi everyone, Following the discussion on nanog-futures, we'd like to let you all know that the [NANOG] in the subject line and the three extra info lines mailman appends will be dropped from all future messages going to the NANOG list, starting in around 24 hours from now. If any of you have you changed your e-mail filtering to depend on the [NANOG] subject tag, please consider this 24 hours notice to move to another message filtering technique. Best wishes, philip (for the SC) -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From james.cutler at consultant.com Thu May 22 22:16:42 2008 From: james.cutler at consultant.com (James R. Cutler) Date: Thu, 22 May 2008 23:16:42 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> Message-ID: <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> The announcement was made to nanog-announce, but not to nanog. I would expect that there are scads more readers of nanog than of nanog announce. For some, that could cause unexpected results, especially with the 24 hour notice. Corroborative detail below. (Oops, top posting) Regards. On May 22, 2008, at 10:45 PM, Jim Popovitch wrote: > On Thu, May 22, 2008 at 9:35 PM, someone wrote: >> Add me to the list of never-saw-that. In addition, I just checked the >> nanog archives, and there isn't an announcement of that type in the >> archives. > > Below is the full email, with headers, from Monday. Hopefully it will > put this issue to rest.... but somehow I doubt that. ;-) > > -Jim P. > > MIME-Version: 1.0 > To: nanog-announce at nanog.org > X-Enigmail-Version: 0.95.6 > Authentication-Results: hkg-dkim-1; header.From=pfs at cisco.com; > dkim=pass ( > > philip > (for the SC) > -- > > > _______________________________________________ > NANOG-announce mailing list > NANOG-announce at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog-announce > James R. Cutler james.cutler at consultant.com From pfs at cisco.com Fri May 23 02:18:23 2008 From: pfs at cisco.com (Philip Smith) Date: Fri, 23 May 2008 17:18:23 +1000 Subject: nanog / nanog-announce subs (was Re: Announce list: Re: Hughes Network) In-Reply-To: <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> Message-ID: <48366FBF.9020708@cisco.com> Everyone, The main nanog list is subscribed to nanog-announce. So everything sent to nanog-announce should appear on the nanog list too. If folks choose to unsubscribe from the nanog list, they will need to subscribe to nanog-announce to carry on seeing announcements. Hope this clarifies at least this piece for everyone. Yes it seems as though my "subject tags" e-mail sent around 11pm UTC/GMT on Monday didn't get to some folks on the main list; I'll try and find out what happened there. philip SC Chair -- James R. Cutler said the following on 23/5/08 13:16: > The announcement was made to nanog-announce, but not to nanog. I would > expect that there are scads more readers of nanog than of nanog announce. > > For some, that could cause unexpected results, especially with the 24 > hour notice. > > Corroborative detail below. (Oops, top posting) > > Regards. > > On May 22, 2008, at 10:45 PM, Jim Popovitch wrote: > >> On Thu, May 22, 2008 at 9:35 PM, someone wrote: >>> Add me to the list of never-saw-that. In addition, I just checked the >>> nanog archives, and there isn't an announcement of that type in the >>> archives. >> >> Below is the full email, with headers, from Monday. Hopefully it will >> put this issue to rest.... but somehow I doubt that. ;-) >> >> -Jim P. >> >> MIME-Version: 1.0 >> To: nanog-announce at nanog.org >> X-Enigmail-Version: 0.95.6 >> Authentication-Results: hkg-dkim-1; header.From=pfs at cisco.com >> ; dkim=pass ( >> >> philip >> (for the SC) >> -- >> >> >> _______________________________________________ >> NANOG-announce mailing list >> NANOG-announce at nanog.org >> http://mailman.nanog.org/mailman/listinfo/nanog-announce >> > > James R. Cutler > james.cutler at consultant.com > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nanog-futures mailing list > Nanog-futures at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog-futures From rs at seastrom.com Fri May 23 04:44:36 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 23 May 2008 05:44:36 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> (Jim Popovitch's message of "Thu, 22 May 2008 22:45:32 -0400") References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> Message-ID: <86abih1hiz.fsf@seastrom.com> Once upon a time, wasn't nanog@ subscribed to nanog-announce@ ? It appears to not be now. I went looking in my archives for that message-id; the only copy of that mail I got was from you, and I am on both -futures and the main list. Thanks for sending that along, Jim. ---Rob "Jim Popovitch" writes: > On Thu, May 22, 2008 at 9:35 PM, someone wrote: >> Add me to the list of never-saw-that. In addition, I just checked the >> nanog archives, and there isn't an announcement of that type in the >> archives. > > Below is the full email, with headers, from Monday. Hopefully it will > put this issue to rest.... but somehow I doubt that. ;-) > > -Jim P. > > Received: by 10.90.53.15 with SMTP id b15cs245753aga; > Mon, 19 May 2008 16:02:48 -0700 (PDT) > Received: by 10.35.10.13 with SMTP id n13mr12798008pyi.30.1211238167720; > Mon, 19 May 2008 16:02:47 -0700 (PDT) > Return-Path: > Received: from s0.nanog.org (s0.nanog.org [198.108.95.20]) > by mx.google.com with ESMTP id s59si4779396pyh.13.2008.05.19.16.02.47; > Mon, 19 May 2008 16:02:47 -0700 (PDT) > Received-SPF: pass (google.com: best guess record for domain of > nanog-announce-bounces at nanog.org designates 198.108.95.20 as permitted > sender) client-ip=198.108.95.20; > Authentication-Results: mx.google.com; spf=pass (google.com: best > guess record for domain of nanog-announce-bounces at nanog.org designates > 198.108.95.20 as permitted sender) > smtp.mail=nanog-announce-bounces at nanog.org > Received: from localhost ([127.0.0.1] helo=s0.nanog.org) > by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) > (envelope-from ) > id 1JyENK-0006V5-UV; Mon, 19 May 2008 23:02:38 +0000 > Received: from ind-iport-1.cisco.com ([64.104.129.195]) > by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) > (envelope-from ) id 1JyENI-0006UC-1L > for nanog-announce at nanog.org; Mon, 19 May 2008 23:02:36 +0000 > X-IronPort-AV: E=Sophos;i="4.27,512,1204482600"; d="scan'208";a="107943185" > Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) > by ind-iport-1.cisco.com with ESMTP; 20 May 2008 04:32:33 +0530 > Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) > by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4JN2XlM012133 > for ; Tue, 20 May 2008 07:02:33 +0800 > Received: from Philip-PB.local (sin-vpn-client-20-47.cisco.com [10.68.20.47]) > by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4JN2WVp007247 > for ; Mon, 19 May 2008 23:02:32 GMT > Message-ID: <48320722.70807 at cisco.com> > Date: Tue, 20 May 2008 09:02:58 +1000 > From: Philip Smith > Organization: Cisco Systems > User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) > MIME-Version: 1.0 > To: nanog-announce at nanog.org > X-Enigmail-Version: 0.95.6 > Authentication-Results: hkg-dkim-1; header.From=pfs at cisco.com; dkim=pass ( > sig from cisco.com/hkgdkim1002 verified; ); > Subject: [NANOG-announce] email subject tags and footers > X-BeenThere: nanog-announce at nanog.org > X-Mailman-Version: 2.1.9 > Precedence: list > List-Id: NANOG-Announce > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > Errors-To: nanog-announce-bounces at nanog.org > > Hi everyone, > > Following the discussion on nanog-futures, we'd like to let you all know > that the [NANOG] in the subject line and the three extra info lines > mailman appends will be dropped from all future messages going to the > NANOG list, starting in around 24 hours from now. > > If any of you have you changed your e-mail filtering > to depend on the [NANOG] subject tag, please consider this 24 hours > notice to move to another message filtering technique. > > Best wishes, > > philip > (for the SC) > -- > > > _______________________________________________ > NANOG-announce mailing list > NANOG-announce at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog-announce > > _______________________________________________ > Nanog-futures mailing list > Nanog-futures at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog-futures From cidr-report at potaroo.net Fri May 23 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 May 2008 22:00:05 +1000 (EST) Subject: BGP Update Report Message-ID: <200805231200.m4NC05nN026957@wattle.apnic.net> BGP Update Report Interval: 21-Apr-08 -to- 22-May-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15169 285184 2.6% 2160.5 -- GOOGLE - Google Inc. 2 - AS4538 111915 1.0% 22.8 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS9498 91877 0.8% 75.2 -- BBIL-AP BHARTI BT INTERNET LTD. 4 - AS6140 89204 0.8% 100.6 -- IMPSAT-USA - ImpSat USA, Inc. 5 - AS22773 69817 0.6% 34.0 -- CCINET-2 - Cox Communications Inc. 6 - AS9583 68436 0.6% 56.2 -- SIFY-AS-IN Sify Limited 7 - AS2386 65019 0.6% 44.5 -- INS-AS - AT&T Data Communications Services 8 - AS17974 62775 0.6% 136.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 9 - AS10796 59261 0.5% 77.3 -- SCRR-10796 - Road Runner HoldCo LLC 10 - AS4755 50655 0.5% 30.6 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 11 - AS6517 50149 0.5% 74.4 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 12 - AS7011 50043 0.5% 44.4 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 13 - AS29571 47834 0.4% 329.9 -- CITelecom-AS 14 - AS26829 44644 0.4% 44644.0 -- YKK-USA - YKK USA,INC 15 - AS9198 44580 0.4% 89.7 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 16 - AS8151 43986 0.4% 35.4 -- Uninet S.A. de C.V. 17 - AS17488 42326 0.4% 37.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 18 - AS6478 41971 0.4% 43.4 -- ATT-INTERNET3 - AT&T WorldNet Services 19 - AS24731 41967 0.4% 518.1 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - AS6389 41492 0.4% 21.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26829 44644 0.4% 44644.0 -- YKK-USA - YKK USA,INC 2 - AS42787 32201 0.3% 10733.7 -- MMIP-AS MultiMedia IP Ltd. 3 - AS28646 8000 0.1% 8000.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 4 - AS30929 5665 0.1% 5665.0 -- HUTCB Hidrotechnical Faculty - Technical University 5 - AS40359 4001 0.0% 4001.0 -- SOUTHEASTERNMILLS-ROME - Southeastern Mills, Inc. 6 - AS23082 18317 0.2% 3663.4 -- MPHI - Michigan Public Health Institute 7 - AS16466 17895 0.2% 3579.0 -- AVAYA AVAYA 8 - AS35324 3562 0.0% 3562.0 -- ECH-WILL-AS E.C.H. Will 9 - AS32996 3551 0.0% 3551.0 -- AGRIBANK-STPAUL - AgriBank, FCB 10 - AS36384 9402 0.1% 3134.0 -- GOOGLE-IT - Google Incorporated 11 - AS19017 3089 0.0% 3089.0 -- QUALCOMM-QWBS-LV - Qualcomm Wireless Business Solutions 12 - AS9122 2993 0.0% 2993.0 -- TECHNOELECTROSERVIS-AS Technoelektroservis Ltd. 13 - AS10551 5255 0.1% 2627.5 -- RAPID-CITY-REGIONAL - Rapid City Regional Hospital 14 - AS18131 5222 0.1% 2611.0 -- IR3 NTT Communications Corporation 15 - AS29910 2581 0.0% 2581.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 16 - AS34378 2450 0.0% 2450.0 -- RUG-AS Razgulay Group 17 - AS11278 4677 0.0% 2338.5 -- NINTENDO - Nintendo Of America inc. 18 - AS44730 2284 0.0% 2284.0 -- ALFAGOMMA Alfa Gomma s.p.a. 19 - AS15169 285184 2.6% 2160.5 -- GOOGLE - Google Inc. 20 - AS42923 2153 0.0% 2153.0 -- PLK-AS PLK AS Number TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 125.23.208.0/20 50682 0.4% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 12.108.254.0/24 44644 0.4% AS26829 -- YKK-USA - YKK USA,INC 3 - 193.33.184.0/23 32139 0.3% AS42787 -- MMIP-AS MultiMedia IP Ltd. 4 - 221.128.192.0/18 26584 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 5 - 118.95.56.0/24 17093 0.1% AS9583 -- SIFY-AS-IN Sify Limited 6 - 213.91.175.0/24 15839 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 7 - 84.23.100.0/24 12272 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 8 - 192.12.120.0/24 11212 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 9 - 203.63.26.0/24 9826 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 10 - 221.135.80.0/24 9412 0.1% AS9583 -- SIFY-AS-IN Sify Limited 11 - 201.77.80.0/20 8000 0.1% AS28646 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 12 - 64.201.128.0/20 7859 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 13 - 89.4.131.0/24 7148 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 14 - 135.10.4.0/24 6841 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 15 - 135.10.5.0/24 6839 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 16 - 65.189.229.0/24 6086 0.1% AS10796 -- SCRR-10796 - Road Runner HoldCo LLC 17 - 208.83.118.0/24 6068 0.1% AS23082 -- MPHI - Michigan Public Health Institute 18 - 208.83.117.0/24 6065 0.1% AS23082 -- MPHI - Michigan Public Health Institute 19 - 208.83.119.0/24 6064 0.1% AS23082 -- MPHI - Michigan Public Health Institute 20 - 65.189.110.0/24 6027 0.1% AS10796 -- SCRR-10796 - Road Runner HoldCo LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 23 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 May 2008 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200805231200.m4NC02dX026949@wattle.apnic.net> This report has been generated at Fri May 23 21:15:02 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-05-08 265972 166191 17-05-08 265940 166750 18-05-08 266065 167040 19-05-08 266093 167136 20-05-08 266061 167565 21-05-08 266529 166168 22-05-08 266725 167032 23-05-08 266670 167475 AS Summary 28401 Number of ASes in routing system 11946 Number of ASes announcing only one prefix 4900 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88356864 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 23May08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 266730 167328 99402 37.3% All ASes AS4538 4900 867 4033 82.3% ERX-CERNET-BKB China Education and Research Network Center AS4755 1637 262 1375 84.0% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS6389 1994 638 1356 68.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS9498 1175 84 1091 92.9% BBIL-AP BHARTI BT INTERNET LTD. AS18566 1044 143 901 86.3% COVAD - Covad Communications Co. AS4323 1461 580 881 60.3% TWTC - Time Warner Telecom, Inc. AS22773 946 138 808 85.4% CCINET-2 - Cox Communications Inc. AS8151 1228 492 736 59.9% Uninet S.A. de C.V. AS19262 903 168 735 81.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1223 495 728 59.5% CABLEONE - CABLE ONE AS17488 1064 376 688 64.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1022 365 657 64.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS2386 1440 888 552 38.3% INS-AS - AT&T Data Communications Services AS6478 951 400 551 57.9% ATT-INTERNET3 - AT&T WorldNet Services AS18101 679 155 524 77.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS855 597 106 491 82.2% CANET-ASN-4 - Bell Aliant AS7011 1087 627 460 42.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4766 876 432 444 50.7% KIXS-AS-KR Korea Telecom AS22047 565 129 436 77.2% VTR BANDA ANCHA S.A. AS17676 509 75 434 85.3% GIGAINFRA BB TECHNOLOGY Corp. AS8103 581 152 429 73.8% STATE-OF-FLA - Florida Department of Management Services - Technology Program AS6197 988 582 406 41.1% BATI-ATL - BellSouth Network Solutions, Inc AS4668 674 272 402 59.6% LGNET-AS-KR LG CNS AS7018 1405 1003 402 28.6% ATT-INTERNET4 - AT&T WorldNet Services AS6140 612 213 399 65.2% IMPSAT-USA - ImpSat USA, Inc. AS9443 467 84 383 82.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS3602 455 79 376 82.6% AS3602-RTI - Rogers Telecom Inc. AS4134 854 494 360 42.2% CHINANET-BACKBONE No.31,Jin-rong Street AS16814 426 66 360 84.5% NSS S.A. AS19916 556 202 354 63.7% ASTRUM-0001 - OLM LLC Total 32319 10567 21752 67.3% Top 30 total Possible Bogus Routes 10.0.70.0/24 AS31005 WORKZONE-AS Workzone as, Norway 10.2.1.0/24 AS31005 WORKZONE-AS Workzone as, Norway 10.2.2.0/30 AS31005 WORKZONE-AS Workzone as, Norway 10.2.2.4/32 AS31005 WORKZONE-AS Workzone as, Norway 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.42.96.0/19 AS23148 TERREMARK Terremark 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 74.204.160.0/20 AS14383 DTGL-AS - Defender Technologies Group, LLC 74.204.188.0/22 AS30568 DTGL-AS - Defender Technologies Group, LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.200.192.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.193.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.194.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.195.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 94.43.0.0/16 AS35805 UTG-AS United Telecom AS 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 172.16.0.0/24 AS31005 WORKZONE-AS Workzone as, Norway 190.155.0.0/20 AS14522 Satnet 190.155.0.0/22 AS14522 Satnet 190.155.4.0/22 AS14522 Satnet 190.155.8.0/22 AS14522 Satnet 190.155.12.0/22 AS14522 Satnet 190.155.16.0/22 AS14522 Satnet 190.155.20.0/22 AS14522 Satnet 190.155.24.0/22 AS14522 Satnet 190.155.28.0/22 AS14522 Satnet 190.155.64.0/19 AS14522 Satnet 190.155.64.0/20 AS14522 Satnet 190.155.80.0/20 AS14522 Satnet 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS7891 BELLSOUTH-NET-BLK2 - Bellsouth.Net 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.45.132.0/22 AS24314 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.192.0/19 AS11881 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 212.241.0.0/19 AS12997 KTNET Kyrgyztelecom's Network 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.239.160.0/19 AS16402 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jabley at ca.afilias.info Fri May 23 08:57:12 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Fri, 23 May 2008 09:57:12 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> Message-ID: On 22 May 2008, at 23:16, James R. Cutler wrote: > The announcement was made to nanog-announce, but not to nanog. I > would expect that there are scads more readers of nanog than of > nanog announce. When I was sending things to nanog-announce, it was the case that mail to nanog-announce was sent to people who had specifically subscribed to that list, plus anybody who hadn't but who was subscribed to nanog (in other words, it was sent to the union of both lists). That might have changed since the transition to mailman. It seemed like a useful approach, though. Joe From sam_mailinglists at spacething.org Fri May 23 08:59:15 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Fri, 23 May 2008 14:59:15 +0100 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> Message-ID: <4836CDB3.5030104@spacething.org> Joe Abley wrote: > > On 22 May 2008, at 23:16, James R. Cutler wrote: > >> The announcement was made to nanog-announce, but not to nanog. I >> would expect that there are scads more readers of nanog than of nanog >> announce. > > When I was sending things to nanog-announce, it was the case that mail > to nanog-announce was sent to people who had specifically subscribed > to that list, plus anybody who hadn't but who was subscribed to nanog > (in other words, it was sent to the union of both lists). > > That might have changed since the transition to mailman. It seemed > like a useful approach, though. > Kinda makes you wonder what the purpose on the announce list is though. Are there actually people subscribed to nanog-annouce that aren't subscribed to nanog? Sam From darcy at druid.net Fri May 23 09:06:44 2008 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Fri, 23 May 2008 10:06:44 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <4836CDB3.5030104@spacething.org> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> <4836CDB3.5030104@spacething.org> Message-ID: <20080523100644.4bea5d90.darcy@druid.net> On Fri, 23 May 2008 14:59:15 +0100 Sam Stickland wrote: > Kinda makes you wonder what the purpose on the announce list is though. > Are there actually people subscribed to nanog-annouce that aren't > subscribed to nanog? Perhaps not but it could be useful anyway. People may be subscribed to both lists but are filtering announce to a separate folder. That way they can skim the busier list but pay a bit more attention to the announce one. Maybe there are other possibilities. More options is generally better. I do agree though that announcements, especially any concerning other lists, should probably be duplicated on that list. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From alex at corp.nac.net Thu May 22 16:06:18 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 22 May 2008 17:06:18 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> Message-ID: > I hate to break the news to the New York bashers, but New York is one of > the safest American cities. This is not a controversial statement. While I generally agree with what Rod is saying, saying "NYC is safe" is like saying "all routers are cisco" There are safe areas, and there are not safe areas. I don't know how the Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be overly concerned. And, since people going to NANOG tend to have a herding instinct, there shouldn't be a problem. > New York has a lower incidence of crime than Miami, Detroit, Seattle, > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. Yes, but in at least most of those locations, my Florida or Utah CCW is valid. From tme at multicasttech.com Fri May 23 10:37:24 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 23 May 2008 11:37:24 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <4836CDB3.5030104@spacething.org> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> <4836CDB3.5030104@spacething.org> Message-ID: <2ABA65C9-BCF3-42D4-BD7D-DE03DA2F8EB5@multicasttech.com> On May 23, 2008, at 9:59 AM, Sam Stickland wrote: > Joe Abley wrote: >> >> On 22 May 2008, at 23:16, James R. Cutler wrote: >> >>> The announcement was made to nanog-announce, but not to nanog. I >>> would expect that there are scads more readers of nanog than of >>> nanog announce. >> >> When I was sending things to nanog-announce, it was the case that >> mail to nanog-announce was sent to people who had specifically >> subscribed to that list, plus anybody who hadn't but who was >> subscribed to nanog (in other words, it was sent to the union of >> both lists). >> >> That might have changed since the transition to mailman. It seemed >> like a useful approach, though. >> > Kinda makes you wonder what the purpose on the announce list is > though. IMHO the purpose is (or should be) that the posting-privileges for announce is limited, so that messages from that list about things like changes in format or meeting times can be treated as authoritative. Regards Marshall > Are there actually people subscribed to nanog-annouce that aren't > subscribed to nanog? > > Sam > From pstewart at nexicomgroup.net Fri May 23 10:49:59 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 23 May 2008 11:49:59 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com><71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> Message-ID: <89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net> A lot of it is common sense - New York is a GREAT city .. no question and very safe overall. But common sense will tell you not to take a leisure walk through Harlem at 3AM .. having said that, I've walked through Central Park (65th St.) at various times of the night and never had a problem, but then again that's different too... Travel in herds and mind your own business - don't travel at 3AM (on foot) and you'll be fine..;) That really goes for any city when you think about it... Take care, Paul -----Original Message----- From: Alex Rubenstein [mailto:alex at corp.nac.net] Sent: Thursday, May 22, 2008 5:06 PM To: Rod Beck; David Diaz; Martin Hannigan Cc: nanog at nanog.org Subject: RE: Hauling gear around a NANOG meeting > I hate to break the news to the New York bashers, but New York is one of > the safest American cities. This is not a controversial statement. While I generally agree with what Rod is saying, saying "NYC is safe" is like saying "all routers are cisco" There are safe areas, and there are not safe areas. I don't know how the Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be overly concerned. And, since people going to NANOG tend to have a herding instinct, there shouldn't be a problem. > New York has a lower incidence of crime than Miami, Detroit, Seattle, > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. Yes, but in at least most of those locations, my Florida or Utah CCW is valid. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From andrewy at webair.com Fri May 23 11:28:16 2008 From: andrewy at webair.com (andrew young) Date: Fri, 23 May 2008 12:28:16 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com> <71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> <89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net> Message-ID: <1211560097.12328.2.camel@andrewy-desktop> The part of brooklyn where the meeting is being held is often referred to as MetroTech brooklyn: http://www.metrotechbid.org/ IMO, its a nice place to relax and get a feel for life outside of Manhattan. - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy at webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare at webair.com ------------------------------------- On Fri, 2008-05-23 at 11:49 -0400, Paul Stewart wrote: > A lot of it is common sense - New York is a GREAT city .. no question > and very safe overall. But common sense will tell you not to take a > leisure walk through Harlem at 3AM .. having said that, I've walked > through Central Park (65th St.) at various times of the night and never > had a problem, but then again that's different too... > > Travel in herds and mind your own business - don't travel at 3AM (on > foot) and you'll be fine..;) That really goes for any city when you > think about it... > > Take care, > > Paul > > -----Original Message----- > From: Alex Rubenstein [mailto:alex at corp.nac.net] > Sent: Thursday, May 22, 2008 5:06 PM > To: Rod Beck; David Diaz; Martin Hannigan > Cc: nanog at nanog.org > Subject: RE: Hauling gear around a NANOG meeting > > > I hate to break the news to the New York bashers, but New York is one > of > > the safest American cities. This is not a controversial statement. > > While I generally agree with what Rod is saying, saying "NYC is safe" is > like saying "all routers are cisco" > > There are safe areas, and there are not safe areas. I don't know how the > Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be > overly concerned. And, since people going to NANOG tend to have a > herding instinct, there shouldn't be a problem. > > > > New York has a lower incidence of crime than Miami, Detroit, Seattle, > > Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. > > Yes, but in at least most of those locations, my Florida or Utah CCW is > valid. > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From williamsjj at digitar.com Fri May 23 11:29:33 2008 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Fri, 23 May 2008 10:29:33 -0600 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: <4836CDB3.5030104@spacething.org> References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <004601c8bc19$72d81ff0$1401a8c0@E520> <15BDDC14871D2A49BFCEEEF409EB298305B20D13@exchange.syssrcad.syssrc.com> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> <4836CDB3.5030104@spacething.org> Message-ID: I'm subscribed to both now. ;-) The advantage to the NANOG subject header was obviously it was resilient to e-mail address changes for the list. A nice attribute given e-mails now come in from both nanog at nanog.org and nanog at merit.edu addresses. Anyhow, I assume there was compelling reason for the change. -J --- Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com E: williamsjj at digitar.com V: 208-343-8520 M: 208-863-0727 F: 208-322-8520 XMPP: williamsjj at digitar.com -----Original Message----- From: Sam Stickland [mailto:sam_mailinglists at spacething.org] Sent: Friday, May 23, 2008 7:59 AM To: Joe Abley Cc: nanog; nanog-futures Subject: Re: [Nanog-futures] Announce list: Re: Hughes Network Joe Abley wrote: > > On 22 May 2008, at 23:16, James R. Cutler wrote: > >> The announcement was made to nanog-announce, but not to nanog. I >> would expect that there are scads more readers of nanog than of nanog >> announce. > > When I was sending things to nanog-announce, it was the case that mail > to nanog-announce was sent to people who had specifically subscribed > to that list, plus anybody who hadn't but who was subscribed to nanog > (in other words, it was sent to the union of both lists). > > That might have changed since the transition to mailman. It seemed > like a useful approach, though. > Kinda makes you wonder what the purpose on the announce list is though. Are there actually people subscribed to nanog-annouce that aren't subscribed to nanog? Sam !SIG:4836ce2871591551116042! From yahoo at jimpop.com Fri May 23 11:44:48 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Fri, 23 May 2008 12:44:48 -0400 Subject: [Nanog-futures] Announce list: Re: Hughes Network In-Reply-To: References: <457A257D963C2940B3DB55D0BDBE18390188F935@comm01.annese.local> <7ff145960805221446q182f5154x8f9d3650d02f92d0@mail.gmail.com> <46EA037D-6A1F-4182-9CFB-402412E388D0@ca.afilias.info> <48361F59.4010800@deaddrop.org> <7ff145960805221945g3544a51ei8ce1576ab899552d@mail.gmail.com> <9FD5732E-1536-4153-9BEB-5F41F372C486@consultant.com> <4836CDB3.5030104@spacething.org> Message-ID: <7ff145960805230944s78865f68x324fc7cdbf5a70da@mail.gmail.com> On Fri, May 23, 2008 at 12:29 PM, Jason J. W. Williams wrote: > I'm subscribed to both now. ;-) The advantage to the NANOG subject > header was obviously it was resilient to e-mail address changes for the > list. A nice attribute given e-mails now come in from both > nanog at nanog.org and nanog at merit.edu addresses. Anyhow, I assume there > was compelling reason for the change. There are a plethera of common headers available for filtering, regardless of To: -Jim P. From cscora at apnic.net Fri May 23 13:07:38 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 May 2008 04:07:38 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200805231807.m4NI7cnk017778@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 May, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 256264 Prefixes after maximum aggregation: 127251 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 124284 Total ASes present in the Internet Routing Table: 28277 Prefixes per ASN: 9.06 Origin-only ASes present in the Internet Routing Table: 24653 Origin ASes announcing only one prefix: 11865 Transit ASes present in the Internet Routing Table: 3624 Transit-only ASes present in the Internet Routing Table: 81 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN (39375) 13 Prefixes from unregistered ASNs in the Routing Table: 601 Unregistered ASNs in the Routing Table: 219 Number of 32-bit ASNs allocated by the RIRs: 47 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 805 Number of addresses announced to Internet: 1870739648 Equivalent to 111 /8s, 129 /16s and 56 /24s Percentage of available address space announced: 50.5 Percentage of allocated address space announced: 62.0 Percentage of available address space allocated: 81.4 Percentage of address space in use by end-sites: 72.0 Total number of prefixes smaller than registry allocations: 123489 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 58778 Total APNIC prefixes after maximum aggregation: 21606 APNIC Deaggregation factor: 2.72 Prefixes being announced from the APNIC address blocks: 55812 Unique aggregates announced from the APNIC address blocks: 23839 APNIC Region origin ASes present in the Internet Routing Table: 3240 APNIC Prefixes per ASN: 17.23 APNIC Region origin ASes announcing only one prefix: 848 APNIC Region transit ASes present in the Internet Routing Table: 500 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 349390304 Equivalent to 20 /8s, 211 /16s and 69 /24s Percentage of available APNIC address space announced: 80.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 117761 Total ARIN prefixes after maximum aggregation: 65072 ARIN Deaggregation factor: 1.81 Prefixes being announced from the ARIN address blocks: 87269 Unique aggregates announced from the ARIN address blocks: 34233 ARIN Region origin ASes present in the Internet Routing Table: 12191 ARIN Prefixes per ASN: 7.16 ARIN Region origin ASes announcing only one prefix: 4698 ARIN Region transit ASes present in the Internet Routing Table: 1136 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 357831296 Equivalent to 21 /8s, 84 /16s and 18 /24s Percentage of available ARIN address space announced: 73.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, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 55139 Total RIPE prefixes after maximum aggregation: 33790 RIPE Deaggregation factor: 1.63 Prefixes being announced from the RIPE address blocks: 50307 Unique aggregates announced from the RIPE address blocks: 33864 RIPE Region origin ASes present in the Internet Routing Table: 11361 RIPE Prefixes per ASN: 4.43 RIPE Region origin ASes announcing only one prefix: 5933 RIPE Region transit ASes present in the Internet Routing Table: 1718 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 357934464 Equivalent to 21 /8s, 85 /16s and 165 /24s Percentage of available RIPE address space announced: 82.1 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, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20118 Total LACNIC prefixes after maximum aggregation: 5085 LACNIC Deaggregation factor: 3.96 Prefixes being announced from the LACNIC address blocks: 18471 Unique aggregates announced from the LACNIC address blocks: 10100 LACNIC Region origin ASes present in the Internet Routing Table: 947 LACNIC Prefixes per ASN: 19.50 LACNIC Region origin ASes announcing only one prefix: 309 LACNIC Region transit ASes present in the Internet Routing Table: 159 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 15 Number of LACNIC addresses announced to Internet: 51585024 Equivalent to 3 /8s, 19 /16s and 32 /24s Percentage of available LACNIC address space announced: 51.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3871 Total AfriNIC prefixes after maximum aggregation: 1200 AfriNIC Deaggregation factor: 3.23 Prefixes being announced from the AfriNIC address blocks: 4177 Unique aggregates announced from the AfriNIC address blocks: 1842 AfriNIC Region origin ASes present in the Internet Routing Table: 243 AfriNIC Prefixes per ASN: 17.19 AfriNIC Region origin ASes announcing only one prefix: 77 AfriNIC Region transit ASes present in the Internet Routing Table: 49 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12240640 Equivalent to 0 /8s, 186 /16s and 199 /24s Percentage of available AfriNIC address space announced: 36.5 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 4755 1639 387 91 Videsh Sanchar Nigam Ltd. Aut 9498 1151 550 60 BHARTI BT INTERNET LTD. 9583 1149 140 15 Sify Limited 17488 1064 70 76 Hathway IP Over Cable Interne 4134 854 12661 319 CHINANET-BACKBONE 4766 847 6006 343 Korea Telecom (KIX) 23577 823 34 703 Korea Telecom (ATM-MPLS) 18101 681 149 51 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 546 1919 420 Telstra Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 1993 3087 178 bellsouth.net, inc. 4323 1464 1045 379 Time Warner Telecom 2386 1434 659 871 AT&T Data Communications Serv 7018 1384 5971 986 AT&T WorldNet Services 11492 1223 148 11 Cable One 7011 1088 302 616 Citizens Utilities 18566 1044 296 10 Covad Communications 1785 1022 510 105 AppliedTheory Corporation 6197 987 597 507 BellSouth Network Solutions, 174 970 6837 806 Cogent Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 408 1788 369 TDC Tele Danmark 8452 356 188 7 TEDATA 3301 337 1458 305 TeliaNet Sweden 3320 317 7044 266 Deutsche Telekom AG 8866 297 77 21 Bulgarian Telecommunication C 5462 291 666 26 Telewest Broadband 3215 284 2702 93 France Telecom Transpac 8551 282 269 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 9155 267 46 11 QualityNet AS number Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1227 2464 228 UniNet S.A. de C.V. 11830 601 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 460 225 66 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 414 85 46 ENTEL CHILE S.A. 11172 410 117 67 Servicios Alestra S.A de C.V 10620 388 99 70 TVCABLE BOGOTA 14117 372 23 9 Telefonica del Sur S.A. 20299 330 36 31 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 472 61 28 LINKdotNET AS number 3741 286 853 223 The Internet Solution 20858 223 34 3 EgyNet 2018 182 173 82 Tertiary Education Network 5713 174 575 108 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 100 13 8 Ci Telecom Autonomous system 33776 99 6 7 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 1993 3087 178 bellsouth.net, inc. 4755 1639 387 91 Videsh Sanchar Nigam Ltd. Aut 4323 1464 1045 379 Time Warner Telecom 2386 1434 659 871 AT&T Data Communications Serv 7018 1384 5971 986 AT&T WorldNet Services 8151 1227 2464 228 UniNet S.A. de C.V. 11492 1223 148 11 Cable One 9498 1151 550 60 BHARTI BT INTERNET LTD. 9583 1149 140 15 Sify Limited 7011 1088 302 616 Citizens Utilities Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4755 1639 1548 Videsh Sanchar Nigam Ltd. Aut 11492 1223 1212 Cable One 9583 1149 1134 Sify Limited 9498 1151 1091 BHARTI BT INTERNET LTD. 4323 1464 1085 Time Warner Telecom 18566 1044 1034 Covad Communications 8151 1227 999 UniNet S.A. de C.V. 17488 1064 988 Hathway IP Over Cable Interne 1785 1022 917 AppliedTheory Corporation 22773 946 883 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:16 /11:42 /12:141 /13:282 /14:513 /15:1009 /16:9919 /17:4362 /18:7282 /19:15459 /20:17899 /21:17380 /22:21782 /23:22818 /24:135021 /25:791 /26:926 /27:494 /28:81 /29:9 /30:1 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 1229 1993 bellsouth.net, inc. 11492 1205 1223 Cable One 2386 1133 1434 AT&T Data Communications Serv 18566 1025 1044 Covad Communications 9583 987 1149 Sify Limited 4755 985 1639 Videsh Sanchar Nigam Ltd. Aut 7011 972 1088 Citizens Utilities 6478 950 951 AT&T Worldnet Services 17488 877 1064 Hathway IP Over Cable Interne 9498 835 1151 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:107 12:2049 13:1 15:20 16:3 17:5 18:13 20:35 24:1075 25:1 32:61 33:3 38:425 40:93 41:649 44:2 47:12 52:3 55:3 56:3 57:23 58:511 59:462 60:442 61:997 62:1113 63:1953 64:3393 65:2417 66:3651 67:1197 68:681 69:2239 70:631 71:125 72:1755 73:5 74:973 75:216 76:308 77:654 78:611 79:153 80:898 81:858 82:583 83:394 84:566 85:1032 86:416 87:654 88:329 89:1223 90:11 91:1231 92:193 93:487 96:31 97:17 98:172 99:3 114:13 116:642 117:321 118:132 119:423 120:37 121:530 122:768 123:345 124:852 125:1131 128:325 129:200 130:131 131:401 132:66 133:9 134:178 135:33 136:220 137:90 138:151 139:64 140:484 141:99 142:399 143:299 144:352 145:50 146:363 147:153 148:503 149:183 150:131 151:191 152:141 153:134 154:10 155:273 156:174 157:271 158:163 159:221 160:257 161:114 162:228 163:186 164:524 165:448 166:309 167:323 168:609 169:131 170:427 171:28 172:10 189:168 190:2017 192:5789 193:4100 194:3212 195:2438 196:1063 198:3740 199:3261 200:5634 201:1436 202:7602 203:7839 204:3998 205:2079 206:2404 207:2766 208:3338 209:3426 210:2499 211:1051 212:1389 213:1637 214:473 215:49 216:4357 217:1200 218:355 219:416 220:1080 221:466 222:309 End of report From rbonica at juniper.net Fri May 23 14:00:02 2008 From: rbonica at juniper.net (Ron Bonica) Date: Fri, 23 May 2008 15:00:02 -0400 Subject: IPv4 Router Alert Option Message-ID: <48371432.3050609@juniper.net> Folks, It is my belief that many ISPs, will not accept datagrams containing the Router Alert IP option from customers. Do I have that right? I am asking so that I might better evaluate Internet drafts that would require ISPs to accept such packets. Ron Bonica From rs at seastrom.com Fri May 23 14:29:55 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 23 May 2008 15:29:55 -0400 Subject: IPv4 Router Alert Option In-Reply-To: <48371432.3050609@juniper.net> (Ron Bonica's message of "Fri, 23 May 2008 15:00:02 -0400") References: <48371432.3050609@juniper.net> Message-ID: <86fxs8byz0.fsf@seastrom.com> Ron Bonica writes: > Folks, > > It is my belief that many ISPs, will not accept datagrams containing the > Router Alert IP option from customers. Do I have that right? I think that in general, it is safe to say that most folks who run Internet backbones do not care what options you have on IP packets and are not filtering anyway. Heck, I've never encountered anything beyond unicast RPF in terms of SP filtering, and even *that* is not especially prevalent. If he's reading, Dave Katz will probably be disappointed to hear that I couldn't even remember what that option did without referring to RFC2113. > I am asking so that I might better evaluate Internet drafts that would > require ISPs to accept such packets. Do these drafts actually exist, or are they merely hypothetical? ---rob From Valdis.Kletnieks at vt.edu Fri May 23 14:30:11 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 May 2008 15:30:11 -0400 Subject: IPv4 Router Alert Option In-Reply-To: Your message of "Fri, 23 May 2008 15:00:02 EDT." <48371432.3050609@juniper.net> References: <48371432.3050609@juniper.net> Message-ID: <29203.1211571011@turing-police.cc.vt.edu> On Fri, 23 May 2008 15:00:02 EDT, Ron Bonica said: > Folks, > > It is my belief that many ISPs, will not accept datagrams containing the > Router Alert IP option from customers. Do I have that right? > > I am asking so that I might better evaluate Internet drafts that would > require ISPs to accept such packets. What you're likely to find in *reality* is that ISPs will be more than happy to pass the packets along, but the corporate/consumer firewalls in place at the ISP's *customers* will stomp on the options (see all the ways that mismanaged firewalls fail to do ingress/egress filtering of rfc1918 packets, or think "ICMP Frag Needed" means "This ICMP needs to be fragged", or...). And it doesn't really matter if it's the ISP or the end site that screws it up - if it gets thrown away, it gets thrown away. Unless you had an ISP-specific use for Router Alert, where end-customer behavior doesn't matter? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri May 23 14:35:02 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 May 2008 15:35:02 -0400 Subject: IPv4 Router Alert Option In-Reply-To: <29203.1211571011@turing-police.cc.vt.edu> References: <48371432.3050609@juniper.net> <29203.1211571011@turing-police.cc.vt.edu> Message-ID: <75cb24520805231235o1e3ea07ay38acc8868102f33a@mail.gmail.com> On Fri, May 23, 2008 at 3:30 PM, wrote: > On Fri, 23 May 2008 15:00:02 EDT, Ron Bonica said: >> Folks, >> >> It is my belief that many ISPs, will not accept datagrams containing the >> Router Alert IP option from customers. Do I have that right? >> >> I am asking so that I might better evaluate Internet drafts that would >> require ISPs to accept such packets. > > What you're likely to find in *reality* is that ISPs will be more than happy > to pass the packets along, but the corporate/consumer firewalls in place s/pass the packets/pass the packets that don't harm their network devices/ > at the ISP's *customers* will stomp on the options (see all the ways that > mismanaged firewalls fail to do ingress/egress filtering of rfc1918 packets, > or think "ICMP Frag Needed" means "This ICMP needs to be fragged", or...). > > And it doesn't really matter if it's the ISP or the end site that screws it > up - if it gets thrown away, it gets thrown away. > > Unless you had an ISP-specific use for Router Alert, where end-customer > behavior doesn't matter? router-alert is blocked in many places, I believe (I'm fuzzy on this) that some vendors allow you to ignore router-alert, which I think is the preferred option for this option. -Chris From smj at merit.edu Fri May 23 15:02:30 2008 From: smj at merit.edu (Sue Joiner) Date: Fri, 23 May 2008 16:02:30 -0400 Subject: [Fwd: [NANOG-announce] email subject tags and footers] Message-ID: <483722D6.9010607@merit.edu> To help clarify what has happened with the mail lists. The message below was sent to nanog-announce at nanog.org on Tuesday, May 20 and was blocked from delivering to the nanog mail list. It was caught as a pending message to be approved for delivery to the nanog list. It was marked as Defer and was accidentally deleted. After the 24 hour notice the subject tag and the footers to the nanog mail list were removed. The archives for nanog, nanog-futures and nanog-announce are now currently available publicly: http://mailman.nanog.org/pipermail/nanog http://mailman.nanog.org/pipermail/nanog-announce http://mailman.nanog.org/pipermail/nanog-futures The information pages for each of the lists can be found: http://mailman.nanog.org/mailman/listinfo/nanog http://mailman.nanog.org/mailman/listinfo/nanog-announce http://mailman.nanog.org/mailman/listinfo/nanog-futures There are links to the archives on their respective information pages. Also there are links to the old archives on the information pages. Note that nanog-announce was never archived in the past because the messages were always archived on the nanog list. If you have any questions, please send a message to nanog-support at nanog.org. -sue Sue Joiner Merit Network -------- Original Message -------- Subject: [NANOG-announce] email subject tags and footers Date: Tue, 20 May 2008 09:02:58 +1000 From: Philip Smith Organization: Cisco Systems To: nanog-announce at nanog.org Hi everyone, Following the discussion on nanog-futures, we'd like to let you all know that the [NANOG] in the subject line and the three extra info lines mailman appends will be dropped from all future messages going to the NANOG list, starting in around 24 hours from now. If any of you have you changed your e-mail filtering to depend on the [NANOG] subject tag, please consider this 24 hours notice to move to another message filtering technique. Best wishes, philip (for the SC) -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From branto at branto.com Fri May 23 16:00:55 2008 From: branto at branto.com (Brant I. Stevens) Date: Fri, 23 May 2008 17:00:55 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <1211560097.12328.2.camel@andrewy-desktop> Message-ID: The days of The Warriors (come out and plaaaaaaaYYYYYAAYYYYYY) have long since passed. As someone else said, a car would be a mistake, as parking in Manhattan at night is both very expensive and very scarce. On 5/23/08 12:28 PM, "andrew young" wrote: > The part of brooklyn where the meeting is being held is often referred > to as MetroTech brooklyn: > > http://www.metrotechbid.org/ > > IMO, its a nice place to relax and get a feel for life outside of > Manhattan. > - > ------------------------------------ > Andrew Young > Webair Internet Development, Inc > Phone: 1 866 WEBAIR 1 > FAX: 516.938.5100 > http://www.webair.com > andrewy at webair.com > ------------------------------------- > We are interested in any feedback you might have about the service > you received. Please contact our technical support consumer care manager > directly at 1.866.WEBAIR1 or e-mail customercare at webair.com > ------------------------------------- > > > On Fri, 2008-05-23 at 11:49 -0400, Paul Stewart wrote: > >> A lot of it is common sense - New York is a GREAT city .. no question >> and very safe overall. But common sense will tell you not to take a >> leisure walk through Harlem at 3AM .. having said that, I've walked >> through Central Park (65th St.) at various times of the night and never >> had a problem, but then again that's different too... >> >> Travel in herds and mind your own business - don't travel at 3AM (on >> foot) and you'll be fine..;) That really goes for any city when you >> think about it... >> >> Take care, >> >> Paul >> >> -----Original Message----- >> From: Alex Rubenstein [mailto:alex at corp.nac.net] >> Sent: Thursday, May 22, 2008 5:06 PM >> To: Rod Beck; David Diaz; Martin Hannigan >> Cc: nanog at nanog.org >> Subject: RE: Hauling gear around a NANOG meeting >> >>> I hate to break the news to the New York bashers, but New York is one >> of >>> the safest American cities. This is not a controversial statement. >> >> While I generally agree with what Rod is saying, saying "NYC is safe" is >> like saying "all routers are cisco" >> >> There are safe areas, and there are not safe areas. I don't know how the >> Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be >> overly concerned. And, since people going to NANOG tend to have a >> herding instinct, there shouldn't be a problem. >> >> >>> New York has a lower incidence of crime than Miami, Detroit, Seattle, >>> Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. >> >> Yes, but in at least most of those locations, my Florida or Utah CCW is >> valid. >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "The information transmitted is intended only for the person or entity to >> which it is addressed and contains confidential and/or privileged material. >> If you received this in error, please contact the sender immediately and then >> destroy this transmission, including all attachments, without copying, >> distributing or disclosing same. Thank you." From virendra.rode at gmail.com Fri May 23 16:09:43 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Fri, 23 May 2008 14:09:43 -0700 Subject: outages mailing list is back online! Message-ID: <48373297.8070403@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ Apologies to those of you who receive this note in multiple forums. ] Hello all, I wanted to drop a quick note to everyone and explain how/why things took so long and I deeply apologize for the service interruption. Apparently the machine hosting outages mailing list went belly up during the package upgrade (postfix/mailman/apache) in order to bring the system up to date. This was suppose to be a planned upgrade which unfortunately turned out to be sysadmin's nightmare. During the headless chicken syndrome it led into further issues and from there on murphy took over that led to a prolonged outage. We are working towards a cluster setup (active-active cluster) where we will be able to pull the host out of operation without affecting the service in the future. Something we are also looking into is a separate instance in availability zones (multi-site) in order to protect applications/ host availability from failure of a single location. We deeply regret the delay this caused the mailing list to be off the air. Many thanks to Gadi Evron / Randy Vanghn / James Eastman / Larry Vaden / Joe St Sauver and other members of the team who work effortlessly to resurrect this list. Without there help and direction outages list wouldn't exist today. I'm indebted to them. Suggestions, comments are welcome. If interested, you can subscribe to the list at, http://isotf.org/mailman/listinfo/outages respectfully, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFINzKXpbZvCIJx1bcRAv0lAJ46sBa9/uZ/lbl54ehE7tgNZiySZgCghKsq AjuiEP7kwKGXSsJqDBBe08w= =1OV7 -----END PGP SIGNATURE----- From sean at donelan.com Fri May 23 16:59:01 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 23 May 2008 17:59:01 -0400 (EDT) Subject: IPv4 Router Alert Option In-Reply-To: <48371432.3050609@juniper.net> References: <48371432.3050609@juniper.net> Message-ID: On Fri, 23 May 2008, Ron Bonica wrote: > It is my belief that many ISPs, will not accept datagrams containing the > Router Alert IP option from customers. Do I have that right? > > I am asking so that I might better evaluate Internet drafts that would > require ISPs to accept such packets. Depends on what you mean by the word "accept." Transit backbone operators have been changing to the position of protecting their router CPU's from user packets being punted up the control plane. If they can forward the packet without going up the control plane, I think most transit backbones will "accept" the packet and ignore IP options like Router Alert. If someone writes a standard to require ISPs to do something besides ignore an IP option and forward the packet, then you may see ISPs drop packets instead of punting them to the control plane. For example, packets with IP Source Route options. Router# conf t Router(config)# ip options ignore Router(config)# exit Router# write mem As Chris mentions, packets with IP options are likely to have more problems crossing firewalls/security devices or even simple NAT/middle-boxes. I don't remember who, but someone once suggested if we could go back in time to the late 1970's and redo the Internet Protocol we would get rid of all IP options and made IP addresses 64 bits and classless from the beginning. From sean at donelan.com Fri May 23 18:23:57 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 23 May 2008 19:23:57 -0400 (EDT) Subject: [NANOG] Limiting ICMP In-Reply-To: <200805212115.m4LLFcBJ016955@larry.centergate.com> References: <200805212115.m4LLFcBJ016955@larry.centergate.com> Message-ID: On Wed, 21 May 2008, John Kristoff wrote: > In the environments where I've done this, my experience was that it was > an acceptable practice at the time and in a couple cases it did help the > net upstream when something went wrong (e.g. this did stop some real > DoS traffic for me more than once). I made use of protocol counters or > some monitoring tools to ensure they were not unnecessarily dropping > valid packets. Your mileage may vary of course, as it apparently does? Welcome to the wonderful world of deciding on "defaults." Unfortunately, the people most likely to be negatively affected by defaults are also people least likely to know the consequences of those defaults. Is it better to set defaults conservatively and allow people who want more to expand them? Or better to set defaults liberally and allow people who want less to reduce them? From bzs at world.std.com Fri May 23 18:59:30 2008 From: bzs at world.std.com (Barry Shein) Date: Fri, 23 May 2008 19:59:30 -0400 (EDT) Subject: amazonaws.com? Message-ID: <200805232359.m4NNxUEY020333@world.std.com> Is it just us or does someone pWn *.amazonaws.com? Every one of our mail servers is being slammed by I'm not sure what but many thousands of user unknowns per hour (fortunately we handle those pretty quickly but this is a deluge.) All I know is "amazonaws.com" is "Amazon Web Services", not sure if these particular systems should be sending email at all, the hostnames look like: ec2-67-202-36-134.compute-1.amazonaws.com ec2-67-202-37-35.compute-1.amazonaws.com ec2-67-202-37-38.compute-1.amazonaws.com ec2-67-202-38-112.compute-1.amazonaws.com ec2-67-202-39-87.compute-1.amazonaws.com ec2-67-202-8-122.compute-1.amazonaws.com ec2-72-44-37-77.compute-1.amazonaws.com ec2-75-101-192-20.compute-1.amazonaws.com ec2-75-101-202-130.compute-1.amazonaws.com ec2-75-101-207-190.compute-1.amazonaws.com ec2-75-101-210-120.compute-1.amazonaws.com ec2-75-101-224-146.compute-1.amazonaws.com ec2-75-101-227-187.compute-1.amazonaws.com ec2-75-101-228-221.compute-1.amazonaws.com ec2-75-101-229-15.compute-1.amazonaws.com ec2-75-101-230-147.compute-1.amazonaws.com ec2-75-101-234-192.compute-1.amazonaws.com ec2-75-101-236-135.compute-1.amazonaws.com ec2-75-101-238-69.compute-1.amazonaws.com ec2-75-101-241-105.compute-1.amazonaws.com Those don't look like mail servers but what do I know? Anyhow, if there's anyone awake at Amazonaws.com, your hair is on fire. -b From patrick at chegg.com Fri May 23 19:06:15 2008 From: patrick at chegg.com (Patrick Clochesy) Date: Fri, 23 May 2008 19:06:15 -0500 Subject: amazonaws.com? In-Reply-To: <200805232359.m4NNxUEY020333@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> Message-ID: <7620A2BC-CDC9-4DF7-8C85-344D86BB5627@chegg.com> EC2 is a pay-per-cycle service, where you can run your work on their servers. Probably one of their clients. Try abuse@? -Patrick On May 23, 2008, at 6:59 PM, Barry Shein wrote: > > Is it just us or does someone pWn *.amazonaws.com? > > Every one of our mail servers is being slammed by I'm not sure what > but many thousands of user unknowns per hour (fortunately we handle > those pretty quickly but this is a deluge.) > > All I know is "amazonaws.com" is "Amazon Web Services", not sure if > these particular systems should be sending email at all, the hostnames > look like: > > ec2-67-202-36-134.compute-1.amazonaws.com > ec2-67-202-37-35.compute-1.amazonaws.com > ec2-67-202-37-38.compute-1.amazonaws.com > ec2-67-202-38-112.compute-1.amazonaws.com > ec2-67-202-39-87.compute-1.amazonaws.com > ec2-67-202-8-122.compute-1.amazonaws.com > ec2-72-44-37-77.compute-1.amazonaws.com > ec2-75-101-192-20.compute-1.amazonaws.com > ec2-75-101-202-130.compute-1.amazonaws.com > ec2-75-101-207-190.compute-1.amazonaws.com > ec2-75-101-210-120.compute-1.amazonaws.com > ec2-75-101-224-146.compute-1.amazonaws.com > ec2-75-101-227-187.compute-1.amazonaws.com > ec2-75-101-228-221.compute-1.amazonaws.com > ec2-75-101-229-15.compute-1.amazonaws.com > ec2-75-101-230-147.compute-1.amazonaws.com > ec2-75-101-234-192.compute-1.amazonaws.com > ec2-75-101-236-135.compute-1.amazonaws.com > ec2-75-101-238-69.compute-1.amazonaws.com > ec2-75-101-241-105.compute-1.amazonaws.com > > Those don't look like mail servers but what do I know? > > Anyhow, if there's anyone awake at Amazonaws.com, your hair is on > fire. > > -b > > From devangnp at gmail.com Fri May 23 19:08:00 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 23 May 2008 19:08:00 -0500 Subject: Same AS number from different location Message-ID: Hello, Is that okay to use Same AS number for the two different site on different location? as well as any good documentation or link or deployment scenario where I can find the merging of two different AS into one AS? As well as what to do if I have an IP addresses as a service provider dependent block and want to migrate IP addressing to the IANA assigned ip addresses? how can i achieve that? regards Devang Patel From cstone at axint.net Fri May 23 19:12:55 2008 From: cstone at axint.net (Chris Stone) Date: Fri, 23 May 2008 18:12:55 -0600 Subject: amazonaws.com? In-Reply-To: <7620A2BC-CDC9-4DF7-8C85-344D86BB5627@chegg.com> References: <200805232359.m4NNxUEY020333@world.std.com> <7620A2BC-CDC9-4DF7-8C85-344D86BB5627@chegg.com> Message-ID: <48375D87.5030903@axint.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Patrick Clochesy wrote: > EC2 is a pay-per-cycle service, where you can run your work on their > servers. Probably one of their clients. Try abuse@? > > -Patrick > > On May 23, 2008, at 6:59 PM, Barry Shein wrote: > >> >> Is it just us or does someone pWn *.amazonaws.com? >> >> Every one of our mail servers is being slammed by I'm not sure what >> but many thousands of user unknowns per hour (fortunately we handle >> those pretty quickly but this is a deluge.) >> >> All I know is "amazonaws.com" is "Amazon Web Services", not sure if >> these particular systems should be sending email at all, the hostnames >> look like: >> Send to abuse at amazon.com - amazonaws.com has no MX: [cstone at csmdv ~]$ host -tmx amazonaws.com amazonaws.com has no MX record - -- Chris Stone, MCSE Vice President, CTO AxisInternet, Inc. http://www.axint.net DSL, dialup, hosting, email filtering, co-location, online backup Phone: +1 303 592 2947 x302 (office) +1 303 570 6947 (cell) - ------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iEYEAREKAAYFAkg3XYIACgkQnSVip47FEdNW6wCdF4KcQEbgCIYQVEjt7vCxwi7Y pEUAn3D1wYWIy08BE9XuOE99Ojon2V5O =BQ1p -----END PGP SIGNATURE----- From devangnp at gmail.com Fri May 23 19:15:52 2008 From: devangnp at gmail.com (devang patel) Date: Fri, 23 May 2008 19:15:52 -0500 Subject: Same AS number from different location and Migration of IP addresses Message-ID: Hello, Is that okay to use Same AS number for the two different site on different location? as well as any good documentation or link or deployment scenario where I can find the merging of two different AS into one AS? As well as what to do if I have an IP addresses as a service provider dependent block and want to migrate IP addressing to the IANA assigned ip addresses? how can i achieve that? regards Devang Patel From steve at blighty.com Fri May 23 19:42:26 2008 From: steve at blighty.com (Steve Atkins) Date: Fri, 23 May 2008 17:42:26 -0700 Subject: amazonaws.com? In-Reply-To: <200805232359.m4NNxUEY020333@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> Message-ID: <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> On May 23, 2008, at 4:59 PM, Barry Shein wrote: > > Is it just us or does someone pWn *.amazonaws.com? > > Every one of our mail servers is being slammed by I'm not sure what > but many thousands of user unknowns per hour (fortunately we handle > those pretty quickly but this is a deluge.) > > All I know is "amazonaws.com" is "Amazon Web Services", not sure if > these particular systems should be sending email at all, the hostnames > look like: It's a compute farm. Anyone can rent time on it. The processes they run will be assigned to random machines in the farm, AIUI, and will have full network access. If you're seeing something more egregious than just deluges of spam then ec2-abuse at amazon.com would likely be the right people to talk to. They've been contacted about it and, AIUI, state that the spam being sent from there is not something they're going to take action on. I suspect that taking the obvious preemptive action w.r.t. 67.202.0.0/18 is likely to be more effective than relying on their abuse staff. Cheers, Steve From scg at gibbard.org Fri May 23 19:53:11 2008 From: scg at gibbard.org (Steve Gibbard) Date: Fri, 23 May 2008 17:53:11 -0700 (PDT) Subject: Hauling gear around a NANOG meeting In-Reply-To: <89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com><71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> <89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net> Message-ID: <20080523165954.N4485@sprockets.gibbard.org> I hesitate to weigh in here, but my observation after several years of doing a fair bit of traveling to a wide variety of places is this: In any big city, anywhere in the world, there will be plenty of people ready with lectures on how "this is a big city, and is therefore a dangerous place. You need to be careful." Often, this will be repeated with escalating tones of alarm if it becomes clear that I've been ignoring it. Sometimes the claim will be that their city is especially dangerous, and sometimes the claim will be that it's dangerous just like any other big city. Sometimes it takes on the form of "this is a really safe city, but don't go out at night." It doesn't matter. Some cities really are dangerous, and some seem quite safe, but there's no quantifiable difference between lectures received in places that really are dangerous and places that aren't. -Steve On Fri, 23 May 2008, Paul Stewart wrote: > A lot of it is common sense - New York is a GREAT city .. no question > and very safe overall. But common sense will tell you not to take a > leisure walk through Harlem at 3AM .. having said that, I've walked > through Central Park (65th St.) at various times of the night and never > had a problem, but then again that's different too... > > Travel in herds and mind your own business - don't travel at 3AM (on > foot) and you'll be fine..;) That really goes for any city when you > think about it... > > Take care, > > Paul > > -----Original Message----- > From: Alex Rubenstein [mailto:alex at corp.nac.net] > Sent: Thursday, May 22, 2008 5:06 PM > To: Rod Beck; David Diaz; Martin Hannigan > Cc: nanog at nanog.org > Subject: RE: Hauling gear around a NANOG meeting > >> I hate to break the news to the New York bashers, but New York is one > of >> the safest American cities. This is not a controversial statement. > > While I generally agree with what Rod is saying, saying "NYC is safe" is > like saying "all routers are cisco" > > There are safe areas, and there are not safe areas. I don't know how the > Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be > overly concerned. And, since people going to NANOG tend to have a > herding instinct, there shouldn't be a problem. > > >> New York has a lower incidence of crime than Miami, Detroit, Seattle, >> Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. > > Yes, but in at least most of those locations, my Florida or Utah CCW is > valid. > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ops.lists at gmail.com Fri May 23 21:26:48 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 24 May 2008 07:56:48 +0530 Subject: amazonaws.com? In-Reply-To: <200805232359.m4NNxUEY020333@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> Message-ID: On Sat, May 24, 2008 at 5:29 AM, Barry Shein wrote: > > Is it just us or does someone pWn *.amazonaws.com? > > ec2-67-202-36-134.compute-1.amazonaws.com > ec2-67-202-37-35.compute-1.amazonaws.com Why dont you just use spamhaus PBL? That'd take care of email from the EC2 cloud, dynamic IP ranges etc etc. http://www.spamhaus.org/pbl/query/PBL181003 Ref: PBL181003 67.202.0.0/18 is listed on the Policy Block List (PBL) Outbound Email Policy of The Spamhaus Project for this IP range: This IP range has been identified by Spamhaus as not meeting our policy for IPs which should deliver 'direct-to-mx' mail to PBL users. From cdl at asgaard.org Fri May 23 21:47:47 2008 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Fri, 23 May 2008 19:47:47 -0700 Subject: Hauling gear around a NANOG meeting In-Reply-To: <20080523165954.N4485@sprockets.gibbard.org> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com><71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local> <89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net> <20080523165954.N4485@sprockets.gibbard.org> Message-ID: <346841A5-F848-4FFA-886B-D05AF9411CE7@asgaard.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I think the 0.02 take-away for this discussion is: If you don't feel safe doing what you are doing, or being where you are, then stop/leave. In almost any big city, it's really not a problem - there are lots of people around and things are usually ok. However, your intuition is usually a pretty good guide. A corollary is, if you are scared, even if the area is "safe" certain actors will pickup on it. Therefore, the simple act of feeling uncomfortable will probably raise the likelihood of you getting into trouble. Unless you've lived a very sheltered life, your "intuition" will usually give you warning WAY before you get into trouble. BTW - there are a lot of big cities that I have no concerns walking alone in at 0300. However, not all cities fit in that bucket. There are also places that you just don't go to even in the middle of the day. Chris On 23 May 2008, at 17.53, Steve Gibbard wrote: > I hesitate to weigh in here, but my observation after several years > of doing a fair bit of traveling to a wide variety of places is > this: In any big city, anywhere in the world, there will be plenty > of people ready with lectures on how "this is a big city, and is > therefore a dangerous place. You need to be careful." Often, this > will be repeated with escalating tones of alarm if it becomes clear > that I've been ignoring it. Sometimes the claim will be that their > city is especially dangerous, and sometimes the claim will be that > it's dangerous just like any other big city. Sometimes it takes on > the form of "this is a really safe city, but don't go out at > night." It doesn't matter. Some cities really are dangerous, and > some seem quite safe, but there's no quantifiable difference between > lectures received in places that really are dangerous and places > that aren't. > > -Steve > > On Fri, 23 May 2008, Paul Stewart wrote: > >> A lot of it is common sense - New York is a GREAT city .. no question >> and very safe overall. But common sense will tell you not to take a >> leisure walk through Harlem at 3AM .. having said that, I've walked >> through Central Park (65th St.) at various times of the night and >> never >> had a problem, but then again that's different too... >> >> Travel in herds and mind your own business - don't travel at 3AM (on >> foot) and you'll be fine..;) That really goes for any city when you >> think about it... >> >> Take care, >> >> Paul >> >> -----Original Message----- >> From: Alex Rubenstein [mailto:alex at corp.nac.net] >> Sent: Thursday, May 22, 2008 5:06 PM >> To: Rod Beck; David Diaz; Martin Hannigan >> Cc: nanog at nanog.org >> Subject: RE: Hauling gear around a NANOG meeting >> >>> I hate to break the news to the New York bashers, but New York is >>> one >> of >>> the safest American cities. This is not a controversial statement. >> >> While I generally agree with what Rod is saying, saying "NYC is >> safe" is >> like saying "all routers are cisco" >> >> There are safe areas, and there are not safe areas. I don't know >> how the >> Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be >> overly concerned. And, since people going to NANOG tend to have a >> herding instinct, there shouldn't be a problem. >> >> >>> New York has a lower incidence of crime than Miami, Detroit, >>> Seattle, >>> Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. >> >> Yes, but in at least most of those locations, my Florida or Utah >> CCW is >> valid. >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "The information transmitted is intended only for the person or >> entity to which it is addressed and contains confidential and/or >> privileged material. If you received this in error, please contact >> the sender immediately and then destroy this transmission, >> including all attachments, without copying, distributing or >> disclosing same. Thank you." > > - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJIN4HTAAoJEGmx2Mt/+Iw/vLwH/1vk5L3Hbmd0Pp0iA8CY8lt4 ssVs5lQMcR5t1ssZ112q0EvlqRTaUhilPGw86+Rn502LtGZAvgBsXWssvT/B14vP 8mkh6qz1fCQ1X3xrdocxgRl92KGtIYz6qJLp/AtGVxrjzNXxc14PB5eteGcDWNjm jrfnGvbBBr4c5aSKE9EJmYZWW19dtsMTjZbiKF9UbJjzU6ynxFp5FO26ovEy12ux u6YhSH37kYzUNqCehWRz7rfE/MhBew5wHdPRHJNhVLwbhtImrZrl+RlHQLZi30ff 7MLkAkwG2EMDdyTHZaPiPHCr8ar6hBfVCNavzjIDCtYlp6lKAqlHCYb9D6mkTfQ= =L1XZ -----END PGP SIGNATURE----- From hcb at netcases.net Fri May 23 23:40:15 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sat, 24 May 2008 00:40:15 -0400 Subject: Hauling gear around a NANOG meeting In-Reply-To: <346841A5-F848-4FFA-886B-D05AF9411CE7@asgaard.org> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com><71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local><89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net><20080523165954.N4485@sprockets.gibbard.org> <346841A5-F848-4FFA-886B-D05AF9411CE7@asgaard.org> Message-ID: <000f01c8bd58$475e1920$020fa8c0@HDESK1> I cannot resist a tale told to me, in fact, by a service provider, who was at the Empiricon science fiction and fantasy convention in New York, some years ago. At about 3 AM, six attendees decided to go to a Chinese restaurant they knew was still open, and chose to take the subway. At the time, this was _not_ a safe transportation route. To compound their strange choice, they were all in costume. As it was told to me, they were joined by four young men, wearing leather, as is common to the Thief class in Dungeons & Dragons. Indeed, the laughing young men pulled out daggers, or modern equivalents, and demanded purses. At that point, things took an unusual turn. Some conventions allow no actual weapons. Others will allow certain items, but "peace bonded" with a symbolic seal on the scabbard. Three of the convention-goers were D&D players, and, as things developed, things went considerably beyond "That's not a knife. THIS is a knife." In this case, the three drew what were, indeed, not knives. They were swords. After the smallest woman in the group broke one of the young gentlemens' arms, with a firm blow from the flat of her saber, things became a bit confused...but, soon afterwards, the four young gentlemen were spread-eagled against a subway station wall, the waistbands of their trousers cut and hobbling their ankles. When the Transit Police arrived, had it explained that a sword was hardly a concealed weapon, the young gentlemen greeted the constabulary with great relief. You see, the remaining three convention-goers were admirers of Star Trek, and were suitably garbed. The young gentlemen knew only a bit about Star Trek, but just enough, considering their recent experience with true blades, to have absolutely no desire to determine, experimentally, if the leveled phasers were real. -----Original Message----- From: Christopher LILJENSTOLPE [mailto:cdl at asgaard.org] Sent: Friday, May 23, 2008 10:48 PM To: Steve Gibbard Cc: nanog at nanog.org Subject: Re: Hauling gear around a NANOG meeting -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I think the 0.02 take-away for this discussion is: If you don't feel safe doing what you are doing, or being where you are, then stop/leave. In almost any big city, it's really not a problem - there are lots of people around and things are usually ok. However, your intuition is usually a pretty good guide. A corollary is, if you are scared, even if the area is "safe" certain actors will pickup on it. Therefore, the simple act of feeling uncomfortable will probably raise the likelihood of you getting into trouble. Unless you've lived a very sheltered life, your "intuition" will usually give you warning WAY before you get into trouble. BTW - there are a lot of big cities that I have no concerns walking alone in at 0300. However, not all cities fit in that bucket. There are also places that you just don't go to even in the middle of the day. Chris On 23 May 2008, at 17.53, Steve Gibbard wrote: > I hesitate to weigh in here, but my observation after several years > of doing a fair bit of traveling to a wide variety of places is > this: In any big city, anywhere in the world, there will be plenty > of people ready with lectures on how "this is a big city, and is > therefore a dangerous place. You need to be careful." Often, this > will be repeated with escalating tones of alarm if it becomes clear > that I've been ignoring it. Sometimes the claim will be that their > city is especially dangerous, and sometimes the claim will be that > it's dangerous just like any other big city. Sometimes it takes on > the form of "this is a really safe city, but don't go out at > night." It doesn't matter. Some cities really are dangerous, and > some seem quite safe, but there's no quantifiable difference between > lectures received in places that really are dangerous and places > that aren't. > > -Steve > > On Fri, 23 May 2008, Paul Stewart wrote: > >> A lot of it is common sense - New York is a GREAT city .. no question >> and very safe overall. But common sense will tell you not to take a >> leisure walk through Harlem at 3AM .. having said that, I've walked >> through Central Park (65th St.) at various times of the night and >> never >> had a problem, but then again that's different too... >> >> Travel in herds and mind your own business - don't travel at 3AM (on >> foot) and you'll be fine..;) That really goes for any city when you >> think about it... >> >> Take care, >> >> Paul >> >> -----Original Message----- >> From: Alex Rubenstein [mailto:alex at corp.nac.net] >> Sent: Thursday, May 22, 2008 5:06 PM >> To: Rod Beck; David Diaz; Martin Hannigan >> Cc: nanog at nanog.org >> Subject: RE: Hauling gear around a NANOG meeting >> >>> I hate to break the news to the New York bashers, but New York is >>> one >> of >>> the safest American cities. This is not a controversial statement. >> >> While I generally agree with what Rod is saying, saying "NYC is >> safe" is >> like saying "all routers are cisco" >> >> There are safe areas, and there are not safe areas. I don't know >> how the >> Brooklyn side of the Brooklyn bridge rates, but I don't think I'd be >> overly concerned. And, since people going to NANOG tend to have a >> herding instinct, there shouldn't be a problem. >> >> >>> New York has a lower incidence of crime than Miami, Detroit, >>> Seattle, >>> Los Vegas, Houston, Atlanta, DC, Los Angeles, and Philadelphia. >> >> Yes, but in at least most of those locations, my Florida or Utah >> CCW is >> valid. >> >> >> >> >> >> >> ---------------------------------------------------------------------------- >> >> "The information transmitted is intended only for the person or >> entity to which it is addressed and contains confidential and/or >> privileged material. If you received this in error, please contact >> the sender immediately and then destroy this transmission, >> including all attachments, without copying, distributing or >> disclosing same. Thank you." > > - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJIN4HTAAoJEGmx2Mt/+Iw/vLwH/1vk5L3Hbmd0Pp0iA8CY8lt4 ssVs5lQMcR5t1ssZ112q0EvlqRTaUhilPGw86+Rn502LtGZAvgBsXWssvT/B14vP 8mkh6qz1fCQ1X3xrdocxgRl92KGtIYz6qJLp/AtGVxrjzNXxc14PB5eteGcDWNjm jrfnGvbBBr4c5aSKE9EJmYZWW19dtsMTjZbiKF9UbJjzU6ynxFp5FO26ovEy12ux u6YhSH37kYzUNqCehWRz7rfE/MhBew5wHdPRHJNhVLwbhtImrZrl+RlHQLZi30ff 7MLkAkwG2EMDdyTHZaPiPHCr8ar6hBfVCNavzjIDCtYlp6lKAqlHCYb9D6mkTfQ= =L1XZ -----END PGP SIGNATURE----- From karnaugh at karnaugh.za.net Sat May 24 02:24:02 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Sat, 24 May 2008 09:24:02 +0200 Subject: amazonaws.com? In-Reply-To: <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> Message-ID: <4837C292.8060605@karnaugh.za.net> On 24/05/2008 02:42 Steve Atkins wrote: > If you're seeing something more egregious than just deluges of spam > then ec2-abuse at amazon.com would likely be the right people > to talk to. > > They've been contacted about it and, AIUI, state that the spam being sent > from there is not something they're going to take action on. You should not accept SMTP from the Amazon EC2 cloud at all. Amazon don't intend for anyone to use it as an email platform and tell their clients to use an external relay. -- Colin Alston ~ http://syllogism.co.za/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From randy at psg.com Sat May 24 05:54:22 2008 From: randy at psg.com (Randy Bush) Date: Sat, 24 May 2008 10:54:22 +0000 Subject: Hauling gear around a NANOG meeting In-Reply-To: <000f01c8bd58$475e1920$020fa8c0@HDESK1> References: <3E555810-5462-4DC3-B4EA-22BACF2366A8@gmail.com><71CB284A12EDA54880FF588A8BAC0BE221FEB9@ernie.HiberniaAtlantic.local><89D27DE3375BB6428DDCC2927489826A014CAEBA@nexus.nexicomgroup.net><20080523165954.N4485@sprockets.gibbard.org> <346841A5-F848-4FFA-886B-D05AF9411CE7@asgaard.org> <000f01c8bd58$475e1920$020fa8c0@HDESK1> Message-ID: <4837F3DE.3050109@psg.com> i am greatly amused by all the poor country hicks so worried about having to go to the big scary city. when arriving, sweet virginia, please be sure to scrape that right off your shoes. randy From diogo.montagner at gmail.com Sat May 24 07:25:52 2008 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Sat, 24 May 2008 09:25:52 -0300 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: References: Message-ID: <84eb7a820805240525mce55b70q2ac33517e1c447b@mail.gmail.com> Hi Devang, a good start point is the Internet Routing Architecture book: http://www.ciscopress.com/bookstore/product.asp?isbn=157870233X Regards, Diogo On Fri, May 23, 2008 at 9:15 PM, devang patel wrote: > Hello, > > Is that okay to use Same AS number for the two different site on different > location? > as well as any good documentation or link or deployment scenario where I > can > find the merging of two different AS into one AS? > As well as what to do if I have an IP addresses as a service provider > dependent block and want to migrate IP addressing to the IANA assigned ip > addresses? > how can i achieve that? > > regards > Devang Patel > -- ./diogo -montagner From Robert.MacDonald at Haworth.com Sat May 24 07:50:23 2008 From: Robert.MacDonald at Haworth.com (Robert MacDonald) Date: Sat, 24 May 2008 08:50:23 -0400 Subject: Same AS number from different location and Migration of IPaddresses In-Reply-To: <84eb7a820805240525mce55b70q2ac33517e1c447b@mail.gmail.com> References: , <84eb7a820805240525mce55b70q2ac33517e1c447b@mail.gmail.com> Message-ID: <8EE9F853-6F55-4617-BBB3-8B8AF31B3A5E@mimectl> (I'm sending from a non text-only system at the moment, sorry.) These should help on the merging part. [1]http://www.cisco.com/en/US/docs/ios/12_4/ip_route/configuration/guid e/hbgpdas.html [2]http://www.cisco.com/univercd/cc/td/doc/product/software/ios122s/122 snwft/release/122s25/fsbgpdas.htm [3]http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11 bhla.html __________________________________________________________________ From: Diogo Montagner Sent: Sat 5/24/2008 8:25 AM To: [4]nanog at nanog.org Hi Devang, a good start point is the Internet Routing Architecture book: [5]http://www.ciscopress.com/bookstore/product.asp?isbn=157870233X Regards, Diogo On Fri, May 23, 2008 at 9:15 PM, devang patel wrote: > Hello, > > Is that okay to use Same AS number for the two different site on different > location? > as well as any good documentation or link or deployment scenario where I > can > find the merging of two different AS into one AS? > As well as what to do if I have an IP addresses as a service provider > dependent block and want to migrate IP addressing to the IANA assigned ip > addresses? > how can i achieve that? > > regards > Devang Patel > -- ./diogo -montagner References 1. http://www.cisco.com/en/US/docs/ios/12_4/ip_route/configuration/guide/hbgpdas.html 2. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122s/122snwft/release/122s25/fsbgpdas.htm 3. http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ft11bhla.html 4. mailto:nanog at nanog.org 5. http://www.ciscopress.com/bookstore/product.asp?isbn=157870233X From tme at multicasttech.com Sat May 24 08:15:01 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 24 May 2008 09:15:01 -0400 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: References: Message-ID: On May 23, 2008, at 8:15 PM, devang patel wrote: > Hello, > > Is that okay to use Same AS number for the two different site on > different > location? To answer this specific question, Autonomous Systems should be topologically convex. This means, at the Internet interdomain routing (BGP) level, that packets cannot leave an AS in one place to get to locations in the same AS in some other place. So, to put two sites on one AS, there should be an internal connection between them, which can be done through your internal network, by a direct connection, or by a tunnel. Traffic might come to the AS at either site, and has to be routed internally to get to the other. See RFC 1930 and the material linked to in the other posts. Regards Marshall > > as well as any good documentation or link or deployment scenario > where I can > find the merging of two different AS into one AS? > > As well as what to do if I have an IP addresses as a service provider > dependent block and want to migrate IP addressing to the IANA > assigned ip > addresses? > how can i achieve that? > > regards > Devang Patel From adrian at creative.net.au Sat May 24 08:47:17 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 24 May 2008 21:47:17 +0800 Subject: Hauling gear around a NANOG meeting In-Reply-To: <4837F3DE.3050109@psg.com> References: <346841A5-F848-4FFA-886B-D05AF9411CE7@asgaard.org> <000f01c8bd58$475e1920$020fa8c0@HDESK1> <4837F3DE.3050109@psg.com> Message-ID: <20080524134717.GQ15887@skywalker.creative.net.au> On Sat, May 24, 2008, Randy Bush wrote: > i am greatly amused by all the poor country hicks so worried about > having to go to the big scary city. when arriving, sweet virginia, > please be sure to scrape that right off your shoes. Meh. I'm from the most remote pretend-city in the western world and New York seemed fine to me. The subway wasn't dangerous in midtown right out past three/four AM; there's always people going places and in general seemed friendly enough to answer questions (and ask questions; I had a native NY'er ask me how to get somewhere on the subway system!) I'm sure there are places which are labelled "Don't go at night if you're an unarmed middle-class white guy by yourself" but frankly, this place isn't anywhere near as bad as historically portrayed. I'm pleasantly surprised. :) (And annoyed that I'm leaving..) adrian From peter at peter-dambier.de Sat May 24 10:02:40 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Sat, 24 May 2008 17:02:40 +0200 Subject: Fake-alert: VERIFY YOUR MERIT.EDU WEBMAIL ACCOUNT Message-ID: <48382E10.70904@peter-dambier.de> I dont trust it: yahoo address, not nanog. Passwords asked ??? Kind regrards Peter -------- Original Message -------- Return-Path: X-Flags: 1000 Delivered-To: GMX delivery to peter at peter-dambier.de Received: (qmail invoked by alias); 24 May 2008 09:21:30 -0000 Received: from post2.tau.ac.il (EHLO post.tau.ac.il) [132.66.3.221] by mx0.gmx.net (mx059) with SMTP; 24 May 2008 11:21:30 +0200 Received: from localhost (unknown [127.0.0.1]) by post.tau.ac.il (Postfix) with ESMTP id 6E25874294; Sat, 24 May 2008 09:21:28 +0000 (UTC) Received: from post.tau.ac.il ([127.0.0.1]) by localhost (post2.tau.ac.il [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRIT3G8U5W+e; Sat, 24 May 2008 12:21:28 +0300 (IDT) Received: from localhost (webmail.tau.ac.il [132.66.16.180]) by post.tau.ac.il (Postfix) with ESMTP id BB5E0741CE; Sat, 24 May 2008 12:21:27 +0300 (IDT) Received: from 62.32.32.77 ([62.32.32.77]) by webmail.tau.ac.il (Horde MIME library) with HTTP; Sat, 24 May 2008 12:21:27 +0300 Message-ID: <20080524122127.5ns0jelzhss4gc40 at webmail.tau.ac.il> Date: Sat, 24 May 2008 12:21:27 +0300 From: webmaster1 at merit.edu Reply-to: upgradingaccount08 at yahoo.com To: undisclosed-recipients:; Subject: VERIFY YOUR MERIT.EDU WEBMAIL ACCOUNT This email is to inform all our {www.merit.edu} users that we will be upgrading our site in a couple of days from now. So you as a user of our site, you are required send us your Email account details so as to enable us know if you are still making use of your email box. Further be informed that we will be deleting all email account that is not functioning so as to create more space for new user. So you are to send us your email account details which are as follows: *User name in full :......................... *Email in full :......................... *Password:....................................... *Date of birth: ............................... *Security question :......................... *Security answer:??..................... Any email user that refuses to send his/her details within the next two (2) days of receipt this mail, his/her mail account will be deleted from the site. Webmaster Team -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ From patrick at ianai.net Sat May 24 10:11:06 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 24 May 2008 11:11:06 -0400 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: References: Message-ID: <832AB09B-4C9E-40BE-9B93-DC0C2E6942C7@ianai.net> On May 24, 2008, at 9:15 AM, Marshall Eubanks wrote: > On May 23, 2008, at 8:15 PM, devang patel wrote: > >> Is that okay to use Same AS number for the two different site on >> different >> location? > > To answer this specific question, Autonomous Systems should be > topologically convex. > This means, at the Internet interdomain routing (BGP) level, that > packets > cannot leave an AS in one place to get to locations in the same AS > in some other place. > > So, to put two sites on one AS, there should be an internal > connection between them, which can be done > through your internal network, by a direct connection, or by a > tunnel. Traffic might come to > the AS at either site, and has to be routed internally to get to the > other. I am afraid I have to disagree with Marshall. The idea behind an AS when the routing protocols were written long ago may have been a contiguous domain, but there are lots of things the protocols did not originally envision. If you have two islands, and they each have a prefix which is globally routable, there is nothing wrong with the two islands sharing a single ASN. Island A announces Prefix A, and Island B announces Prefix B. Routing is done by prefix, not ASN, so there is no fear of Island A getting packets for Island B, and therefore no requirement for internal connectivity. And before anyone says anything about Island A not having connectivity to Island B, these are obviously not "transit free" networks, so each island can just point default. In fact, cisco even has a knob to listen to paths with your own ASN in it so you can do this without default (although I'm not sure I'd recommend that). It works fine and saves the community from burning an ASN. -- TTFN, patrick From ari.constancio at gmail.com Sat May 24 10:22:22 2008 From: ari.constancio at gmail.com (Ari Constancio) Date: Sat, 24 May 2008 16:22:22 +0100 Subject: Fake-alert: VERIFY YOUR MERIT.EDU WEBMAIL ACCOUNT In-Reply-To: <48382E10.70904@peter-dambier.de> References: <48382E10.70904@peter-dambier.de> Message-ID: <66e82c800805240822o7305731w32cf132e0933681c@mail.gmail.com> On Sat, May 24, 2008 at 4:02 PM, Peter Dambier wrote: > I dont trust it: > > yahoo address, not nanog. > > Passwords asked ??? Of course, they're 'upgrating' the accounts :). > Return-Path: Ari Constancio From nazgul at somewhere.com Sat May 24 11:13:50 2008 From: nazgul at somewhere.com (Kee Hinckley) Date: Sat, 24 May 2008 12:13:50 -0400 Subject: amazonaws.com? In-Reply-To: <4837C292.8060605@karnaugh.za.net> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> Message-ID: <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> On May 24, 2008, at 3:24 AM, Colin Alston wrote: > You should not accept SMTP from the Amazon EC2 cloud at all. Amazon > don't intend for anyone to use it as an email platform and tell > their clients to use an external relay. I'm sure this is good advice. But if an ISP used that as an excuse for not taking action, we'd hang them over hot coals. Is Amazon truly not policing the network for spammers? From graeme at graemef.net Sat May 24 11:14:33 2008 From: graeme at graemef.net (Graeme Fowler) Date: Sat, 24 May 2008 17:14:33 +0100 Subject: Fake-alert: VERIFY YOUR MERIT.EDU WEBMAIL ACCOUNT In-Reply-To: <48382E10.70904@peter-dambier.de> References: <48382E10.70904@peter-dambier.de> Message-ID: <1211645673.2541.3.camel@ernie.internal.graemef.net> On Sat, 2008-05-24 at 17:02 +0200, Peter Dambier wrote: > I dont trust it: Quite right too, it's a spear-phishing attack. This is currently an almost daily occurrence for .edu domains. The compromised accounts are frequently abused via webmail systems, being used to send out more scams. The scammers responsible are also targeting UK higher ed institutions, with a limited degree of success. I can't really speak for my US counterparts with regards the success of the attacks, but one would surmise that it's more or less the same. To paraphrase badly: All users are gullible, but some are more gullible than others. -g From randy at psg.com Sat May 24 11:19:34 2008 From: randy at psg.com (Randy Bush) Date: Sat, 24 May 2008 16:19:34 +0000 Subject: OT: problems getting to our net in maroc Message-ID: <48384016.7080902@psg.com> apologies for operational content. pfs and i are debugging access to/from the afnog class network in rabat. the net is 196.200.216.0/21. for example route-views.oregon-ix.net>traceroute 196.200.216.102 Type escape sequence to abort. Tracing the route to 196.200.216.102 1 vl-51.uonet1-gw.uoregon.edu (128.223.51.2) [AS 3582] 0 msec 0 msec 4 msec 2 0.ge-0-1-0.uonet8-gw.uoregon.edu (128.223.3.8) [AS 3582] 0 msec 0 msec 0 msec 3 eugn-car1-gw.nero.net (207.98.64.65) [AS 3701] 4 msec 0 msec 0 msec 4 eugn-core1-gw.nero.net (207.98.64.168) [AS 3701] 0 msec 0 msec 4 msec 5 eugn-core1-gw.nero.net (207.98.64.168) [AS 3701] !H * * route-views.oregon-ix.net>sh ip bg 196.200.216.102 | i 3701 i.e. nero net does not have our prefix. but others do, for example, from the net here i can ping home no prob. rmac.psg.com:/Users/randy> ping psg.com PING psg.com (147.28.0.62): 56 data bytes 64 bytes from 147.28.0.62: icmp_seq=0 ttl=46 time=257.398 ms 64 bytes from 147.28.0.62: icmp_seq=1 ttl=46 time=285.779 ms --- psg.com ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 257.398/271.589/285.779/14.191 ms rmac.psg.com:/Users/randy> traceroute psg.com traceroute to psg.com (147.28.0.62), 64 hops max, 40 byte packets 1 196.200.217.254 (196.200.217.254) 3.040 ms 1.686 ms 1.720 ms 2 ll81-2-205-33-192-81.ll81-2.iam.net.ma (81.192.33.205) 2.875 ms 3.049 ms 4.112 ms 3 172.20.2.31 (172.20.2.31) 4.497 ms 4.195 ms 2.973 ms 4 ppp-17-3-217-212.dialup.iam.net.ma (212.217.3.17) 5.700 ms 3.043 ms 3.012 ms 5 pal9-maroc-telecom-15.pal.seabone.net (195.22.197.161) 83.778 ms 82.221 ms 86.066 ms 6 ash2-new11-racc3.new.seabone.net (195.22.216.205) 145.379 ms 281.139 ms 146.080 ms 7 nttverio-1-us-ash2.ash.seabone.net (195.22.206.30) 162.111 ms * * 8 ae-2.r20.asbnva01.us.bb.gin.ntt.net (129.250.2.56) 152.031 ms 148.205 ms * 9 as-0.r20.snjsca04.us.bb.gin.ntt.net (129.250.4.21) 224.672 ms 224.431 ms 229.258 ms 10 p64-0-0-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.22) 245.879 ms 247.197 ms 242.687 ms 11 p16-0-0-0.r05.sttlwa01.us.bb.gin.ntt.net (129.250.3.11) 241.235 ms 242.230 ms 241.175 ms 12 p1-0.psg.sttlwa01.us.bb.gin.ntt.net (129.250.11.42) 246.562 ms 241.192 ms 246.050 ms 13 psg.com (147.28.0.62) 232.241 ms * * we suspect multiple bugs, bad filters within maroc telcom and poor propagation of announcements of our prefix. a pingable target here is 196.200.216.102 until i leave in three hours or so. randy From randy at psg.com Sat May 24 12:08:26 2008 From: randy at psg.com (Randy Bush) Date: Sat, 24 May 2008 17:08:26 +0000 Subject: OT: problems getting to our net in maroc In-Reply-To: <483846D4.9050201@st-andrews.ac.uk> References: <48384016.7080902@psg.com> <483846D4.9050201@st-andrews.ac.uk> Message-ID: <48384B8A.8000707@psg.com> thanks all. MT seems to have fixed it. randy From morrowc.lists at gmail.com Sat May 24 13:08:09 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 24 May 2008 14:08:09 -0400 Subject: amazonaws.com? In-Reply-To: <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> Message-ID: <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> On Sat, May 24, 2008 at 12:13 PM, Kee Hinckley wrote: > On May 24, 2008, at 3:24 AM, Colin Alston wrote: >> >> You should not accept SMTP from the Amazon EC2 cloud at all. Amazon don't >> intend for anyone to use it as an email platform and tell their clients to >> use an external relay. > > I'm sure this is good advice. But if an ISP used that as an excuse for not > taking action, we'd hang them over hot coals. Is Amazon truly not policing > the network for spammers? not to excuse this, but... it's not a simple problem. The 'bad guy' rolls up to the website, orders 200 machines for 20 mins under the name 'xplosiveman' pays with some paypal/CC and runs his/her job. That job happens to create a bunch of email outbound. It could be a legitimate email service outsourcing their compute/bw needs to AWS, it could be 'pick-yer-bad-spammer' ... AWS really can't tell until after when the complaints roll in. :( I suppose they could say: "no tcp/25 outbound from AWS computer clusters", though that's probably a decent market in the real email-deliver-services :( Also, truly bad folk will just move to using proxies or other methods :( -Chris. From brunner at nic-naa.net Sat May 24 13:35:17 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 24 May 2008 11:35:17 -0700 Subject: [NANOG] An account of the Estonian Internet War In-Reply-To: References: Message-ID: <48385FE5.8000204@nic-naa.net> Gadi, I read it. As it happens, about a year ago I plowed through a bunch of Information Operations (formerly known as Information Warfare) papers in a then-linkable bibliography on the subject. Your GJIA paper is of that genre. There wasn't enough for me to distinguish between an ad insert campaign executed by several hundred nodes injecting link and keyword payload via POST, which I've observed as multi-hour ddos on vhost targets implemented on generic webservers with no particular load planning, and whatever happened "in Estonia". Technical details may change that impression, or the general observation that the relaxation times of such events is measured in hours to a small number of days. Note: hosts with domain names ending in .mil have been observed in ad insert campaigns. Eric From bzs at world.std.com Sat May 24 13:32:37 2008 From: bzs at world.std.com (Barry Shein) Date: Sat, 24 May 2008 14:32:37 -0400 Subject: amazonaws.com? In-Reply-To: <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> Message-ID: <18488.24389.732571.594007@world.std.com> > not to excuse this, but... it's not a simple problem. The 'bad guy' > rolls up to the website, orders 200 machines for 20 mins under the > name 'xplosiveman' pays with some paypal/CC and runs his/her job. That > job happens to create a bunch of email outbound. It could be a > legitimate email service outsourcing their compute/bw needs to AWS, it > could be 'pick-yer-bad-spammer' ... AWS really can't tell until after > when the complaints roll in. :( Oh rubbish, it's a trivial problem. You verify the payment method in advance and make it clear in the agreement to use the resources that any of the following activities (list, define...) will be billed at a steep rate (e.g., $100 per spamming complaint) and make some reasonable effort to ensure you can collect that, like do an authorize on their credit card (that's what hotels do to reserve but not charge typically $1000 or whatever on your card when you check in.) It's trivial, using your systems to spam is a cost, make sure at the very least you get paid for it. This isn't hypothetical, I have done exactly this many times here and billed customers who were crossing the line and generating too many complaints (but not quite what I'd call egregious spamming, but maybe harvesting addresses for their "newsletter" from specific chat groups for example) $50 per complaint, and I've collected it, and it stopped, either they paid it and cleaned up their act or they went away, good riddance. Anyone who builds a business model which allows for this sort of massive fraud and criminality where a few common sense precautions would prevent it is just transferring the costs of reasonable precaution to others and courts should come to understand that sooner than later. Their business model is monetizing your time and efforts to accomodate that abuse. The money is going right into their pockets by not having to pay for employees to implement and execute an avoidance, detection, and recovery plan, for starters. Microsoft has made untold billions monetizing spam (by knowingly not fixing their OS for over a decade) and others are figuring this out and building new business models which profit on abuse enablement even if indirectly (i.e., as a cost savings.) They're laughing all the way to the bank as you get shook out of bed with another 3AM emergency or stay over the weekend to upgrade your newly purchased firewall capacity, etc etc etc. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From sethm at rollernet.us Sat May 24 14:10:58 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 24 May 2008 12:10:58 -0700 Subject: amazonaws.com? In-Reply-To: <18488.24389.732571.594007@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> Message-ID: <48386842.20007@rollernet.us> Barry Shein wrote: > > not to excuse this, but... it's not a simple problem. The 'bad guy' > > rolls up to the website, orders 200 machines for 20 mins under the > > name 'xplosiveman' pays with some paypal/CC and runs his/her job. That > > job happens to create a bunch of email outbound. It could be a > > legitimate email service outsourcing their compute/bw needs to AWS, it > > could be 'pick-yer-bad-spammer' ... AWS really can't tell until after > > when the complaints roll in. :( > > Oh rubbish, it's a trivial problem. > > You verify the payment method in advance and make it clear in the > agreement to use the resources that any of the following activities > (list, define...) will be billed at a steep rate (e.g., $100 per > spamming complaint) and make some reasonable effort to ensure you can > collect that, like do an authorize on their credit card (that's what > hotels do to reserve but not charge typically $1000 or whatever on > your card when you check in.) > > It's trivial, using your systems to spam is a cost, make sure at the > very least you get paid for it. > And 6 months later, a chargeback shows up because the cardholder claims their card was used fraudulently. The bank will most likely side with the cardholder if you challenge it. How can that loophole be closed? ~Seth From bzs at world.std.com Sat May 24 14:36:57 2008 From: bzs at world.std.com (Barry Shein) Date: Sat, 24 May 2008 15:36:57 -0400 Subject: amazonaws.com? In-Reply-To: <48386842.20007@rollernet.us> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> Message-ID: <18488.28249.428093.815912@world.std.com> On May 24, 2008 at 12:10 sethm at rollernet.us (Seth Mattinen) wrote: > > And 6 months later, a chargeback shows up because the cardholder claims > their card was used fraudulently. The bank will most likely side with > the cardholder if you challenge it. How can that loophole be closed? Since this comment applies equally to every single credit card payment on the internet etc I suppose you've just proven that credit cards can't possibly work and even Amazon itself is an impossibility. Perhaps we can move on to why bumble bees can't fly? Like I said, they have to verify who they're doing business with to some reasonable degree matching the risk involved. Declining a legitimate charge can be a criminal fraud. Even when someone declines a charge it doesn't mean you can't collect what you believe to be money legitimately owed you. You can hand it to a collection agency if it's worthwhile. If not (e.g., you took a card w/o any verification from someone in a country whose name you can't even pronounce) OH WELL, you're a fool, or it better be part of your cost of doing business. Obviously an occasional successful fraud will happen, you can't make the best the enemy of the good, but what a reasonable rather than totally irresponsible policy does is discourage criminals preventatively. STICKING TO THE POINT OF THESE COMPUTING CLOUDS... What is the dollar range of a typical charge for these services? Let's not broaden the point to include every pennyante transaction on the internet. There's a big difference between talking about credit card problems with $20 charges which are hardly worth pursuing and thousands of dollars. Anyhow, it's not my problem to get them paid, it's my problem when they're aiding and abetting criminals who harm me and my business. If they're not even getting paid for that then they're just stupid and deserve whatever happens to them. You make it sound like I have to design a successful business model for them in order to claim damages from their flawed model. I don't think so. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From hcb at netcases.net Sat May 24 15:22:17 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sat, 24 May 2008 16:22:17 -0400 Subject: Same AS number from different location and Migration of IPaddresses In-Reply-To: <832AB09B-4C9E-40BE-9B93-DC0C2E6942C7@ianai.net> References: <832AB09B-4C9E-40BE-9B93-DC0C2E6942C7@ianai.net> Message-ID: <006301c8bddb$dd792250$020fa8c0@HDESK1> Patrick, Your usage is quite consistent with the RFC 1930 guidelines on the use of AS, which probably does need some updating but does have an operational rather than a protocol theory viewpoint. Specifically, an AS is defined not as a business entity, not as a routing domain, but as: "...a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy." In this case, the sites have a common, coordinated routing policy. I do agree that practicality does call for them to have a direct connection, but otherwise, they meet the requirement of being one or more IP prefixes run by one or more operators. I do hope they register their routing policy, with appropriate comments. Howard -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Saturday, May 24, 2008 11:11 AM To: NANOG list Subject: Re: Same AS number from different location and Migration of IPaddresses On May 24, 2008, at 9:15 AM, Marshall Eubanks wrote: > On May 23, 2008, at 8:15 PM, devang patel wrote: > >> Is that okay to use Same AS number for the two different site on >> different >> location? > > To answer this specific question, Autonomous Systems should be > topologically convex. > This means, at the Internet interdomain routing (BGP) level, that > packets > cannot leave an AS in one place to get to locations in the same AS > in some other place. > > So, to put two sites on one AS, there should be an internal > connection between them, which can be done > through your internal network, by a direct connection, or by a > tunnel. Traffic might come to > the AS at either site, and has to be routed internally to get to the > other. I am afraid I have to disagree with Marshall. The idea behind an AS when the routing protocols were written long ago may have been a contiguous domain, but there are lots of things the protocols did not originally envision. If you have two islands, and they each have a prefix which is globally routable, there is nothing wrong with the two islands sharing a single ASN. Island A announces Prefix A, and Island B announces Prefix B. Routing is done by prefix, not ASN, so there is no fear of Island A getting packets for Island B, and therefore no requirement for internal connectivity. And before anyone says anything about Island A not having connectivity to Island B, these are obviously not "transit free" networks, so each island can just point default. In fact, cisco even has a knob to listen to paths with your own ASN in it so you can do this without default (although I'm not sure I'd recommend that). It works fine and saves the community from burning an ASN. -- TTFN, patrick From ops.lists at gmail.com Sat May 24 21:13:19 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 25 May 2008 07:43:19 +0530 Subject: amazonaws.com? In-Reply-To: <18488.28249.428093.815912@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> Message-ID: On Sun, May 25, 2008 at 1:06 AM, Barry Shein wrote: > Even when someone declines a charge it doesn't mean you can't collect > what you believe to be money legitimately owed you. You can hand it to > a collection agency if it's worthwhile. If not (e.g., you took a card > w/o any verification from someone in a country whose name you can't > even pronounce) OH WELL, you're a fool, or it better be part of your > cost of doing business. The funny part is, the scam artists already know that "mismatch between account holder's name and cc holder's name / address / country" is one of the first and most elementary anti fraud checks. So, if they steal a cc from Joe Sixpack of Bumfuck, Iowa, guess who signs up to Amazon AWS for 200 VMs and 20 minutes worth of service? --srs From bmanning at vacation.karoshi.com Sat May 24 22:40:12 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 25 May 2008 03:40:12 +0000 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: References: Message-ID: <20080525034012.GA23446@vacation.karoshi.com.> sure it is. the magical anycast, used by many for DNS service delivery oes exactly this. --bill On Fri, May 23, 2008 at 07:15:52PM -0500, devang patel wrote: > Hello, > > Is that okay to use Same AS number for the two different site on different > location? > > regards > Devang Patel From karnaugh at karnaugh.za.net Sun May 25 02:02:21 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Sun, 25 May 2008 09:02:21 +0200 Subject: amazonaws.com? In-Reply-To: <18488.28249.428093.815912@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> Message-ID: <48390EFD.3000306@karnaugh.za.net> On 24/05/2008 21:36 Barry Shein wrote: > Anyhow, it's not my problem to get them paid, it's my problem when > they're aiding and abetting criminals who harm me and my business. Well, all I know is that they deliberately leave the compute cloud ranges in blacklists. I don't really like the idea of using DNS blacklists but they work. As I also said, you have many peoples blessing to simply block the entire range as per their service terms they don't gurantee mail going out at all - blocking 25 entirely would be counter productive to allowing people to use an authenticated relay though unless they used the submission port. It is entirely possible that the spammers do pay for the service genuinely though, since it's very cheap. -- Colin Alston ~ http://syllogism.co.za/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From jabley at ca.afilias.info Sun May 25 05:17:55 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sun, 25 May 2008 10:17:55 +0000 Subject: Same AS number from different location In-Reply-To: References: Message-ID: On 24 May 2008, at 00:08, devang patel wrote: > Is that okay to use Same AS number for the two different site on > different > location? From the perspective of the rest of the Internet, it will be indistinguishable from a topologically-distributed AS with interior connectivity, with a different exit policy in different places. So yes, it will work. You should note, though, that in the presence of interior connectivity (e.g. a circuit directly between the sites) site A would learn routing information about site B internally, and it would not matter that site A doesn't hear BGP routes announced to the Internet from site B (in fact, that would be a feature). If you have no internal connectivity, you might have to think a little harder about that. I have seen some people plumb tunnels between their sites to provide interior-looking connectivity where none actually exists. I have seen other people not worry so much, and just point default at transit from each place. > as well as any good documentation or link or deployment scenario > where I can > find the merging of two different AS into one AS? > As well as what to do if I have an IP addresses as a service provider > dependent block and want to migrate IP addressing to the IANA > assigned ip > addresses? I seem to think you'll find presentations about AS consolidation in the NANOG meeting archives, somewhere. But basically you join your ASes together, start advertising routes from the to-remain AS and drop the corresponding routes from the going-away AS, with appropriate pauses for checks and breathing. To renumber, change the addresses on individual things with appropriate pauses for DNS TTL expiry. Where changes require interaction with customers, good luck and be patient (or drive round and change the config on their routers yourself, or give up waiting and expect them to get back to you when their net stops working, as appropriate). Joe From ge at linuxbox.org Sun May 25 05:27:36 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 25 May 2008 05:27:36 -0500 (CDT) Subject: [NANOG] IOS rootkits In-Reply-To: <48309C29.70700@bogus.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> Message-ID: On Sun, 18 May 2008, Joel Jaeggli wrote: > Dragos Ruiu wrote: > >> First of all about prevention, I'm not at all sure about this being >> covered by existing router security planning / BCP. >> I don't believe most operators reflash their routers periodically, nor >> check existing images (particularly because the tools for this >> integrity verification don't even exist). If I'm wrong about this I >> would love to be corrected with pointers to the tools. > > I have 6 years worth of rancid logs for every time the reported number > of blocks in use on my flash changes, I imagine others do as well. > That's hardly the silver bullet however. Cisco considerably updated its rootkits page (which was 3 lines, yes, just 3 lines, last week, you might think it was a previously unknown threat). Last Updated 2008 May 22 1600 UTC (GMT) For Public Release 2008 May 16 0400 UTC (GMT) Some update! The new page gives a lot of information on best practices, MD5 verifications, etc. Very good as a security best practices page but still not much of an "anti rootkit" page. Well worth taking a look: http://www.cisco.com/warp/public/707/cisco-sr-20080516-rootkits.shtml Again, very good page even if it in no way addresses the threat. Last week my opinions were well-formed after a few years of thinking on the subject. I decided to re-examine my take as I may have just stagnated on the issue and the landscape changed. I reached the same conclusions. Still no decent response on why they never spoke to their clients on Trojan horses on IOS, rootkits on IOS.. or practically, what tools they provide to deal with them or what their plans are to help us protect ourselves and our infrastructure. One could guess they have non. As someone recently mentioned to me, after the Michael Lynn talk they started admitting to remote code execution vulnerabilities being more than just DoS in their announcements. Maybe that is a trend and we will get more information from them in the future, now that rootkits as a threat to IOS is a publis issue. Cisco's "threats don't exist until our clients already know of them" strategy is running out of steam, and will soon outlive its usefulness. Cisco is acting pretty much like Microsoft did 10 years ago, they shouldn't be surprised if security research treats them the same way as it treated Microsoft. I know what their treatment made _me_ do psychologically, it made me not want to reach out to them. It seems like the Michael Lynn way is the only way to go with their current attitude--full disclosure. As to the risk itself, it is my personal belief IOS rootkits are currently a threat as a targeted attack. Therefore, although of serious concern it is not yet something I fear on the Internet scale. Pure FUD, Cisco provided us with no real data: I do however dread the day XR gains some popularity, then it is as bad as Windows XP exploitability-wise. 2003, year of the worm. 2013, year of the Cisco worms? Gadi. From bzs at world.std.com Sun May 25 13:14:38 2008 From: bzs at world.std.com (Barry Shein) Date: Sun, 25 May 2008 14:14:38 -0400 Subject: amazonaws.com? In-Reply-To: <48390EFD.3000306@karnaugh.za.net> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> <48390EFD.3000306@karnaugh.za.net> Message-ID: <18489.44174.799122.202793@world.std.com> If I may be so bold as to summarize a few posts: It's ok to let spammers and other criminals use your systems (e.g., compute clouds) to slam others just so long as you get yourself into the various blacklists. But I thought (routed) bandwidth was the ISP's stock in trade? And trust (e.g., whaddya think of people who hijack IP blocks?) I don't think it's ok for someone to be slamming my bandwidth and computrons, even at the firewall. As was mentioned some of these clouds are looking at multiple 10gb connections. Just because I can fend off seeing their content at my end doesn't mean I'm not being damaged. I have to keep up with their bandwidth and firewall computron usage, and managing usage of the blacklists. That's damages. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From christian at visr.org Sun May 25 18:26:24 2008 From: christian at visr.org (Christian) Date: Sun, 25 May 2008 19:26:24 -0400 Subject: [NANOG] IOS rootkits In-Reply-To: References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> Message-ID: <9b62cf2f0805251626q6b7c4af7yc445d4cebfffdcb9@mail.gmail.com> any news of the presentation surfacing anywhere? interested to details of what was discussed On Sun, May 25, 2008 at 6:27 AM, Gadi Evron wrote: > On Sun, 18 May 2008, Joel Jaeggli wrote: > >> Dragos Ruiu wrote: >> >> First of all about prevention, I'm not at all sure about this being >>> covered by existing router security planning / BCP. >>> I don't believe most operators reflash their routers periodically, nor >>> check existing images (particularly because the tools for this >>> integrity verification don't even exist). If I'm wrong about this I >>> would love to be corrected with pointers to the tools. >>> >> >> I have 6 years worth of rancid logs for every time the reported number >> of blocks in use on my flash changes, I imagine others do as well. >> That's hardly the silver bullet however. >> > > Cisco considerably updated its rootkits page (which was 3 lines, yes, just > 3 lines, last week, you might think it was a previously unknown threat). > > Last Updated 2008 May 22 1600 UTC (GMT) > For Public Release 2008 May 16 0400 UTC (GMT) > Some update! > > The new page gives a lot of information on best practices, MD5 > verifications, etc. Very good as a security best practices page but still > not much of an "anti rootkit" page. Well worth taking a look: > > http://www.cisco.com/warp/public/707/cisco-sr-20080516-rootkits.shtml > > Again, very good page even if it in no way addresses the threat. > > Last week my opinions were well-formed after a few years of thinking on the > subject. I decided to re-examine my take as I may have just stagnated on the > issue and the landscape changed. I reached the same conclusions. > > Still no decent response on why they never spoke to their clients on Trojan > horses on IOS, rootkits on IOS.. or practically, what tools they provide to > deal with them or what their plans are to help us protect ourselves and our > infrastructure. One could guess they have non. > > As someone recently mentioned to me, after the Michael Lynn talk they > started admitting to remote code execution vulnerabilities being more than > just DoS in their announcements. Maybe that is a trend and we will get more > information from them in the future, now that rootkits as a threat to IOS is > a publis issue. > > Cisco's "threats don't exist until our clients already know of them" > strategy is running out of steam, and will soon outlive its usefulness. > Cisco is acting pretty much like Microsoft did 10 years ago, they shouldn't > be surprised if security research treats them the same way as it treated > Microsoft. > > I know what their treatment made _me_ do psychologically, it made me not > want to reach out to them. It seems like the Michael Lynn way is the only > way to go with their current attitude--full disclosure. > > As to the risk itself, it is my personal belief IOS rootkits are currently > a threat as a targeted attack. Therefore, although of serious concern it is > not yet something I fear on the Internet scale. > > Pure FUD, Cisco provided us with no real data: > I do however dread the day XR gains some popularity, then it is as bad as > Windows XP exploitability-wise. 2003, year of the worm. 2013, year of the > Cisco worms? > > Gadi. > > From aaron.glenn at gmail.com Sun May 25 19:18:13 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sun, 25 May 2008 17:18:13 -0700 Subject: [NANOG] IOS rootkits In-Reply-To: <9b62cf2f0805251626q6b7c4af7yc445d4cebfffdcb9@mail.gmail.com> References: <20080516.210000.6055.0@webmail15.vgs.untd.com> <620fd17c0805162357p5d4b62ebh1e2b557286ca3506@mail.gmail.com> <482E866E.8000000@internode.com.au> <7723C954-E108-4388-A046-9DE520F3A394@kyx.net> <48309C29.70700@bogus.com> <9b62cf2f0805251626q6b7c4af7yc445d4cebfffdcb9@mail.gmail.com> Message-ID: <18f601940805251718k16996714hf277ba7c04a07fe9@mail.gmail.com> On Sun, May 25, 2008 at 4:26 PM, Christian wrote: > any news of the presentation surfacing anywhere? interested to details of > what was discussed yeah. where's the beef?* *not that I don't think said beef exists. From devangnp at gmail.com Sun May 25 21:55:19 2008 From: devangnp at gmail.com (devang patel) Date: Sun, 25 May 2008 21:55:19 -0500 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: <20080525034012.GA23446@vacation.karoshi.com.> References: <20080525034012.GA23446@vacation.karoshi.com.> Message-ID: Hi, So if I will have the globally unique IP addresses for both the site which are located at different location then its perfectly fine to use the same as number in for same organisation having two different site located at different location...right!!! regards Devang Patel On Sat, May 24, 2008 at 10:40 PM, wrote: > > sure it is. the magical anycast, used by many for DNS service delivery > oes exactly this. > > --bill > > > On Fri, May 23, 2008 at 07:15:52PM -0500, devang patel wrote: > > Hello, > > > > Is that okay to use Same AS number for the two different site on > different > > location? > > > > regards > > Devang Patel > From jay at west.net Sun May 25 22:25:02 2008 From: jay at west.net (Jay Hennigan) Date: Sun, 25 May 2008 20:25:02 -0700 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: References: <20080525034012.GA23446@vacation.karoshi.com.> Message-ID: <483A2D8E.7080407@west.net> devang patel wrote: > So if I will have the globally unique IP addresses for both the site which > are located at different location then its perfectly fine to use the same as > number in for same organisation having two different site located at > different location...right!!! Right. But as others have stated you will have to do some configuration in order for the two locations to communicate *with each other*. There are a a few different ways to accomplish this as has been discussed previously. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From bmanning at vacation.karoshi.com Sun May 25 22:25:41 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 26 May 2008 03:25:41 +0000 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: References: <20080525034012.GA23446@vacation.karoshi.com.> Message-ID: <20080526032541.GA6326@vacation.karoshi.com.> ascii art: (==== Internet =====) | | 192.0.2.10 192.0.2.10 | | AS-0 AS-0 | | 256.0.0.0 256.0.0.0 works a treat (as Joe Abley mentions as well). --bill On Sun, May 25, 2008 at 09:55:19PM -0500, devang patel wrote: > Hi, > > So if I will have the globally unique IP addresses for both the site which > are located at different location then its perfectly fine to use the same as > number in for same organisation having two different site located at > different location...right!!! > > > regards > Devang Patel > On Sat, May 24, 2008 at 10:40 PM, wrote: > > > > > sure it is. the magical anycast, used by many for DNS service delivery > > oes exactly this. > > > > --bill > > > > > > On Fri, May 23, 2008 at 07:15:52PM -0500, devang patel wrote: > > > Hello, > > > > > > Is that okay to use Same AS number for the two different site on > > different > > > location? > > > > > > regards > > > Devang Patel > > From devangnp at gmail.com Sun May 25 23:29:49 2008 From: devangnp at gmail.com (devang patel) Date: Sun, 25 May 2008 23:29:49 -0500 Subject: Same AS number from different location and Migration of IP addresses In-Reply-To: <483A2D8E.7080407@west.net> References: <20080525034012.GA23446@vacation.karoshi.com.> <483A2D8E.7080407@west.net> Message-ID: Hi, Yes I do have link between two sites so I will configure routing accordingly so communication between two sites will follow that link... regards Devang Patel On Sun, May 25, 2008 at 10:25 PM, Jay Hennigan wrote: > devang patel wrote: > > So if I will have the globally unique IP addresses for both the site which >> are located at different location then its perfectly fine to use the same >> as >> number in for same organisation having two different site located at >> different location...right!!! >> > > Right. > > But as others have stated you will have to do some configuration in order > for the two locations to communicate *with each other*. > > There are a a few different ways to accomplish this as has been discussed > previously. > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From bzs at world.std.com Mon May 26 02:17:23 2008 From: bzs at world.std.com (Barry Shein) Date: Mon, 26 May 2008 03:17:23 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> Message-ID: <18490.25603.517718.744351@world.std.com> On May 25, 2008 at 22:11 beckman at angryox.com (Peter Beckman) wrote: > On Sat, 24 May 2008, Barry Shein wrote: > > > Since this comment applies equally to every single credit card payment on > > the internet etc I suppose you've just proven that credit cards can't > > possibly work and even Amazon itself is an impossibility. Perhaps we can > > move on to why bumble bees can't fly? > > It's clear to me that people believe it is easy, cheap and inexpensive to > prevent credit card fraud. You think this until you yourself run a small > business, and an entire months profits go into the toilet because you > missed someone who got through what you thought were thorough checks for > fraud. Hello, let me introduce myself to you. I'm Barry Shein, president of The World, the oldest public access internet service provider on the planet, since 1989 (see rfc 2235). We have always taken credit cards. But thank you for the lecture on doing business with credit cards and the potential pitfalls. Anyhow, let me reiterate, making Amazon's business models work, or ensuring that their customers can get the service they want when they want it, is none of my concern. What is my concern is if they're running their resources so irresponsibly that it permits criminals to use them to damage my business. Personally I don't really care if their compute cloud service succeeds or fails, except on general principles (I always like to wish people well.) But if their business model is designed so poorly that it enables criminality to be directed at my business then, for me, that's a problem. So I'm not particularly interested in how hard it would be for Amazon to make a buck on cloud services if they had to stop damaging me. 'kay? This thread started when I found my mail servers being pounded by their cloud machines for a day or so. It's since stopped, thank you, but a few here indicated, and I don't know if they speak with any authority, that Amazon seems to believe that so long as their cloud machines are in blacklists then they shouldn't have to feel any responsibilty to exercise any control over them vis a vis spammers et al. It should just be up to the rest of us to buy sufficient firewalls and bandwidth and staff to manage it all. That sounds so outlandish that I am suspicious of its origin. But others indicated "they're in the blacklists so what's your beef?" and I responded that there's a problem with large computing resources (their clouds) pounding on my mail servers even if we can dodge seeing the content with blacklist entries. > > Declining a legitimate charge can be a criminal fraud. > > In what world do you live in? I can decline to take anyone's money and > decline to provide them service, for any reason. If I don't like your I'm sorry, you're having trouble with the english language, let me help you out here: That comment was in response to a reference to a credit card customer declining a legitimate charge for goods and/or services s/he received. Ya know, you buy a laptop over the net on a credit card, the laptop comes, and then you try to decline the charge? Got it? That can be a criminal fraud. Whatever the relevance that's what that comment was referring to. > tone, I don't take your money, you don't get my service. Criminal fraud, > ha. Where exactly do you live? Maybe I assume to much, because in the > US, I get to decide who's money I take. (key in twilight zone music) You've been hurt before, haven't you? (whoo boy, angry man alert...) -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From karnaugh at karnaugh.za.net Mon May 26 02:58:37 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 26 May 2008 09:58:37 +0200 Subject: amazonaws.com? In-Reply-To: <18490.25603.517718.744351@world.std.com> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> <18490.25603.517718.744351@world.std.com> Message-ID: <483A6DAD.4080006@karnaugh.za.net> On 26/05/2008 09:17 Barry Shein wrote: > It's since stopped, thank you, but a few here indicated, and I don't > know if they speak with any authority, that Amazon seems to believe > that so long as their cloud machines are in blacklists then they > shouldn't have to feel any responsibilty to exercise any control over > them vis a vis spammers et al. You are speaking a bit hyperbolically and that is not what anyone believes or feels. Much like any large datacenter or hosting provider it is not feasible to police every packet in and out of the network, I assume "The World" has lots of experience with super-scale networks so I'll limit my "lecturing" on the subject. Regardless, like any large datacenter or hosting provider they can only respond to complaints when they get them, and they do, and they respond (unless you have evidence to suggest the contrary). As a corollary to this I was simply noting that their terms do not include the ability to SMTP at all and as such the ranges are left in any blacklists they might fall into. You are also free to block them for SMTP on your own kit given this directive. Blocking at RCPT time or even before limits any bandwidth usage from spam to negligible amounts in most cases. The consequences of blocking TCP/25 as an upstream though is much worse since customers frown on upstream port filtering and it makes SMTP impossible for everything except those which accept the submission port. Many people may still have numerous valid reasons for using port 25 to talk to their own kit somewhere else. -- Colin Alston ~ http://syllogism.co.za/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From dhetzel at gmail.com Mon May 26 09:31:31 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 26 May 2008 10:31:31 -0400 Subject: amazonaws.com? In-Reply-To: <48386842.20007@rollernet.us> References: <200805232359.m4NNxUEY020333@world.std.com> <9C67F9CD-1584-4200-AB01-BEE146B8592B@blighty.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> Message-ID: <2ee691ff0805260731h714c096fx6b106ffd2df31450@mail.gmail.com> Requiring accounts have more time active with charges on the same credit card than the length of the chargeback window before they can transmit on 25, or be filled by wire transfer if someone is in a huge hurry would certainly do the trick.n Yes, some business would be lost, but probably not much. On Sat, May 24, 2008 at 3:10 PM, Seth Mattinen wrote: > Barry Shein wrote: > >> > not to excuse this, but... it's not a simple problem. The 'bad guy' >> > rolls up to the website, orders 200 machines for 20 mins under the >> > name 'xplosiveman' pays with some paypal/CC and runs his/her job. That >> > job happens to create a bunch of email outbound. It could be a >> > legitimate email service outsourcing their compute/bw needs to AWS, it >> > could be 'pick-yer-bad-spammer' ... AWS really can't tell until after >> > when the complaints roll in. :( >> >> Oh rubbish, it's a trivial problem. >> >> You verify the payment method in advance and make it clear in the >> agreement to use the resources that any of the following activities >> (list, define...) will be billed at a steep rate (e.g., $100 per >> spamming complaint) and make some reasonable effort to ensure you can >> collect that, like do an authorize on their credit card (that's what >> hotels do to reserve but not charge typically $1000 or whatever on >> your card when you check in.) >> >> It's trivial, using your systems to spam is a cost, make sure at the >> very least you get paid for it. >> >> > And 6 months later, a chargeback shows up because the cardholder claims > their card was used fraudulently. The bank will most likely side with the > cardholder if you challenge it. How can that loophole be closed? > > ~Seth > > > From ops.lists at gmail.com Mon May 26 11:13:12 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 26 May 2008 21:43:12 +0530 Subject: amazonaws.com? In-Reply-To: <483A6DAD.4080006@karnaugh.za.net> References: <200805232359.m4NNxUEY020333@world.std.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> <18490.25603.517718.744351@world.std.com> <483A6DAD.4080006@karnaugh.za.net> Message-ID: On Mon, May 26, 2008 at 1:28 PM, Colin Alston wrote: > Much like any large datacenter or hosting provider it is not feasible to > police every packet in and out of the network, I assume "The World" has lots Not a question of packet policing as much as having sufficient controls in place to get rid of card fraud, regular audits etc .. and THEN looking for obvious signs of abuse, proactively (inbound and outbound traffic flow analysis, passive dns checks and a whole host of other things that are possible). The second thing is, of course, having an active abuse desk, but by the time an abuse desk gets around to reading and responding to the complaint, the damage is done (1 business day is a very good turnaround indeed, at shops rather larger than world.std.com). > (unless you have evidence to suggest the contrary). As a corollary to this I > was simply noting that their terms do not include the ability to SMTP at all > and as such the ranges are left in any blacklists they might fall into. You With respect, in such cases, amazon is better off firewalling outbound port 25 (or indeed, outbound anything at all) for accounts that dont specifically ask for it. Quite a lot of EC2 compute time is for number crunching and such - not just hosting, or email, or .. srs From bonomi at mail.r-bonomi.com Mon May 26 11:38:47 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 26 May 2008 11:38:47 -0500 (CDT) Subject: amazonaws.com? Message-ID: <200805261638.m4QGclFj010401@mail.r-bonomi.com> > From: "Suresh Ramasubramanian" > Subject: Re: amazonaws.com? > > On Mon, May 26, 2008 at 1:28 PM, Colin Alston > wrote: [[.. sneck ..]] > With respect, in such cases, amazon is better off firewalling outbound > port 25 (or indeed, outbound anything at all) for accounts that dont > specifically ask for it. Quite a lot of EC2 compute time is for > number crunching and such - not just hosting, or email, or .. I'm hard-pressed to think of a single letigimate use for a _compute_ cluster that requires outgoing access to more than a handful (i.e. an _itemizable_ list) of machines. Am I missing something obvious? If not, such a "block all outgoing, except for listed exceptions" policy could be 'trivially' implemented with an extra list field on the sign-up form, coupled with automated transformation into firewall rules. From karnaugh at karnaugh.za.net Mon May 26 14:40:17 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 26 May 2008 21:40:17 +0200 Subject: amazonaws.com? In-Reply-To: References: <200805232359.m4NNxUEY020333@world.std.com> <4837C292.8060605@karnaugh.za.net> <47B83FB5-710B-46CD-BE28-1EF77FDD5B77@somewhere.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> <18490.25603.517718.744351@world.std.com> <483A6DAD.4080006@karnaugh.za.net> Message-ID: <483B1221.7070904@karnaugh.za.net> On 26/05/2008 18:13 Suresh Ramasubramanian wrote: > Quite a lot of EC2 compute time is for > number crunching and such - not just hosting, or email, or .. That's not actually true, the trend is towards thumbnail generation and video encoding dispatch for sites that use it, this requires getting the information back to storage. Mail processing would be an entirely valid use of this as well - you could for instance offload your own mail to EC2 instances for virus scanning and Bayesian spam filtering. Either way, limiting of ports is a direct and undeniable limiting of the capability of the product. A staggeringly large amount of my spam comes from DSL lines in eastern europe and such places, and yet for some reason I don't see anyone here asserting that DSL lines should only be used for POP, IMAP and WWW and to talk to your ISP's SMTP relay. That's because it's a stupid move. It doesn't matter what EC2 or any service is used for, it's sold as having an IP connection, not IP minus whatever TCP ports NANOG people dictate based on their beliefs about how you should do business or how customers should use it. I agree with abuse reports and active abuse desks but please, don't for one second expect me to believe you side with the idea that upstream providers and hosts should randomly firewall ports - since 90% of the time, as history has shown me, they screw it up. -- Colin Alston ~ http://syllogism.co.za/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From ops.lists at gmail.com Mon May 26 21:16:26 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 27 May 2008 07:46:26 +0530 Subject: amazonaws.com? In-Reply-To: <483B1221.7070904@karnaugh.za.net> References: <200805232359.m4NNxUEY020333@world.std.com> <75cb24520805241108h30d0d7c8wba68941d4809d5b6@mail.gmail.com> <18488.24389.732571.594007@world.std.com> <48386842.20007@rollernet.us> <18488.28249.428093.815912@world.std.com> <18490.25603.517718.744351@world.std.com> <483A6DAD.4080006@karnaugh.za.net> <483B1221.7070904@karnaugh.za.net> Message-ID: On Tue, May 27, 2008 at 1:10 AM, Colin Alston wrote: > On 26/05/2008 18:13 Suresh Ramasubramanian wrote: >> I didnt actually, Bonomi did .. but going on .. >> Quite a lot of EC2 compute time is for >> number crunching and such - not just hosting, or email, or .. > > That's not actually true, the trend is towards thumbnail generation and > video encoding dispatch for sites that use it, this requires getting the [yes, that's right - twitter seems to be using it for example] > Either way, limiting of ports is a direct and undeniable limiting of the > capability of the product. A staggeringly large amount of my spam comes from > DSL lines in eastern europe and such places, and yet for some reason I don't You're at odds with a lot of best practice there. This one for example - http://www.maawg.org/port25 > I agree with abuse reports and active abuse desks but please, don't for one > second expect me to believe you side with the idea that upstream providers > and hosts should randomly firewall ports - since 90% of the time, as history > has shown me, they screw it up. I am sure that all the nanog regulars here who are / have been the guys with enable on tier 1 networks routers (and run huge dialup/dsl pools) will agree with that (!) Port firewalling, especially port 25 firewalling, isnt - or rather shouldnt be - random. There are enough cookbook configs to just blanket block port 25, and far more advanced configs (ask Chris Morrow sometime about huge uunet dialup pools with radius filters to punch holes for port 25 connectivity to different ISP smarthosts etc etc) --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From nicolist at securite.org Tue May 27 02:03:54 2008 From: nicolist at securite.org (Nicolas FISCHBACH) Date: Tue, 27 May 2008 09:03:54 +0200 Subject: IOS Rookit: the sky isn't falling (yet) Message-ID: <483BB25A.4030204@securite.org> I finally got to see Topo's presentation this week-end at PH-Neutral and discuss it with him and FX. Given that the slides aren't online yet [1], that Core hasn't published Topo's technical paper on their website [2] yet either, and that I'm done replying to direct inquiries about it [3], here's a summary of the IOS rootkit saga and its impact on the Service Provider community (from my point of view :) Topo spent a lot of time (and if you ever loaded an IOS image in IDA you know what I'm talking about) analyzing strings and functions in IOS. In his proof of concept he located the code doing the password check and adds a trampoline to his backdoor code (by saving paramaters, glueing the two codes together, doing the "new" password check and returning properly to the main code path). Nice lesson on 101 hooking on IOS. The (oversimplified) modus operandi is pretty straight forward: take an image, decompress it, have his tool locate the function and later patch it, add his code by overwriting large strings, (re)compress the image and (re)calculate/fix the checksums. Pretty neat. The fact that he doesn't do basic binary patching makes the approach portable and not architecture, version or feature set specific. This image then needs to be uploaded to the router and the device need to be reloaded. This backdoor is persistent (vs the old backdoor trick using the TCL shell [4] which wasn't - or if you want to turn it into a non-volatile one it was easy to detect as in clear text in the startup/running configuration). An alternative approach is to use gdb on the router (and combine it with a TCL script to make it easier) and patch on the fly. This is non-persistent, but some people don't wan't to leave traces as large as an IOS image behind :) Or another alternative approach: network boot the router via TFTP. At the end of the day this is nothing new from a rootkit technology point of view, but it's in the IOS/router world. He deserves credit to actually have researched this in deep and managed to make it work (it's much more difficult to achieve this on a mostly undocumented and large binary than on common OSes). Respect. What's the best way to actually test this when you don't have the HW you ask ? Dynamips [9] is the answer. As long as the rootkit isn't too advanced and e.g. also hooks the write/copy functions (e.g. an attacker could store the image diff on the system and play a "proper" memory dump or proper IOS back when you write core/copy to TFTP) then FX's CIR[7] is the forensics tool of choice. On platforms where the IOS image is stored on an external flash card forensics may be easier. Here's [8] a "screenshot" of CIR vs Topo. So what's the impact today ? Topo's proof of concept doesn't bypass ACLs (rACLs, VTY ACLs), AAA, etc [yet], requires enable rights, a new image and a reload (or enable only if you do gdb-on-the-fly patching). In summary it's "noisy" and unless you bought the router on an auction site and/or download IOS from "alternative" sources) you should notice (or probably deserve to get owned :) See the Cisco PSIRT response for best current practices on securing routers [10] and my old forensics presentation [3]. In the past FX [5] and Mike Lynn [6] proved that code execution is doable. This is a different approach. Can it be combined ? Probably. It is much more complex ? Yes. Is it going to be architecture specific ? Probably. Future developments ? I'm surprised people still focus on the IOS side of things and don't attack the bootrom code as it's smaller and usually never changed unless you bring in some new/unsupported hardware/features. IOS-XR is probably going to become a target too as it makes some of these things easier [11] but code signing may have to be broken/bypassed first. This has been done on other devices, so it's just one more layer to attack. An alternative rootkit ? Privilege level 16 used by the Lawful Intercept [12] feature could be abused to do some of this too. Or the other way around: use a "patched" IOS to keep an eye on Law Enforcement's operations on the router as privilege level 15 doesn't allow it and the only alternative is to sniff the traffic export. I've probably missed some stuff (and got some stuff wrong), but this summary became way too long already and it's late. Feedback welcome! [1] Dragos should post them soon here: http://www.eusecwest.com/ [2] Watch http://www.coresecurity.com/?module=ContentMod&action=news&id=papers [3] Google "IOS rootkit" used to return the presentation below as first hit "Cisco Router Forensics" - http://www.securite.org/presentations/secip/ [4] http://seclists.org/bugtraq/2007/Nov/0384.html [5] http://www.phenoelit-us.org/ultimaratio/index.html http://www.milw0rm.com/exploits/77 [6] http://cryptome.org/lynn-cisco.pdf [7] http://cir.recurity.com/ [8] http://www.securite.org/nico/XP/CIRvsTopo.jpg [9] http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator [10] http://www.cisco.com/en/US/products/products_security_response09186a0080997783.html [11] http://lists.darklab.org/pipermail/darklab/2005-August/000029.html [12] http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lawf_int.html Nico. -- Nicolas FISCHBACH Senior Manager - Network Engineering/Security - COLT Telecom e:(nico at securite.org) w: From a.harrowell at gmail.com Tue May 27 07:42:23 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 27 May 2008 13:42:23 +0100 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <483BB25A.4030204@securite.org> References: <483BB25A.4030204@securite.org> Message-ID: >An alternative rootkit ? Privilege level 16 used by the Lawful Intercept >[12] feature could be abused to do some of this too. Or the other way >around: use a "patched" IOS to keep an eye on Law Enforcement's >operations on the router as privilege level 15 doesn't allow it and the only >alternative is to sniff the traffic export. The combination of rootkits and specially privileged Lawful Intercept functions is a very dangerous one. This was precisely what was exploited in the now-legendary and still unsolved Vodafone Greece hack. Alex From rsk at gsp.org Tue May 27 08:00:36 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 27 May 2008 09:00:36 -0400 Subject: outages mailing list is back online! In-Reply-To: <48373297.8070403@gmail.com> References: <48373297.8070403@gmail.com> Message-ID: <20080527130036.GA26085@gsp.org> Not quite. Outages list traffic appears to be originating from 209.151.108.146, which has rDNS mx2.amigostecnicos.net, which has forward DNS 209.151.108.152, which does not match the originating IP. This inconsistency may cause deferral/rejection/quarantining depending on how recipients' MTAs are configured. For example, sendmail with require_rdns switched on responds with a 451 to this. I suggest fixing the DNS inconsistency. ---Rsk From christian at visr.org Tue May 27 09:15:38 2008 From: christian at visr.org (Christian) Date: Tue, 27 May 2008 10:15:38 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <483BB25A.4030204@securite.org> References: <483BB25A.4030204@securite.org> Message-ID: <9b62cf2f0805270715r6e8d19f3g98f2dcc58bf39f39@mail.gmail.com> interesting, thanks for the summary.. until the presentation becomes available On Tue, May 27, 2008 at 3:03 AM, Nicolas FISCHBACH wrote: > I finally got to see Topo's presentation this week-end at PH-Neutral and > discuss > it with him and FX. > > Given that the slides aren't online yet [1], that Core hasn't published > Topo's > technical paper on their website [2] yet either, and that I'm done replying > to > direct inquiries about it [3], here's a summary of the IOS rootkit saga and > its > impact on the Service Provider community (from my point of view :) > > Topo spent a lot of time (and if you ever loaded an IOS image in IDA you > know > what I'm talking about) analyzing strings and functions in IOS. In his > proof > of concept he located the code doing the password check and adds a > trampoline > to his backdoor code (by saving paramaters, glueing the two codes together, > doing the "new" password check and returning properly to the main code > path). > Nice lesson on 101 hooking on IOS. > > The (oversimplified) modus operandi is pretty straight forward: take an > image, > decompress it, have his tool locate the function and later patch it, add > his > code by overwriting large strings, (re)compress the image and > (re)calculate/fix > the checksums. Pretty neat. The fact that he doesn't do basic binary > patching > makes the approach portable and not architecture, version or feature set > specific. > > This image then needs to be uploaded to the router and the device need to > be > reloaded. This backdoor is persistent (vs the old backdoor trick using the > TCL > shell [4] which wasn't - or if you want to turn it into a non-volatile one > it > was easy to detect as in clear text in the startup/running configuration). > > An alternative approach is to use gdb on the router (and combine it with a > TCL > script to make it easier) and patch on the fly. This is non-persistent, but > some people don't wan't to leave traces as large as an IOS image behind :) > Or another alternative approach: network boot the router via TFTP. > > At the end of the day this is nothing new from a rootkit technology point > of > view, but it's in the IOS/router world. He deserves credit to actually have > researched this in deep and managed to make it work (it's much more > difficult > to achieve this on a mostly undocumented and large binary than on common > OSes). > Respect. > > What's the best way to actually test this when you don't have the HW you > ask ? > Dynamips [9] is the answer. > > As long as the rootkit isn't too advanced and e.g. also hooks the > write/copy > functions (e.g. an attacker could store the image diff on the system and > play > a "proper" memory dump or proper IOS back when you write core/copy to TFTP) > then > FX's CIR[7] is the forensics tool of choice. On platforms where the IOS > image > is stored on an external flash card forensics may be easier. > > Here's [8] a "screenshot" of CIR vs Topo. > > So what's the impact today ? Topo's proof of concept doesn't bypass ACLs > (rACLs, > VTY ACLs), AAA, etc [yet], requires enable rights, a new image and a reload > (or > enable only if you do gdb-on-the-fly patching). In summary it's "noisy" and > unless you bought the router on an auction site and/or download IOS from > "alternative" sources) you should notice (or probably deserve to get owned > :) > > See the Cisco PSIRT response for best current practices on securing routers > [10] > and my old forensics presentation [3]. > > In the past FX [5] and Mike Lynn [6] proved that code execution is doable. > This is a different approach. Can it be combined ? Probably. It is much > more > complex ? Yes. Is it going to be architecture specific ? Probably. > > Future developments ? I'm surprised people still focus on the IOS side of > things > and don't attack the bootrom code as it's smaller and usually never changed > unless you bring in some new/unsupported hardware/features. IOS-XR is > probably going to become a target too as it makes some of these things > easier > [11] but code signing may have to be broken/bypassed first. This has been > done > on other devices, so it's just one more layer to attack. > > An alternative rootkit ? Privilege level 16 used by the Lawful Intercept > [12] > feature could be abused to do some of this too. Or the other way around: > use a > "patched" IOS to keep an eye on Law Enforcement's operations on the router > as > privilege level 15 doesn't allow it and the only alternative is to sniff > the > traffic export. > > I've probably missed some stuff (and got some stuff wrong), but this > summary > became way too long already and it's late. Feedback welcome! > > [1] Dragos should post them soon here: http://www.eusecwest.com/ > [2] Watch > http://www.coresecurity.com/?module=ContentMod&action=news&id=papers > [3] Google "IOS rootkit" used to return the presentation below as first > hit > "Cisco Router Forensics" - > http://www.securite.org/presentations/secip/ > [4] http://seclists.org/bugtraq/2007/Nov/0384.html > [5] http://www.phenoelit-us.org/ultimaratio/index.html > http://www.milw0rm.com/exploits/77 > [6] http://cryptome.org/lynn-cisco.pdf > [7] http://cir.recurity.com/ > [8] http://www.securite.org/nico/XP/CIRvsTopo.jpg > [9] http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator > [10] > > http://www.cisco.com/en/US/products/products_security_response09186a0080997783.html > [11] http://lists.darklab.org/pipermail/darklab/2005-August/000029.html > [12] http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/lawf_int.html > > Nico. > -- > Nicolas FISCHBACH > Senior Manager - Network Engineering/Security - COLT Telecom > e:(nico at securite.org) w: > > From morrowc.lists at gmail.com Tue May 27 10:32:52 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 27 May 2008 11:32:52 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> Message-ID: <75cb24520805270832y4f15daa6pbc32fdf760bd227a@mail.gmail.com> On Tue, May 27, 2008 at 8:42 AM, Alexander Harrowell wrote: >>An alternative rootkit ? Privilege level 16 used by the Lawful Intercept >>[12] feature could be abused to do some of this too. Or the other way >>around: use a "patched" IOS to keep an eye on Law Enforcement's >operations > on the router as privilege level 15 doesn't allow it and the only >>alternative is to sniff the traffic export. > > The combination of rootkits and specially privileged Lawful Intercept > functions is a very dangerous one. This was precisely what was exploited in > the now-legendary and still unsolved Vodafone Greece hack. to be clear though, the LI functions on cisco are audit-able (assuming the ios is still cisco not patched/hacked) you just have to snmp-v3 to audit the activities... which most mediation devices have to do because the settings don't get committed to config so upon system reload they have to be re-set to baseline again. -Chris From bonomi at mail.r-bonomi.com Tue May 27 10:33:54 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 27 May 2008 10:33:54 -0500 (CDT) Subject: amazonaws.com? Message-ID: <200805271533.m4RFXsI8024116@mail.r-bonomi.com> > From nanog-bounces at nanog.org Mon May 26 21:16:58 2008 > Date: Tue, 27 May 2008 07:46:26 +0530 > From: "Suresh Ramasubramanian" > To: "Colin Alston" > Subject: Re: amazonaws.com? > Cc: nanog at merit.edu > > On Tue, May 27, 2008 at 1:10 AM, Colin Alston wrote: > > On 26/05/2008 18:13 Suresh Ramasubramanian wrote: > >> > > I didnt actually, Bonomi did .. but going on .. Mis-credit where mis-credit isn't due ... Twasn't me, either. I just commented that I couldn't think of a reason for a _compute_ cluster to need access to unlimited remote machines/ports. And that it could 'trivially' be made an _automatic_ part of the 'compute session' config -- to allow access to a laundry-list of ports/machines, and those ports/machines -only-. If Amazon were a 'good neighbor', they _would_ implement something like this. That they see no need to do _anything_ -- when _actual_ problems, which are directly attributable to their failure to do so, have been brought to their attention -- does argue in favor of wholesale firewalling of the EC2 address- space. If the address-space owner won't police it's own property, there is no reason for the rest of the world to spend the time/effort to _selectively_ police it for them. Amazon _might_ 'get a clue' if enough providers walled off the EC2 space, and they found difficulty selling cycles to people who couldn't access the machines to set up their compute applications. From jared at puck.nether.net Tue May 27 10:41:17 2008 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 May 2008 11:41:17 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> Message-ID: <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote: >> An alternative rootkit ? Privilege level 16 used by the Lawful >> Intercept >> [12] feature could be abused to do some of this too. Or the other way >> around: use a "patched" IOS to keep an eye on Law Enforcement's >> >operations > on the router as privilege level 15 doesn't allow it and the only >> alternative is to sniff the traffic export. > > The combination of rootkits and specially privileged Lawful Intercept > functions is a very dangerous one. This was precisely what was > exploited in > the now-legendary and still unsolved Vodafone Greece hack. Perhaps the above should be simplified. Running a hacked/modded IOS version is a dangerous prospect. This seems like such a non-event because what is the exploit path to load the image? There needs to be a primary exploit to load the malware image. *yawn* - Jared From virendra.rode at gmail.com Tue May 27 10:41:36 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Tue, 27 May 2008 08:41:36 -0700 Subject: outages mailing list is back online! In-Reply-To: <20080527130036.GA26085@gsp.org> References: <48373297.8070403@gmail.com> <20080527130036.GA26085@gsp.org> Message-ID: <483C2BB0.2030205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Rich Kulawiec wrote: > Not quite. Outages list traffic appears to be originating from > 209.151.108.146, which has rDNS mx2.amigostecnicos.net, which has > forward DNS 209.151.108.152, which does not match the originating IP. > This inconsistency may cause deferral/rejection/quarantining depending > on how recipients' MTAs are configured. For example, sendmail with > require_rdns switched on responds with a 451 to this. > > I suggest fixing the DNS inconsistency. > > ---Rsk > - -------------------------- outages mail is being delivered.....but the second entry is botched, we'll address it. isotf.org has address 209.151.108.158 isotf.org mail is handled by 10 mail.isotf.org. isotf.org mail is handled by 50 mx2.amigostecnicos.net. vrode at promiscious:~$ host mx2.amigostecnicos.net. mx2.amigostecnicos.net has address 209.151.108.152 vrode at promiscious:~$ host 209.151.108.152 152.108.151.209.in-addr.arpa domain name pointer mx.amigostecnicos.net. vrode at promiscious:~$ host 209.151.108.146 146.108.151.209.in-addr.arpa domain name pointer mx2.amigostecnicos.net. thanks for bringing it up. regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIPCuvpbZvCIJx1bcRAoKMAKCzO+Y5p6D2bgDNIqzPqhGjWo6OLQCeMoJ+ EHEoXiMIJOXkqr4oGfyTk+M= =HUPX -----END PGP SIGNATURE----- From jra at baylink.com Tue May 27 10:50:50 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 27 May 2008 11:50:50 -0400 Subject: outages mailing list is back online! In-Reply-To: <483C2BB0.2030205@gmail.com> References: <48373297.8070403@gmail.com> <20080527130036.GA26085@gsp.org> <483C2BB0.2030205@gmail.com> Message-ID: <20080527155050.GP23607@cgi.jachomes.com> On Tue, May 27, 2008 at 08:41:36AM -0700, virendra rode // wrote: > vrode at promiscious:~$ host mx2.amigostecnicos.net. I believe you've mispelt promiscuous. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Tue May 27 10:50:50 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 27 May 2008 11:50:50 -0400 Subject: outages mailing list is back online! In-Reply-To: <483C2BB0.2030205@gmail.com> References: <48373297.8070403@gmail.com> <20080527130036.GA26085@gsp.org> <483C2BB0.2030205@gmail.com> Message-ID: <20080527155050.GP23607@cgi.jachomes.com> On Tue, May 27, 2008 at 08:41:36AM -0700, virendra rode // wrote: > vrode at promiscious:~$ host mx2.amigostecnicos.net. I believe you've mispelt promiscuous. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From ge at linuxbox.org Tue May 27 11:02:32 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 27 May 2008 11:02:32 -0500 (CDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: On Tue, 27 May 2008, Jared Mauch wrote: > > On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote: > >>> An alternative rootkit ? Privilege level 16 used by the Lawful Intercept >>> [12] feature could be abused to do some of this too. Or the other way >>> around: use a "patched" IOS to keep an eye on Law Enforcement's >>> >operations >> on the router as privilege level 15 doesn't allow it and the only >>> alternative is to sniff the traffic export. >> >> The combination of rootkits and specially privileged Lawful Intercept >> functions is a very dangerous one. This was precisely what was exploited in >> the now-legendary and still unsolved Vodafone Greece hack. > > Perhaps the above should be simplified. > > Running a hacked/modded IOS version is a dangerous prospect. > > This seems like such a non-event because what is the exploit path to load the > image? There needs to be a primary exploit to load the malware image. > > *yawn* I guess we will wait for the next one before waking up, than. > - Jared Gadi. From jra at baylink.com Tue May 27 11:30:09 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 27 May 2008 12:30:09 -0400 Subject: META: duplicate posts? In-Reply-To: <20080527155050.GP23607@cgi.jachomes.com> References: <48373297.8070403@gmail.com> <20080527130036.GA26085@gsp.org> <483C2BB0.2030205@gmail.com> <20080527155050.GP23607@cgi.jachomes.com> Message-ID: <20080527163009.GS23607@cgi.jachomes.com> On Tue, May 27, 2008 at 11:50:50AM -0400, Jay R. Ashworth wrote: > Date: Tue, 27 May 2008 11:50:50 -0400 > From: "Jay R. Ashworth" > To: nanog at nanog.org, NANOG > Subject: Re: outages mailing list is back online! > > On Tue, May 27, 2008 at 08:41:36AM -0700, virendra rode // wrote: > > vrode at promiscious:~$ host mx2.amigostecnicos.net. > > I believe you've mispelt promiscuous. :-) I was clearly not paying enough attention to the message to which I replied... but why did 2 copies of it make it through the machinery? I would have assumed nanog at nanog and nanog at merit went to the same copy of Mailman, which should have noted the identical message-id's and bounced one; no? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Tue May 27 11:30:09 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 27 May 2008 12:30:09 -0400 Subject: META: duplicate posts? In-Reply-To: <20080527155050.GP23607@cgi.jachomes.com> References: <48373297.8070403@gmail.com> <20080527130036.GA26085@gsp.org> <483C2BB0.2030205@gmail.com> <20080527155050.GP23607@cgi.jachomes.com> Message-ID: <20080527163009.GS23607@cgi.jachomes.com> On Tue, May 27, 2008 at 11:50:50AM -0400, Jay R. Ashworth wrote: > Date: Tue, 27 May 2008 11:50:50 -0400 > From: "Jay R. Ashworth" > To: nanog at nanog.org, NANOG > Subject: Re: outages mailing list is back online! > > On Tue, May 27, 2008 at 08:41:36AM -0700, virendra rode // wrote: > > vrode at promiscious:~$ host mx2.amigostecnicos.net. > > I believe you've mispelt promiscuous. :-) I was clearly not paying enough attention to the message to which I replied... but why did 2 copies of it make it through the machinery? I would have assumed nanog at nanog and nanog at merit went to the same copy of Mailman, which should have noted the identical message-id's and bounced one; no? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From tme at multicasttech.com Tue May 27 11:32:16 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 27 May 2008 12:32:16 -0400 Subject: SEA-ME-WE-4 cut ? Message-ID: <5B990169-19C3-40EA-BECD-3792613EDB27@multicasttech.com> Has anyone heard of a cut in SEA-ME-WE-4 off Singapore sometime about 36 hours ago ? We received a report of this, but no circuit alarms, which is odd. Regards Marshall From copraphage at gmail.com Tue May 27 11:38:20 2008 From: copraphage at gmail.com (Chris McDonald) Date: Tue, 27 May 2008 12:38:20 -0400 Subject: SEA-ME-WE-4 cut ? In-Reply-To: <5B990169-19C3-40EA-BECD-3792613EDB27@multicasttech.com> References: <5B990169-19C3-40EA-BECD-3792613EDB27@multicasttech.com> Message-ID: <25dbbe250805270938j1fda31d7u3fb23b5402a06a31@mail.gmail.com> "SMW4 Cable segment 1.1 cable fault A cable fault was observed on SMW4 Seg. 1.1 (Singapore - Branching Unit #1A) at 03:15GMT on 26-May. The fault point is about 46km from TUAS Singapore cable station. Services will resume upon cable repair complete. Cable ship Asean Restorer was mobilized for the repair." On Tue, May 27, 2008 at 12:32 PM, Marshall Eubanks wrote: > Has anyone heard of a cut in SEA-ME-WE-4 off Singapore sometime about 36 > hours ago ? > We received a report of this, but no circuit alarms, which is odd. > > Regards > Marshall > > > From ghicks at cadence.com Tue May 27 11:36:43 2008 From: ghicks at cadence.com (Gregory Hicks) Date: Tue, 27 May 2008 09:36:43 -0700 (PDT) Subject: META: duplicate posts? Message-ID: <200805271636.m4RGahhl027772@mailhub.Cadence.COM> > Date: Tue, 27 May 2008 12:30:09 -0400 > From: "Jay R. Ashworth" > To: nanog at nanog.org, NANOG > Subject: META: duplicate posts? > > On Tue, May 27, 2008 at 11:50:50AM -0400, Jay R. Ashworth wrote: > > Date: Tue, 27 May 2008 11:50:50 -0400 > > From: "Jay R. Ashworth" > > To: nanog at nanog.org, NANOG > > Subject: Re: outages mailing list is back online! > > > > On Tue, May 27, 2008 at 08:41:36AM -0700, virendra rode // wrote: > > > vrode at promiscious:~$ host mx2.amigostecnicos.net. > > > > I believe you've mispelt promiscuous. :-) > > I was clearly not paying enough attention to the message to which I > replied... but why did 2 copies of it make it through the machinery? Because the address nanog at merit.edu is still active. Or at least, the list @merit forwards to @nanog.org... > I would have assumed nanog at nanog and nanog at merit went to the same copy > of Mailman, which should have noted the identical message-id's and > bounced one; no? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Joseph Stalin) > ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 2655 Seely Ave M/S 9A1 San Jose, CA 95134 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." "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From ghicks at cadence.com Tue May 27 11:36:43 2008 From: ghicks at cadence.com (Gregory Hicks) Date: Tue, 27 May 2008 09:36:43 -0700 (PDT) Subject: META: duplicate posts? Message-ID: <200805271636.m4RGahhl027772@mailhub.Cadence.COM> > Date: Tue, 27 May 2008 12:30:09 -0400 > From: "Jay R. Ashworth" > To: nanog at nanog.org, NANOG > Subject: META: duplicate posts? > > On Tue, May 27, 2008 at 11:50:50AM -0400, Jay R. Ashworth wrote: > > Date: Tue, 27 May 2008 11:50:50 -0400 > > From: "Jay R. Ashworth" > > To: nanog at nanog.org, NANOG > > Subject: Re: outages mailing list is back online! > > > > On Tue, May 27, 2008 at 08:41:36AM -0700, virendra rode // wrote: > > > vrode at promiscious:~$ host mx2.amigostecnicos.net. > > > > I believe you've mispelt promiscuous. :-) > > I was clearly not paying enough attention to the message to which I > replied... but why did 2 copies of it make it through the machinery? Because the address nanog at merit.edu is still active. Or at least, the list @merit forwards to @nanog.org... > I would have assumed nanog at nanog and nanog at merit went to the same copy > of Mailman, which should have noted the identical message-id's and > bounced one; no? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com '87 e24 > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > Those who cast the vote decide nothing. > Those who count the vote decide everything. > -- (Joseph Stalin) > ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 2655 Seely Ave M/S 9A1 San Jose, CA 95134 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." "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From Valdis.Kletnieks at vt.edu Tue May 27 11:57:17 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 May 2008 12:57:17 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: Your message of "Tue, 27 May 2008 11:02:32 CDT." References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: <21778.1211907437@turing-police.cc.vt.edu> On Tue, 27 May 2008 11:02:32 CDT, Gadi Evron said: > On Tue, 27 May 2008, Jared Mauch wrote: > > *yawn* > > I guess we will wait for the next one before waking up, than. No Gadi. What Jared is saying is that there are exactly *ZERO* routers (for some infinitesimally small value of zero) that will get rootkitted that weren't *already* vulnerable to the stuff that Lynn talked about three years ago. There's basically 2 classes of Cisco routers out there: 1) Ones managed by Jared and similarly clued people, who can quite rightfully yawn because the specter of "IOS rootkits" changes nothing in their actual threat model - they put stuff in place 3 years ago to mitigate "Lynn-style IOS pwnage", and it will stop this just as well. Move along, nothing to see. 2) Ones managed by unclued people. And quite frankly, if Lynn didn't wake them up 3 years ago, this isn't going to wake them up either. Move along, nothing new to see here either. "60% of routers run by bozos who shouldn't have enable. Film at 11". *yawn*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From michael.dillon at bt.com Tue May 27 12:08:16 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 May 2008 18:08:16 +0100 Subject: amazonaws.com? In-Reply-To: <200805271533.m4RFXsI8024116@mail.r-bonomi.com> References: <200805271533.m4RFXsI8024116@mail.r-bonomi.com> Message-ID: > If the address-space owner won't police it's own property, > there is no reason for the rest of the world to spend the > time/effort to _selectively_ police it for them. Exactly!!! If an SMTP server operator is not willing to police their server by implementing a list of approved email partners, then why should the rest of the Internet have to block outgoing port 25 connections? The buck needs to stop right where the problem is and that is on the SMTP servers that are promiscuously allowing almost any IP address to open an socket with them and inject email messages. > Amazon _might_ 'get a clue' if enough providers walled off > the EC2 space, and they found difficulty selling cycles to > people who couldn't access the machines to set up their > compute applications. Amazon might get a clue and sue companies who take such outrageously extreme action. Even if you are being slammed by millions of email messaged from Amazon address space, that is not justification for blocking all access to the space. It's a point problem on your mail server so leave the shotgun alone, and put an ACL blocking port 25 access to your mail server. I don't believe that horrendously broken email architecture and email operators with no vision, are sufficient justification for blocking new and innovative business models on the Internet. 10 months of the year, Amazon has 10 times as many servers as they need. They want to rent them out piecemeal and I applaud their innovation. Maybe their model is not perfect yet, but the solution to that is not to raise a lynch mob. Instead you should build a better cloud computing business and beat them that way. --Michael Dillon From adrian at creative.net.au Tue May 27 12:13:20 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 28 May 2008 01:13:20 +0800 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <21778.1211907437@turing-police.cc.vt.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> Message-ID: <20080527171319.GE2135@skywalker.creative.net.au> On Tue, May 27, 2008, Valdis.Kletnieks at vt.edu wrote: > There's basically 2 classes of Cisco routers out there: > > 1) Ones managed by Jared and similarly clued people, who can quite rightfully > yawn because the specter of "IOS rootkits" changes nothing in their actual > threat model - they put stuff in place 3 years ago to mitigate "Lynn-style IOS > pwnage", and it will stop this just as well. Move along, nothing to see. > > 2) Ones managed by unclued people. And quite frankly, if Lynn didn't wake > them up 3 years ago, this isn't going to wake them up either. Move along, > nothing new to see here either. > > "60% of routers run by bozos who shouldn't have enable. Film at 11". Bloody network people, always assuming their network security stops at their router. So nowthat someone's done the hard lifting to backdoor an IOS binary, and I'm assuming you all either upgrade by downloading from the cisco.com website or maintain a set of your own images somewhere, all one needs to do is insert themselves into -that- path and you're screwed. Hijacking prefixes isn't hard. That was presented at the same security conference. Cracking a UNIX/Windows management/FTP/TFTP host isn't impossible - how many large networks have their server infrastructure run by different people to their network infrastructure? Lots and lots? :) Sure, its not all fire and brimstone, but the bar -was- dropped a little, and somehow you need to make sure that the IOS thats sitting on your network management site is indeed the IOS that you put there in the first place.. Adrian From michael.dillon at bt.com Tue May 27 12:15:31 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 May 2008 18:15:31 +0100 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: > This seems like such a non-event because what is the exploit > path to load the image? There needs to be a primary exploit > to load the malware image. Hmmm. Get a job servicing/installing data centre HVAC systems, wait until you get called out to a mostly empty data center, lift some floor tiles or change a flash with tongs through a wire cage, or whatever. Maybe make some "fog" in the room to block the security cameras while you do your work. Maybe bribe the security guard to look the other way, or just bribe the NOC employees. There are hundreds of ways for a primary exploit to happen. The Internet data center may not be the primary target of the people who try these things, i.e. Cisco's main customer base is the enterprise, not the ISP. The fact is that there are more and more reasons why someone would go to all the trouble of exploiting one or two routers in this way. Do you have the processes and systems to demonstrate that it has not happened already? --Michael Dillon From sean at donelan.com Tue May 27 12:22:52 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 27 May 2008 13:22:52 -0400 (EDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: On Tue, 27 May 2008, Gadi Evron wrote: >> Perhaps the above should be simplified. >> >> Running a hacked/modded IOS version is a dangerous prospect. >> >> This seems like such a non-event because what is the exploit path to load >> the image? There needs to be a primary exploit to load the malware image. >> >> *yawn* > > I guess we will wait for the next one before waking up, than. If you let people load unauthorized images on your equipment, you probably have bigger problems than potential rootkits. It may be a better use of resources to prevent people from installing unauthorized images on your hardware versus debating all the things an unauthorized image could do after it is installed. Other things you could install rootkits on, if you can load unauthorized images on the device: Anything with a CPU and loadable images. Even old fashion printing presses are vulnerable to the old fashion version of a rootkit. If you could replace the printing press plates with unauthorized plates, you could change what the printing press printed. Modifying printing plates is the easy part, getting the unauthorized printing plates on the printing press is the trick. From jared at puck.nether.net Tue May 27 12:23:34 2008 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 May 2008 13:23:34 -0400 Subject: IOS Rookit: running hacked binaries certainly places you at risk! In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: On May 27, 2008, at 12:02 PM, Gadi Evron wrote: > On Tue, 27 May 2008, Jared Mauch wrote: >> >> On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote: >> >>>> An alternative rootkit ? Privilege level 16 used by the Lawful >>>> Intercept >>>> [12] feature could be abused to do some of this too. Or the other >>>> way >>>> around: use a "patched" IOS to keep an eye on Law Enforcement's >>>> >operations >>> on the router as privilege level 15 doesn't allow it and the only >>>> alternative is to sniff the traffic export. >>> The combination of rootkits and specially privileged Lawful >>> Intercept >>> functions is a very dangerous one. This was precisely what was >>> exploited in >>> the now-legendary and still unsolved Vodafone Greece hack. >> >> Perhaps the above should be simplified. >> >> Running a hacked/modded IOS version is a dangerous prospect. >> >> This seems like such a non-event because what is the exploit path >> to load the image? There needs to be a primary exploit to load the >> malware image. >> >> *yawn* > > I guess we will wait for the next one before waking up, than. You seem to be missing the point and I'm concerned that wasting my time attempting to educate you and others on this topic is fruitless, but I will attempt the impossible. Surely you should insure your devices are secured and audit their security. Attack vectors change over time. This case is easily mitigated against if Cisco shipped signed binaries and the platform performed this validation. That's not something unique, but something that is unavailable today. I state again: Running any random code will certainly put you at risk, this continues to be the case for routers in the same way as it is for the millions of infected PCs. I await information on the remote router exploit path and the mitigation strategy you allude to in your above bait. Without compromising the router in the first place, either physically by swapping the image media (hard drive, flash of varying varieties) or remotely with some unnamed and perhaps unfound 0-day exploit, the strategy outlined in this thread is not a viable one. Anyone following a set of "sane" practices, (watching those flash/disk inserted/removed messages in your syslogs and doing image validation will help mitigate the risk). There's alternate cases that have not been outlined here that could prove to be more problematic and cause you to do some incident response but I will not outline those in this public forum. From cgrundemann at gmail.com Tue May 27 12:24:19 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 27 May 2008 11:24:19 -0600 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <20080527171319.GE2135@skywalker.creative.net.au> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> Message-ID: <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> On Tue, May 27, 2008 at 11:13 AM, Adrian Chadd wrote: > > Bloody network people, always assuming their network security stops at > their router. > > So nowthat someone's done the hard lifting to backdoor an IOS binary, > and I'm assuming you all either upgrade by downloading from the cisco.com > website or maintain a set of your own images somewhere, all one needs > to do is insert themselves into -that- path and you're screwed. > > Hijacking prefixes isn't hard. That was presented at the same security > conference. > > Cracking a UNIX/Windows management/FTP/TFTP host isn't impossible - how > many large networks have their server infrastructure run by different > people to their network infrastructure? Lots and lots? :) > > Sure, its not all fire and brimstone, but the bar -was- dropped a little, > and somehow you need to make sure that the IOS thats sitting on your > network management site is indeed the IOS that you put there in the > first place.. Like MD5 File Validation? - "MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values." ~Chris > > > > > Adrian > > > -- Chris Grundemann www.linkedin.com/in/cgrundemann From adrian at creative.net.au Tue May 27 12:29:03 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 28 May 2008 01:29:03 +0800 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> Message-ID: <20080527172903.GF2135@skywalker.creative.net.au> On Tue, May 27, 2008, Chris Grundemann wrote: > > Sure, its not all fire and brimstone, but the bar -was- dropped a little, > > and somehow you need to make sure that the IOS thats sitting on your > > network management site is indeed the IOS that you put there in the > > first place.. > > Like MD5 File Validation? - "MD5 values are now made available on > Cisco.com for all Cisco IOS software images for comparison against > local system image values." Yes, but the only thing the router checks iirc is the old-style checksum, and not some oob provided md5 hash? And if you can exploit the management box itself, you can load your own MD5 hash in. This is all the sort of stuff that public key crypto and chains of trust were meant to solve, IIRC.. Adrian From Frank.DelungJr at Level3.com Tue May 27 12:30:18 2008 From: Frank.DelungJr at Level3.com (Delung Jr, Frank) Date: Tue, 27 May 2008 11:30:18 -0600 Subject: unsubscribe Message-ID: <978DDEB4E5924B4AAA158EB54EB93FE429392F2B93@idc1embx0002.corp.global.level3.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: Blank Bkgrd.gif Type: image/gif Size: 145 bytes Desc: Blank Bkgrd.gif URL: From Valdis.Kletnieks at vt.edu Tue May 27 12:35:41 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 May 2008 13:35:41 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: Your message of "Tue, 27 May 2008 11:24:19 MDT." <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> Message-ID: <23642.1211909741@turing-police.cc.vt.edu> On Tue, 27 May 2008 11:24:19 MDT, Chris Grundemann said: > Like MD5 File Validation? - "MD5 values are now made available on > Cisco.com for all Cisco IOS software images for comparison against > local system image values." That does wonders for catching a corruption in the FTP that wasn't caught by the relatively weak TCP checksumming. But if the attacker has the wherewithal to cause a modified file to be downloaded (either by replacing it on the real server, or getting you to visit a fake server), they can also present you with a webpage that has an MD5 hash that matches the modified file. Now, if they provided a PGP signature of the file, done with a key that I have reason to trust, *that* raises the bar significantly... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Pederson at Covad.COM Tue May 27 12:37:35 2008 From: Pederson at Covad.COM (Pederson, Krishna) Date: Tue, 27 May 2008 10:37:35 -0700 Subject: unsubscribe In-Reply-To: <978DDEB4E5924B4AAA158EB54EB93FE429392F2B93@idc1embx0002.corp.global.level3.com> Message-ID: <3BC5D44AB71A754FAE3CA68A7597EABE74A4B5@ZANEVS03.cc-ntd1.covad.com> Really now ... why we using nanog at merit.edu instead of nanog at nanog.org? Totally messed up my mail filtering system. Sometime last week people started sending TO or CC'ing nanog at merit.edu instead of nanog at nanog.org. Can we go back? Thanks, mkay. Kris -----Original Message----- From: Delung Jr, Frank [mailto:Frank.DelungJr at Level3.com] Sent: Tuesday, May 27, 2008 10:30 AM To: 'nanog at merit.edu' Subject: unsubscribe From mlinsenmayer at symantec.com Tue May 27 12:37:43 2008 From: mlinsenmayer at symantec.com (Mike Linsenmayer) Date: Tue, 27 May 2008 10:37:43 -0700 Subject: IPV6 network feeds Message-ID: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> Hey all, I am looking for a IPV6 internet feed for our testing labs in Southern California, I know this is off subject but I am a little exasperated in trying to locate one. if anyone on the list knows of a provider please contact me off list. Thanks! Mike Linsenmayer Sr. Manager Labs Engineering QALABS Symantec Corporation www.symantec.com ___________________________ Office: 424.750.7560 Cell: 805.404.1813 YIM: mike_linsenmayer ___________________________ ___________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1765 bytes Desc: image001.gif URL: From tims at donet.com Tue May 27 12:40:25 2008 From: tims at donet.com (Tim Sanderson) Date: Tue, 27 May 2008 13:40:25 -0400 Subject: unsubscribe In-Reply-To: <3BC5D44AB71A754FAE3CA68A7597EABE74A4B5@ZANEVS03.cc-ntd1.covad.com> References: <978DDEB4E5924B4AAA158EB54EB93FE429392F2B93@idc1embx0002.corp.global.level3.com> <3BC5D44AB71A754FAE3CA68A7597EABE74A4B5@ZANEVS03.cc-ntd1.covad.com> Message-ID: Same gripe here... -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Pederson, Krishna [mailto:Pederson at Covad.COM] Sent: Tuesday, May 27, 2008 1:38 PM To: Delung Jr, Frank; nanog at merit.edu Subject: RE: unsubscribe Really now ... why we using nanog at merit.edu instead of nanog at nanog.org? Totally messed up my mail filtering system. Sometime last week people started sending TO or CC'ing nanog at merit.edu instead of nanog at nanog.org. Can we go back? Thanks, mkay. Kris -----Original Message----- From: Delung Jr, Frank [mailto:Frank.DelungJr at Level3.com] Sent: Tuesday, May 27, 2008 10:30 AM To: 'nanog at merit.edu' Subject: unsubscribe From charles at thewybles.com Tue May 27 12:45:56 2008 From: charles at thewybles.com (charles at thewybles.com) Date: Tue, 27 May 2008 17:45:56 +0000 Subject: IPV6 network feeds In-Reply-To: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> Message-ID: <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> What kind of existing connectivity do you have? Who provides your local loop? Verizon provides ipv6 connectivity according to their website. At&t most likely does as well. Charles Sent via BlackBerry from T-Mobile -----Original Message----- From: "Mike Linsenmayer" Date: Tue, 27 May 2008 10:37:43 To: Subject: IPV6 network feeds Hey all, I am looking for a IPV6 internet feed for our testing labs in Southern California, I know this is off subject but I am a little exasperated in trying to locate one. if anyone on the list knows of a provider please contact me off list. Thanks! Mike Linsenmayer Sr. Manager Labs Engineering QALABS Symantec Corporation www.symantec.com ___________________________ Office: 424.750.7560 Cell: 805.404.1813 YIM: mike_linsenmayer ___________________________ ___________________________ From goemon at anime.net Tue May 27 12:47:08 2008 From: goemon at anime.net (goemon at anime.net) Date: Tue, 27 May 2008 10:47:08 -0700 (PDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <23642.1211909741@turing-police.cc.vt.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <23642.1211909741@turing-police.cc.vt.edu> Message-ID: On Tue, 27 May 2008, Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 May 2008 11:24:19 MDT, Chris Grundemann said: >> Like MD5 File Validation? - "MD5 values are now made available on >> Cisco.com for all Cisco IOS software images for comparison against >> local system image values." > That does wonders for catching a corruption in the FTP that wasn't caught > by the relatively weak TCP checksumming. > But if the attacker has the wherewithal to cause a modified file to be > downloaded (either by replacing it on the real server, or getting you to > visit a fake server), they can also present you with a webpage that has an > MD5 hash that matches the modified file. > Now, if they provided a PGP signature of the file, done with a key that I > have reason to trust, *that* raises the bar significantly... What you want is cisco hardware that verifies firmware signatures in hardware. -Dan From doon.bulk at inoc.net Tue May 27 12:48:53 2008 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Tue, 27 May 2008 13:48:53 -0400 Subject: unsubscribe In-Reply-To: <3BC5D44AB71A754FAE3CA68A7597EABE74A4B5@ZANEVS03.cc-ntd1.covad.com> References: <3BC5D44AB71A754FAE3CA68A7597EABE74A4B5@ZANEVS03.cc-ntd1.covad.com> Message-ID: <20D7C6D7-1CA3-4B50-8E6C-29585F32A7DB@inoc.net> On May 27, 2008, at 1:37 PM, Pederson, Krishna wrote: > Really now ... why we using nanog at merit.edu instead of > nanog at nanog.org? > Totally messed up my mail filtering system. > Sometime last week people started sending TO or CC'ing nanog at merit.edu > instead of nanog at nanog.org. > > Can we go back? Thanks, mkay. X-BeenThere: nanog at nanog.org FTW! Is there regardless of which alias to the list used, much easier to filter on IMHO -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Don't try to out-weird me, three eyes. I get weirder things than you in my breakfast cereal. - Zaphod Beeblebrox, The Hitchhiker's Guide to the Galaxy From ghicks at cadence.com Tue May 27 12:50:18 2008 From: ghicks at cadence.com (Gregory Hicks) Date: Tue, 27 May 2008 10:50:18 -0700 (PDT) Subject: unsubscribe Message-ID: <200805271750.m4RHoHhl017592@mailhub.Cadence.COM> > Subject: RE: unsubscribe > Date: Tue, 27 May 2008 10:37:35 -0700 > From: "Pederson, Krishna" > To: "Delung Jr, Frank" , > > Really now ... why we using nanog at merit.edu instead of nanog at nanog.org? > Totally messed up my mail filtering system. Because there are people left in the world that did not get the word that the mailer was moving from merit->nanog.org. So some forwarding mechanism was left in place at merit so that mail to the old system would get forwarded to the new system. Frank found out that addresses of the form To: "nanog at merit.edu" were interpreted by Mutt to be TWO separate addresses - even though one of them was a "constant" (thusly identified by the quote marks around the text... and should have been ignored. The "@" made Mutt think it was an actual address that its' user mis-typed. So to fix the user's mistake, Mutt forwarded the mail to the mis-typed address.) My diagnosis. Sounds reasonable anyway. > Sometime last week people started sending TO or CC'ing nanog at merit.edu > instead of nanog at nanog.org. > > Can we go back? Thanks, mkay. > > Kris > > > -----Original Message----- > From: Delung Jr, Frank [mailto:Frank.DelungJr at Level3.com] > Sent: Tuesday, May 27, 2008 10:30 AM > To: 'nanog at merit.edu' > Subject: unsubscribe > > > > > > ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 2655 Seely Ave M/S 9A1 San Jose, CA 95134 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." "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From black at csulb.edu Tue May 27 12:52:10 2008 From: black at csulb.edu (Matthew Black) Date: Tue, 27 May 2008 10:52:10 -0700 Subject: Fake-alert: VERIFY YOUR MERIT.EDU WEBMAIL ACCOUNT In-Reply-To: <1211645673.2541.3.camel@ernie.internal.graemef.net> References: <48382E10.70904@peter-dambier.de> <1211645673.2541.3.camel@ernie.internal.graemef.net> Message-ID: On Sat, 24 May 2008 17:14:33 +0100 Graeme Fowler wrote: > On Sat, 2008-05-24 at 17:02 +0200, Peter Dambier wrote: >> I dont trust it: > > Quite right too, it's a spear-phishing attack. This is currently an > almost daily occurrence for .edu domains. > > The compromised accounts are frequently abused via webmail systems, > being used to send out more scams. > > The scammers responsible are also targeting UK higher ed institutions, > with a limited degree of success. I can't really speak for my US > counterparts with regards the success of the attacks, but one would > surmise that it's more or less the same. To paraphrase badly: > > All users are gullible, but some are more gullible than others. > > -g As a US EDU, I can attest to the fact that a handful of our webmail accounts have been compromised and subsequently used to send out these types of phishing attacks. We never figured out how the accounts were compromised. I suspect users with hand-held devices are being snooped when they use IMAP. Our webmail is SSL, but not IMAP. Most of the spammers' messages appear as though someone is manually using their cut & paste to generate the spam, not anything automated (based on the rate messages go out. Seems rather tedious. matthew black e-mail postmaster network services california state university, long beach From Valdis.Kletnieks at vt.edu Tue May 27 12:54:19 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 May 2008 13:54:19 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: Your message of "Tue, 27 May 2008 10:47:08 PDT." References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <23642.1211909741@turing-police.cc.vt.edu> Message-ID: <24679.1211910859@turing-police.cc.vt.edu> On Tue, 27 May 2008 10:47:08 PDT, goemon at anime.net said: > What you want is cisco hardware that verifies firmware signatures in > hardware. Yes, but that requires new hardware. Understanding the security risk in accepting an unsigned MD5 signature from the same place that you accepted the file from is a wetware issue. Granted, at many shops hardware upgrades are easier than wetware upgrades. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From surfer at mauigateway.com Tue May 27 12:55:40 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 27 May 2008 10:55:40 -0700 Subject: unsubscribe Message-ID: <20080527105540.203A9046@resin17.mta.everyone.net> ------ tims at donet.com wrote: ------ From: Tim Sanderson Same gripe here... -------Original Message------- From: Pederson, Krishna [mailto:Pederson at Covad.COM] Really now ... why we using nanog at merit.edu instead of nanog at nanog.org? Totally messed up my mail filtering system. Sometime last week people started sending TO or CC'ing nanog at merit.edu instead of nanog at nanog.org. Can we go back? Thanks, mkay. ------------------------------------------- Bummer you can't get your email systems to work. Should 10,000 folks change what they do to what you ask because of that? scott From yahoo at jimpop.com Tue May 27 13:03:13 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Tue, 27 May 2008 14:03:13 -0400 Subject: unsubscribe In-Reply-To: <20080527105540.203A9046@resin17.mta.everyone.net> References: <20080527105540.203A9046@resin17.mta.everyone.net> Message-ID: <7ff145960805271103p2a2f7666s23d9e74c8a5b10ae@mail.gmail.com> On Tue, May 27, 2008 at 1:55 PM, Scott Weeks wrote: > Should 10,000 folks change what they do to what you ask because of that? How many of those 10,000 would need to change, let alone notice a change? I suspect the number is less than 10 (that's ten, not ten thousand). ;-) -Jim P. From bpfankuch at cpgreeley.com Tue May 27 13:13:52 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 27 May 2008 12:13:52 -0600 Subject: unsubscribe In-Reply-To: <7ff145960805271103p2a2f7666s23d9e74c8a5b10ae@mail.gmail.com> References: <20080527105540.203A9046@resin17.mta.everyone.net> <7ff145960805271103p2a2f7666s23d9e74c8a5b10ae@mail.gmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D73C8D23941D@CPExchange1.cpgreeley.com> Didn't even notice as my rule is set as nanog@* -----Original Message----- From: Jim Popovitch [mailto:yahoo at jimpop.com] Sent: Tuesday, May 27, 2008 12:03 PM To: nanog at merit.edu Subject: Re: unsubscribe On Tue, May 27, 2008 at 1:55 PM, Scott Weeks wrote: > Should 10,000 folks change what they do to what you ask because of that? How many of those 10,000 would need to change, let alone notice a change? I suspect the number is less than 10 (that's ten, not ten thousand). ;-) -Jim P. From sdhillon at decarta.com Tue May 27 13:17:03 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Tue, 27 May 2008 11:17:03 -0700 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <23642.1211909741@turing-police.cc.vt.edu> Message-ID: <483C501F.60706@decarta.com> goemon at anime.net wrote: > On Tue, 27 May 2008, Valdis.Kletnieks at vt.edu wrote: >> On Tue, 27 May 2008 11:24:19 MDT, Chris Grundemann said: >>> Like MD5 File Validation? - "MD5 values are now made available on >>> Cisco.com for all Cisco IOS software images for comparison against >>> local system image values." >> That does wonders for catching a corruption in the FTP that wasn't >> caught >> by the relatively weak TCP checksumming. >> But if the attacker has the wherewithal to cause a modified file to be >> downloaded (either by replacing it on the real server, or getting you to >> visit a fake server), they can also present you with a webpage that >> has an >> MD5 hash that matches the modified file. >> Now, if they provided a PGP signature of the file, done with a key >> that I >> have reason to trust, *that* raises the bar significantly... > > What you want is cisco hardware that verifies firmware signatures in > hardware. > > -Dan > Why not TPM? Sign every binary on the device, encrypt & sign the headers. The entire device runs in a hypervisor. Everything must be approved by Cisco. Let's make routers even more blackboxish and require vendor certification for every little thing. I don't know about you, but I don't want layers of DRM and crap ontop of my router when I'm still wondering about idiots leaving tftpds open. :-/ -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From sean at donelan.com Tue May 27 13:20:04 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 27 May 2008 14:20:04 -0400 (EDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <23642.1211909741@turing-police.cc.vt.edu> Message-ID: On Tue, 27 May 2008, goemon at anime.net wrote: > What you want is cisco hardware that verifies firmware signatures in > hardware. Of course, how do you know your hardware hasn't been compromised? http://www.usdoj.gov/opa/pr/2008/February/08_crm_150.html From michael.holstein at csuohio.edu Tue May 27 13:47:10 2008 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 27 May 2008 14:47:10 -0400 Subject: Fake-alert: VERIFY YOUR MERIT.EDU WEBMAIL ACCOUNT In-Reply-To: References: <48382E10.70904@peter-dambier.de> <1211645673.2541.3.camel@ernie.internal.graemef.net> Message-ID: <483C572E.3060800@csuohio.edu> > We never figured out how the accounts were compromised. I suspect another .edu here .. how we've seen it happen is we get blasted by one of those "verify your email account" messages. despite our countless efforts at user education about responding to this stuff, a dozen or so people always do (we try to configure outbound filters to catch it, but don't always do so in time). These accounts are then used by automated scripts to hammer on our webmail (and ours is https, forced). > Most of the spammers' messages appear as though someone > is manually using their cut & paste to generate the spam, > not anything automated (based on the rate messages go out. When we've had it happen, the messages are being relayed at a rate of ~10,000/hr. Note that the messages sent *after* the compromise are NOT more of the "verify your account" type .. they're run-of-the-mill pill and watch adverts. The original "verify your account" stuff comes in from various botnet PCs. Cheers, Michael Holstein Cleveland State University From michael.dillon at bt.com Tue May 27 13:49:21 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 May 2008 19:49:21 +0100 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> Message-ID: > Like MD5 File Validation? - "MD5 values are now made > available on Cisco.com for all Cisco IOS software images for > comparison against local system image values." I would expect a real exploit to try to match Cisco's MD5 hashes. By all means, check those hashes after you download them but I would suggest calculating a hash using an alternate algorithm for later checking. --Michael Dillon From bill at bfccomputing.com Tue May 27 13:47:20 2008 From: bill at bfccomputing.com (Bill McGonigle) Date: Tue, 27 May 2008 14:47:20 -0400 Subject: [NANOG] Fiber Cut at 60 Hudson In-Reply-To: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> Message-ID: <7E2BB500-F802-47F3-BE70-901B458DD984@bfccomputing.com> On May 20, 2008, at 05:33, Robert Blayzor wrote: > Does anyone know of any NY fiber cuts going on near/around 60 Hudson > Street? I have a Level3 DIA Gig-E that's been out for almost 36 hours > and each time I call them I get a different answer on what the problem > is and exactly how much longer this is going to take to be resolved. > We noticed this go down around 7pm EDT on Sunday and the following > morning the dark fiber we have going through 60 Hudson took a hit for > about an hour on one side of our DWDM ring... > > Anyone know whats up? FWIW, Level 3 work at 60 Hudson took out Vermont and adjacent areas on the 20th, the same day as you wrote. Quoting their explanation: ---begin quote--- Level 3 experienced a protected outage that impacted customers in Vermont. While a fiber outage on the working side was being repaired, we experienced a module failure on the protect side. Traffic had been switched to the protect path. Root cause: There were 2 separate situations. 1. A working route between Albany and New York failed due to bad fiber jumpers in at 60 Hudson and this outage was extended due to fibers being moved during troubleshooting which needed to be re-terminated to their original assignments. Traffic was switched to the protect path. 2. While the traffic was switched to the protect path, there was also an Optical Amplifier card failure on an OC-48 riding the protect path through Albany, which resulted in the outage in South Burlington, VT. Once the Field Technician arrived with the new OA card and replaced it, traffic restored. --- end quote --- I've also heard contradictory information from Level3 reps on some of the above, so I'm not asserting any accuracy for it; so just FYI. Maybe they finally got to looking into your problem and unplugged the fiber labeled 'Vermont' by accident. ;) -Bill ----- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 bill at bfccomputing.com Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf From bonomi at mail.r-bonomi.com Tue May 27 13:53:40 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 27 May 2008 13:53:40 -0500 (CDT) Subject: amazonaws.com? Message-ID: <200805271853.m4RIrenk026073@mail.r-bonomi.com> > From nanog-bounces at nanog.org Tue May 27 12:06:50 2008 > Subject: RE: amazonaws.com? > Date: Tue, 27 May 2008 18:08:16 +0100 > From: > To: > > > If the address-space owner won't police it's own property, > > there is no reason for the rest of the world to spend the > > time/effort to _selectively_ police it for them. > > Exactly!!! > If an SMTP server operator is not willing to police their server > by implementing a list of approved email partners, then why should > the rest of the Internet have to block outgoing port 25 connections? Because the _privilege_ to send packets to other networks has been, from 'day one', conditional on the presumption that the sending network _is_ a "good neighbor" to the networks receiving their traffic. AS SUCH, they have a firm 'moral responsibility' to *NOT* let _their_ users =originate= traffic that is harmful/offensive/abusive to the receiving/destination network. Or, are you arguing for _no_ "acceptable use" policies for _anything_ on the 'net. That anyone should be free to attempt anything against any server/network, and that it is the sole responsibility of the receiving system to build and maintain the defenses against "whatever" any malefactor might decide to do? *AND* that the party providing that black hat' with connectivity should bear no responsibility for anything that their customer's do? Thinking about it, I realize that asking _you_ (an employee of major telephone company) is a silly question -- you have a biased viewopoint from a government-regulated monopoly > The buck needs to stop right where the problem is and that is > on the SMTP servers that are promiscuously allowing almost any > IP address to open an socket with them and inject email messages. Since one _cannot_ stop the -attempts- at the destination end, and the volume of -attempts- (even though they're blocked at the fence-line) *CAN* be enough to to render 'normal' operations of the receiving network impossible -- "it should be obvious to the meanest intelligence" that the matter *must* be addressed at a point _upstream_ from the destination network. It is universally recognized in the real world that 'toxic waste' issues must be dealt with at the _source_ point -- where that toxic waste is produced. AND that the costs of doing so should fall on those who produce them. There is no reason that the Internet should be any different. The polluter is the party who *should* get hits with the majority of the costs of handling the toxic waste they produce, not the party simply tryng to enjoy the 'quiet satisfaction' of their own property. It is arguable that the Internet has advanced from the 'early pioneer' days of the '80s, to a state that is comparable to the height of the "Robber Baron" era -- where everybody was out for 'me first, and to h*ll with whomever isn't big enough, mean enough, and tough enough to stand up to whatever I want to do to take advantage of them. History shows that such attitudes weren't right _for_the_world_as_a_whole_ then, and societal barriers were put in place to prevent such abuses from re-occuring. > > Amazon _might_ 'get a clue' if enough providers walled off > > the EC2 space, and they found difficulty selling cycles to > > people who couldn't access the machines to set up their > > compute applications. > > Amazon might get a clue and sue companies who take such outrageously > extreme action. *SNICKER* The results of such a suit are _utterly_ predictable. There's established case-law going back a couple of _decades_. For, example, look at any of the (100% _unsuccessful) suits that "Cyber Promotions, Inc." filed against any of the several providers that did exactly that to said plaintiff. There's similar case law in England, the Netherlands, Germany, Switzerland, Norway, Finland, and Austrailia -- just to name a few of the places where the matter has been litigated. There are no "rights" on the Internet, only "privileges". Your right to access any part of my network exists only -if- I extend you that privilege. And it _is_ revokable at whim. WITHOUT any need to 'show cause why'. Such a suit as you suggest runs the very real risk that the filing party would be sanctioned as regards "frivolous" filings. > Even if you are being slammed by millions of email > messaged from Amazon address space, that is not justification for > blocking all access to the space. It's a point problem on your > mail server so leave the shotgun alone, and put an ACL blocking > port 25 access to your mail server. FALSE TO FACT. If they generate _enough_ 'unwanted' traffic towards me, that can/will constitute a fairly effective (D)DOS attack -- admittedly, it's only 'slightly' distributed, and it's coming from a single block, so it can be dealt with by some forms of point responses. I _cannot_ deal with volume-based DOS at -my- end of my pipes; it -requires- blocking/limiting the traffic *before* it hits the choke-point that is my external connectivity. When that traffic is coming from a 'well defined' source under a single entity's control, *THAT* -- the source -- is the appropriate place to deal with it. In the alternate case -- a widely distributed set of disparate sources -- other methods (usually involving the immediate "upstreams" -- who presumably have enough bigger resources to be able to 'absorb' a volume of toxic waste that would be fatal to me) are necessary. The fact that such methods are necessary in some circumstances does -not- mean that they are the _preferred_ method in all circumstances. > > I don't believe that horrendously broken email architecture and email > operators with no vision, are sufficient justification for blocking new and > innovative business models on the Internet. 10 months of the year, Amazon > has 10 times as many servers as they need. They want to rent them out > piecemeal and I applaud their innovation. Maybe their model is not perfect > yet, but the solution to that is not to raise a lynch mob. Instead you > should build a better cloud computin> business and beat them that way. I applaud their _intentions_, and deplore their *implementation*. They, like many others, have forgotten that "the Internet" is, in fact, a fairly -unique- institution/facility -- where the 'value' of what _you_ offer is contingent on the 'courtesies' you get for free from the rest of the world. Every internet service provider and service offerer *needs* the 'good will' of its competitors _more_ than it needs any of its own customers. Something like the initial part of the Hippocratic Oath is needed for those who consider Internet-based service offerings -- "First, do no evil." People who fail to control the toxic waste emissions from their property are _not_ "good neighbors", and fail that 'do no evil' test. The same for those who allow toxic waste emissions to flow from their networks over the Internet. From jabley at ca.afilias.info Tue May 27 14:06:25 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Tue, 27 May 2008 19:06:25 +0000 Subject: IPV6 network feeds In-Reply-To: <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> Message-ID: <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> On 27 May 2008, at 17:45, charles at thewybles.com wrote: > Verizon provides ipv6 connectivity according to their website. I mentioned this on another list, but if anybody has tried to actually turn the words referred to above into service, I would be very happy to hear about how they did it. > At&t most likely does as well. The last time I attempted to buy 7018 transit I specified that I needed v6, and the answer was "yes, we can do that". But when it came to placing an order, the reaction swiftly changed to "oh, no, actually we can't". There seems to be a certain trend towards claiming IPv6 capability in order to win business, hoping that people are just looking for the check in the box and not actual exchange of packets. Joe From Valdis.Kletnieks at vt.edu Tue May 27 14:07:26 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 May 2008 15:07:26 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: Your message of "Tue, 27 May 2008 19:49:21 BST." References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> Message-ID: <28288.1211915246@turing-police.cc.vt.edu> On Tue, 27 May 2008 19:49:21 BST, michael.dillon at bt.com said: > > Like MD5 File Validation? - "MD5 values are now made=20 > > available on Cisco.com for all Cisco IOS software images for=20 > > comparison against local system image values." > > I would expect a real exploit to try to match Cisco's > MD5 hashes. Although there is a known attack against MD5 that will generate two plaintexts with the same (unpredictable) hash, there is as yet no known way significantly better than brute force to generate a file which hashes to a given hash. On the other hand, there have been multiple cases where vandals have replaced a file on a download site, and updated the webpage to reflect the new MD5 hash. If you were an attacker, which would you go with: 1) The brute-force attack which will require hundreds of thousands of CPU-years. 2) The super-secret attack that causes a collision to a given hash that none of the crypto experts know about yet. 3) 'md5sum trojan_ios.bin' and cut-n-paste that into the web page. > By all means, check those hashes after you download > them but I would suggest calculating a hash using an alternate > algorithm for later checking. You missed the point - if the *FILE* you downloaded from a webpage is suspect, why do you trust the MD5sum that *the same webpage* says is correct? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From karnaugh at karnaugh.za.net Tue May 27 14:08:13 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 27 May 2008 21:08:13 +0200 Subject: amazonaws.com? In-Reply-To: <200805271853.m4RIrenk026073@mail.r-bonomi.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> Message-ID: <483C5C1D.4090702@karnaugh.za.net> On 27/05/2008 20:53 Robert Bonomi wrote: > Because the _privilege_ to send packets to other networks has been, from > 'day one', conditional on the presumption that the sending network _is_ > a "good neighbor" to the networks receiving their traffic. You need to wake up Dorothy, this isn't Kansas anymore. Free access to the internet won long ago, it's all about defending your self. -- Colin Alston ~ http://syllogism.co.za/ "To the world you may be one person, to one person you may be the world" ~ Rachel Ann Nunes. From rblayzor.bulk at inoc.net Tue May 27 14:17:19 2008 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Tue, 27 May 2008 15:17:19 -0400 Subject: [NANOG] Fiber Cut at 60 Hudson In-Reply-To: <7E2BB500-F802-47F3-BE70-901B458DD984@bfccomputing.com> References: <8FFB0891-7F02-48F2-817D-625A147E99E8@inoc.net> <7E2BB500-F802-47F3-BE70-901B458DD984@bfccomputing.com> Message-ID: On May 27, 2008, at 2:47 PM, Bill McGonigle wrote: > I've also heard contradictory information from Level3 reps on some > of the above, so I'm not asserting any accuracy for it; so just FYI. > > Maybe they finally got to looking into your problem and unplugged > the fiber labeled 'Vermont' by accident. ;) That's about what we experienced. After about 45 hours they finally managed to bring our service back up. :-/ Our problem is that when it did come back up (assuming on the protect side of the ring) our first hop latency to Level3 was through the roof, so we decided to keep our BGP peer shutdown until things completely cleared up. Unfortunately for us I think there is a lot of "legacy" pre-Level3 network between us in Albany and 60 Hudson/111 8th in NYC... a lot of stuff that probably isn't well documented or maintained. (thus, the 40+ hour outage) -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From dhetzel at gmail.com Tue May 27 14:18:17 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Tue, 27 May 2008 15:18:17 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <28288.1211915246@turing-police.cc.vt.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> Message-ID: <2ee691ff0805271218h13f178e5o231ac9ae8ca5edd6@mail.gmail.com> Perhaps Cisco and friends should take to periodically printing MD5 checksums in full page ads in the New York Times or similar? Maybe not impossible for an attacker to replicate, but it certainly does raise the bar :) On Tue, May 27, 2008 at 3:07 PM, wrote: > On Tue, 27 May 2008 19:49:21 BST, michael.dillon at bt.com said: > > > Like MD5 File Validation? - "MD5 values are now made=20 > > > available on Cisco.com for all Cisco IOS software images for=20 > > > comparison against local system image values." > > > > I would expect a real exploit to try to match Cisco's > > MD5 hashes. > > Although there is a known attack against MD5 that will generate two > plaintexts > with the same (unpredictable) hash, there is as yet no known way > significantly > better than brute force to generate a file which hashes to a given hash. > On the > other hand, there have been multiple cases where vandals have replaced a > file > on a download site, and updated the webpage to reflect the new MD5 hash. > > If you were an attacker, which would you go with: > > 1) The brute-force attack which will require hundreds of thousands of > CPU-years. > > 2) The super-secret attack that causes a collision to a given hash that > none > of the crypto experts know about yet. > > 3) 'md5sum trojan_ios.bin' and cut-n-paste that into the web page. > > > By all means, check those hashes after you download > > them but I would suggest calculating a hash using an alternate > > algorithm for later checking. > > You missed the point - if the *FILE* you downloaded from a webpage is > suspect, > why do you trust the MD5sum that *the same webpage* says is correct? > > From sthaug at nethelp.no Tue May 27 14:19:43 2008 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 27 May 2008 21:19:43 +0200 (CEST) Subject: IPV6 network feeds In-Reply-To: <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> Message-ID: <20080527.211943.74696154.sthaug@nethelp.no> > > Verizon provides ipv6 connectivity according to their website. > > I mentioned this on another list, but if anybody has tried to actually > turn the words referred to above into service, I would be very happy > to hear about how they did it. > > > At&t most likely does as well. > > The last time I attempted to buy 7018 transit I specified that I > needed v6, and the answer was "yes, we can do that". But when it came > to placing an order, the reaction swiftly changed to "oh, no, actually > we can't". No comment on either Verizon or AT&T since we don't buy transit from them. However, we *do* buy transit from Global Crossing, and have had IPv6 (native, non tunneled) transit from them since at least 2004. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jtraylor at networkinglinux.net Tue May 27 14:21:45 2008 From: jtraylor at networkinglinux.net (Jonathan Traylor) Date: Tue, 27 May 2008 14:21:45 -0500 Subject: AT&T IPv6 Network Initialization/Assignment Contact? Message-ID: <20080527192145.GA17489@gonzo.fearandloathing.org> Heya NANOG members, I have a client with AT&T Metro DIA services who are looking to add routable IPv6 services. We need an AT&T contact who will have the knowledge and ability to coordinate IPv6 netblock assignments and delegate static routes to the IPv6 addresses assigned. As well as provide other IPv6 centric abilities. FYI: We contacted a representive found via the monthly DIA invoices, which seen us thru a few others which must not have understood the different between the (near)legacy and forthcoming technologies, because we got a empty form to fill out for IPv4 (yes, v4) addresses. Please contact me off-list unless you strongly feel it will do the rest of us some good. Thanks much! -- Jonathan Traylor jtraylor at internetpro.net From hannigan at verneglobal.com Tue May 27 14:27:16 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 27 May 2008 19:27:16 -0000 Subject: IPV6 network feeds Message-ID: You didn't say native was required and a tunnel might be ok for testing. Try Hurricane Electric's Tunnel Broker. Your favorite search engine will find it ie 'Hurricane Electric Tunnel Broker' IIRC. -M<. ----- Original Message ----- From: Mike Linsenmayer To: nanog at merit.edu Sent: Tue May 27 17:37:43 2008 Subject: IPV6 network feeds Hey all, I am looking for a IPV6 internet feed for our testing labs in Southern California, I know this is off subject but I am a little exasperated in trying to locate one. if anyone on the list knows of a provider please contact me off list. Thanks! Mike Linsenmayer Sr. Manager Labs Engineering QALABS Symantec Corporation www.symantec.com ___________________________ Office: 424.750.7560 Cell: 805.404.1813 YIM: mike_linsenmayer ___________________________ ___________________________ From goemon at anime.net Tue May 27 14:27:40 2008 From: goemon at anime.net (goemon at anime.net) Date: Tue, 27 May 2008 12:27:40 -0700 (PDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <23642.1211909741@turing-police.cc.vt.edu> Message-ID: On Tue, 27 May 2008, Sean Donelan wrote: > On Tue, 27 May 2008, goemon at anime.net wrote: >> What you want is cisco hardware that verifies firmware signatures in >> hardware. > Of course, how do you know your hardware hasn't been compromised? > http://www.usdoj.gov/opa/pr/2008/February/08_crm_150.html Are you buying directly from cisco or from resellers? If you are getting counterfeit hardware directly from cisco then I guess we have real problems. -Dan From michael.dillon at bt.com Tue May 27 14:31:32 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 May 2008 20:31:32 +0100 Subject: amazonaws.com? In-Reply-To: <200805271853.m4RIrenk026073@mail.r-bonomi.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> Message-ID: > Thinking about it, I realize that > asking _you_ (an > employee of major telephone company) is a silly question -- you have a > biased viewopoint from a government-regulated monopoly Reductio ad absurdum. Needs no other reply. > "it should be obvious to the meanest intelligence" that > the matter *must* be addressed at a point _upstream_ from the > destination network. Of course. But a more advanced intelligence will wonder why we have to have an SMTP server architecture that invites attacks. Why, by definition, do SMTP servers have to accept connections from all comers, by default? We have shown that other architectures are workable on the Internet, where communications only take place between peers who have prearranged which devices talk to which. This worked for USENET news and it works for exchanging BGP route announcements. Such peering architectures allow you to introduce hierarchy into the set of bilateral arrangements, and as everyone should know, hierarchy is essential to scaling a network. As long as we don't fix the architecture of Internet email, we are stuck with the catch-22 situation that Amazon, and all hosting providers find themsleves in. These companies really have no choice but to allow spammers to exploit their services until the spamming is detected, either proactively by the provider, or reactively by a complaint to their abuse desk. And eyeball providers really have no choice but to accept this state of affairs, because without the hosted sites, there is not a lot of incentive for eyeballs to attach to the net. Sure, Amazon could try to react more quickly to abuse reports, but if more ISPs would get behind a standard like ARF or IODEF http://mipassoc.org/arf/ http://xml.coverpages.org/iodef.html then this would be possible without huge spending on an abuse desk that spends most of its time discarding junk mail. The fact is that around 10 years ago, the Internet lost its abuse reporting system and ISPs have not yet replaced it with one that works. > It is universally recognized in the real world that 'toxic > waste' issues > must be dealt with at the _source_ point -- where that toxic waste is > produced. AND that the costs of doing so should fall on > those who produce them. And that is what we do with our retail DSL and dial customers because sending out tons of mail to port 25 is not normal in such an environment. But in a hosting environment, it is perfectly normal to send out tons of mail so it is not possible to be as proactive as you can be with consumer customers. > There is no reason that the Internet should be any different. > The polluter > is the party who *should* get hits with the majority of the > costs of handling > the toxic waste they produce, not the party simply tryng to > enjoy the 'quiet > satisfaction' of their own property. Actually, there *IS* a reason why the Internet should be "different". In the real world, if you try to enjoy the quiet satisfaction of your property without locking the doors, and someone walks in and takes your valuables, both the law, and the insurance company will consider you to be negligible. You do have an obligation to take reasonable measures to secure your property, i.e. don't leave the keys in the ignition. The Internet is no different. > History shows that such > attitudes weren't right > _for_the_world_as_a_whole_ then, and societal barriers were > put in place to > prevent such abuses from re-occuring. Prevent? I don't think so. Enron did happen not so long ago and it was not an isolated incident. > Your right to > access any part of my network exists only -if- I extend you > that privilege. > And it _is_ revokable at whim. WITHOUT any need to 'show > cause why'. Go ahead, no one will sue you for that. But if you solicit other companies to join you in painting Amazon the same color as Cyber Promotions, then I would expect them to sue you and win. In any case this will never happen because few ISPs have a customer base that would allow them to cut off Amazon, and all the other cloud computing suppliers. > I _cannot_ deal with volume-based DOS at -my- end of my > pipes; it -requires- > blocking/limiting the traffic *before* it hits the > choke-point that is my > external connectivity. This is one of the flaws in the existing email architecture because it invites anyone and everyone to hit your email server with as many messages as they desire. This invitation is what drives spammers to do what they do. > I applaud their _intentions_, and deplore their *implementation*. In what way does their implementation differ substantially from any other hosting provider? --Michael Dillon From jabley at ca.afilias.info Tue May 27 14:40:10 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Tue, 27 May 2008 19:40:10 +0000 Subject: IPV6 network feeds In-Reply-To: <20080527.211943.74696154.sthaug@nethelp.no> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> <20080527.211943.74696154.sthaug@nethelp.no> Message-ID: On 27 May 2008, at 19:19, sthaug at nethelp.no wrote: > No comment on either Verizon or AT&T since we don't buy transit from > them. However, we *do* buy transit from Global Crossing, and have had > IPv6 (native, non tunneled) transit from them since at least 2004. Similarly, we have had no problems with ordering v6 transit from NTT America, Global Crossing or Teleglobe in North America (also, Tiscali in Europe, and FLAG in Asia). In each case v6 transit was treated as a routine provisioning exercise, with no need for escalation to obscure greybeards. Joe From michael.dillon at bt.com Tue May 27 14:45:11 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 May 2008 20:45:11 +0100 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <28288.1211915246@turing-police.cc.vt.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> Message-ID: > If you were an attacker, which would you go with: > > 1) The brute-force attack which will require hundreds of > thousands of CPU-years. In this case an attacker would definitely go with this option. Since they can't change most of the IOS bytes because they contain IOS and the exploit, they would definitely run a brute force attack on the remaining bytes. Granted, the chances of success are slim, but these are people who are used to playing the odds even if they lose most of the time. > 3) 'md5sum trojan_ios.bin' and cut-n-paste that into the web page. One would hope that Cisco is taking measures to protect against that. > You missed the point - if the *FILE* you downloaded from a > webpage is suspect, why do you trust the MD5sum that *the > same webpage* says is correct? I wasn't thinking of any old web page but one that belongs to a trusted vendor and which requires some kind of authentication before you can get to the file. In any case, the whole issue ca be bypassed using CDs or using a PGP chain of trust. --Michael Dillon From sean at donelan.com Tue May 27 14:46:34 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 27 May 2008 15:46:34 -0400 (EDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <23642.1211909741@turing-police.cc.vt.edu> Message-ID: On Tue, 27 May 2008, goemon at anime.net wrote: > Are you buying directly from cisco or from resellers? If you are getting > counterfeit hardware directly from cisco then I guess we have real problems. According to the FBI presentation, which may not be a reliable source for this topic, Cisco has very few "direct" customers. Even if you think you are ordering "direct" from Cisco, e.g. www.cisco.com, the order seems to get forwarded to several primary Cisco resellers and the hardware shipped via a reseller. Even most resellers buy their Cisco products from a primary reseller or a secondary reseller, not direct from Cisco. The FBI presentation did note that a few US Cisco customers, such as some unnamed large US telcos and unnamed intelligence agencies, do order and ship directly from Cisco. From michael.dillon at bt.com Tue May 27 14:58:31 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 27 May 2008 20:58:31 +0100 Subject: IPV6 network feeds In-Reply-To: References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com><159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry><0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info><20080527.211943.74696154.sthaug@nethelp.no> Message-ID: > Similarly, we have had no problems with ordering v6 transit > from NTT America, Global Crossing or Teleglobe in North > America (also, Tiscali in Europe, and FLAG in Asia). In each > case v6 transit was treated as a routine provisioning > exercise, with no need for escalation to obscure greybeards. I've just added this list to the ARIN IPv6 wiki here: --Michael Dillon From kgasso-lists at visp.net Tue May 27 15:21:20 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Tue, 27 May 2008 13:21:20 -0700 Subject: Oregon/Washington Comcast outage Message-ID: <483C6D40.60907@visp.net> Looks like I can't reach several of Comcast's fiber/coax customers in Oregon and Washington: grps-edge-rtr-1#trace 75.145.64.XXX Type escape sequence to abort. Tracing the route to 75-145-64-XXX-Oregon.hfc.comcastbusiness.net (75.145.64.XXX) 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 4 msec 0 msec 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 0 msec 4 msec 0 msec 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 12 msec 12 msec 12 msec 4 pos10-0-2488M.cr1.SEA1.gblx.net (67.17.71.182) [AS 3549] !H * !H Our NOC has had several calls from folks using Comcast who weren't able to reach us, and we then confirmed that they had no network connectivity whatsoever... -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From vtadorsett at gmail.com Tue May 27 15:27:42 2008 From: vtadorsett at gmail.com (Andrew Dorsett) Date: Tue, 27 May 2008 16:27:42 -0400 Subject: IPV6 network feeds In-Reply-To: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> Message-ID: <30cc5c70805271327k2cf05a99l3ee4ddd3863ced7c@mail.gmail.com> On Tue, May 27, 2008 at 1:37 PM, Mike Linsenmayer wrote: > I am looking for a IPV6 internet feed for our testing labs in Southern > California, I know this is off subject but I am a little exasperated in > trying to locate one. if anyone on the list knows of a provider please > contact me off list. It seems that in North America many providers are spouting v6, but it's transit or tunneled, not native internet service. I've had native v6 internet service from NTT/Verio since 2004. Been great so far... Andrew From hannigan at verneglobal.com Tue May 27 15:30:17 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 27 May 2008 20:30:17 -0000 Subject: IPV6 network feeds Message-ID: I think HE does native as well. Likely good based on their rep. Best, Marty ----- Original Message ----- From: Andrew Dorsett To: nanog at nanog.org Sent: Tue May 27 20:27:42 2008 Subject: Re: IPV6 network feeds On Tue, May 27, 2008 at 1:37 PM, Mike Linsenmayer wrote: > I am looking for a IPV6 internet feed for our testing labs in Southern > California, I know this is off subject but I am a little exasperated in > trying to locate one. if anyone on the list knows of a provider please > contact me off list. It seems that in North America many providers are spouting v6, but it's transit or tunneled, not native internet service. I've had native v6 internet service from NTT/Verio since 2004. Been great so far... Andrew From mike.acosta at gmail.com Tue May 27 15:30:27 2008 From: mike.acosta at gmail.com (Michael Acosta) Date: Tue, 27 May 2008 13:30:27 -0700 Subject: Oregon/Washington Comcast outage In-Reply-To: <483C6D40.60907@visp.net> References: <483C6D40.60907@visp.net> Message-ID: <4d4f439c0805271330o12cfcb48x9dbf0b3884a764e2@mail.gmail.com> As a Comcast customer in the NW, I see the same thing outbound. Traceroute to some sites die in glbx, and other sites work via other transit providers. On Tue, May 27, 2008 at 1:21 PM, Kameron Gasso wrote: > Looks like I can't reach several of Comcast's fiber/coax customers in Oregon > and Washington: > > grps-edge-rtr-1#trace 75.145.64.XXX > > Type escape sequence to abort. > Tracing the route to 75-145-64-XXX-Oregon.hfc.comcastbusiness.net > (75.145.64.XXX) > > 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 4 msec 0 msec > 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 0 msec 4 msec 0 msec > 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 12 msec 12 msec 12 > msec > 4 pos10-0-2488M.cr1.SEA1.gblx.net (67.17.71.182) [AS 3549] !H * !H > > Our NOC has had several calls from folks using Comcast who weren't able to > reach us, and we then confirmed that they had no network connectivity > whatsoever... > > -- > Kameron Gasso | Senior Systems Administrator | visp.net > Direct: 541-955-6903 | Fax: 541-471-0821 > > -- Michael Acosta From ddunkin at netos.net Tue May 27 15:34:00 2008 From: ddunkin at netos.net (Darryl Dunkin) Date: Tue, 27 May 2008 13:34:00 -0700 Subject: Oregon/Washington Comcast outage References: <483C6D40.60907@visp.net> Message-ID: <56F5BC5F404CF84896C447397A1AAF2063B309@MAIL.nosi.netos.com> Here is the reverse view from one of my systems on residential Comcast in the Everett/Mill Creek area (source is 76.121.150.xxx): Tracing route to 208.74.128.9 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.254.254 2 * * * Request timed out. 3 9 ms * 9 ms ge-1-8-ur01.everett.wa.seattle.comcast.net [68.86.177.117] 4 10 ms * 18 ms te-9-1-ar01.burien.wa.seattle.comcast.net [68.86.96.177] 5 10 ms * 11 ms te-9-1-ar02.burien.wa.seattle.comcast.net [68.86.96.170] 6 11 ms 9 ms 9 ms te-8-1-ar02.seattle.wa.seattle.comcast.net [68.86.96.134] 7 11 ms 11 ms 12 ms te-9-1-ar02.seattle.wa.seattle.comcast.net [68.86.90.210] 8 11 ms 11 ms 12 ms COMCAST-IP-SERVICES.TenGigabitethernet1-4.ar5.SEA1.gblx.net [64.209.111.94] 9 10 ms 11 ms 11 ms TenGigabitethernet1-4.ar5.SEA1.gblx.net [64.209.111.93] 10 38 ms 38 ms 39 ms Prime-Time-Ventures.so-2-1-0.ar2.SEA1.gblx.net [64.212.109.182] 11 39 ms 40 ms 38 ms 208.74.128.9 -----Original Message----- From: Kameron Gasso [mailto:kgasso-lists at visp.net] Sent: Tuesday, May 27, 2008 13:21 To: nanog at merit.edu; outages at isotf.org Subject: Oregon/Washington Comcast outage Looks like I can't reach several of Comcast's fiber/coax customers in Oregon and Washington: grps-edge-rtr-1#trace 75.145.64.XXX Type escape sequence to abort. Tracing the route to 75-145-64-XXX-Oregon.hfc.comcastbusiness.net (75.145.64.XXX) 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 4 msec 0 msec 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 0 msec 4 msec 0 msec 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 12 msec 12 msec 12 msec 4 pos10-0-2488M.cr1.SEA1.gblx.net (67.17.71.182) [AS 3549] !H * !H Our NOC has had several calls from folks using Comcast who weren't able to reach us, and we then confirmed that they had no network connectivity whatsoever... -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From Valdis.Kletnieks at vt.edu Tue May 27 15:43:11 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 May 2008 16:43:11 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: Your message of "Tue, 27 May 2008 20:45:11 BST." References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> Message-ID: <32648.1211920991@turing-police.cc.vt.edu> On Tue, 27 May 2008 20:45:11 BST, michael.dillon at bt.com said: > > 1) The brute-force attack which will require hundreds of > > thousands of CPU-years. Millions. Not thousands. See below. > In this case an attacker would definitely go with this option. Since > they can't change most of the IOS bytes because they contain IOS and > the exploit, they would definitely run a brute force attack on the > remaining bytes. Granted, the chances of success are slim, but these > are people who are used to playing the odds even if they lose most > of the time. I think you're thinking of the known collision attack against MD5, where you start off with two plaintexts of your choice, and by suitable manipulation of a smallish (on the order of 256 bytes) section of each, you can get the two files to have the same MD5sum. Unfortunately, you have zero control over what the output MD5sum is. There's a known method for doing this that will do it in about 8 hours on a 1.6Ghz computer: http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf In contrast, a "pre-image" attack (finding a plaintext that will hash to a given MD5 hash) is still a bunch of work - this 2004 paper by Kelsey and Schneier (http://eprint.iacr.org/2004/304.pdf) shows how to, for a 128-bit hash and (for instance) a 1 gigabyte file, to compute a second-preimage attack in (roughly) 2**105 rather than the expected 2**128 (n=128 and k=24, for those of you playing along at home). So let's see - if you had a billion CPUs in your botnet, and each one could go at a billion to the second, you still need 2**69 seconds or 449,235,776,528,695 years. Not bad - only 10,000 times the amount of time this planet has been around, so yeah, that's the way they'll attack all right. (If somebody knows a *better* pre-image attack, please fill me in. I know there's a few other crypto-heads out there...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ge at linuxbox.org Tue May 27 16:06:54 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 27 May 2008 16:06:54 -0500 (CDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <21778.1211907437@turing-police.cc.vt.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> Message-ID: On Tue, 27 May 2008 Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 May 2008 11:02:32 CDT, Gadi Evron said: >> On Tue, 27 May 2008, Jared Mauch wrote: >>> *yawn* >> >> I guess we will wait for the next one before waking up, than. > > No Gadi. What Jared is saying is that there are exactly *ZERO* routers > (for some infinitesimally small value of zero) that will get rootkitted > that weren't *already* vulnerable to the stuff that Lynn talked about > three years ago. > > There's basically 2 classes of Cisco routers out there: > > 1) Ones managed by Jared and similarly clued people, who can quite rightfully > yawn because the specter of "IOS rootkits" changes nothing in their actual > threat model - they put stuff in place 3 years ago to mitigate "Lynn-style IOS > pwnage", and it will stop this just as well. Move along, nothing to see. > > 2) Ones managed by unclued people. And quite frankly, if Lynn didn't wake > them up 3 years ago, this isn't going to wake them up either. Move along, > nothing new to see here either. > > "60% of routers run by bozos who shouldn't have enable. Film at 11". > > *yawn*. > My bad. Sorry Jared. From ge at linuxbox.org Tue May 27 16:09:16 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 27 May 2008 16:09:16 -0500 (CDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: On Tue, 27 May 2008, Sean Donelan wrote: > On Tue, 27 May 2008, Gadi Evron wrote: >>> Perhaps the above should be simplified. >>> >>> Running a hacked/modded IOS version is a dangerous prospect. >>> >>> This seems like such a non-event because what is the exploit path to load >>> the image? There needs to be a primary exploit to load the malware image. >>> >>> *yawn* >> >> I guess we will wait for the next one before waking up, than. > > If you let people load unauthorized images on your equipment, you > probably have bigger problems than potential rootkits. It may be a better > use of resources to prevent people from installing unauthorized images on > your hardware versus debating all the things an unauthorized image could do > after it is installed. > > Other things you could install rootkits on, if you can load > unauthorized images on the device: > > Anything with a CPU and loadable images. > > Even old fashion printing presses are vulnerable to the old fashion > version of a rootkit. If you could replace the printing press plates > with unauthorized plates, you could change what the printing press > printed. Modifying printing plates is the easy part, getting the > unauthorized printing plates on the printing press is the trick. Sean, you are right. My point is that these things exist and we should not limit our assessment to what's available in presentations, which is the current rootkit. The next one and the ones after that is what matters. Gadi. From keith_mitchell at isc.org Tue May 27 16:10:08 2008 From: keith_mitchell at isc.org (Keith Mitchell) Date: Tue, 27 May 2008 17:10:08 -0400 Subject: REMINDER: DNS Operations Meeting, Brooklyn NY 4/5th June In-Reply-To: <482B0166.6050604@isc.org> References: <47FD0BF9.7020306@isc.org> <482B0166.6050604@isc.org> Message-ID: <483C78B0.6010903@isc.org> This is a reminder that the OARC DNS Operations meeting takes place next Wed 4th PM and Thu 5th AM in Brooklyn NY, USA, immediately after NANOG43. The meeting will be held in Brooklyn College, NY, about 5 miles from the NANOG venue, and is open to all. Meeting information is at: http://public.oarci.net/dns-operations/workshop-2008/ including an agenda for the DNS Operations Meeting now available at: http://public.oarci.net/dns-operations/workshop-2008/agenda If you are planning to attend, please can I ask you to register ASAP at: https://oarc.isc.org/register.php We still have plenty of space available for NANOG attendees as well as OARC members, but need to finalize numbers very soon. Registration is free, and I'd like to thank our sponsor VeriSign for covering meeting costs and making this possible. There is still space for additional presentations, if you have or know of material relevant to DNS Operator or Researchers to present, it would be very welcome. Please let me know ASAP, or feel free to discuss with me at NANOG. Keith Mitchell OARC Programme Manager From ge at linuxbox.org Tue May 27 16:12:31 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 27 May 2008 16:12:31 -0500 (CDT) Subject: IOS Rookit: running hacked binaries certainly places you at risk! In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> Message-ID: On Tue, 27 May 2008, Jared Mauch wrote: > > On May 27, 2008, at 12:02 PM, Gadi Evron wrote: > >> On Tue, 27 May 2008, Jared Mauch wrote: >>> >>> On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote: >>> >>>>> An alternative rootkit ? Privilege level 16 used by the Lawful Intercept >>>>> [12] feature could be abused to do some of this too. Or the other way >>>>> around: use a "patched" IOS to keep an eye on Law Enforcement's >>>>> >operations >>>> on the router as privilege level 15 doesn't allow it and the only >>>>> alternative is to sniff the traffic export. >>>> The combination of rootkits and specially privileged Lawful Intercept >>>> functions is a very dangerous one. This was precisely what was exploited >>>> in >>>> the now-legendary and still unsolved Vodafone Greece hack. >>> >>> Perhaps the above should be simplified. >>> >>> Running a hacked/modded IOS version is a dangerous prospect. >>> >>> This seems like such a non-event because what is the exploit path to load >>> the image? There needs to be a primary exploit to load the malware image. >>> >>> *yawn* >> >> I guess we will wait for the next one before waking up, than. > > > You seem to be missing the point and I'm concerned that wasting my time > attempting to educate you and others on this topic is fruitless, but I will > attempt the impossible. > > Surely you should insure your devices are secured and audit their security. > Attack vectors change over time. This case is easily mitigated against if > Cisco shipped signed binaries and the platform performed this validation. > That's not something unique, but something that is unavailable today. Then you'd use the memory or manipulate the validation. It's a cat and mouse game the same as any other. I disagree with you there, although these are certainly good steps for Cisco to take. > I state again: Running any random code will certainly put you at risk, this > continues to be the case for routers in the same way as it is for the > millions of infected PCs. > > I await information on the remote router exploit path and the mitigation > strategy you allude to in your above bait. Without compromising the router > in the first place, either physically by swapping the image media (hard > drive, flash of varying varieties) or remotely with some unnamed and perhaps > unfound 0-day exploit, the strategy outlined in this thread is not a viable > one. I allude to nothing, Jared. > Anyone following a set of "sane" practices, (watching those flash/disk > inserted/removed messages in your syslogs and doing image validation will > help mitigate the risk). There's alternate cases that have not been outlined > here that could prove to be more problematic and cause you to do some > incident response but I will not outline those in this public forum. Thanks for clarifying these points. I am concerned about how far current methods can take an operator trying to detect badness. Gadi. From sean at donelan.com Tue May 27 16:18:05 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 27 May 2008 17:18:05 -0400 (EDT) Subject: Hurricane season starts June 1: Carriers harden networks Message-ID: [...] The most common threat to communications during a severe storm is not destruction of physical infrastructure but loss of power. Individual cell sites tend to survive high winds and flooding, Walsh said. "That is a testament to the site planning" for the towers, she said. "That's why we focus on backup power." [...] "Our expectation is that backup will last long enough to get power back up," Walsh said. "Most outages are of a relatively short duration." But there are times when outages can outlast generators' reserve batteries or fuel supplies, and service then depends on getting more fuel into the stricken areas. If roads are not passable, service could be lost during an extended outage. The official spokespeople don't mention it, but there is also a tendency for local officials to divert fuel delivery trucks for their use instead of maintaining communication facilities. From deepak at ai.net Tue May 27 17:05:05 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 27 May 2008 18:05:05 -0400 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: References: Message-ID: <483C8591.3060105@ai.net> > > The official spokespeople don't mention it, but there is also a tendency > for local officials to divert fuel delivery trucks for their use instead > of maintaining communication facilities. > Perhaps a company will get in the business of labeling trucks that normally say fuel to something like "spoiled milk" during such events and specialize in refueling certain customers. ;) I *think* I'm kidding. Deepak From oberman at es.net Tue May 27 17:10:29 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 27 May 2008 15:10:29 -0700 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: Your message of "Tue, 27 May 2008 15:46:34 EDT." Message-ID: <20080527221029.D01FD4500F@ptavv.es.net> > Date: Tue, 27 May 2008 15:46:34 -0400 (EDT) > From: Sean Donelan > > On Tue, 27 May 2008, goemon at anime.net wrote: > > Are you buying directly from cisco or from resellers? If you are getting > > counterfeit hardware directly from cisco then I guess we have real problems. > > According to the FBI presentation, which may not be a reliable source > for this topic, Cisco has very few "direct" customers. > > Even if you think you are ordering "direct" from Cisco, e.g. > www.cisco.com, the order seems to get forwarded to several primary Cisco > resellers and the hardware shipped via a reseller. Even most resellers > buy their Cisco products from a primary reseller or a secondary reseller, > not direct from Cisco. > > The FBI presentation did note that a few US Cisco customers, such as some > unnamed large US telcos and unnamed intelligence agencies, do order and > ship directly from Cisco. > A lot of folks order from a reseller and Cisco ships directly. This is true for many section 8a resellers when selling to organizations under those purchasing mandates...anyone spending federal $$$. I suspect some states have similar requirements. (Section 8a gives preference to small, minority owned, and disadvantaged businesses.) In any case, the reseller never sees this equipment. I am unclear on how common this is in the non-8a part of the world, but I suspect a lot of folks get their stuff direct from Cisco (or Juniper, for that matter), even though they buy from a reseller, if they are buying bigger boxes that small resellers are unlikely to stock. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From ml at t-b-o-h.net Tue May 27 17:09:38 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 27 May 2008 18:09:38 -0400 (EDT) Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <483C8591.3060105@ai.net> Message-ID: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> > > > > > > The official spokespeople don't mention it, but there is also a tendency > > for local officials to divert fuel delivery trucks for their use instead > > of maintaining communication facilities. > > > > Perhaps a company will get in the business of labeling trucks that > normally say fuel to something like "spoiled milk" during such events > and specialize in refueling certain customers. ;) > > I *think* I'm kidding. > After we went down at Telehouse 25 Broadway during 9/11 because the National Guard halted one of the deliveries... I'm open to just about any suggestions incase of another incident. Maybe "Firefighting Foam Refill Truck" would be better. Or just "HAZMAT CLEANUP". Tuc/TBOH From jeroen at unfix.org Tue May 27 17:16:37 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 28 May 2008 00:16:37 +0200 Subject: IPV6 network feeds In-Reply-To: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> Message-ID: <483C8845.8060206@spaghetti.zurich.ibm.com> Mike Linsenmayer wrote: > Hey all, > > > > I am looking for a IPV6 internet feed for our testing labs in Southern > California, I know this is off subject but I am a little exasperated in > trying to locate one. if anyone on the list knows of a provider please > contact me off list. My queue to spam: = Where can I get native IPv6 / Which ISP's provide IPv6? http://www.sixxs.net/faq/connectivity/?faq=native and: = Where can I get native IPv6 transit? http://www.sixxs.net/faq/connectivity/?faq=ipv6transit and of course: = GRH http://www.sixxs.net/tools/grh/ so that you can see who is at least announcing a prefix into BGP. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Tue May 27 17:35:10 2008 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 May 2008 18:35:10 -0400 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> References: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <5A42EFBD-2B22-4CD8-9952-A5E317FB34F4@puck.nether.net> On May 27, 2008, at 6:09 PM, Tuc at T-B-O-H.NET wrote: >> >> >>> >>> The official spokespeople don't mention it, but there is also a >>> tendency >>> for local officials to divert fuel delivery trucks for their use >>> instead >>> of maintaining communication facilities. >>> >> >> Perhaps a company will get in the business of labeling trucks that >> normally say fuel to something like "spoiled milk" during such events >> and specialize in refueling certain customers. ;) >> >> I *think* I'm kidding. >> > After we went down at Telehouse 25 Broadway during 9/11 because the > National Guard halted one of the deliveries... I'm open to just > about any > suggestions incase of another incident. Maybe "Firefighting Foam > Refill > Truck" would be better. Or just "HAZMAT CLEANUP". You need to make sure you know how to get the DOT waivers (in advance) for fuel deliveries and other deliveries. Knowing which FEMA region you are in and where the JFO and how to properly coordinate with them may help avoid these types of problems. It may take some time to sort through the issues, but it may help to review the NRF, and know what the government means when they say NOC or NICC. http://www.fema.gov/pdf/emergency/nims/jfo_sop.pdf May be a good place to read up on things, as well as what your role may be under ESF #2 or other NS/EP roles. It's not exactly the most enjoyable reading in the world, but it may provide some insight into what is going on. From jerry at jdixon.com Tue May 27 17:47:12 2008 From: jerry at jdixon.com (Jerry Dixon) Date: Tue, 27 May 2008 18:47:12 -0400 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <5A42EFBD-2B22-4CD8-9952-A5E317FB34F4@puck.nether.net> References: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> <5A42EFBD-2B22-4CD8-9952-A5E317FB34F4@puck.nether.net> Message-ID: <000001c8c04b$9accc390$d0664ab0$@com> Jared nailed it on the head. It is absolutely critical to get to know who your State JFO POC is, State EOC POC, and have the National Communication Systems Hotline on speed dial or at least in your cell. They can help facilitate needs such as getting human resources from your company or mutual aide in to help with a crisis (credentialing issues), fuel trucks, and other supplies as needed. Also you might want to check to see if your company has a govt. affairs person within your organization who might all ready have a lot of this info and the contacts to assist. Based on experience, they've also been extremely helpful to have those POC's on speed dial in case your company needs to get flight clearance to survey damage if you have an extensive amount of lines in an affected area. If you have the opportunity to participate in preparedness exercise with DHS I'd highly recommend it as you'll develop some of those essential relationships plus get plugged into your local Infragard folks too. You can never have enough paths for getting assistance when you needed it. Jerry jerry at jdixon.com -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Tuesday, May 27, 2008 6:35 PM To: Tuc at T-B-O-H.NET Cc: nanog at nanog.org Subject: Re: Hurricane season starts June 1: Carriers harden networks On May 27, 2008, at 6:09 PM, Tuc at T-B-O-H.NET wrote: >> >> >>> >>> The official spokespeople don't mention it, but there is also a >>> tendency >>> for local officials to divert fuel delivery trucks for their use >>> instead >>> of maintaining communication facilities. >>> >> >> Perhaps a company will get in the business of labeling trucks that >> normally say fuel to something like "spoiled milk" during such events >> and specialize in refueling certain customers. ;) >> >> I *think* I'm kidding. >> > After we went down at Telehouse 25 Broadway during 9/11 because the > National Guard halted one of the deliveries... I'm open to just > about any > suggestions incase of another incident. Maybe "Firefighting Foam > Refill > Truck" would be better. Or just "HAZMAT CLEANUP". You need to make sure you know how to get the DOT waivers (in advance) for fuel deliveries and other deliveries. Knowing which FEMA region you are in and where the JFO and how to properly coordinate with them may help avoid these types of problems. It may take some time to sort through the issues, but it may help to review the NRF, and know what the government means when they say NOC or NICC. http://www.fema.gov/pdf/emergency/nims/jfo_sop.pdf May be a good place to read up on things, as well as what your role may be under ESF #2 or other NS/EP roles. It's not exactly the most enjoyable reading in the world, but it may provide some insight into what is going on. From jared at puck.nether.net Tue May 27 17:58:47 2008 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 May 2008 18:58:47 -0400 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <000001c8c04b$9accc390$d0664ab0$@com> References: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> <5A42EFBD-2B22-4CD8-9952-A5E317FB34F4@puck.nether.net> <000001c8c04b$9accc390$d0664ab0$@com> Message-ID: <91025932-899A-45C0-8211-79DEC46E2FDA@puck.nether.net> On May 27, 2008, at 6:47 PM, Jerry Dixon wrote: > Jared nailed it on the head. It is absolutely critical to get to > know who > your State JFO POC is, State EOC POC, and have the National > Communication > Systems Hotline on speed dial or at least in your cell. They can help > facilitate needs such as getting human resources from your company > or mutual > aide in to help with a crisis (credentialing issues), fuel trucks, > and other > supplies as needed. > > Also you might want to check to see if your company has a govt. > affairs > person within your organization who might all ready have a lot of > this info > and the contacts to assist. I think there's something else to make note of. NCS wants to make sure that a number of the ISPs and critical infrastructure operators have WPS/GETS available to the people who rightly need them. If you're not sure, give them a ring and chat with them about what resources you should have at your disposal. If there is a major communication disruption, this may help your operations team communicate. You can fill out the forms online at gets.ncs.gov - Jared From kgasso-lists at visp.net Tue May 27 17:56:13 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Tue, 27 May 2008 15:56:13 -0700 Subject: [Outages] Oregon/Washington Comcast outage In-Reply-To: <4d4f439c0805271330o12cfcb48x9dbf0b3884a764e2@mail.gmail.com> References: <483C6D40.60907@visp.net> <4d4f439c0805271330o12cfcb48x9dbf0b3884a764e2@mail.gmail.com> Message-ID: <483C918D.3020507@visp.net> Michael Acosta wrote: > As a Comcast customer in the NW, I see the same thing outbound. > Traceroute to some sites die in glbx, and other sites work via other > transit providers. Looks like whatever the SNAFU between Comcast and GLBX was, it's been resolved for some time now... :) Cheers, -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 > On Tue, May 27, 2008 at 1:21 PM, Kameron Gasso wrote: >> Looks like I can't reach several of Comcast's fiber/coax customers in Oregon >> and Washington: >> >> grps-edge-rtr-1#trace 75.145.64.XXX >> >> Type escape sequence to abort. >> Tracing the route to 75-145-64-XXX-Oregon.hfc.comcastbusiness.net >> (75.145.64.XXX) >> >> 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 4 msec 0 msec >> 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 0 msec 4 msec 0 msec >> 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 12 msec 12 msec 12 >> msec >> 4 pos10-0-2488M.cr1.SEA1.gblx.net (67.17.71.182) [AS 3549] !H * !H >> >> Our NOC has had several calls from folks using Comcast who weren't able to >> reach us, and we then confirmed that they had no network connectivity >> whatsoever... >> >> -- >> Kameron Gasso | Senior Systems Administrator | visp.net >> Direct: 541-955-6903 | Fax: 541-471-0821 >> >> > > > From orion at pirk.com Tue May 27 18:50:14 2008 From: orion at pirk.com (Steve Pirk) Date: Tue, 27 May 2008 16:50:14 -0700 (PDT) Subject: Oregon/Washington Comcast outage In-Reply-To: <56F5BC5F404CF84896C447397A1AAF2063B309@MAIL.nosi.netos.com> References: <483C6D40.60907@visp.net> <56F5BC5F404CF84896C447397A1AAF2063B309@MAIL.nosi.netos.com> Message-ID: I have a Comcast business line, and have bbeen up all day. Here is my trace to the same IP (from Bremerton WA): orion at orion:~/tmp$ traceroute 208.74.128.9 traceroute to 208.74.128.9 (208.74.128.9), 30 hops max, 38 byte packets 1 73.96.188.1 (73.96.188.1) 8.051 ms 11.888 ms 6.731 ms 2 GE-2-35-ur01.bremerton.wa.seattle.comcast.net (68.86.98.81) 8.541 ms 7.219 ms * 3 te-7-3-ar01.burien.wa.seattle.comcast.net (68.86.96.46) 13.948 ms 8.413 ms * 4 * * te-9-1-ar02.burien.wa.seattle.comcast.net (68.86.96.170) 9.484 ms 5 te-7-4-ar02.seattle.wa.seattle.comcast.net (68.86.96.198) 9.429 ms 10.701 ms 10.251 ms 6 te-9-1-ar02.seattle.wa.seattle.comcast.net (68.86.90.210) 13.720 ms 11.470 ms 10.241 ms 7 * * * 8 TenGigabitethernet1-4.ar5.SEA1.gblx.net (64.209.111.93) 13.467 ms 12.165 ms 10.647 ms 9 Prime-Time-Ventures.so-2-1-0.ar2.SEA1.gblx.net (64.212.109.182) 36.033 ms 40.281 ms 36.884 ms 10 gp-edge-04.visp.net (69.9.134.66) 44.607 ms * 39.161 ms -- Steve Equal bytes for women. On Tue, 27 May 2008, Darryl Dunkin wrote: > Here is the reverse view from one of my systems on residential Comcast > in the Everett/Mill Creek area (source is 76.121.150.xxx): > Tracing route to 208.74.128.9 over a maximum of 30 hops > > 1 <1 ms <1 ms <1 ms 192.168.254.254 > 2 * * * Request timed out. > 3 9 ms * 9 ms > ge-1-8-ur01.everett.wa.seattle.comcast.net [68.86.177.117] > 4 10 ms * 18 ms > te-9-1-ar01.burien.wa.seattle.comcast.net [68.86.96.177] > 5 10 ms * 11 ms > te-9-1-ar02.burien.wa.seattle.comcast.net [68.86.96.170] > 6 11 ms 9 ms 9 ms > te-8-1-ar02.seattle.wa.seattle.comcast.net [68.86.96.134] > 7 11 ms 11 ms 12 ms > te-9-1-ar02.seattle.wa.seattle.comcast.net [68.86.90.210] > 8 11 ms 11 ms 12 ms > COMCAST-IP-SERVICES.TenGigabitethernet1-4.ar5.SEA1.gblx.net > [64.209.111.94] > 9 10 ms 11 ms 11 ms TenGigabitethernet1-4.ar5.SEA1.gblx.net > [64.209.111.93] > 10 38 ms 38 ms 39 ms > Prime-Time-Ventures.so-2-1-0.ar2.SEA1.gblx.net [64.212.109.182] > 11 39 ms 40 ms 38 ms 208.74.128.9 > > -----Original Message----- > From: Kameron Gasso [mailto:kgasso-lists at visp.net] > Sent: Tuesday, May 27, 2008 13:21 > To: nanog at merit.edu; outages at isotf.org > Subject: Oregon/Washington Comcast outage > > Looks like I can't reach several of Comcast's fiber/coax customers in > Oregon and Washington: > > grps-edge-rtr-1#trace 75.145.64.XXX > > Type escape sequence to abort. > Tracing the route to 75-145-64-XXX-Oregon.hfc.comcastbusiness.net > (75.145.64.XXX) > > 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 4 msec 0 msec > 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 0 msec 4 msec 0 > msec > 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 12 msec 12 > msec 12 msec > 4 pos10-0-2488M.cr1.SEA1.gblx.net (67.17.71.182) [AS 3549] !H * !H > > Our NOC has had several calls from folks using Comcast who weren't able > to reach us, and we then confirmed that they had no network connectivity > > whatsoever... > > -- > Kameron Gasso | Senior Systems Administrator | visp.net > Direct: 541-955-6903 | Fax: 541-471-0821 > > From ml at t-b-o-h.net Tue May 27 20:42:51 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 27 May 2008 21:42:51 -0400 (EDT) Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <91025932-899A-45C0-8211-79DEC46E2FDA@puck.nether.net> Message-ID: <200805280142.m4S1gpwB074479@himinbjorg.tucs-beachin-obx-house.com> > > > On May 27, 2008, at 6:47 PM, Jerry Dixon wrote: > > > Jared nailed it on the head. It is absolutely critical to get to > > know who > > your State JFO POC is, State EOC POC, and have the National > > Communication > > Systems Hotline on speed dial or at least in your cell. They can help > > facilitate needs such as getting human resources from your company > > or mutual > > aide in to help with a crisis (credentialing issues), fuel trucks, > > and other > > supplies as needed. > > > > Also you might want to check to see if your company has a govt. > > affairs > > person within your organization who might all ready have a lot of > > this info > > and the contacts to assist. > > > I think there's something else to make note of. > > NCS wants to make sure that a number of the ISPs and critical > infrastructure operators have WPS/GETS available to the people who > rightly need them. If you're not sure, give them a ring and chat with > them about what resources you should have at your disposal. If there > is a major communication disruption, this may help your operations > team communicate. > > You can fill out the forms online at gets.ncs.gov > > - Jared > Thanks to everyone for their suggestions. Its alot of information. Unfortunately, next time something like that happens.... I'm getting out of there. It won't be my company, so I'm gonna get outta there. Living at Ground Zero (1 BUILDING away before, a few blocks inside during as well as after) was just plain stupid. No more Port Authority or Japanese pieces of paper saying I was "Critical" to be down there and could come/go as I please. No, I wouldn't be wheezing pretty bad this week if I was smart and did get out. Yea, next time...... I'm SO outta there. :) Hopefully someone else read all this and did the right things. Tuc From todd at renesys.com Tue May 27 20:27:55 2008 From: todd at renesys.com (Todd Underwood) Date: Wed, 28 May 2008 01:27:55 +0000 Subject: [NANOG-announce] Program Committee Nominations Message-ID: <20080528012755.GB15880@renesys.com> Attached are all of the the current nominations to the nanog program committee. comments in support (or opposition) to any candidate can be made to the nanog steering committee steering at nanog.org. (if you submitted a nomination and you do not see it here, please notify me immediately, resend it and we'll get it added). thanks, todd underwood chair, nanog program committee Nominated by David Conrad - Nominee's name (if not you) - Nominee's email address: drc at virtualized.org - Reason why: I was the co-founder and original program chair committee for APRICOT for 3 years, been loosely involved with APRICOT since then. Been doing various jobs in network infrastructure since around 1983. I'm fairly well versed in network operations, at least from a non-router jockey point of view. Due to a change in my job responsibilities, I have a bit of time that could be supported by my company (ICANN) to do this sort of thing. Nominated by Aaron Hughes - Nominees name: Randy Epstein - Nominees email: repstein at chello.at - Reason why: For starters, take a look at his linkedin profile: http://www.linkedin.com/profile?viewProfile=&key=11803139 He has a hell of a lot of industry experience, a great personality, is well known in the community and respected for his decisions. I believe Randy would make a fantastic addition to the PC. Nominated by Michael K. Smith - Nominee's name (if not you) - Nominee's email address: mksmith at adhost.com - Reason why: Strong desire to see NANOG continue to be relevant to the largest group of people possible through a diverse and dynamic program offering. - I have a keen sense of irony - I have a thick skin - I've been attending NANOG since 1998 - I have a diverse networking background that includes at least one thing at each of the OSI Extended Layers through 12. - I would really enjoy giving back to a community that has given me a lot over the years (seriously). Nominated by jared mauch - Nominees name: Mike Long - Nominees email: Moong at us.ntt.net - Reason why: Mike is our top operations guy for our backbone and would be an asset in providing critical reviews of presentations. I hope he accepts this nomination! Nominated by John G. Scudder - Nominee's name: Ron Bonica - Nominee's email: rbonica at juniper.net - Reasons why: Ron has a long history with Internet operations, first as an operator (Internet MCI, VBNS) and now as IETF Operations Area co-director. I think this would be a good opportunity to improve communications between the operations community and the IETF. Also, Ron is very easy to get along with! - Nominater Kevin Epperson - Nominate Brian Deardorff - Brian.Deardorff at Level3.com - 720-888-1227 - Brian has extensive experience working for ISPs going back to 1995 racking and stacking Portmasters. He is currently a senior engineer at Level 3 working on multiple products and technologies in the layer 2/3/4 space. He would be a great addition to the program committee bringing both techinical expertise and outstanding industry knowledge from an ISP point of view. Please consider this nomination for Brian to the NANOG PC. Please contact me if you have any questions. - Your name: Richard Steenbergen - Nominee's name (if not you): Tom Scholl - Nominee's email address: tscholl at gmail.com - Reasons why you believe the nominee is qualified to serve on the Program Committee. Tom is very experienced in the operation of large scale networks, and a frequent contributor to the NANOG program. His many years of experience at SBC/AT&T would be an excellent replacement to the value Ted Seely brought to the Program Committee with his experience from Sprint. - Nominee's name (if not you) - Celeste Anderson - Nominee's email address - celestea at usc.edu - Reasons why you believe the nominee is qualified to serve on the Program Committee quoting bill woodcock: "Celeste has been at the center of the Southern-California academic networking scene for, I believe, twenty years. Which is about as long as there's been an Internet that counts. She ran the Los Angeles IXP since it was established in 1994/1995, and grew it very well, way beyond how it could have grown if it had been done solely as an academic project. She included all kinds of commercial and governmental folks, roped in One Wilshire, etc. Very active in getting everybody there to peer, regardless of many of them not having much of any language in common, since LA is such a big hub for Asian traffic. At the same time that she was doing all the outward-facing IXP stuff, she was also equally active in Los Nettos, the SoCal R&E network. Lots of contacts within the research community, the peering community, the network ops community, and the R&E-specific-networking community." -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From phil at mindfury.net Tue May 27 23:08:19 2008 From: phil at mindfury.net (Philip L.) Date: Wed, 28 May 2008 00:08:19 -0400 Subject: AT&T BGP blackholing Message-ID: <483CDAB3.3040301@mindfury.net> Does anyone have information or a contact at AT&T with regards to setting up BGP blackholing with them? I see that the question has been asked in the past but there was no definitive answer, at least none that I could find. --Philip L. From brian at meganet.net Tue May 27 23:35:19 2008 From: brian at meganet.net (Brian Wallingford) Date: Wed, 28 May 2008 00:35:19 -0400 (EDT) Subject: AT&T BGP blackholing In-Reply-To: <483CDAB3.3040301@mindfury.net> References: <483CDAB3.3040301@mindfury.net> Message-ID: If you're a direct customer, use your MIS contact. We've used them for nearly 8 years, and I've been consistently impressed. If not, your upstream should be your first point of contact. For maintenance (e.g., prefix-list mods) they tend to take their time unless you insist on expedition; but, for performance-impacting issues, they're quite responsive. cheers, brian On Wed, 28 May 2008, Philip L. wrote: :Does anyone have information or a contact at AT&T with regards to :setting up BGP blackholing with them? I see that the question has been :asked in the past but there was no definitive answer, at least none that :I could find. : :--Philip L. : : : : -- ___________________________________ Brian Wallingford Director, Network Operations MegaNet Communications, TCIX, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From blackham at gmail.com Wed May 28 01:53:59 2008 From: blackham at gmail.com (Kevin Blackham) Date: Wed, 28 May 2008 00:53:59 -0600 Subject: AT&T BGP blackholing In-Reply-To: <483CDAB3.3040301@mindfury.net> References: <483CDAB3.3040301@mindfury.net> Message-ID: As a former customer of 7018, I was unable to get anyone with enough clue who understood BGP triggered blackholing. Retries and debates with regular MIS contacts lead to nothing. Perhaps a better contact is available, but I had no luck. On 5/27/08, Philip L. wrote: > Does anyone have information or a contact at AT&T with regards to > setting up BGP blackholing with them? I see that the question has been > asked in the past but there was no definitive answer, at least none that > I could find. > > --Philip L. > > > > From pauldotwall at gmail.com Wed May 28 03:59:05 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 28 May 2008 04:59:05 -0400 Subject: AT&T BGP blackholing In-Reply-To: <483CDAB3.3040301@mindfury.net> References: <483CDAB3.3040301@mindfury.net> Message-ID: <620fd17c0805280159ic63dceay68776bf9caeb8da8@mail.gmail.com> On Wed, May 28, 2008 at 12:08 AM, Philip L. wrote: > Does anyone have information or a contact at AT&T with regards to setting up > BGP blackholing with them? I see that the question has been asked in the > past but there was no definitive answer, at least none that I could find. Good luck. The problem is the MIS product managers would rather sell you their DoS Clean Pipe solution rather than accept a prefix via a BGP session with a unique community. Their DoS Clean Pipe redirects your impacted networks into their scrubber (Cisco Riverheads) then back towards your network. What I find funny is that on the list of AT&T achievements of the past 100 years, the DoS Clean Pipe is listed in the 2000s while transistor is listed for the 1940s. Whats next for 2008, claiming the Apple iPhone or Cisco Telepresence as an AT&T achievement? Didn't know resetting BGP next-hops was up there next to the transistor. Mr. Wallingford says you should call up your MIS contact, but why should you call up when most other networks let you black hole with an existing or separate BGP session? Sounds like AT&T MIS needs to get with the times and stop catering only to the enterprise T1's. Paul Wall Drive slow...like Brucie. From michael.dillon at bt.com Wed May 28 04:37:05 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 May 2008 10:37:05 +0100 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <32648.1211920991@turing-police.cc.vt.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> <32648.1211920991@turing-police.cc.vt.edu> Message-ID: > So let's see - if you had a billion CPUs in your botnet, and > each one could go at a billion to the second, you still need > 2**69 seconds or 449,235,776,528,695 years. Not bad - only > 10,000 times the amount of time this planet has been around, > so yeah, that's the way they'll attack all right. I didn't say that. I said that they are starting with an IOS image in which there are some small number of bytes which they can possibly change and still have a functional image. So it is likely that they will brute force that by computing an MD5 hash on all variations of those few bytes. It's like winning the lottery, you only *NEED* to buy one ticket. No matter how slim the chances are of bad guys winning that lottery, it is no excuse for ignoring the possibility that an MD5 hash check may not be proof that you have an original image. And lets not get into all the other possibilities such as an insider who corrupts your database in which you safely store the MD5 hashes. There is no magic bullet, only various security layers which reduce the odds of an exploit in your network in a similar way to how multiple routers and multiple paths can increase your network's uptime to very nearly 100%. --Michael Dillon From michael.dillon at bt.com Wed May 28 04:58:09 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 May 2008 10:58:09 +0100 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: References: Message-ID: > The official spokespeople don't mention it, but there is also > a tendency for local officials to divert fuel delivery trucks > for their use instead of maintaining communication facilities. How much fuel can you legally carry in drums inside the trucks that your company already has with your logo on it? Is it logistically feasible to resupply your sites using such vehicles? --Michael Dillon From dot at dotat.at Wed May 28 05:59:39 2008 From: dot at dotat.at (Tony Finch) Date: Wed, 28 May 2008 11:59:39 +0100 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> Message-ID: On Tue, 27 May 2008, michael.dillon at bt.com wrote: > > But a more advanced intelligence will wonder why we have to have an SMTP > server architecture that invites attacks. Why, by definition, do SMTP > servers have to accept connections from all comers, by default? We have > shown that other architectures are workable on the Internet, where > communications only take place between peers who have prearranged which > devices talk to which. This worked for USENET news and it works for > exchanging BGP route announcements. Of course there's no unwanted traffic on USENET or BGP. Everyone de-peers Tiscali when their customers' compromised home computers perform DDOS attacks. > As long as we don't fix the architecture of Internet email, we > are stuck with the catch-22 situation that Amazon, and all hosting > providers find themsleves in. These companies really have no choice > but to allow spammers to exploit their services until the spamming > is detected, either proactively by the provider, or reactively by > a complaint to their abuse desk. Nothing prevents Amazon from implementing a hierarchial email delivery network for their little corner of the net. They just have to block outgoing port 25 and require their users to use Amazon's smarthosts. I don't see how, in your preferred replacement email architecture, a provider would be able to avoid policing their users to prevent spam in the way that you complain is so burdensome. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER: SOUTHEAST VEERING SOUTHWEST 5 TO 7, PERHAPS GALE 8 LATER. MODERATE OR ROUGH. THUNDERY RAIN, FOG PATCHES. MODERATE, OCCASIONALLY VERY POOR. From michael.dillon at bt.com Wed May 28 06:13:01 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 May 2008 12:13:01 +0100 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> Message-ID: > I don't see how, in your preferred replacement email > architecture, a provider would be able to avoid policing > their users to prevent spam in the way that you complain is > so burdensome. To begin with, mail could only enter such a system through port 587 or through a rogue operator signing an email peering agreement. In either case, there is a bilateral contract involved so that it is clear whose customer is doing wrong, and therefore who is responsible for policing it. It's a different model in which email traffic follows a chain of bilateral agreements from the sender to the recipient. At each link in the chain, a provider can block traffic if it does not conform to the peering agreement (or service agreement for end users). Today, an anonymous spammer can obfuscate the source of their email in a way that an average user can't figure out who to complain to. In a hierarchical email peering system, only a rogue operator could do that, and by nature of the system, they can't really be totally anonymous. After all they have to sign a peering agreement with someone. --Michael Dillon From braaen at zcorum.com Wed May 28 06:30:51 2008 From: braaen at zcorum.com (Brian Raaen) Date: Wed, 28 May 2008 07:30:51 -0400 Subject: AT&T BGP blackholing In-Reply-To: <483CDAB3.3040301@mindfury.net> References: <483CDAB3.3040301@mindfury.net> Message-ID: <200805280730.55950.braaen@zcorum.com> I'll have to check I have a doc from AT&T at work from when I just set up a BGP session with them about 2 weeks ago. I don't remember if there was a blackhole community or not listed. The doc does list some community strings. I was surprised, they were pretty responsive, now I will find out how the qwest side goes, then I'll have full BGP. -- Brian Raaen Network Engineer braaen at zcorum.com On Wednesday 28 May 2008, Philip L. wrote: > Does anyone have information or a contact at AT&T with regards to > setting up BGP blackholing with them? I see that the question has been > asked in the past but there was no definitive answer, at least none that > I could find. > > --Philip L. > > > > From virendra.rode at gmail.com Wed May 28 10:02:45 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Wed, 28 May 2008 08:02:45 -0700 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <91025932-899A-45C0-8211-79DEC46E2FDA@puck.nether.net> References: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> <5A42EFBD-2B22-4CD8-9952-A5E317FB34F4@puck.nether.net> <000001c8c04b$9accc390$d0664ab0$@com> <91025932-899A-45C0-8211-79DEC46E2FDA@puck.nether.net> Message-ID: <483D7415.1@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jared Mauch wrote: > > On May 27, 2008, at 6:47 PM, Jerry Dixon wrote: > >> Jared nailed it on the head. It is absolutely critical to get to know >> who >> your State JFO POC is, State EOC POC, and have the National Communication >> Systems Hotline on speed dial or at least in your cell. They can help >> facilitate needs such as getting human resources from your company or >> mutual >> aide in to help with a crisis (credentialing issues), fuel trucks, and >> other >> supplies as needed. >> >> Also you might want to check to see if your company has a govt. affairs >> person within your organization who might all ready have a lot of this >> info >> and the contacts to assist. > > I think there's something else to make note of. > > NCS wants to make sure that a number of the ISPs and critical > infrastructure operators have WPS/GETS available to the people who > rightly need them. If you're not sure, give them a ring and chat with > them about what resources you should have at your disposal. If there is > a major communication disruption, this may help your operations team > communicate. - ---------------------------- What you briefly outlined here applies to outages effecting certain size of customers. If so I wonder what's that magic number is? How do you measure the impact of an outage that would require companies to issue outages? It would be nice for these companies to report network outages to a central public forum (w/o bureaucracy) so end users irrespective of the size can lookup such reports and know why their services (e-mail, phones, etc) went down eliminating the need to open tons of trouble tickets during a major event. This way everyone could benefit from it. Due to such lack of information sharing outages mailing was started for the purpose of on having outages available to the public when and where it is most needed irrespective how big or small the company is. Then there are others who believe that there are companies who are protected from public disclosure like to use this protection to their advantage as they no longer have to air their dirty laundry. IMO, network outages needs to get to the public rather than keeping it a secret. Before software bugs were routinely published, network/software companies denied their existence and wouldn't bother fixing them, believing in the security of secrecy. If we return to a practice of keeping these bugs secret, we'll have vulnerabilities known to a few in the security community. Public reporting forces companies to improve their service. regards, /virendra > > You can fill out the forms online at gets.ncs.gov > > - Jared > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIPXQVpbZvCIJx1bcRAjHrAJkB9lNtGYdib5Kezhmz2EBtpoXMowCeKgqR tR1+3To4MsBnTNMEgGJ/6Kw= =GrRH -----END PGP SIGNATURE----- From dot at dotat.at Wed May 28 10:29:55 2008 From: dot at dotat.at (Tony Finch) Date: Wed, 28 May 2008 16:29:55 +0100 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> Message-ID: On Wed, 28 May 2008, michael.dillon at bt.com wrote: > > > I don't see how, in your preferred replacement email > > architecture, a provider would be able to avoid policing > > their users to prevent spam in the way that you complain is > > so burdensome. > > To begin with, mail could only enter such a system through > port 587 or through a rogue operator signing an email peering > agreement. In either case, there is a bilateral contract involved > so that it is clear whose customer is doing wrong, and therefore > who is responsible for policing it. This is different from Amazon's situation how? Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST ICELAND: EASTERLY 4 OR 5, INCREASING 6 OR 7. MODERATE INCREASING ROUGH. RAIN LATER. MODERATE OR GOOD, OCCASIONALLY POOR. From sdhillon at decarta.com Wed May 28 11:03:12 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Wed, 28 May 2008 09:03:12 -0700 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> Message-ID: <483D8240.2080602@decarta.com> Has Amazon given an official statement on this? It would be nice to get someone from within Amazon to give us their official view on this. It would be even more appropriate for the other cloud infrastructures to join in, and or have some sort of RFC to do with SMTP access within the "cloud." I forsee this as a major problem as the idea of "the cloud" is being pushed more and more. You are talking about a spammers dream. Low cost , powerful resources with no restrictions and complete anonymity. Personally I'm going to block *.amazonaws.com from my mail server until Amazon gives us a statement on how they are planning on fighting spam from the cloud. Tony Finch wrote: > On Wed, 28 May 2008, michael.dillon at bt.com wrote: > >>> I don't see how, in your preferred replacement email >>> architecture, a provider would be able to avoid policing >>> their users to prevent spam in the way that you complain is >>> so burdensome. >>> >> To begin with, mail could only enter such a system through >> port 587 or through a rogue operator signing an email peering >> agreement. In either case, there is a bilateral contract involved >> so that it is clear whose customer is doing wrong, and therefore >> who is responsible for policing it. >> > > This is different from Amazon's situation how? > > Tony. > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From steve at blighty.com Wed May 28 11:14:55 2008 From: steve at blighty.com (Steve Atkins) Date: Wed, 28 May 2008 09:14:55 -0700 Subject: amazonaws.com? In-Reply-To: <483D8240.2080602@decarta.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> Message-ID: On May 28, 2008, at 9:03 AM, Sargun Dhillon wrote: > Has Amazon given an official statement on this? It would be nice to > get > someone from within Amazon to give us their official view on this. It > would be even more appropriate for the other cloud infrastructures to > join in, and or have some sort of RFC to do with SMTP access within > the > "cloud." I forsee this as a major problem as the idea of "the cloud" > is > being pushed more and more. You are talking about a spammers dream. > Low > cost , powerful resources with no restrictions and complete anonymity. > > Personally I'm going to block *.amazonaws.com from my mail server > until > Amazon gives us a statement on how they are planning on fighting spam > from the cloud. "The cloud" is just a marketing term for a bunch of virtual servers, at least in Amazons case. It's nothing particularly new, just a VPS farm with the same constraints and abuse issues as a VPS or managed server provider. The only reason this is a problem in the case of Amazon is that they're knowingly selling service to spammers, their abuse guy is in way over his head and isn't interested in policing their users unless they're doing something illegal or the check doesn't clear. As long as the spam being sent doesn't violate CAN-SPAM, it's legal. Cheers, Steve From sdhillon at decarta.com Wed May 28 11:34:24 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Wed, 28 May 2008 09:34:24 -0700 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> Message-ID: <483D8990.50609@decarta.com> Well the thing that differentiates "the cloud" is that there is an infinite amount of resources, the ability to have anonymous access, and the infinite amount of identities. Basically Amazon has allocated a /18, /19, and /17 to EC2. The chances of getting the same IP between two instances amongst that many possibilities is low. Basically someone could easily go get a temporary credit card and start up 10 small EC2 instances. This would give them 10 public IPs which would probably take 3-4 hours (minimum) to show up on any sort of blacklists. Then its just a matter of rebooting and you have another 3-4 hours. This could last weeks with a credit card. Then you could rinse and repeat. In the past I've seen companies require EIN/SSN verification (a bit much) in order to open up certain things (port 25, BGP, etc...). If Amazon is going to continue to have policies that allow spammers to thrive it will end with EC2 failing. SMTP has inherent trust issues. I'm currently researching Amazon AWS's static IP addresses. I think it would be easiest to block everything and just make exemptions for people who purchase the static IPs. My advice to you if you are buying anonymous resources would be to purchase an agreement with a relay that isn't part of the anonymous computing center. Steve Atkins wrote: > > On May 28, 2008, at 9:03 AM, Sargun Dhillon wrote: > >> Has Amazon given an official statement on this? It would be nice to get >> someone from within Amazon to give us their official view on this. It >> would be even more appropriate for the other cloud infrastructures to >> join in, and or have some sort of RFC to do with SMTP access within the >> "cloud." I forsee this as a major problem as the idea of "the cloud" is >> being pushed more and more. You are talking about a spammers dream. Low >> cost , powerful resources with no restrictions and complete anonymity. >> >> Personally I'm going to block *.amazonaws.com from my mail server until >> Amazon gives us a statement on how they are planning on fighting spam >> from the cloud. > > "The cloud" is just a marketing term for a bunch of virtual servers, > at least in Amazons case. It's nothing particularly new, just a VPS > farm with the same constraints and abuse issues as a VPS or > managed server provider. > > The only reason this is a problem in the case of Amazon is that they're > knowingly selling service to spammers, their abuse guy is in > way over his head and isn't interested in policing their users > unless they're doing something illegal or the check doesn't clear. > As long as the spam being sent doesn't violate CAN-SPAM, it's legal. > > Cheers, > Steve > > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From Skywing at valhallalegends.com Wed May 28 12:01:30 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 28 May 2008 12:01:30 -0500 Subject: amazonaws.com? In-Reply-To: <483D8990.50609@decarta.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> That's somewhat ironic of a sentiment you referred to there, given that the conception that one should have to hand over one's SSN for "verification" to anyone who asks for it is the kind of thing that many of these spammers/phishers thrive on in the first place... (I assume that you are not actually really advocating such a requirement for anyone wanting to run a mail server...) - S -----Original Message----- From: Sargun Dhillon [mailto:sdhillon at decarta.com] Sent: Wednesday, May 28, 2008 12:34 PM To: Steve Atkins Cc: nanog at nanog.org Subject: Re: amazonaws.com? Well the thing that differentiates "the cloud" is that there is an infinite amount of resources, the ability to have anonymous access, and the infinite amount of identities. Basically Amazon has allocated a /18, /19, and /17 to EC2. The chances of getting the same IP between two instances amongst that many possibilities is low. Basically someone could easily go get a temporary credit card and start up 10 small EC2 instances. This would give them 10 public IPs which would probably take 3-4 hours (minimum) to show up on any sort of blacklists. Then its just a matter of rebooting and you have another 3-4 hours. This could last weeks with a credit card. Then you could rinse and repeat. In the past I've seen companies require EIN/SSN verification (a bit much) in order to open up certain things (port 25, BGP, etc...). If Amazon is going to continue to have policies that allow spammers to thrive it will end with EC2 failing. SMTP has inherent trust issues. I'm currently researching Amazon AWS's static IP addresses. I think it would be easiest to block everything and just make exemptions for people who purchase the static IPs. My advice to you if you are buying anonymous resources would be to purchase an agreement with a relay that isn't part of the anonymous computing center. Steve Atkins wrote: > > On May 28, 2008, at 9:03 AM, Sargun Dhillon wrote: > >> Has Amazon given an official statement on this? It would be nice to get >> someone from within Amazon to give us their official view on this. It >> would be even more appropriate for the other cloud infrastructures to >> join in, and or have some sort of RFC to do with SMTP access within the >> "cloud." I forsee this as a major problem as the idea of "the cloud" is >> being pushed more and more. You are talking about a spammers dream. Low >> cost , powerful resources with no restrictions and complete anonymity. >> >> Personally I'm going to block *.amazonaws.com from my mail server until >> Amazon gives us a statement on how they are planning on fighting spam >> from the cloud. > > "The cloud" is just a marketing term for a bunch of virtual servers, > at least in Amazons case. It's nothing particularly new, just a VPS > farm with the same constraints and abuse issues as a VPS or > managed server provider. > > The only reason this is a problem in the case of Amazon is that they're > knowingly selling service to spammers, their abuse guy is in > way over his head and isn't interested in policing their users > unless they're doing something illegal or the check doesn't clear. > As long as the spam being sent doesn't violate CAN-SPAM, it's legal. > > Cheers, > Steve > > -- +1.925.202.9485 Sargun Dhillon deCarta sdhillon at decarta.com www.decarta.com From dhetzel at gmail.com Wed May 28 12:13:25 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Wed, 28 May 2008 13:13:25 -0400 Subject: amazonaws.com? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> Message-ID: <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> I would think that simply requiring some appropriate amount of irrevocable funds (wire transfer, etc) for a deposit that will be forfeited in the case of usage in violation of AUP/contract/etc would be both sufficient and not excessive for allowing port 25 access, etc. On Wed, May 28, 2008 at 1:01 PM, Skywing wrote: > That's somewhat ironic of a sentiment you referred to there, given that the > conception that one should have to hand over one's SSN for "verification" to > anyone who asks for it is the kind of thing that many of these > spammers/phishers thrive on in the first place... > > (I assume that you are not actually really advocating such a requirement > for anyone wanting to run a mail server...) > > - S > > -----Original Message----- > From: Sargun Dhillon [mailto:sdhillon at decarta.com] > Sent: Wednesday, May 28, 2008 12:34 PM > To: Steve Atkins > Cc: nanog at nanog.org > Subject: Re: amazonaws.com? > > Well the thing that differentiates "the cloud" is that there is an > infinite amount of resources, the ability to have anonymous access, and > the infinite amount of identities. Basically Amazon has allocated a /18, > /19, and /17 to EC2. The chances of getting the same IP between two > instances amongst that many possibilities is low. Basically someone > could easily go get a temporary credit card and start up 10 small EC2 > instances. This would give them 10 public IPs which would probably take > 3-4 hours (minimum) to show up on any sort of blacklists. Then its just > a matter of rebooting and you have another 3-4 hours. This could last > weeks with a credit card. Then you could rinse and repeat. In the past > I've seen companies require EIN/SSN verification (a bit much) in order > to open up certain things (port 25, BGP, etc...). If Amazon is going to > continue to have policies that allow spammers to thrive it will end with > EC2 failing. > > SMTP has inherent trust issues. I'm currently researching Amazon AWS's > static IP addresses. I think it would be easiest to block everything and > just make exemptions for people who purchase the static IPs. > > My advice to you if you are buying anonymous resources would be to > purchase an agreement with a relay that isn't part of the anonymous > computing center. > > > > > Steve Atkins wrote: > > > > On May 28, 2008, at 9:03 AM, Sargun Dhillon wrote: > > > >> Has Amazon given an official statement on this? It would be nice to get > >> someone from within Amazon to give us their official view on this. It > >> would be even more appropriate for the other cloud infrastructures to > >> join in, and or have some sort of RFC to do with SMTP access within the > >> "cloud." I forsee this as a major problem as the idea of "the cloud" is > >> being pushed more and more. You are talking about a spammers dream. Low > >> cost , powerful resources with no restrictions and complete anonymity. > >> > >> Personally I'm going to block *.amazonaws.com from my mail server until > >> Amazon gives us a statement on how they are planning on fighting spam > >> from the cloud. > > > > "The cloud" is just a marketing term for a bunch of virtual servers, > > at least in Amazons case. It's nothing particularly new, just a VPS > > farm with the same constraints and abuse issues as a VPS or > > managed server provider. > > > > The only reason this is a problem in the case of Amazon is that they're > > knowingly selling service to spammers, their abuse guy is in > > way over his head and isn't interested in policing their users > > unless they're doing something illegal or the check doesn't clear. > > As long as the spam being sent doesn't violate CAN-SPAM, it's legal. > > > > Cheers, > > Steve > > > > > > > -- > +1.925.202.9485 > Sargun Dhillon > deCarta > sdhillon at decarta.com > www.decarta.com > > > > > > From brandon.galbraith at gmail.com Wed May 28 12:18:57 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 28 May 2008 12:18:57 -0500 Subject: amazonaws.com? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> Message-ID: <366100670805281018o66a3f32es13130fec2cb921e7@mail.gmail.com> On 5/28/08, Skywing wrote: > > That's somewhat ironic of a sentiment you referred to there, given that the > conception that one should have to hand over one's SSN for "verification" to > anyone who asks for it is the kind of thing that many of these > spammers/phishers thrive on in the first place... > > (I assume that you are not actually really advocating such a requirement > for anyone wanting to run a mail server...) > > > - S > Many, many years ago, when I was working someplace that was just starting to dabble in shared hosting, the company would require a faxed copy of a driver's license to enable some hosting features (shell off the top of my head). In today's world, this simply will not do (customer sentiment, liability for loss of that data you're storing, and so on). I think the straightforward fix is for Amazon to put some practical mail guidelines together for their environment (time-based volume limitations, Amazon-provided smarthosts, etc) with an exception process for those who need larger amounts of legitimate outbound mail. I guess legitimate is subjective though. *sigh* -brandon From jabley at ca.afilias.info Wed May 28 12:24:56 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 28 May 2008 17:24:56 +0000 Subject: amazonaws.com? In-Reply-To: <483D8990.50609@decarta.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> Message-ID: On 28 May 2008, at 16:34, Sargun Dhillon wrote: > Well the thing that differentiates "the cloud" is that there is an > infinite amount of resources, the ability to have anonymous access, > and > the infinite amount of identities. That sounds great. Presumably in addition to the above the sun is always shining, cats never crap in the kitchen and those responsible for the American Idol franchise have been lined up against the wall and shot? Joe From jra at baylink.com Wed May 28 13:15:01 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 28 May 2008 14:15:01 -0400 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: <91025932-899A-45C0-8211-79DEC46E2FDA@puck.nether.net> References: <200805272209.m4RM9cWO050606@himinbjorg.tucs-beachin-obx-house.com> <5A42EFBD-2B22-4CD8-9952-A5E317FB34F4@puck.nether.net> <000001c8c04b$9accc390$d0664ab0$@com> <91025932-899A-45C0-8211-79DEC46E2FDA@puck.nether.net> Message-ID: <20080528181501.GO28946@cgi.jachomes.com> On Tue, May 27, 2008 at 06:58:47PM -0400, Jared Mauch wrote: > I think there's something else to make note of. > > NCS wants to make sure that a number of the ISPs and critical > infrastructure operators have WPS/GETS available to the people who > rightly need them. If you're not sure, give them a ring and chat with > them about what resources you should have at your disposal. If there > is a major communication disruption, this may help your operations > team communicate. > > You can fill out the forms online at gets.ncs.gov It might be useful, too, to talk to the people who did this in NOLA during and after Katrina; if they didn't know what to do before, they probably do now... Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Wed May 28 13:41:03 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 28 May 2008 14:41:03 -0400 Subject: amazonaws.com? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> Message-ID: <20080528184103.GR28946@cgi.jachomes.com> On Wed, May 28, 2008 at 12:01:30PM -0500, Skywing wrote: > That's somewhat ironic of a sentiment you referred to there, given > that the conception that one should have to hand over one's SSN for > "verification" to anyone who asks for it is the kind of thing that > many of these spammers/phishers thrive on in the first place... What... are people still using SSNs as authenticators instead of identifiers, 20 years on? Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From sean at donelan.com Wed May 28 14:12:29 2008 From: sean at donelan.com (Sean Donelan) Date: Wed, 28 May 2008 15:12:29 -0400 (EDT) Subject: New ID: Special Use IPv4 Addresses Message-ID: http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-01.txt Other than a formatting error in the header ("IPv4 Multicast Guidelines") instead of ("Special Use IPv4 Addresses"), the only significant change appears to be removing the "Reserved" status of the old Classfull boundary networks. The former boundary networks are now subject to allocation like any other unicast IPv4 address space. Host, Router vendors and Network Operators should have already been testing their equipment for proper handling (i.e. not doing anything different) of these network addresses. So this ID should just be a minor IANA administrative cleanup. From michael.dillon at bt.com Wed May 28 14:55:48 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 28 May 2008 20:55:48 +0100 Subject: amazonaws.com? In-Reply-To: <366100670805281018o66a3f32es13130fec2cb921e7@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com><483D8240.2080602@decarta.com><483D8990.50609@decarta.com><982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <366100670805281018o66a3f32es13130fec2cb921e7@mail.gmail.com> Message-ID: > I think the straightforward fix is for Amazon to put some > practical mail guidelines together for their environment Has anyone making these suggestions ever thought to look at the Amazon Web Services agreement that governs these EC2 customers? --Michael Dillon From ml at t-b-o-h.net Wed May 28 18:05:42 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 28 May 2008 19:05:42 -0400 (EDT) Subject: Network meltdowns anywhere in US? Message-ID: <200805282305.m4SN5gdT091976@himinbjorg.tucs-beachin-obx-house.com> Hi, Sorry, would have posted this elsewhere, but I can't get to alot of places... I originally started chasing not being able to get to 71.74.56.243 (RR Mail server). I then found out neither L3 nor my other connection saw it in the table. I checked a few other router servers, some had it, some didn't. Now, though, I'm trying to get a few other places and most of them oddly seem to hang off L3.... (Like the outages list. :) ) Any ideas of there is some meltdown happening in L3 or elsewhere? Thanks, Tuc From virendra.rode at gmail.com Wed May 28 20:15:43 2008 From: virendra.rode at gmail.com (virendra rode) Date: Wed, 28 May 2008 18:15:43 -0700 Subject: Network meltdowns anywhere in US? In-Reply-To: <200805282305.m4SN5gdT091976@himinbjorg.tucs-beachin-obx-house.com> References: <200805282305.m4SN5gdT091976@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <889fd8b20805281815r600522cdrcc233f057f9f69e3@mail.gmail.com> On Wed, May 28, 2008 at 4:05 PM, Tuc at T-B-O-H.NET wrote: > Hi, > > Sorry, would have posted this elsewhere, but I can't get > to alot of places... > > I originally started chasing not being able to get to > 71.74.56.243 (RR Mail server). I then found out neither L3 nor > my other connection saw it in the table. I checked a few other > router servers, some had it, some didn't. > > Now, though, I'm trying to get a few other places and > most of them oddly seem to hang off L3.... (Like the outages > list. :) ) > > Any ideas of there is some meltdown happening > in L3 or elsewhere? > > Thanks, Tuc > > -------------------------------- >From a cursory glance seems to be ok from where I'm currently looking from (at&t), then again I haven't done my technical diligence. Will need to look further and I'm sure someone will pipe up. Do you have any traceroutes, route stats, etc to give us as to what you are experiencing? regards, /virendra From ml at t-b-o-h.net Wed May 28 20:24:28 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 28 May 2008 21:24:28 -0400 (EDT) Subject: Network meltdowns anywhere in US? In-Reply-To: <889fd8b20805281815r600522cdrcc233f057f9f69e3@mail.gmail.com> Message-ID: <200805290124.m4T1OSAR094050@himinbjorg.tucs-beachin-obx-house.com> > On Wed, May 28, 2008 at 4:05 PM, Tuc at T-B-O-H.NET wrote: > > > Hi, > > > > Sorry, would have posted this elsewhere, but I can't get > > to alot of places... > > > > I originally started chasing not being able to get to > > 71.74.56.243 (RR Mail server). I then found out neither L3 nor > > my other connection saw it in the table. I checked a few other > > router servers, some had it, some didn't. > > > > Now, though, I'm trying to get a few other places and > > most of them oddly seem to hang off L3.... (Like the outages > > list. :) ) > > > > Any ideas of there is some meltdown happening > > in L3 or elsewhere? > > > > Thanks, Tuc > > > > -------------------------------- > >From a cursory glance seems to be ok from where I'm currently looking from > (at&t), then again I haven't done my technical diligence. Will need to look > further and I'm sure someone will pipe up. > > Do you have any traceroutes, route stats, etc to give us as to what you are > experiencing? > No, no traceroutes since when I'd query BGP, it just said that the network didn't exist in the table like : ***route-server***>sho ip bgp 71.74.56.243 % Network not in table ***route-server***>sho ip route 71.74.56.243 % Subnet not in table (Only output I captured... But I know that Cerfnet did this too.) Tuc From hannigan at gmail.com Wed May 28 20:33:15 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 28 May 2008 18:33:15 -0700 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> Message-ID: <2d106eb50805281833k46b67ed5na52f47151d608c8f@mail.gmail.com> On Wed, May 28, 2008 at 9:14 AM, Steve Atkins wrote: > > On May 28, 2008, at 9:03 AM, Sargun Dhillon wrote: > >> Has Amazon given an official statement on this? It would be nice to get >> someone from within Amazon to give us their official view on this. It >> would be even more appropriate for the other cloud infrastructures to >> join in, and or have some sort of RFC to do with SMTP access within the >> "cloud." I forsee this as a major problem as the idea of "the cloud" is >> being pushed more and more. You are talking about a spammers dream. Low >> cost , powerful resources with no restrictions and complete anonymity. >> >> Personally I'm going to block *.amazonaws.com from my mail server until >> Amazon gives us a statement on how they are planning on fighting spam >> from the cloud. > > "The cloud" is just a marketing term for a bunch of virtual servers, > at least in Amazons case. It's nothing particularly new, just a VPS > farm with the same constraints and abuse issues as a VPS or > managed server provider.\ These are highly dense service farms that are making efficient use of power, CPU, memory and network based on huge densities based on power and square footage. It's far more than a marketing term. Careful. Don't under estimate this trend. -M< From beckman at angryox.com Wed May 28 20:43:53 2008 From: beckman at angryox.com (Peter Beckman) Date: Wed, 28 May 2008 21:43:53 -0400 Subject: amazonaws.com? In-Reply-To: <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> Message-ID: On Wed, 28 May 2008, Dorn Hetzel wrote: > I would think that simply requiring some appropriate amount of irrevocable > funds (wire transfer, etc) for a deposit that will be forfeited in the case > of usage in violation of AUP/contract/etc would be both sufficient and not > excessive for allowing port 25 access, etc. Until you find out that the source of those supposedly irrevocable funds was stolen or fraudulent, and you have some sort of court subpoena to give it back. I don't believe there is a way for you to outwit the scammer/spammer by making them pay more of their or someone elses money. If you have what they need, they'll find a way to trick you into giving it to them. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From ml at t-b-o-h.net Wed May 28 21:23:31 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Wed, 28 May 2008 22:23:31 -0400 (EDT) Subject: Network meltdowns anywhere in US? In-Reply-To: <889fd8b20805281815r600522cdrcc233f057f9f69e3@mail.gmail.com> from "virendra rode" at May 28, 2008 06:15:43 PM Message-ID: <200805290223.m4T2NWl0056135@vjofn.tucs-beachin-obx-house.com> > On Wed, May 28, 2008 at 4:05 PM, Tuc at T-B-O-H.NET wrote: > > > Hi, > > > > Sorry, would have posted this elsewhere, but I can't get > > to alot of places... > > > > I originally started chasing not being able to get to > > 71.74.56.243 (RR Mail server). I then found out neither L3 nor > > my other connection saw it in the table. I checked a few other > > router servers, some had it, some didn't. > > > > Now, though, I'm trying to get a few other places and > > most of them oddly seem to hang off L3.... (Like the outages > > list. :) ) > > > > Any ideas of there is some meltdown happening > > in L3 or elsewhere? > > > > Thanks, Tuc > > > > -------------------------------- > >From a cursory glance seems to be ok from where I'm currently looking from > (at&t), then again I haven't done my technical diligence. Will need to look > further and I'm sure someone will pipe up. > > Do you have any traceroutes, route stats, etc to give us as to what you are > experiencing? > A bit more "clue"... :) 1) If its been discussed before, I was out that day... But it seems that CERF NET route-server isn't quite authoritative: route-server>sho ip bgp 204.107.90.128 % Network not in table route-server>sho ip bgp route-server> 2) The other route-server it wasn't showing up in is my "backup" provider. I'm trying to get clarification, but I think my backup provider relies too heavily on my primary provider. So yea, it would make sense, if Level3 had an issue, that the provider USING L3 would have an issue. 3) I've gotten zip from L3 about any of this. Can anyone atleast, once again, despite a certain list members contentions, tell me I'm not crazy. That someone else SOMEWHERE saw it? (Or more DIDN'T see RR. :) ) Thanks, Tuc From bzs at world.std.com Wed May 28 22:08:56 2008 From: bzs at world.std.com (Barry Shein) Date: Wed, 28 May 2008 23:08:56 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> Message-ID: <18494.7752.530297.196323@world.std.com> On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: > On Wed, 28 May 2008, Dorn Hetzel wrote: > > > I would think that simply requiring some appropriate amount of irrevocable > > funds (wire transfer, etc) for a deposit that will be forfeited in the case > > of usage in violation of AUP/contract/etc would be both sufficient and not > > excessive for allowing port 25 access, etc. > > Until you find out that the source of those supposedly irrevocable funds > was stolen or fraudulent, and you have some sort of court subpoena to give > it back. > > I don't believe there is a way for you to outwit the scammer/spammer by > making them pay more of their or someone elses money. If you have what > they need, they'll find a way to trick you into giving it to them. Are you still trying to prove that Amazon, Dell, The World, etc can't possibly work? By your reasoning why don't the spammers just empty out Amazon's (et al) warehouses and retire! Oh right, they'd have to sell it all over the internet which'd mean taking credit cards... I'm still curious what a typical $ sale is on one of these cloud compute clusters, in orders of magnitude, $1, $10, $100, $1000, ...? P.S. For the record I'm not a great fan of blocking port 25 as someone mis-cited me here, I don't really care strongly either way, it's a tool. I am a big, big fan of assessing charges for AUP abuse and making some realistic attempt to try to make sure it's collectible, and otherwise make some attempt to know who you're doing business with. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From beckman at angryox.com Wed May 28 22:53:49 2008 From: beckman at angryox.com (Peter Beckman) Date: Wed, 28 May 2008 23:53:49 -0400 Subject: amazonaws.com? In-Reply-To: <18494.7752.530297.196323@world.std.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: On Wed, 28 May 2008, Barry Shein wrote: > On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: > > On Wed, 28 May 2008, Dorn Hetzel wrote: > > > > > I would think that simply requiring some appropriate amount of irrevocable > > > funds (wire transfer, etc) for a deposit that will be forfeited in the case > > > of usage in violation of AUP/contract/etc would be both sufficient and not > > > excessive for allowing port 25 access, etc. > > > > Until you find out that the source of those supposedly irrevocable funds > > was stolen or fraudulent, and you have some sort of court subpoena to give > > it back. > > > > I don't believe there is a way for you to outwit the scammer/spammer by > > making them pay more of their or someone elses money. If you have what > > they need, they'll find a way to trick you into giving it to them. > > Are you still trying to prove that Amazon, Dell, The World, etc can't > possibly work? Amazon and Dell ship physical goods. Amazon Web Services sells services, as do I. Services are commonly enabled and activated immediately after payment or verification of a valid credit card, as is often expected by the customer immediately after payment. Shipment of physical goods will almost always take at least 24 hours, often longer, enabling more thorough checks of credit, however they might do it. And even with the extra time to review the transaction and attempt to detect fraud, I'm confident Amazon and Dell lose millions per year due to fraud. The reality is that the millions they lose to fraud doesn't affect us because a Blu-Ray player purchased with a stolen credit card doesn't send spam or initiate DOS attacks. At least not yet; those Blu-Ray players do have an ethernet port. > By your reasoning why don't the spammers just empty out Amazon's (et > al) warehouses and retire! Oh right, they'd have to sell it all over > the internet which'd mean taking credit cards... Now you're just being rediculous. Or sarcastic. :-) > I am a big, big fan of assessing charges for AUP abuse and making some > realistic attempt to try to make sure it's collectible, and otherwise > make some attempt to know who you're doing business with. Charging whom? The spammer who pays your extra AUP abuse charges with stolen paypal accounts, credit cards, and legit bank accounts funded by money stolen from paypal accounts and transferred from stolen credit cards? If you are taking card-not-present credit card transactions over the Internet or phone, and not shipping physical goods but providing services, in my experience the merchant gets screwed, no matter how much money you might have charged for the privilege of using port 25 or violating AUPs. That money you collected and believed was yours and was in your bank account can be taken out just as easily 6 months later, after the lazy card holder finally reviews his credit card bill, sees unrecognized charges and says "This is fraudulent!" And there you are, without your money. Getting someone to fax their ID in takes extra time and resources, and means it might be hours before you get your account "approved," and for some service providers, part of the value of the service is the immediacy in which a customer can gain new service. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From smb at cs.columbia.edu Wed May 28 23:14:50 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 29 May 2008 00:14:50 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> <32648.1211920991@turing-police.cc.vt.edu> Message-ID: <20080529001450.10db0337@cs.columbia.edu> On Wed, 28 May 2008 10:37:05 +0100 wrote: > > So let's see - if you had a billion CPUs in your botnet, and > > each one could go at a billion to the second, you still need > > 2**69 seconds or 449,235,776,528,695 years. Not bad - only > > 10,000 times the amount of time this planet has been around, > > so yeah, that's the way they'll attack all right. > > I didn't say that. I said that they are starting with an IOS image > in which there are some small number of bytes which they can possibly > change and still have a functional image. So it is likely that they > will brute force that by computing an MD5 hash on all variations of > those few bytes. It's like winning the lottery, you only *NEED* to > buy one ticket. No matter how slim the chances are of bad guys winning > that lottery, it is no excuse for ignoring the possibility that an > MD5 hash check may not be proof that you have an original image. > Did you even look at Valdis' arithmetic? It *won't work*. It isn't "likely" that they'll try anything with that low a chance of success. As for "no matter how slim the chances" -- if you want to have even a vague chance of succeeding before Sol turns into a red giant, you're going to have to devote enormous resources to the project. (Actually, I don't think you can succeed even then, not by brute force -- there aren't a "small number of bytes" that can be changed, you can introduce "random" "typographical" errors in error messages for the SNA stack or some such, and if you're doing a brute force pre-image attack on MD5 any bit is as good as any other.) Let's put it purely in economic terms: which is a better way to invest your effort, building a machine (or botnet) with many billions of processors and still having no plausible chance of winning, or -- as you yourself suggest -- getting the HVAC contract for the data center. Or putting back doors in the chips. Or bribing or blackmailing coders. Or breaking into the vault where Cisco keeps its master RSA key. Or funding a vast research effort on cracking MD5 before it's replaced by SHA-512. Or *something* even vaguely sane, because brute-forcing MD5 isn't physically possible. --Steve Bellovin, http://www.cs.columbia.edu/~smb From virendra.rode at gmail.com Wed May 28 23:18:12 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Wed, 28 May 2008 21:18:12 -0700 Subject: Network meltdowns anywhere in US? In-Reply-To: <200805290223.m4T2NWl0056135@vjofn.tucs-beachin-obx-house.com> References: <200805290223.m4T2NWl0056135@vjofn.tucs-beachin-obx-house.com> Message-ID: <483E2E84.1020300@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tuc at T-B-O-H wrote: >> On Wed, May 28, 2008 at 4:05 PM, Tuc at T-B-O-H.NET wrote: >> >>> Hi, >>> >>> Sorry, would have posted this elsewhere, but I can't get >>> to alot of places... >>> >>> I originally started chasing not being able to get to >>> 71.74.56.243 (RR Mail server). I then found out neither L3 nor >>> my other connection saw it in the table. I checked a few other >>> router servers, some had it, some didn't. >>> >>> Now, though, I'm trying to get a few other places and >>> most of them oddly seem to hang off L3.... (Like the outages >>> list. :) ) >>> >>> Any ideas of there is some meltdown happening >>> in L3 or elsewhere? >>> >>> Thanks, Tuc >>> >>> -------------------------------- >> >From a cursory glance seems to be ok from where I'm currently looking from >> (at&t), then again I haven't done my technical diligence. Will need to look >> further and I'm sure someone will pipe up. >> >> Do you have any traceroutes, route stats, etc to give us as to what you are >> experiencing? >> > > A bit more "clue"... :) > > 1) If its been discussed before, I was out that day... But it seems > that CERF NET route-server isn't quite authoritative: > > route-server>sho ip bgp 204.107.90.128 > % Network not in table > > route-server>sho ip bgp > > route-server> - --------------------------------- you could also try, route-views.oregon-ix.net>sho ip bgp 204.107.90.128 BGP routing table entry for 204.107.90.0/24, version 201333 Paths: (35 available, best #32, table Default-IP-Routing-Table) Not advertised to any peer 3303 3356 1784 35954 164.128.32.11 from 164.128.32.11 (164.128.32.11) Origin IGP, localpref 100, valid, external Community: 3303:5004 3277 3267 9002 1784 35954 194.85.4.55 from 194.85.4.55 (194.85.4.16) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65100 3277:65320 3277:65326 812 6461 3356 7911 35954 64.71.255.61 from 64.71.255.61 (64.71.255.61) Origin IGP, localpref 100, valid, external 293 3356 7911 35954 134.55.200.1 from 134.55.200.1 (134.55.200.1) Origin IGP, localpref 100, valid, external Community: 293:14 293:41 2905 701 3356 1784 35954 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external 4513 13789 22212 1784 35954 209.10.12.125 from 209.10.12.125 (209.10.12.125) Origin IGP, metric 4103, localpref 100, valid, external 4513 12182 3356 7911 35954 209.10.12.156 from 209.10.12.156 (209.10.12.156) Origin IGP, metric 7002, localpref 100, valid, external 2497 1784 35954 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 5511 3356 1784 35954 193.251.245.6 from 193.251.245.6 (193.251.245.6) Origin IGP, localpref 100, valid, external 3257 3356 7911 35954 89.149.178.10 from 89.149.178.10 (213.200.87.40) Origin IGP, metric 10, localpref 100, valid, external Community: 3257:3150 3257:3152 3257:5010 6079 1784 35954 207.172.6.162 from 207.172.6.162 (207.172.6.162) Origin IGP, metric 6, localpref 100, valid, external 6539 1784 35954 66.59.190.221 from 66.59.190.221 (66.59.190.221) Origin IGP, localpref 100, valid, external 6453 3356 1784 35954 195.219.96.239 from 195.219.96.239 (195.219.96.239) Origin IGP, localpref 100, valid, external 1221 4637 3356 7911 35954 203.62.252.186 from 203.62.252.186 (203.62.252.186) Origin IGP, localpref 100, valid, external 7500 2516 1784 35954 202.249.2.86 from 202.249.2.86 (203.178.133.115) Origin IGP, localpref 100, valid, external 7660 2516 1784 35954 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 2914 3356 7911 35954 129.250.0.171 from 129.250.0.171 (129.250.0.12) Origin IGP, metric 1, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:3356 6079 1784 35954 207.172.6.20 from 207.172.6.20 (207.172.6.20) Origin IGP, metric 0, localpref 100, valid, external 701 3356 7911 35954 157.130.10.233 from 157.130.10.233 (137.39.3.60) Origin IGP, localpref 100, valid, external 1668 3356 7911 35954 66.185.128.48 from 66.185.128.48 (66.185.128.48) Origin IGP, metric 504, localpref 100, valid, external 3549 3356 7911 35954 208.51.134.254 from 208.51.134.254 (67.17.81.162) Origin IGP, metric 53, localpref 100, valid, external Community: 3549:2142 3549:30840 852 1239 3356 7911 35954 154.11.11.113 from 154.11.11.113 (154.11.11.113) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 3333 3356 1784 35954 193.0.0.56 from 193.0.0.56 (193.0.0.56) Origin IGP, localpref 100, valid, external 3356 7911 35954 4.68.1.166 from 4.68.1.166 (4.68.1.166) Origin IGP, metric 0, localpref 100, valid, external Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2008 7911:777 7911:7707 35954:5000 852 1239 3356 7911 35954 154.11.98.225 from 154.11.98.225 (154.11.98.225) Origin IGP, metric 0, localpref 100, valid, external Community: 852:180 7018 3356 1784 35954 12.0.1.63 from 12.0.1.63 (12.0.1.63) Origin IGP, localpref 100, valid, external Community: 7018:5000 3561 3356 7911 35954 206.24.210.100 from 206.24.210.100 (206.24.210.100) Origin IGP, localpref 100, valid, external 6453 3356 7911 35954 207.45.223.244 from 207.45.223.244 (207.45.196.93) Origin IGP, localpref 100, valid, external 12956 3356 7911 35954 213.140.32.146 from 213.140.32.146 (213.140.32.146) Origin IGP, localpref 100, valid, external Community: 3356:3 3356:22 3356:100 3356:123 3356:575 3356:2008 7911:777 7911:7707 12956:321 12956:4003 12956:4030 12956:4303 12956:18300 12956:26570 12956:26571 35954:5000 1239 3356 7911 35954 144.228.241.81 from 144.228.241.81 (144.228.241.81) Origin IGP, metric 4294967294, localpref 100, valid, external Community: 1239:321 1239:1000 1239:1011 2828 3356 7911 35954 65.106.7.139 from 65.106.7.139 (66.239.189.139) Origin IGP, metric 3, localpref 100, valid, external 8075 1784 35954 207.46.32.34 from 207.46.32.34 (207.46.32.34) Origin IGP, localpref 100, valid, external, best 6939 1784 35954 216.218.252.164 from 216.218.252.164 (216.218.252.164) Origin IGP, localpref 100, valid, external 6461 3356 7911 35954 64.125.0.137 from 64.125.0.137 (64.125.0.137) Origin IGP, metric 124, localpref 100, valid, external Community: 6461:5997 2914 3356 7911 35954 129.250.0.11 from 129.250.0.11 (129.250.0.51) Origin IGP, metric 4, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:3356 > > > 2) The other route-server it wasn't showing up in is my "backup" > provider. I'm trying to get clarification, but I think my backup provider > relies too heavily on my primary provider. So yea, it would make sense, if > Level3 had an issue, that the provider USING L3 would have an issue. > > 3) I've gotten zip from L3 about any of this. - ------------------- I will try and look deeper into this and get back with you tomorrow. > > > > Can anyone atleast, once again, despite a certain list members > contentions, tell me I'm not crazy. That someone else SOMEWHERE saw it? > (Or more DIDN'T see RR. :) ) - ----------------------- Level 3 (Cleveland, OH) BGP routes for 204.107.90.128 BGP routing table entry for 204.107.90.0/24 Paths: (2 available, best #1) 7911 35954 AS-path translation: { WCG TBOH-SwitchData } car4.Washington1 (metric 50748) Origin IGP, metric 0, localpref 100, valid, internal, best Community: North_America Lclprf_100 Level3_Customer United_States Washington_DC 7911:777 7911:7707 35954:5000 Originator: car4.Washington1 7911 35954 AS-path translation: { WCG TBOH-SwitchData } car4.Washington1 (metric 50748) Origin IGP, metric 0, localpref 100, valid, internal Community: North_America Lclprf_100 Level3_Customer United_States Washington_DC 7911:777 7911:7707 35954:5000 Originator: car4.Washington1 regards, /virendra > > Thanks, Tuc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIPi6EpbZvCIJx1bcRAqJ/AJ0c8vNHCnRbWAs6cX/GPa1tAuiocwCfXDx2 U0se0Anjo5GfttXFOkC/6DI= =M5RR -----END PGP SIGNATURE----- From ge at linuxbox.org Wed May 28 23:20:48 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 28 May 2008 23:20:48 -0500 (CDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <20080529001450.10db0337@cs.columbia.edu> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> <32648.1211920991@turing-police.cc.vt.edu> <20080529001450.10db0337@cs.columbia.edu> Message-ID: On Thu, 29 May 2008, Steven M. Bellovin wrote: > On Wed, 28 May 2008 10:37:05 +0100 > wrote: > >>> So let's see - if you had a billion CPUs in your botnet, and >>> each one could go at a billion to the second, you still need >>> 2**69 seconds or 449,235,776,528,695 years. Not bad - only >>> 10,000 times the amount of time this planet has been around, >>> so yeah, that's the way they'll attack all right. >> >> I didn't say that. I said that they are starting with an IOS image >> in which there are some small number of bytes which they can possibly >> change and still have a functional image. So it is likely that they >> will brute force that by computing an MD5 hash on all variations of >> those few bytes. It's like winning the lottery, you only *NEED* to >> buy one ticket. No matter how slim the chances are of bad guys winning >> that lottery, it is no excuse for ignoring the possibility that an >> MD5 hash check may not be proof that you have an original image. >> > Did you even look at Valdis' arithmetic? It *won't work*. It isn't > "likely" that they'll try anything with that low a chance of success. > As for "no matter how slim the chances" -- if you want to have even a > vague chance of succeeding before Sol turns into a red giant, you're > going to have to devote enormous resources to the project. (Actually, > I don't think you can succeed even then, not by brute force -- there > aren't a "small number of bytes" that can be changed, you can introduce > "random" "typographical" errors in error messages for the SNA stack or > some such, and if you're doing a brute force pre-image attack on MD5 any > bit is as good as any other.) Let's put it purely in economic terms: > which is a better way to invest your effort, building a machine (or > botnet) with many billions of processors and still having no plausible > chance of winning, or -- as you yourself suggest -- getting the HVAC > contract for the data center. Or putting back doors in the chips. Or > bribing or blackmailing coders. Or breaking into the vault where Cisco > keeps its master RSA key. Or funding a vast research effort on > cracking MD5 before it's replaced by SHA-512. Or *something* even > vaguely sane, because brute-forcing MD5 isn't physically possible. I don't understand how this disucssion got to breaking MD5 to begin with? The whole point was that the results will be manipulated due to the rootkit messing with the test, no? Gadi. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From hb-nanog at bsws.de Thu May 29 07:11:12 2008 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 29 May 2008 14:11:12 +0200 Subject: Postmaster @ vtext.com (or what are best practice to send SMS these days) In-Reply-To: <48063098.2050500@everydns.net> References: <48063098.2050500@everydns.net> Message-ID: <20080529121112.GO348@nudo.bsws.de> * David Ulevitch [2008-04-16 19:18]: > What else are operators doing to get the pages out when things go wonky? a UMTS/3G card, that just attaches a usb controller (ohci) and a usb-serial converter behind it (ubsa), and a "modem" behind that takes AT commands. the commands are even somewhat standardized. Add a bit of kermit and shell scripting around and you have a very reliable out-of-band notification mechanism. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam From jloiacon at csc.com Thu May 29 07:12:16 2008 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 29 May 2008 08:12:16 -0400 Subject: amazonaws.com? In-Reply-To: <18494.7752.530297.196323@world.std.com> Message-ID: Barry Shein wrote on 05/28/2008 11:08:56 PM: > I'm still curious what a typical $ sale is on one of these cloud > compute clusters, in orders of magnitude, $1, $10, $100, $1000, ...? Not sure what a typical sale looks like, but Single virtual instance: ~ $72/month from AWS: Storage $0.15 per GB-Month of storage used Data Transfer $0.100 per GB - all data transfer in $0.170 per GB - first 10 TB / month data transfer out $0.130 per GB - next 40 TB / month data transfer out $0.110 per GB - next 100 TB / month data transfer out $0.100 per GB - data transfer out / month over 150 TB Requests $0.01 per 1,000 PUT, POST, or LIST requests $0.01 per 10,000 GET and all other requests* * No charge for delete requests Joe From pizzonia at dia.uniroma3.it Thu May 29 07:24:55 2008 From: pizzonia at dia.uniroma3.it (Maurizio Pizzonia) Date: Thu, 29 May 2008 14:24:55 +0200 Subject: Announcing iBGPlay: visualization of BGP events Message-ID: <483EA097.7010305@dia.uniroma3.it> iBGPlay is a free tool that graphically displays and animates BGP routing announcements (http://www.ibgplay.org). iBGPlay will be presented at NANOG43 on June 3, 2008. For those that are familiar with BGPlay (http://bgplay.routeviews.org/bgplay/, http://www.ris.ripe.net/bgplay): - iBGPlay offers a similar service showing BGP updates received by the border routers of the ISP that uses it. Hence, it is somehow complementary to BGPlay. - BGP updates received by different border routers of the ISP are shown in an integrated view. Maurizio Pizzonia iBGPlay team -- _Maurizio Pizzonia_______________________________________________ Dipartimento di Informatica e Automazione ph. +39-06-5733-3311 Universita` Roma Tre fax +39-06-5733-3211 ____________________________ http://www.dia.uniroma3.it/~pizzonia From dhetzel at gmail.com Thu May 29 07:56:07 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 29 May 2008 08:56:07 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> There is a really huge difference in the ease with which payment from a credit card can be reversed if fraudulent, and the amount of effort necessary to reverse a wire transfer. I won't go so far as to say that reversing a wire transfer is impossible, but I would claim it's many orders of magnitude harder than the credit card reversal. A mere "court subpoena" wouldn't even be remotely sufficient. The person wanting their money back would pretty much have to sue for it and win. Heck, people that get scammed and send their money via western union can't even get their money back... People who sell physical goods that get shipped internationally to places where they can't get them back from have been dealing with irrevocable payment forms for a long, long time, and those are generally wire transfers. Once that guy in Frackustan has my widgets, I need to make darn sure he can't take his money back :) So, yeah, there would be some customers for whom the couple of business hours it take their wire to go through (that's a pretty typical time from my actual experience) would be longer than they would want to wait for their port 25 or other "risky" service to be enabled, but really, how many is that going to be. We're not talking about the wait for ordinary customers who don't need those particular services that tend to be problem children, and we're not talking about existing accounts of long standing, just about a barrier for the drive-by customer who wants to use services and then not pay the cost when they violate the AUP... On Wed, May 28, 2008 at 11:53 PM, Peter Beckman wrote: > On Wed, 28 May 2008, Barry Shein wrote: > > On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: >> > On Wed, 28 May 2008, Dorn Hetzel wrote: >> > >> > > I would think that simply requiring some appropriate amount of >> irrevocable >> > > funds (wire transfer, etc) for a deposit that will be forfeited in the >> case >> > > of usage in violation of AUP/contract/etc would be both sufficient and >> not >> > > excessive for allowing port 25 access, etc. >> > >> > Until you find out that the source of those supposedly irrevocable >> funds >> > was stolen or fraudulent, and you have some sort of court subpoena to >> give >> > it back. >> > >> > I don't believe there is a way for you to outwit the scammer/spammer >> by >> > making them pay more of their or someone elses money. If you have >> what >> > they need, they'll find a way to trick you into giving it to them. >> >> Are you still trying to prove that Amazon, Dell, The World, etc can't >> possibly work? >> > > Amazon and Dell ship physical goods. Amazon Web Services sells services, > as do I. Services are commonly enabled and activated immediately after > payment or verification of a valid credit card, as is often expected by > the customer immediately after payment. Shipment of physical goods will > almost always take at least 24 hours, often longer, enabling more thorough > checks of credit, however they might do it. > > And even with the extra time to review the transaction and attempt to > detect fraud, I'm confident Amazon and Dell lose millions per year due to > fraud. The reality is that the millions they lose to fraud doesn't affect > us because a Blu-Ray player purchased with a stolen credit card doesn't > send spam or initiate DOS attacks. > > At least not yet; those Blu-Ray players do have an ethernet port. > > By your reasoning why don't the spammers just empty out Amazon's (et >> al) warehouses and retire! Oh right, they'd have to sell it all over >> the internet which'd mean taking credit cards... >> > > Now you're just being rediculous. Or sarcastic. :-) > > I am a big, big fan of assessing charges for AUP abuse and making some >> realistic attempt to try to make sure it's collectible, and otherwise >> make some attempt to know who you're doing business with. >> > > Charging whom? The spammer who pays your extra AUP abuse charges with > stolen paypal accounts, credit cards, and legit bank accounts funded by > money stolen from paypal accounts and transferred from stolen credit > cards? > > If you are taking card-not-present credit card transactions over the > Internet or phone, and not shipping physical goods but providing services, > in my experience the merchant gets screwed, no matter how much money you > might have charged for the privilege of using port 25 or violating AUPs. > That money you collected and believed was yours and was in your bank > account can be taken out just as easily 6 months later, after the lazy > card holder finally reviews his credit card bill, sees unrecognized > charges and says "This is fraudulent!" And there you are, without your > money. > > Getting someone to fax their ID in takes extra time and resources, and > means it might be hours before you get your account "approved," and for > some service providers, part of the value of the service is the immediacy > in which a customer can gain new service. > > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > --------------------------------------------------------------------------- > > From aiversonlists at spamresource.com Thu May 29 08:07:10 2008 From: aiversonlists at spamresource.com (Al Iverson) Date: Thu, 29 May 2008 09:07:10 -0400 Subject: amazonaws.com? In-Reply-To: <18494.7752.530297.196323@world.std.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: <7d6a0cac0805290607t244f342dwe7f7f3788a1eb0b8@mail.gmail.com> On Wed, May 28, 2008 at 11:08 PM, Barry Shein wrote: > I am a big, big fan of assessing charges for AUP abuse and making some > realistic attempt to try to make sure it's collectible, and otherwise > make some attempt to know who you're doing business with. Just out of curiosity, what stats can you make available as far as: - How often you assess this AUP abuse fee? - How often it is successfully collected? - How successful are chargebacks against that fee? I've heard lots of anti-abuse folks opine that this helps with spam and other abuse prevention and cleanup, but I've never seen it in practice before. I've also heard multiple ISP folks talk about it being unenforceable. And from what I know from working for an e-commerce service provider in the past, it sounds like a chargeback magnet that could even endanger the merchant account of anybody who uses it more than once. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove "lists" from my email address to reach me faster and directly. From joelja at bogus.com Thu May 29 08:08:47 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 29 May 2008 06:08:47 -0700 Subject: amazonaws.com? In-Reply-To: <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> Message-ID: <483EAADF.5040905@bogus.com> Dorn Hetzel wrote: > There is a really huge difference in the ease with which payment from a > credit card can be reversed if fraudulent, and the amount of effort > necessary to reverse a wire transfer. I won't go so far as to say that > reversing a wire transfer is impossible, but I would claim it's many orders > of magnitude harder than the credit card reversal. To paraphrase one of my colleagues from the user interaction world: "The key to offering a compelling service is minimising transaction hassles." I encourage all my competitors to implement inconvenient hard to use payment methods.... > A mere "court subpoena" wouldn't even be remotely sufficient. The person > wanting their money back would pretty much have to sue for it and win. > Heck, people that get scammed and send their money via western union can't > even get their money back... People who sell physical goods that get > shipped internationally to places where they can't get them back from have > been dealing with irrevocable payment forms for a long, long time, and those > are generally wire transfers. > > Once that guy in Frackustan has my widgets, I need to make darn sure he > can't take his money back :) > > So, yeah, there would be some customers for whom the couple of business > hours it take their wire to go through (that's a pretty typical time from my > actual experience) would be longer than they would want to wait for their > port 25 or other "risky" service to be enabled, but really, how many is that > going to be. We're not talking about the wait for ordinary customers who > don't need those particular services that tend to be problem children, and > we're not talking about existing accounts of long standing, just about a > barrier for the drive-by customer who wants to use services and then not pay > the cost when they violate the AUP... > > On Wed, May 28, 2008 at 11:53 PM, Peter Beckman wrote: > >> On Wed, 28 May 2008, Barry Shein wrote: >> >> On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: >>>> On Wed, 28 May 2008, Dorn Hetzel wrote: >>>> >>>>> I would think that simply requiring some appropriate amount of >>> irrevocable >>>>> funds (wire transfer, etc) for a deposit that will be forfeited in the >>> case >>>>> of usage in violation of AUP/contract/etc would be both sufficient and >>> not >>>>> excessive for allowing port 25 access, etc. >>>> Until you find out that the source of those supposedly irrevocable >>> funds >>>> was stolen or fraudulent, and you have some sort of court subpoena to >>> give >>>> it back. >>>> >>>> I don't believe there is a way for you to outwit the scammer/spammer >>> by >>>> making them pay more of their or someone elses money. If you have >>> what >>>> they need, they'll find a way to trick you into giving it to them. >>> Are you still trying to prove that Amazon, Dell, The World, etc can't >>> possibly work? >>> >> Amazon and Dell ship physical goods. Amazon Web Services sells services, >> as do I. Services are commonly enabled and activated immediately after >> payment or verification of a valid credit card, as is often expected by >> the customer immediately after payment. Shipment of physical goods will >> almost always take at least 24 hours, often longer, enabling more thorough >> checks of credit, however they might do it. >> >> And even with the extra time to review the transaction and attempt to >> detect fraud, I'm confident Amazon and Dell lose millions per year due to >> fraud. The reality is that the millions they lose to fraud doesn't affect >> us because a Blu-Ray player purchased with a stolen credit card doesn't >> send spam or initiate DOS attacks. >> >> At least not yet; those Blu-Ray players do have an ethernet port. >> >> By your reasoning why don't the spammers just empty out Amazon's (et >>> al) warehouses and retire! Oh right, they'd have to sell it all over >>> the internet which'd mean taking credit cards... >>> >> Now you're just being rediculous. Or sarcastic. :-) >> >> I am a big, big fan of assessing charges for AUP abuse and making some >>> realistic attempt to try to make sure it's collectible, and otherwise >>> make some attempt to know who you're doing business with. >>> >> Charging whom? The spammer who pays your extra AUP abuse charges with >> stolen paypal accounts, credit cards, and legit bank accounts funded by >> money stolen from paypal accounts and transferred from stolen credit >> cards? >> >> If you are taking card-not-present credit card transactions over the >> Internet or phone, and not shipping physical goods but providing services, >> in my experience the merchant gets screwed, no matter how much money you >> might have charged for the privilege of using port 25 or violating AUPs. >> That money you collected and believed was yours and was in your bank >> account can be taken out just as easily 6 months later, after the lazy >> card holder finally reviews his credit card bill, sees unrecognized >> charges and says "This is fraudulent!" And there you are, without your >> money. >> >> Getting someone to fax their ID in takes extra time and resources, and >> means it might be hours before you get your account "approved," and for >> some service providers, part of the value of the service is the immediacy >> in which a customer can gain new service. >> >> >> Beckman >> --------------------------------------------------------------------------- >> Peter Beckman Internet Guy >> beckman at angryox.com >> http://www.angryox.com/ >> --------------------------------------------------------------------------- >> >> > From mhuff at ox.com Thu May 29 08:14:50 2008 From: mhuff at ox.com (Matthew Huff) Date: Thu, 29 May 2008 09:14:50 -0400 Subject: amazonaws.com? In-Reply-To: <483EAADF.5040905@bogus.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> Message-ID: <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> The financial services world felt the same pre-9/11. Since then FINRA and SEC regulations enforce "Know Your Customer" rules that require extensive record keeping. The regulations now are quite burdensome. Given that usage of "cloud" resources could be used for DDOS and other illegal activities, I wonder how long it will take companies to realize that if they don't do a good job of self policing, the result will be something they would prefer not to have happen. ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.otaotr.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Thursday, May 29, 2008 9:09 AM To: Dorn Hetzel Cc: nanog at nanog.org Subject: Re: amazonaws.com? Dorn Hetzel wrote: > There is a really huge difference in the ease with which payment from a > credit card can be reversed if fraudulent, and the amount of effort > necessary to reverse a wire transfer. I won't go so far as to say that > reversing a wire transfer is impossible, but I would claim it's many orders > of magnitude harder than the credit card reversal. To paraphrase one of my colleagues from the user interaction world: "The key to offering a compelling service is minimising transaction hassles." I encourage all my competitors to implement inconvenient hard to use payment methods.... > A mere "court subpoena" wouldn't even be remotely sufficient. The person > wanting their money back would pretty much have to sue for it and win. > Heck, people that get scammed and send their money via western union can't > even get their money back... People who sell physical goods that get > shipped internationally to places where they can't get them back from have > been dealing with irrevocable payment forms for a long, long time, and those > are generally wire transfers. > > Once that guy in Frackustan has my widgets, I need to make darn sure he > can't take his money back :) > > So, yeah, there would be some customers for whom the couple of business > hours it take their wire to go through (that's a pretty typical time from my > actual experience) would be longer than they would want to wait for their > port 25 or other "risky" service to be enabled, but really, how many is that > going to be. We're not talking about the wait for ordinary customers who > don't need those particular services that tend to be problem children, and > we're not talking about existing accounts of long standing, just about a > barrier for the drive-by customer who wants to use services and then not pay > the cost when they violate the AUP... > > On Wed, May 28, 2008 at 11:53 PM, Peter Beckman wrote: > >> On Wed, 28 May 2008, Barry Shein wrote: >> >> On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: >>>> On Wed, 28 May 2008, Dorn Hetzel wrote: >>>> >>>>> I would think that simply requiring some appropriate amount of >>> irrevocable >>>>> funds (wire transfer, etc) for a deposit that will be forfeited in the >>> case >>>>> of usage in violation of AUP/contract/etc would be both sufficient and >>> not >>>>> excessive for allowing port 25 access, etc. >>>> Until you find out that the source of those supposedly irrevocable >>> funds >>>> was stolen or fraudulent, and you have some sort of court subpoena to >>> give >>>> it back. >>>> >>>> I don't believe there is a way for you to outwit the scammer/spammer >>> by >>>> making them pay more of their or someone elses money. If you have >>> what >>>> they need, they'll find a way to trick you into giving it to them. >>> Are you still trying to prove that Amazon, Dell, The World, etc can't >>> possibly work? >>> >> Amazon and Dell ship physical goods. Amazon Web Services sells services, >> as do I. Services are commonly enabled and activated immediately after >> payment or verification of a valid credit card, as is often expected by >> the customer immediately after payment. Shipment of physical goods will >> almost always take at least 24 hours, often longer, enabling more thorough >> checks of credit, however they might do it. >> >> And even with the extra time to review the transaction and attempt to >> detect fraud, I'm confident Amazon and Dell lose millions per year due to >> fraud. The reality is that the millions they lose to fraud doesn't affect >> us because a Blu-Ray player purchased with a stolen credit card doesn't >> send spam or initiate DOS attacks. >> >> At least not yet; those Blu-Ray players do have an ethernet port. >> >> By your reasoning why don't the spammers just empty out Amazon's (et >>> al) warehouses and retire! Oh right, they'd have to sell it all over >>> the internet which'd mean taking credit cards... >>> >> Now you're just being rediculous. Or sarcastic. :-) >> >> I am a big, big fan of assessing charges for AUP abuse and making some >>> realistic attempt to try to make sure it's collectible, and otherwise >>> make some attempt to know who you're doing business with. >>> >> Charging whom? The spammer who pays your extra AUP abuse charges with >> stolen paypal accounts, credit cards, and legit bank accounts funded by >> money stolen from paypal accounts and transferred from stolen credit >> cards? >> >> If you are taking card-not-present credit card transactions over the >> Internet or phone, and not shipping physical goods but providing services, >> in my experience the merchant gets screwed, no matter how much money you >> might have charged for the privilege of using port 25 or violating AUPs. >> That money you collected and believed was yours and was in your bank >> account can be taken out just as easily 6 months later, after the lazy >> card holder finally reviews his credit card bill, sees unrecognized >> charges and says "This is fraudulent!" And there you are, without your >> money. >> >> Getting someone to fax their ID in takes extra time and resources, and >> means it might be hours before you get your account "approved," and for >> some service providers, part of the value of the service is the immediacy >> in which a customer can gain new service. >> >> >> Beckman >> --------------------------------------------------------------------------- >> Peter Beckman Internet Guy >> beckman at angryox.com >> http://www.angryox.com/ >> --------------------------------------------------------------------------- >> >> > From freimer at ctiusa.com Thu May 29 08:18:07 2008 From: freimer at ctiusa.com (Fred Reimer) Date: Thu, 29 May 2008 09:18:07 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu> Message-ID: <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> The conversation shifted to breaking MD5 because it was mentioned that one way to prevent the installation of cracked IOS images was to include some sort of DRM or trusted computing chip in new hardware, and have Cisco sign their IOS images (supposedly even the boot EEPROM). This wouldn't be DRM in the sense of DVD's, where they don't want everyone to be able to decode the disk, so must come up with some scheme where they provide the decryption key that is itself decrypted with a private key which all of the DVD players have the public key for, hence could be relatively easily broken (just extract the public key from the player, which was what was done for HD-DVD. In other words, attacking the crypto scheme instead of the algorithm. Cisco would presumably want everyone to be able to read the file, just sign it with their private key. So how do you sign an IOS image? Most crypto schemes work by generating a MD5 hash of the data, and then signing the MD5 hash, not signing the whole IOS image, which would be encrypting the whole thing. Decrypting an IOS image sized data block with the RSA algorithm would presumably take too long, so just the hash is signed. If the signed hash matches the hash you compute when loading the image it's a good image, so the boot ROM would load the code. Once loaded, it would check the signature (of the hash) on any new boot ROM loaded so that attackers could not use that vector. For what it's worth, encrypting the whole file is still not normally done by encrypting with the RSA public key of the destination. Rather, another symmetric protocol is used, such as 3DES or IDEA or something, and they key for that protocol is encrypted with RSA. The private key in this case would be located... on the new Cisco hardware. So, much like breaking HD-DVD crypto scheme this could be broken also. However, I don't think it is the goal to encrypt the IOS code, just ensure that it is valid code from Cisco, so an appropriate hash should do just fine. So the only easy way to attack this is the MD5 hash. We have a know plaintext (the IOS code) and the hash. It is not trivial to be able to make changes in the code and maintain the same hash value, but there has been at least limited success in doing so. If they can change the code and fiddle with the help text in some obscure feature no one regularly uses and generate the same hash then viola, access. That's how we got onto breaking MD5. However, if there is a known vulnerability, to however few people, in IOS where there is a buffer overflow or something else where remote code can be executed, this presumably could overwrite the IOS code running on the box and bypass the code-checking hardware. It may not be possible to replace the boot ROM, because presumably the new hardware would check the ROM code hash before loading it and also presumably the ROM code does not have quite as much text messages that can be changed to generate the same hash value, thereby bypassing the security checks. So in this scenario rooted IOS would only exist transiently; a reboot would load the known good code again (or brick the box if "bad" ROMMON were burned). Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Thursday, May 29, 2008 12:21 AM > To: Steven M. Bellovin > Cc: nanog at nanog.org > Subject: Re: IOS Rookit: the sky isn't falling (yet) > > On Thu, 29 May 2008, Steven M. Bellovin wrote: > > On Wed, 28 May 2008 10:37:05 +0100 > > wrote: > > > >>> So let's see - if you had a billion CPUs in your botnet, and > >>> each one could go at a billion to the second, you still need > >>> 2**69 seconds or 449,235,776,528,695 years. Not bad - only > >>> 10,000 times the amount of time this planet has been around, > >>> so yeah, that's the way they'll attack all right. > >> > >> I didn't say that. I said that they are starting with an IOS image > >> in which there are some small number of bytes which they can > possibly > >> change and still have a functional image. So it is likely that they > >> will brute force that by computing an MD5 hash on all variations of > >> those few bytes. It's like winning the lottery, you only *NEED* to > >> buy one ticket. No matter how slim the chances are of bad guys > winning > >> that lottery, it is no excuse for ignoring the possibility that an > >> MD5 hash check may not be proof that you have an original image. > >> > > Did you even look at Valdis' arithmetic? It *won't work*. It isn't > > "likely" that they'll try anything with that low a chance of success. > > As for "no matter how slim the chances" -- if you want to have even a > > vague chance of succeeding before Sol turns into a red giant, you're > > going to have to devote enormous resources to the project. > (Actually, > > I don't think you can succeed even then, not by brute force -- there > > aren't a "small number of bytes" that can be changed, you can > introduce > > "random" "typographical" errors in error messages for the SNA stack > or > > some such, and if you're doing a brute force pre-image attack on MD5 > any > > bit is as good as any other.) Let's put it purely in economic terms: > > which is a better way to invest your effort, building a machine (or > > botnet) with many billions of processors and still having no > plausible > > chance of winning, or -- as you yourself suggest -- getting the HVAC > > contract for the data center. Or putting back doors in the chips. > Or > > bribing or blackmailing coders. Or breaking into the vault where > Cisco > > keeps its master RSA key. Or funding a vast research effort on > > cracking MD5 before it's replaced by SHA-512. Or *something* even > > vaguely sane, because brute-forcing MD5 isn't physically possible. > > I don't understand how this disucssion got to breaking MD5 to begin > with? > The whole point was that the results will be manipulated due to the > rootkit messing with the test, no? > > Gadi. > > > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3080 bytes Desc: not available URL: From dhetzel at gmail.com Thu May 29 08:18:04 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 29 May 2008 09:18:04 -0400 Subject: amazonaws.com? In-Reply-To: <483EAADF.5040905@bogus.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> Message-ID: <2ee691ff0805290618o82b506fl148afcaa06dd179a@mail.gmail.com> Oh, come on... Businesses buy services every day that have to be paid for by methods like wire transfer. We're not talking about making it the only payment method, just the method for deposits for "risky" services. I wonder what percentage of Amazon E2C customers even want outbound port 25 access anyway. Of those that do want port 25 access, how many are going to wind up being more trouble than they are worth? And it's not really central to this conversation, but I don't think Amazon is in *any* danger with respect to their merchant account, almost no matter what they do :) On Thu, May 29, 2008 at 9:08 AM, Joel Jaeggli wrote: > Dorn Hetzel wrote: > >> There is a really huge difference in the ease with which payment from a >> credit card can be reversed if fraudulent, and the amount of effort >> necessary to reverse a wire transfer. I won't go so far as to say that >> reversing a wire transfer is impossible, but I would claim it's many >> orders >> of magnitude harder than the credit card reversal. >> > > To paraphrase one of my colleagues from the user interaction world: > > "The key to offering a compelling service is minimising > transaction hassles." > > I encourage all my competitors to implement inconvenient hard to use > payment methods.... > > > A mere "court subpoena" wouldn't even be remotely sufficient. The person >> wanting their money back would pretty much have to sue for it and win. >> Heck, people that get scammed and send their money via western union can't >> even get their money back... People who sell physical goods that get >> shipped internationally to places where they can't get them back from have >> been dealing with irrevocable payment forms for a long, long time, and >> those >> are generally wire transfers. >> >> Once that guy in Frackustan has my widgets, I need to make darn sure he >> can't take his money back :) >> >> So, yeah, there would be some customers for whom the couple of business >> hours it take their wire to go through (that's a pretty typical time from >> my >> actual experience) would be longer than they would want to wait for their >> port 25 or other "risky" service to be enabled, but really, how many is >> that >> going to be. We're not talking about the wait for ordinary customers who >> don't need those particular services that tend to be problem children, and >> we're not talking about existing accounts of long standing, just about a >> barrier for the drive-by customer who wants to use services and then not >> pay >> the cost when they violate the AUP... >> >> On Wed, May 28, 2008 at 11:53 PM, Peter Beckman >> wrote: >> >> On Wed, 28 May 2008, Barry Shein wrote: >>> >>> On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: >>> >>>> On Wed, 28 May 2008, Dorn Hetzel wrote: >>>>> >>>>> I would think that simply requiring some appropriate amount of >>>>>> >>>>> irrevocable >>>> >>>>> funds (wire transfer, etc) for a deposit that will be forfeited in the >>>>>> >>>>> case >>>> >>>>> of usage in violation of AUP/contract/etc would be both sufficient and >>>>>> >>>>> not >>>> >>>>> excessive for allowing port 25 access, etc. >>>>>> >>>>> Until you find out that the source of those supposedly irrevocable >>>>> >>>> funds >>>> >>>>> was stolen or fraudulent, and you have some sort of court subpoena to >>>>> >>>> give >>>> >>>>> it back. >>>>> >>>>> I don't believe there is a way for you to outwit the scammer/spammer >>>>> >>>> by >>>> >>>>> making them pay more of their or someone elses money. If you have >>>>> >>>> what >>>> >>>>> they need, they'll find a way to trick you into giving it to them. >>>>> >>>> Are you still trying to prove that Amazon, Dell, The World, etc can't >>>> possibly work? >>>> >>>> Amazon and Dell ship physical goods. Amazon Web Services sells >>> services, >>> as do I. Services are commonly enabled and activated immediately after >>> payment or verification of a valid credit card, as is often expected by >>> the customer immediately after payment. Shipment of physical goods will >>> almost always take at least 24 hours, often longer, enabling more >>> thorough >>> checks of credit, however they might do it. >>> >>> And even with the extra time to review the transaction and attempt to >>> detect fraud, I'm confident Amazon and Dell lose millions per year due >>> to >>> fraud. The reality is that the millions they lose to fraud doesn't >>> affect >>> us because a Blu-Ray player purchased with a stolen credit card doesn't >>> send spam or initiate DOS attacks. >>> >>> At least not yet; those Blu-Ray players do have an ethernet port. >>> >>> By your reasoning why don't the spammers just empty out Amazon's (et >>> >>>> al) warehouses and retire! Oh right, they'd have to sell it all over >>>> the internet which'd mean taking credit cards... >>>> >>>> Now you're just being rediculous. Or sarcastic. :-) >>> >>> I am a big, big fan of assessing charges for AUP abuse and making some >>> >>>> realistic attempt to try to make sure it's collectible, and otherwise >>>> make some attempt to know who you're doing business with. >>>> >>>> Charging whom? The spammer who pays your extra AUP abuse charges with >>> stolen paypal accounts, credit cards, and legit bank accounts funded by >>> money stolen from paypal accounts and transferred from stolen credit >>> cards? >>> >>> If you are taking card-not-present credit card transactions over the >>> Internet or phone, and not shipping physical goods but providing >>> services, >>> in my experience the merchant gets screwed, no matter how much money you >>> might have charged for the privilege of using port 25 or violating AUPs. >>> That money you collected and believed was yours and was in your bank >>> account can be taken out just as easily 6 months later, after the lazy >>> card holder finally reviews his credit card bill, sees unrecognized >>> charges and says "This is fraudulent!" And there you are, without your >>> money. >>> >>> Getting someone to fax their ID in takes extra time and resources, and >>> means it might be hours before you get your account "approved," and for >>> some service providers, part of the value of the service is the >>> immediacy >>> in which a customer can gain new service. >>> >>> >>> Beckman >>> >>> --------------------------------------------------------------------------- >>> Peter Beckman Internet >>> Guy >>> beckman at angryox.com >>> http://www.angryox.com/ >>> >>> --------------------------------------------------------------------------- >>> >>> >>> >> > From dhetzel at gmail.com Thu May 29 08:22:50 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 29 May 2008 09:22:50 -0400 Subject: amazonaws.com? In-Reply-To: <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> Message-ID: <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> Yeah, there was a day when anyone could buy a pickup truck full of ammonium nitrate fertilizer from a random feed store and not attract any attention at all, now, maybe not. Just like port 25, it has plenty of legitimate uses, and some more problematic ones. On Thu, May 29, 2008 at 9:14 AM, Matthew Huff wrote: > The financial services world felt the same pre-9/11. Since then FINRA and > SEC regulations enforce "Know Your Customer" rules that require extensive > record keeping. The regulations now are quite burdensome. Given that usage > of "cloud" resources could be used for DDOS and other illegal activities, I > wonder how long it will take companies to realize that if they don't do a > good job of self policing, the result will be something they would prefer > not to have happen. > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.otaotr.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Thursday, May 29, 2008 9:09 AM > To: Dorn Hetzel > Cc: nanog at nanog.org > Subject: Re: amazonaws.com? > > Dorn Hetzel wrote: > > There is a really huge difference in the ease with which payment from a > > credit card can be reversed if fraudulent, and the amount of effort > > necessary to reverse a wire transfer. I won't go so far as to say that > > reversing a wire transfer is impossible, but I would claim it's many > orders > > of magnitude harder than the credit card reversal. > > To paraphrase one of my colleagues from the user interaction world: > > "The key to offering a compelling service is minimising > transaction hassles." > > I encourage all my competitors to implement inconvenient hard to use > payment methods.... > > > A mere "court subpoena" wouldn't even be remotely sufficient. The person > > wanting their money back would pretty much have to sue for it and win. > > Heck, people that get scammed and send their money via western union > can't > > even get their money back... People who sell physical goods that get > > shipped internationally to places where they can't get them back from > have > > been dealing with irrevocable payment forms for a long, long time, and > those > > are generally wire transfers. > > > > Once that guy in Frackustan has my widgets, I need to make darn sure he > > can't take his money back :) > > > > So, yeah, there would be some customers for whom the couple of business > > hours it take their wire to go through (that's a pretty typical time from > my > > actual experience) would be longer than they would want to wait for their > > port 25 or other "risky" service to be enabled, but really, how many is > that > > going to be. We're not talking about the wait for ordinary customers who > > don't need those particular services that tend to be problem children, > and > > we're not talking about existing accounts of long standing, just about a > > barrier for the drive-by customer who wants to use services and then not > pay > > the cost when they violate the AUP... > > > > On Wed, May 28, 2008 at 11:53 PM, Peter Beckman > wrote: > > > >> On Wed, 28 May 2008, Barry Shein wrote: > >> > >> On May 28, 2008 at 21:43 beckman at angryox.com (Peter Beckman) wrote: > >>>> On Wed, 28 May 2008, Dorn Hetzel wrote: > >>>> > >>>>> I would think that simply requiring some appropriate amount of > >>> irrevocable > >>>>> funds (wire transfer, etc) for a deposit that will be forfeited in > the > >>> case > >>>>> of usage in violation of AUP/contract/etc would be both sufficient > and > >>> not > >>>>> excessive for allowing port 25 access, etc. > >>>> Until you find out that the source of those supposedly irrevocable > >>> funds > >>>> was stolen or fraudulent, and you have some sort of court subpoena > to > >>> give > >>>> it back. > >>>> > >>>> I don't believe there is a way for you to outwit the scammer/spammer > >>> by > >>>> making them pay more of their or someone elses money. If you have > >>> what > >>>> they need, they'll find a way to trick you into giving it to them. > >>> Are you still trying to prove that Amazon, Dell, The World, etc can't > >>> possibly work? > >>> > >> Amazon and Dell ship physical goods. Amazon Web Services sells > services, > >> as do I. Services are commonly enabled and activated immediately after > >> payment or verification of a valid credit card, as is often expected by > >> the customer immediately after payment. Shipment of physical goods > will > >> almost always take at least 24 hours, often longer, enabling more > thorough > >> checks of credit, however they might do it. > >> > >> And even with the extra time to review the transaction and attempt to > >> detect fraud, I'm confident Amazon and Dell lose millions per year due > to > >> fraud. The reality is that the millions they lose to fraud doesn't > affect > >> us because a Blu-Ray player purchased with a stolen credit card doesn't > >> send spam or initiate DOS attacks. > >> > >> At least not yet; those Blu-Ray players do have an ethernet port. > >> > >> By your reasoning why don't the spammers just empty out Amazon's (et > >>> al) warehouses and retire! Oh right, they'd have to sell it all over > >>> the internet which'd mean taking credit cards... > >>> > >> Now you're just being rediculous. Or sarcastic. :-) > >> > >> I am a big, big fan of assessing charges for AUP abuse and making some > >>> realistic attempt to try to make sure it's collectible, and otherwise > >>> make some attempt to know who you're doing business with. > >>> > >> Charging whom? The spammer who pays your extra AUP abuse charges with > >> stolen paypal accounts, credit cards, and legit bank accounts funded by > >> money stolen from paypal accounts and transferred from stolen credit > >> cards? > >> > >> If you are taking card-not-present credit card transactions over the > >> Internet or phone, and not shipping physical goods but providing > services, > >> in my experience the merchant gets screwed, no matter how much money > you > >> might have charged for the privilege of using port 25 or violating > AUPs. > >> That money you collected and believed was yours and was in your bank > >> account can be taken out just as easily 6 months later, after the lazy > >> card holder finally reviews his credit card bill, sees unrecognized > >> charges and says "This is fraudulent!" And there you are, without your > >> money. > >> > >> Getting someone to fax their ID in takes extra time and resources, and > >> means it might be hours before you get your account "approved," and for > >> some service providers, part of the value of the service is the > immediacy > >> in which a customer can gain new service. > >> > >> > >> Beckman > >> > --------------------------------------------------------------------------- > >> Peter Beckman Internet > Guy > >> beckman at angryox.com > >> http://www.angryox.com/ > >> > --------------------------------------------------------------------------- > >> > >> > > > > > From jwise at draga.com Thu May 29 08:37:49 2008 From: jwise at draga.com (Jim Wise) Date: Thu, 29 May 2008 09:37:49 -0400 (EDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 May 2008, Fred Reimer wrote: >plaintext (the IOS code) and the hash. It is not trivial to be able to >make changes in the code and maintain the same hash value, but there has >been at least limited success in doing so. Has there? My understanding is that constructing a new image to match an existing MD5 checksum (vs. constructing two new images with matching MD5 checksums) was still not feasible. Did I miss something? >It may not be possible to replace the boot ROM, because presumably the new >hardware would check the ROM code hash before loading it and also >presumably the ROM code does not have quite as much text messages that can >be changed to generate the same hash value, thereby bypassing the security >checks. This may be an obvious question, but given that the code which verifies an IOS image would (presumably) be part of the boot ROM, where would you put the code which verifies the boot ROM? What does it mean to say `the hardware' should check the boot ROM? - -- Jim Wise jwise at draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFIPrGtq/KRbT0KwbwRArN+AJ0QTuytahkUluOYpCHQ9jw94gNWFQCfTQ5c 2V0w8OO3EnCnJvb3lYh1+sQ= =o9Ro -----END PGP SIGNATURE----- From smb at cs.columbia.edu Thu May 29 08:42:59 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 29 May 2008 09:42:59 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> References: <483BB25A.4030204@securite.org> <79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net> <21778.1211907437@turing-police.cc.vt.edu> <20080527171319.GE2135@skywalker.creative.net.au> <443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com> <28288.1211915246@turing-police.cc.vt.edu> <32648.1211920991@turing-police.cc.vt.edu> <20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> Message-ID: <20080529094259.51dc493e@yellowstone.machshav.com> On Thu, 29 May 2008 09:18:07 -0400 "Fred Reimer" wrote: > So the only easy way to attack this is the MD5 hash. We have a know > plaintext (the IOS code) and the hash. It is not trivial to be able > to make changes in the code and maintain the same hash value, but > there has been at least limited success in doing so. No there has not. There has been considerable success at creating *collisions*; if you don't have a collaborator inside Cisco's build team, that does you no good in this case. There has been *no* success at preimage attacks, which is what we're talking about here. (Aside: I'm on record as saying I wouldn't be surprised if preimage attacks were developed soon by the cryptanalytic community, since people are paying so much more attention to hash functions now, but that hasn't happened yet.) If you do have a collaborator, there is a conceivable attack. Use the collision attack -- that is, the ability to simultaneously produce two files with the same hash -- to generate a genuine IOS image that is nevertheless susceptible to being replaced by a corrupted one. It's a delicate process, though, since even a 1-bit change will completely change the hash output and ruin the collision. You're much better off having your collaborator simply install a back door for you -- and it almost certainly won't be found. See http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb From joelja at bogus.com Thu May 29 08:46:48 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 29 May 2008 06:46:48 -0700 Subject: amazonaws.com? In-Reply-To: <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> Message-ID: <483EB3C8.30301@bogus.com> Dorn Hetzel wrote: > Yeah, there was a day when anyone could buy a pickup truck full of > ammonium nitrate fertilizer from a random feed store and not attract any > attention at all, now, maybe not. Just like port 25, it has plenty of > legitimate uses, and some more problematic ones. Equating port 25 use with domestic terrorism is specious. Ammonium nitrate requires requires some care in handling regardless of your intentions,see for exmple the oppau or texas city disasters. > On Thu, May 29, 2008 at 9:14 AM, Matthew Huff > wrote: > > The financial services world felt the same pre-9/11. Since then > FINRA and SEC regulations enforce "Know Your Customer" rules that > require extensive record keeping. The regulations now are quite > burdensome. Given that usage of "cloud" resources could be used for > DDOS and other illegal activities, I wonder how long it will take > companies to realize that if they don't do a good job of self > policing, the result will be something they would prefer not to have > happen. > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.otaotr.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com ] > Sent: Thursday, May 29, 2008 9:09 AM > To: Dorn Hetzel > Cc: nanog at nanog.org > Subject: Re: amazonaws.com ? > > Dorn Hetzel wrote: > > There is a really huge difference in the ease with which payment > from a > > credit card can be reversed if fraudulent, and the amount of effort > > necessary to reverse a wire transfer. I won't go so far as to say > that > > reversing a wire transfer is impossible, but I would claim it's > many orders > > of magnitude harder than the credit card reversal. > > To paraphrase one of my colleagues from the user interaction world: > > "The key to offering a compelling service is minimising > transaction hassles." > > I encourage all my competitors to implement inconvenient hard to use > payment methods.... > > > A mere "court subpoena" wouldn't even be remotely sufficient. > The person > > wanting their money back would pretty much have to sue for it and > win. > > Heck, people that get scammed and send their money via western > union can't > > even get their money back... People who sell physical goods that get > > shipped internationally to places where they can't get them back > from have > > been dealing with irrevocable payment forms for a long, long > time, and those > > are generally wire transfers. > > > > Once that guy in Frackustan has my widgets, I need to make darn > sure he > > can't take his money back :) > > > > So, yeah, there would be some customers for whom the couple of > business > > hours it take their wire to go through (that's a pretty typical > time from my > > actual experience) would be longer than they would want to wait > for their > > port 25 or other "risky" service to be enabled, but really, how > many is that > > going to be. We're not talking about the wait for ordinary > customers who > > don't need those particular services that tend to be problem > children, and > > we're not talking about existing accounts of long standing, just > about a > > barrier for the drive-by customer who wants to use services and > then not pay > > the cost when they violate the AUP... > > > > On Wed, May 28, 2008 at 11:53 PM, Peter Beckman > > wrote: > > > >> On Wed, 28 May 2008, Barry Shein wrote: > >> > >> On May 28, 2008 at 21:43 beckman at angryox.com > (Peter Beckman) wrote: > >>>> On Wed, 28 May 2008, Dorn Hetzel wrote: > >>>> > >>>>> I would think that simply requiring some appropriate amount of > >>> irrevocable > >>>>> funds (wire transfer, etc) for a deposit that will be > forfeited in the > >>> case > >>>>> of usage in violation of AUP/contract/etc would be both > sufficient and > >>> not > >>>>> excessive for allowing port 25 access, etc. > >>>> Until you find out that the source of those supposedly > irrevocable > >>> funds > >>>> was stolen or fraudulent, and you have some sort of court > subpoena to > >>> give > >>>> it back. > >>>> > >>>> I don't believe there is a way for you to outwit the > scammer/spammer > >>> by > >>>> making them pay more of their or someone elses money. If > you have > >>> what > >>>> they need, they'll find a way to trick you into giving it to > them. > >>> Are you still trying to prove that Amazon, Dell, The World, etc > can't > >>> possibly work? > >>> > >> Amazon and Dell ship physical goods. Amazon Web Services sells > services, > >> as do I. Services are commonly enabled and activated > immediately after > >> payment or verification of a valid credit card, as is often > expected by > >> the customer immediately after payment. Shipment of physical > goods will > >> almost always take at least 24 hours, often longer, enabling > more thorough > >> checks of credit, however they might do it. > >> > >> And even with the extra time to review the transaction and > attempt to > >> detect fraud, I'm confident Amazon and Dell lose millions per > year due to > >> fraud. The reality is that the millions they lose to fraud > doesn't affect > >> us because a Blu-Ray player purchased with a stolen credit card > doesn't > >> send spam or initiate DOS attacks. > >> > >> At least not yet; those Blu-Ray players do have an ethernet port. > >> > >> By your reasoning why don't the spammers just empty out > Amazon's (et > >>> al) warehouses and retire! Oh right, they'd have to sell it all > over > >>> the internet which'd mean taking credit cards... > >>> > >> Now you're just being rediculous. Or sarcastic. :-) > >> > >> I am a big, big fan of assessing charges for AUP abuse and > making some > >>> realistic attempt to try to make sure it's collectible, and > otherwise > >>> make some attempt to know who you're doing business with. > >>> > >> Charging whom? The spammer who pays your extra AUP abuse > charges with > >> stolen paypal accounts, credit cards, and legit bank accounts > funded by > >> money stolen from paypal accounts and transferred from stolen > credit > >> cards? > >> > >> If you are taking card-not-present credit card transactions > over the > >> Internet or phone, and not shipping physical goods but > providing services, > >> in my experience the merchant gets screwed, no matter how much > money you > >> might have charged for the privilege of using port 25 or > violating AUPs. > >> That money you collected and believed was yours and was in your > bank > >> account can be taken out just as easily 6 months later, after > the lazy > >> card holder finally reviews his credit card bill, sees unrecognized > >> charges and says "This is fraudulent!" And there you are, > without your > >> money. > >> > >> Getting someone to fax their ID in takes extra time and > resources, and > >> means it might be hours before you get your account "approved," > and for > >> some service providers, part of the value of the service is the > immediacy > >> in which a customer can gain new service. > >> > >> > >> Beckman > >> > --------------------------------------------------------------------------- > >> Peter Beckman > Internet Guy > >> beckman at angryox.com > >> http://www.angryox.com/ > >> > --------------------------------------------------------------------------- > >> > >> > > > > > From jared at puck.nether.net Thu May 29 08:47:50 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 29 May 2008 09:47:50 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> Message-ID: <5B115146-15BF-4935-A0D1-583A4E4CCD71@puck.nether.net> On May 29, 2008, at 9:37 AM, Jim Wise wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 29 May 2008, Fred Reimer wrote: > >> plaintext (the IOS code) and the hash. It is not trivial to be >> able to >> make changes in the code and maintain the same hash value, but >> there has >> been at least limited success in doing so. > > Has there? My understanding is that constructing a new image to match > an existing MD5 checksum (vs. constructing two new images with > matching > MD5 checksums) was still not feasible. Did I miss something? I think the point here is that most (read: average) consumers don't verify the md5/sha1/gpg/pgp signatures of the binaries they run. If that was the case, we wouldn't have problems quite as bad as we do today. >> It may not be possible to replace the boot ROM, because presumably >> the new >> hardware would check the ROM code hash before loading it and also >> presumably the ROM code does not have quite as much text messages >> that can >> be changed to generate the same hash value, thereby bypassing the >> security >> checks. > > This may be an obvious question, but given that the code which > verifies an > IOS image would (presumably) be part of the boot ROM, where would > you put > the code which verifies the boot ROM? What does it mean to say `the > hardware' should check the boot ROM? I agree with you here. Cisco even ships methods to do a field-upgrade of the rommon on a variety of platforms and linecards. There are numerous challenges when talking about how to prevent these types of updates. I could imagine a case where you leverage the current 'phlashing' stuff to "brick" your router rommon so it won't boot. Once again it gets to the how do you obtain an exploit path to perform these actions on the device? I always have said physical access = "root". Perhaps the path is that oob modem? You need to think about these things, but unless you have a mission dealing with state secrets or your corporate IP (not the protocol) guys treat everything like it is (eg: pharmaceutical companies), you're likely to not notice the router in the closet has a 2 year old bogon filter list installed. - Jared From freimer at ctiusa.com Thu May 29 09:20:44 2008 From: freimer at ctiusa.com (Fred Reimer) Date: Thu, 29 May 2008 10:20:44 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <20080529094259.51dc493e@yellowstone.machshav.com> References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu><98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> <20080529094259.51dc493e@yellowstone.machshav.com> Message-ID: <98B7739FB65BF04F9B3233AB842EEC950297AE2F@EXCHANGE.ctiusa.com> This is not a crypto form, so we shouldn't get deep into the MD5 collision debate, but I didn't say HOW there has been limited success. Sorry if the wording of my message was not clear and implied that all you would need were the plaintext and the hash. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb at cs.columbia.edu] > Sent: Thursday, May 29, 2008 9:43 AM > To: Fred Reimer > Cc: Gadi Evron; nanog at nanog.org > Subject: Re: IOS Rookit: the sky isn't falling (yet) > > On Thu, 29 May 2008 09:18:07 -0400 > "Fred Reimer" wrote: > > > So the only easy way to attack this is the MD5 hash. We have a know > > plaintext (the IOS code) and the hash. It is not trivial to be able > > to make changes in the code and maintain the same hash value, but > > there has been at least limited success in doing so. > > No there has not. There has been considerable success at creating > *collisions*; if you don't have a collaborator inside Cisco's build > team, that does you no good in this case. There has been *no* success > at preimage attacks, which is what we're talking about here. (Aside: > I'm on record as saying I wouldn't be surprised if preimage attacks > were developed soon by the cryptanalytic community, since people are > paying so much more attention to hash functions now, but that hasn't > happened yet.) > > If you do have a collaborator, there is a conceivable attack. Use the > collision attack -- that is, the ability to simultaneously produce two > files with the same hash -- to generate a genuine IOS image that is > nevertheless susceptible to being replaced by a corrupted one. It's a > delicate process, though, since even a 1-bit change will completely > change the hash output and ruin the collision. You're much better off > having your collaborator simply install a back door for you -- and it > almost certainly won't be found. See > http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-136.html or > Chapter 8 of http://zesty.ca/pubs/yee-phd.pdf > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3080 bytes Desc: not available URL: From freimer at ctiusa.com Thu May 29 09:24:50 2008 From: freimer at ctiusa.com (Fred Reimer) Date: Thu, 29 May 2008 10:24:50 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <5B115146-15BF-4935-A0D1-583A4E4CCD71@puck.nether.net> References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> <5B115146-15BF-4935-A0D1-583A4E4CCD71@puck.nether.net> Message-ID: <98B7739FB65BF04F9B3233AB842EEC950297AE32@EXCHANGE.ctiusa.com> The code would presumably be run upon boot from a non-flashable source, which would run the boot ROM code through a check on the crypto chip and only execute it if it passed. You would not put the code that checks the boot ROM on the boot ROM. The new crypto chip would presumably have the initial boot code, which would only be designed to check the boot ROM signature and nothing else so presumably would never need to be replaced and hence would be designed to be non-flashable. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Thursday, May 29, 2008 9:48 AM > To: Jim Wise > Cc: Fred Reimer; nanog at nanog.org > Subject: Re: IOS Rookit: the sky isn't falling (yet) > > > On May 29, 2008, at 9:37 AM, Jim Wise wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thu, 29 May 2008, Fred Reimer wrote: > > > >> plaintext (the IOS code) and the hash. It is not trivial to be > >> able to > >> make changes in the code and maintain the same hash value, but > >> there has > >> been at least limited success in doing so. > > > > Has there? My understanding is that constructing a new image to > match > > an existing MD5 checksum (vs. constructing two new images with > > matching > > MD5 checksums) was still not feasible. Did I miss something? > > I think the point here is that most (read: average) consumers > don't > verify the md5/sha1/gpg/pgp signatures of the binaries they run. If > that was the case, we wouldn't have problems quite as bad as we do > today. > > >> It may not be possible to replace the boot ROM, because presumably > >> the new > >> hardware would check the ROM code hash before loading it and also > >> presumably the ROM code does not have quite as much text messages > >> that can > >> be changed to generate the same hash value, thereby bypassing the > >> security > >> checks. > > > > This may be an obvious question, but given that the code which > > verifies an > > IOS image would (presumably) be part of the boot ROM, where would > > you put > > the code which verifies the boot ROM? What does it mean to say `the > > hardware' should check the boot ROM? > > I agree with you here. Cisco even ships methods to do a field-upgrade > of the rommon on a variety of platforms and linecards. There are > numerous challenges when talking about how to prevent these types of > updates. I could imagine a case where you leverage the current > 'phlashing' stuff to "brick" your router rommon so it won't boot. > Once again it gets to the how do you obtain an exploit path to perform > these actions on the device? I always have said physical access = > "root". Perhaps the path is that oob modem? You need to think about > these things, but unless you have a mission dealing with state secrets > or your corporate IP (not the protocol) guys treat everything like it > is (eg: pharmaceutical companies), you're likely to not notice the > router in the closet has a 2 year old bogon filter list installed. > > - Jared -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3080 bytes Desc: not available URL: From jwise at draga.com Thu May 29 10:10:09 2008 From: jwise at draga.com (Jim Wise) Date: Thu, 29 May 2008 11:10:09 -0400 (EDT) Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <98B7739FB65BF04F9B3233AB842EEC950297AE32@EXCHANGE.ctiusa.com> References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> <5B115146-15BF-4935-A0D1-583A4E4CCD71@puck.nether.net> <98B7739FB65BF04F9B3233AB842EEC950297AE32@EXCHANGE.ctiusa.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 May 2008, Fred Reimer wrote: >The code would presumably be run upon boot from a non-flashable source, >which would run the boot ROM code through a check on the crypto chip and >only execute it if it passed. You would not put the code that checks the >boot ROM on the boot ROM. The new crypto chip would presumably have the >initial boot code, which would only be designed to check the boot ROM >signature and nothing else so presumably would never need to be replaced and >hence would be designed to be non-flashable. Doesn't this just push the chicken-and-egg problem up the chain one step? The ROMMON would be flashable (among other reasons) because the key used to sign IOS releases should change over the years -- gaining length as cycles get cheaper, being replaced periodically to prevent use of the same key for too long, and perhaps being revoked if it should ever be compromised. If the ROMMON is itself to be verified by a prior, non-flashable ROM, then all the same arguments would call for making its key-list updatable -- and given the time-in-service seen by many such devices, any weakness in that key list would be around for quite some time. - -- Jim Wise jwise at draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw 43+1Pq3xWS4MagWzdetZ0ws= =62gJ -----END PGP SIGNATURE----- From freimer at ctiusa.com Thu May 29 10:27:34 2008 From: freimer at ctiusa.com (Fred Reimer) Date: Thu, 29 May 2008 11:27:34 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: References: <483BB25A.4030204@securite.org><79AF9AD3-889F-408D-99FE-902930C402EC@puck.nether.net><21778.1211907437@turing-police.cc.vt.edu><20080527171319.GE2135@skywalker.creative.net.au><443de7ad0805271024o199dc443u6f907eda871433f8@mail.gmail.com><28288.1211915246@turing-police.cc.vt.edu><32648.1211920991@turing-police.cc.vt.edu><20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> <5B115146-15BF-4935-A0D1-583A4E4CCD71@puck.nether.net> <98B7739FB65BF04F9B3233AB842EEC950297AE32@EXCHANGE.ctiusa.com> Message-ID: <98B7739FB65BF04F9B3233AB842EEC950297AEB6@EXCHANGE.ctiusa.com> New keys, to be stored on the crypto chip, would presumably be delivered in a separately signed package using a master key that would not change (embedded within the chip). Maybe Cisco even doesn't have this key, and would need to send a revocation or new public key to be stored on the chip to the chip manufacturer, who would sign it with the master private key and which then could be delivered in a software update to the system. There are many possibilities, and no crypto scheme is foolproof. That much has been proven. But no, you would not make the on-chip EEPROM of the crypto chip "flashable" in the normal meaning of the word. You would send the chip a pointer to a buffer that contains a signed update key, and the chip itself would verify that signature and only then program the updated key(s). My intention was not to turn nanog into a crypto forum. I'd be much more interested in any unique methods that people use to harden their systems that have not already been widely distributed through vendor or industry best practices. Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 > -----Original Message----- > From: Jim Wise [mailto:jwise at draga.com] > Sent: Thursday, May 29, 2008 11:10 AM > To: Fred Reimer > Cc: Jared Mauch; nanog at nanog.org > Subject: RE: IOS Rookit: the sky isn't falling (yet) > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 29 May 2008, Fred Reimer wrote: > > >The code would presumably be run upon boot from a non-flashable > source, > >which would run the boot ROM code through a check on the crypto chip > and > >only execute it if it passed. You would not put the code that checks > the > >boot ROM on the boot ROM. The new crypto chip would presumably have > the > >initial boot code, which would only be designed to check the boot ROM > >signature and nothing else so presumably would never need to be > replaced and > >hence would be designed to be non-flashable. > > Doesn't this just push the chicken-and-egg problem up the chain one > step? > The ROMMON would be flashable (among other reasons) because the key > used to > sign IOS releases should change over the years -- gaining length as > cycles > get cheaper, being replaced periodically to prevent use of the same key > for > too long, and perhaps being revoked if it should ever be compromised. > > If the ROMMON is itself to be verified by a prior, non-flashable ROM, > then > all the same arguments would call for making its key-list updatable -- > and > given the time-in-service seen by many such devices, any weakness in > that > key list would be around for quite some time. > > - -- > Jim Wise > jwise at draga.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (NetBSD) > > iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw > 43+1Pq3xWS4MagWzdetZ0ws= > =62gJ > -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3080 bytes Desc: not available URL: From bzs at world.std.com Thu May 29 10:45:35 2008 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 May 2008 11:45:35 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: <18494.53151.706343.959606@world.std.com> On May 28, 2008 at 23:53 beckman at angryox.com (Peter Beckman) wrote: > > Getting someone to fax their ID in takes extra time and resources, and > means it might be hours before you get your account "approved," and for > some service providers, part of the value of the service is the immediacy > in which a customer can gain new service. Right, which means they're monetizing the risk and cost of damages for the rest of the net. They're selling your resources also (e.g., need for firewalls, bandwidth, cleanup.) That monetization needs to be recognized. If I rented cars to people w/o checking creds to a reasonable standard and those cars were used in the commission of crimes or generated a lot of insurance claims and emergency personnel expenses what would the reaction be? I doubt it would be "...but fast turnaround is that car rental company's competitive advantage! what can they do???" -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From beckman at angryox.com Thu May 29 11:04:15 2008 From: beckman at angryox.com (Peter Beckman) Date: Thu, 29 May 2008 12:04:15 -0400 Subject: amazonaws.com? In-Reply-To: <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> Message-ID: On Thu, 29 May 2008, Dorn Hetzel wrote: > There is a really huge difference in the ease with which payment from a > credit card can be reversed if fraudulent, and the amount of effort > necessary to reverse a wire transfer. A mere "court subpoena" wouldn't > even be remotely sufficient. The person wanting their money back would > pretty much have to sue for it and win. > > So, yeah, there would be some customers for whom the couple of business > hours it take their wire to go through would be longer than they would > want to wait for their port 25 or other "risky" service to be enabled, > but really, how many is that going to be. In the end, all you've done with these "extra" AUP and risk charges is line YOUR (generally, not directed at you Dorn) pockets while the rest of us suffer under the deluge of spam sent from your systems. Which still sucks for the rest of the 'net. I suspect that for Amazon, it is easier and cheaper for them to screw us and allow spam to flow out port 25 unhindered (which costs US money and time) than it is to implement something that makes them a good Internet citizen (which costs AMAZON money and time). Maybe they'll change their stance, but I suspect it is a business decision to not block port 25 and hang out on blacklists, not a good Internet citizen decision. My position from the beginning of this thread is that you cannot AUP this problem away, nor can you just "charge more" and hope THAT will stop it, nor can you simply improve and perfect anti-fraud systems so spammers and fraudsters cannot gain access to your services. It's free to do nothing, and there is a cost of doing something. There are no laws that say what Amazon is doing is illegal, either. You have choices: null route them, blacklist them, get a group together (NANOG?) and group null route Amazon's EC2 IP blocks until they bow to your demands. Being on the 'net means spam, DOS attacks, being slashdotted, dealing with bad Internet citizens, etc. Either you accept those facts, or you should give up and go unplug your connection. With a backhoe, preferably. Much more fun. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From bzs at world.std.com Thu May 29 11:33:14 2008 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 May 2008 12:33:14 -0400 Subject: amazonaws.com? In-Reply-To: <7d6a0cac0805290607t244f342dwe7f7f3788a1eb0b8@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <7d6a0cac0805290607t244f342dwe7f7f3788a1eb0b8@mail.gmail.com> Message-ID: <18494.56010.9219.991915@world.std.com> On May 29, 2008 at 09:07 aiversonlists at spamresource.com (Al Iverson) wrote: > On Wed, May 28, 2008 at 11:08 PM, Barry Shein wrote: > > > I am a big, big fan of assessing charges for AUP abuse and making some > > realistic attempt to try to make sure it's collectible, and otherwise > > make some attempt to know who you're doing business with. > > Just out of curiosity, what stats can you make available as far as: > - How often you assess this AUP abuse fee? > - How often it is successfully collected? > - How successful are chargebacks against that fee? I'll just say we have certainly assessed AUP abuse fees and in most cases collected those fees. The most common fee is a $50 per incident charge for spam complaints after a stern warning or two which depends on frequency, a few per day is very different than one or two per month, and what to do with those phony AOL TOS complaints which almost always mean "I asked to be on this list but I forgot how to get off so maybe if I keep clicking the spam button..."? These are not generally for all-out spamming in our experience. I don't think that's even happened from here in this century. But I've had people who sold services and harvested addresses from, e.g., usenet groups or mailing lists they joined specific to those services (kinda like the router salesman you sometimes hear about on nanog) which generated complaints. They got a lecture and a warning. In a few cases their persistance got them billed, as warned, which usually put a stop to it. One time very early on I remember someone did some more egregious spamming and I shut him down and added a $1500 clean-up fee and he paid it. I was a bit shocked. I've billed a few others like that and of course they just disappeared. One advantage of AUP abuse fees, from a business point of view, is that if you've done your homework (in the AUP, customer clearly warned on first offense, response received) you can then shut them down pending a significant deposit or payment of abuse fees on your terms. You can, e.g., say this is too much for a credit card if you doubt their trustworthiness, credit cards aren't legal tender, and demand some more trustworthy payment method. Let's be frank, once you're pretty sure they're willful spammers you're not losing a lot of sleep over keeping them happy, you're mostly trying to get rid of them unless this is really something they're willing to give up entirely. Should they try to come back at you legally this is a lot more understandable ("I never extended them a credit relationship of $1500 on a $20/mo account!") than just "we didn't like what they were doing with their account". Anyone can understand non-payment, even a court, so claims of "business damages" etc mostly go out the window ("but if it was so important to your business why didn't you just pay the fees??? it was in their AUP, didn't you read it?") Obviously the fees have to be steep enough to discourage even someone who might otherwise be willing to pay the fees. And for the way spammers work that doesn't have to be very high, they mostly shoot for "free" as an overhead goal, even the semi-legitimate types who would claim they're just doing direct email marketing and sell products a little more credible than herbal body enlargement pills. At any rate I'll admit all this begs the zombie bot spammers and others whose businesses are entirely built on crime and fraud but we were talking about computing clouds. As to chargebacks, over almost 20 years we've punched millions of card charges and I'd say the number of chargebacks is small enough that it usually gets mentioned when it happens, "hmm, we had a couple of chargebacks this month", very few, certainly not one a month. We have what I'd call a normal number of "card invalid" (closed, over limit, expiration date wrong, etc.), you get a steady stream of those, but nothing I'd call serious and in most cases gets straightened out with the customer...before someone (as usually happens in these discussions) re-defines those as "chargebacks" and uses the redefinition to question my credibility/sanity. By chargebacks I mean a disputed charge, they're clearly distinguished in your merchant acct from just "bad" cards. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Thu May 29 11:38:43 2008 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 May 2008 12:38:43 -0400 Subject: amazonaws.com? In-Reply-To: <483EAADF.5040905@bogus.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> Message-ID: <18494.56339.763165.217906@world.std.com> On May 29, 2008 at 06:08 joelja at bogus.com (Joel Jaeggli) wrote: > > To paraphrase one of my colleagues from the user interaction world: > > "The key to offering a compelling service is minimising > transaction hassles." > > I encourage all my competitors to implement inconvenient hard to use > payment methods.... One way of describing it is "minimizing transaction hassles". Another way of describing it is "monetizing others' hassles", let them spend on bandwidth, firewalls, personnel, etc, to deal with my customers' spamming. That's the arbitrage we're currently deaing with. But you're right, there was no good reason for tobacco companies to concern themselves with the cost of health effects of their products for many, many years, it wasn't their problem. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Thu May 29 11:44:47 2008 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 May 2008 12:44:47 -0400 Subject: amazonaws.com? In-Reply-To: <483EB3C8.30301@bogus.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> <483EB3C8.30301@bogus.com> Message-ID: <18494.56703.315361.140476@world.std.com> On May 29, 2008 at 06:46 joelja at bogus.com (Joel Jaeggli) wrote: > Dorn Hetzel wrote: > > Yeah, there was a day when anyone could buy a pickup truck full of > > ammonium nitrate fertilizer from a random feed store and not attract any > > attention at all, now, maybe not. Just like port 25, it has plenty of > > legitimate uses, and some more problematic ones. > > Equating port 25 use with domestic terrorism is specious. > > Ammonium nitrate requires requires some care in handling regardless of > your intentions,see for exmple the oppau or texas city disasters. And how different is that from the million+ strong zombie botnets? Who owns (not pwns) those zombie'd systems and what were their intentions? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lsc at prgmr.com Thu May 29 13:07:05 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 29 May 2008 14:07:05 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: Peter Beckman writes: > If you are taking card-not-present credit card transactions over the ...snip "hard to charge fradulent customers" and also "verifying customer identity annoys the customer"... points- The goal here is to give abuse a negative expected return. One way to do this is to charge (and collect) a fee that is greater than what the spammer can earn between when they sign up and when you shut then down. There are two ways to do this - 1. raise (and collect) the abuse fee, or 2. lower the amount they can earn before you shut them down. I am suggesting that we put some effort into 2- If we can reduce the amount of time between when a spammer signs up and when they are shut down, we raise the spammer's costs. I think there is low-hanging fruit in this area. I believe that the 'strongly authenticate customer, then take legal action' model is dictated by the fact that most abuse incidents are not actually reported to your abuse desk- some abusive customers can go days or weeks before you receive a complaint. to give abuse a negative expected return, then, you need to make the consequence expensive. (to say nothing of covering the costs of trying to get good logs/evidence out of those who are complaining, or trying to figure out if your customer is a spammer or if your customer was owned by a spammer, and the costs of collecting the fee.) I wanted to point out another option providers now have. IDS technology has matured. Snort is free and pretty standard. Personally, I find monitoring incoming traffic to be... of limited utility. However, I believe snort is an excellent tool for lowering the cost of running an abuse desk, if you run it on the outgoing traffic. Snort is pretty good about alerting you to outgoing abuse before people complain. Heck, if you trust it, you can have it automatically shut down the abusive customers. From joelja at bogus.com Thu May 29 13:10:40 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 29 May 2008 11:10:40 -0700 Subject: amazonaws.com? In-Reply-To: <18494.56703.315361.140476@world.std.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> <483EB3C8.30301@bogus.com> <18494.56703.315361.140476@world.std.com> Message-ID: <483EF1A0.9080103@bogus.com> Barry Shein wrote: > On May 29, 2008 at 06:46 joelja at bogus.com (Joel Jaeggli) wrote: > > Dorn Hetzel wrote: > > > Yeah, there was a day when anyone could buy a pickup truck full of > > > ammonium nitrate fertilizer from a random feed store and not attract any > > > attention at all, now, maybe not. Just like port 25, it has plenty of > > > legitimate uses, and some more problematic ones. > > > > Equating port 25 use with domestic terrorism is specious. > > > > Ammonium nitrate requires requires some care in handling regardless of > > your intentions,see for exmple the oppau or texas city disasters. > > And how different is that from the million+ strong zombie botnets? Who > owns (not pwns) those zombie'd systems and what were their intentions? Well let's see. The texas city disaster is/was considered the worst industrial accident in american history. 581 people killed by an explosive yield of about 2 kilotons. The secondary effects includes fires in many of the chemical facilities in Galveston and a swath of destruction that reached up to 40 miles inland... http://www.local1259iaff.org/disaster.html So no, I don't think internet attached hosts can casually equated with the destructive potential of a pile of fertilizer at least not in the context described. From beckman at angryox.com Thu May 29 13:46:15 2008 From: beckman at angryox.com (Peter Beckman) Date: Thu, 29 May 2008 14:46:15 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: On Thu, 29 May 2008, Luke S Crawford wrote: > Peter Beckman writes: > >> If you are taking card-not-present credit card transactions over the > ...snip "hard to charge fradulent customers" and also "verifying customer > identity annoys the customer"... points- > > The goal here is to give abuse a negative expected return. One way to do > this is to charge (and collect) a fee that is greater than what the > spammer can earn between when they sign up and when you shut then down. > There are two ways to do this - 1. raise (and collect) the abuse fee, or > 2. lower the amount they can earn before you shut them down. All these charges do is line the coffers. Sure, a few might be prevented from doing it in the first place, but the rest will continue, and everyone else here, including Barry, will continue to get hit by spam and DOS and backscatter. > I wanted to point out another option providers now have. IDS technology > has matured. Snort is free and pretty standard. Personally, I find > monitoring incoming traffic to be... of limited utility. However, > I believe snort is an excellent tool for lowering the cost of running an > abuse desk, if you run it on the outgoing traffic. Snort is pretty good > about alerting you to outgoing abuse before people complain. Heck, if you > trust it, you can have it automatically shut down the abusive customers. This is what I think we should ALL be doing -- monitoring our own network to make sure we aren't the source, via customers, of the spam or DOS attacks. All outbound email from your own network should be scanned by some sort of best-practice system before delivery to prevent or limit spam from originating on your network. IMO. But let's be realistic -- the reality is that not everyone does, due to financial or resource or management constraints, and that receiving spam and being hit by DOS attacks and being slashdotted is simply part of the cost of being on the 'net. Profiting MORE from those that proliferate these attacks may hurt you less in the bottom line, but it still hurts everyone else who is the target of the attacks enabled by high AUP abuse fees. I know I'd be just as ticked off about a spam attack from Amazon EC2, whether or not Amazon got paid extra to enable it. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From bzs at world.std.com Thu May 29 14:19:22 2008 From: bzs at world.std.com (Barry Shein) Date: Thu, 29 May 2008 15:19:22 -0400 Subject: amazonaws.com? In-Reply-To: <483EF1A0.9080103@bogus.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> <483EB3C8.30301@bogus.com> <18494.56703.315361.140476@world.std.com> <483EF1A0.9080103@bogus.com> Message-ID: <18495.442.593611.855414@world.std.com> What I really, really, (really), don't understand is what is this perverse urge to argue incessantly that spam and related do little or no harm, are of little consequence, and nothing can be done about it anyhow? You'd think we were discussing ways to prevent hurricanes (and some won't even accept that there's no answer to those!) I realize there's a little bit of one-upsmanship to just beating a hopeless point to death (ok, fine, huge ammonium nitrate explosions which level entire cities are worse than million+ zombie bot armies, and superman can beat up the hulk, etc.) Zombie bot armies et al do cause probably billions of dollars in damages (e.g., equipment and personnel to deal with them not to mention lost productivity by end users), undermine trust, etc. But don't you ever stop to consider where your collective bread is buttered before you give the public and quotable impression as professionals that whether or not spam, phishing et al are bad is debateable, like we were arguing creationism vs. evolution, that there's no point in even trying to curb it, that credit cards can't possibly work, etc? It's one thing to give an idea a proper vetting, it's something else to work backwards from the assumption that nothing can possibly be done and just use reasoning like "I can think of something even worse, so therefore it's not so bad", or "fraud has occurred in credit card transactions, therefore credit cards cannot be viable." On May 29, 2008 at 11:10 joelja at bogus.com (Joel Jaeggli) wrote: > Barry Shein wrote: > > On May 29, 2008 at 06:46 joelja at bogus.com (Joel Jaeggli) wrote: > > > Dorn Hetzel wrote: > > > > Yeah, there was a day when anyone could buy a pickup truck full of > > > > ammonium nitrate fertilizer from a random feed store and not attract any > > > > attention at all, now, maybe not. Just like port 25, it has plenty of > > > > legitimate uses, and some more problematic ones. > > > > > > Equating port 25 use with domestic terrorism is specious. > > > > > > Ammonium nitrate requires requires some care in handling regardless of > > > your intentions,see for exmple the oppau or texas city disasters. > > > > And how different is that from the million+ strong zombie botnets? Who > > owns (not pwns) those zombie'd systems and what were their intentions? > > Well let's see. The texas city disaster is/was considered the worst > industrial accident in american history. 581 people killed by an > explosive yield of about 2 kilotons. The secondary effects includes > fires in many of the chemical facilities in Galveston and a swath of > destruction that reached up to 40 miles inland... > > http://www.local1259iaff.org/disaster.html > > So no, I don't think internet attached hosts can casually equated with > the destructive potential of a pile of fertilizer at least not in the > context described. > -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From leslien at arin.net Thu May 29 14:39:53 2008 From: leslien at arin.net (Leslie Nobile) Date: Thu, 29 May 2008 15:39:53 -0400 Subject: APNIC receives 112 /8 and 113 /8 Message-ID: Forwarding this email on behalf of APNIC... ________________________________________________________________________ New IPv4 allocation for APNIC (112/8 and 113/8) ________________________________________________________________________ Dear colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in May 2008 and will be making allocations from these ranges in the near future: 112/8 113/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Kind regards, ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________ From up at 3.am Thu May 29 14:58:35 2008 From: up at 3.am (up at 3.am) Date: Thu, 29 May 2008 15:58:35 -0400 (EDT) Subject: Update was Re: [NANOG] Level3 not honoring Broadwing contracts? In-Reply-To: References: Message-ID: Update to below (sorry for top-post, but not everone needs to read the original post). Thanks in part to the pro-bono efforts of two very good attorneys: Nachman Yaakov Ziskind, (awacs at ziskind.us) (nanog list member who kindly emailed me when I sent this to the list) and my father in law, Level 3 has acknowledged that my contract is still in term and will honor their contract until it expires in August of 2009. The contract has a provision for paying only the undisputed portion of disputed invoices, provided formal notice is given, so I followed it and CC'd the director of colo services who sent me the original letter of intent to raise my pricing, along with Mr. Ziskind's letter and it got taken care of. Thank you to everyone who responded to this last month. If anybody else is having similar issues and would like more information, please don't hesitate to contact me off-list. On Mon, 28 Apr 2008, up at 3.am wrote: > > In 2006, I signed a 3 year contract with Broadwing for a 1 cabinet > colocation with 6Mbs dedicated for under $1,000/mo. A few weeks ago, > about halfway through this contract, I get a letter from Level 3's > "Director of Colocation" that they are going to raise my price by several > hundred dollars a month. > > I spoke with my new Level 3 rep, and he just notified me that their legal > deparment confirms that all they have to do is give me 30 days notice to > increase their price. > > This does not make sense to me. I am bound to a 3 year contract, where I > have to pay them the rest of the term if I were to leave early, but they > can jack up the price by 40-50% during that time, arbitrarily? I do not > see that provision in my contract, and would rather avoid legal expenses > if possible. Has anyone else had to deal with this sort of thing from > Level 3? > > TIA, > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up at 3.am http://3.am > ========================================================================= > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From lists at internetpolicyagency.com Thu May 29 12:00:44 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Thu, 29 May 2008 18:00:44 +0100 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: References: Message-ID: In article , michael.dillon at bt.com writes >> The official spokespeople don't mention it, but there is also >> a tendency for local officials to divert fuel delivery trucks >> for their use instead of maintaining communication facilities. > >How much fuel can you legally carry in drums inside the trucks that >your company already has with your logo on it? Is it logistically >feasible to resupply your sites using such vehicles? Briefly, you also need permission for those trucks to be moving inside the cordons. What you need to know who to ask to get that permission, and why they should believe your business case. -- Roland Perry From lsc at prgmr.com Thu May 29 15:38:14 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 29 May 2008 16:38:14 -0400 Subject: amazonaws.com? In-Reply-To: References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> Message-ID: Peter Beckman writes: ...snip "use snort" suggestion.... > This is what I think we should ALL be doing -- monitoring our own network > to make sure we aren't the source, via customers, of the spam or DOS > attacks. All outbound email from your own network should be scanned by > some sort of best-practice system before delivery to prevent or limit spam > from originating on your network. IMO. > But let's be realistic -- the reality is that not everyone does, due to > financial or resource or management constraints I believe that in the case of a VPS provider like ec2, monitoring outgoing traffic with an IDS is cheaper than not monitoring it. Abuse reports are expensive to process. You need people with both social and technical skills on your end, people with social and technical skills who are willing to do what amounts to technical support. Often the abuse reports are vague, requiring back-and-fourth. Even if your IDS only catches a small percentage of the abuse-generating complaints (and I bet the IDS can get a large percentage of the complaint-generating abuse- it takes a lot of abuse to generate a complaint) you are saving a lot of money on abuse desk services. Heck, I bet just the ability to search IDS logs after a abuse report would pay for the IDS. From joelja at bogus.com Thu May 29 15:48:38 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 29 May 2008 13:48:38 -0700 Subject: amazonaws.com? In-Reply-To: <18495.442.593611.855414@world.std.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> <483EB3C8.30301@bogus.com> <18494.56703.315361.140476@world.std.com> <483EF1A0.9080103@bogus.com> <18495.442.593611.855414@world.std.com> Message-ID: <483F16A6.7080708@bogus.com> Barry Shein wrote: > What I really, really, (really), don't understand is what is this > perverse urge to argue incessantly that spam and related do little or > no harm, are of little consequence, and nothing can be done about it > anyhow? You'd think we were discussing ways to prevent hurricanes (and > some won't even accept that there's no answer to those!) > > I realize there's a little bit of one-upsmanship to just beating a > hopeless point to death (ok, fine, huge ammonium nitrate explosions > which level entire cities are worse than million+ zombie bot armies, > and superman can beat up the hulk, etc.) So don't use bad analogies... Describe the scope of the possible harm you envision. > Zombie bot armies et al do cause probably billions of dollars in > damages (e.g., equipment and personnel to deal with them not to > mention lost productivity by end users), undermine trust, etc. > > But don't you ever stop to consider where your collective bread is > buttered before you give the public and quotable impression as > professionals that whether or not spam, phishing et al are bad is > debateable, like we were arguing creationism vs. evolution, that > there's no point in even trying to curb it, that credit cards can't > possibly work, etc? The fact that is criminal enterprise is undesirable is not a subject of much debate. I object to the notion the destruction of life and property are suitably analogous to spam, fraud, theft of resource and denial of service. They aren't. One is at risk of minimizing the suffering of the victims of the former by equating them with the later. > It's one thing to give an idea a proper vetting, it's something else > to work backwards from the assumption that nothing can possibly be > done and just use reasoning like "I can think of something even worse, > so therefore it's not so bad", or "fraud has occurred in credit card > transactions, therefore credit cards cannot be viable." I don't think there's any evidence of me assuming that. The potential for abuse is not a prima facie reason not to do something. Large successful parts of our economy as well as the basic human condition are devoted to the business of managing opportunity vs risk and the mitigation of the later where possible. > On May 29, 2008 at 11:10 joelja at bogus.com (Joel Jaeggli) wrote: > > Barry Shein wrote: > > > On May 29, 2008 at 06:46 joelja at bogus.com (Joel Jaeggli) wrote: > > > > Dorn Hetzel wrote: > > > > > Yeah, there was a day when anyone could buy a pickup truck full of > > > > > ammonium nitrate fertilizer from a random feed store and not attract any > > > > > attention at all, now, maybe not. Just like port 25, it has plenty of > > > > > legitimate uses, and some more problematic ones. > > > > > > > > Equating port 25 use with domestic terrorism is specious. > > > > > > > > Ammonium nitrate requires requires some care in handling regardless of > > > > your intentions,see for exmple the oppau or texas city disasters. > > > > > > And how different is that from the million+ strong zombie botnets? Who > > > owns (not pwns) those zombie'd systems and what were their intentions? > > > > Well let's see. The texas city disaster is/was considered the worst > > industrial accident in american history. 581 people killed by an > > explosive yield of about 2 kilotons. The secondary effects includes > > fires in many of the chemical facilities in Galveston and a swath of > > destruction that reached up to 40 miles inland... > > > > http://www.local1259iaff.org/disaster.html > > > > So no, I don't think internet attached hosts can casually equated with > > the destructive potential of a pile of fertilizer at least not in the > > context described. > > > From bburke at merit.edu Thu May 29 16:01:33 2008 From: bburke at merit.edu (Betty J. Burke) Date: Thu, 29 May 2008 17:01:33 -0400 Subject: [NANOG-announce] NANOG43 Reminder Message-ID: Dear NANOG Community-- We are looking forward to seeing those who plan to attend NANOG43 at the New York Marriott at the Brooklyn Bridge in Brooklyn on Sunday. We expect excellent attendance, with almost 400 registered attendees to date. Some important highlights for those still considering attending and a reminder that registration is required to attend any of the NANOG events. Registration Fees ----------------- Through 5-30-08 Registration Fee is @$525 Late and On-Site Registration Fee is @$600 Agenda ------ The agenda is complete and available at: http://www.nanog.org/mtg-0806/agenda.html Community meeting ----------------- An important part of every NANOG meeting!! NANOG43 Community Meeting is scheduled for 5:30-6:30 p.m. on Sunday. Social gatherings ----------------- Monday, June 2, 6:00 PM ? 8:00 PM Tuesday, June 3, 6:00 p.m. ? 9:00 p.m. Wednesday, June 4, 7:00 p.m. ? 11:00 p.m. As always, feel free to email NANOG-Support at nanog.org with any questions. --Merit Network - NANOG Registration & Support _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From jonathanheinlein at gmail.com Thu May 29 17:39:34 2008 From: jonathanheinlein at gmail.com (Jonathan Heinlein) Date: Thu, 29 May 2008 18:39:34 -0400 Subject: New ID: Special Use IPv4 Addresses In-Reply-To: References: Message-ID: Link change? http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-02.txt On Wed, May 28, 2008 at 3:12 PM, Sean Donelan wrote: > > http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-01.txt > > Other than a formatting error in the header ("IPv4 Multicast Guidelines") > instead of ("Special Use IPv4 Addresses"), the only significant change > appears to be removing the "Reserved" status of the old Classfull boundary > networks. The former boundary networks are now subject to allocation like > any other unicast IPv4 address space. > > Host, Router vendors and Network Operators should have already been testing > their equipment for proper handling (i.e. not doing anything different) of > these network addresses. So this ID should just be a minor IANA > administrative cleanup. > > > From Crist.Clark at globalstar.com Thu May 29 18:22:35 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Thu, 29 May 2008 16:22:35 -0700 Subject: Comcast Users, Time to Change Your Password Message-ID: <483ED84A.8C45.0097.0@globalstar.com> I'm getting "connection refused" from Comcast's POP3 servers, mail.comcast.net. Related to this? http://www.theregister.co.uk/2008/05/29/comcast_domain_hijacked/ Oh, NetSol... Comcast.... Let the finger pointing begin. -- Crist J. Clark crist.clark at globalstar.com Globalstar Communications (408) 933-4387 B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.com From sean at donelan.com Thu May 29 18:24:40 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 29 May 2008 19:24:40 -0400 (EDT) Subject: New ID: Special Use IPv4 Addresses In-Reply-To: References: Message-ID: The header was corrected an hour or so after my original message, and a revised internet-draft (02) was published. On Thu, 29 May 2008, Jonathan Heinlein wrote: > Link change? > > http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-02.txt > > On Wed, May 28, 2008 at 3:12 PM, Sean Donelan wrote: > >> >> http://www.ietf.org/internet-drafts/draft-iana-rfc3330bis-01.txt >> >> Other than a formatting error in the header ("IPv4 Multicast Guidelines") >> instead of ("Special Use IPv4 Addresses"), the only significant change >> appears to be removing the "Reserved" status of the old Classfull boundary >> networks. The former boundary networks are now subject to allocation like >> any other unicast IPv4 address space. >> >> Host, Router vendors and Network Operators should have already been testing >> their equipment for proper handling (i.e. not doing anything different) of >> these network addresses. So this ID should just be a minor IANA >> administrative cleanup. From nanog at ian.co.uk Thu May 29 18:41:44 2008 From: nanog at ian.co.uk (Ian Mason) Date: Fri, 30 May 2008 00:41:44 +0100 Subject: Hurricane season starts June 1: Carriers harden networks In-Reply-To: References: Message-ID: <37FEF3BA-C324-49ED-B5CB-FA6DB2021C32@ian.co.uk> On 27 May 2008, at 22:18, Sean Donelan wrote: > > The official spokespeople don't mention it, but there is also a > tendency for local officials to divert fuel delivery trucks for > their use instead > of maintaining communication facilities. > > Some years ago we managed to get the UK government emergency planning folks to actually factor this into their plans so that communications fuel supplies get adequate priority. In fact we even planned for some highly unlikely contingencies. Fortunately we haven't yet had a chance to find out if this planning actually works out in practice. Ian From nanog at ian.co.uk Thu May 29 18:51:21 2008 From: nanog at ian.co.uk (Ian Mason) Date: Fri, 30 May 2008 00:51:21 +0100 Subject: amazonaws.com? In-Reply-To: <200805271533.m4RFXsI8024116@mail.r-bonomi.com> References: <200805271533.m4RFXsI8024116@mail.r-bonomi.com> Message-ID: <8BC6C5BE-A14F-4A76-BA09-7F2E9C334AE5@ian.co.uk> On 27 May 2008, at 16:33, Robert Bonomi wrote: >> From nanog-bounces at nanog.org Mon May 26 21:16:58 2008 >> Date: Tue, 27 May 2008 07:46:26 +0530 >> From: "Suresh Ramasubramanian" >> To: "Colin Alston" >> Subject: Re: amazonaws.com? >> Cc: nanog at merit.edu >> >> On Tue, May 27, 2008 at 1:10 AM, Colin Alston >> wrote: >>> On 26/05/2008 18:13 Suresh Ramasubramanian wrote: >>>> >> >> I didnt actually, Bonomi did .. but going on .. > > Mis-credit where mis-credit isn't due ... Twasn't me, either. > > I just commented that I couldn't think of a reason for a _compute_ > cluster to > need access to unlimited remote machines/ports. And that it could > 'trivially' > be made an _automatic_ part of the 'compute session' config -- to > allow access > to a laundry-list of ports/machines, and those ports/machines -only-. > > If Amazon were a 'good neighbor', they _would_ implement something > like this. > That they see no need to do _anything_ -- when _actual_ problems, > which are > directly attributable to their failure to do so, have been brought > to their > attention -- does argue in favor of wholesale firewalling of the > EC2 address- > space. > > If the address-space owner won't police it's own property, there is > no reason > for the rest of the world to spend the time/effort to _selectively_ > police it > for them. > > Amazon _might_ 'get a clue' if enough providers walled off the EC2 > space, and > they found difficulty selling cycles to people who couldn't access > the machines > to set up their compute applications. This is a classic example of externalities in the economics of security. Currently, any damage caused by Amazon customers costs Amazon little or nothing. The costs are borne by the victims of that damage. On the other hand mitigating this damage would cause Amazon costs, in engineering and lost revenue. So in economic terms they have no incentive to 'do the right thing'. So to get Amazon to police their customers either requires regulation or an external economic pressure. Blocking AWS from folk's mail servers would apply some pressure, making areas of the net go dark to AWS would apply more pressure faster. A considerable amount of pressure could be placed by a big enough money damages lawsuit but that has a feedback delay of months to years. From vixie at isc.org Thu May 29 19:49:09 2008 From: vixie at isc.org (Paul Vixie) Date: 30 May 2008 00:49:09 +0000 Subject: amazonaws.com? In-Reply-To: <8BC6C5BE-A14F-4A76-BA09-7F2E9C334AE5@ian.co.uk> References: <8BC6C5BE-A14F-4A76-BA09-7F2E9C334AE5@ian.co.uk> Message-ID: nanog at ian.co.uk (Ian Mason) writes: > On 27 May 2008, at 16:33, Robert Bonomi wrote: > > > Amazon _might_ 'get a clue' if enough providers walled off the EC2 > > space, and they found difficulty selling cycles to people who couldn't > > access the machines to set up their compute applications. > > This is a classic example of externalities in the economics of security. > > Currently, any damage caused by Amazon customers costs Amazon little or > nothing. The costs are borne by the victims of that damage. On the other > hand mitigating this damage would cause Amazon costs, in engineering and > lost revenue. So in economic terms they have no incentive to 'do the > right thing'. i've heard this called "the chemical polluter business model". > So to get Amazon to police their customers either requires regulation or > an external economic pressure. Blocking AWS from folk's mail servers > would apply some pressure, making areas of the net go dark to AWS would > apply more pressure faster. A considerable amount of pressure could be > placed by a big enough money damages lawsuit but that has a feedback > delay of months to years. to that end, i don't accept e-mail from any free e-mail provider, including gmail, nor from most ISP mail servers. all of them face this same economics decision, and all of them end up spewing quite a bit of spam, and there's no end in sight. e-mail sourcing doesn't scale. the highest quality e-mail comes from the smallest communities. EC2 will probably face some boycotts. i don't think these will change the endgame, whatever it is. -- Paul Vixie From ml at t-b-o-h.net Thu May 29 20:55:00 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 29 May 2008 21:55:00 -0400 (EDT) Subject: L3/RR "incident" (Previously Network meltdowns anywhere in US?) Message-ID: <200805300155.m4U1t0O0014170@himinbjorg.tucs-beachin-obx-house.com> Hi, Another case of getting much better help via NANOG than through a NOC. Turns out there was an issue, and it subsequently was fixed in a relatively small timeframe. Atleast a /20 of RR was not visible inside of L3, I'm not sure if it was more. Thanks again to those people from L3 that DID help me who are on this list. Tuc/TBOH From ops.lists at gmail.com Thu May 29 22:11:35 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 30 May 2008 08:41:35 +0530 Subject: amazonaws.com? In-Reply-To: <18494.56010.9219.991915@world.std.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <7d6a0cac0805290607t244f342dwe7f7f3788a1eb0b8@mail.gmail.com> <18494.56010.9219.991915@world.std.com> Message-ID: On Thu, May 29, 2008 at 10:03 PM, Barry Shein wrote: > The most common fee is a $50 per incident charge for spam complaints > after a stern warning or two which depends on frequency, a few per day > is very different than one or two per month, and what to do with those > phony AOL TOS complaints which almost always mean "I asked to be on > this list but I forgot how to get off so maybe if I keep clicking the > spam button..."? You run a botique provider of shells that - at least today - almost exclusively caters to geeks. You arent as likely to pick up genuinely badhat spamming customers as the rest of us large ISPs are - and the large colo farms (he.net, softlayer etc) are even more vulnerable to this kind of thing. Feedback loops (such as those AOL provide, or we provide - and we were the second ISP after AOL to offer ARF'd feedback loops) are about the best tool any ISP has available to it, to get near real time spam reports. You're a corner case. And an opinionated corner case at that. That doesnt change just how useful FBLs are to the vast majority of consumer ISPs out there. --srs From michael.dillon at bt.com Fri May 30 02:57:05 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 30 May 2008 08:57:05 +0100 Subject: amazonaws.com? In-Reply-To: <8BC6C5BE-A14F-4A76-BA09-7F2E9C334AE5@ian.co.uk> References: <200805271533.m4RFXsI8024116@mail.r-bonomi.com> <8BC6C5BE-A14F-4A76-BA09-7F2E9C334AE5@ian.co.uk> Message-ID: > So to get Amazon to police their customers either requires > regulation or an external economic pressure. Blocking AWS > from folk's mail servers would apply some pressure, No it would not. That is what AWS wants you to to. > making > areas of the net go dark to AWS would apply more pressure > faster. A considerable amount of pressure could be placed by > a big enough money damages lawsuit but that has a feedback > delay of months to years. And such lawsuits can go both ways. As soon as a company moves beyond protective blocking of port 25, to punitive blocking of all traffic from AWS, they run the risk of being the target of a damages lawsuit. Not to mention complaints from their own customers. There simply is no simple solution to this problem. --Michael Dillon From rs at seastrom.com Fri May 30 06:45:50 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 30 May 2008 07:45:50 -0400 Subject: amazonaws.com? In-Reply-To: <483F16A6.7080708@bogus.com> (Joel Jaeggli's message of "Thu, 29 May 2008 13:48:38 -0700") References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> <483EB3C8.30301@bogus.com> <18494.56703.315361.140476@world.std.com> <483EF1A0.9080103@bogus.com> <18495.442.593611.855414@world.std.com> <483F16A6.7080708@bogus.com> Message-ID: <86zlq8t3pt.fsf@seastrom.com> I'm not on the MLC (which doesn't have any community representatives on it at present) anymore. Nonetheless, I implore everyone to consider this thread dead. It's run far enough afield on speculation and analogies that I for one think it's fairly out of scope. Thanks, ---Rob From cidr-report at potaroo.net Fri May 30 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 May 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200805301200.m4UC04wl014818@wattle.apnic.net> BGP Update Report Interval: 28-Apr-08 -to- 29-May-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15169 316375 2.7% 2378.8 -- GOOGLE - Google Inc. 2 - AS4538 136309 1.2% 27.7 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS6140 96355 0.8% 106.2 -- IMPSAT-USA - ImpSat USA, Inc. 4 - AS9498 83516 0.7% 67.0 -- BBIL-AP BHARTI BT INTERNET LTD. 5 - AS22773 74090 0.6% 36.1 -- CCINET-2 - Cox Communications Inc. 6 - AS2386 65395 0.6% 44.7 -- INS-AS - AT&T Data Communications Services 7 - AS17974 64506 0.6% 139.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS9583 61158 0.5% 50.7 -- SIFY-AS-IN Sify Limited 9 - AS9198 55489 0.5% 111.4 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - AS7011 54916 0.5% 48.9 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 11 - AS6517 51873 0.5% 76.4 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 12 - AS4755 49493 0.4% 29.9 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 13 - AS8151 48301 0.4% 38.7 -- Uninet S.A. de C.V. 14 - AS6389 46761 0.4% 23.0 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 15 - AS6478 44190 0.4% 44.9 -- ATT-INTERNET3 - AT&T WorldNet Services 16 - AS11492 44091 0.4% 35.8 -- CABLEONE - CABLE ONE 17 - AS17488 43143 0.4% 37.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 18 - AS7018 42048 0.4% 28.7 -- ATT-INTERNET4 - AT&T WorldNet Services 19 - AS24731 41096 0.4% 513.7 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - AS6298 41052 0.3% 53.0 -- COX-PHX - Cox Communications Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26829 33281 0.3% 33281.0 -- YKK-USA - YKK USA,INC 2 - AS17834 12211 0.1% 12211.0 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 3 - AS42787 35901 0.3% 11967.0 -- MMIP-AS MultiMedia IP Ltd. 4 - AS28646 7141 0.1% 7141.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 5 - AS36384 18882 0.2% 6294.0 -- GOOGLE-IT - Google Incorporated 6 - AS30929 5091 0.0% 5091.0 -- HUTCB Hidrotechnical Faculty - Technical University 7 - AS40359 3964 0.0% 3964.0 -- SOUTHEASTERNMILLS-ROME - Southeastern Mills, Inc. 8 - AS35324 3748 0.0% 3748.0 -- ECH-WILL-AS E.C.H. Will 9 - AS16466 17907 0.1% 3581.4 -- AVAYA AVAYA 10 - AS32996 3451 0.0% 3451.0 -- AGRIBANK-STPAUL - AgriBank, FCB 11 - AS23082 17085 0.1% 3417.0 -- MPHI - Michigan Public Health Institute 12 - AS29910 3027 0.0% 3027.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 13 - AS9122 2995 0.0% 2995.0 -- TECHNOELECTROSERVIS-AS Technoelektroservis Ltd. 14 - AS10551 5605 0.1% 2802.5 -- RAPID-CITY-REGIONAL - Rapid City Regional Hospital 15 - AS34378 2703 0.0% 2703.0 -- RUG-AS Razgulay Group 16 - AS15169 316375 2.7% 2378.8 -- GOOGLE - Google Inc. 17 - AS44730 2286 0.0% 2286.0 -- ALFAGOMMA Alfa Gomma s.p.a. 18 - AS5691 29154 0.2% 2242.6 -- MITRE-AS-5 - The MITRE Corporation 19 - AS35309 2206 0.0% 2206.0 -- NERO-AG-AS Nero AG 20 - AS47212 23175 0.2% 2106.8 -- UGD-AS University "Goce Delcev" TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 125.23.208.0/20 37848 0.3% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 2 - 193.33.184.0/23 35853 0.3% AS42787 -- MMIP-AS MultiMedia IP Ltd. 3 - 12.108.254.0/24 33281 0.3% AS26829 -- YKK-USA - YKK USA,INC 4 - 192.12.120.0/24 28636 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 5 - 221.128.192.0/18 26803 0.2% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 213.91.175.0/24 17150 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 7 - 210.92.148.0/24 12211 0.1% AS17834 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 8 - 203.63.26.0/24 10050 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 9 - 193.239.114.0/24 9817 0.1% AS31003 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 10 - 221.135.230.0/23 9266 0.1% AS9583 -- SIFY-AS-IN Sify Limited 11 - 84.23.102.0/24 8625 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 12 - 64.201.128.0/20 8536 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 13 - 72.14.230.0/24 7822 0.1% AS36384 -- GOOGLE-IT - Google Incorporated 14 - 118.95.56.0/24 7512 0.1% AS9583 -- SIFY-AS-IN Sify Limited 15 - 89.4.131.0/24 7148 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 16 - 201.77.80.0/20 7141 0.1% AS28646 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 17 - 193.142.125.0/24 6919 0.1% AS15169 -- GOOGLE - Google Inc. AS41264 -- GOOGLE-CORPNET Google Ireland Limited 18 - 135.10.4.0/24 6842 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 19 - 135.10.5.0/24 6840 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 20 - 84.23.100.0/24 6743 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri May 30 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 May 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200805301200.m4UC00VG014799@wattle.apnic.net> This report has been generated at Fri May 30 21:17:45 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-05-08 266670 167326 24-05-08 266754 167382 25-05-08 266501 166389 26-05-08 266731 166040 27-05-08 266584 166616 28-05-08 266831 167687 29-05-08 267378 168129 30-05-08 267397 167991 AS Summary 28457 Number of ASes in routing system 11987 Number of ASes announcing only one prefix 4919 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88356864 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center 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'). --- 30May08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 266995 168031 98964 37.1% All ASes AS4538 4919 876 4043 82.2% ERX-CERNET-BKB China Education and Research Network Center AS4755 1640 218 1422 86.7% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS6389 1994 620 1374 68.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS9498 1167 67 1100 94.3% BBIL-AP BHARTI BT INTERNET LTD. AS22773 945 66 879 93.0% CCINET-2 - Cox Communications Inc. AS18566 1044 279 765 73.3% COVAD - Covad Communications Co. AS11492 1226 491 735 60.0% CABLEONE - CABLE ONE AS8151 1233 506 727 59.0% Uninet S.A. de C.V. AS4323 1459 741 718 49.2% TWTC - Time Warner Telecom, Inc. AS1785 1022 323 699 68.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1073 375 698 65.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS19262 898 205 693 77.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1439 886 553 38.4% INS-AS - AT&T Data Communications Services AS6478 948 409 539 56.9% ATT-INTERNET3 - AT&T WorldNet Services AS19916 638 119 519 81.3% ASTRUM-0001 - OLM LLC AS18101 686 186 500 72.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4766 878 391 487 55.5% KIXS-AS-KR Korea Telecom AS7011 1076 604 472 43.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4134 825 381 444 53.8% CHINANET-BACKBONE No.31,Jin-rong Street AS17676 525 83 442 84.2% GIGAINFRA BB TECHNOLOGY Corp. AS855 597 165 432 72.4% CANET-ASN-4 - Bell Aliant AS6197 1007 591 416 41.3% BATI-ATL - BellSouth Network Solutions, Inc AS4668 675 272 403 59.7% LGNET-AS-KR LG CNS AS7018 1396 997 399 28.6% ATT-INTERNET4 - AT&T WorldNet Services AS22047 565 169 396 70.1% VTR BANDA ANCHA S.A. AS9443 467 85 382 81.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS3602 455 80 375 82.4% AS3602-RTI - Rogers Telecom Inc. AS4808 521 147 374 71.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7029 554 183 371 67.0% WINDSTREAM - Windstream Communications Inc AS16814 426 66 360 84.5% NSS S.A. Total 32298 10581 21717 67.2% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.200.192.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.193.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.194.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.195.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 93.158.64.0/18 AS39369 PORT80 Port80 AB, Sweden 93.158.64.0/19 AS39369 PORT80 Port80 AB, Sweden 93.158.64.0/20 AS39369 PORT80 Port80 AB, Sweden 93.158.80.0/20 AS39369 PORT80 Port80 AB, Sweden 93.158.96.0/19 AS39369 PORT80 Port80 AB, Sweden 93.158.96.0/20 AS39369 PORT80 Port80 AB, Sweden 93.158.112.0/20 AS39369 PORT80 Port80 AB, Sweden 94.50.16.0/20 AS3239 RU-SURNET Uralsvyazinform, Chelyabinsk branch 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS7891 BELLSOUTH-NET-BLK2 - Bellsouth.Net 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.45.132.0/22 AS24314 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.192.0/19 AS11881 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From frnkblk at iname.com Fri May 30 09:58:27 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 30 May 2008 09:58:27 -0500 Subject: Power/temperature monitoring Message-ID: Hopefully monitoring the status of a network is on-topic. I'm looking for temperature and power monitoring unit to install in some remote BWA cabinets. We had two incidents where we lost power in a town and we weren't aware of it until the backup batter drained to empty, and another situation where the cabinet became too cold. Because these cabinets are less than 19" wide and just 3-5" deep, I need something quite small. I did find one product but it requires four components (unit with built-in temperature sensor, adapter, and AC power sensor, plus power supply) Perhaps there's someone on this list who has gone down this road and can point me to a good product. Required: - temperature sensor - 110 VAC power monitoring (on/off, not necessarily current) - Ethernet interface (at least SNMP, Web GUI and Optional: - fed via 12 VDC power - 12 VDC power monitoring (current) - humidity sensor Frank From jeremy.anderson at reignmaker.net Fri May 30 10:09:10 2008 From: jeremy.anderson at reignmaker.net (Jeremy Anderson) Date: Fri, 30 May 2008 11:09:10 -0400 Subject: Power/temperature monitoring In-Reply-To: References: Message-ID: <1212160150.6142.4.camel@jeremy-laptop> http://akcp.com/company/sensorProbe8.htm Everything you need. Jeremy On Fri, 2008-05-30 at 09:58 -0500, Frank Bulk wrote: > Hopefully monitoring the status of a network is on-topic. > > I'm looking for temperature and power monitoring unit to install in some > remote BWA cabinets. We had two incidents where we lost power in a town and > we weren't aware of it until the backup batter drained to empty, and another > situation where the cabinet became too cold. Because these cabinets are > less than 19" wide and just 3-5" deep, I need something quite small. I did > find one product but it requires four components (unit with built-in > temperature sensor, adapter, and AC power sensor, plus power supply) > > Perhaps there's someone on this list who has gone down this road and can > point me to a good product. > > Required: > - temperature sensor > - 110 VAC power monitoring (on/off, not necessarily current) > - Ethernet interface (at least SNMP, Web GUI and > > Optional: > - fed via 12 VDC power > - 12 VDC power monitoring (current) > - humidity sensor > > > Frank > > From mike at sentex.net Fri May 30 10:10:50 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri, 30 May 2008 11:10:50 -0400 Subject: Power/temperature monitoring In-Reply-To: References: Message-ID: <200805301510.m4UFAv70006213@lava.sentex.ca> At 10:58 AM 5/30/2008, Frank Bulk wrote: >Required: >- temperature sensor >- 110 VAC power monitoring (on/off, not necessarily current) >- Ethernet interface (at least SNMP, Web GUI and We have been using "Uptime Devices". Our units have room for 3 sensors (we have 2 temp and one for humidity). Web, SNMP, ethernet, external AC power blob. Its a fairly small form factor and it has been reliable for us over the years. Alerts work as expected and havent had any false positives either over the years. ---Mike From cstone at axint.net Fri May 30 10:22:12 2008 From: cstone at axint.net (Chris Stone) Date: Fri, 30 May 2008 09:22:12 -0600 Subject: Power/temperature monitoring In-Reply-To: <200805301510.m4UFAv70006213@lava.sentex.ca> References: <200805301510.m4UFAv70006213@lava.sentex.ca> Message-ID: <200805300922.16878.cstone@axint.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 30 May 2008 9:10:50 am Mike Tancsa wrote: > At 10:58 AM 5/30/2008, Frank Bulk wrote: > >Required: > >- temperature sensor > >- 110 VAC power monitoring (on/off, not necessarily current) > >- Ethernet interface (at least SNMP, Web GUI and > > We have been using "Uptime Devices". Our units have room for 3 > sensors (we have 2 temp and one for humidity). Web, SNMP, ethernet, > external AC power blob. Its a fairly small form factor and it has > been reliable for us over the years. Alerts work as expected and > havent had any false positives either over the years. > > ---Mike We also use Uptime Devices and have for years. Never had a problem. Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhAG6QACgkQnSVip47FEdO8+ACfQ4AOvKK+waM6ZTxSHHxibAo3 b48AoIpvsK2Fr2ARftsfrSFq4jmAxHlP =IknF -----END PGP SIGNATURE----- From mcrocker at crocker.com Fri May 30 10:22:20 2008 From: mcrocker at crocker.com (Matthew Crocker) Date: Fri, 30 May 2008 11:22:20 -0400 Subject: Power/temperature monitoring In-Reply-To: <200805301510.m4UFAv70006213@lava.sentex.ca> References: <200805301510.m4UFAv70006213@lava.sentex.ca> Message-ID: We used an Uptime Device and it didn't work out too well. We switched to an AKCP SensorProbe8-60 http://www.akcp.com/company/sensorProbe8X60.htm which has worked out better. We need a lot of dry contacts to monitor our alarm relays (Cisco ONS15454, Taqua T7000, Liebert HVACs, Generator, Fire Suppression, etc, etc...) On May 30, 2008, at 11:10 AM, Mike Tancsa wrote: > At 10:58 AM 5/30/2008, Frank Bulk wrote: > >> Required: >> - temperature sensor >> - 110 VAC power monitoring (on/off, not necessarily current) >> - Ethernet interface (at least SNMP, Web GUI and > > We have been using "Uptime Devices". Our units have room for 3 > sensors (we have 2 temp and one for humidity). Web, SNMP, ethernet, > external AC power blob. Its a fairly small form factor and it has > been reliable for us over the years. Alerts work as expected and > havent had any false positives either over the years. > > ---Mike > From alex at corp.nac.net Fri May 30 10:27:46 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Fri, 30 May 2008 11:27:46 -0400 Subject: Power/temperature monitoring In-Reply-To: <200805301510.m4UFAv70006213@lava.sentex.ca> References: <200805301510.m4UFAv70006213@lava.sentex.ca> Message-ID: We've started using ControlByWeb, specifically http://www.controlbyweb.com/temperature/index.html .. POE, and handles four probes. We just don't use their probes, we buy them elsewhere (it's plain old one wire). > -----Original Message----- > From: Mike Tancsa [mailto:mike at sentex.net] > Sent: Friday, May 30, 2008 11:11 AM > To: frnkblk at iname.com; nanog at nanog.org > Subject: Re: Power/temperature monitoring > > At 10:58 AM 5/30/2008, Frank Bulk wrote: > > >Required: > >- temperature sensor > >- 110 VAC power monitoring (on/off, not necessarily current) > >- Ethernet interface (at least SNMP, Web GUI and > > We have been using "Uptime Devices". Our units have room for 3 > sensors (we have 2 temp and one for humidity). Web, SNMP, ethernet, > external AC power blob. Its a fairly small form factor and it has > been reliable for us over the years. Alerts work as expected and > havent had any false positives either over the years. > > ---Mike From pfs at cisco.com Fri May 30 09:49:51 2008 From: pfs at cisco.com (Philip Smith) Date: Sat, 31 May 2008 00:49:51 +1000 Subject: [NANOG-announce] New NANOG Mail List Committee Message-ID: <4840140F.4090105@cisco.com> Hi everyone, In its recent meeting, the SC selected four volunteers from the community to join Sue Joiner of Merit on the Mail List Committee. The new team is as follows: Sue Joiner (appointed by Merit) Simon Lyall (term finishes in October 2009) Kris Foster (term finishes in October 2009) David Barak (term finishes in October 2008) Tim Yocum (term finishes in October 2008) The SC would like to thank the four successful volunteers for their willingness to contribute their time and energy to assist with supporting the NANOG mail list. The SC also would like to thank Michael K Smith, John Osman and Alex Pilosov for also stepping forward and offering to help. We hope you will be willing to volunteer again when two positions on the MLC become available in October. Kind regards, Philip Smith SC Chair -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From pfs at cisco.com Fri May 30 10:23:58 2008 From: pfs at cisco.com (Philip Smith) Date: Sat, 31 May 2008 01:23:58 +1000 Subject: [NANOG-announce] Please welcome Brian Deardorff to the PC Message-ID: <48401C0E.9030701@cisco.com> Hi everyone, In its recent meeting, the SC selected Brian Deardorff to fill the PC position vacated by Ted Seely last month. Brian joins the current PC (http://www.nanog.org/pc.current.html) and serves until the term is up for renewal in October this year. The SC would like to thank David Conrad, Randy Epstein, Michael K. Smith, Mike Long, Ron Bonica, Tom Scholl and Celeste Anderson for volunteering. We hope they will all consider volunteering again when positions on the PC become available again in October. Kind regards, Philip Smith SC Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cboyd at gizmopartners.com Fri May 30 10:40:40 2008 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 30 May 2008 10:40:40 -0500 Subject: Power/temperature monitoring In-Reply-To: References: Message-ID: We've got a couple of the (beta test) mini goose climate monitors installed. Takes up less space than the big APC boxes we've been using. http://www.itwatchdogs.com/ --Chris From frnkblk at iname.com Fri May 30 10:53:09 2008 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 30 May 2008 10:53:09 -0500 Subject: Power/temperature monitoring In-Reply-To: References: <200805301510.m4UFAv70006213@lava.sentex.ca> Message-ID: Do you know if they have a AC power probe? Frank -----Original Message----- From: Alex Rubenstein [mailto:alex at corp.nac.net] Sent: Friday, May 30, 2008 10:28 AM To: Mike Tancsa; frnkblk at iname.com; nanog at nanog.org Subject: RE: Power/temperature monitoring We've started using ControlByWeb, specifically http://www.controlbyweb.com/temperature/index.html .. POE, and handles four probes. We just don't use their probes, we buy them elsewhere (it's plain old one wire). > -----Original Message----- > From: Mike Tancsa [mailto:mike at sentex.net] > Sent: Friday, May 30, 2008 11:11 AM > To: frnkblk at iname.com; nanog at nanog.org > Subject: Re: Power/temperature monitoring > > At 10:58 AM 5/30/2008, Frank Bulk wrote: > > >Required: > >- temperature sensor > >- 110 VAC power monitoring (on/off, not necessarily current) > >- Ethernet interface (at least SNMP, Web GUI and > > We have been using "Uptime Devices". Our units have room for 3 > sensors (we have 2 temp and one for humidity). Web, SNMP, ethernet, > external AC power blob. Its a fairly small form factor and it has > been reliable for us over the years. Alerts work as expected and > havent had any false positives either over the years. > > ---Mike From howard.jones at network-i.net Fri May 30 10:58:43 2008 From: howard.jones at network-i.net (Howard Jones) Date: Fri, 30 May 2008 16:58:43 +0100 Subject: Power/temperature monitoring In-Reply-To: References: <200805301510.m4UFAv70006213@lava.sentex.ca> Message-ID: <48402433.40209@network-i.net> Frank Bulk wrote: > Do you know if they have a AC power probe? > > Frank > Does the UPS not have a dry-contact alarm output, or similar? Presumably you trust the UPS, just not the colo... From tony at swalter.com Fri May 30 10:59:00 2008 From: tony at swalter.com (Tony Patti) Date: Fri, 30 May 2008 15:59:00 +0000 Subject: Power/temperature monitoring Message-ID: <20080530160003.00A7B1F8056@smtp01.swalter.com> I agree with Chris -- we also have been using the ITWatchDogs products for years, and both the products and company have been wonderful to work with. Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Chris Boyd Sent: 5/30/2008 11:40 AM To: nanog at nanog.org Subject: Re: Power/temperature monitoring We've got a couple of the (beta test) mini goose climate monitors installed. Takes up less space than the big APC boxes we've been using. http://www.itwatchdogs.com/ --Chris From jbittman at chewcorp.com Fri May 30 11:24:28 2008 From: jbittman at chewcorp.com (Jobe Bittman) Date: Fri, 30 May 2008 09:24:28 -0700 Subject: Need Infiniband card recommendation Message-ID: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> Is anyone using Infiniband cards under linux? I'm trying to find a supported card other than the Cisco one. -- Jobe Bittman From christian at visr.org Fri May 30 11:25:47 2008 From: christian at visr.org (Christian) Date: Fri, 30 May 2008 12:25:47 -0400 Subject: Need Infiniband card recommendation In-Reply-To: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> References: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> Message-ID: <9b62cf2f0805300925n112190e8ja6fb4e2ae6bad26b@mail.gmail.com> try http://www.mellanox.com/ On Fri, May 30, 2008 at 12:24 PM, Jobe Bittman wrote: > Is anyone using Infiniband cards under linux? I'm trying to find a > supported > card other than the Cisco one. > > -- > Jobe Bittman > From Gregori.Parker at theplatform.com Fri May 30 11:35:02 2008 From: Gregori.Parker at theplatform.com (Gregori Parker) Date: Fri, 30 May 2008 09:35:02 -0700 Subject: Power/temperature monitoring In-Reply-To: <20080530160003.00A7B1F8056@smtp01.swalter.com> References: <20080530160003.00A7B1F8056@smtp01.swalter.com> Message-ID: <1A9866F953006D45AEE0166066114E09100DEA47@TPMAIL02.corp.theplatform.com> Perhaps a little pricier than the others mentioned, but I've had great experiences with the APC Netbotz line...the additional audio, visual and door monitoring comes in handy, plus it plays well with snmp-based trending tools like cacti and mrtg. Netbotz also monitors humidty, dew point, airflow, etc, which is great for measuring differentiation between cold and hot rows. -----Original Message----- From: Tony Patti [mailto:tony at swalter.com] Sent: Friday, May 30, 2008 8:59 AM To: Chris Boyd; nanog at nanog.org Subject: RE: Power/temperature monitoring I agree with Chris -- we also have been using the ITWatchDogs products for years, and both the products and company have been wonderful to work with. Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Chris Boyd Sent: 5/30/2008 11:40 AM To: nanog at nanog.org Subject: Re: Power/temperature monitoring We've got a couple of the (beta test) mini goose climate monitors installed. Takes up less space than the big APC boxes we've been using. http://www.itwatchdogs.com/ --Chris From andy-nanog at bash.sh Fri May 30 11:49:12 2008 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Fri, 30 May 2008 17:49:12 +0100 Subject: Need Infiniband card recommendation In-Reply-To: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> References: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> Message-ID: <20080530164912.GG7747@waffl.ing.me.uk> On Fri, May 30, 2008 at 09:24:28AM -0700, Jobe Bittman wrote: > Is anyone using Infiniband cards under linux? I'm trying to find a supported > card other than the Cisco one. Whats wrong with the cisco ones? We're using their DDR ones here under Ubuntu 7.10 and haven't experienced any issues. They appear to be just 'Mellanox Technologies MT25208 InfiniHost III Ex' though.. best wishes From jwise at draga.com Fri May 30 12:05:31 2008 From: jwise at draga.com (Jim Wise) Date: Fri, 30 May 2008 13:05:31 -0400 (EDT) Subject: Large number of DNS probes in last 24 hours Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've seen a surprising number of attempted recursive DNS requests against unpublished non-recursive DNS servers in the last 24 hours or so, many of them obviously probes of some sort (query for "." IN NS, eg). Is anyone else seeing this? Is it new? Or did some botnet just reach this corner of the IP space? - -- Jim Wise jwise at draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFIQDPbq/KRbT0KwbwRAuzVAJ0QRpMw59U7U2qfpEdHOeIt+YVzxgCeLQK4 0HeEYDsVW4VI6ahbjE8xphQ= =QV9h -----END PGP SIGNATURE----- From shrdlu at deaddrop.org Fri May 30 12:11:43 2008 From: shrdlu at deaddrop.org (Lynda) Date: Fri, 30 May 2008 10:11:43 -0700 Subject: Large number of DNS probes in last 24 hours In-Reply-To: References: Message-ID: <4840354F.8090206@deaddrop.org> Jim Wise wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've seen a surprising number of attempted recursive DNS requests > against unpublished non-recursive DNS servers in the last 24 hours or > so, many of them obviously probes of some sort (query for "." IN NS, > eg). > Is anyone else seeing this? Is it new? Or did some botnet just reach > this corner of the IP space? Yes, no, and yes. I've seen this sort of thing severe enough that I simply took the servers down for a day (yes, really), even considering the severe inconvenience that caused. -- Die Gedanken sind frei From cscora at apnic.net Fri May 30 13:07:13 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 May 2008 04:07:13 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200805301807.m4UI7DSg020949@thyme.apnic.net> 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 at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 May, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 256681 Prefixes after maximum aggregation: 127966 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 125823 Total ASes present in the Internet Routing Table: 28326 Prefixes per ASN: 9.06 Origin-only ASes present in the Internet Routing Table: 24711 Origin ASes announcing only one prefix: 11900 Transit ASes present in the Internet Routing Table: 3615 Transit-only ASes present in the Internet Routing Table: 74 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN (43380) 13 Prefixes from unregistered ASNs in the Routing Table: 626 Unregistered ASNs in the Routing Table: 236 Number of 32-bit ASNs allocated by the RIRs: 49 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 782 Number of addresses announced to Internet: 1874228320 Equivalent to 111 /8s, 182 /16s and 116 /24s Percentage of available address space announced: 50.6 Percentage of allocated address space announced: 61.4 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.0 Total number of prefixes smaller than registry allocations: 123722 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 58811 Total APNIC prefixes after maximum aggregation: 22049 APNIC Deaggregation factor: 2.67 Prefixes being announced from the APNIC address blocks: 55821 Unique aggregates announced from the APNIC address blocks: 24827 APNIC Region origin ASes present in the Internet Routing Table: 3252 APNIC Prefixes per ASN: 17.17 APNIC Region origin ASes announcing only one prefix: 854 APNIC Region transit ASes present in the Internet Routing Table: 502 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 351187872 Equivalent to 20 /8s, 238 /16s and 179 /24s Percentage of available APNIC address space announced: 74.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 117915 Total ARIN prefixes after maximum aggregation: 65206 ARIN Deaggregation factor: 1.81 Prefixes being announced from the ARIN address blocks: 87447 Unique aggregates announced from the ARIN address blocks: 34419 ARIN Region origin ASes present in the Internet Routing Table: 12183 ARIN Prefixes per ASN: 7.18 ARIN Region origin ASes announcing only one prefix: 4701 ARIN Region transit ASes present in the Internet Routing Table: 1131 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 357844480 Equivalent to 21 /8s, 84 /16s and 70 /24s Percentage of available ARIN address space announced: 73.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, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 55345 Total RIPE prefixes after maximum aggregation: 33873 RIPE Deaggregation factor: 1.63 Prefixes being announced from the RIPE address blocks: 50545 Unique aggregates announced from the RIPE address blocks: 33982 RIPE Region origin ASes present in the Internet Routing Table: 11397 RIPE Prefixes per ASN: 4.43 RIPE Region origin ASes announcing only one prefix: 5957 RIPE Region transit ASes present in the Internet Routing Table: 1722 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 359785600 Equivalent to 21 /8s, 113 /16s and 228 /24s Percentage of available RIPE address space announced: 82.5 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, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20091 Total LACNIC prefixes after maximum aggregation: 5118 LACNIC Deaggregation factor: 3.93 Prefixes being announced from the LACNIC address blocks: 18402 Unique aggregates announced from the LACNIC address blocks: 10322 LACNIC Region origin ASes present in the Internet Routing Table: 951 LACNIC Prefixes per ASN: 19.35 LACNIC Region origin ASes announcing only one prefix: 314 LACNIC Region transit ASes present in the Internet Routing Table: 157 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 15 Number of LACNIC addresses announced to Internet: 51751040 Equivalent to 3 /8s, 21 /16s and 168 /24s Percentage of available LACNIC address space announced: 51.4 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3893 Total AfriNIC prefixes after maximum aggregation: 1197 AfriNIC Deaggregation factor: 3.25 Prefixes being announced from the AfriNIC address blocks: 4182 Unique aggregates announced from the AfriNIC address blocks: 1862 AfriNIC Region origin ASes present in the Internet Routing Table: 240 AfriNIC Prefixes per ASN: 17.43 AfriNIC Region origin ASes announcing only one prefix: 74 AfriNIC Region transit ASes present in the Internet Routing Table: 49 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12279808 Equivalent to 0 /8s, 187 /16s and 96 /24s Percentage of available AfriNIC address space announced: 36.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 4755 1547 387 87 Videsh Sanchar Nigam Ltd. Aut 9498 1165 549 61 BHARTI BT INTERNET LTD. 9583 1101 110 410 Sify Limited 17488 1084 71 76 Hathway IP Over Cable Interne 4766 849 6006 343 Korea Telecom (KIX) 4134 825 12917 323 CHINANET-BACKBONE 23577 817 34 698 Korea Telecom (ATM-MPLS) 18101 690 150 53 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 548 1919 421 Telstra Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 1992 3087 178 bellsouth.net, inc. 4323 1462 1045 377 Time Warner Telecom 2386 1438 659 873 AT&T Data Communications Serv 7018 1377 5830 982 AT&T WorldNet Services 11492 1223 148 12 Cable One 7011 1076 298 603 Citizens Utilities 18566 1044 296 10 Covad Communications 1785 1022 510 105 AppliedTheory Corporation 6197 1006 597 507 BellSouth Network Solutions, 174 973 6837 806 Cogent Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 409 1772 368 TDC Tele Danmark 8452 347 188 7 TEDATA 3301 339 1460 307 TeliaNet Sweden 3320 317 7044 266 Deutsche Telekom AG 8866 298 77 21 Bulgarian Telecommunication C 5462 291 666 26 Telewest Broadband 3215 285 2718 94 France Telecom Transpac 8551 283 269 38 Bezeq International 680 274 2047 264 DFN-IP service G-WiN 9155 267 46 11 QualityNet AS number Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1233 2464 227 UniNet S.A. de C.V. 11830 603 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 464 228 69 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 414 85 46 ENTEL CHILE S.A. 11172 411 118 69 Servicios Alestra S.A de C.V 10620 392 100 63 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 338 23 89 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 472 61 28 LINKdotNET AS number 3741 288 853 223 The Internet Solution 20858 224 34 3 EgyNet 2018 189 173 83 Tertiary Education Network 5713 168 575 102 Telkom SA Ltd 6713 145 136 12 Itissalat Al-MAGHRIB 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 100 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 1992 3087 178 bellsouth.net, inc. 4755 1547 387 87 Videsh Sanchar Nigam Ltd. Aut 4323 1462 1045 377 Time Warner Telecom 2386 1438 659 873 AT&T Data Communications Serv 7018 1377 5830 982 AT&T WorldNet Services 8151 1233 2464 227 UniNet S.A. de C.V. 11492 1223 148 12 Cable One 9498 1165 549 61 BHARTI BT INTERNET LTD. 9583 1101 110 410 Sify Limited 17488 1084 71 76 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4755 1547 1460 Videsh Sanchar Nigam Ltd. Aut 11492 1223 1211 Cable One 9498 1165 1104 BHARTI BT INTERNET LTD. 4323 1462 1085 Time Warner Telecom 18566 1044 1034 Covad Communications 17488 1084 1008 Hathway IP Over Cable Interne 8151 1233 1006 UniNet S.A. de C.V. 1785 1022 917 AppliedTheory Corporation 22773 945 883 Cox Communications, Inc. 6478 948 797 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:16 /11:42 /12:142 /13:280 /14:513 /15:1019 /16:9933 /17:4373 /18:7283 /19:15509 /20:17927 /21:17339 /22:21799 /23:22883 /24:135257 /25:800 /26:948 /27:490 /28:81 /29:9 /30:1 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 1227 1992 bellsouth.net, inc. 11492 1205 1223 Cable One 2386 1136 1438 AT&T Data Communications Serv 18566 1025 1044 Covad Communications 7011 964 1076 Citizens Utilities 9583 955 1101 Sify Limited 6478 947 948 AT&T Worldnet Services 4755 936 1547 Videsh Sanchar Nigam Ltd. Aut 17488 897 1084 Hathway IP Over Cable Interne 9498 848 1165 BHARTI BT INTERNET LTD. Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:108 12:2048 13:1 15:20 16:3 17:5 18:13 20:35 24:1079 25:1 32:61 33:3 38:431 40:93 41:640 43:1 44:2 47:12 52:3 55:3 56:3 57:23 58:514 59:456 60:443 61:988 62:1115 63:1946 64:3337 65:2430 66:3668 67:1205 68:685 69:2253 70:629 71:125 72:1764 73:5 74:980 75:217 76:322 77:664 78:617 79:170 80:905 81:859 82:593 83:391 84:573 85:1007 86:421 87:671 88:325 89:1214 90:12 91:1264 92:187 93:502 96:32 97:21 98:178 99:3 114:17 116:657 117:331 118:142 119:430 120:45 121:524 122:772 123:344 124:832 125:1142 128:325 129:202 130:131 131:403 132:66 133:9 134:177 135:33 136:220 137:91 138:151 139:69 140:484 141:99 142:399 143:308 144:358 145:51 146:357 147:153 148:504 149:184 150:130 151:196 152:172 153:135 154:10 155:273 156:174 157:271 158:167 159:222 160:257 161:115 162:233 163:186 164:526 165:448 166:315 167:322 168:610 169:131 170:429 171:29 172:10 189:174 190:2025 192:5789 193:4094 194:3210 195:2451 196:1082 198:3746 199:3257 200:5628 201:1432 202:7586 203:7856 204:3989 205:2069 206:2400 207:2760 208:3360 209:3433 210:2516 211:1023 212:1394 213:1644 214:470 215:49 216:4363 217:1188 218:347 219:412 220:1081 221:462 222:308 End of report From onewingaengel at gmail.com Fri May 30 13:54:56 2008 From: onewingaengel at gmail.com (John Menerick) Date: Fri, 30 May 2008 11:54:56 -0700 Subject: Large number of DNS probes in last 24 hours In-Reply-To: <4840354F.8090206@deaddrop.org> References: <4840354F.8090206@deaddrop.org> Message-ID: <70726B55-B92D-4162-9D7B-1DFC23860BC6@gmail.com> I have seen this as well on my fringe IP-space networks. Just a botnet or two running along the range. A cost of doing business :\ John Menerick http://icehax.us On May 30, 2008, at 10:11 AM, Lynda wrote: > Jim Wise wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> I've seen a surprising number of attempted recursive DNS requests >> against unpublished non-recursive DNS servers in the last 24 hours >> or so, many of them obviously probes of some sort (query for "." IN >> NS, eg). > >> Is anyone else seeing this? Is it new? Or did some botnet just >> reach this corner of the IP space? > > Yes, no, and yes. I've seen this sort of thing severe enough that I > simply took the servers down for a day (yes, really), even > considering the severe inconvenience that caused. > > -- > Die Gedanken sind frei > > From guy.shepperd at vanderbilt.edu Fri May 30 14:47:46 2008 From: guy.shepperd at vanderbilt.edu (Shepperd, Guy) Date: Fri, 30 May 2008 14:47:46 -0500 Subject: anyone have an AOL Email Engineer contact? Message-ID: <81B69C38CCD3244CA02209A63175E2560EE1DF4B03@ITS-HCWNAP07-TS.UC2k7.Vanderbilt.Edu> Needing an AOL Email engineer to contact me. Thanks Guy Shepperd From christian at visr.org Fri May 30 16:27:38 2008 From: christian at visr.org (Christian) Date: Fri, 30 May 2008 17:27:38 -0400 Subject: cluepon irrweb.com Message-ID: <9b62cf2f0805301427u1dc98ee7r60ccd8ebd7467047@mail.gmail.com> anyone know whats going on with this - still a work in progress? plans/etc? From jbittman at chewcorp.com Fri May 30 17:26:41 2008 From: jbittman at chewcorp.com (Jobe Bittman) Date: Fri, 30 May 2008 15:26:41 -0700 Subject: Need Infiniband card recommendation In-Reply-To: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> References: <4aa1ddab0805300924h32a66946h41e61d8559091ba7@mail.gmail.com> Message-ID: <4aa1ddab0805301526m3edf4290y91a8a5912b8d16cc@mail.gmail.com> Nothing wrong with the Cisco's. The ones we have work great. It's just they were 5-7 days out to get some and I needed them fast. I actually lucked out. There was a Mellanox reseller in San Diego, wsm.com. I picked up a couple ConnectX IB and they even drove them to my door! From mikal at stillhq.com Fri May 30 22:00:49 2008 From: mikal at stillhq.com (Michael Still) Date: Fri, 30 May 2008 20:00:49 -0700 Subject: Large number of DNS probes in last 24 hours In-Reply-To: References: Message-ID: <4840BF61.5000906@stillhq.com> Jim Wise wrote: > I've seen a surprising number of attempted recursive DNS requests > against unpublished non-recursive DNS servers in the last 24 hours or > so, many of them obviously probes of some sort (query for "." IN NS, > eg). > > Is anyone else seeing this? Is it new? Or did some botnet just reach > this corner of the IP space? I have seen PlanetLab experiments doing this. What are the originating IP addresses? Mikal From jwise at draga.com Fri May 30 23:34:31 2008 From: jwise at draga.com (Jim Wise) Date: Sat, 31 May 2008 00:34:31 -0400 (EDT) Subject: Large number of DNS probes in last 24 hours In-Reply-To: <4840BF61.5000906@stillhq.com> References: <4840BF61.5000906@stillhq.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 30 May 2008, Michael Still wrote: >Jim Wise wrote: >> I've seen a surprising number of attempted recursive DNS requests >> against unpublished non-recursive DNS servers in the last 24 hours or >> so, many of them obviously probes of some sort (query for "." IN NS, >> eg). >> >> Is anyone else seeing this? Is it new? Or did some botnet just reach >> this corner of the IP space? > >I have seen PlanetLab experiments doing this. What are the originating >IP addresses? Three observed source addresses 208.78.169.237 204.11.51.62 194.199.24.101 Source ports are high and non-repeating. Other than the domain root, A-record queries for "google.com" and for hostnames which appear to be on the same subnet as the querying host. - -- Jim Wise jwise at draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iD8DBQFIQNVXq/KRbT0KwbwRAvxDAJ9AuikE/UHx8YvlWIyiL4cdnaVjhwCdGYBI CTEd5J0L0NCeDnpViMxOPmY= =W/wp -----END PGP SIGNATURE----- From Rod.Beck at hiberniaatlantic.com Sat May 31 11:36:35 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sat, 31 May 2008 17:36:35 +0100 Subject: NANOG NYC Event References: <200805271853.m4RIrenk026073@mail.r-bonomi.com><483D8240.2080602@decarta.com><483D8990.50609@decarta.com><982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net><2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com><18494.7752.530297.196323@world.std.com> Message-ID: <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> I strongly suggest that those heading to New York visit the great musems, architecture (Saint Patrick's Cathedral), and restaurants. You have the American Museum of Natural History, which includes an excellent Planetarium and just on the other side of Central Park, the Metropolitan Museum of Art and the Guggenheim. There are excellent Chinese and Indian restaurants in Lower Manhattan. Do not take taxis in New York. The subway is much faster and cheaper. Regards, Roderick. From morrowc.lists at gmail.com Sat May 31 13:08:56 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 31 May 2008 14:08:56 -0400 Subject: NANOG NYC Event In-Reply-To: <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> Message-ID: <75cb24520805311108k61aaabe7n32f8becea5a796c4@mail.gmail.com> On Sat, May 31, 2008 at 12:36 PM, Rod Beck wrote: > Do not take taxis in New York. The subway is much faster and cheaper. 'you may consider that the NYC metro system is fairly cheap, fairly ubiquitous... Taxi's are relatively expensive in the city, though nice for certain places which maybe more of a gymnastics event on the metro' (the taxi system in nyc isn't too horrid, though it is pricey, which I think was Rod's main objection... plus if you taxi you miss out on the other famous NYC attraction, the giant metro rats! :) ) From Rod.Beck at hiberniaatlantic.com Sat May 31 13:33:06 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sat, 31 May 2008 19:33:06 +0100 Subject: [SPAM-HEADER] - Re: NANOG NYC Event - Email found in subject References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> <75cb24520805311108k61aaabe7n32f8becea5a796c4@mail.gmail.com> Message-ID: <71CB284A12EDA54880FF588A8BAC0BE221FEF6@ernie.HiberniaAtlantic.local> I miss those dancing rats on the Subway platform at Columbus Circle. Frisky Little Criters. Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com Wireless: 1-212-444-8829. Landline: 33-1-4346-3209. French Wireless: 33-6-14-33-48-97. AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com rodbeck at erols.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From sil at infiltrated.net Sat May 31 13:42:04 2008 From: sil at infiltrated.net (J. Oquendo) Date: Sat, 31 May 2008 14:42:04 -0400 Subject: NANOG NYC Event In-Reply-To: <75cb24520805311108k61aaabe7n32f8becea5a796c4@mail.gmail.com> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> <75cb24520805311108k61aaabe7n32f8becea5a796c4@mail.gmail.com> Message-ID: <48419BFC.2060303@infiltrated.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Morrow wrote: | On Sat, May 31, 2008 at 12:36 PM, Rod Beck | wrote: | |> Do not take taxis in New York. The subway is much faster and cheaper. | | 'you may consider that the NYC metro system is fairly cheap, fairly | ubiquitous... Taxi's are relatively expensive in the city, though nice | for certain places which maybe more of a gymnastics event on the | metro' | | (the taxi system in nyc isn't too horrid, though it is pricey, which I | think was Rod's main objection... plus if you taxi you miss out on the | other famous NYC attraction, the giant metro rats! :) ) | | If you're not from NYC and or aren't familiar with certain places be advised that taxi drivers can *mistakenly* get lost resulting in you paying a high bill. Tips on getting around: * East and West starts on 5th Avenue When you're on a numbered STREET (not Avenue) the divider from East and West is Fifth Avenue. The numbers work themselves from there on. So for example, if you needed to get to say 12 E57th Street, this will be between 5th and Madison Avenue. 400 E57th will likely be down near 2nd and 3rd Avenue. Numbers head higher in opposite directions: 1 West Whatever Street will be between on the West side of 5th Avenue and vice versa, 1 East will be across from 1 West ;) * Good eating: Chinese is best (opinion) around Mott Street and Canal. I've always stayed away from places directly on Canal Street. Best method to get around here via subway, 4 or 5 train from Brooklyn to City Hall, transfer to the 6 train one stop. Italian: Anywhere in Little Italy is usually good. Mulberry Street has some pretty good restuarants. Dress is usually casual for most places. Nightlife: Depending on your genre, see if you can pick up a copy of "Village Voice" usually free in the city (Manhattan for non NYers). Towards the end of the page, they usually post all sorts of clubs, dance spots, bars, etc.. Unsure of NANOG's dates (too lazy to read) - if it ends up going on through next Sunday or even begins then, some may want to keep away from the city or at least the midtown area as the Puerto Rican Day Parade is in the city. Usually crowded and getting or around the city via the train is a headache. NY'er tips... After certain hours, say 11pm'ish, when taking any of the subways (if you do), you generally want to stay in the car nearest the conductor. You'll usually find the troublemakers near the end of the cars. Same goes for the platforms. If you have to take a train late at night, stay in a visible area (common sense). Empire State Building... If you're going to visit, be aware they're doing a slew of security checks so expect delays. Any entrance you come in on, you'll end up getting in the line (tourist). Unsure about the visitors heading to the top, but you'll usually be asked for photo ID getting in the building (I was just there earlier this month). Yankee Stadium: Its the B, D or 4 trains. 4 is generally fastest to 161st Street. Shea Stadium, Tennis Center, Worlds Fair: 7 train. If you see a 7 train in a diamond (not circle) jump on it. Its the express train and will get you there faster. Lest I forget... Good good good steak: Peter Luger's (overrated a bit but some really good steaks). Here is a link for bars, clubs, nightlife, etc., etc., for those who don't pick up the paper: http://www.villagevoice.com/bestof/2007/category/arts http://www.villagevoice.com/bestof/2007/category/bars http://www.villagevoice.com/bestof/2007/category/sports (browse through not what you may think) Hippest bars (noise, music, people factor) (opinion): Anywhere under 14th street (14-Delancey) on 2nd Avenue. You could head towards midtown but they end up becoming. Snootiest bars (snooty meaning stuck up, I make more money from my dad's trust fund then you): 40s-60s circa 2nd and 3rd Avenue. Anything goes bars: Usually in the East Village (Bowery) Guess My Gender bars: Usually in the West Village Cool place to get a bite to eat, be seen, hear some cool music, see some cool people (think noisy): Caliente Cab Company. Best place to throw away your money for lights, camera and crapaganda: Times Square. Thats it for me. ;) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSEGbkIOeOV2sx4+mAQKQEg/5AQEBPhsztJ2IOcWy/rjNG0NtHPcjJBbl /WOmVKCG/HRnFYQMgett/OTqMNCQ5ebTnWTJk9zx1biO2y6ky+EBDLCl4iEmu7XQ 2S53NYLgR7En1be5RnguHAIHK2jUcfYqxNfEzaJfMlzjH8ptzAcFR3BoC89Sazr5 LeTiyzaq2nRlszocEAvCoONMDoqWch9rTqTurBSSxyeVOhpZdnHZfYh+CS5VaLHO GUuUJKcGHhlt1kyTgE//mtNe5tCwidJ91bLyo4625th/66Ie1K76OqVHBAaKqw/i ian1U1G03Rcx1MMo2D5n96kVxGxbcQ2ZBcGZetym23ynl+Jgp95BCESIe/5qTm7/ bWPNgsQ1jEzaQUqEm8lLlCjxa9eARMH1HHzggQsn8AmCG1QlEWn/q3V1UlkvVFfE lqKt0iQIj3B30anO+hY+xW4Le/8DxzSU+iRt8D+JwLXesJJtdo0kEVsYEyYMCw8b 8jESt4gjqVr0vxfs3fIOejFu+aUjd44nn9MvbgHGzqWzjTlpq4xXHVMVyCYrlSVb 8Fb0kXcDQPPgdzQ/YsTHyvo1LQrXIaGAm+cbz2+jZazSGHG2Kd3s7QysKiuIi3I9 yGHtj9JTi9mTD/J1BZ45bSh3DztIZmEc8B33xDnv8+50gicl6tojV5LKxwCoNKMr B3fjy5YjuWs= =xgN2 -----END PGP SIGNATURE----- From nanog at grrrrreg.net Sat May 31 16:34:15 2008 From: nanog at grrrrreg.net (Greg VILLAIN) Date: Sat, 31 May 2008 23:34:15 +0200 Subject: [Splitting ARIN assignment] MPLS VPNv4, iBGP, split announce In-Reply-To: <4835A725.9090404@ttec.com> References: <4835A188.2000302@pandora.com> <4835A725.9090404@ttec.com> Message-ID: On May 22, 2008, at 7:02 PM, Joe Maimon wrote: > > James Kelty wrote: >> Hey all, >> I'm looking for an opinion from the group. I have an ARIN /21 >> assignment and a new requirement for a second data center. Rather >> than ask for another assignment, I would like to advertise one /22 >> from one location and the other /22 from the second location both >> with the same asn. My apps will work that way, so I don't have an >> issue internally, but I'm looking for a broader base opinion on that. >> Thanks a lot! >> -James > > You should attempt to advertise the /21 at each site along with the > site's /22 > > If you dont have dedicated interconnectivity between the sites, > tunneling *carefully* should do the trick. > > This will ensure that if/when those who filter on strict allocation > boundaries dont hear your /22, there will still be reachability, > even if suboptimal, to your sites. I have an equivalent dilemma: I'm of course well educated about not de- aggregating and would like, as much as possible, to avoid it. I'm trying to build a small-bandwidth core across an MPLS VPN, and I haven't been able to get an answer from the suppliers I'm auditing (even big ones...) although I'm pretty sure I can do it. Basically, the way I see it is that it would only be equivalent to a situation where hosts on my local LANs had tcp179 sessions across the VPN - but yet some (quite big players, not mentioning them though) are saying it would conflict with their instance of MP-BGP used for the VPN-v4. I seriously doubt it, but don't want to try it if there is a slightest risk. Also, I'm technically convinced that the supplier can maintain my loopback's connectivity and replace my IGP to bear my infrastructure's addressing (well I'd first have to get them to accept whatever OSPF between my router and their CPE, so their CPEs redistribute my subnets into the VPN's vrf on their PEs). I also don't want to add operational complexity by setting tunnels (one of the suppliers advised me to...) to bear the sessions - which I know would work, but I need to be sure my designed can be maintained easily, with least possible training. The only B-Plan that I eventually have, is voluntarily bypass best- practice (should my self esteem suffer from that :) split my announces on different geographical zones, to not have to maintain iBGP sync. Any one of you folks have any such experience ? I'd hate to upset the community and get NOs to peering enquiries just because of that, which basically would make running an AS pointless... Any pointers warmly welcome. Greg VILLAIN Independent internet architect From jfmezei at vaxination.ca Sat May 31 16:59:40 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sat, 31 May 2008 17:59:40 -0400 Subject: Types of packet modifications allowed for networks Message-ID: <4841CA4C.5020708@vaxination.ca> I would like any pointers to good documents that outline what sort of packet modifications are allowed (in terms of Internet culture/policies) by networks. Notably: For a transit network (neither sending or destination IPs belong to the network) For the sending network (originating IP belongs to that network) For the destination network (destination IP belongs to that network). Obviously, every router will change/decrement the TTL (and recalculate the header checksum) in the IP header. Are there other fields that are routinely changed at every hop ? Would it also be correct to state that any network along the way would have the right to fragment a packet in two or more pieces ? Or would that only be the destination network needing to fragment a packet to fit the last mile (PPP dialup or PPPoE ) in cases where MTU negotiations failed ? Are there sacred rules documented anywhere about not modifying anything else in the packets during transit ? Or has there never been any formal documentation on this because it was so obvious nobody was allowed to modify packets in transit ? (I an in Canada and currently participating in CRTC proceedings about the Bell throttling issue, and would like to consider the angle where the CRTC might decides Bell has the right to manage PPPoE packets as if they were TCPIP packets (by looking inside). Thanks in advance for any hints/pointers on this issue. From morrowc.lists at gmail.com Sat May 31 17:02:55 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 31 May 2008 18:02:55 -0400 Subject: [Splitting ARIN assignment] MPLS VPNv4, iBGP, split announce In-Reply-To: References: <4835A188.2000302@pandora.com> <4835A725.9090404@ttec.com> Message-ID: <75cb24520805311502g24b105b6mcec3c3bd3d6f621e@mail.gmail.com> On Sat, May 31, 2008 at 5:34 PM, Greg VILLAIN wrote: > I have an equivalent dilemma: I'm of course well educated about not > de-aggregating and would like, as much as possible, to avoid it. > I'm trying to build a small-bandwidth core across an MPLS VPN, and I haven't > been able to get an answer from the suppliers I'm auditing (even big > ones...) although I'm pretty sure I can do it. > > Basically, the way I see it is that it would only be equivalent to a > situation where hosts on my local LANs had tcp179 sessions across the VPN - > but yet some (quite big players, not mentioning them though) are saying it > would conflict with their instance of MP-BGP used for the VPN-v4. I nonsense... traffic from CE to CE isn't visible to the PE nor P routers aside from labelled packets... How else would people be able to sell CCC circuits across MPLS networks that are used for Internet Connectivity and have BGP from CE to PE (where the ce/pe link is the CCC link) I think the folks you are chatting with at the providers are not understanding your question(s) or their network(s). -Chris From swb at employees.org Sat May 31 17:17:44 2008 From: swb at employees.org (Scott Brim) Date: Sat, 31 May 2008 18:17:44 -0400 Subject: NANOG NYC Event In-Reply-To: <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com><483D8240.2080602@decarta.com><483D8990.50609@decarta.com><982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net><2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com><18494.7752.530297.196323@world.std.com> <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> Message-ID: <4841CE88.1070609@employees.org> On 5/31/08 12:36 PM, Rod Beck allegedly wrote: > I strongly suggest that those heading to New York visit the great > musems, architecture (Saint Patrick's Cathedral), and restaurants. > You have the American Museum of Natural History, which includes an > excellent Planetarium and just on the other side of Central Park, the > Metropolitan Museum of Art and the Guggenheim. There are excellent > Chinese and Indian restaurants in Lower Manhattan. Don't forget about Brooklyn in all this Manhattan praise :-). Consider the Brooklyn Botanic Garden. It's too late for cherries but the rose collections will be great. And the best pizza in New York (if you can get in) is at http://menupages.com/restaurantdetails.asp?areaid=0&restaurantid=31402&neighborhoodid=114&cuisineid=0 From swb at employees.org Sat May 31 17:18:18 2008 From: swb at employees.org (Scott Brim) Date: Sat, 31 May 2008 18:18:18 -0400 Subject: NANOG NYC Event In-Reply-To: <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com><483D8240.2080602@decarta.com><483D8990.50609@decarta.com><982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net><2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com><18494.7752.530297.196323@world.std.com> <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> Message-ID: <4841CEAA.60005@employees.org> ... which isn't to say those all aren't wonderful. From ddrummond at rnkcom.com Sat May 31 17:22:12 2008 From: ddrummond at rnkcom.com (ddrummond at rnkcom.com) Date: Sat, 31 May 2008 18:22:12 -0400 (EDT) Subject: Out of office Message-ID: <20080531222212.DA4DF3740FC@mail1.rnktel.com> I will be out of the office from May 31 - June 4 attending the NANOG conference in NYC with limited access to email. For urgent issues, please contact Dwight Ernest (dwight at rnkcom.com). From andrewy at webair.com Sat May 31 17:28:57 2008 From: andrewy at webair.com (andrew young) Date: Sat, 31 May 2008 18:28:57 -0400 Subject: NANOG NYC Event In-Reply-To: <4841CE88.1070609@employees.org> References: <200805271853.m4RIrenk026073@mail.r-bonomi.com> <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <71CB284A12EDA54880FF588A8BAC0BE221FEF3@ernie.HiberniaAtlantic.local> <4841CE88.1070609@employees.org> Message-ID: <1212272937.16998.3.camel@andrewy-desktop> Speaking of food, ill be going to the Big Apple BBQ fest next weekend: http://bigapplebbq.org/2008/ If you love to eat BBQ, this is a big MUST to cap off your stay in NYC. if you do decided to go, be sure to get the Fastpass: http://www.bigapplebbq.org/2008/index.php?s=fastpass You dont want to wait 30 mins online for food. Don't forget a bib and leave your belt at home. :-) - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy at webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare at webair.com ------------------------------------- On Sat, 2008-05-31 at 18:17 -0400, Scott Brim wrote: > On 5/31/08 12:36 PM, Rod Beck allegedly wrote: > > I strongly suggest that those heading to New York visit the great > > musems, architecture (Saint Patrick's Cathedral), and restaurants. > > You have the American Museum of Natural History, which includes an > > excellent Planetarium and just on the other side of Central Park, the > > Metropolitan Museum of Art and the Guggenheim. There are excellent > > Chinese and Indian restaurants in Lower Manhattan. > > Don't forget about Brooklyn in all this Manhattan praise :-). Consider > the Brooklyn Botanic Garden. It's too late for cherries but the rose > collections will be great. And the best pizza in New York (if you can > get in) is at > http://menupages.com/restaurantdetails.asp?areaid=0&restaurantid=31402&neighborhoodid=114&cuisineid=0 > -------------- next part -------------- A non-text attachment was scrubbed... Name: stock_smiley-1.png Type: image/png Size: 873 bytes Desc: not available URL: From SFisher at Bresnan.com Sat May 31 17:39:47 2008 From: SFisher at Bresnan.com (Fisher, Shawn) Date: Sat, 31 May 2008 18:39:47 -0400 Subject: NANOG NYC Event Message-ID: <21352038E7719F43A6D65B2D90B5256CCBFA33@fossil.bresnan.com> Personally I like dinosaur bbq, great malt beverages as well, and also blue smoke is great and if you like jazz, check out downstairs. -------------------------- Sent using BlackBerry -----Original Message----- From: andrew young To: Scott Brim CC: nanog at nanog.org Sent: Sat May 31 18:28:57 2008 Subject: Re: NANOG NYC Event Speaking of food, ill be going to the Big Apple BBQ fest next weekend: http://bigapplebbq.org/2008/ If you love to eat BBQ, this is a big MUST to cap off your stay in NYC. if you do decided to go, be sure to get the Fastpass: http://www.bigapplebbq.org/2008/index.php?s=fastpass You dont want to wait 30 mins online for food. Don't forget a bib and leave your belt at home. :-) - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy at webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare at webair.com ------------------------------------- On Sat, 2008-05-31 at 18:17 -0400, Scott Brim wrote: > On 5/31/08 12:36 PM, Rod Beck allegedly wrote: > > I strongly suggest that those heading to New York visit the great > > musems, architecture (Saint Patrick's Cathedral), and restaurants. > > You have the American Museum of Natural History, which includes an > > excellent Planetarium and just on the other side of Central Park, the > > Metropolitan Museum of Art and the Guggenheim. There are excellent > > Chinese and Indian restaurants in Lower Manhattan. > > Don't forget about Brooklyn in all this Manhattan praise :-). Consider > the Brooklyn Botanic Garden. It's too late for cherries but the rose > collections will be great. And the best pizza in New York (if you can > get in) is at > http://menupages.com/restaurantdetails.asp?areaid=0&restaurantid=31402&neighborhoodid=114&cuisineid=0 > From danny at tcb.net Sat May 31 21:34:39 2008 From: danny at tcb.net (Danny McPherson) Date: Sat, 31 May 2008 20:34:39 -0600 Subject: ISP Security BOF: NANOG 43 Message-ID: Folks, Here's the agenda for the ISP security BOF tomorrow afternoon. There's still some space left on the agenda so if there's something you'd like to discuss (or hear someone else discuss) drop Stefan and I an email. Thanks, see you in Brooklyn! -danny & Stefan --- Sunday, June 1 - 4-530 P Salon F/G ISP Security BOF: NANOG 43 http://www.nanog.org/mtg-0806/abstracts.php?sp=Fouant Moderators: Stefan Fouant/Neustar Danny McPherson/Arbor ISC SIE Update http://sie.isc.org/ Paul Vixie/ISC ICANN SSAC Update http://www.icann.org/committees/security/ Paul Vixie & Danny McPherson/SSAC DNS OARC Update/Meeting Pointers http://public.oarci.net/dns-operations/workshop-2008/ https://oarc.isc.org/register.php Keith Mitchell & Paul Vixie/OARC ISP Security POC Intros & Open Microphone --- From mikelieman at gmail.com Sat May 31 22:28:28 2008 From: mikelieman at gmail.com (Mike Lieman) Date: Sat, 31 May 2008 23:28:28 -0400 Subject: NANOG NYC Event In-Reply-To: <21352038E7719F43A6D65B2D90B5256CCBFA33@fossil.bresnan.com> References: <21352038E7719F43A6D65B2D90B5256CCBFA33@fossil.bresnan.com> Message-ID: <43661d390805312028u130046ddlc804e4615c83ba62@mail.gmail.com> I second the motion to recognize Dinosaur BBQ. All those in favor? On Sat, May 31, 2008 at 6:39 PM, Fisher, Shawn wrote: > Personally I like dinosaur bbq, great malt beverages as well, and also blue smoke is great and if you like jazz, check out downstairs. > -------------------------- > Sent using BlackBerry > > > -----Original Message----- > From: andrew young > To: Scott Brim > CC: nanog at nanog.org > Sent: Sat May 31 18:28:57 2008 > Subject: Re: NANOG NYC Event > > Speaking of food, ill be going to the Big Apple BBQ fest next weekend: > http://bigapplebbq.org/2008/ > > If you love to eat BBQ, this is a big MUST to cap off your stay in NYC. > > if you do decided to go, be sure to get the Fastpass: > http://www.bigapplebbq.org/2008/index.php?s=fastpass You dont want to > wait 30 mins online for food. Don't forget a bib and leave your belt at > home. :-) > > > > > - > ------------------------------------ > Andrew Young > Webair Internet Development, Inc > Phone: 1 866 WEBAIR 1 > FAX: 516.938.5100 > http://www.webair.com > andrewy at webair.com > ------------------------------------- > We are interested in any feedback you might have about the service > you received. Please contact our technical support consumer care manager > directly at 1.866.WEBAIR1 or e-mail customercare at webair.com > ------------------------------------- > > > On Sat, 2008-05-31 at 18:17 -0400, Scott Brim wrote: > >> On 5/31/08 12:36 PM, Rod Beck allegedly wrote: >> > I strongly suggest that those heading to New York visit the great >> > musems, architecture (Saint Patrick's Cathedral), and restaurants. >> > You have the American Museum of Natural History, which includes an >> > excellent Planetarium and just on the other side of Central Park, the >> > Metropolitan Museum of Art and the Guggenheim. There are excellent >> > Chinese and Indian restaurants in Lower Manhattan. >> >> Don't forget about Brooklyn in all this Manhattan praise :-). Consider >> the Brooklyn Botanic Garden. It's too late for cherries but the rose >> collections will be great. And the best pizza in New York (if you can >> get in) is at >> http://menupages.com/restaurantdetails.asp?areaid=0&restaurantid=31402&neighborhoodid=114&cuisineid=0 >> > > From johnl at iecc.com Sat May 31 22:58:50 2008 From: johnl at iecc.com (John Levine) Date: 1 Jun 2008 03:58:50 -0000 Subject: NANOG NYC Event In-Reply-To: <43661d390805312028u130046ddlc804e4615c83ba62@mail.gmail.com> Message-ID: <20080601035850.45405.qmail@simone.iecc.com> In article <43661d390805312028u130046ddlc804e4615c83ba62 at mail.gmail.com> you write: >I second the motion to recognize Dinosaur BBQ. All those in favor? Dinosaur is swell, but it's in Syracuse. Perhaps you could pick one that's reachable by subway instead. From mikelieman at gmail.com Sat May 31 23:00:26 2008 From: mikelieman at gmail.com (Mike Lieman) Date: Sun, 1 Jun 2008 00:00:26 -0400 Subject: NANOG NYC Event In-Reply-To: <20080601035850.45405.qmail@simone.iecc.com> References: <43661d390805312028u130046ddlc804e4615c83ba62@mail.gmail.com> <20080601035850.45405.qmail@simone.iecc.com> Message-ID: <43661d390805312100w4cb30f0bob3b3953aa392cac8@mail.gmail.com> Address: 646 W 131st St. New York, NY 10027 212-694-1777 Catering: 212-694-1777 NYC Directions: Dinosaur BBQ NYC is located on the corner of 131st St and 12th Ave. Just South of Fairway Market and North of the Cotton Club under the Riverside Drive Bridge. Exit 125th street off of the Henry Hudson Highway. The closest subway stop is the 1, at the intersection of Broadway and 125th St. On Sat, May 31, 2008 at 11:58 PM, John Levine wrote: > In article <43661d390805312028u130046ddlc804e4615c83ba62 at mail.gmail.com> you write: >>I second the motion to recognize Dinosaur BBQ. All those in favor? > > Dinosaur is swell, but it's in Syracuse. > > Perhaps you could pick one that's reachable by subway instead. > > > >