From jlewis at lewis.org Fri Aug 1 00:45:06 2008 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 1 Aug 2008 01:45:06 -0400 (EDT) Subject: Level3 BGP help Message-ID: If someone from Level3 could tell me why routes tagged with 65000:0 and/or 65000:1239 don't actually stop those routes from being advertised to 1239, I'd appreciate it. They show up in lg.level3.net with: Suppress_to_Peers Suppress_to_AS1239 but they also show up in other route servers with an as-path of 1239 3356 6364. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cidr-report at potaroo.net Fri Aug 1 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Aug 2008 22:00:05 +1000 (EST) Subject: BGP Update Report Message-ID: <200808011200.m71C05NU038203@wattle.apnic.net> BGP Update Report Interval: 30-Jun-08 -to- 31-Jul-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 122069 1.8% 98.8 -- SIFY-AS-IN Sify Limited 2 - AS4538 112661 1.6% 22.5 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS17488 80816 1.2% 60.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS5691 73841 1.1% 5680.1 -- MITRE-AS-5 - The MITRE Corporation 5 - AS1803 68104 1.0% 54.4 -- ICMNET-5 - Sprint 6 - AS6298 57728 0.8% 31.3 -- COX-PHX - Cox Communications Inc. 7 - AS10396 56155 0.8% 1039.9 -- COQUI-NET - DATACOM CARIBE, INC. 8 - AS7738 53571 0.8% 173.9 -- Telecomunicacoes da Bahia S.A. 9 - AS9051 52726 0.8% 323.5 -- IDM Autonomous System 10 - AS4766 50485 0.7% 57.0 -- KIXS-AS-KR Korea Telecom 11 - AS8866 47434 0.7% 148.2 -- BTC-AS Bulgarian Telecommunication Company Plc. 12 - AS17974 47379 0.7% 64.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS33783 43181 0.6% 261.7 -- EEPAD 14 - AS4788 40747 0.6% 19.0 -- TMNET-AS-AP TM Net, Internet Service Provider 15 - AS306 40457 0.6% 235.2 -- DNIC - DoD Network Information Center 16 - AS12455 39791 0.6% 523.6 -- JAMBONET 17 - AS8151 37280 0.5% 25.9 -- Uninet S.A. de C.V. 18 - AS3464 34641 0.5% 92.1 -- ASC-NET - Alabama Supercomputer Network 19 - AS9929 33311 0.5% 105.7 -- CNCNET-CN China Netcom Corp. 20 - AS9394 32523 0.5% 21.3 -- CRNET CHINA RAILWAY Internet(CRNET) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47467 26561 0.4% 13280.5 -- GRIFFEL Griffel AB 2 - AS27245 14477 0.2% 7238.5 -- HEIDRICK-CHICAGO - HEIDRICK 3 - AS30850 12500 0.2% 6250.0 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 4 - AS5691 73841 1.1% 5680.1 -- MITRE-AS-5 - The MITRE Corporation 5 - AS29910 5222 0.1% 5222.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 6 - AS39105 5002 0.1% 5002.0 -- CLASS-AS SC Class Computers And Service SRL 7 - AS44656 4902 0.1% 4902.0 -- HOLOSFIND-ROMANIA HOLOSFIND SRL 8 - AS22678 3945 0.1% 3945.0 -- OSDE 9 - AS23082 18507 0.3% 3701.4 -- MPHI - Michigan Public Health Institute 10 - AS28361 3311 0.1% 3311.0 -- 11 - AS44194 3261 0.1% 3261.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 12 - AS27786 2845 0.0% 2845.0 -- SSA SISTEMAS S.A. 13 - AS40627 4082 0.1% 2041.0 -- RC-COLO1 - RingCentral Inc 14 - AS5382 2033 0.0% 2033.0 -- TELESYSTEM-NET Planet Service Srl 15 - AS38513 1995 0.0% 1995.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 16 - AS36988 5752 0.1% 1917.3 -- MILLICOM-SL 17 - AS28542 1751 0.0% 1751.0 -- Gobierno del Estado de Coahuila 18 - AS30560 16921 0.2% 1692.1 -- GE-MS001 - General Electric Company 19 - AS36966 1672 0.0% 1672.0 -- Edgenet 20 - AS40256 6549 0.1% 1637.2 -- ACS-HCMS-ASN - Affiliated Computer Services, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 73669 1.0% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 63345 0.8% AS9583 -- SIFY-AS-IN Sify Limited 3 - 194.126.143.0/24 42847 0.6% AS9051 -- IDM Autonomous System 4 - 83.228.71.0/24 38724 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.128.192.0/18 25021 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 210.214.128.0/23 19650 0.3% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.214.144.0/24 17053 0.2% AS9583 -- SIFY-AS-IN Sify Limited 8 - 72.50.96.0/20 14955 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 9 - 63.84.91.0/24 13583 0.2% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 10 - 62.182.216.0/21 13292 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 11 - 91.203.160.0/22 13283 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 12 - 195.47.233.0/24 12480 0.2% AS30850 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 13 - 203.63.26.0/24 10716 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 14 - 196.42.0.0/20 9406 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 15 - 196.42.48.0/20 9360 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 216.255.56.0/21 9293 0.1% AS7106 -- OHIOBRIGHTNET - Com Net, Inc. 17 - 72.50.112.0/20 9263 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 18 - 202.150.80.0/20 8762 0.1% AS9251 -- SPEEDNET-AP PT Speed Internet Digital 19 - 210.214.26.0/24 6969 0.1% AS9583 -- SIFY-AS-IN Sify Limited 20 - 81.21.104.0/24 6805 0.1% AS31065 -- MCIT AS5536 -- Internet-Egypt 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 Aug 1 07:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Aug 2008 22:00:01 +1000 (EST) Subject: The Cidr Report Message-ID: <200808011200.m71C01ae038190@wattle.apnic.net> This report has been generated at Fri Aug 1 21:14:54 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-07-08 275453 173831 26-07-08 275442 173410 27-07-08 275750 173503 28-07-08 275756 173855 29-07-08 275931 173240 30-07-08 275991 174045 31-07-08 276919 172327 01-08-08 276746 172621 AS Summary 28973 Number of ASes in routing system 12245 Number of ASes announcing only one prefix 4989 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88348160 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'). --- 01Aug08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 277003 172671 104332 37.7% All ASes AS4538 4989 881 4108 82.3% ERX-CERNET-BKB China Education and Research Network Center AS6389 3204 268 2936 91.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2999 677 2322 77.4% ASN-QWEST - Qwest AS4755 1692 253 1439 85.0% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 40 1005 96.2% COVAD - Covad Communications Co. AS6298 1774 784 990 55.8% COX-PHX - Cox Communications Inc. AS22773 970 67 903 93.1% CCINET-2 - Cox Communications Inc. AS17488 1262 366 896 71.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1427 567 860 60.3% Uninet S.A. de C.V. AS4323 1487 678 809 54.4% TWTC - tw telecom holdings, inc. AS1785 1390 613 777 55.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 931 231 700 75.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1214 523 691 56.9% CABLEONE - CABLE ONE AS2386 1492 897 595 39.9% INS-AS - AT&T Data Communications Services AS18101 710 151 559 78.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS9498 661 107 554 83.8% BBIL-AP BHARTI BT INTERNET LTD. AS6478 1016 474 542 53.3% ATT-INTERNET3 - AT&T WorldNet Services AS4766 881 397 484 54.9% KIXS-AS-KR Korea Telecom AS6197 954 486 468 49.1% BATI-ATL - BellSouth Network Solutions, Inc AS4808 623 160 463 74.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7011 1001 548 453 45.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17676 524 82 442 84.4% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 129 436 77.2% VTR BANDA ANCHA S.A. AS855 587 156 431 73.4% CANET-ASN-4 - Bell Aliant AS9443 519 91 428 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1430 1004 426 29.8% ATT-INTERNET4 - AT&T WorldNet Services AS4134 830 436 394 47.5% CHINANET-BACKBONE No.31,Jin-rong Street AS4780 716 323 393 54.9% SEEDNET Digital United Inc. AS24560 542 150 392 72.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd. AS3602 454 78 376 82.8% AS3602-RTI - Rogers Telecom Inc. Total 37889 11617 26272 69.3% Top 30 total Possible Bogus Routes 14.14.14.0/24 AS577 BACOM - Bell Canada 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.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.246.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.23.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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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 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.165.102.0/24 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.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 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 91.205.12.0/22 AS33891 CORE-BACKBONE Core-Backbone GmbH 94.137.128.0/19 AS8804 REGIO-AS regio[.NET] Holding GmbH, Bahnhofstr. 8, 36157 Ebersburg 94.137.160.0/19 AS20771 DELTANET DeltaNet Autonomous System 94.153.0.0/16 AS15895 KSNET-AS Kyivstar GSM 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 116.90.0.0/18 AS38576 121.50.10.0/24 AS38236 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 AS2018 TENET-1 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.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 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 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.254.192.0/19 AS2116 ASN-CATCHCOM Catch Communications 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.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 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 - tw telecom holdings, 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.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, 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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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. 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 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 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.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.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 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 tme at multicasttech.com Fri Aug 1 08:05:57 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 1 Aug 2008 09:05:57 -0400 Subject: Fwd: [LN20080729.4147] RE: AS 28551 References: <20080731171024.GC72633@lacnic.net> Message-ID: <7B1FB434-0BD0-4C6F-B4E5-1594662CF95B@multicasttech.com> I think that 161.164.248.0/21 and AS 28551 may be hijacked. To summarize AS 28551 is announcing 161.164.248.0/21 28551 is assigned to LANIC but has not been assigned to a end user. 161.164.248.0/21 is assigned to WalMart 161.164.248.0/21 is currently routed through AS35681 - VINDAVA-AS - which is in Bucharest, Romania I think that this is a bogon. Regards Marshall P.S. I have asked WalMart about this, and received no response. Begin forwarded message: > From: Lucas Graciano > Date: July 31, 2008 1:10:25 PM EDT > To: Marshall Eubanks > Cc: LACNIC Hostmaster > Subject: Re: [LN20080729.4147] RE: AS 28551 > > Dear Sir, > > This AS number is under administration by NIC.MX, but is a resource > that is not allocated yet! > > Regards, > > Hostmaster // Registration Service > ======================================================== > > L A C N I C http://lacnic.net > Latin American and Caribbean Internet Addresses Registry > ======================================================== > > > On Tue, Jul 29, 2008 at 04:59:02AM -0400, Marshall Eubanks wrote: >> Hello; >> >> I contacted LANIC (read below) to see if they actually did register >> AS >> 28551. >> >> My question remains : Is there a reason for this ASN not to be in the >> LACNIC whois, or is this a rogue ASN ? >> >> Regards >> Marshall Eubanks >> >> >> On Jul 29, 2008, at 3:14 AM, Network Abuse wrote: >> >>> >>> ** This is an automatic message. ** >>> ** Please carefully read the information below. ** >>> >>> You have contacted LACNIC due to some abuse activity (spam, >>> hacking, etc), >>> from an IP address allocated or assigned by LACNIC. >>> >>> LACNIC is an RIR (Regional Internet Registry) for Latin America and >>> the Caribbean region. What that means is that LACNIC is responsible >>> for >>> the IP address space and ASN allocation/assignment in this region. >>> >>> As mentioned, the IP address in question was allocated by LACNIC to >>> some other organization or ISP in the region. So the abuse activity >>> originated in that organization's network, not in LACNIC. >>> >>> You should query our whois database to get information about the >>> source of this abuse activity and the appropriate network contact. >>> >>> LACNIC's whois is available at: >>> http://lacnic.net/cgi-bin/lacnic/whois >>> >>> or via the command line: >>> whois -h whois.lacnic.net [IP ADDRESS] >>> >>> Important Note: >>> >>> ---------------------------------------------------------------------- >>> Addresses allocated to "Comite Gestor da Internet no Brasil" are >>> those >>> allocated to the Brazilian NIR (Registro BR), and in this case you >>> might want to query their Whois database: >>> http://registro.br/cgi-bin/nicbr/whois >>> whois -h whois.nic.br [IP ADDRESS] >>> --------------------------------------------------------------------- >>> >>> Please note that LACNIC has no authority to investigate spam, >>> hacking >>> or any other kind of network abuse activity committed by other >>> organizations. Nor can we punish other organizations' users. >>> >>> More details are available at: http://lacnic.net/abuse >>> >>> If this information did not help you, please reply this message to >>> hostmaster at lacnic.net and keep the subject line. >>> >>> Regards, >>> LACNIC Hostmaster >>> >>> >>> >>> ----------Original Header >>> From tme at multicasttech.com Tue Jul 29 04:14:07 2008 >>> Return-Path: >>> X-Original-To: whois-contact at lacnic.net >>> Delivered-To: whois-contact at lacnic.net >>> Received: from localhost (localhost [127.0.0.1]) >>> by mail.lacnic.net (Postfix) with ESMTP id C6A23B9C3 >>> for ; Tue, 29 Jul 2008 04:14:07 -0300 >>> (BRT) >>> X-Virus-Scanned: amavisd-new at lacnic.net >>> X-Spam-Score: -2.407 >>> X-Spam-Level: >>> X-Spam-Status: No, score=-2.407 tagged_above=-99 required=4 >>> tests=[AWL=0.192, >>> BAYES_00=-2.599] >>> Received: from mail.lacnic.net ([127.0.0.1]) >>> by localhost (mail.lacnic.net [127.0.0.1]) (amavisd-new, port >>> 10024) >>> with ESMTP id 7B1tNXyA0p7h for ; >>> Tue, 29 Jul 2008 04:14:05 -0300 (BRT) >>> X-Greylist: delayed 3599 seconds by postgrey-1.27 at >>> mail.lacnic.net; Tue, 29 Jul 2008 04:14:04 BRT >>> Received: from multicasttech.com (lennon.multicasttech.com >>> [63.105.122.7]) >>> by mail.lacnic.net (Postfix) with ESMTP id DB5F5B9C0 >>> for ; Tue, 29 Jul 2008 04:14:04 -0300 >>> (BRT) >>> Received: from [63.105.122.7] (account marshall_eubanks HELO >>> [IPv6:::1]) >>> by multicasttech.com (CommuniGate Pro SMTP 3.4.8) >>> with ESMTP-TLS id 12277392 for whois-contact at lacnic.net; Tue, 29 >>> Jul 2008 02:14:04 -0400 >>> Message-Id: >>> From: Marshall Eubanks >>> To: whois-contact at lacnic.net >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> Content-Transfer-Encoding: 7bit >>> Mime-Version: 1.0 (Apple Message framework v926) >>> Subject: AS 28551 >>> Date: Tue, 29 Jul 2008 02:14:03 -0400 >>> X-Mailer: Apple Mail (2.926) >>> >>> >>> ----------Original Message >>> Hello; >>> >>> AS 28551 is in a ASN block assigned to LACNIC and is shwoing up in >>> my >>> BGP tables, >>> but a whois returns a blank : >>> >>> [tme at lennon mcast]$ lacnic_whois 28551 >>> [lacnic.net] >>> >>> % Joint Whois - whois.lacnic.net >>> % This server accepts single ASN, IPv4 or IPv6 queries >>> >>> % LACNIC resource: whois.lacnic.net >>> >>> >>> % Copyright LACNIC lacnic.net >>> % The data below is provided for information purposes >>> % and to assist persons in obtaining information about or >>> % related to AS and IP numbers registrations >>> % By submitting a whois query, you agree to use this data >>> % only for lawful purposes. >>> % 2008-07-29 03:13:17 (BRT -03:00) >>> >>> % No match for "AS28551" >>> >>> % whois.lacnic.net accepts only direct match queries. >>> % Types of queries are: POCs, ownerid, CIDR blocks, IP >>> % and AS numbers. >>> >>> Is there a reason for this, or is this a rogue ASN ? >>> >>> Regards >>> Marshall Eubanks >>> From ww at styx.org Fri Aug 1 08:21:25 2008 From: ww at styx.org (William Waites) Date: Fri, 1 Aug 2008 15:21:25 +0200 Subject: [LN20080729.4147] RE: AS 28551 In-Reply-To: <7B1FB434-0BD0-4C6F-B4E5-1594662CF95B@multicasttech.com> References: <20080731171024.GC72633@lacnic.net> <7B1FB434-0BD0-4C6F-B4E5-1594662CF95B@multicasttech.com> Message-ID: Le 08-08-01 ? 15:05, Marshall Eubanks a ?crit : > I think that 161.164.248.0/21 and AS 28551 may be hijacked. traceroute to 161.164.248.1 (161.164.248.1), 64 hops max, 40 byte packets 7 tengige0-3-0-3.auvtr1.Aubervilliers.opentransit.net (193.251.241.253) 78.728 ms 79.154 ms 79.548 ms 8 tengige0-3-0-1.ffttr1.FrankfurtAmMain.opentransit.net (193.251.241.254) 85.894 ms 86.476 ms 86.701 ms 9 64.208.110.229 (64.208.110.229) 86.312 ms 87.509 ms 87.463 ms 10 Alestra-S-De-R-L-De-CV-San-Pedro-Garza.so-0-2-0.ar1.MEX1.gblx.net (208.48.33.78) 266.280 ms Alestra-S-De-R-L-De-CV-Lago- Zurich.so-0-2-2.ar1.MEX1.gblx.net (64.215.25.70) 262.566 ms Alestra-S- De-R-L-De-CV-San-Pedro-Garza.so-1-1-0.ar1.MEX1.gblx.net (208.48.238.98) 473.559 ms 11 host-201-151-29-61.block.alestra.net.mx (201.151.29.61) 260.021 ms 433.502 ms 259.899 ms 12 host-201-151-29-42.block.alestra.net.mx (201.151.29.42) 661.863 ms 256.985 ms 434.032 ms 13 * * * As well AS paths shown from route-views.ip.att.net end with AS11172 (alestra) then AS28551. Perhaps Walmart is providing Internet access for its maquilladoras? ;) Cheers, -w From paul at clubi.ie Fri Aug 1 09:53:34 2008 From: paul at clubi.ie (Paul Jakma) Date: Fri, 1 Aug 2008 15:53:34 +0100 (BST) Subject: Hardware capture platforms In-Reply-To: References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B72F.4070303@aset.com> Message-ID: On Fri, 1 Aug 2008, Paul Jakma wrote: > GigE is PtP at the physical-layer by the IEEE 802.3ad specification. It's Gah, I meant 802.3ab, of course. > just not possible to have a dumb, GigE hub. You have to have a switch that > can be told to L2-forward everything to one or more ports (e.g. through a > port-mirroring feature, or by disabling MAC learning). > > Also, though probably not terribly relevant, various switches have various > bugs/malfeatures that cause them to consume certain kinds of frames rather > than forward them (e.g. consuming all or certain kinds of ISO frames). regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: Anything is possible, unless it's not. From paul at clubi.ie Fri Aug 1 09:46:41 2008 From: paul at clubi.ie (Paul Jakma) Date: Fri, 1 Aug 2008 15:46:41 +0100 (BST) Subject: Hardware capture platforms In-Reply-To: <4890B72F.4070303@aset.com> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B72F.4070303@aset.com> Message-ID: On Wed, 30 Jul 2008, Jon Kibler wrote: > However, there is a problem with your specification: No hub (that I am > aware of) can do 1Gbps. All hubs are 10/100 AFAIK. GigE is PtP at the physical-layer by the IEEE 802.3ad specification. It's just not possible to have a dumb, GigE hub. You have to have a switch that can be told to L2-forward everything to one or more ports (e.g. through a port-mirroring feature, or by disabling MAC learning). Also, though probably not terribly relevant, various switches have various bugs/malfeatures that cause them to consume certain kinds of frames rather than forward them (e.g. consuming all or certain kinds of ISO frames). regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: lisp, v.: To call a spade a thpade. From craigp at tozz.net Fri Aug 1 10:13:04 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Fri, 1 Aug 2008 11:13:04 -0400 Subject: Level3 BGP help In-Reply-To: References: Message-ID: <20080801151304.GB16974@eagle.deardorff.com> * Jon Lewis was thought to have said: > If someone from Level3 could tell me why routes tagged with > > 65000:0 and/or 65000:1239 don't actually stop those routes from being > advertised to 1239, I'd appreciate it. You should start to see them disappear shortly. On route-views they're starting to show as history entries. Bad community list on one router was the issue. regards -Craig From john at sackheads.org Fri Aug 1 10:22:41 2008 From: john at sackheads.org (John Payne) Date: Fri, 1 Aug 2008 11:22:41 -0400 Subject: Level3 BGP help In-Reply-To: <20080801151304.GB16974@eagle.deardorff.com> References: <20080801151304.GB16974@eagle.deardorff.com> Message-ID: On Aug 1, 2008, at 11:13 AM, Craig Pierantozzi wrote: > * Jon Lewis was thought to have said: > >> If someone from Level3 could tell me why routes tagged with >> >> 65000:0 and/or 65000:1239 don't actually stop those routes from being >> advertised to 1239, I'd appreciate it. > > You should start to see them disappear shortly. On route-views they're > starting to show as history entries. Bad community list on one router > was the issue. I thought perhaps we'd found the reason behind the tax^surcharge in the other thread... a community tax :) From craigp at tozz.net Fri Aug 1 11:02:14 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Fri, 1 Aug 2008 12:02:14 -0400 Subject: Level3 BGP help In-Reply-To: References: <20080801151304.GB16974@eagle.deardorff.com> Message-ID: <20080801160214.GA23215@eagle.deardorff.com> * John Payne was thought to have said: > > I thought perhaps we'd found the reason behind the tax^surcharge in > the other thread... a community tax :) No, that's a pass through charge that goes to epperson. From sil at infiltrated.net Fri Aug 1 11:52:04 2008 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 1 Aug 2008 11:52:04 -0500 Subject: Covad VOA contact Message-ID: <20080801165204.GA10474@infiltrated.net> Hey all sorry for the noise, can someone put me in touch with someone with a clue @ Covad hopefully on their VoA side. Attempting a resolution of some circuits and don't care to escalate things right now. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA #579 (FW+VPN v4.1) SGFE #574 (FW+VPN v4.1) CEH/CNDA, CHFI "Experience hath shewn, that even under the best forms (of government) those entrusted with power have, in time, and by slow operations, perverted it into tyranny." Thomas Jefferson wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From stu at spacehopper.org Fri Aug 1 12:04:32 2008 From: stu at spacehopper.org (Stuart Henderson) Date: Fri, 1 Aug 2008 17:04:32 +0000 (UTC) Subject: Software router state of the art References: <488E0A56.6020801@thewybles.com> <200807281823.m6SIN0QC005897@aurora.sol.net> Message-ID: On 2008-07-28, Joe Greco wrote: >> I have yet to look into *BSD based solutions, but hear very good things >> about firewall performance. I don't know about BGP/OSPF/MPLS etc support >> on FreeBSD but am going to wager a guess its on par with Linux if not >> better. > > The underlying OS is responsible for packet forwarding, but none of them > do any significant routing protocols natively. OpenBSD has OpenOSPFD/OpenBGPD in the base OS rather than as a port/ package, so it's fully coupled with any kernel changes (and supports some things missing from the FreeBSD port). From cscora at apnic.net Fri Aug 1 13:07:59 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Aug 2008 04:07:59 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200808011807.m71I7xol029492@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 02 Aug, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 265184 Prefixes after maximum aggregation: 129461 Deaggregation factor: 2.05 Unique aggregates announced to Internet: 129300 Total ASes present in the Internet Routing Table: 28821 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25126 Origin ASes announcing only one prefix: 12150 Transit ASes present in the Internet Routing Table: 3695 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 21 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 572 Unregistered ASNs in the Routing Table: 211 Number of 32-bit ASNs allocated by the RIRs: 53 Prefixes from 32-bit ASNs in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 791 Number of addresses announced to Internet: 1888212576 Equivalent to 112 /8s, 139 /16s and 214 /24s Percentage of available address space announced: 50.9 Percentage of allocated address space announced: 61.9 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.0 Total number of prefixes smaller than registry allocations: 129790 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 60837 Total APNIC prefixes after maximum aggregation: 22712 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 57817 Unique aggregates announced from the APNIC address blocks: 26028 APNIC Region origin ASes present in the Internet Routing Table: 3320 APNIC Prefixes per ASN: 17.41 APNIC Region origin ASes announcing only one prefix: 878 APNIC Region transit ASes present in the Internet Routing Table: 513 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 369846304 Equivalent to 22 /8s, 11 /16s and 104 /24s Percentage of available APNIC address space announced: 78.7 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: 121736 Total ARIN prefixes after maximum aggregation: 65145 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 91199 Unique aggregates announced from the ARIN address blocks: 34975 ARIN Region origin ASes present in the Internet Routing Table: 12333 ARIN Prefixes per ASN: 7.39 ARIN Region origin ASes announcing only one prefix: 4760 ARIN Region transit ASes present in the Internet Routing Table: 1172 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 359625120 Equivalent to 21 /8s, 111 /16s and 113 /24s Percentage of available ARIN address space announced: 73.9 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: 57109 Total RIPE prefixes after maximum aggregation: 34644 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 52259 Unique aggregates announced from the RIPE address blocks: 35059 RIPE Region origin ASes present in the Internet Routing Table: 11666 RIPE Prefixes per ASN: 4.48 RIPE Region origin ASes announcing only one prefix: 6118 RIPE Region transit ASes present in the Internet Routing Table: 1753 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 368008320 Equivalent to 21 /8s, 239 /16s and 92 /24s Percentage of available RIPE address space announced: 84.4 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: 20879 Total LACNIC prefixes after maximum aggregation: 5274 LACNIC Deaggregation factor: 3.96 Prefixes being announced from the LACNIC address blocks: 19108 Unique aggregates announced from the LACNIC address blocks: 10762 LACNIC Region origin ASes present in the Internet Routing Table: 971 LACNIC Prefixes per ASN: 19.68 LACNIC Region origin ASes announcing only one prefix: 316 LACNIC Region transit ASes present in the Internet Routing Table: 162 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 54027264 Equivalent to 3 /8s, 56 /16s and 100 /24s Percentage of available LACNIC address space announced: 53.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: 4054 Total AfriNIC prefixes after maximum aggregation: 1210 AfriNIC Deaggregation factor: 3.35 Prefixes being announced from the AfriNIC address blocks: 4420 Unique aggregates announced from the AfriNIC address blocks: 1902 AfriNIC Region origin ASes present in the Internet Routing Table: 245 AfriNIC Prefixes per ASN: 18.04 AfriNIC Region origin ASes announcing only one prefix: 78 AfriNIC Region transit ASes present in the Internet Routing Table: 47 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12521984 Equivalent to 0 /8s, 191 /16s and 18 /24s Percentage of available AfriNIC address space announced: 37.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 1688 345 177 Videsh Sanchar Nigam Ltd. Aut 17488 1267 87 91 Hathway IP Over Cable Interne 9583 1146 87 486 Sify Limited 4766 855 6390 348 Korea Telecom (KIX) 4134 831 13619 339 CHINANET-BACKBONE 23577 830 35 702 Korea Telecom (ATM-MPLS) 4780 712 353 64 Digital United Inc. 18101 711 167 33 Reliance Infocom Ltd Internet 9498 663 291 54 BHARTI BT INTERNET LTD. 4808 623 1120 138 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 6389 3205 3359 213 bellsouth.net, inc. 209 2982 3860 621 Qwest 6298 1778 270 769 Cox Communicatons 4323 1491 1062 380 Time Warner Telecom 2386 1486 673 880 AT&T Data Communications Serv 7018 1409 5829 987 AT&T WorldNet Services 1785 1390 478 102 AppliedTheory Corporation 11492 1215 151 23 Cable One 20115 1115 1080 572 Charter Communications 18566 1045 296 10 Covad 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 414 1792 372 TDC Tele Danmark 3215 358 2756 106 France Telecom Transpac 8452 347 188 11 TEDATA 3301 332 1460 303 TeliaNet Sweden 3320 322 7047 270 Deutsche Telekom AG 8866 316 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 287 270 38 Bezeq International 680 274 2047 264 DFN-IP service G-WiN 6746 267 125 242 Dynamic Network Technologies, 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 1447 2591 226 UniNet S.A. de C.V. 11830 612 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 474 234 62 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 417 85 48 ENTEL CHILE S.A. 11172 408 118 71 Servicios Alestra S.A de C.V 10620 405 106 58 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 329 23 104 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 479 62 20 LINKdotNET AS number 20858 398 34 3 EgyNet 3741 268 855 223 The Internet Solution 2018 212 213 131 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5713 129 540 74 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 33776 115 6 3 Starcomms Nigeria Limited 29571 107 13 8 Ci Telecom Autonomous system 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 3205 3359 213 bellsouth.net, inc. 209 2982 3860 621 Qwest 6298 1778 270 769 Cox Communicatons 4755 1688 345 177 Videsh Sanchar Nigam Ltd. Aut 4323 1491 1062 380 Time Warner Telecom 2386 1486 673 880 AT&T Data Communications Serv 8151 1447 2591 226 UniNet S.A. de C.V. 7018 1409 5829 987 AT&T WorldNet Services 1785 1390 478 102 AppliedTheory Corporation 17488 1267 87 91 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 209 2982 2361 Qwest 4755 1688 1511 Videsh Sanchar Nigam Ltd. Aut 1785 1390 1288 AppliedTheory Corporation 8151 1447 1221 UniNet S.A. de C.V. 11492 1215 1192 Cable One 17488 1267 1176 Hathway IP Over Cable Interne 4323 1491 1111 Time Warner Telecom 18566 1045 1035 Covad Communications 6298 1778 1009 Cox Communicatons 22773 969 906 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.48.244.0/23 7843 Adelphia Corp. 24.48.246.0/24 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.23.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 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:17 /11:46 /12:147 /13:294 /14:520 /15:1051 /16:10043 /17:4339 /18:7536 /19:15968 /20:18587 /21:18269 /22:22879 /23:23873 /24:138870 /25:833 /26:1022 /27:758 /28:88 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2034 3205 bellsouth.net, inc. 6298 1752 1778 Cox Communicatons 209 1734 2982 Qwest 11492 1196 1215 Cable One 2386 1179 1486 AT&T Data Communications Serv 17488 1077 1267 Hathway IP Over Cable Interne 1785 1047 1390 AppliedTheory Corporation 4755 1039 1688 Videsh Sanchar Nigam Ltd. Aut 18566 1026 1045 Covad Communications 6478 1007 1016 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:128 12:2105 13:2 14:1 15:22 16:3 17:5 18:13 20:35 24:1098 32:60 38:471 40:92 41:698 43:1 44:2 47:12 52:3 55:3 56:3 57:25 58:527 59:511 60:456 61:990 62:1201 63:2039 64:3284 65:2381 66:3510 67:1225 68:746 69:2291 70:822 71:118 72:2008 73:6 74:1071 75:153 76:305 77:757 78:765 79:212 80:979 81:847 82:602 83:376 84:567 85:957 86:407 87:687 88:338 89:1315 90:31 91:1402 92:237 93:721 94:89 96:52 97:41 98:290 99:4 112:1 113:1 114:76 115:28 116:903 117:328 118:189 119:446 120:59 121:571 122:807 123:371 124:904 125:1175 128:360 129:198 130:135 131:412 132:66 133:9 134:186 135:33 136:223 137:95 138:146 139:93 140:498 141:98 142:405 143:321 144:393 145:51 146:371 147:157 148:519 149:194 150:125 151:182 152:137 153:136 154:10 155:252 156:173 157:291 158:187 159:239 160:274 161:118 162:214 163:155 164:517 165:454 166:316 167:330 168:624 169:139 170:422 171:32 172:10 188:1 189:362 190:2243 192:5787 193:4125 194:3239 195:2547 196:1031 198:3725 199:3309 200:5566 201:1473 202:7666 203:8056 204:3979 205:2136 206:2359 207:2761 208:3481 209:3493 210:2590 211:1078 212:1425 213:1602 214:161 215:49 216:4517 217:1243 218:343 219:428 220:1059 221:455 222:312 End of report From jose at onzra.com Fri Aug 1 15:20:45 2008 From: jose at onzra.com (Jose Avila) Date: Fri, 1 Aug 2008 13:20:45 -0700 Subject: Cache Poisoning Detection via ONZRA's CacheAudit Message-ID: In light of new attack vectors DNS Cache Poisoning discovered by Dan Kaminsky, ONZRA has developed a free Open Source (BSD License) tool called CacheAudit. This tool allows recursive providers to detect cache poisoning events using cache dumps from their DNS servers. Along with releasing this tool, ONZRA has also released a white paper describing the validation process. Main Tool Page: http://www.onzra.com/cacheaudit.html White Paper: http://www.onzra.com/RecursiveDNSCacheAuditingWhitepaper.pdf Jose -- Jose Avila III ONZRA www.onzra.com From black at csulb.edu Fri Aug 1 17:25:46 2008 From: black at csulb.edu (Matthew Black) Date: Fri, 01 Aug 2008 15:25:46 -0700 Subject: Cache Poisoning Detection via ONZRA's CacheAudit In-Reply-To: References: Message-ID: On Fri, 1 Aug 2008 13:20:45 -0700 Jose Avila wrote: > In light of new attack vectors DNS Cache Poisoning discovered by Dan > Kaminsky, ONZRA has developed a free Open Source (BSD License) tool > called CacheAudit. This tool allows recursive providers to detect cache >poisoning events using cache dumps from their DNS servers. Along with >releasing this tool, ONZRA has also released a white paper describing the >validation process. > > Main Tool Page: http://www.onzra.com/cacheaudit.html > White Paper: http://www.onzra.com/RecursiveDNSCacheAuditingWhitepaper.pdf > Main Tool Page: http://www.onzra.com/cacheaudit.html LOL. Now that's funny! I get a completely black screen with Firefox and IE. I briefly glanced at the HTML src code (CTRL-U) but don't want to burn brain cells figuring out what you have to say. matthew black network services california state university, long beach From jose at onzra.com Fri Aug 1 17:34:18 2008 From: jose at onzra.com (Jose Avila) Date: Fri, 1 Aug 2008 15:34:18 -0700 Subject: Cache Poisoning Detection via ONZRA's CacheAudit In-Reply-To: References: Message-ID: Issue should be corrected. Thanks, Jose On Aug 1, 2008, at 3:25 PM, Matthew Black wrote: > On Fri, 1 Aug 2008 13:20:45 -0700 > Jose Avila wrote: >> In light of new attack vectors DNS Cache Poisoning discovered by >> Dan Kaminsky, ONZRA has developed a free Open Source (BSD License) >> tool called CacheAudit. This tool allows recursive providers to >> detect cache poisoning events using cache dumps from their DNS >> servers. Along with releasing this tool, ONZRA has also released a >> white paper describing the validation process. >> Main Tool Page: http://www.onzra.com/cacheaudit.html >> White Paper: http://www.onzra.com/RecursiveDNSCacheAuditingWhitepaper.pdf > > > >> Main Tool Page: http://www.onzra.com/cacheaudit.html > > LOL. Now that's funny! I get a completely black screen > with Firefox and IE. I briefly glanced at the HTML src > code (CTRL-U) but don't want to burn brain cells figuring > out what you have to say. > > matthew black > network services > california state university, long beach > From amwinckles at yahoo.co.uk Fri Aug 1 17:54:05 2008 From: amwinckles at yahoo.co.uk (Adrian Winckles) Date: Fri, 1 Aug 2008 22:54:05 +0000 (GMT) Subject: Test Cases for Network Management Message-ID: <828121.53219.qm@web25216.mail.ukl.yahoo.com> Hi Everyone Does anyone have any network management test cases or templates (particularly based around fault management, performance and security) which I could have access to help with some evaluation of some open source network management platforms for SME clients. Ideally test cases which support IP based networks (both local and wide area) and Cisco/Nortel equipment would be excellent. Many thanks in advance Adrian __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html From j at arpa.com Fri Aug 1 19:54:41 2008 From: j at arpa.com (jamie) Date: Fri, 01 Aug 2008 19:54:41 -0500 Subject: [to nanog-page@] ATT/AS7018 eng? Message-ID: ?When in Rome...? Any backbone eng?s (access or ipfr) from as7018 present? An off list reply leading to problem mitigation wins you a case of beer . . . ;) -jamie -- jamie rishaw // arpa From cgucker at onesc.net Fri Aug 1 20:05:40 2008 From: cgucker at onesc.net (Charles Gucker) Date: Fri, 1 Aug 2008 21:05:40 -0400 Subject: Sprint Looking Glass Message-ID: Greetings, Earlier today, I was tying to determine what local preferences Sprint uses within their network for peers vs customers ... Long story short, their Looking Glass only allows for: ping traceroute bgp dampened bgp flap-statistics But not 'bgp X.X.X.X' which can be quite frustrating. The customer local preferences are within their community guide, but they do not state that of a peer. Anybody find an alternative means to get this type of information, short of emailing bgp-adm at sprint.net ? (I did email them and have yet to get a response) I also called the customer service group who were kind, but clueless about the question, forget the answer. If anybody from Sprint is reading this and can aid in getting 'show ip bgp X.X.X.X' re-enabled on the Looking Glass, I would be most grateful. charles From jra at baylink.com Sat Aug 2 00:16:19 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Sat, 2 Aug 2008 01:16:19 -0400 Subject: Yahoo mail abuse contact? Message-ID: <20080802051619.GA3286@cgi.jachomes.com> Randy Cassingham at This Is True is complaining in his newsletter that he has something like 15K undeliverables to Yahoo email addresses, because, as he understands it, some of those people clicked Yahoo's 'This is Spam' button, and he can't find a way off the list. Anyone got a pointer to Yahoo closed-loop stuff I can point him at? 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. -- (Josef Stalin) From frnkblk at iname.com Sat Aug 2 09:12:10 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sat, 2 Aug 2008 09:12:10 -0500 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <4891DE62.9000202@zill.net> References: <4891DE62.9000202@zill.net> Message-ID: At least they didn't label it a fuel surcharge. =) Frank -----Original Message----- From: Patrick Giagnocavo [mailto:patrick at zill.net] Sent: Thursday, July 31, 2008 10:47 AM To: nanog at nanog.org Subject: Level3 tries cell-phone style billing scam on customers Today I looked at my most recent bill from Level3. They are now assessing a 2.5% surcharge, which is listed as "Taxes" on the bandwidth bill I have. In the state of PA, telecoms services are explicitly not taxable. When you call Level3 billing, they admit in their recorded message it is not a tax at all, but a surcharge, and if you want to dispute it you are supposed to quote back their own contract terms to them via email (i.e. you cannot reach a human). I would expect this kind of scamminess from Verizon's cell-phone billing, but a contract is a contract and I can see no provision for arbitrarily tacking on fees, illegally labeling them as "taxes" and then putting the onus on you to prove that they can't charge you. Anyone else seeing this same behavior from Level3? (It seems that the larger a telecom company gets, the more they want to act like a scum-sucking ILEC.) --Patrick From tomb at byrneit.net Sat Aug 2 13:15:06 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 2 Aug 2008 11:15:06 -0700 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: References: <4891DE62.9000202@zill.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F3FC@pascal.zaphodb.org> There's a big difference between the airlines hiking fares for future flights, which you can see when searching, and choose the competition; and companies adding "surcharges" to pre-existing contracts, some with terms and penalties for termination; all of which have a relatively high switching cost. This is a way for them to raise prices above what they contracted for, while preventing termination of contracts for cause. It's sleazy. -----Original Message----- From: Frank Bulk - iNAME [mailto:frnkblk at iname.com] Sent: Saturday, August 02, 2008 10:12 AM To: 'Patrick Giagnocavo'; nanog at nanog.org Subject: RE: Level3 tries cell-phone style billing scam on customers At least they didn't label it a fuel surcharge. =) Frank -----Original Message----- From: Patrick Giagnocavo [mailto:patrick at zill.net] Sent: Thursday, July 31, 2008 10:47 AM To: nanog at nanog.org Subject: Level3 tries cell-phone style billing scam on customers Today I looked at my most recent bill from Level3. They are now assessing a 2.5% surcharge, which is listed as "Taxes" on the bandwidth bill I have. In the state of PA, telecoms services are explicitly not taxable. When you call Level3 billing, they admit in their recorded message it is not a tax at all, but a surcharge, and if you want to dispute it you are supposed to quote back their own contract terms to them via email (i.e. you cannot reach a human). I would expect this kind of scamminess from Verizon's cell-phone billing, but a contract is a contract and I can see no provision for arbitrarily tacking on fees, illegally labeling them as "taxes" and then putting the onus on you to prove that they can't charge you. Anyone else seeing this same behavior from Level3? (It seems that the larger a telecom company gets, the more they want to act like a scum-sucking ILEC.) --Patrick No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.10/1586 - Release Date: 8/1/2008 6:59 PM From jam at zoidtechnologies.com Sat Aug 2 19:24:29 2008 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Sat, 2 Aug 2008 20:24:29 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <70D072392E56884193E3D2DE09C097A9F3FC@pascal.zaphodb.org> References: <4891DE62.9000202@zill.net> <70D072392E56884193E3D2DE09C097A9F3FC@pascal.zaphodb.org> Message-ID: <20080803002428.GA4670@zoidtechnologies.com> On Sat, Aug 02, 2008 at 11:15:06AM -0700, Tomas L. Byrnes wrote: > There's a big difference between the airlines hiking fares for future > flights, which you can see when searching, and choose the competition; > and companies adding "surcharges" to pre-existing contracts, some with > terms and penalties for termination; all of which have a relatively high > switching cost. > > This is a way for them to raise prices above what they contracted for, > while preventing termination of contracts for cause. > > It's sleazy. > > agreed. however, is there a provision in the contract that allows the rates, fees, etc to be changed without notice? regards, jam From patrick at ianai.net Sat Aug 2 19:38:16 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 2 Aug 2008 20:38:16 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <20080803002428.GA4670@zoidtechnologies.com> References: <4891DE62.9000202@zill.net> <70D072392E56884193E3D2DE09C097A9F3FC@pascal.zaphodb.org> <20080803002428.GA4670@zoidtechnologies.com> Message-ID: <72BEE226-4B87-4B4B-B142-1C5AAFF6A7A8@ianai.net> On Aug 2, 2008, at 8:24 PM, Jeff MacDonald wrote: > On Sat, Aug 02, 2008 at 11:15:06AM -0700, Tomas L. Byrnes wrote: >> There's a big difference between the airlines hiking fares for future >> flights, which you can see when searching, and choose the >> competition; >> and companies adding "surcharges" to pre-existing contracts, some >> with >> terms and penalties for termination; all of which have a relatively >> high >> switching cost. >> >> This is a way for them to raise prices above what they contracted >> for, >> while preventing termination of contracts for cause. >> >> It's sleazy. > > agreed. > > however, is there a provision in the contract that allows the rates, > fees, > etc to be changed without notice? Usually there is something about having to pay whatever taxes & legally mandated fees there are no matter what. Which is probably why they called it a "tax", even though it isn't. (No comments on what that says about L3.) -- TTFN, patrick From bicknell at ufp.org Mon Aug 4 07:52:48 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 Aug 2008 08:52:48 -0400 Subject: ARIN Advisory Council wants your input. Message-ID: <20080804125247.GA8306@ussenterprise.ufp.org> Dear NANOG Community: ARIN has two proposals currently active that may have significant operational impact on *your network* as the IPv4 free pool depletes. 2008-2 "IPv4 Transfer Policy Proposal" which would allow the transfer of the right to use an IP block. 2008-5 "Dedicated IPv4 block to facilitate IPv6 deployment" would set aside some IPv4 space to be used only to assist in the transition to IPv6. Please see http://www.arin.net/policy/proposals/proposal_archive.html for complete information. The place where discussions on proposed ARIN policies takes place is the ARIN Public Policy Mailing list . You're encouraged to join the list, and observe or participate as you see fit. Additionally, you're encouraged to attend the ARIN meeting which will be colocated with the NANOG meeting this fall in Los Angeles. The Advisory Council has the task of editing proposal 2008-2. There are many complex technical and political considerations that are related to this proposal, and the ARIN Advisory Council values the input of all community members and stakeholders. The ARIN Advisory Council will shortly be publishing a questionnaire on ppml@ to help gauge community sentiments on the aforementioned considerations. In order to keep a lid on ballot box stuffing activities, ppml subscribers will each be given a token to allow them to weigh in once on the survey. The survey is anonymous; no record of how or whether particular individuals responded will be preserved. If you'd like to be in on this survey, *now* is the time to subscribe to ppml at arin.net. Information on how to subscribe is located at http://www.arin.net/mailing_lists/index.html Thank you for your time and input, on behalf of the ARIN Advisory Council. --- Leo Bicknell, ARIN Advisory Council Chair -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From randy at psg.com Mon Aug 4 08:20:32 2008 From: randy at psg.com (Randy Bush) Date: Mon, 04 Aug 2008 22:20:32 +0900 Subject: ARIN Advisory Council wants your input. In-Reply-To: <20080804125247.GA8306@ussenterprise.ufp.org> References: <20080804125247.GA8306@ussenterprise.ufp.org> Message-ID: <48970220.7080707@psg.com> > 2008-2 "IPv4 Transfer Policy Proposal" which would allow the > transfer of the right to use an IP block. you may find it interesting to compare this to apnic's proposal http://www.apnic.net/policy/discussions/prop-050-v003.txt and ripe's http://www.ripe.net/ripe/draft-documents/ripe-424-draft2007-08.html randy From jra at baylink.com Mon Aug 4 11:24:22 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 4 Aug 2008 12:24:22 -0400 Subject: Is Usenet actually dead? Message-ID: <20080804162422.GL11750@cgi.jachomes.com> Opinion pieces in Wired and AG's grandstanding by throwing babies out with bathwater notwithstanding, a query from a cow-orker caused me to wonder: is there still anyplace to get a Usenet feed from these days that isn't {Giga,Super,etc}News? I want to pull maybe 30 or 40 tech groups into my own server for the 5 or 6 people in my IT group. In lieu of How It Used To Be, does anyone have data or anecdotes on which of the commercial providers will let me run a server in-house? Off-list is fine; I can summarize if anyone really cares anymore. :-) 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. -- (Josef Stalin) From ge at linuxbox.org Mon Aug 4 11:26:44 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 4 Aug 2008 11:26:44 -0500 (CDT) Subject: Is Usenet actually dead? In-Reply-To: <20080804162422.GL11750@cgi.jachomes.com> References: <20080804162422.GL11750@cgi.jachomes.com> Message-ID: Avi Freedman runs a decent service. Gadi. On Mon, 4 Aug 2008, Jay R. Ashworth wrote: > Opinion pieces in Wired and AG's grandstanding by throwing babies out > with bathwater notwithstanding, a query from a cow-orker caused me to > wonder: is there still anyplace to get a Usenet feed from these days > that isn't {Giga,Super,etc}News? I want to pull maybe 30 or 40 tech > groups into my own server for the 5 or 6 people in my IT group. > > In lieu of How It Used To Be, does anyone have data or anecdotes on > which of the commercial providers will let me run a server in-house? > > Off-list is fine; I can summarize if anyone really cares anymore. :-) > > 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. > -- (Josef Stalin) > From fw at deneb.enyo.de Mon Aug 4 15:19:16 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 22:19:16 +0200 Subject: Is Usenet actually dead? In-Reply-To: <20080804162422.GL11750@cgi.jachomes.com> (Jay R. Ashworth's message of "Mon, 4 Aug 2008 12:24:22 -0400") References: <20080804162422.GL11750@cgi.jachomes.com> Message-ID: <87vdyg354r.fsf@mid.deneb.enyo.de> * Jay R. Ashworth: > Opinion pieces in Wired and AG's grandstanding by throwing babies out > with bathwater notwithstanding, a query from a cow-orker caused me to > wonder: is there still anyplace to get a Usenet feed from these days > that isn't {Giga,Super,etc}News? I want to pull maybe 30 or 40 tech > groups into my own server for the 5 or 6 people in my IT group. You should be able to get the Big 8 (without any binary junk) fairly easily. Finding someone who manages your subscriptions using GUP (or even manually *gasp*) could be more difficult, though, so receiving a subset is likely not an option. (I haven't got a Big 8 feed to offer, I'm sorry. The regional ISP I use offers an NNTP feed managed by GUP.) From jra at baylink.com Mon Aug 4 15:33:56 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 4 Aug 2008 16:33:56 -0400 Subject: Is Usenet actually dead? In-Reply-To: <87vdyg354r.fsf@mid.deneb.enyo.de> References: <20080804162422.GL11750@cgi.jachomes.com> <87vdyg354r.fsf@mid.deneb.enyo.de> Message-ID: <20080804203356.GI11750@cgi.jachomes.com> On Mon, Aug 04, 2008 at 10:19:16PM +0200, Florian Weimer wrote: > * Jay R. Ashworth: > > Opinion pieces in Wired and AG's grandstanding by throwing babies out > > with bathwater notwithstanding, a query from a cow-orker caused me to > > wonder: is there still anyplace to get a Usenet feed from these days > > that isn't {Giga,Super,etc}News? I want to pull maybe 30 or 40 tech > > groups into my own server for the 5 or 6 people in my IT group. > > You should be able to get the Big 8 (without any binary junk) fairly > easily. Finding someone who manages your subscriptions using GUP (or > even manually *gasp*) could be more difficult, though, so receiving a > subset is likely not an option. Some offlist chatter suggests it might not be that difficult; I'm investigating more deeply and will report what I can. :-) How much *is* Big8 a day these days, though, a gig? I have a 10MBs hose... 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. -- (Josef Stalin) From ge at linuxbox.org Tue Aug 5 04:22:46 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 5 Aug 2008 04:22:46 -0500 (CDT) Subject: EFF tool to check bandwidth throttling Message-ID: Story is here: http://www.webmonkey.com/blog/Switzerland%3A_EFF_Software_Helps_Track_ISP_Bandwidth_Throttling The tool is called... Switzerland. Gadi. From kuenzler at init7.net Tue Aug 5 05:10:39 2008 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 05 Aug 2008 12:10:39 +0200 Subject: EFF tool to check bandwidth throttling In-Reply-To: References: Message-ID: <4898271F.9060300@init7.net> Gadi Evron schrieb: > Story is here: > http://www.webmonkey.com/blog/Switzerland%3A_EFF_Software_Helps_Track_ISP_Bandwidth_Throttling > > The tool is called... Switzerland. For the Swiss it's kinda strange ... and, the initial version was released on Aug 1st, which is in fact the Swiss national day. Coincidence? F. From hb-nanog at bsws.de Tue Aug 5 07:29:14 2008 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 5 Aug 2008 14:29:14 +0200 Subject: Software router state of the art In-Reply-To: References: <488E0A56.6020801@thewybles.com> <200807281823.m6SIN0QC005897@aurora.sol.net> Message-ID: <20080805122914.GK16304@nudo.bsws.de> * Stuart Henderson [2008-08-01 19:06]: > On 2008-07-28, Joe Greco wrote: > >> I have yet to look into *BSD based solutions, but hear very good things > >> about firewall performance. I don't know about BGP/OSPF/MPLS etc support > >> on FreeBSD but am going to wager a guess its on par with Linux if not > >> better. > > > > The underlying OS is responsible for packet forwarding, but none of them > > do any significant routing protocols natively. > > OpenBSD has OpenOSPFD/OpenBGPD in the base OS rather than as a port/ > package, so it's fully coupled with any kernel changes (and supports > some things missing from the FreeBSD port). can't be stressed enough; the concept of OpenBGPD/OSPFD/RIPD/DVRMPD/OSPF6D (did I forget one again?) is not too be just another daemon implementing the protocol at hand, they come with massive changes to the OpenBSD kernel to offer an alternative to other solutions, including "hardware" routers. Now it is quite clear that you don't want to run 5 loaded 10GE ports on any Hardware OpenBSD currently supports (it's not just PCs), but there are enough installations with smaller bandwidth requirements where it is a very viable alternative. -- 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 tme at multicasttech.com Tue Aug 5 07:41:51 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 5 Aug 2008 08:41:51 -0400 Subject: EFF tool to check bandwidth throttling In-Reply-To: References: Message-ID: <7D651F90-3CB8-49A8-9B3C-3C1CFD4B59DF@multicasttech.com> On Aug 5, 2008, at 5:22 AM, Gadi Evron wrote: > Story is here: > http://www.webmonkey.com/blog/Switzerland%3A_EFF_Software_Helps_Track_ISP_Bandwidth_Throttling > > The tool is called... Switzerland. > Yes, the first time I read about it, I was well into the article before I realized that they were not talking about some new initiative in the Confoederatio Helvetica, and stopped wondering if the EFF had become a International Organization and John Perry Barlow would no longer pay income taxes. On a related note, Jason Livingood and Rich Woundy of Comcast were at the recent IETF, particularly in the the ALTO and TANA BOFs, where some progress was made I think. Jason provided this link for insight into Comcast Network Management Policy, which might be of interest here : http://www.comcast.net/terms/network/ Regards Marshall > Gadi. > From rs at seastrom.com Tue Aug 5 08:17:06 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 05 Aug 2008 09:17:06 -0400 Subject: ARIN Advisory Council wants your input. In-Reply-To: <48970220.7080707@psg.com> (Randy Bush's message of "Mon, 04 Aug 2008 22:20:32 +0900") References: <20080804125247.GA8306@ussenterprise.ufp.org> <48970220.7080707@psg.com> Message-ID: <86bq07d2jx.fsf@seastrom.com> Randy Bush writes: >> 2008-2 "IPv4 Transfer Policy Proposal" which would allow the >> transfer of the right to use an IP block. > > you may find it interesting to compare this to apnic's proposal > > http://www.apnic.net/policy/discussions/prop-050-v003.txt > > and ripe's > > http://www.ripe.net/ripe/draft-documents/ripe-424-draft2007-08.html > > randy Not speaking on behalf of the ARIN AC, of which I am a member, I agree with Randy here. The more people read up on the competing proposals (particularly before responding to our survey) the better. ---Rob From rs at seastrom.com Tue Aug 5 08:19:44 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 05 Aug 2008 09:19:44 -0400 Subject: Is Usenet actually dead? In-Reply-To: <20080804203356.GI11750@cgi.jachomes.com> (Jay R. Ashworth's message of "Mon, 4 Aug 2008 16:33:56 -0400") References: <20080804162422.GL11750@cgi.jachomes.com> <87vdyg354r.fsf@mid.deneb.enyo.de> <20080804203356.GI11750@cgi.jachomes.com> Message-ID: <867iavd2fj.fsf@seastrom.com> "Jay R. Ashworth" writes: > How much *is* Big8 a day these days, though, a gig? I have a 10MBs > hose... If trends have continued since last I looked at it, very manageable after you take out the binaries. Insignificant if you could figure out a way to get rid of the flames and spam. :) -r From jra at baylink.com Tue Aug 5 09:54:12 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 5 Aug 2008 10:54:12 -0400 Subject: Level3 tries cell-phone style billing scam on customers In-Reply-To: <20080731193429.GA76636@typo.org> References: <4891DE62.9000202@zill.net> <4891FCE6.4050308@ttec.com> <20080731193429.GA76636@typo.org> Message-ID: <20080805145412.GE16739@cgi.jachomes.com> On Thu, Jul 31, 2008 at 12:34:29PM -0700, Wayne E. Bouchard wrote: > Hoping for a company which will put ethics above profit is like > looking for an honest politician. They're extremely rare. And, like Wiltel nd Mindspring, they tend to get bought out and ruined. 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. -- (Josef Stalin) From jra at baylink.com Tue Aug 5 10:48:51 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 5 Aug 2008 11:48:51 -0400 Subject: Yahoo mail abuse contact? - Duplicate nanog addrs on list mail In-Reply-To: <20080802051619.GA3286@cgi.jachomes.com> References: <20080802051619.GA3286@cgi.jachomes.com> Message-ID: <20080805154851.GG16739@cgi.jachomes.com> On Sat, Aug 02, 2008 at 01:16:19AM -0400, Jay R. Ashworth wrote: > Randy Cassingham at This Is True is complaining in his newsletter that > he has something like 15K undeliverables to Yahoo email addresses, > because, as he understands it, some of those people clicked Yahoo's > 'This is Spam' button, and he can't find a way off the list. > > Anyone got a pointer to Yahoo closed-loop stuff I can point him at? Several people were nice enough to provide pointers and encouragement... one of them may or may not have been who sent his plight also to Slashdot, whuich appears to have shamed the responsible department head out of his office. Thanks. On an unrelated topic: I may have discovered the "nanog at nanog.org,nanog at merit.edu" problem's source: I think it's the list. I sent this message manually, typing in nanog at nanog.org by hand as the To address. The reply-to is apparently *both* addresses, since that's what Mutt picked up when I hit 'r'. 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. -- (Josef Stalin) From ndowney at mediacomcc.com Tue Aug 5 12:16:53 2008 From: ndowney at mediacomcc.com (Nick Downey) Date: Tue, 5 Aug 2008 12:16:53 -0500 Subject: Out of Date Bogon Prefix Message-ID: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> This is an heads-up from the Mediacom Network Operations Center about an issue we are seeing. We were recently given an IP scope from ARIN (American Registry for Internet Numbers) that still exists on older Bogon lists many web providers are currently using. A Bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a Bogon range. These are commonly found as the source addresses of DDoS attacks. The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all websites using a Bogon prefix up until February of 2008, when it was released by IANA (Internet Assigned Numbers Authority) for public use and an updated Bogon prefix was provided. Mediacom customers that are within this IP range are not able to reach a website hosted by many organizations. Mediacom is individually requesting that these providers update their Bogon prefix to the most current version to resolve this issue immediately. We are requesting assistance from this community to make this issue known and to advise administrators to update to the most current Bogon list. We have provided some reference material that many may find helpful in resolving this issue. Bogons are defined as Martians (private and reserved addresses defined by RFC 1918 < http://www.faqs.org/rfcs/rfc1918.html> and RFC 3330 < http://www.faqs.org/rfcs/rfc3330.html>) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority < http://www.iana.org/>. IANA maintains a convenient IPv4 summary page < http://www.iana.org/assignments/ipv4-address-space> listing allocated and reserved netblocks. Please help to spread the word. Nick Downey Director Network Operations Center Mediacom Communications Main (800)308-6715 Secondary (515)267-1167 ndowney at mediacomcc.com ============================================================================ ================================================================ LEGAL DISCLAIMER ============================================================================ ================================================================ This E-mail and any attachments are strictly confidential and intended solely for the addressee. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender or Mediacom Communications Corporation. If you are not the intended addressee please notify the sender by return E-mail and delete this E-mail and its attachments. ============================================================================ ================================================================ From jeroen at unfix.org Tue Aug 5 12:37:20 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 05 Aug 2008 19:37:20 +0200 Subject: Out of Date Bogon Prefix In-Reply-To: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> Message-ID: <48988FD0.6010009@spaghetti.zurich.ibm.com> Nick Downey wrote: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > > were recently given an IP scope from ARIN (American Registry for Internet > Numbers) that still [..] Please fix your mailer as it seems to be broken with respect to line-breaks and that makes reading very annoying. > The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list > and was blocked by all If you really want the block you have to be debogonized it would be handy if you: - provide the full prefix, including prefix length, and not just x.x.x - reference to the whois entry - the ASN you are announcing this from - an IP address in that prefix that replies to at least ICMP echo requests with an ICMP echo response so that people can check for you if they can reach it. The people who care about these things would love to help you, but without proper information (173.0.0.0/8 is pretty big you know), that is very impossible, and why would they spend time on resolving your problem if you don't take the nice steps to provide proper information? Please also do some work on your side, and read up on: http://www.ris.ripe.net/debogon/ Greets, Jeroen PS: Most people here know what ARIN is and they also know what bogon routes are, repeating those terms is not very clueful ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From ndowney at mediacomcc.com Tue Aug 5 12:44:25 2008 From: ndowney at mediacomcc.com (Nick Downey) Date: Tue, 5 Aug 2008 12:44:25 -0500 Subject: Out of Date Bogon Prefix In-Reply-To: <48988FD0.6010009@spaghetti.zurich.ibm.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <48988FD0.6010009@spaghetti.zurich.ibm.com> Message-ID: <00c001c8f722$e7d2a6b0$d135190a@mediacomcorp.com> Will do. Thanks for the input. First time posting to this board. When I get everything together, should I just resend the entire email or just the information being requested? Nick Downey -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Tuesday, August 05, 2008 12:37 PM To: Nick Downey Cc: nanog at nanog.org Subject: Re: Out of Date Bogon Prefix Nick Downey wrote: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > > were recently given an IP scope from ARIN (American Registry for > Internet > Numbers) that still [..] Please fix your mailer as it seems to be broken with respect to line-breaks and that makes reading very annoying. > The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon > list and was blocked by all If you really want the block you have to be debogonized it would be handy if you: - provide the full prefix, including prefix length, and not just x.x.x - reference to the whois entry - the ASN you are announcing this from - an IP address in that prefix that replies to at least ICMP echo requests with an ICMP echo response so that people can check for you if they can reach it. The people who care about these things would love to help you, but without proper information (173.0.0.0/8 is pretty big you know), that is very impossible, and why would they spend time on resolving your problem if you don't take the nice steps to provide proper information? Please also do some work on your side, and read up on: http://www.ris.ripe.net/debogon/ Greets, Jeroen PS: Most people here know what ARIN is and they also know what bogon routes are, repeating those terms is not very clueful ;) From Valdis.Kletnieks at vt.edu Tue Aug 5 13:14:56 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 05 Aug 2008 14:14:56 -0400 Subject: Out of Date Bogon Prefix In-Reply-To: Your message of "Tue, 05 Aug 2008 12:16:53 CDT." <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> Message-ID: <20009.1217960096@turing-police.cc.vt.edu> On Tue, 05 Aug 2008 12:16:53 CDT, Nick Downey said: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > were recently given an IP scope from ARIN (American Registry for Internet > Numbers) that still > exists on older Bogon lists many web providers are currently using. Out of curiosity - what percentage of connectivity providers are both clued enough to be represented on NANOG and yet unclued enough to not understand the need to keep bogon filters up to date (even if you just get a BGP feed from Team Cymru)? (By the way, Nick - if what you sent NANOG was a form letter template, I'd lose a lot of the RFC references and point at Team Cymru's stuff instead)... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From smb at cs.columbia.edu Tue Aug 5 13:16:38 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 5 Aug 2008 14:16:38 -0400 Subject: Yahoo mail abuse contact? - Duplicate nanog addrs on list mail In-Reply-To: <20080805154851.GG16739@cgi.jachomes.com> References: <20080802051619.GA3286@cgi.jachomes.com> <20080805154851.GG16739@cgi.jachomes.com> Message-ID: <20080805141638.353edcaa@cs.columbia.edu> On Tue, 5 Aug 2008 11:48:51 -0400 "Jay R. Ashworth" wrote: > On an unrelated topic: I may have discovered the > "nanog at nanog.org,nanog at merit.edu" problem's source: > > I think it's the list. > > I sent this message manually, typing in nanog at nanog.org by hand as the > To address. > > The reply-to is apparently *both* addresses, since that's what Mutt > picked up when I hit 'r'. > Except that I don't see any Reply-To line on this message of yours. --Steve Bellovin, http://www.cs.columbia.edu/~smb From ndowney at mediacomcc.com Tue Aug 5 13:32:18 2008 From: ndowney at mediacomcc.com (Nick Downey) Date: Tue, 5 Aug 2008 13:32:18 -0500 Subject: Out of Date Bogon Prefix In-Reply-To: <48988FD0.6010009@spaghetti.zurich.ibm.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <48988FD0.6010009@spaghetti.zurich.ibm.com> Message-ID: <00e001c8f729$97d11140$d135190a@mediacomcorp.com> Thanks for the input. Currently, we are receiving 173.16.x.x /19 and /18, with plans to get additional IPs within the same range. ASN 6478 or 7018 - Through AT&T You can test access to this network by ping this gateway: 173.16.28.1 Whois information: 173.16.28.1 Record Type: IP Address OrgName: Mediacom Communications Corp OrgID: MCC-244 Address: 100 Crystal Run Rd. City: Middletown StateProv: NY PostalCode: 10941 Country: US ReferralServer: rwhois://rwhois.mediacomcc.com:4321 NetRange: 173.16.0.0 - 173.17.31.255 CIDR: 173.16.0.0/16, 173.17.0.0/19 NetName: MEDIACOM-RESIDENTIAL-CUST NetHandle: NET-173-16-0-0-1 Parent: NET-173-0-0-0-0 NetType: Direct Allocation NameServer: NS1.MCHSI.COM NameServer: NS2.MCHSI.COM Comment: RegDate: 2008-05-19 Updated: 2008-07-29 OrgTechHandle: JSE90-ARIN OrgTechName: Selvage, Joe OrgTechPhone: +1-845-695-2706 OrgTechEmail: jselvage at mediacomcc.com -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Tuesday, August 05, 2008 12:37 PM To: Nick Downey Cc: nanog at nanog.org Subject: Re: Out of Date Bogon Prefix Nick Downey wrote: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > > were recently given an IP scope from ARIN (American Registry for > Internet > Numbers) that still [..] Please fix your mailer as it seems to be broken with respect to line-breaks and that makes reading very annoying. > The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon > list and was blocked by all If you really want the block you have to be debogonized it would be handy if you: - provide the full prefix, including prefix length, and not just x.x.x - reference to the whois entry - the ASN you are announcing this from - an IP address in that prefix that replies to at least ICMP echo requests with an ICMP echo response so that people can check for you if they can reach it. The people who care about these things would love to help you, but without proper information (173.0.0.0/8 is pretty big you know), that is very impossible, and why would they spend time on resolving your problem if you don't take the nice steps to provide proper information? Please also do some work on your side, and read up on: http://www.ris.ripe.net/debogon/ Greets, Jeroen PS: Most people here know what ARIN is and they also know what bogon routes are, repeating those terms is not very clueful ;) From tims at donet.com Tue Aug 5 14:26:57 2008 From: tims at donet.com (Tim Sanderson) Date: Tue, 5 Aug 2008 15:26:57 -0400 Subject: Out of Date Bogon Prefix In-Reply-To: <20009.1217960096@turing-police.cc.vt.edu> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> Message-ID: Ya sure, like any of us would admit to 50% clue-ness. With all the posts here about bogons I would really be surprised that any nanog readers didn't know about keeping bogons updated. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, August 05, 2008 2:15 PM To: Nick Downey Cc: nanog at nanog.org Subject: Re: Out of Date Bogon Prefix On Tue, 05 Aug 2008 12:16:53 CDT, Nick Downey said: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > were recently given an IP scope from ARIN (American Registry for > Internet > Numbers) that still > exists on older Bogon lists many web providers are currently using. Out of curiosity - what percentage of connectivity providers are both clued enough to be represented on NANOG and yet unclued enough to not understand the need to keep bogon filters up to date (even if you just get a BGP feed from Team Cymru)? (By the way, Nick - if what you sent NANOG was a form letter template, I'd lose a lot of the RFC references and point at Team Cymru's stuff instead)... From frnkblk at iname.com Tue Aug 5 16:43:23 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 5 Aug 2008 16:43:23 -0500 Subject: Out of Date Bogon Prefix In-Reply-To: <00c001c8f722$e7d2a6b0$d135190a@mediacomcorp.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <48988FD0.6010009@spaghetti.zurich.ibm.com> <00c001c8f722$e7d2a6b0$d135190a@mediacomcorp.com> Message-ID: Nick: Out of curiosity and considering your position in the NOC, does anyone else on your staff read this list regularly? Frank -----Original Message----- From: Nick Downey [mailto:ndowney at mediacomcc.com] Sent: Tuesday, August 05, 2008 12:44 PM To: 'Jeroen Massar' Cc: nanog at nanog.org Subject: RE: Out of Date Bogon Prefix Will do. Thanks for the input. First time posting to this board. When I get everything together, should I just resend the entire email or just the information being requested? Nick Downey From patrick at ianai.net Tue Aug 5 23:18:58 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 6 Aug 2008 00:18:58 -0400 Subject: Out of Date Bogon Prefix In-Reply-To: References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> Message-ID: On Aug 5, 2008, at 3:26 PM, Tim Sanderson wrote: > Ya sure, like any of us would admit to 50% clue-ness. > > With all the posts here about bogons I would really be surprised > that any nanog readers didn't know about keeping bogons updated. I'd be shocked it there were no people who read NANOG and misunderstood or blatantly ignored some of it. Unfortunately, that means they would ignore / misunderstand the OP's request. But there is probably a small percentage clueless enough to have stale bogon filters, but just clueful enough to realize what the OP said might apply to them. A very small percentage.... Switching topics only slightly: Nick, do you have any data on what parts of the 'Net you can and cannot reach? Perhaps take a dump of route-views and ping some IPs in each ASN? Shouldn't be hard to script, and might yield useful data - both to you and the rest of us. -- TTFN, patrick > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, August 05, 2008 2:15 PM > To: Nick Downey > Cc: nanog at nanog.org > Subject: Re: Out of Date Bogon Prefix > > On Tue, 05 Aug 2008 12:16:53 CDT, Nick Downey said: >> This is an heads-up from the Mediacom Network Operations Center >> about an >> issue we are seeing. We >> were recently given an IP scope from ARIN (American Registry for >> Internet >> Numbers) that still >> exists on older Bogon lists many web providers are currently using. > > Out of curiosity - what percentage of connectivity providers are > both clued enough to be represented on NANOG and yet unclued enough > to not understand the need to keep bogon filters up to date (even if > you just get a BGP feed from Team Cymru)? > > (By the way, Nick - if what you sent NANOG was a form letter > template, I'd lose a lot of the RFC references and point at Team > Cymru's stuff instead)... > From nanog at daork.net Tue Aug 5 23:25:44 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 6 Aug 2008 16:25:44 +1200 Subject: Out of Date Bogon Prefix In-Reply-To: References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> Message-ID: On 6/08/2008, at 4:18 PM, Patrick W. Gilmore wrote: > Switching topics only slightly: Nick, do you have any data on what > parts of the 'Net you can and cannot reach? Perhaps take a dump of > route-views and ping some IPs in each ASN? Shouldn't be hard to > script, and might yield useful data - both to you and the rest of us. http://www.apricot.net/apricot2007/presentation/conference/plenary3-randy-bogon.pdf is probably of interest to you. Not sure if it's been published elsewhere, or if the work has been scripted and run recently. Perhaps a monthly update would be useful? -- Nathan Ward From randy at psg.com Tue Aug 5 23:32:15 2008 From: randy at psg.com (Randy Bush) Date: Wed, 06 Aug 2008 13:32:15 +0900 Subject: Out of Date Bogon Prefix In-Reply-To: References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> Message-ID: <4899294F.8030204@psg.com> > Switching topics only slightly: Nick, do you have any data on what parts > of the 'Net you can and cannot reach? Perhaps take a dump of > route-views and ping some IPs in each ASN? Shouldn't be hard to script, > and might yield useful data - both to you and the rest of us. tee hee. been there. done that. and for 173.0.0.0/20. paper submitted a month ago, but you saw a preso of the technique a year ago, see . arin has the code from us so they could put it into production if they so chose. randy From randy at psg.com Tue Aug 5 23:37:52 2008 From: randy at psg.com (Randy Bush) Date: Wed, 06 Aug 2008 13:37:52 +0900 Subject: Out of Date Bogon Prefix In-Reply-To: References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> Message-ID: <48992AA0.4030503@psg.com> > Perhaps a monthly update would be useful? we are running it approximately monthly from servers on three continents to see how things change over time and how locations differ. oh, and we do comparative traceroutes do diagnose *where* the filter is. just pinging out there, as patrick suggested, does not tell you where the blockage actually is. sad to say, folk do not seem to remove filters. but when we wrote to them, they did. credit to olaf maennel, now of t-labs, tu berlin, etc., for most of the hard work on this. randy From bicknell at ufp.org Wed Aug 6 08:09:38 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 6 Aug 2008 09:09:38 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> Message-ID: <20080806130937.GA99520@ussenterprise.ufp.org> "Bogon" filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From darden at armc.org Wed Aug 6 08:18:57 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 09:18:57 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080806130937.GA99520@ussenterprise.ufp.org> Message-ID: Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog at nanog.org Subject: Is it time to abandon bogon prefix filters? "Bogon" filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From darden at armc.org Wed Aug 6 08:25:36 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 09:25:36 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: Message-ID: Was looking over 1918 again, and for the record I have only run into one network that follows: "If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose *randomly* from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation." I added the asterisks. Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. --Patrick Darden -----Original Message----- From: Darden, Patrick S. Sent: Wednesday, August 06, 2008 9:19 AM To: 'Leo Bicknell'; nanog at nanog.org Subject: RE: Is it time to abandon bogon prefix filters? Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog at nanog.org Subject: Is it time to abandon bogon prefix filters? "Bogon" filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From bpfankuch at cpgreeley.com Wed Aug 6 08:39:20 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 6 Aug 2008 07:39:20 -0600 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <01759D50DC387C45A018FE1817CE27D74F2744F250@CPExchange1.cpgreeley.com> Where I work we are more aimed towards the SMB market, and we do run into that issue a lot. Of course a lot of the problem we run into is that the "engineers" who set up these SMB clients, even getting into some of the larger businesses just use what they always do. I can think of one specific engineer who everything he does is 192.168.1.0/24 .254 gateway .1 server which has cause issues. We have one particular client who has nearly 40 VPN's between partners and they have actually had to do a lot of natting at the vpn endpoint as they have 3 clients they connect to that are 10.0.1.0/24 and several that are 192.168.0.0/24 however a lot of the newer VPN firewalls that we work with actually do a pretty slick job. SonicWall NSA series devices have a "NAT VPN range" checkbox when you build the VPN and you just give it the range to use, as do the Fortinet devices. -----Original Message----- From: Darden, Patrick S. [mailto:darden at armc.org] Sent: Wednesday, August 06, 2008 7:26 AM To: nanog at nanog.org Subject: was bogon filters, now "Brief Segue on 1918" Was looking over 1918 again, and for the record I have only run into one network that follows: "If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose *randomly* from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation." I added the asterisks. Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. --Patrick Darden -----Original Message----- From: Darden, Patrick S. Sent: Wednesday, August 06, 2008 9:19 AM To: 'Leo Bicknell'; nanog at nanog.org Subject: RE: Is it time to abandon bogon prefix filters? Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog at nanog.org Subject: Is it time to abandon bogon prefix filters? "Bogon" filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From robt at cymru.com Wed Aug 6 09:28:18 2008 From: robt at cymru.com (Rob Thomas) Date: Wed, 06 Aug 2008 09:28:18 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080806130937.GA99520@ussenterprise.ufp.org> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> Message-ID: <4899B502.1090407@cymru.com> This makes sense especially for static filters. Automated feeds, such as the bogon route-server or DNS zones, leaves folks with options. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From matthew at eeph.com Wed Aug 6 09:44:16 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Wed, 06 Aug 2008 07:44:16 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <4899B8C0.4040606@eeph.com> Darden, Patrick S. wrote: > Most private networks start at the bottom and work up: 192.168.0.X++, > 10.0.0.X++, etc. This makes > any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen > a lot of hack jobs > using NAT to get around this. Ugly. Well, you can always do what one of the companies I work with does: allocate from 42.0.0.0/8 for networks that might need to interoperate with 1918 space and hope that it is "forever" before we run so low on IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status. How many more weeks is "forever" now? Matthew Kaufman matthew at eeph.com http://www.matthew.at From randy at psg.com Wed Aug 6 09:51:55 2008 From: randy at psg.com (Randy Bush) Date: Wed, 06 Aug 2008 23:51:55 +0900 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899B8C0.4040606@eeph.com> References: <4899B8C0.4040606@eeph.com> Message-ID: <4899BA8B.8070605@psg.com> Matthew Kaufman wrote: > do what one of the companies I work with does: allocate from > 42.0.0.0/8 some italian isps use blocked american military /8s. i find that highly amusing, especially when i think of the long-term implication for the folk who blocked access to that they wanted to 'own'. randy From patrick at ianai.net Wed Aug 6 09:55:44 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 6 Aug 2008 10:55:44 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899B502.1090407@cymru.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> Message-ID: <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> On Aug 6, 2008, at 10:28 AM, Rob Thomas wrote: > This makes sense especially for static filters. Automated feeds, > such as the bogon route-server or DNS zones, leaves folks with > options. Honestly, I don't believe the 80/20 rules applies here. Until all transit networks are willing to strictly filter their downstreams (and themselves!), if there is any unused space (note I said "unused", not "unallocated"), the miscreants will use it. They are not going around saying "oh, damn, there are only a few /8s left, we better stop!". Filter your bogons. But do it in an automated fashion, from a trusted source. Of course, I recommend Team Cymru, which has a most sterling record. Nearly perfect (other than the fact they still recommend MD5 on BGP sessions :). -- TTFN, patrick From randy at psg.com Wed Aug 6 10:01:06 2008 From: randy at psg.com (Randy Bush) Date: Thu, 07 Aug 2008 00:01:06 +0900 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> Message-ID: <4899BCB2.6050808@psg.com> > Until all transit networks are willing to strictly filter their > downstreams (and themselves!), if there is any unused space (note I said > "unused", not "unallocated"), the miscreants will use it. serious curiosity: what is the proportion of bad stuff coming from unallocated space vs allocated space? real measurements, please. and are there longitudinal data on this? are the uw folk, gatech, vern, ... measuring? randy From robt at cymru.com Wed Aug 6 10:18:28 2008 From: robt at cymru.com (Rob Thomas) Date: Wed, 06 Aug 2008 10:18:28 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899BCB2.6050808@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> Message-ID: <4899C0C4.1050804@cymru.com> > serious curiosity: > > what is the proportion of bad stuff coming from unallocated space vs > allocated space? real measurements, please. and are there longitudinal > data on this? Let me see what we can produce in the way of data. I'll just count 2008, though I could go back further if there's interest. Stay tuned, I should have some answers in a few hours. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From joelja at bogus.com Wed Aug 6 10:20:53 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 06 Aug 2008 08:20:53 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <4899C155.7000501@bogus.com> Darden, Patrick S. wrote: > Was looking over 1918 again, and for the record I have only run into one > network that follows: > > "If two (or more) organizations follow the address allocation > specified in this document and then later wish to establish IP > connectivity with each other, then there is a risk that address > uniqueness would be violated. To minimize the risk it is strongly > recommended that an organization using private IP addresses choose > *randomly* from the reserved pool of private addresses, when > allocating > sub-blocks for its internal allocation." > > I added the asterisks. > You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a /8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4. > --Patrick Darden > > > -----Original Message----- > From: Darden, Patrick S. > Sent: Wednesday, August 06, 2008 9:19 AM > To: 'Leo Bicknell'; nanog at nanog.org > Subject: RE: Is it time to abandon bogon prefix filters? > > > > Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing > mirroring), and as always individual discretion. > > --Patrick Darden > > > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Wednesday, August 06, 2008 9:10 AM > To: nanog at nanog.org > Subject: Is it time to abandon bogon prefix filters? > > > > "Bogon" filters made a lot of sense when most of the Internet was > bogons. Back when 5% of the IP space was allocated blocking the > other 95% was an extremely useful endevour. However, by the same > logic as we get to 80-90% used, blocking the 20-10% unused is > reaching diminishing returns; and at the same time the rate in which > new blocks are allocated continues to increase causing more and > more frequent updates. > > Have bogon filters outlived their use? Is it time to recommend people > go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that > doesn't need to be updated as frequently? > From justin at justinshore.com Wed Aug 6 10:52:36 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 06 Aug 2008 10:52:36 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899BCB2.6050808@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> Message-ID: <4899C8C4.7010302@justinshore.com> Randy Bush wrote: > serious curiosity: > > what is the proportion of bad stuff coming from unallocated space vs > allocated space? real measurements, please. and are there longitudinal > data on this? > > are the uw folk, gatech, vern, ... measuring? I still have 2 of my borders using an inbound ACL to filter BOGONs vs null routes. For the ACLs I've broken down the BOGONs to nothing larger than a /8. I see a number of hits on those entries, especially on 94/8. and 0/8. While some of the other hits are accidental I'm sure, I would seriously doubt if those 2 /8s are. Justin From justin at justinshore.com Wed Aug 6 11:02:27 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 06 Aug 2008 11:02:27 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080806130937.GA99520@ussenterprise.ufp.org> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> Message-ID: <4899CB13.6010000@justinshore.com> Leo Bicknell wrote: > Have bogon filters outlived their use? Is it time to recommend people > go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that > doesn't need to be updated as frequently? In my opinion no; BOGON filters are still very useful. Back when only 5% of the IP space was allocated we didn't have the same kinds of serious threats to our networks and our users that we have today. We didn't have spammers hijacking unallocated space (can if be considered hijacking when the block hasn't been allocated yet?) to mass mail our users, host phishing servers, run C&C servers for botnets, etc. Today we do and the use of what few networks are still unallocated for bad purposes are prevalent. For my users I only recommend that they use dynamic methods of keeping up to date with changes in the BOGON list. While I still do much of my BOGON work manually, as I'm sure many of us do, I have my local BOGON lists updated within a few hours of learning of a new allocation (sometimes even before the bogon-announce email arrives). For those that aren't uber network geeks I recommend using something automated. Look at it this way: you have what's essentially a mostly static list of netblocks from which all traffic is unquestionably malicious. Wouldn't you block it if you could for the sake of your network security and that of your users? Justin From internetplumber at gmail.com Wed Aug 6 11:06:10 2008 From: internetplumber at gmail.com (Rob Evans) Date: Wed, 6 Aug 2008 17:06:10 +0100 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899C8C4.7010302@justinshore.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <4899C8C4.7010302@justinshore.com> Message-ID: <9a8fa98b0808060906k75ac68ccl39fce8326da2e534@mail.gmail.com> > I see a number of hits on those entries, especially on 94/8. and 0/8. You do know that 94/8 has been assigned to the RIPE NCC, right? :-) Cheers, Rob From owen at delong.com Wed Aug 6 11:06:22 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Aug 2008 09:06:22 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899B8C0.4040606@eeph.com> References: <4899B8C0.4040606@eeph.com> Message-ID: <68085C2D-44F4-44F3-99BA-317D29C3E7D4@delong.com> On Aug 6, 2008, at 7:44 AM, Matthew Kaufman wrote: > Darden, Patrick S. wrote: >> Most private networks start at the bottom and work up: 192.168.0.X++, >> 10.0.0.X++, etc. This makes >> any internetworking (ptp, vpn, etc.) ridiculously difficult. I've >> seen >> a lot of hack jobs >> using NAT to get around this. Ugly. > > Well, you can always do what one of the companies I work with does: > allocate from 42.0.0.0/8 for networks that might need to > interoperate with 1918 space and hope that it is "forever" before we > run so low on IPv4 space that 42.0.0.0/8 needs to be taken out of > reserved status. > > How many more weeks is "forever" now? Personally, I'd like to see such numbers put on a list for ICANN to give priority to in their next RIR distribution. Owen From LarrySheldon at cox.net Wed Aug 6 10:46:35 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 06 Aug 2008 10:46:35 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080806130937.GA99520@ussenterprise.ufp.org> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> Message-ID: <4899C75B.1010805@cox.net> Leo Bicknell wrote: > Have bogon filters outlived their use? Is it time to recommend people > go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that > doesn't need to be updated as frequently? Seems like filtering against those could be done on the backplane, so to speak. One of the things that has always puzzled me is this: In the default-free zone, why is necessary to filter _against_ anybody? Seems like traffic for which there is no route would at most be dumped to an error-log someplace. For folks with a default route, I have long advocated (with no success what ever) filtering against stuff like the above, your own networks as sourced somewhere else, such. I also think a central blacklist a la spamhaus for networks makes sense. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From justin at justinshore.com Wed Aug 6 11:19:37 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 06 Aug 2008 11:19:37 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <9a8fa98b0808060906k75ac68ccl39fce8326da2e534@mail.gmail.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <4899C8C4.7010302@justinshore.com> <9a8fa98b0808060906k75ac68ccl39fce8326da2e534@mail.gmail.com> Message-ID: <4899CF19.6090609@justinshore.com> Rob Evans wrote: >> I see a number of hits on those entries, especially on 94/8. and 0/8. > > You do know that 94/8 has been assigned to the RIPE NCC, right? :-) I knew I should have logged into a production box to look at the ACL counters. But no, I thought the former border that I was already logged into was good enough. Apparently not! :-) I stopped updating it's BOGON list when it was decommissioned and retasked. I could have sworn that was just this past April and the only change since then was 112 and 113/8 which I accounted for mentally. Apparently it was longer ago than I thought! Justin From darden at armc.org Wed Aug 6 11:26:51 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 12:26:51 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899C155.7000501@bogus.com> Message-ID: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). --p -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, August 06, 2008 11:21 AM To: Darden, Patrick S. Cc: nanog at nanog.org Subject: Re: was bogon filters, now "Brief Segue on 1918" Darden, Patrick S. wrote: > *randomly* from the reserved pool of private addresses, when You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a /8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4. From leo.vegoda at icann.org Wed Aug 6 11:35:59 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 6 Aug 2008 09:35:59 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899B8C0.4040606@eeph.com> Message-ID: On 06/08/2008 4:44, "Matthew Kaufman" wrote: [...] > Well, you can always do what one of the companies I work with does: > allocate from 42.0.0.0/8 for networks that might need to interoperate > with 1918 space and hope that it is "forever" before we run so low on > IPv4 space that 42.0.0.0/8 needs to be taken out of reserved status. I'm very confident that 42.0.0.0/8 will be allocated within the next three years. Leo From joelja at bogus.com Wed Aug 6 11:36:05 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 06 Aug 2008 09:36:05 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <4899D2F5.9040003@bogus.com> Darden, Patrick S. wrote: > Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. > > E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) > > Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? > --p > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Wednesday, August 06, 2008 11:21 AM > To: Darden, Patrick S. > Cc: nanog at nanog.org > Subject: Re: was bogon filters, now "Brief Segue on 1918" > > > Darden, Patrick S. wrote: >> *randomly* from the reserved pool of private addresses, when > > You're supposed to choose ula-v6 /48 prefixs randomly as well... Any > bets on whether that routinely happens? > > While you're home can probably randomly allocate subnets out of a /8 or > /12 for a while without collisions, nobody that's actually building a > subnetting plan for a large private network is going to be able to get > away with that in v4. > From alan at halachmi.net Wed Aug 6 11:36:59 2008 From: alan at halachmi.net (Alan Halachmi) Date: Wed, 06 Aug 2008 12:36:59 -0400 (EDT) Subject: Verizon Contactg Message-ID: Would someone from Verizon please contact me? Or, if you know of a technical contact for Verizon, please pass it along. Thanks. Best, Alan From tme at multicasttech.com Wed Aug 6 11:46:33 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 6 Aug 2008 12:46:33 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899D2F5.9040003@bogus.com> References: <4899D2F5.9040003@bogus.com> Message-ID: <13A7D55B-AA45-4419-8C47-775A36A17563@multicasttech.com> On Aug 6, 2008, at 12:36 PM, Joel Jaeggli wrote: > Darden, Patrick S. wrote: >> Most organizations that would be doing this would not randomly pick >> out subnets, if I understand you. They would randomly pick out a >> subnet, then they would sub-subnet that based on a scheme. I >> believe this is the intent of RFC 1918. Not to apply a random IP >> scheme, but to randomly pick a network from the appropriate sized >> Private Networking ranges, then apply a well thought out scheme to >> the section of IP addresses you chose. >> E.g. 10.150.x.y/16 as their network. X could be physical >> positioning, and Y could be purposive in nature. 10.150.0.0 as >> basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, >> etc. 1-20 as switches/routers, 21-50 as servers and static >> workstations, 51-100 as printers, and 101--200 as DHCP scope for >> PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) >> Yes, I think a large private network would work this way. RFC 1918 >> wants it to work this way (imho). > > How much of 10/8 and 172.16/12 does an organization with ~80k > employees, on 5 continents, with hundreds of extranet connections to > partners and suppliers in addition to numerous aquistions and the > occasional subsidiary who also use 10/8 and 172.16/12 use? In my experience, effectively all of it. Marshall > > >> --p >> -----Original Message----- >> From: Joel Jaeggli [mailto:joelja at bogus.com] >> Sent: Wednesday, August 06, 2008 11:21 AM >> To: Darden, Patrick S. >> Cc: nanog at nanog.org >> Subject: Re: was bogon filters, now "Brief Segue on 1918" >> Darden, Patrick S. wrote: >>> *randomly* from the reserved pool of private addresses, when >> You're supposed to choose ula-v6 /48 prefixs randomly as well... >> Any bets on whether that routinely happens? >> While you're home can probably randomly allocate subnets out of a / >> 8 or /12 for a while without collisions, nobody that's actually >> building a subnetting plan for a large private network is going to >> be able to get away with that in v4. > > From patrick at ianai.net Wed Aug 6 11:58:51 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 6 Aug 2008 12:58:51 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899C75B.1010805@cox.net> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899C75B.1010805@cox.net> Message-ID: On Aug 6, 2008, at 11:46 AM, Laurence F. Sheldon, Jr. wrote: > Leo Bicknell wrote: > >> Have bogon filters outlived their use? Is it time to recommend >> people >> go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that >> doesn't need to be updated as frequently? > > Seems like filtering against those could be done on the backplane, > so to speak. > > One of the things that has always puzzled me is this: > > In the default-free zone, why is necessary to filter _against_ > anybody? Seems like traffic for which there is no route would at > most be dumped to an error-log someplace. > > For folks with a default route, I have long advocated (with no > success what ever) filtering against stuff like the above, your own > networks as sourced somewhere else, such. I'm confused. Why does it matter if you are DF or not? If the packets are just coming in, there does not need to be a prefix in the table. If duplex communication is required (e.g. spam runs), a prefix need to be in the table whether you have a 0/0 or not. We know spammers have done runs by announcing a block (which gets it into the DFZ if it is not filtered properly), send spam, pull prefix. So again, why does it matter if you have a default route or not? > I also think a central blacklist a la spamhaus for networks makes > sense. See Team Cymru. -- TTFN, patrick From darden at armc.org Wed Aug 6 12:01:25 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 13:01:25 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899D2F5.9040003@bogus.com> Message-ID: Well, how about this then: 10.Z.X.Y with Z being continent, X being country name with letters beginning with A assigned 1-10, B 11-20, with any unused letters having their numbers appended as needed, and Y being of course the host/int itself with maybe still 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) continent 1: 10.100.x.y/16 provides ~65,000 IP addresses Continent 2: 10.101.x.y/16 provides the same continent 3: whoa, asian market is big, better allocate for enterprise growth. 10.102.x.y and 10.103.x.y cont 4: 10.104/16 cont 5: 10.105/16 We have provided for ~400,000 employees here, fairly spread out equally amongst your 5 continents. With lots of room for growth by just adding another 10.Z/16 or two to each continent. Country algeria gets 10.100.1 and 10.100.2, country aguonia (?) gets 10.100.3 and 10.100.4, country bwabistan gets 10.100.11-15 (~1270 usable IPs, room for 150 servers, 250 printers, 500 PCs, 250 simultaneous telecommuters, and 100 switches and routers) because the company is big there. Etc. etc. My off the cuff network scheme isn't very good, but you get the drift. RFC1918 works. Details just have to be worked out on a case by case basis. IPV6 where are you?! --p -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, August 06, 2008 12:36 PM To: Darden, Patrick S. Cc: nanog at nanog.org Subject: Re: was bogon filters, now "Brief Segue on 1918" Darden, Patrick S. wrote: > Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. > > E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) > > Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? From darden at armc.org Wed Aug 6 12:19:10 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 13:19:10 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <13A7D55B-AA45-4419-8C47-775A36A17563@multicasttech.com> Message-ID: Actually, rereading this, I agree. My experience is large companies take it all, using huge swathes inefficiently, instead of doing it right. In my previous post I was answering the question I thought you were asking, not your real question. I agree with you both. I think that RFC1918 Could work, if companies used it correctly.... Again, though, I have only run into one company that used it correctly. IPV6, you are our only hope! (obiwan kenobi, you are our only hope!) --p Joel said > > How much of 10/8 and 172.16/12 does an organization with ~80k > employees, on 5 continents, with hundreds of extranet connections to > partners and suppliers in addition to numerous aquistions and the > occasional subsidiary who also use 10/8 and 172.16/12 use? Marshall said In my experience, effectively all of it. > From Skywing at valhallalegends.com Wed Aug 6 12:25:08 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 6 Aug 2008 12:25:08 -0500 Subject: Is it time to abandon bogon prefix filters? Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S (Sent via dumb phone mail client, apologies for any formatting badness). -----Original Message----- From: Patrick W. Gilmore Sent: Wednesday, August 06, 2008 11:59 To: NANOG list Subject: Re: Is it time to abandon bogon prefix filters? On Aug 6, 2008, at 11:46 AM, Laurence F. Sheldon, Jr. wrote: > Leo Bicknell wrote: > >> Have bogon filters outlived their use? Is it time to recommend >> people >> go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that >> doesn't need to be updated as frequently? > > Seems like filtering against those could be done on the backplane, > so to speak. > > One of the things that has always puzzled me is this: > > In the default-free zone, why is necessary to filter _against_ > anybody? Seems like traffic for which there is no route would at > most be dumped to an error-log someplace. > > For folks with a default route, I have long advocated (with no > success what ever) filtering against stuff like the above, your own > networks as sourced somewhere else, such. I'm confused. Why does it matter if you are DF or not? If the packets are just coming in, there does not need to be a prefix in the table. If duplex communication is required (e.g. spam runs), a prefix need to be in the table whether you have a 0/0 or not. We know spammers have done runs by announcing a block (which gets it into the DFZ if it is not filtered properly), send spam, pull prefix. So again, why does it matter if you have a default route or not? > I also think a central blacklist a la spamhaus for networks makes > sense. See Team Cymru. -- TTFN, patrick From joelja at bogus.com Wed Aug 6 12:30:42 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 06 Aug 2008 10:30:42 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <4899DFC2.9010000@bogus.com> That's comical thanks. come back when you've done it. Marshall is correct. If you'd like to avoid constant renumbering you need a sparser allocation model. You're still going to have collisions with your suppliers and acquisitions and some applications (eg labs, factory automation systems etc) have orders of magnitude large address space requirements than the number of humans using them implies. In practice indivudal sites might be assigned between a 22 and a 16 with sites with exotic requirements having multiple assignments potentially from different non-interconnected networks (but still with internal uniqueness requirements). Darden, Patrick S. wrote: > Well, how about this then: 10.Z.X.Y with Z being continent, X being country name with letters beginning with A assigned 1-10, B 11-20, with any unused letters having their numbers appended as needed, and Y being of course the host/int itself with maybe still 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) > > continent 1: 10.100.x.y/16 provides ~65,000 IP addresses > Continent 2: 10.101.x.y/16 provides the same > continent 3: whoa, asian market is big, better allocate for enterprise growth. 10.102.x.y and 10.103.x.y > cont 4: 10.104/16 > cont 5: 10.105/16 > > We have provided for ~400,000 employees here, fairly spread out equally amongst your 5 continents. With lots of room for growth by just adding another 10.Z/16 or two to each continent. > > Country algeria gets 10.100.1 and 10.100.2, country aguonia (?) gets 10.100.3 and 10.100.4, country bwabistan gets 10.100.11-15 (~1270 usable IPs, room for 150 servers, 250 printers, 500 PCs, 250 simultaneous telecommuters, and 100 switches and routers) because the company is big there. Etc. etc. > > My off the cuff network scheme isn't very good, but you get the drift. > > RFC1918 works. Details just have to be worked out on a case by case basis. > > IPV6 where are you?! > > --p > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Wednesday, August 06, 2008 12:36 PM > To: Darden, Patrick S. > Cc: nanog at nanog.org > Subject: Re: was bogon filters, now "Brief Segue on 1918" > > > Darden, Patrick S. wrote: >> Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. >> >> E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) >> >> Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). > > How much of 10/8 and 172.16/12 does an organization with ~80k employees, > on 5 continents, with hundreds of extranet connections to partners and > suppliers in addition to numerous aquistions and the occasional > subsidiary who also use 10/8 and 172.16/12 use? > From darden at armc.org Wed Aug 6 12:32:42 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 13:32:42 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> Message-ID: 1. DOS of Cymru (as noted below). 2. False Positives. Your network is suddenly stranded. Maybe on purpose. (DOS of a network, e.g. China or Youtube). 3. False Negatives. A bogus network is suddenly centrally rubber-stamped. Could happen. We've seen a lot of shenanigans with the domain registrars--similar issues could happen here. . . I guess I am just trying to say that a centralized trusted repository brings with it a chance for a single point of failure. Could be the pros outweigh the cons. There are issues with a de-centralized system as well (which is what brought this conversation about.) Nothing specific to Cymru. --Patrick Darden -----Original Message----- From: Skywing [mailto:Skywing at valhallalegends.com] Sent: Wednesday, August 06, 2008 1:25 PM To: Patrick W. Gilmore; NANOG list Subject: RE: Is it time to abandon bogon prefix filters? Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S From randy.whitney at verizonbusiness.com Wed Aug 6 12:31:55 2008 From: randy.whitney at verizonbusiness.com (Randy Whitney) Date: Wed, 06 Aug 2008 13:31:55 -0400 Subject: Verizon Contactg In-Reply-To: References: Message-ID: <4899E00B.10408@verizonbusiness.com> Hi Alan, To contact various carriers in the future, please start with peeringdb.org for POCs. How can I help you. Regards, Randy. Alan Halachmi wrote: > Would someone from Verizon please contact me? Or, if you know of a > technical contact for Verizon, please pass it along. Thanks. > > Best, > Alan > From darden at armc.org Wed Aug 6 12:48:16 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 13:48:16 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899DFC2.9010000@bogus.com> Message-ID: I'll reply below with //s. My point is still: most companies do not use RFC1918 correctly. Your point seemed to be that it is not a large enough allocation of IPs for an international enterprise of 80K souls. My rebuttal is: 16.5 million IPs isn't enough? --p -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, August 06, 2008 1:31 PM To: Darden, Patrick S. Cc: nanog at nanog.org Subject: Re: was bogon filters, now "Brief Segue on 1918" That's comical thanks. come back when you've done it. //Ok. Marshall is correct. //Ok. If you'd like to avoid constant renumbering you need a sparser allocation model. You're still going to have collisions with your suppliers and acquisitions and some applications (eg labs, factory automation systems etc) have orders of magnitude large address space requirements than the number of humans using them implies. //You used the metric of 80K people. Now you say it is a bad metric when I reply using it. Your fault, you compound it--you don't provide a better one. What are we talking about then? 100 IPs per person--say each person has 10 PCs, 10 printers, 10 automated factory machines, 10 lab instruments, 49 servers and the soda machine on their network? 80,000*100==8 million IP addresses. That leaves you with 8.5 million.... And that includes 80,000 networked soda machines. I don't think you have that many soda machines. Even on 5 continents. Even with your growing Asian market, your suppliers, and the whole marketing team. In practice indivudal sites might be assigned between a 22 and a 16 with sites with exotic requirements having multiple assignments potentially from different non-interconnected networks (but still with internal uniqueness requirements). //Err. Doing it wrong does not justify doing it wrong. From sean at donelan.com Wed Aug 6 13:01:30 2008 From: sean at donelan.com (Sean Donelan) Date: Wed, 6 Aug 2008 14:01:30 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899BCB2.6050808@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> Message-ID: <200808061354530.28CAECBD.21371@clifden.donelan.com> On Thu, 7 Aug 2008, Randy Bush wrote: > serious curiosity: > > what is the proportion of bad stuff coming from unallocated space vs > allocated space? real measurements, please. and are there longitudinal > data on this? > > are the uw folk, gatech, vern, ... measuring? Attacks or misconfigured leaks? Leaks of RFC1918 stuff is pretty common, just ask any of the root server operators how many packets they see from RFC1918 leaking networks or do a traceroute across several residential cable network backbones. Attacks aren't as common because there is enough (not 100%) anti-spoofing (good) and/or bogon-filters (not as good) in different parts of the Internet it requires more thought to launch a spoofed DDOS than it does just to use tens of thousands of non-spoofed bots to launch a DDOS. Arbor Networks has some data. From jra at baylink.com Wed Aug 6 13:08:10 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 6 Aug 2008 14:08:10 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899D2F5.9040003@bogus.com> References: <4899D2F5.9040003@bogus.com> Message-ID: <20080806180810.GA21443@cgi.jachomes.com> On Wed, Aug 06, 2008 at 09:36:05AM -0700, Joel Jaeggli wrote: > Darden, Patrick S. wrote: > >Most organizations that would be doing this would not randomly pick out > >subnets, if I understand you. They would randomly pick out a subnet, then > >they would sub-subnet that based on a scheme. I believe this is the > >intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick > >a network from the appropriate sized Private Networking ranges, then apply > >a well thought out scheme to the section of IP addresses you chose. > > > >E.g. 10.150.x.y/16 as their network. X could be physical positioning, and > >Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as > >first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, > >21-50 as servers and static workstations, 51-100 as printers, and 101--200 > >as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, > >dialup, etc.) > > > >Yes, I think a large private network would work this way. RFC 1918 wants > >it to work this way (imho). I'm certain that wasn't the intent of 1918, from the "random" wording. > How much of 10/8 and 172.16/12 does an organization with ~80k employees, > on 5 continents, with hundreds of extranet connections to partners and > suppliers in addition to numerous aquistions and the occasional > subsidiary who also use 10/8 and 172.16/12 use? My network serves around 300 machines and employees, and uses 10.10/16, though very sparsely -- we do indeed subject one /24 per function. The *point* though, is that it's 10.*10*. Another client is using 10.55.storenumber with one /24 per store. 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. -- (Josef Stalin) From robt at cymru.com Wed Aug 6 13:36:39 2008 From: robt at cymru.com (Rob Thomas) Date: Wed, 06 Aug 2008 13:36:39 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> Message-ID: <4899EF37.2030100@cymru.com> Hi, Skywing. We've had a few DDoS attacks and lots of scans and hack attempts. Some of the DDoS attacks managed to wipe out our front-end. At no point were the route-servers impacted, since we keep them well away from our networks, widely distributed, and vigorously monitored (configs, responsiveness, advertisements). Of course we're not perfect and there is no 100% solution, but we understand the implications of filtering gone awry (especially since we use it ourselves), and spend a lot of time and code keeping an eye on these things. Knowing that no one has a monopoly on imagination, we also have some friends at commercial pen-testers hit us regularly, just to be sure. :) Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From joelja at bogus.com Wed Aug 6 13:49:14 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 06 Aug 2008 11:49:14 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <4899F22A.1080200@bogus.com> Darden, Patrick S. wrote: > I'll reply below with //s. My point is still: most companies do not use RFC1918 correctly. As with say v4 prefix distribution as a whole where you observe that the number of very large prefix holders is rather small, it's really easy to say most casually, trivially in fact, that most rfc1918 uses are single devices with a single subnet behind them. There are a small number (low tens of thousands instead of low hundreds of millions) of applications where rfc1918 space feels rather tight, because in fact it's all going to get used. you don't have to look very far for operators (what we traditionally thing of as operators represent a chunk of those applications) chaffing under their 1918 limitations, see for example this draft which is undoubtedly met with opposition since the idea has come around before. http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-00 > Your point seemed to be that it is not a large enough allocation of IPs for an international enterprise of 80K souls. My rebuttal is: 16.5 million IPs isn't enough? That is my point, 24 bits is rather tight. The least specific 32 of 96 bits looks like it will continue to work ok for some time... > --p > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Wednesday, August 06, 2008 1:31 PM > To: Darden, Patrick S. > Cc: nanog at nanog.org > Subject: Re: was bogon filters, now "Brief Segue on 1918" > > > That's comical thanks. come back when you've done it. > //Ok. > > Marshall is correct. > //Ok. > > If you'd like to avoid constant renumbering you need a sparser > allocation model. You're still going to have collisions with your > suppliers and acquisitions and some applications (eg labs, factory > automation systems etc) have orders of magnitude large address space > requirements than the number of humans using them implies. > //You used the metric of 80K people. Now you say it is a bad metric when I reply using it. Your fault, you compound it--you don't provide a better one. What are we talking about then? 100 IPs per person--say each person has 10 PCs, 10 printers, 10 automated factory machines, 10 lab instruments, 49 servers and the soda machine on their network? 80,000*100==8 million IP addresses. That leaves you with 8.5 million.... And that includes 80,000 networked soda machines. I don't think you have that many soda machines. Even on 5 continents. Even with your growing Asian market, your suppliers, and the whole marketing team. > > > In practice indivudal sites might be assigned between a 22 and a 16 with > sites with exotic requirements having multiple assignments potentially > from different non-interconnected networks (but still with internal > uniqueness requirements). > //Err. Doing it wrong does not justify doing it wrong. > > From eddy+public+spam at noc.everquick.net Wed Aug 6 13:47:39 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Wed, 6 Aug 2008 18:47:39 +0000 (GMT) Subject: Is Usenet actually dead? In-Reply-To: <867iavd2fj.fsf@seastrom.com> References: <20080804162422.GL11750@cgi.jachomes.com> <87vdyg354r.fsf@mid.deneb.enyo.de> <20080804203356.GI11750@cgi.jachomes.com> <867iavd2fj.fsf@seastrom.com> Message-ID: RES> Date: Tue, 05 Aug 2008 09:19:44 -0400 RES> From: Robert E. Seastrom RES> If trends have continued since last I looked at it, very manageable RES> after you take out the binaries. Insignificant if you could figure RES> out a way to get rid of the flames and spam. :) Usenet - binaries - flames - spam = pretty close to "actually dead" ;-) 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 hir.assie at gmail.com Wed Aug 6 13:51:26 2008 From: hir.assie at gmail.com (Hiroyuki ASHIDA) Date: Thu, 7 Aug 2008 03:51:26 +0900 Subject: Out of Date Bogon Prefix In-Reply-To: <48992AA0.4030503@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> <48992AA0.4030503@psg.com> Message-ID: Nick, I had experienced similar situation in last year. We evaluated our internet connectivity on application layer to explain our connectivity for our customer. I had presentation in JANOG21 (JApan Network Operators' Group 21th meeting) in January. JANOG i18n members translated my Japansese material. http://www.janog.gr.jp/en/index.php?JANOG21%20Programs#t4bc51ef From alex at corp.nac.net Wed Aug 6 13:54:35 2008 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 6 Aug 2008 14:54:35 -0400 Subject: Is Usenet actually dead? In-Reply-To: References: <20080804162422.GL11750@cgi.jachomes.com><87vdyg354r.fsf@mid.deneb.enyo.de><20080804203356.GI11750@cgi.jachomes.com> <867iavd2fj.fsf@seastrom.com> Message-ID: We operate a transit box, and there are still quite a few of them out there. Pushing hundreds and hundreds of megs. http://news.anthologeek.net/ > -----Original Message----- > From: Edward B. DREGER [mailto:eddy+public+spam at noc.everquick.net] > Sent: Wednesday, August 06, 2008 2:48 PM > To: Robert E. Seastrom > Cc: nanog at nanog.org > Subject: Re: Is Usenet actually dead? > > RES> Date: Tue, 05 Aug 2008 09:19:44 -0400 > RES> From: Robert E. Seastrom > > RES> If trends have continued since last I looked at it, very manageable > RES> after you take out the binaries. Insignificant if you could figure > RES> out a way to get rid of the flames and spam. :) > > Usenet - binaries - flames - spam = pretty close to "actually dead" > > ;-) > > > 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 surfer at mauigateway.com Wed Aug 6 14:17:42 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 6 Aug 2008 12:17:42 -0700 Subject: was bogon filters, now "Brief Segue on 1918" Message-ID: <20080806121742.8E78AD52@resin09.mta.everyone.net> --- darden at armc.org wrote: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. ----------------------------------------------- One way to do it... In picking out 1918 space for a network, I happened to notice it was 2:45pm. I randomly picked 20 minutes less and came up with 10.245.225. Then I started going lower as everyone seems to start lower and then goes higher. 10.245.225.0/24, 10.245.224.0/24, etc. Within those (and the larger subnets) I chose to fill out the blocks based on a scheme. So far, no network has used these ranges and we've connected to many. scott From trejrco at gmail.com Wed Aug 6 14:24:14 2008 From: trejrco at gmail.com (TJ) Date: Wed, 6 Aug 2008 15:24:14 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: <13A7D55B-AA45-4419-8C47-775A36A17563@multicasttech.com> Message-ID: <007801c8f7fa$046260e0$0d2722a0$@com> But ... that's part of why RFC1918 is used, so they have this fairly large address range to play with. And remember, what one person calls inefficiency, another calls flexibility. Either (or neither) may be right! Oh, and I don't think we can say RFC1918 doesn't work today - obviously it does, just possibly inducing lots of head-aches. And yes, same ideas occur - just with larger numbers :) - in v6. To keep the analogy complete, reference ULAs ... with a (more stringent?) random component. (I put a question mark on that just because you can break the spec and configure non-random ones ) /TJ >-----Original Message----- >From: Darden, Patrick S. [mailto:darden at armc.org] >Sent: Wednesday, August 06, 2008 1:19 PM >To: Marshall Eubanks; Joel Jaeggli >Cc: nanog at nanog.org >Subject: RE: was bogon filters, now "Brief Segue on 1918" > > >Actually, rereading this, I agree. My experience is large companies take it >all, using huge swathes inefficiently, instead of doing it right. In my >previous post I was answering the question I thought you were asking, not >your real question. > >I agree with you both. > >I think that RFC1918 Could work, if companies used it correctly.... Again, >though, I have only run into one company that used it correctly. IPV6, you >are our only hope! (obiwan kenobi, you are our only hope!) > >--p > > >Joel said >> >> How much of 10/8 and 172.16/12 does an organization with ~80k >> employees, on 5 continents, with hundreds of extranet connections to >> partners and suppliers in addition to numerous aquistions and the >> occasional subsidiary who also use 10/8 and 172.16/12 use? > > >Marshall said >In my experience, effectively all of it. > > > >> From ndowney at mediacomcc.com Wed Aug 6 14:28:35 2008 From: ndowney at mediacomcc.com (Nick Downey) Date: Wed, 6 Aug 2008 14:28:35 -0500 Subject: Out of Date Bogon Prefix In-Reply-To: References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> <48992AA0.4030503@psg.com> Message-ID: <00e101c8f7fa$9f8cf940$d135190a@mediacomcorp.com> Very helpful information. Thanks. Nick Downey -----Original Message----- From: Hiroyuki ASHIDA [mailto:hir.assie at gmail.com] Sent: Wednesday, August 06, 2008 1:51 PM To: ndowney at mediacomcc.com Cc: nanog at nanog.org Subject: Re: Out of Date Bogon Prefix Nick, I had experienced similar situation in last year. We evaluated our internet connectivity on application layer to explain our connectivity for our customer. I had presentation in JANOG21 (JApan Network Operators' Group 21th meeting) in January. JANOG i18n members translated my Japansese material. http://www.janog.gr.jp/en/index.php?JANOG21%20Programs#t4bc51ef From ross at ign.com Wed Aug 6 14:32:59 2008 From: ross at ign.com (Ross Dmochowski) Date: Wed, 6 Aug 2008 12:32:59 -0700 Subject: gTLD root nameserver anomaly Message-ID: <42FC052309DF3B4CB5C297D226CEACC0205C82@IGN-MSG-04.hq.ign.com> Something weird seems afoot in the root nameservers. I am noticing that the root nameservers are handing out extra info with TTLs much longer than those delineated in the respective zone file on the authoritative nameserver for that zone. Case in point: I asked my local DNS server for ns2.gamespy.com and it went directly to a gtld server (f.gtld-servers.net.): 08:25:27.541627 IP 172.19.2.15.45505 > 192.35.51.30.domain: 42289% [1au] A? ns2.gamespy.com. (44) 08:25:27.544415 IP 192.35.51.30.domain > 172.19.2.15.45505: 42289- 1/5/3 A 207.38.0.11 (229) and returned an answer with the larger TTL: dig ns2.gamespy.com ; <<>> DiG 9.2.4 <<>> ns2.gamespy.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37167 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 7 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com. 172800 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com. 172800 IN NS pdns4.ultradns.org. gamespy.com. 172800 IN NS pdns5.ultradns.info. gamespy.com. 172800 IN NS pdns1.ultradns.net. gamespy.com. 172800 IN NS pdns2.ultradns.net. gamespy.com. 172800 IN NS pdns3.ultradns.org. ;; ADDITIONAL SECTION: pdns1.ultradns.net. 131158 IN A 204.74.108.1 pdns1.ultradns.net. 44758 IN AAAA 2001:502:f3ff::1 pdns2.ultradns.net. 131158 IN A 204.74.109.1 pdns3.ultradns.org. 44758 IN A 199.7.68.1 pdns4.ultradns.org. 44758 IN A 199.7.69.1 pdns4.ultradns.org. 44758 IN AAAA 2001:502:4612::1 pdns5.ultradns.info. 44758 IN A 204.74.114.1 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 6 08:25:27 2008 ;; MSG SIZE rcvd: 322 but if I ask an UltraDNS server directly...it returns the correct TTL dig @204.74.108.1 ns2.gamespy.com ; <<>> DiG 9.2.4 <<>> @204.74.108.1 ns2.gamespy.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com. 300 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com. 300 IN NS PDNS6.ULTRADNS.CO.UK. gamespy.com. 300 IN NS PDNS5.ULTRADNS.INFO. gamespy.com. 300 IN NS PDNS4.ULTRADNS.ORG. gamespy.com. 300 IN NS PDNS3.ULTRADNS.ORG. gamespy.com. 300 IN NS PDNS2.ULTRADNS.NET. gamespy.com. 300 IN NS PDNS1.ULTRADNS.NET. but unfortunately, my nameserver honors (as expected) the TTL that came back from the initial request ;; ANSWER SECTION: ns2.gamespy.com. 172493 IN A 207.38.0.11 Another example would be 'gss1.foxtv.com'. I changed the IP for that server on Sunday night, and if you ask the authoritative nameservers (for IGN), they give you the correct response. However, when you do a trace, once can see that the gTLD server gives out its own info, which is not correct, and no one ever seems to get to the authoritative nameserver to get the appropriate information. -bash-2.05b$ dig +trace gss1.foxtv.com ; <<>> DiG 9.2.4 <<>> +trace gss1.foxtv.com ;; global options: printcmd . 1796 IN NS f.root-servers.net. . 1796 IN NS g.root-servers.net. . 1796 IN NS h.root-servers.net. . 1796 IN NS i.root-servers.net. . 1796 IN NS j.root-servers.net. . 1796 IN NS k.root-servers.net. . 1796 IN NS l.root-servers.net. . 1796 IN NS m.root-servers.net. . 1796 IN NS a.root-servers.net. . 1796 IN NS b.root-servers.net. . 1796 IN NS c.root-servers.net. . 1796 IN NS d.root-servers.net. . 1796 IN NS e.root-servers.net. ;; Received 332 bytes from 10.1.100.100#53(10.1.100.100) in 1 ms com. 172800 IN NS L.GTLD-SERVERS.NET. com. 172800 IN NS A.GTLD-SERVERS.NET. com. 172800 IN NS J.GTLD-SERVERS.NET. com. 172800 IN NS G.GTLD-SERVERS.NET. com. 172800 IN NS C.GTLD-SERVERS.NET. com. 172800 IN NS H.GTLD-SERVERS.NET. com. 172800 IN NS E.GTLD-SERVERS.NET. com. 172800 IN NS K.GTLD-SERVERS.NET. com. 172800 IN NS I.GTLD-SERVERS.NET. com. 172800 IN NS D.GTLD-SERVERS.NET. com. 172800 IN NS F.GTLD-SERVERS.NET. com. 172800 IN NS M.GTLD-SERVERS.NET. com. 172800 IN NS B.GTLD-SERVERS.NET. ;; Received 492 bytes from 192.5.5.241#53(f.root-servers.net) in 5 ms gss1.foxtv.com. 172800 IN A 63.241.173.211 foxtv.com. 172800 IN NS ns1.ign.com. foxtv.com. 172800 IN NS ns2.gamespy.com. foxtv.com. 172800 IN NS ns4.ign.com. ;; Received 162 bytes from 192.41.162.30#53(L.GTLD-SERVERS.NET) in 81 ms Anyone have any ideas of why I am seeing this? Any info would be greatly appreciated. Ross S. Dmochowski | Sr. Linux Administrator | Fox Interactive Media Desk: (415) 508-2230 | Cell: (415) 279-3761 | Fax: (415) 508-2001 | AIM: rossfim From trejrco at gmail.com Wed Aug 6 14:35:49 2008 From: trejrco at gmail.com (TJ) Date: Wed, 6 Aug 2008 15:35:49 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: <4899DFC2.9010000@bogus.com> Message-ID: <007f01c8f7fb$a46cb9e0$ed462da0$@com> I think the problem is that operational reality (ease of use, visual clarity, etc.) has long since won the war against the numerical capabilities. Things like assigning /24's per vlan make the routing table easy to read, subnets easy to assign, etc. Starting from the bottom up, the next easy segregation point is /16s per site. Yielding just over 250 sites, each with just over 250 network segments, each supporting up to 250 or so users. Easy aggregation & summarization, easy to "own and operate" ... grossly inefficient. But common. So, right or wrong is largely irrelevant - it just is. Now go into that environment and push for a strictly-speaking efficient allocation mechanism and let me know what kind of traction you get. Moving forward, we can try to do things right in our IPv6 networks ... assuming we don't inherit too much of the cruft from above. Use the bits to do flexible allocation while also maintaining aggregation / summarization - it can be done. ... now let's get some work done. /TJ >-----Original Message----- >From: Darden, Patrick S. [mailto:darden at armc.org] >Sent: Wednesday, August 06, 2008 1:48 PM >To: Joel Jaeggli >Cc: nanog at nanog.org >Subject: RE: was bogon filters, now "Brief Segue on 1918" > > >I'll reply below with //s. My point is still: most companies do not use >RFC1918 correctly. Your point seemed to be that it is not a large enough >allocation of IPs for an international enterprise of 80K souls. My rebuttal >is: 16.5 million IPs isn't enough? >--p > >-----Original Message----- >From: Joel Jaeggli [mailto:joelja at bogus.com] >Sent: Wednesday, August 06, 2008 1:31 PM >To: Darden, Patrick S. >Cc: nanog at nanog.org >Subject: Re: was bogon filters, now "Brief Segue on 1918" > > >That's comical thanks. come back when you've done it. >//Ok. > >Marshall is correct. >//Ok. > >If you'd like to avoid constant renumbering you need a sparser allocation >model. You're still going to have collisions with your suppliers and >acquisitions and some applications (eg labs, factory automation systems etc) >have orders of magnitude large address space requirements than the number of >humans using them implies. >//You used the metric of 80K people. Now you say it is a bad metric when I >reply using it. Your fault, you compound it--you don't provide a better >one. What are we talking about then? 100 IPs per person--say each person >has 10 PCs, 10 printers, 10 automated factory machines, 10 lab instruments, >49 servers and the soda machine on their network? 80,000*100==8 million IP >addresses. That leaves you with 8.5 million.... And that includes 80,000 >networked soda machines. I don't think you have that many soda machines. >Even on 5 continents. Even with your growing Asian market, your suppliers, >and the whole marketing team. > > >In practice indivudal sites might be assigned between a 22 and a 16 with >sites with exotic requirements having multiple assignments potentially from >different non-interconnected networks (but still with internal uniqueness >requirements). >//Err. Doing it wrong does not justify doing it wrong. > From sam_mailinglists at spacething.org Wed Aug 6 14:59:58 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Wed, 06 Aug 2008 20:59:58 +0100 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> Message-ID: <489A02BE.5050101@spacething.org> Skywing wrote: > Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. > > (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) > Use a prefix list of existing bogons against the Team Cymru BGP feed. If they are hacked this limits the possible attacks to the following bounds: 1) They advertise no address space, and you end up with no bogon filtering. 2) They advertise all of the IPv4 address space, but your prefix list limits this to (an admittedly out-of-date) list of bogons. Sam From ross at ign.com Wed Aug 6 15:02:03 2008 From: ross at ign.com (Ross Dmochowski) Date: Wed, 6 Aug 2008 13:02:03 -0700 Subject: gTLD root nameserver anomaly In-Reply-To: <42FC052309DF3B4CB5C297D226CEACC0205C82@IGN-MSG-04.hq.ign.com> References: <42FC052309DF3B4CB5C297D226CEACC0205C82@IGN-MSG-04.hq.ign.com> Message-ID: <42FC052309DF3B4CB5C297D226CEACC0205C8A@IGN-MSG-04.hq.ign.com> sorry, nm. glue records in the rootzones, that no one should have put. I'll go back in my corner now. -----Original Message----- From: Ross Dmochowski Sent: Wednesday, August 06, 2008 12:33 PM To: nanog at nanog.org Subject: gTLD root nameserver anomaly Importance: High Something weird seems afoot in the root nameservers. I am noticing that the root nameservers are handing out extra info with TTLs much longer than those delineated in the respective zone file on the authoritative nameserver for that zone. Case in point: I asked my local DNS server for ns2.gamespy.com and it went directly to a gtld server (f.gtld-servers.net.): 08:25:27.541627 IP 172.19.2.15.45505 > 192.35.51.30.domain: 42289% [1au] A? ns2.gamespy.com. (44) 08:25:27.544415 IP 192.35.51.30.domain > 172.19.2.15.45505: 42289- 1/5/3 A 207.38.0.11 (229) and returned an answer with the larger TTL: dig ns2.gamespy.com ; <<>> DiG 9.2.4 <<>> ns2.gamespy.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37167 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 7 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com. 172800 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com. 172800 IN NS pdns4.ultradns.org. gamespy.com. 172800 IN NS pdns5.ultradns.info. gamespy.com. 172800 IN NS pdns1.ultradns.net. gamespy.com. 172800 IN NS pdns2.ultradns.net. gamespy.com. 172800 IN NS pdns3.ultradns.org. ;; ADDITIONAL SECTION: pdns1.ultradns.net. 131158 IN A 204.74.108.1 pdns1.ultradns.net. 44758 IN AAAA 2001:502:f3ff::1 pdns2.ultradns.net. 131158 IN A 204.74.109.1 pdns3.ultradns.org. 44758 IN A 199.7.68.1 pdns4.ultradns.org. 44758 IN A 199.7.69.1 pdns4.ultradns.org. 44758 IN AAAA 2001:502:4612::1 pdns5.ultradns.info. 44758 IN A 204.74.114.1 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 6 08:25:27 2008 ;; MSG SIZE rcvd: 322 but if I ask an UltraDNS server directly...it returns the correct TTL dig @204.74.108.1 ns2.gamespy.com ; <<>> DiG 9.2.4 <<>> @204.74.108.1 ns2.gamespy.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com. 300 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com. 300 IN NS PDNS6.ULTRADNS.CO.UK. gamespy.com. 300 IN NS PDNS5.ULTRADNS.INFO. gamespy.com. 300 IN NS PDNS4.ULTRADNS.ORG. gamespy.com. 300 IN NS PDNS3.ULTRADNS.ORG. gamespy.com. 300 IN NS PDNS2.ULTRADNS.NET. gamespy.com. 300 IN NS PDNS1.ULTRADNS.NET. but unfortunately, my nameserver honors (as expected) the TTL that came back from the initial request ;; ANSWER SECTION: ns2.gamespy.com. 172493 IN A 207.38.0.11 Another example would be 'gss1.foxtv.com'. I changed the IP for that server on Sunday night, and if you ask the authoritative nameservers (for IGN), they give you the correct response. However, when you do a trace, once can see that the gTLD server gives out its own info, which is not correct, and no one ever seems to get to the authoritative nameserver to get the appropriate information. -bash-2.05b$ dig +trace gss1.foxtv.com ; <<>> DiG 9.2.4 <<>> +trace gss1.foxtv.com ;; global options: printcmd . 1796 IN NS f.root-servers.net. . 1796 IN NS g.root-servers.net. . 1796 IN NS h.root-servers.net. . 1796 IN NS i.root-servers.net. . 1796 IN NS j.root-servers.net. . 1796 IN NS k.root-servers.net. . 1796 IN NS l.root-servers.net. . 1796 IN NS m.root-servers.net. . 1796 IN NS a.root-servers.net. . 1796 IN NS b.root-servers.net. . 1796 IN NS c.root-servers.net. . 1796 IN NS d.root-servers.net. . 1796 IN NS e.root-servers.net. ;; Received 332 bytes from 10.1.100.100#53(10.1.100.100) in 1 ms com. 172800 IN NS L.GTLD-SERVERS.NET. com. 172800 IN NS A.GTLD-SERVERS.NET. com. 172800 IN NS J.GTLD-SERVERS.NET. com. 172800 IN NS G.GTLD-SERVERS.NET. com. 172800 IN NS C.GTLD-SERVERS.NET. com. 172800 IN NS H.GTLD-SERVERS.NET. com. 172800 IN NS E.GTLD-SERVERS.NET. com. 172800 IN NS K.GTLD-SERVERS.NET. com. 172800 IN NS I.GTLD-SERVERS.NET. com. 172800 IN NS D.GTLD-SERVERS.NET. com. 172800 IN NS F.GTLD-SERVERS.NET. com. 172800 IN NS M.GTLD-SERVERS.NET. com. 172800 IN NS B.GTLD-SERVERS.NET. ;; Received 492 bytes from 192.5.5.241#53(f.root-servers.net) in 5 ms gss1.foxtv.com. 172800 IN A 63.241.173.211 foxtv.com. 172800 IN NS ns1.ign.com. foxtv.com. 172800 IN NS ns2.gamespy.com. foxtv.com. 172800 IN NS ns4.ign.com. ;; Received 162 bytes from 192.41.162.30#53(L.GTLD-SERVERS.NET) in 81 ms Anyone have any ideas of why I am seeing this? Any info would be greatly appreciated. Ross S. Dmochowski | Sr. Linux Administrator | Fox Interactive Media Desk: (415) 508-2230 | Cell: (415) 279-3761 | Fax: (415) 508-2001 | AIM: rossfim From rjoffe at centergate.com Wed Aug 6 15:02:59 2008 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 6 Aug 2008 13:02:59 -0700 Subject: gTLD root nameserver anomaly In-Reply-To: <42FC052309DF3B4CB5C297D226CEACC0205C82@IGN-MSG-04.hq.ign.com> References: <42FC052309DF3B4CB5C297D226CEACC0205C82@IGN-MSG-04.hq.ign.com> Message-ID: <731551BD-5078-4D21-B0B4-38E9E5E03113@centergate.com> Handled directly. The problem was glue records within the .com TLD for the nameserver that needed to be changed as well as the zonefile. On Aug 6, 2008, at 12:32 PM, Ross Dmochowski wrote: > Something weird seems afoot in the root nameservers. > I am noticing that the root nameservers are handing out extra info > with > TTLs much > longer than those delineated in the respective zone file on the > authoritative nameserver > for that zone. > > Case in point: > I asked my local DNS server for ns2.gamespy.com and it went directly > to > a gtld server (f.gtld-servers.net.): > > 08:25:27.541627 IP 172.19.2.15.45505 > 192.35.51.30.domain: > 42289% [1au] A? ns2.gamespy.com. (44) > 08:25:27.544415 IP 192.35.51.30.domain > 172.19.2.15.45505: > 42289- 1/5/3 A 207.38.0.11 (229) > > and returned an answer with the larger TTL: > > dig ns2.gamespy.com > > ; <<>> DiG 9.2.4 <<>> ns2.gamespy.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37167 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, > ADDITIONAL: 7 > > ;; QUESTION SECTION: > ;ns2.gamespy.com. IN A > > ;; ANSWER SECTION: > ns2.gamespy.com. 172800 IN A 207.38.0.11 > > ;; AUTHORITY SECTION: > gamespy.com. 172800 IN NS > pdns4.ultradns.org. > gamespy.com. 172800 IN NS > pdns5.ultradns.info. > gamespy.com. 172800 IN NS > pdns1.ultradns.net. > gamespy.com. 172800 IN NS > pdns2.ultradns.net. > gamespy.com. 172800 IN NS > pdns3.ultradns.org. > > ;; ADDITIONAL SECTION: > pdns1.ultradns.net. 131158 IN A 204.74.108.1 > pdns1.ultradns.net. 44758 IN AAAA 2001:502:f3ff::1 > pdns2.ultradns.net. 131158 IN A 204.74.109.1 > pdns3.ultradns.org. 44758 IN A 199.7.68.1 > pdns4.ultradns.org. 44758 IN A 199.7.69.1 > pdns4.ultradns.org. 44758 IN AAAA 2001:502:4612::1 > pdns5.ultradns.info. 44758 IN A 204.74.114.1 > > ;; Query time: 4 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Aug 6 08:25:27 2008 > ;; MSG SIZE rcvd: 322 > > but if I ask an UltraDNS server directly...it returns the correct TTL > > dig @204.74.108.1 ns2.gamespy.com > > ; <<>> DiG 9.2.4 <<>> @204.74.108.1 ns2.gamespy.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23978 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, > ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;ns2.gamespy.com. IN A > > ;; ANSWER SECTION: > ns2.gamespy.com. 300 IN A 207.38.0.11 > > ;; AUTHORITY SECTION: > gamespy.com. 300 IN NS > PDNS6.ULTRADNS.CO.UK. > gamespy.com. 300 IN NS > PDNS5.ULTRADNS.INFO. > gamespy.com. 300 IN NS > PDNS4.ULTRADNS.ORG. > gamespy.com. 300 IN NS > PDNS3.ULTRADNS.ORG. > gamespy.com. 300 IN NS > PDNS2.ULTRADNS.NET. > gamespy.com. 300 IN NS > PDNS1.ULTRADNS.NET. > > but unfortunately, my nameserver honors (as expected) the TTL that > came > back from the initial request > > ;; ANSWER SECTION: > ns2.gamespy.com. 172493 IN A 207.38.0.11 > > Another example would be 'gss1.foxtv.com'. I changed the IP for that > server on Sunday night, > and if you ask the authoritative nameservers (for IGN), they give you > the correct response. > However, when you do a trace, once can see that the gTLD server gives > out its own > info, which is not correct, and no one ever seems to get to the > authoritative nameserver > to get the appropriate information. > > -bash-2.05b$ dig +trace gss1.foxtv.com > > ; <<>> DiG 9.2.4 <<>> +trace gss1.foxtv.com > ;; global options: printcmd > . 1796 IN NS f.root-servers.net. > . 1796 IN NS g.root-servers.net. > . 1796 IN NS h.root-servers.net. > . 1796 IN NS i.root-servers.net. > . 1796 IN NS j.root-servers.net. > . 1796 IN NS k.root-servers.net. > . 1796 IN NS l.root-servers.net. > . 1796 IN NS m.root-servers.net. > . 1796 IN NS a.root-servers.net. > . 1796 IN NS b.root-servers.net. > . 1796 IN NS c.root-servers.net. > . 1796 IN NS d.root-servers.net. > . 1796 IN NS e.root-servers.net. > ;; Received 332 bytes from 10.1.100.100#53(10.1.100.100) in 1 ms > > com. 172800 IN NS L.GTLD-SERVERS.NET. > com. 172800 IN NS A.GTLD-SERVERS.NET. > com. 172800 IN NS J.GTLD-SERVERS.NET. > com. 172800 IN NS G.GTLD-SERVERS.NET. > com. 172800 IN NS C.GTLD-SERVERS.NET. > com. 172800 IN NS H.GTLD-SERVERS.NET. > com. 172800 IN NS E.GTLD-SERVERS.NET. > com. 172800 IN NS K.GTLD-SERVERS.NET. > com. 172800 IN NS I.GTLD-SERVERS.NET. > com. 172800 IN NS D.GTLD-SERVERS.NET. > com. 172800 IN NS F.GTLD-SERVERS.NET. > com. 172800 IN NS M.GTLD-SERVERS.NET. > com. 172800 IN NS B.GTLD-SERVERS.NET. > ;; Received 492 bytes from 192.5.5.241#53(f.root-servers.net) in 5 ms > > gss1.foxtv.com. 172800 IN A 63.241.173.211 > foxtv.com. 172800 IN NS ns1.ign.com. > foxtv.com. 172800 IN NS ns2.gamespy.com. > foxtv.com. 172800 IN NS ns4.ign.com. > ;; Received 162 bytes from 192.41.162.30#53(L.GTLD-SERVERS.NET) in > 81 ms > > > Anyone have any ideas of why I am seeing this? > Any info would be greatly appreciated. > > Ross S. Dmochowski | Sr. Linux Administrator | Fox > Interactive > Media > Desk: (415) 508-2230 | Cell: (415) 279-3761 | Fax: (415) 508-2001 | > AIM: > rossfim > > From heather.schiller at verizonbusiness.com Wed Aug 6 15:13:02 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 06 Aug 2008 16:13:02 -0400 Subject: Out of Date Bogon Prefix In-Reply-To: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> Message-ID: <489A05CE.90907@verizonbusiness.com> Nick, You might want to take a closer look at who is really bogon filtering you. Emailing their upstream providers may not be the most effective method for getting endsites to update their bogon filters. They don't have to listen to us when we forward your note on. We can't force them to accept traffic from you or update their filters. As someone else pointed out, directly contacting the folks who are filtering you may be time consuming but typically draws the best results. I agree with the other comments that if you are going to use a form letter please provide more details about the IP's you are using and your ASN. Please also pass this on to your colleagues Eric and Kevin, who I've heard from lately :) --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Nick Downey wrote: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > > were recently given an IP scope from ARIN (American Registry for Internet > Numbers) that still > > exists on older Bogon lists many web providers are currently using. > > > A Bogon prefix is a route that should never appear in the Internet routing > table. A packet routed > > over the public Internet (not including over VPN or other tunnels) should > never have a source > > address in a Bogon range. These are commonly found as the source addresses > of DDoS attacks. > > > The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list > and was blocked by all > > websites using a Bogon prefix up until February of 2008, when it was > released by IANA (Internet > > Assigned Numbers Authority) for public use and an updated Bogon prefix was > provided. Mediacom > > customers that are within this IP range are not able to reach a website > hosted by many organizations. > > > > > > Mediacom is individually requesting that these providers update their Bogon > prefix to the most current version > > to resolve this issue immediately. We are requesting assistance from this > community to make this issue known > and to advise administrators to update to the most current Bogon list. > > We have provided some reference material that many may find helpful in > resolving this issue. > Bogons are defined as Martians (private and reserved addresses defined by > RFC 1918 < > > http://www.faqs.org/rfcs/rfc1918.html> and > RFC 3330 < > > http://www.faqs.org/rfcs/rfc3330.html>) and netblocks that have not been > allocated to a regional internet registry (RIR) by the Internet Assigned > Numbers Authority < http://www.iana.org/>. IANA > maintains a convenient IPv4 summary page < > > http://www.iana.org/assignments/ipv4-address-space> listing allocated and > reserved netblocks. > > Please help to spread the word. > > Nick Downey > Director > Network Operations Center > Mediacom Communications > Main (800)308-6715 > Secondary (515)267-1167 > ndowney at mediacomcc.com > > > > > ============================================================================ > ================================================================ > LEGAL DISCLAIMER > ============================================================================ > ================================================================ > This E-mail and any attachments are strictly confidential and intended > solely for the addressee. You must not disclose, forward or copy this E-mail > or attachments to any third party without the prior consent of the sender or > Mediacom Communications Corporation. If you are not the intended addressee > please notify the sender by return E-mail and delete this E-mail and its > attachments. > ============================================================================ > ================================================================ > > > From ndowney at mediacomcc.com Wed Aug 6 16:22:23 2008 From: ndowney at mediacomcc.com (Nick Downey) Date: Wed, 6 Aug 2008 16:22:23 -0500 Subject: Out of Date Bogon Prefix In-Reply-To: <489A05CE.90907@verizonbusiness.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <489A05CE.90907@verizonbusiness.com> Message-ID: <010f01c8f80a$84b27b30$d135190a@mediacomcorp.com> That makes sense. I am working on updating our M&P. Thanks. Nick -----Original Message----- From: Heather Schiller [mailto:heather.schiller at verizonbusiness.com] Sent: Wednesday, August 06, 2008 3:13 PM To: Nick Downey Cc: nanog at nanog.org Subject: Re: Out of Date Bogon Prefix Nick, You might want to take a closer look at who is really bogon filtering you. Emailing their upstream providers may not be the most effective method for getting endsites to update their bogon filters. They don't have to listen to us when we forward your note on. We can't force them to accept traffic from you or update their filters. As someone else pointed out, directly contacting the folks who are filtering you may be time consuming but typically draws the best results. I agree with the other comments that if you are going to use a form letter please provide more details about the IP's you are using and your ASN. Please also pass this on to your colleagues Eric and Kevin, who I've heard from lately :) --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Nick Downey wrote: > This is an heads-up from the Mediacom Network Operations Center about an > issue we are seeing. We > > were recently given an IP scope from ARIN (American Registry for > Internet > Numbers) that still > > exists on older Bogon lists many web providers are currently using. > > > A Bogon prefix is a route that should never appear in the Internet routing > table. A packet routed > > over the public Internet (not including over VPN or other tunnels) > should never have a source > > address in a Bogon range. These are commonly found as the source > addresses of DDoS attacks. > > > The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon > list and was blocked by all > > websites using a Bogon prefix up until February of 2008, when it was > released by IANA (Internet > > Assigned Numbers Authority) for public use and an updated Bogon prefix > was provided. Mediacom > > customers that are within this IP range are not able to reach a > website hosted by many organizations. > > > > > > Mediacom is individually requesting that these providers update their > Bogon prefix to the most current version > > to resolve this issue immediately. We are requesting assistance from > this community to make this issue known and to advise administrators > to update to the most current Bogon list. > > We have provided some reference material that many may find helpful in > resolving this issue. > Bogons are defined as Martians (private and reserved addresses defined > by RFC 1918 < > > http://www.faqs.org/rfcs/rfc1918.html> and > RFC 3330 < > > http://www.faqs.org/rfcs/rfc3330.html>) and netblocks that have not > been allocated to a regional internet registry (RIR) by the Internet > Assigned Numbers Authority < > http://www.iana.org/>. IANA maintains a convenient IPv4 summary page < > > http://www.iana.org/assignments/ipv4-address-space> listing allocated > and reserved netblocks. > > Please help to spread the word. > > Nick Downey > Director > Network Operations Center > Mediacom Communications > Main (800)308-6715 > Secondary (515)267-1167 > ndowney at mediacomcc.com > > > > > ====================================================================== > ====== > ================================================================ > LEGAL DISCLAIMER > ====================================================================== > ====== > ================================================================ > This E-mail and any attachments are strictly confidential and intended > solely for the addressee. You must not disclose, forward or copy this > E-mail or attachments to any third party without the prior consent of > the sender or Mediacom Communications Corporation. If you are not the > intended addressee please notify the sender by return E-mail and > delete this E-mail and its attachments. > ====================================================================== > ====== > ================================================================ > > > From ge at linuxbox.org Wed Aug 6 23:44:37 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 6 Aug 2008 23:44:37 -0500 (CDT) Subject: facebook worm Message-ID: Hi all. You may want to be ready for a *possible* support lines flood today. Yesterday I discovered a fast-spreading facebook worm. It spreads by sending messages to all your facebook friends, from your account, asking them to click on a link in the .pl ccTLD. This worm is somewhat similar to zlob, here is a link to a kaspersky paper on a previous iteration of it, they call it koobface: http://www.kaspersky.com/news?id=207575670 The worm collects spam subject lines from, and then sends the users personal data to the following C&C: zzzping.com I spoke with DirectNIC last night and the Registrar Operations (reg-ops) mailing list was updated that the domain is no longer reachable. That was very fast response time from DirectNIC, which we appreciate. The worm is still fast-spreading, watch the statistics as they fly: http://www.d9.pl/system/stats.php The facebook security team is working on this, and they are quite capable. The security operations community has been doing analysis and take-downs, but the worm seems to still be spreading. All anti virus vendors have been notified, and detection (if not removal) should be added within a few hours to a few days. For now, while users may get infected, their information is safe (unless the worm has a secondary contact C&C which I have not verified yet). It seems like some users may have learned not to click on links in email, but any other medium does not compute. Gadi. From lists at memetic.org Thu Aug 7 08:26:55 2008 From: lists at memetic.org (Adam Armstrong) Date: Thu, 07 Aug 2008 14:26:55 +0100 Subject: Ericsson / Marconi AHX ADSL2+ Message-ID: <489AF81F.60707@memetic.org> Hi All, Are any of you using Marconi/Ericsson AXH 2500 (or similar) MSANs for ADSL2+? Does anyone know much about setting up ADSL2+ to operate stabily with fastpath (trellis off) and adaptive runtime on? Any offlist help would be much appreciated! Thanks, adam. From darden at armc.org Wed Aug 6 12:48:16 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 6 Aug 2008 10:48:16 -0700 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <4899DFC2.9010000@bogus.com> Message-ID: I'll reply below with //s. My point is still: most companies do not use RFC1918 correctly. Your point seemed to be that it is not a large enough allocation of IPs for an international enterprise of 80K souls. My rebuttal is: 16.5 million IPs isn't enough? --p -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, August 06, 2008 1:31 PM To: Darden, Patrick S. Cc: nanog at nanog.org Subject: Re: was bogon filters, now "Brief Segue on 1918" That's comical thanks. come back when you've done it. //Ok. Marshall is correct. //Ok. If you'd like to avoid constant renumbering you need a sparser allocation model. You're still going to have collisions with your suppliers and acquisitions and some applications (eg labs, factory automation systems etc) have orders of magnitude large address space requirements than the number of humans using them implies. //You used the metric of 80K people. Now you say it is a bad metric when I reply using it. Your fault, you compound it--you don't provide a better one. What are we talking about then? 100 IPs per person--say each person has 10 PCs, 10 printers, 10 automated factory machines, 10 lab instruments, 49 servers and the soda machine on their network? 80,000*100==8 million IP addresses. That leaves you with 8.5 million.... And that includes 80,000 networked soda machines. I don't think you have that many soda machines. Even on 5 continents. Even with your growing Asian market, your suppliers, and the whole marketing team. In practice indivudal sites might be assigned between a 22 and a 16 with sites with exotic requirements having multiple assignments potentially from different non-interconnected networks (but still with internal uniqueness requirements). //Err. Doing it wrong does not justify doing it wrong. To report this e-mail as SPAM, forward it to spam at mailcontrol.com The information contained in this E-mail message, including any attached files transmitted, is confidential and may be legally privileged. It is intended only for the sole use of the individual(s) named above. If you are the intended recipient, be aware that your use of any confidential or personal information may be restricted by state and federal privacy laws. If you, the reader of this message, are not the intended recipient, you are hereby notified that you should not further disseminate, distribute, or forward this E-mail message. If you have received this E-mail in error, please notify the sender and delete the material from your computer system. This message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments in any jurisdiction. From sam_mailinglists at spacething.org Wed Aug 6 14:59:58 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Wed, 6 Aug 2008 12:59:58 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D66150B1D4DC@caralain.haven.nynaeve.net> Message-ID: <489A02BE.5050101@spacething.org> Skywing wrote: > Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. > > (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) > Use a prefix list of existing bogons against the Team Cymru BGP feed. If they are hacked this limits the possible attacks to the following bounds: 1) They advertise no address space, and you end up with no bogon filtering. 2) They advertise all of the IPv4 address space, but your prefix list limits this to (an admittedly out-of-date) list of bogons. Sam To report this e-mail as SPAM, forward it to spam at mailcontrol.com The information contained in this E-mail message, including any attached files transmitted, is confidential and may be legally privileged. It is intended only for the sole use of the individual(s) named above. If you are the intended recipient, be aware that your use of any confidential or personal information may be restricted by state and federal privacy laws. If you, the reader of this message, are not the intended recipient, you are hereby notified that you should not further disseminate, distribute, or forward this E-mail message. If you have received this E-mail in error, please notify the sender and delete the material from your computer system. This message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments in any jurisdiction. From michael.dillon at bt.com Thu Aug 7 12:06:29 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 Aug 2008 18:06:29 +0100 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: Message-ID: >Your point seemed to be that > it is not a large enough allocation of IPs for an > international enterprise of 80K souls. My rebuttal is: 16.5 > million IPs isn't enough? You don't seem to understand how IPv4 networks are designed and how that interacts with scale, i.e. the large sprawling networks that international enterprises have. You don't simply count out x addresses per employee. Instead, you design a subnet architecture that a) can grow at all levels, and b) can be cut off the network when you sell off a branch operation or two. This leads to large amounts of IP addresses used up in padding at all levels, which then leads to these organizations running out of RFC 1918 space, a more and more common occurence. This, in itself, is a good incentive to move to IPv6, since the seemingly wasteful subnet architecture is considered best practice with IPv6, and a ULA prefix or two gives you lots of space to keep growing. > What are we talking > about then? 100 IPs per person--say each person has 10 PCs, > 10 printers, 10 automated factory machines, 10 lab > instruments, 49 servers and the soda machine on their > network? Nope. We are not talking about people, but about network architecture and topology. Two people in one office need two addresses. Put them in separate offices and they need two subnets. Topology dominates the design. > I don't think you have that many soda > machines. Even on 5 continents. Even with your growing > Asian market, your suppliers, and the whole marketing team. I believe the first two companies to run out of RFC 1918 space (or to project that it would happen) are Comcast, and American cable provider in one continent, and a Japanese cable provider on a small Pacific island next to China. > //Err. Doing it wrong does not justify doing it wrong. Cute sound bites does not make you an expert in anything. In any case, IPv4 is yesterday's news. Nowadays everyone is scrambling to integrate IPv6 into their networks and shift services onto IPv6. --Michael Dillon From darden at armc.org Thu Aug 7 12:47:02 2008 From: darden at armc.org (Patrick Darden) Date: Thu, 07 Aug 2008 13:47:02 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <489B3516.9060005@armc.org> I've always enjoyed your posts Michael. You are obviously an expert, with no patience for idiocy, and you always go for the throat and try to hurt the other person as much as you can. Your messages are always very entertaining. In this case, however, you are responding to a conversation that is pretty much over and done. I've already received umpty emails telling me how right I am, and another umpty emails telling me I am an idiot and I should go back to knitting. Most of the latter were privately sent, and I appreciate both their candor and discretion.... The reasonable voices seem to feel that it doesn't matter if I am right, as the real world just doesn't care. I have to agree with that. That's kinda the whole point, I think. The forward thinkers feel as you do that IPV6 is the real answer. I believe I was the first to say that in this thread. As far as the individual points that you satirize below--well ok then. We are not talking about people. I was not the person who raised people as a metric. Jump his case if you feel the need. I was actually jumping his case about it myself, albeit tongue in cheek, and hopefully with no hard feelings. However, the original conversation centered on the best way to design private networks so that internetworking between companies who did not confer on eachothers' network design does not cause problems, and how very few companies follow RFC1918 very well in my experience. Whether they fail at RFC1918 for real reasons or not, they still fail. As far as companies that design their own networks so they have trouble interoperating with themselves--well, bummer for them. I bet they wish they had done their design more efficiently instead of making "large sprawling" networks with plenty of room for growth for soda machines. Because you just can't assign enough IP address space for your soda machines. "Cute sound bites does (sic) not make you an expert in anything. " I agree with this too. But just because it's cute, doesn't mean it's wrong. --Patrick Darden michael.dillon at bt.com wrote: >> Your point seemed to be that >> it is not a large enough allocation of IPs for an >> international enterprise of 80K souls. My rebuttal is: 16.5 >> million IPs isn't enough? >> > > You don't seem to understand how IPv4 networks are designed > and how that interacts with scale, i.e. the large sprawling > networks that international enterprises have. You don't simply > count out x addresses per employee. Instead, you design a subnet > architecture that a) can grow at all levels, and b) can be > cut off the network when you sell off a branch operation or two. > > This leads to large amounts of IP addresses used up in padding > at all levels, which then leads to these organizations running > out of RFC 1918 space, a more and more common occurence. This, > in itself, is a good incentive to move to IPv6, since the > seemingly wasteful subnet architecture is considered best practice > with IPv6, and a ULA prefix or two gives you lots of space to > keep growing. > > >> What are we talking >> about then? 100 IPs per person--say each person has 10 PCs, >> 10 printers, 10 automated factory machines, 10 lab >> instruments, 49 servers and the soda machine on their >> network? >> > > Nope. We are not talking about people, but about network > architecture and topology. Two people in one office need > two addresses. Put them in separate offices and they need > two subnets. Topology dominates the design. > > >> I don't think you have that many soda >> machines. Even on 5 continents. Even with your growing >> Asian market, your suppliers, and the whole marketing team. >> > > I believe the first two companies to run out of RFC 1918 > space (or to project that it would happen) are Comcast, > and American cable provider in one continent, and a > Japanese cable provider on a small Pacific island next > to China. > > >> //Err. Doing it wrong does not justify doing it wrong. >> > > Cute sound bites does not make you an expert in anything. > > In any case, IPv4 is yesterday's news. Nowadays everyone is > scrambling to integrate IPv6 into their networks and shift > services onto IPv6. > > --Michael Dillon > > From petelists at templin.org Thu Aug 7 13:04:19 2008 From: petelists at templin.org (Pete Templin) Date: Thu, 07 Aug 2008 14:04:19 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> Message-ID: <489B3923.3000309@templin.org> Patrick W. Gilmore wrote: > Filter your bogons. But do it in an automated fashion, from a trusted > source. > > Of course, I recommend Team Cymru, which has a most sterling record. > Nearly perfect (other than the fact they still recommend MD5 on BGP > sessions :). How can you recommend Team Cymru, when their product is not in any way a filter? It is merely an automated method of injecting aggregate null routes for bogons, but in no way prevents a network from accepting aggregate or specific bogon announcements (i.e. it does not _filter_). pt From jlewis at lewis.org Thu Aug 7 13:37:39 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 7 Aug 2008 14:37:39 -0400 (EDT) Subject: Sprint IP engineer Message-ID: Could a Sprintlink.net IP engineer please get in touch with me. I'd like to talk about some really unusual IP routing/connectivity issues I'm seeing between our network and yours. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From patrick at ianai.net Thu Aug 7 13:52:43 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 7 Aug 2008 14:52:43 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B3923.3000309@templin.org> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> Message-ID: <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> On Aug 7, 2008, at 2:04 PM, Pete Templin wrote: > Patrick W. Gilmore wrote: > >> Filter your bogons. But do it in an automated fashion, from a >> trusted source. >> Of course, I recommend Team Cymru, which has a most sterling >> record. Nearly perfect (other than the fact they still recommend >> MD5 on BGP sessions :). > > How can you recommend Team Cymru, when their product is not in any > way a filter? It is merely an automated method of injecting > aggregate null routes for bogons, but in no way prevents a network > from accepting aggregate or specific bogon announcements (i.e. it > does not _filter_). HUH? Team Cymru offers many ways to set up filters, null routes, etc. See . Oh, and to answer Randy's question about how much actually comes from bogons, on that same page: How much does it help to filter the bogons? In one study conducted by Rob Thomas of a frequently attacked site, fully 60% of the naughty packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.). A presentation based on that study, entitled "60 Days of Basic Naughtiness," can be viewed here. Your mileage may vary, and you may opt to filter more conservatively or more liberally. As always, you must KNOW YOUR NETWORK to understand the effects of such filtering. I guess that means filtering bogons is useful. -- TTFN, patrick From jra at baylink.com Thu Aug 7 14:28:26 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 7 Aug 2008 15:28:26 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <489B3516.9060005@armc.org> References: <489B3516.9060005@armc.org> Message-ID: <20080807192826.GM25292@cgi.jachomes.com> On Thu, Aug 07, 2008 at 01:47:02PM -0400, Patrick Darden wrote: > I've always enjoyed your posts Michael. You are obviously an expert, > with no patience for idiocy, and you always go for the throat and try to > hurt the other person as much as you can. Your messages are always very > entertaining. You really think Michael is malicious in his intent? You've spent a whole lot of time paying now attention around here, haven't you? > As far as companies that design their own networks so they have trouble > interoperating with themselves--well, bummer for them. I bet they wish > they had done their design more efficiently instead of making "large > sprawling" networks with plenty of room for growth for soda machines. > Because you just can't assign enough IP address space for your soda > machines. > > "Cute sound bites does (sic) not make you an expert in anything. " I > agree with this too. But just because it's cute, doesn't mean it's wrong. No, cute soundbites don't make you an expert. But in this case, Dillon's right, and you're wrong: your attempt to trivialize the specific issue on point (allocation within the 1918 space internal to a company network) by implying that the only reasons to do it the way he suggests amount to "leaving space for soda machines" only proves in public that you don't know what you're talking about. As randy would put it, I encourage my competitors to hire you to architect their WANs. 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. -- (Josef Stalin) From rs at seastrom.com Thu Aug 7 14:29:41 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 07 Aug 2008 15:29:41 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> (Patrick W. Gilmore's message of "Thu, 7 Aug 2008 14:52:43 -0400") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> Message-ID: <8663qc39p6.fsf@seastrom.com> "Patrick W. Gilmore" writes: > How much does it help to filter the bogons? In one study conducted by > Rob Thomas of a frequently attacked site, fully 60% of the naughty > packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) Stated another way, you can get 60% success on bogon filtering by ignoring the free pool (which is getting smaller over time which indicates the value in filtering it is asymptotic to zero) and only filtering obvious crud, whose definition is not going to change over time. In other words, Leo is right, and I'd submit that we're past the point where putting in non-auto-updated filters for the free pool has a value that exceeds the operational cost of dealing with their lossage... by a couple of years. -r From info at arin.net Thu Aug 7 14:34:30 2008 From: info at arin.net (Member Services) Date: Thu, 07 Aug 2008 15:34:30 -0400 Subject: Out of Date Bogon Prefix In-Reply-To: <4899294F.8030204@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20009.1217960096@turing-police.cc.vt.edu> <4899294F.8030204@psg.com> Message-ID: <489B4E46.80700@arin.net> The code that Randy mentioned is part of an ARIN bogon testing initiative. ARIN funded this work and provided equipment to Randy to perform this testing. ARIN thanks Randy and those who worked with him for the effort in this area. ARIN will deploy this code as it continues its bogon testing efforts in the coming year. Nate Davis Chief Operations Officer ARIN Randy Bush wrote: >>Switching topics only slightly: Nick, do you have any data on what parts >>of the 'Net you can and cannot reach? Perhaps take a dump of >>route-views and ping some IPs in each ASN? Shouldn't be hard to script, >>and might yield useful data - both to you and the rest of us. > > > tee hee. been there. done that. and for 173.0.0.0/20. paper > submitted a month ago, but you saw a preso of the technique a year ago, > see . > > arin has the code from us so they could put it into production if they > so chose. > > randy > > From randy at psg.com Thu Aug 7 15:14:46 2008 From: randy at psg.com (Randy Bush) Date: Fri, 08 Aug 2008 05:14:46 +0900 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <8663qc39p6.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> Message-ID: <489B57B6.7030602@psg.com> >> How much does it help to filter the bogons? In one study conducted by >> Rob Thomas of a frequently attacked site, fully 60% of the naughty >> packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) > Stated another way, you can get 60% success on bogon filtering by > ignoring the free pool if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more /8s in the bank then we thought, eh? :) btw, patrick neglected the last sentences of that paragraph, which made me wonder what rob would actually say. luckily, in response to my post, rob replied that he/they would try to get some useful measures in the near term. i am patient. but your post makes me inclined to beg that he/that he have a few taxa within the bogon space. randy From darden at armc.org Thu Aug 7 14:55:13 2008 From: darden at armc.org (Patrick Darden) Date: Thu, 07 Aug 2008 15:55:13 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <20080807192826.GM25292@cgi.jachomes.com> References: <489B3516.9060005@armc.org> <20080807192826.GM25292@cgi.jachomes.com> Message-ID: <489B5321.5090803@armc.org> Hi Jay, Jay R. Ashworth wrote: > You really think Michael is malicious in his intent? > You've spent a whole lot of time paying now attention around here, > haven't you? > > I think Michael tends to get confrontational. As, apparently, do you. I'm on a lot of the same lists Michael is on. Have been since 1997. I have a lot of respect for him, with reservations gathered from experience. He is sharp, and he has a sharp tongue. > No, cute soundbites don't make you an expert. > > But in this case, Dillon's right, and you're wrong: your attempt to > trivialize the specific issue on point (allocation within the 1918 > space internal to a company network) by implying that the only reasons > to do it the way he suggests amount to "leaving space for soda > machines" only proves in public that you don't know what you're talking > about. > > No, you are wrong. Your attempt to trivialize what I have to say by calling it cute only proves that you don't know what you are talking about. Bad logic, isn't it? Statement that you are wrong, then "proving it" with nonsense addressing someone's character without addressing the point.... Your mislabelling my tongue-in-cheek ongoing obsession with soda machines as Trivializing only proves you have no sense of humor. I remember when some kids at MIT first put their dorm's soda machine on the internet. Man that was cool. You could ping it and find out how many cokes were left, and their temperature.... > As randy would put it, I encourage my competitors to hire you to > architect their WANs. > > Thank you. Your bile does you credit. --Patrick Darden From jra at baylink.com Thu Aug 7 16:24:27 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 7 Aug 2008 17:24:27 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <489B5321.5090803@armc.org> References: <489B3516.9060005@armc.org> <20080807192826.GM25292@cgi.jachomes.com> <489B5321.5090803@armc.org> Message-ID: <20080807212427.GU25292@cgi.jachomes.com> On Thu, Aug 07, 2008 at 03:55:13PM -0400, Patrick Darden wrote: > Jay R. Ashworth wrote: > >You really think Michael is malicious in his intent? > >You've spent a whole lot of time paying now attention around here, > >haven't you? > > I think Michael tends to get confrontational. As, apparently, do you. Sure. And he's not always right either; none of us are. But he gave cogent arguments to support his point, and you gave us coke machines -- worse, *accused him*, backhandedly, of leaving space for coke machines. See below. > I'm on a lot of the same lists Michael is on. Have been since 1997. I > have a lot of respect for him, with reservations gathered from > experience. He is sharp, and he has a sharp tongue. None of which amounts to "wants to hurt people", which is what you accused him of. > >No, cute soundbites don't make you an expert. > > > >But in this case, Dillon's right, and you're wrong: your attempt to > >trivialize the specific issue on point (allocation within the 1918 > >space internal to a company network) by implying that the only reasons > >to do it the way he suggests amount to "leaving space for soda > >machines" only proves in public that you don't know what you're talking > >about. > > No, you are wrong. Your attempt to trivialize what I have to say by > calling it cute only proves that you don't know what you are talking > about. Bad logic, isn't it? Statement that you are wrong, then > "proving it" with nonsense addressing someone's character without > addressing the point.... And yet I see tha tyou don't yourself bother to try to prove your argument; you merely continue to go after Michael and I on peripheral points. No pun intended. > Your mislabelling my tongue-in-cheek ongoing obsession with soda > machines as Trivializing only proves you have no sense of humor. I > remember when some kids at MIT first put their dorm's soda machine on > the internet. Man that was cool. You could ping it and find out how > many cokes were left, and their temperature.... Sure. Online coke machines are just about as cool as coffee-pot webcams. But they're orthogonal to the discussion that was at hand, and your returning to that well in the middle of a serious discussion suggests that you, yourself, are not all that serious. Once is tongue in cheek. Twice or three times is dilettante. > >As randy would put it, I encourage my competitors to hire you to > >architect their WANs. > > Thank you. Your bile does you credit. I don't know, Patrick; you seem to be the one emotionalizing the argument. I'm out of this one though; we are certainly out of AUP. 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. -- (Josef Stalin) From Stefan.Fouant at neustar.biz Thu Aug 7 16:26:42 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Thu, 7 Aug 2008 17:26:42 -0400 Subject: Excessive Latency on Verio backbone Message-ID: Is there something going on In Verio's backbone this afternoon? It seems I am getting excessive latency between two of my sites which are directly connected through AS 2914: rtrpxny> traceroute 140.174.21.x as-number-lookup traceroute to 140.174.21.x (140.174.21.x), 30 hops max, 40 byte packets 1 129.250.192.89 (129.250.192.89) [AS 2914] 0.762 ms 0.513 ms 0.589 ms 2 ae-1.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.220) [AS 2914] 0.622 ms 0.554 ms 0.594 ms MPLS Label=127664 CoS=0 TTL=1 S=1 3 p64-2-0-0.r20.chcgil09.us.bb.gin.ntt.net (129.250.5.4) [AS 2914] 28.434 ms 28.430 ms 28.880 ms MPLS Label=326737 CoS=0 TTL=1 S=0 MPLS Label=102000 CoS=0 TTL=1 S=1 4 ae-0.r21.chcgil09.us.bb.gin.ntt.net (129.250.3.98) [AS 2914] 28.965 ms 28.551 ms 28.545 ms MPLS Label=468133 CoS=0 TTL=1 S=0 MPLS Label=102000 CoS=0 TTL=2 S=1 5 p64-7-0-3.r20.snjsca04.us.bb.gin.ntt.net (129.250.5.20) [AS 2914] 88.941 ms 88.935 ms 88.968 ms MPLS Label=144065 CoS=0 TTL=1 S=0 MPLS Label=102000 CoS=0 TTL=3 S=1 6 ae-1.r21.plalca01.us.bb.gin.ntt.net (129.250.5.32) [AS 2914] 89.777 ms 89.894 ms 89.885 ms MPLS Label=102000 CoS=0 TTL=1 S=1 7 xe-4-1.r04.plalca01.us.bb.gin.ntt.net (129.250.4.122) [AS 2914] 201.308 ms 213.554 ms 211.560 ms ? output truncated ? Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D From deepak at ai.net Thu Aug 7 16:28:11 2008 From: deepak at ai.net (Deepak Jain) Date: Thu, 07 Aug 2008 17:28:11 -0400 Subject: IPv6 bogons/unallocated space list? Message-ID: <489B68EB.4060301@ai.net> Is there such a beast yet? I didn't see anything on the CYMRU page (so its either completely obvious, or not there). Given the shrinking use of IPv4 bogon lists and the increasing need of a well-updated IPv6 one, I figured I'd ask. thanks, Deepak From rs at seastrom.com Thu Aug 7 16:35:24 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 07 Aug 2008 17:35:24 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B57B6.7030602@psg.com> (Randy Bush's message of "Fri, 08 Aug 2008 05:14:46 +0900") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> Message-ID: <864p5w4ig3.fsf@seastrom.com> Randy Bush writes: >>> How much does it help to filter the bogons? In one study conducted by >>> Rob Thomas of a frequently attacked site, fully 60% of the naughty >>> packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) >> >> Stated another way, you can get 60% success on bogon filtering by >> ignoring the free pool > > if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more /8s in > the bank then we thought, eh? :) I guess I didn't really word that clearly. My point was that by not including the free pool in your candidates for filtering (i.e., only filtering out packets from addresses that will never be allocated or are permanently reserved such as 1918 space), you're only sacrificing 40% of your likely hits... and that number is going down over time. Why not just cut to the chase and make a filter that will never go stale, take any possible lumps on the bogus packet announcement side, and collect handsomely on the operational side? > btw, patrick neglected the last sentences of that paragraph, which made > me wonder what rob would actually say. luckily, in response to my post, > rob replied that he/they would try to get some useful measures in the > near term. i am patient. I read that thrice and thought "wtf?" twice, until I properly dereferenced "rob" to "robt", not "rs". Heh. > but your post makes me inclined to beg that he/that he have a few taxa > within the bogon space. Come, come, elucidate your thoughts. -r From arnold at nipper.de Thu Aug 7 16:36:12 2008 From: arnold at nipper.de (Arnold Nipper) Date: Thu, 07 Aug 2008 23:36:12 +0200 Subject: IPv6 bogons/unallocated space list? In-Reply-To: <489B68EB.4060301@ai.net> References: <489B68EB.4060301@ai.net> Message-ID: <489B6ACC.3070108@nipper.de> On 07.08.2008 23:28 Deepak Jain wrote > Is there such a beast yet? I didn't see anything on the CYMRU page (so > its either completely obvious, or not there). > > Given the shrinking use of IPv4 bogon lists and the increasing need of a > well-updated IPv6 one, I figured I'd ask. > http://www.space.net/~gert/RIPE/ipv6-filters.html should be fairly up to date. Arnold -- Arnold Nipper, AN45 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From robt at cymru.com Thu Aug 7 16:38:49 2008 From: robt at cymru.com (Rob Thomas) Date: Thu, 07 Aug 2008 16:38:49 -0500 Subject: IPv6 bogons/unallocated space list? In-Reply-To: <489B68EB.4060301@ai.net> References: <489B68EB.4060301@ai.net> Message-ID: <489B6B69.8000009@cymru.com> > Is there such a beast yet? I didn't see anything on the CYMRU page (so > its either completely obvious, or not there). It's not easily located, but it does exist: It is maintained by Team 6Bogon <6bogon at inetcore.com>. We and they would LOVE to have your feedback! -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From robt at cymru.com Thu Aug 7 16:38:47 2008 From: robt at cymru.com (Rob Thomas) Date: Thu, 07 Aug 2008 16:38:47 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B57B6.7030602@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> Message-ID: <489B6B67.9010202@cymru.com> Hi, NANOG (he says with a shout)! > btw, patrick neglected the last sentences of that paragraph, which made > me wonder what rob would actually say. luckily, in response to my post, > rob replied that he/they would try to get some useful measures in the > near term. i am patient. Yep yep, have some results at last. Sorry, the queries took a bit longer than planned. Note that the study I conducted which populated the "60 Days of Basic Naughtiness" presentation is now years old. Such studies, like me, don't necessarily age well. :) This is not meant to replace a more comprehensive and clueful study by the likes of Vern, Stefan, and the CAIDA crew. As folks may know we have a large Darknet[1] project. In there we collect the scanning activity of malware, backscatter, and the like. Often we can tie the scanning pattern to a family of malware or maltool. If the source of a scan or probe is a bogon, we tag it that way in our data store. I went back to 2008-01 and found the following percentages of bogons in our data: 2008-01: 0.001095262% 2008-02: 0.001759343% 2008-03: 0.001619555% 2008-04: 0.001433908% 2008-05: 0.001182351% 2008-06: 0.130534559% 2008-07: 0.002327683% 2008-08: 0.001258054% (thus far) That's not a lot of bogon activity in the Darknets, though Darknets are only one measure of malevolent traffic. Your mileage may vary, etc. [1] Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From darden at armc.org Thu Aug 7 16:52:14 2008 From: darden at armc.org (Darden, Patrick S.) Date: Thu, 7 Aug 2008 17:52:14 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: <20080807212427.GU25292@cgi.jachomes.com> Message-ID: Hi Jay, Jay Ashworth: > Sure. And he's not always right either; none of us are. > But he gave cogent arguments to support his point, and you gave us He gave good arguments. You, however, did not. > None of which amounts to "wants to hurt people", which is what you >accused him of. I was out of line here. I apologize to Michael. I don't think he took offense, but if he did I genuinely regret it. > And yet I see tha tyou don't yourself bother to try to prove your > argument; you merely continue to go after Michael and I on peripheral >points. No pun intended. Didn't have to: you didn't address anything other than personal or peripheral stuff. > Sure. Online coke machines are just about as cool as coffee-pot > webcams. They were in 1995. Back when the first one went online. That was too cool for me to express. > But they're orthogonal to the discussion that was at hand, and your > returning to that well in the middle of a serious discussion suggests > that you, yourself, are not all that serious. Or perhaps that I was trying to cool the discussion down a bit. I had already tried to bring it to a close once.... It was an extended hyperbole of ridiculousness. Soda machines. MMMMMMMMMmmmmmmmmm. > Once is tongue in cheek. > Twice or three times is dilettante. No, I think it just proves that saying the same stupid joke three times doesn't make it funny. Doesn't mean I am a dilettante network operator. Just means I'm not funny. ;-) > I don't know, Patrick; you seem to be the one emotionalizing the > argument. Yeah, I have a sharp tongue too. And I am a dillettante. And everything I say is just so cute and precious. And I am Wrong. > I'm out of this one though; we are certainly out of AUP. I'm with you on this, for sure. If you want to address me off-list please feel free. --Patrick Darden From patrick at ianai.net Thu Aug 7 17:04:50 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 7 Aug 2008 18:04:50 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B57B6.7030602@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> Message-ID: [Just a correction because Randy attributed something to me that I didn't do.] On Aug 7, 2008, at 4:14 PM, Randy Bush wrote: > btw, patrick neglected the last sentences of that paragraph, which > made > me wonder what rob would actually say. luckily, in response to my > post, > rob replied that he/they would try to get some useful measures in the > near term. i am patient. _patrick_ did not cut anything from that paragraph. Check the archives, the whole paragraph is in my post. Rob Seastrom cut patrick's quote off when he replied. -- TTFN, patrick From patrick at ianai.net Thu Aug 7 17:16:21 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 7 Aug 2008 18:16:21 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <864p5w4ig3.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> <864p5w4ig3.fsf@seastrom.com> Message-ID: <33B2130F-FFB4-40D7-BB6E-35D2985FB228@ianai.net> On Aug 7, 2008, at 5:35 PM, Robert E. Seastrom wrote: > Randy Bush writes: > >>>> How much does it help to filter the bogons? In one study >>>> conducted by >>>> Rob Thomas of a frequently attacked site, fully 60% of the naughty >>>> packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.) >>> >>> Stated another way, you can get 60% success on bogon filtering by >>> ignoring the free pool >> >> if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more / >> 8s in >> the bank then we thought, eh? :) > > I guess I didn't really word that clearly. > > My point was that by not including the free pool in your candidates > for filtering (i.e., only filtering out packets from addresses that > will never be allocated or are permanently reserved such as 1918 > space), you're only sacrificing 40% of your likely hits... and that > number is going down over time. Why not just cut to the chase and > make a filter that will never go stale, take any possible lumps on the > bogus packet announcement side, and collect handsomely on the > operational side? I guess I parsed that differently than you did. When he said "fully 60% of the naughty packets were obvious bogons", I read that as meaning 60% of all bad packets (bogon-sourced or otherwise) were from bogon space. If my interpretation is correct, you cannot tell anything about which % was from permanently bad space vs. unallocated space. Rob T., could you clarify for us please? Also, filtering bogons has the same utility / dangers of MD5. Many people think MD5 is a "good thing", even though the amount of downtime caused by it is (at least) several orders of magnitude larger than the amount of downtime caused by successful RST attacks. I think the danger outweighs the benefit. If you are arguing the same thing here, that's fine with me. But let's find out what the danger is and make the decision. Oh, and then everyone should take their own advice and de-configure MD5. :-) -- TTFN, patrick From robt at cymru.com Thu Aug 7 17:19:42 2008 From: robt at cymru.com (Rob Thomas) Date: Thu, 07 Aug 2008 17:19:42 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <33B2130F-FFB4-40D7-BB6E-35D2985FB228@ianai.net> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> <864p5w4ig3.fsf@seastrom.com> <33B2130F-FFB4-40D7-BB6E-35D2985FB228@ianai.net> Message-ID: <489B74FE.8030804@cymru.com> > I guess I parsed that differently than you did. When he said "fully 60% > of the naughty packets were obvious bogons", I read that as meaning 60% > of all bad packets (bogon-sourced or otherwise) were from bogon space. That's correct. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From randy at psg.com Thu Aug 7 17:59:20 2008 From: randy at psg.com (Randy Bush) Date: Fri, 08 Aug 2008 07:59:20 +0900 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B6B67.9010202@cymru.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> <489B6B67.9010202@cymru.com> Message-ID: <489B7E48.4070307@psg.com> rob, > If the source of a scan or probe is a bogon, we tag it that way in our > data store. I went back to 2008-01 and found the following percentages > of bogons in our data: > > 2008-01: 0.001095262% > 2008-02: 0.001759343% > 2008-03: 0.001619555% > 2008-04: 0.001433908% > 2008-05: 0.001182351% > 2008-06: 0.130534559% > 2008-07: 0.002327683% > 2008-08: 0.001258054% (thus far) this is an extremely far cry from 60%. what am i not understanding? and can you separate reserved (127, ...) and unallocated? randy From niels=nanog at bakker.net Thu Aug 7 18:03:21 2008 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 8 Aug 2008 01:03:21 +0200 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B7E48.4070307@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> <489B6B67.9010202@cymru.com> <489B7E48.4070307@psg.com> Message-ID: <20080807230320.GW51825@burnout.tpb.net> * randy at psg.com (Randy Bush) [Fri 08 Aug 2008, 00:59 CEST]: > rob, >> If the source of a scan or probe is a bogon, we tag it that way in our >> data store. I went back to 2008-01 and found the following percentages >> of bogons in our data: [..] >> 2008-08: 0.001258054% (thus far) > > this is an extremely far cry from 60%. what am i not understanding? > > and can you separate reserved (127, ...) and unallocated? This is scanning of darknets - usually you're interested in what comes back, i.e. can you 0wn it? so src has to be valid. (D)DoS of course are much more likely to come closer to the 60% number. No need to get the SYN+ACKs or the ICMP echo replies back... -- Niels. From robt at cymru.com Thu Aug 7 18:13:12 2008 From: robt at cymru.com (Rob Thomas) Date: Thu, 07 Aug 2008 18:13:12 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <489B7E48.4070307@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> <489B6B67.9010202@cymru.com> <489B7E48.4070307@psg.com> Message-ID: <489B8188.7050203@cymru.com> Hey, Randy. > this is an extremely far cry from 60%. what am i not understanding? There are a few factors at work here. One, the 60% figure was from 2001-03-16. There were more bogons then, and our sundry measures saw a lot more malevolence from bogon space. A popular belief in the underground in 2001 was that spoofing in general, and the use of bogon space specifically, added a layer of protection for their collections of compromised hosts. In the age of masses of compromised routers, servers, and workstations, that's no longer a necessary defensive measure. At circa US $.04 each, bots are easily replaced. Compromised routers don't cost much more than that. Two, we really can't compare the two (time issues aside). The 60% figure came from a study of a frequently (as in daily) attacked web site. The figures I shared today came from our Darknets, which are more global and not limited to a certain type of service or site owner. Third, that site has been split into multiple sites (after about 2005) so unfortunately I can't easily reproduce the study from 2001. That is a real bummer. So I'm not comparing apples and apples. We also track DDoS attacks, malware propagation, and other Internet malevolence. As a shot from the hip, I'll say we see very little abuse from bogon IP space. I won't say we see no abuse from bogon space, however, so we keep bogons automatically filtered on our border. I like to keep the online criminal toolkit as sparse as I can. :) > and can you separate reserved (127, ...) and unallocated? I can indeed, though it'll take me a bit to do so. Again, stay tuned. Thanks, Rob. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From robt at cymru.com Thu Aug 7 18:14:55 2008 From: robt at cymru.com (Rob Thomas) Date: Thu, 07 Aug 2008 18:14:55 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080807230320.GW51825@burnout.tpb.net> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <489B3923.3000309@templin.org> <772F968B-2EC2-4AAD-8646-D83E37B22D2E@ianai.net> <8663qc39p6.fsf@seastrom.com> <489B57B6.7030602@psg.com> <489B6B67.9010202@cymru.com> <489B7E48.4070307@psg.com> <20080807230320.GW51825@burnout.tpb.net> Message-ID: <489B81EF.3000006@cymru.com> > This is scanning of darknets - usually you're interested in what comes > back, i.e. can you 0wn it? so src has to be valid. Yep yep. -- Rob Thomas Team Cymru http://www.team-cymru.org/ cmn_err(CEO_PANIC, "Out of coffee!"); From pauldotwall at gmail.com Thu Aug 7 18:56:44 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 7 Aug 2008 19:56:44 -0400 Subject: facebook worm In-Reply-To: References: Message-ID: <620fd17c0808071656tc3d9c9dr6ce2fce7921b7ee7@mail.gmail.com> Gadi, Please take a few moments to reflect on: http://www.nanog.org/endsystem.html I'd appreciate it if you'd try and keep future off-topic postings like this to a minimum, as it makes the list difficult to wade through to get to what matters. Regards, Paul (not currently MLC, though I promise to put you in your place once the SC affords me the privlege :) On Thu, Aug 7, 2008 at 12:44 AM, Gadi Evron wrote: > Hi all. You may want to be ready for a *possible* support lines flood today. > > Yesterday I discovered a fast-spreading facebook worm. It spreads by sending > messages to all your facebook friends, from your account, asking them to > click on a link in the .pl ccTLD. > > This worm is somewhat similar to zlob, here is a link to a kaspersky paper > on a previous iteration of it, they call it koobface: > http://www.kaspersky.com/news?id=207575670 > > The worm collects spam subject lines from, and then sends the users personal > data to the following C&C: > zzzping.com > > I spoke with DirectNIC last night and the Registrar Operations (reg-ops) > mailing list was updated that the domain is no longer reachable. That was > very fast response time from DirectNIC, which we appreciate. > > The worm is still fast-spreading, watch the statistics as they fly: > http://www.d9.pl/system/stats.php > > The facebook security team is working on this, and they are quite capable. > The security operations community has been doing analysis and take-downs, > but the worm seems to still be spreading. > > All anti virus vendors have been notified, and detection (if not removal) > should be added within a few hours to a few days. > > For now, while users may get infected, their information is safe (unless the > worm has a secondary contact C&C which I have not verified yet). > > It seems like some users may have learned not to click on links in email, > but any other medium does not compute. > > Gadi. > > From ge at linuxbox.org Thu Aug 7 20:35:26 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 7 Aug 2008 20:35:26 -0500 (CDT) Subject: facebook worm In-Reply-To: References: Message-ID: [top-posting] Now that this worm has been somewhat balked, I'd like to thank the membership for your patience with this off-topic post. I realize it is probably as annoying to some as it was useful to others. My thinking was that on the rare occasion when we can anticipate *possible* and *serious* floods and bottle-necks at ISP tech-support lines, across multiple providers and regions, we should share that information. NANOG remains the best place for such information sharing. While I realize this mailing list is mostly about network operations and less about ISP operations, we had a discussion in the past where we have seen some in our community do use this information effectively and find it useful. This is a rare occasion indeed, but an explanation and an apology were in order. Thank you, Gadi. On Wed, 6 Aug 2008, Gadi Evron wrote: > Hi all. You may want to be ready for a *possible* support lines flood today. > > Yesterday I discovered a fast-spreading facebook worm. It spreads by sending > messages to all your facebook friends, from your account, asking them to > click on a link in the .pl ccTLD. > > This worm is somewhat similar to zlob, here is a link to a kaspersky paper on > a previous iteration of it, they call it koobface: > http://www.kaspersky.com/news?id=207575670 > > The worm collects spam subject lines from, and then sends the users personal > data to the following C&C: > zzzping.com > > I spoke with DirectNIC last night and the Registrar Operations (reg-ops) > mailing list was updated that the domain is no longer reachable. That was > very fast response time from DirectNIC, which we appreciate. > > The worm is still fast-spreading, watch the statistics as they fly: > http://www.d9.pl/system/stats.php > > The facebook security team is working on this, and they are quite capable. > The security operations community has been doing analysis and take-downs, but > the worm seems to still be spreading. > > All anti virus vendors have been notified, and detection (if not removal) > should be added within a few hours to a few days. > > For now, while users may get infected, their information is safe (unless the > worm has a secondary contact C&C which I have not verified yet). > > It seems like some users may have learned not to click on links in email, but > any other medium does not compute. > > Gadi. > From sam_mailinglists at spacething.org Fri Aug 8 04:47:48 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Fri, 08 Aug 2008 10:47:48 +0100 Subject: Hardware capture platforms In-Reply-To: <48917D76.7070208@spacething.org> References: <20080729155511.R42026@iama.hypergeek.net><75cb24520807291712r5 0167c9ap3a444d7b4792c7e3@mail.gmail.com> <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B850.4080600@deaddrop.org> <48917D76.7070208@spacething.org> Message-ID: <489C1644.7040902@spacething.org> All, On the subject of turning off mac learning on a switch, I've just discovered this - an unusual way of using RSPAN to force the MAC learning off on Cisco switches: http://blog.internetworkexpert.com/2008/02/05/turning-switch-into-hub/ # Turn MAC learning on ports Fa0/1 - 3 vtp mode transparent ! vlan 555 remote-span ! interface range Fa 0/1 - 3 switchport trunk encapsulation dot1q switchport mode trunk switchport trunk allowed vlan 555 switchport trunk native vlan 555 Sam Sam Stickland wrote: > Lynda wrote: >> Warren Kumari wrote: >> >>> What I am looking for is: Small enough to live in my notebook bag >>> (e.g.: 4 port with a wall wart.) Cheap Simple 10/100/1000Mbps >> >> I don't believe that such a thing ever existed. Hubs that did 10/100, >> certainly, but I've never ever seen a hub that did gig speeds. >> > Depends what you mean by 'hub' I guess. I thought the term referred to > a device that was half-duplex only, and had no address learning. GE > has never supported half-duplex. > > Sam > From cidr-report at potaroo.net Fri Aug 8 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Aug 2008 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200808081200.m78C03bX064382@wattle.apnic.net> This report has been generated at Fri Aug 8 21:16:30 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 01-08-08 276746 172840 02-08-08 277156 173225 03-08-08 277237 173424 04-08-08 276952 173871 05-08-08 277270 174215 06-08-08 277640 173603 07-08-08 276961 172748 08-08-08 275536 173068 AS Summary 29004 Number of ASes in routing system 12265 Number of ASes announcing only one prefix 5007 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88347136 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'). --- 08Aug08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 277366 174242 103124 37.2% All ASes AS4538 5007 876 4131 82.5% ERX-CERNET-BKB China Education and Research Network Center AS6389 3203 260 2943 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2993 677 2316 77.4% ASN-QWEST - Qwest AS4755 1700 290 1410 82.9% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 108 937 89.7% COVAD - Covad Communications Co. AS17488 1287 358 929 72.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6298 1779 878 901 50.6% COX-PHX - Cox Communications Inc. AS22773 973 85 888 91.3% CCINET-2 - Cox Communications Inc. AS8151 1475 592 883 59.9% Uninet S.A. de C.V. AS1785 1469 671 798 54.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4323 1487 694 793 53.3% TWTC - tw telecom holdings, inc. AS19262 935 234 701 75.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1217 526 691 56.8% CABLEONE - CABLE ONE AS2386 1565 912 653 41.7% INS-AS - AT&T Data Communications Services AS18101 711 153 558 78.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS9498 669 115 554 82.8% BBIL-AP BHARTI Airtel Ltd. AS6478 1016 466 550 54.1% ATT-INTERNET3 - AT&T WorldNet Services AS6197 953 477 476 49.9% BATI-ATL - BellSouth Network Solutions, Inc AS4766 882 415 467 52.9% KIXS-AS-KR Korea Telecom AS4808 618 155 463 74.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22047 565 129 436 77.2% VTR BANDA ANCHA S.A. AS855 587 156 431 73.4% CANET-ASN-4 - Bell Aliant AS9443 521 91 430 82.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1433 1007 426 29.7% ATT-INTERNET4 - AT&T WorldNet Services AS4134 833 419 414 49.7% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 546 151 395 72.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4780 716 324 392 54.7% SEEDNET Digital United Inc. AS17676 524 142 382 72.9% GIGAINFRA BB TECHNOLOGY Corp. AS3602 453 80 373 82.3% AS3602-RTI - Rogers Telecom Inc. AS16814 426 62 364 85.4% NSS S.A. Total 37588 11503 26085 69.4% Top 30 total Possible Bogus Routes 10.100.15.0/24 AS12739 NETLINE_AS NetLine Ltd 14.14.14.0/24 AS577 BACOM - Bell Canada 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.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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 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.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 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 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.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 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.134.0.0/15 AS8881 VERSATEL Versatel Deutschland 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 121.50.10.0/24 AS38236 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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/16 AS8546 YOUR-COMMS-UK-AS Your Communications Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 AS2018 TENET-1 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.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.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 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.254.192.0/19 AS2116 ASN-CATCHCOM Catch Communications 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.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 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 - tw telecom holdings, 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.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, 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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.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. 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.99.64.0/19 AS29789 REFLECTED - Reflected Networks, Inc. 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 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 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.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 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 cidr-report at potaroo.net Fri Aug 8 07:00:29 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Aug 2008 22:00:29 +1000 (EST) Subject: BGP Update Report Message-ID: <200808081200.m78C0TY8064433@wattle.apnic.net> BGP Update Report Interval: 07-Jul-08 -to- 07-Aug-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 101208 1.6% 81.0 -- SIFY-AS-IN Sify Limited 2 - AS4538 94439 1.5% 18.8 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS17488 76802 1.2% 55.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS5691 74254 1.1% 6750.4 -- MITRE-AS-5 - The MITRE Corporation 5 - AS6298 72337 1.1% 39.0 -- COX-PHX - Cox Communications Inc. 6 - AS7738 70391 1.1% 228.5 -- Telecomunicacoes da Bahia S.A. 7 - AS9051 65914 1.0% 401.9 -- IDM Autonomous System 8 - AS10396 64719 1.0% 1294.4 -- COQUI-NET - DATACOM CARIBE, INC. 9 - AS1803 64323 1.0% 50.9 -- ICMNET-5 - Sprint 10 - AS4766 47900 0.7% 53.9 -- KIXS-AS-KR Korea Telecom 11 - AS33783 45766 0.7% 277.4 -- EEPAD 12 - AS8866 43198 0.7% 135.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 13 - AS17974 41321 0.6% 63.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS4788 40328 0.6% 18.8 -- TMNET-AS-AP TM Net, Internet Service Provider 15 - AS8151 37924 0.6% 25.6 -- Uninet S.A. de C.V. 16 - AS3464 34522 0.5% 91.8 -- ASC-NET - Alabama Supercomputer Network 17 - AS9929 33682 0.5% 106.9 -- CNCNET-CN China Netcom Corp. 18 - AS18231 27893 0.4% 112.9 -- EXATT-AS-AP IOL NETCOM LTD 19 - AS702 26805 0.4% 48.8 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 20 - AS47467 26561 0.4% 13280.5 -- GRIFFEL Griffel AB TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47467 26561 0.4% 13280.5 -- GRIFFEL Griffel AB 2 - AS27245 16218 0.2% 8109.0 -- HEIDRICK-CHICAGO - HEIDRICK 3 - AS5691 74254 1.1% 6750.4 -- MITRE-AS-5 - The MITRE Corporation 4 - AS30850 12469 0.2% 6234.5 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 5 - AS29910 5418 0.1% 5418.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 6 - AS39105 4134 0.1% 4134.0 -- CLASS-AS SC Class Computers And Service SRL 7 - AS22678 3947 0.1% 3947.0 -- OSDE 8 - AS23082 18622 0.3% 3724.4 -- MPHI - Michigan Public Health Institute 9 - AS40627 7426 0.1% 3713.0 -- RC-COLO1 - RingCentral Inc 10 - AS44656 3448 0.1% 3448.0 -- HOLOSFIND-ROMANIA HOLOSFIND SRL 11 - AS28361 3285 0.1% 3285.0 -- 12 - AS44194 3261 0.1% 3261.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 13 - AS5382 2038 0.0% 2038.0 -- TELESYSTEM-NET Planet Service Srl 14 - AS36988 5605 0.1% 1868.3 -- MILLICOM-SL 15 - AS30929 1776 0.0% 1776.0 -- HUTCB Hidrotechnical Faculty - Technical University 16 - AS28542 1751 0.0% 1751.0 -- Gobierno del Estado de Coahuila 17 - AS39244 1661 0.0% 1661.0 -- TEQNOBASE-AS Teqnobase AS 18 - AS36966 1635 0.0% 1635.0 -- Edgenet 19 - AS40256 6445 0.1% 1611.2 -- ACS-HCMS-ASN - Affiliated Computer Services, Inc. 20 - AS42795 1600 0.0% 1600.0 -- XEROX-GENERAL-AS Xerox General Services TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 74114 1.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 63264 0.9% AS9583 -- SIFY-AS-IN Sify Limited 3 - 194.126.143.0/24 56525 0.8% AS9051 -- IDM Autonomous System 4 - 83.228.71.0/24 35575 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.128.192.0/18 25386 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 72.50.96.0/20 20520 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 7 - 63.84.91.0/24 14884 0.2% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 8 - 62.182.216.0/21 13290 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 9 - 91.203.160.0/22 13281 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 10 - 196.42.0.0/20 12689 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 11 - 195.47.233.0/24 12459 0.2% AS30850 -- DESMIE-AS Hellenic Trasmission System Operator S.A. 12 - 210.214.144.0/24 12233 0.2% AS9583 -- SIFY-AS-IN Sify Limited 13 - 210.214.128.0/23 11757 0.2% AS9583 -- SIFY-AS-IN Sify Limited 14 - 203.63.26.0/24 10720 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 15 - 196.42.48.0/20 9348 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 72.50.112.0/20 9257 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 17 - 202.150.80.0/20 8752 0.1% AS9251 -- SPEEDNET-AP PT Speed Internet Digital 18 - 216.255.56.0/21 8670 0.1% AS7106 -- OHIOBRIGHTNET - Com Net, Inc. 19 - 196.27.104.0/21 7325 0.1% AS30969 -- TAN-NET TransAfrica Networks AS8668 -- TELONE-AS TelOne Zimbabwe P/L 20 - 196.27.108.0/22 7158 0.1% AS30969 -- TAN-NET TransAfrica Networks 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 drp at murphy.com Fri Aug 8 10:09:02 2008 From: drp at murphy.com (David Prude) Date: Fri, 08 Aug 2008 11:09:02 -0400 Subject: earthlink.net mail admin contact? Message-ID: <489C618E.9010309@murphy.com> Hello, Could someone from earthlink.net mail ops please contact me off-list? Thank you, -David Prude -- David Prude System Administrator Murphy & Durieu (212)618-0320 From william.allen.simpson at gmail.com Fri Aug 8 11:07:20 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 08 Aug 2008 12:07:20 -0400 Subject: facebook worm In-Reply-To: References: Message-ID: <489C6F38.7030808@gmail.com> Gadi Evron wrote: > My thinking was that on the rare occasion when we can anticipate > *possible* and *serious* floods and bottle-necks at ISP tech-support > lines, across multiple providers and regions, we should share that > information. NANOG remains the best place for such information sharing. > I agree. > While I realize this mailing list is mostly about network operations and > less about ISP operations, we had a discussion in the past where we have > seen some in our community do use this information effectively and find > it useful. > ISP operations are network operations. Fast spreading worms with remediation through DNS configuration that may affect tech-support costs are obviously network related. From patrick at zill.net Fri Aug 8 11:33:29 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Fri, 08 Aug 2008 12:33:29 -0400 Subject: facebook worm In-Reply-To: References: Message-ID: <489C7559.2010008@zill.net> Gadi Evron wrote: > While I realize this mailing list is mostly about network operations and > less about ISP operations, we had a discussion in the past where we have > seen some in our community do use this information effectively and find > it useful. Thing is, I had already heard about the facebook worm via my other sources of info (and a day earlier); same as anyone else who is paying attention to such subjects did. When info like this is spread across multiple lists/sites, the second and subsequent times it is noise instead of signal. I lurk on nanog because of what it focuses on. Turning nanog into a rehash of digg's technology section or the front page of news.com reduces nanog's utility. --Patrick From justin at justinshore.com Fri Aug 8 11:32:53 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 08 Aug 2008 11:32:53 -0500 Subject: Hardware capture platforms In-Reply-To: <20080731163136.GK28903@cgi.jachomes.com> References: <221481660807291926y225766a3k136860c555d964c@mail.gmail.com> <56F5BC5F404CF84896C447397A1AAF207AF0BC@MAIL.nosi.netos.com> <7280DF7C-8677-4552-8B27-1F695CBFFA33@kumari.net> <4890B72F.4070303@aset.com> <20080731163136.GK28903@cgi.jachomes.com> Message-ID: <489C7535.70209@justinshore.com> Jay R. Ashworth wrote: > And, note carefully: some "dual-speed hubs" are actually a 10BT hub and > a 100BT hub *with a switch between them*. I forget which brand I > caught this on, but it bit me a couple of years back. 3COM Dual-Speed 10/100 hubs were this way. Got bit by that too back in the day. Technically I think all hubs supporting both 10 and 100 would have to do this. I can't think of any technical way of getting around the problem without doing this. Justin From LarrySheldon at cox.net Fri Aug 8 11:48:33 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Fri, 08 Aug 2008 11:48:33 -0500 Subject: facebook worm In-Reply-To: <489C7559.2010008@zill.net> References: <489C7559.2010008@zill.net> Message-ID: <489C78E1.60701@cox.net> Patrick Giagnocavo wrote: > Turning nanog into a rehash of digg's technology section or the front > page of news.com reduces nanog's utility. As does the days and days of rehash of one of Gadi's postings. From brett at the-watsons.org Fri Aug 8 11:56:53 2008 From: brett at the-watsons.org (brett watson) Date: Fri, 8 Aug 2008 09:56:53 -0700 Subject: facebook worm In-Reply-To: <489C78E1.60701@cox.net> References: <489C7559.2010008@zill.net> <489C78E1.60701@cox.net> Message-ID: <542DFC28-C461-4002-BC85-EBC552413E4D@the-watsons.org> On Aug 8, 2008, at 9:48 AM, Laurence F. Sheldon, Jr. wrote: > Patrick Giagnocavo wrote: > >> Turning nanog into a rehash of digg's technology section or the >> front page of news.com reduces nanog's utility. > > As does the days and days of rehash of one of Gadi's postings. And all of this BS is even *more* off topic than folks are claiming Gadi's post was. This list goes off topic all the time, at least Gadi's post was technical. From cscora at apnic.net Fri Aug 8 13:08:23 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Aug 2008 04:08:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200808081808.m78I8NtN020952@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 09 Aug, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 265478 Prefixes after maximum aggregation: 129570 Deaggregation factor: 2.05 Unique aggregates announced to Internet: 129591 Total ASes present in the Internet Routing Table: 28883 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25165 Origin ASes announcing only one prefix: 12193 Transit ASes present in the Internet Routing Table: 3718 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: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 569 Unregistered ASNs in the Routing Table: 209 Number of 32-bit ASNs allocated by the RIRs: 55 Prefixes from 32-bit ASNs in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 778 Number of addresses announced to Internet: 1889709152 Equivalent to 112 /8s, 162 /16s and 172 /24s Percentage of available address space announced: 51.0 Percentage of allocated address space announced: 61.9 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.0 Total number of prefixes smaller than registry allocations: 130048 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 61000 Total APNIC prefixes after maximum aggregation: 22709 APNIC Deaggregation factor: 2.69 Prefixes being announced from the APNIC address blocks: 57975 Unique aggregates announced from the APNIC address blocks: 26131 APNIC Region origin ASes present in the Internet Routing Table: 3322 APNIC Prefixes per ASN: 17.45 APNIC Region origin ASes announcing only one prefix: 880 APNIC Region transit ASes present in the Internet Routing Table: 512 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 370241056 Equivalent to 22 /8s, 17 /16s and 110 /24s Percentage of available APNIC address space announced: 78.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: 121751 Total ARIN prefixes after maximum aggregation: 65124 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 91093 Unique aggregates announced from the ARIN address blocks: 34943 ARIN Region origin ASes present in the Internet Routing Table: 12344 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4761 ARIN Region transit ASes present in the Internet Routing Table: 1179 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 360292768 Equivalent to 21 /8s, 121 /16s and 161 /24s Percentage of available ARIN address space announced: 74.1 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: 57093 Total RIPE prefixes after maximum aggregation: 34735 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 52243 Unique aggregates announced from the RIPE address blocks: 35108 RIPE Region origin ASes present in the Internet Routing Table: 11705 RIPE Prefixes per ASN: 4.46 RIPE Region origin ASes announcing only one prefix: 6155 RIPE Region transit ASes present in the Internet Routing Table: 1764 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 368507008 Equivalent to 21 /8s, 246 /16s and 248 /24s Percentage of available RIPE address space announced: 84.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: 21040 Total LACNIC prefixes after maximum aggregation: 5302 LACNIC Deaggregation factor: 3.97 Prefixes being announced from the LACNIC address blocks: 19279 Unique aggregates announced from the LACNIC address blocks: 10899 LACNIC Region origin ASes present in the Internet Routing Table: 977 LACNIC Prefixes per ASN: 19.73 LACNIC Region origin ASes announcing only one prefix: 319 LACNIC Region transit ASes present in the Internet Routing Table: 165 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 54245376 Equivalent to 3 /8s, 59 /16s and 184 /24s Percentage of available LACNIC address space announced: 53.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: 4028 Total AfriNIC prefixes after maximum aggregation: 1224 AfriNIC Deaggregation factor: 3.29 Prefixes being announced from the AfriNIC address blocks: 4372 Unique aggregates announced from the AfriNIC address blocks: 1913 AfriNIC Region origin ASes present in the Internet Routing Table: 246 AfriNIC Prefixes per ASN: 17.77 AfriNIC Region origin ASes announcing only one prefix: 78 AfriNIC Region transit ASes present in the Internet Routing Table: 49 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12534016 Equivalent to 0 /8s, 191 /16s and 65 /24s Percentage of available AfriNIC address space announced: 37.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 1691 345 178 Videsh Sanchar Nigam Ltd. Aut 17488 1288 88 92 Hathway IP Over Cable Interne 9583 1174 92 492 Sify Limited 4766 856 6390 349 Korea Telecom (KIX) 4134 833 13516 353 CHINANET-BACKBONE 23577 831 35 703 Korea Telecom (ATM-MPLS) 4780 712 353 64 Digital United Inc. 18101 712 167 33 Reliance Infocom Ltd Internet 9498 669 291 54 BHARTI BT INTERNET LTD. 4808 618 1112 137 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 6389 3200 3358 208 bellsouth.net, inc. 209 2975 3860 625 Qwest 6298 1778 270 768 Cox Communicatons 2386 1560 707 893 AT&T Data Communications Serv 4323 1489 1078 380 Time Warner Telecom 1785 1450 478 102 AppliedTheory Corporation 7018 1411 5830 989 AT&T WorldNet Services 11492 1218 151 23 Cable One 20115 1117 1082 571 Charter Communications 18566 1045 296 10 Covad 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 414 1792 372 TDC Tele Danmark 3215 371 2756 106 France Telecom Transpac 8452 357 188 11 TEDATA 3301 333 1460 304 TeliaNet Sweden 3320 323 7047 271 Deutsche Telekom AG 8866 316 77 21 Bulgarian Telecommunication C 8551 288 270 38 Bezeq International 5462 286 666 27 Telewest Broadband 680 274 2047 264 DFN-IP service G-WiN 6746 268 126 243 Dynamic Network Technologies, 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 1476 2592 225 UniNet S.A. de C.V. 11830 624 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 475 235 63 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 417 85 48 ENTEL CHILE S.A. 11172 409 118 71 Servicios Alestra S.A de C.V 10620 407 107 51 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 346 24 101 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 495 63 28 LINKdotNET AS number 20858 402 34 3 EgyNet 3741 269 855 224 The Internet Solution 2018 211 213 130 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5713 129 540 74 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 33776 114 6 3 Starcomms Nigeria Limited 29571 107 13 8 Ci Telecom Autonomous system 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 3200 3358 208 bellsouth.net, inc. 209 2975 3860 625 Qwest 6298 1778 270 768 Cox Communicatons 4755 1691 345 178 Videsh Sanchar Nigam Ltd. Aut 2386 1560 707 893 AT&T Data Communications Serv 4323 1489 1078 380 Time Warner Telecom 8151 1476 2592 225 UniNet S.A. de C.V. 1785 1450 478 102 AppliedTheory Corporation 7018 1411 5830 989 AT&T WorldNet Services 17488 1288 88 92 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 209 2975 2350 Qwest 4755 1691 1513 Videsh Sanchar Nigam Ltd. Aut 1785 1450 1348 AppliedTheory Corporation 8151 1476 1251 UniNet S.A. de C.V. 17488 1288 1196 Hathway IP Over Cable Interne 11492 1218 1195 Cable One 4323 1489 1109 Time Warner Telecom 18566 1045 1035 Covad Communications 6298 1778 1010 Cox Communicatons 22773 973 910 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 7018 AT&T WorldNet Servic 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.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 63.143.71.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:146 /13:293 /14:523 /15:1054 /16:10035 /17:4344 /18:7529 /19:15967 /20:18606 /21:18147 /22:22946 /23:23926 /24:139133 /25:843 /26:1036 /27:758 /28:86 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2035 3200 bellsouth.net, inc. 6298 1752 1778 Cox Communicatons 209 1726 2975 Qwest 2386 1236 1560 AT&T Data Communications Serv 11492 1199 1218 Cable One 17488 1096 1288 Hathway IP Over Cable Interne 1785 1064 1450 AppliedTheory Corporation 4755 1042 1691 Videsh Sanchar Nigam Ltd. Aut 9583 1030 1174 Sify Limited 18566 1026 1045 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:129 12:2102 13:2 14:1 15:22 16:3 17:5 18:13 20:35 24:1085 32:59 38:479 40:92 41:695 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:526 59:512 60:456 61:992 62:1208 63:2036 64:3262 65:2376 66:3496 67:1221 68:743 69:2289 70:823 71:116 72:2008 73:6 74:1086 75:156 76:308 77:754 78:805 79:218 80:976 81:849 82:610 83:378 84:570 85:966 86:397 87:684 88:340 89:1296 90:33 91:1389 92:247 93:720 94:95 96:53 97:44 98:301 99:3 114:81 115:34 116:923 117:330 118:193 119:442 120:63 121:581 122:808 123:372 124:904 125:1176 128:360 129:198 130:135 131:411 132:67 133:9 134:187 135:33 136:222 137:94 138:146 139:88 140:500 141:103 142:404 143:335 144:390 145:51 146:372 147:156 148:517 149:198 150:129 151:181 152:143 153:136 154:10 155:252 156:174 157:285 158:186 159:294 160:273 161:119 162:216 163:155 164:516 165:455 166:318 167:329 168:623 169:139 170:425 171:32 172:10 188:1 189:431 190:2264 192:5799 193:4140 194:3241 195:2550 196:1025 198:3738 199:3307 200:5588 201:1471 202:7691 203:8077 204:3962 205:2144 206:2361 207:2760 208:3502 209:3465 210:2586 211:1076 212:1425 213:1600 214:172 215:50 216:4483 217:1212 218:343 219:428 220:1065 221:455 222:309 End of report From roque at lacnic.net Fri Aug 8 15:38:50 2008 From: roque at lacnic.net (Roque Gagliano) Date: Fri, 8 Aug 2008 17:38:50 -0300 Subject: End Users assignments from LACNIC from 2801:0000::/24 with longest prefix length of /48. Message-ID: <996EBA64-5319-4EF4-86AF-8070F6BEFCA0@lacnic.net> Dear Friends, LACNIC has just approved IPv6 assignment policies for End Users. These policies will be implemented from September 1st 2008. In order to comply with these new policies, LACNIC will assign from the IPv6 address block 2801:0000::/24 with a longest prefix length of / 48. We kindly request that you update your internal information and filters. Please remember that all resources administrated by LACNIC are listed at: http://www.lacnic.net/sp/registro/ Best Regards, Roque Gagliano - LACNIC -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From xploitable at gmail.com Fri Aug 8 16:27:33 2008 From: xploitable at gmail.com (n3td3v) Date: Fri, 8 Aug 2008 22:27:33 +0100 Subject: facebook worm In-Reply-To: <489C7559.2010008@zill.net> References: <489C7559.2010008@zill.net> Message-ID: <4b6ee9310808081427v1c535cd0ub92105eda4b0428e@mail.gmail.com> On Fri, Aug 8, 2008 at 5:33 PM, Patrick Giagnocavo wrote: > Gadi Evron wrote: > >> While I realize this mailing list is mostly about network operations and >> less about ISP operations, we had a discussion in the past where we have >> seen some in our community do use this information effectively and find it >> useful. > > Thing is, I had already heard about the facebook worm via my other sources > of info (and a day earlier); same as anyone else who is paying attention to > such subjects did. > > When info like this is spread across multiple lists/sites, the second and > subsequent times it is noise instead of signal. > He's ruining Nanog, just so he can get self glorification and self gratification in himself as some kind of leader of internet security industry when he really is just a sad fat person who is a nobody. All the best, n3td3v From deepak at ai.net Fri Aug 8 17:53:23 2008 From: deepak at ai.net (Deepak Jain) Date: Fri, 08 Aug 2008 18:53:23 -0400 Subject: IPv6 FAQ Message-ID: <489CCE63.9000108@ai.net> According to: http://www.netbsd.org/docs/network/ipv6/ * Larger IP address space. IPv4 uses only 32 bits for IP address space, which allows only 4 billion nodes to be identified on the Internet. 4 billion may look like a large number; however, it is less than the human population on the earth! IPv6 allows 128 bits for IP address space, allowing 340282366920938463463374607431768211456 (three hundred forty undecillion) nodes to be uniquely identified on the Internet. A larger address space allows true end to end communication, without NAT or other short term workarounds against the IPv4 address shortage. (These days NAT is a headache for new protocol deployment and has scalability issues; we really need to decommission NAT networks for the Internet to grow further). * Deploy more recent technologies. After IPv4 was specified 20 years ago, we saw many technical improvements in networking. IPv6 includes a number of those improvements in its base specification, allowing people to assume these features are available everywhere, anytime. "Recent technologies" include, but are not limited to, the following: o Autoconfiguration. With IPv4, DHCP exists but is optional. A novice user can get into trouble if they visit another site without a DHCP server. With IPv6, a "stateless host autoconfiguration" mechanism is mandatory. This is much simpler to use and manage than IPv4 DHCP. RFC2462 has the specification for it. o Security. With IPv4, IPsec is optional and you need to ask the peer if it supports IPsec. With IPv6, IPsec support is mandatory. By mandating IPsec, we can assume that you can secure your IP communication whenever you talk to IPv6 devices. o Friendly to traffic engineering technologies. IPv6 was designed to allow better support for traffic engineering like diffserv or intserv (RSVP). We do not have a single standard for traffic engineering yet, so the IPv6 base specification reserves a 24-bit space in the header field for those technologies and is able to adapt to coming standards better than IPv4. o Multicast. Multicast is mandatory in IPv6, which was optional in IPv4. The IPv6 base specifications themselves extensively use multicast. o Better support for ad-hoc networking. Scoped addresses allow better support for ad-hoc (or "zeroconf") networking. IPv6 supports anycast addresses, which can also contribute to service discoveries. o and more. * A cure to routing table growth. The IPv4 backbone routing table size has been a big headache to ISPs and backbone operators. The IPv6 addressing specification restricts the number of backbone routing entries by advocating route aggregation. With the current IPv6 addressing specification, we will see only 8192 routes on the default-free zone. * Simplified header structures. IPv6 has simpler packet header structures than IPv4. It will allow future vendors to implement hardware acceleration for IPv6 routers easier. * Allows flexible protocol extensions. IPv6 allows more flexible protocol extensions than IPv4 does, by introducing a protocol header chain. Even though IPv6 allows flexible protocol extensions, IPv6 does not impose overhead to intermediate routers. It is achieved by splitting headers into two flavors: the headers intermediate routers need to examine, and the headers the end nodes will examine. This also eases hardware acceleration for IPv6 routers. * Smooth transition from IPv4. There were number of transition considerations made during the IPv6 discussions. Also, there are large number of transition mechanisms available. You can pick the most suitable one for your site. * Follows the key design principles of IPv4. IPv4 was a very successful design, as proven by the ultra large-scale global deployment. IPv6 is "new version of IP", and it follows many of the design features that made IPv4 very successful. This will also allow smooth transition from IPv4 to IPv6. * and more. What I'd like to say is that someone here is playing fast and loose with "mandatory" and "required" (or its true for same definitions of mandatory or required). A couple of these jumped out at me like, "Only 8192 routes on the DFZ" and other things. Rather than jumping down someone's throat here, are these assumptions rampant (or even accurate)? We came across this as we were trying to enhance our own Ops groups documents to share with customers, and well, I don't think we want to share this. ;) Deepak From drc at virtualized.org Fri Aug 8 18:11:19 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 8 Aug 2008 16:11:19 -0700 Subject: IPv6 FAQ In-Reply-To: <489CCE63.9000108@ai.net> References: <489CCE63.9000108@ai.net> Message-ID: On Aug 8, 2008, at 3:53 PM, Deepak Jain wrote: > According to: http://www.netbsd.org/docs/network/ipv6/ The fine folks at NetBSD really need to update their IPv6 FAQ. That stuff looks like the IPv6 marketing spiel from 1997 or so that has long ago been proven ... 'optimistic'. > Rather than jumping down someone's throat here, are these > assumptions rampant (or even accurate)? Unfortunately, you still see the same sort of grandiose claims being made at non-technical (particularly governmental policy-related) events. As for accuracy, IPv6 does provide more address space, the headers are simpler, and stateful auto-config is often provided if you want it. 3 out of 7... Regards, -drc From MTormey at aol.com Fri Aug 8 19:14:53 2008 From: MTormey at aol.com (MTormey at aol.com) Date: Fri, 8 Aug 2008 20:14:53 EDT Subject: facebook worm Message-ID: I feel like I'm on the public blogs with all kinds of idiots giving their opinion and everything degenerating as each entry is posted. I am only a lurker on NANOG, just seeking intelligent info for my job. I've been receiving these emails for a few years now, but this is ridiculous. Not intelligent information. Please stop! **************Looking for a car that's sporty, fun and fits in your budget? Read reviews on AOL Autos. (http://autos.aol.com/cars-BMW-128-2008/expert-review?ncid=aolaut00050000000017 ) From hannigan at gmail.com Sat Aug 9 00:49:47 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 9 Aug 2008 01:49:47 -0400 Subject: facebook worm In-Reply-To: <542DFC28-C461-4002-BC85-EBC552413E4D@the-watsons.org> References: <489C7559.2010008@zill.net> <489C78E1.60701@cox.net> <542DFC28-C461-4002-BC85-EBC552413E4D@the-watsons.org> Message-ID: <2d106eb50808082249w2dae004cjcac953edfc7914c9@mail.gmail.com> On Fri, Aug 8, 2008 at 12:56 PM, brett watson wrote: > On Aug 8, 2008, at 9:48 AM, Laurence F. Sheldon, Jr. wrote: > >> Patrick Giagnocavo wrote: >> >>> Turning nanog into a rehash of digg's technology section or the front >>> page of news.com reduces nanog's utility. >> >> As does the days and days of rehash of one of Gadi's postings. > > And all of this BS is even *more* off topic than folks are claiming Gadi's > post was. This list goes off topic all the time, at least Gadi's post was > technical. > > Not only was his post technical, it was relevant to operator revenue. "Application" doesn't take these calls, the network operators do. I can't think of a more relevant NANOG post of late. Saving us a headache by predefining an issue seems quite on topic to me. FWIW. YMMV. -M< [ No offense towards "Application" intended.] From ge at linuxbox.org Sat Aug 9 01:08:40 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 9 Aug 2008 01:08:40 -0500 (CDT) Subject: facebook worm In-Reply-To: <2d106eb50808082249w2dae004cjcac953edfc7914c9@mail.gmail.com> References: <489C7559.2010008@zill.net> <489C78E1.60701@cox.net> <542DFC28-C461-4002-BC85-EBC552413E4D@the-watsons.org> <2d106eb50808082249w2dae004cjcac953edfc7914c9@mail.gmail.com> Message-ID: On Sat, 9 Aug 2008, Martin Hannigan wrote: > On Fri, Aug 8, 2008 at 12:56 PM, brett watson wrote: >> On Aug 8, 2008, at 9:48 AM, Laurence F. Sheldon, Jr. wrote: >> >>> Patrick Giagnocavo wrote: >>> >>>> Turning nanog into a rehash of digg's technology section or the front >>>> page of news.com reduces nanog's utility. >>> >>> As does the days and days of rehash of one of Gadi's postings. >> >> And all of this BS is even *more* off topic than folks are claiming Gadi's >> post was. This list goes off topic all the time, at least Gadi's post was >> technical. >> >> > > > Not only was his post technical, it was relevant to operator revenue. > "Application" doesn't take these calls, the network operators do. I > can't think of a more relevant NANOG post of late. Saving us a > headache by predefining an issue seems quite on topic to me. FWIW. > YMMV. > > -M< At least unlike blackworm, this one's damage could be measured. Gadi. From fergdawg at netzero.net Sat Aug 9 01:38:16 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sat, 9 Aug 2008 06:38:16 GMT Subject: facebook worm Message-ID: <20080808.233816.28690.1@webmail07.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Gadi Evron wrote: >At least unlike blackworm, this one's damage could be measured. Actually, BlackWorm was measured -- I have the CAIDA poster in my cube. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj4DBQFInTtbq1pz9mNUZTMRAlvOAJ4ntljT/bbS2pJ+K78M2EzwsS7dUACWNGVu mDIH8oOFa6nhjccw7Es3xA== =P/Kv -----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 michael.dillon at bt.com Sat Aug 9 05:06:55 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 9 Aug 2008 11:06:55 +0100 Subject: IPv6 FAQ In-Reply-To: <489CCE63.9000108@ai.net> Message-ID: > Rather than jumping down someone's throat here, are these > assumptions rampant (or even accurate)? We came across this > as we were trying to enhance our own Ops groups documents to > share with customers, and well, I don't think we want to > share this. ;) You can get a lot better information on ARIN's wiki at http://www.getipv6.info I don't believe that the site has an IPv6 FAQ page to give to customers, but if you want to post your draft so far, then I'm sure we can all contribute to it. --Michael Dillon From eslerj at gmail.com Sat Aug 9 11:41:06 2008 From: eslerj at gmail.com (Joel Esler) Date: Sat, 9 Aug 2008 12:41:06 -0400 Subject: Verizon Contactg In-Reply-To: References: Message-ID: You've been forwarded. J On Aug 6, 2008, at 12:36 PM, Alan Halachmi wrote: > Would someone from Verizon please contact me? Or, if you know of a > technical contact for Verizon, please pass it along. Thanks. > > Best, > Alan > -- Joel Esler ? http://blog.joelesler.net ? http://www.dearcupertino.com [m] From bpfankuch at cpgreeley.com Sat Aug 9 13:59:32 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Sat, 9 Aug 2008 12:59:32 -0600 Subject: UK DNS server Message-ID: <01759D50DC387C45A018FE1817CE27D74F2744F569@CPExchange1.cpgreeley.com> Hello. Looking for a UK based DNS server that allows open relay. Please contact me off list, using it to test a slightly problematic geo dns system. From jgreco at ns.sol.net Sat Aug 9 16:02:35 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 9 Aug 2008 16:02:35 -0500 (CDT) Subject: DNS attacks evolve Message-ID: <200808092102.m79L2ZNj031860@aurora.sol.net> It's usually interesting to be proven wrong, but perhaps not in this case. I was among the first to point out that the 11-second DNS poisioning claim made by Vixie only worked out to about a week of concentrated attack after the patch. This was a number I extrapolated purely from Paul's 11-second number and the factor-of-65000x introduced by port randomization. I am very, very, very disheartened to be shown to be wrong. As if 8 days wasn't bad enough, a concentrated attack has been shown to be effective in 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html With modern data rates being what they are, I believe that this is still a severe operational hazard, and would like to suggest a discussion of further mitigation strategies. On my list of concepts: 1) Use of multiple IP addresses for queries (reduce success rate somewhat) 2) Rate-limiting of query traffic, since I really doubt many sites actually have recursers that need to be able to spike to many times their normal traffic, 3) Forwarding of failed queries (which I believe BIND doesn't currently allow) to a "backup" server (which would seem to be interesting in combination with 2) 4) I wonder if it wouldn't make sense to change the advice for large-scale recursers to run multiple instances of BIND, internally distribute the requests (random pf/ipfw load balancing) to present a version of 1) that would render smaller segments of the user base vulnerable in the event of success. It would represent more memory, more CPU, and more requests, but a smaller victory for attackers. 5) Modify BIND to report mismatch QID's. Not a log report per hit, but some reasonable strategy. Make the default installation instructions include a script to scan for these - often - and mail hostmaster. 6) Have someone explain to me the reasoning behind allowing the corruption of in-cache data, even if the data would otherwise be in-baliwick. I'm not sure I quite get why this has to be. It would seem to me to be safer to discard the data. (Does not eliminate the problem, but would seem to me to reduce it) 7) Have someone explain to me the repeated claims I've seen that djbdns and Nominum's server are not vulnerable to this, and why that is. It would seem that the floor is wide open to a large number of possibilities for mitigating this beyond the patch. ... 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 chris.paul at rexconsulting.net Sat Aug 9 16:18:12 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sat, 09 Aug 2008 14:18:12 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... Message-ID: <489E0994.9000100@rexconsulting.net> Paul, Sorry if this is real stupid for some reason because I don't think about DNS all day (I'm the ldap dude) but since we have faster networks and faster cpus today, what would be the harm in switching to use TCP for DNS clients? The latency on the web isn't dns anymore ever it seems to me..... Wouldn't that eliminate the ability to poison clients' caches? any why wouldn't persistent client-server dns connections make sense? any stupid little bsd or linux box can handle several thousand connections today pretty easily if tuned correctly by some reasonably competent primate CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net * web: http://www.rexconsulting.net* phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From cchurc05 at harris.com Sat Aug 9 16:22:27 2008 From: cchurc05 at harris.com (Church, Charles) Date: Sat, 9 Aug 2008 16:22:27 -0500 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489E0994.9000100@rexconsulting.net> References: <489E0994.9000100@rexconsulting.net> Message-ID: TCP would work, but it makes it more difficult to do Anycast, which works well with UDP and DNS. Chuck -----Original Message----- From: Chris Paul [mailto:chris.paul at rexconsulting.net] Sent: Saturday, August 09, 2008 5:18 PM To: nanog at merit.edu Subject: maybe a dumb idea on how to fix the dns problems i don't know.... Paul, Sorry if this is real stupid for some reason because I don't think about DNS all day (I'm the ldap dude) but since we have faster networks and faster cpus today, what would be the harm in switching to use TCP for DNS clients? The latency on the web isn't dns anymore ever it seems to me..... Wouldn't that eliminate the ability to poison clients' caches? any why wouldn't persistent client-server dns connections make sense? any stupid little bsd or linux box can handle several thousand connections today pretty easily if tuned correctly by some reasonably competent primate CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net * web: http://www.rexconsulting.net* phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From jabley at ca.afilias.info Sat Aug 9 17:04:34 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sat, 9 Aug 2008 18:04:34 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: References: <489E0994.9000100@rexconsulting.net> Message-ID: <21E442DF-53EF-4D65-B6A1-C8FFCECA0D64@ca.afilias.info> On 9 Aug 2008, at 17:22, Church, Charles wrote: > TCP would work, but it makes it more difficult to do Anycast, which > works well with UDP and DNS. TCP works pretty well with anycast too, if you're careful. It's helpful if your transactions are short-lived. I've seen concern expressed that a server which can handle 100,000 qps over UDP might well fare substantially more poorly if every query arrives using TCP transport. The business of large-scale HTTP is a fairly well-understood problem, however, and has some similar characteristics, so perhaps this is less of a long-term problem. I don't know, I haven't run any experiments to figure out the practical impact on performance of using TCP exclusively. There is, however, the practical consideration that a generation of firewall "administrators" seem to believe that 53/tcp is only ever used for zone transfers, and can safely be closed for all other use. I suspect that a route with better practical implications will be for resolvers to pad queries with additional entropy as EDNS0 options, and to fall back to TCP if EDNS0 is unsupported. That requires some confidence that EDNS0 support in authority servers is widespread, however. draft-vixie-dnsext-dns0x20 describes a shorter-term option for introducing additional entropy into queries using UDP transport, with or without EDNS0. Joe From matt at credibleinstitution.org Sat Aug 9 17:10:52 2008 From: matt at credibleinstitution.org (Matt F) Date: Sat, 09 Aug 2008 18:10:52 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <21E442DF-53EF-4D65-B6A1-C8FFCECA0D64@ca.afilias.info> References: <489E0994.9000100@rexconsulting.net> <21E442DF-53EF-4D65-B6A1-C8FFCECA0D64@ca.afilias.info> Message-ID: <489E15EC.2060801@credibleinstitution.org> Why not just require TCP for a lookup if a response with an incorrect TXID is received? You could require TCP for just the one lookup or for some configured interval, say 1 hour. That should slow attackers down substantially. Joe Abley wrote: > > On 9 Aug 2008, at 17:22, Church, Charles wrote: > >> TCP would work, but it makes it more difficult to do Anycast, which >> works well with UDP and DNS. > > TCP works pretty well with anycast too, if you're careful. It's > helpful if your transactions are short-lived. > > I've seen concern expressed that a server which can handle 100,000 qps > over UDP might well fare substantially more poorly if every query > arrives using TCP transport. The business of large-scale HTTP is a > fairly well-understood problem, however, and has some similar > characteristics, so perhaps this is less of a long-term problem. I > don't know, I haven't run any experiments to figure out the practical > impact on performance of using TCP exclusively. > > There is, however, the practical consideration that a generation of > firewall "administrators" seem to believe that 53/tcp is only ever > used for zone transfers, and can safely be closed for all other use. > > I suspect that a route with better practical implications will be for > resolvers to pad queries with additional entropy as EDNS0 options, and > to fall back to TCP if EDNS0 is unsupported. That requires some > confidence that EDNS0 support in authority servers is widespread, > however. > > draft-vixie-dnsext-dns0x20 describes a shorter-term option for > introducing additional entropy into queries using UDP transport, with > or without EDNS0. > > > Joe > > > From jabley at ca.afilias.info Sat Aug 9 17:15:56 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sat, 9 Aug 2008 18:15:56 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489E15EC.2060801@credibleinstitution.org> References: <489E0994.9000100@rexconsulting.net> <21E442DF-53EF-4D65-B6A1-C8FFCECA0D64@ca.afilias.info> <489E15EC.2060801@credibleinstitution.org> Message-ID: <3093DC2B-7806-423A-890E-F11649C0B576@ca.afilias.info> On 9 Aug 2008, at 18:10, Matt F wrote: > Why not just require TCP for a lookup if a response with an > incorrect TXID is received? You could require TCP for just the one > lookup or for some configured interval, say 1 hour. That should > slow attackers down substantially. That sounds like a good way for a remote attacker to make a resolver disable UDP transport for a server, more or less at will. I'm not sure I like the sound of that. Joe From vixie at isc.org Sat Aug 9 17:23:30 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 09 Aug 2008 22:23:30 +0000 Subject: DNS attacks evolve In-Reply-To: <200808092102.m79L2ZNj031860@aurora.sol.net> (Joe Greco's message of "Sat\, 9 Aug 2008 16\:02\:35 -0500 \(CDT\)") References: <200808092102.m79L2ZNj031860@aurora.sol.net> Message-ID: jgreco at ns.sol.net (Joe Greco) writes: > I am very, very, very disheartened to be shown to be wrong. As if 8 days > wasn't bad enough, a concentrated attack has been shown to be effective in > 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html that's what theory predicted. guessing a 30-or-so-bit number isn't "hard." > With modern data rates being what they are, I believe that this is still a > severe operational hazard, and would like to suggest a discussion of further > mitigation strategies. > ... i have two gripes here. first, can we please NOT use the nanog@ mailing list as a workshop for discussing possible DNS spoofing mitigation strategies? namedroppers at ops.ietf.org already has a running gun battle on that topic, and dns-operations at lists.oarci.net would be appropriate. but unless we're going to talk about deploying BCP38, which would be the mother of all mitigations for DNS spoofing attacks, it's offtopic on nanog at . second, please think carefully about the word "severe". any time someone can cheerfully hammer you at full-GigE speed for 10 hours, you've got some trouble, and you'll need to monitor for those troubles. 11 seconds of 10MBit/sec fit my definition of "severe". 10 hours at 1000MBit/sec doesn't. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Sat Aug 9 17:28:21 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 09 Aug 2008 22:28:21 +0000 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489E15EC.2060801@credibleinstitution.org> (Matt F.'s message of "Sat\, 09 Aug 2008 18\:10\:52 -0400") References: <489E15EC.2060801@credibleinstitution.org> Message-ID: matt at credibleinstitution.org (Matt F) writes: > Why not just require TCP for a lookup if a response with an incorrect > TXID is received? You could require TCP for just the one lookup or for > some configured interval, say 1 hour. That should slow attackers down > substantially. because TCP is considered optional by many authority DNS server operators. it's only required if you expect AXFR or if you ever emit a TC bit. if you don't want to do TCP then you can rule out the TC bit and AXFR and just not do TCP, and you'll be dead-to-rights within the various DNS protocol RFCs. anyone who insists on reaching such a server by TCP will be shit-outta-luck. however, this suggestion and dozens of others are being workshopped all day every day by actual DNS experts. you may not know about those discussions because they are not occurring on nanog@, where they would be off-topic, like this thread here. please join namedroppers at ops.ietf.org and perhaps dns-operations at lists.oarci.net if you want to discuss DNS protocol matters. please, please, please don't open this can of, um, worms on nanog@ again. not even on a sunday afternoon when just about anything goes. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From randy at psg.com Sat Aug 9 17:32:00 2008 From: randy at psg.com (Randy Bush) Date: Sun, 10 Aug 2008 07:32:00 +0900 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: References: <489E15EC.2060801@credibleinstitution.org> Message-ID: <489E1AE0.6020905@psg.com> Paul Vixie wrote: > hey are not occurring on nanog@, where they would be off-topic, > like this thread here you may want to read the aup. by my read they are not off topic. randy From chris.paul at rexconsulting.net Sat Aug 9 17:48:43 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sat, 09 Aug 2008 15:48:43 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: References: <489E15EC.2060801@credibleinstitution.org> Message-ID: <489E1ECB.9060700@rexconsulting.net> Paul Vixie wrote: > because TCP is considered optional by many authority DNS server operators. > Hey authority DNS server operators. Can you make a change to your servers to always allow TCP client connections? Would this be difficult? What would be the harm? > it's only required if you expect AXFR or if you ever emit a TC bit. if you > don't want to do TCP then you can rule out the TC bit and AXFR and just not > do TCP, and you'll be dead-to-rights within the various DNS protocol RFCs. > what RFCs forbid TCP for clients? I thought TCP was an option for clients. I'm not spending the rest of my sunday though reading rfcs....... and sure as hell not joining another list because to tell you the truth, I don't really care as much about the typical angry Sunday list poster (talk about redundant statement....) thanks for the thoughts, though Paul. I'll leave the rest of this discussion (should it exist) to others in their forum of choice.... I'm thinking of nice insalade caprese with true mozarella di bufalo right now.... now That's A Sunday!" CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From nazgul at somewhere.com Sat Aug 9 17:50:42 2008 From: nazgul at somewhere.com (Kee Hinckley) Date: Sat, 9 Aug 2008 18:50:42 -0400 Subject: DNS attacks evolve In-Reply-To: References: <200808092102.m79L2ZNj031860@aurora.sol.net> Message-ID: <285C28C0-D850-4125-A70E-5965F6DD52B3@somewhere.com> On Aug 9, 2008, at 6:23 PM, Paul Vixie wrote: > second, please think carefully about the word "severe". any time > someone > can cheerfully hammer you at full-GigE speed for 10 hours, you've > got some > trouble, and you'll need to monitor for those troubles. 11 seconds of > 10MBit/sec fit my definition of "severe". 10 hours at 1000MBit/sec > doesn't. I think what we're seeing here is the realization that DNS hosting, like web hosting, is no longer something that can simply be done by tossing a machine on the internet and leaving it there; it needs professional management, monitoring and updates. That's always a hard transition for some people to make, but it's one that has to be made; that's the world we live in. Kee Hinckley CEO/CTO Somewhere Inc. Somewhere: http://www.somewhere.com/ TechnoSocial: http://xrl.us/bh35i I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate those of everybody else. From mike at mtcc.com Sat Aug 9 17:57:52 2008 From: mike at mtcc.com (Michael Thomas) Date: Sat, 09 Aug 2008 15:57:52 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489E1AE0.6020905@psg.com> References: <489E15EC.2060801@credibleinstitution.org> <489E1AE0.6020905@psg.com> Message-ID: <489E20F0.9010905@mtcc.com> Randy Bush wrote: > Paul Vixie wrote: > >> hey are not occurring on nanog@, where they would be off-topic, >> like this thread here >> > > you may want to read the aup. by my read they are not off topic. > Also: given how serious the problem is, I'd think that far and wide perspective on this is appropriate. Knowing IETF, there is usually not nearly enough operations perspective than you'd like, and the various working group lists can be pretty daunting for somebody who's day job is to "merely" keep the net running. Mike, delurking From brett at the-watsons.org Sat Aug 9 19:25:01 2008 From: brett at the-watsons.org (brett watson) Date: Sat, 9 Aug 2008 17:25:01 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489E1ECB.9060700@rexconsulting.net> References: <489E15EC.2060801@credibleinstitution.org> <489E1ECB.9060700@rexconsulting.net> Message-ID: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> On Aug 9, 2008, at 3:48 PM, Chris Paul wrote: > > Paul Vixie wrote: >> because TCP is considered optional by many authority DNS server >> operators. >> > Hey authority DNS server operators. Can you make a change to your > servers to always allow TCP client connections? Would this be > difficult? What would be the harm? SYN flooding? From Valdis.Kletnieks at vt.edu Sun Aug 10 00:33:01 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 10 Aug 2008 01:33:01 -0400 Subject: IPv6 FAQ In-Reply-To: Your message of "Fri, 08 Aug 2008 18:53:23 EDT." <489CCE63.9000108@ai.net> References: <489CCE63.9000108@ai.net> Message-ID: <46306.1218346381@turing-police.cc.vt.edu> On Fri, 08 Aug 2008 18:53:23 EDT, Deepak Jain said: > o Security. With IPv4, IPsec is optional and you need to ask > the peer if it supports IPsec. With IPv6, IPsec support is mandatory. By > mandating IPsec, we can assume that you can secure your IP communication > whenever you talk to IPv6 devices. The *actual* distinction here is that an implementation can be a fully compliant IPv4 stack without any code to do IPSEC. The IPv6 stack is required to have the code. Nowhere does it say that it has to be enabled or configured, with the end result that probably 99.87% of the machines running IPv6 don't actually have the ability to negotiate an IPSEC connection. I suspect that in actual usage, it's a wash, because the sites that actually bother to configure IPSEC for IPv6 do it because they're *already* doing IPSEC for IPv4. Does anybody know of an actual production site that actually does IPSEC for IPv6 but not for IPv4? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From randy at psg.com Sun Aug 10 00:38:20 2008 From: randy at psg.com (Randy Bush) Date: Sun, 10 Aug 2008 14:38:20 +0900 Subject: IPv6 FAQ In-Reply-To: <46306.1218346381@turing-police.cc.vt.edu> References: <489CCE63.9000108@ai.net> <46306.1218346381@turing-police.cc.vt.edu> Message-ID: <489E7ECC.9050807@psg.com> > The *actual* distinction here is that an implementation can be a fully > compliant IPv4 stack without any code to do IPSEC. The IPv6 stack is > required to have the code. but usually does not. it's like the ipv6 forum, almost none of the members' servers have ipv6 enabled. randy From vixie at isc.org Sun Aug 10 00:45:43 2008 From: vixie at isc.org (Paul Vixie) Date: Sun, 10 Aug 2008 05:45:43 +0000 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> (brett watson's message of "Sat\, 9 Aug 2008 17\:25\:01 -0700") References: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> Message-ID: >> Paul Vixie wrote: >>> because TCP is considered optional by many authority DNS server >>> operators. > On Aug 9, 2008, at 3:48 PM, Chris Paul wrote: >> Hey authority DNS server operators. Can you make a change to your >> servers to always allow TCP client connections? Would this be >> difficult? What would be the harm? brett at the-watsons.org (brett watson) writes: > SYN flooding? SYN flooding is a specific instance of "have to hold too much state" whereas the reason for not considering TCP mandatory is the general form of "have to hold too much state". also note, the operators of those nameservers aren't reading nanog@, or indeed any other mailing list where they could all be reached. the installed base is, as usual, an impediment to righteous change. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From fw at deneb.enyo.de Sun Aug 10 03:58:09 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 10 Aug 2008 10:58:09 +0200 Subject: DNS attacks evolve In-Reply-To: <200808092102.m79L2ZNj031860@aurora.sol.net> (Joe Greco's message of "Sat, 9 Aug 2008 16:02:35 -0500 (CDT)") References: <200808092102.m79L2ZNj031860@aurora.sol.net> Message-ID: <87y735utzy.fsf@mid.deneb.enyo.de> * Joe Greco: > I am very, very, very disheartened to be shown to be wrong. As if 8 days > wasn't bad enough, a concentrated attack has been shown to be effective in > 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html Note that the actual bandwidth utilization on that GE link should be somewhere between 10% and 20% if you send minimally sized replies during spoofing. In fact, the theoretically predicted time for 50% success probability for 100mbps attacks is below one day. This also matches the numbers posted here: > 1) Use of multiple IP addresses for queries (reduce success rate somewhat) You must implement this carefully. Just using a load-balanced DNS setup doesn't work, for instance. The attacker could trigger the cache misses through a CNAME he controls, so he'd know which instance to attack in each round. > 2) Rate-limiting of query traffic, since I really doubt many sites actually > have recursers that need to be able to spike to many times their normal > traffic, The problem with that is that 130,000 queries over a 10 hour period (as in Evgeniy's experiment) are often lost in the noise. Only if the authoritative servers are RTT-wise close to your recursor, the attacker benefits from high query rates. > 3) Forwarding of failed queries (which I believe BIND doesn't currently > allow) to a "backup" server (which would seem to be interesting in > combination with 2) I don't think any queries fail in this scenario. > 4) I wonder if it wouldn't make sense to change the advice for large-scale > recursers to run multiple instances of BIND, internally distribute the > requests (random pf/ipfw load balancing) to present a version of 1) that > would render smaller segments of the user base vulnerable in the event of > success. It would represent more memory, more CPU, and more requests, > but a smaller victory for attackers. User-specific DNS caches are interesting from a privacy perspective, too. But I don't think they'll work, except when the cache is in the CPE. > 5) Modify BIND to report mismatch QID's. Not a log report per hit, but some > reasonable strategy. Make the default installation instructions include > a script to scan for these - often - and mail hostmaster. Yes, better monitoring is crucial. Recent BIND 9.5 has a counter for mismatched replies, which should provide at least one indicator. Due to the diversity of potential attacks, it's very difficult to set up generic monitoring. > 6) Have someone explain to me the reasoning behind allowing the corruption > of in-cache data, even if the data would otherwise be in-baliwick. I'm > not sure I quite get why this has to be. It would seem to me to be safer > to discard the data. (Does not eliminate the problem, but would seem to > me to reduce it) The idea is that the delegated zone can introduce additional servers not listed in the delegated zone. (It's one thing that gets you a bit of IPv6 traffic.) Unfortunately, it's likely that performance would suffer for some sites if resolver > 7) Have someone explain to me the repeated claims I've seen that djbdns and > Nominum's server are not vulnerable to this, and why that is. For DJBDNS, see: Nominum has published a few bits about their secret sauce: TCP fallback on detected attack attempts is expected to be sufficiently effective so that you can get away with a smaller source port pool. Even if it's not, on some platforms, a smallish pool is the only way to cope with the existing load until you can bring in more servers, so it's better than nothing. The TCP fallback idea was posted to namedroppers in 2006, in response to one of Bert's early drafts which evolved into the forgery resilience document, so it should not be encumbered. The heuristics when to trigger the attack could be, though. From jabley at ca.afilias.info Sun Aug 10 10:23:19 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sun, 10 Aug 2008 11:23:19 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: References: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> Message-ID: On 10 Aug 2008, at 01:45, Paul Vixie wrote: > SYN flooding is a specific instance of "have to hold too much state" > whereas > the reason for not considering TCP mandatory is the general form of > "have to > hold too much state". It may be worth clarifying that "not considering TCP mandatory" above is an implementation/operational choice, and not something that seems to be clearly endorsed by RFC 1035, such as it is. There are a lot of people who insist that TCP transport is used for nothing other than zone transfers in the DNS, and they do so not out of concern over potential TCP state explosion on their servers but instead because "that's what the last guy told me". That kind of reasoning doesn't need a bigger posse. Joe 4.2. Transport The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities must use virtual circuits because of the need for reliable transfer. The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal). From vixie at isc.org Sun Aug 10 10:56:23 2008 From: vixie at isc.org (Paul Vixie) Date: Sun, 10 Aug 2008 15:56:23 +0000 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: Your message of "Sun\, 10 Aug 2008 11\:23\:19 -0400." References: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> Message-ID: <42379.1218383783@nsa.vix.com> (here we are discussing dns protocol details on nanog@ again. must be sunday.) > From: Joe Abley > > It may be worth clarifying that "not considering TCP mandatory" above is > an implementation/operational choice, and not something that seems to be > clearly endorsed by RFC 1035, such as it is. > > There are a lot of people who insist that TCP transport is used for > nothing other than zone transfers in the DNS, and they do so not out of > concern over potential TCP state explosion on their servers but instead > because "that's what the last guy told me". That kind of reasoning > doesn't need a bigger posse. > > Joe > > 4.2. Transport > ... actually, it does (need a bigger posse). a little further on in RFC 1035 we find this gem: +--- | 4.2.2. TCP usage | ... | Several connection management policies are recommended: | | - The server should not block other activities waiting for TCP | data. | | - The server should support multiple connections. | | - The server should assume that the client will initiate | connection closing, and should delay closing its end of the | connection until all outstanding client requests have been | satisfied. | | - If the server needs to close a dormant connection to reclaim | resources, it should wait until the connection has been idle | for a period on the order of two minutes. In particular, the | server should allow the SOA and AXFR request sequence (which | begins a refresh operation) to be made on a single connection. | Since the server would be unable to answer queries anyway, a | unilateral close or reset may be used instead of a graceful | close. +--- in the era of RFC 1035 the philosophy was "be liberal in what you accept and be conservative in what you generate" because the other people on the network weren't trying to spam, ddos, or poison you. the above text is effectively a "please ddos me" bumper sticker worn across the ass of anyone who implements it. we're having a terrible time with UDP now simply because upstream sockets can now only be used once before they're closed, and any long-running query can tie up a file descriptor for a longish enough time to drain the pool down to the point where new downstream queries can't be accepted because existing upstream queries have not completed. file descriptors are the new "carbon footprint" of DNS. but at least in the UDP case the shortage is experienced only by the initiator. in the TCP case the shortage is experienced by both the initiator and the responder, and the responder is shackled by [4.2.2]. i don't want to completely dismiss the underlying idea of "fall back to TCP if someone guesses a few QID's wrong". however, i dismiss the idea that it's a simple universal solution. on a mailing list called namedroppers@ where i would more likely expect to see a discussion of fine points of DNS protocol, i spake thusly about a week ago, and so far have heard no reply, though i've implemented these recommendations on a server that only keeps 64 descriptors open at a time and it's been incredibly resistant to my poisoning attempts. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An embedded message was scrubbed... From: Paul Vixie Subject: Re: XQID (Re: Forgery Resistance phase #2 ) Date: Wed, 30 Jul 2008 19:00:06 +0000 Size: 3766 URL: From jabley at ca.afilias.info Sun Aug 10 11:51:26 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sun, 10 Aug 2008 12:51:26 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <42379.1218383783@nsa.vix.com> References: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> <42379.1218383783@nsa.vix.com> Message-ID: <925162EA-7946-4234-A8D1-BEF20D6AC4B0@ca.afilias.info> On 10 Aug 2008, at 11:56, Paul Vixie wrote: > (here we are discussing dns protocol details on nanog@ again. must > be sunday.) (Or alternatively we could just be discussing DNS operations, something that is entirely on-topic for this list, and conceivably of interest to the many hundreds of people who are subscribed here but not to other dns-specific lists. That was certainly my intent, even if it wasn't yours.) >> From: Joe Abley >> >> It may be worth clarifying that "not considering TCP mandatory" >> above is >> an implementation/operational choice, and not something that seems >> to be >> clearly endorsed by RFC 1035, such as it is. >> >> There are a lot of people who insist that TCP transport is used for >> nothing other than zone transfers in the DNS, and they do so not >> out of >> concern over potential TCP state explosion on their servers but >> instead >> because "that's what the last guy told me". That kind of reasoning >> doesn't need a bigger posse. >> >> Joe >> >> 4.2. Transport >> ... > > actually, it does (need a bigger posse). Rhetoric aside, no it doesn't. Choosing not to implement (or permit, as an operational decision) TCP because of concerns about state is what you go on to talk about; what you were actually replying to was the wholesale denial of 53/tcp out of simple ignorance, which I would be surprised to hear you endorse, even if it happens to coincide on this instance with the results of your analysis. Joe From vixie at isc.org Sun Aug 10 13:58:14 2008 From: vixie at isc.org (Paul Vixie) Date: Sun, 10 Aug 2008 18:58:14 +0000 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: Your message of "Sun, 10 Aug 2008 12:51:26 -0400." <925162EA-7946-4234-A8D1-BEF20D6AC4B0@ca.afilias.info> References: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> <42379.1218383783@nsa.vix.com> <925162EA-7946-4234-A8D1-BEF20D6AC4B0@ca.afilias.info> Message-ID: <63384.1218394694@nsa.vix.com> > > actually, it does (need a bigger posse). > > Rhetoric aside, no it doesn't. > > Choosing not to implement (or permit, as an operational decision) TCP > because of concerns about state is what you go on to talk about; what you > were actually replying to was the wholesale denial of 53/tcp out of > simple ignorance, which I would be surprised to hear you endorse, even if > it happens to coincide on this instance with the results of your > analysis. not doing tcp/53 because the last guy didn't do it is the first step toward not doing tcp/53 because it's amazingly fragile. sorry to cross the streams without a diagram. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tomb at byrneit.net Sun Aug 10 14:37:27 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 10 Aug 2008 12:37:27 -0700 Subject: FW: maybe a dumb idea on how to fix the dns problems i don't know.... Message-ID: <70D072392E56884193E3D2DE09C097A9F440@pascal.zaphodb.org> -----Original Message----- From: Tomas L. Byrnes Sent: Saturday, August 09, 2008 9:01 PM To: 'Chris Paul' Subject: RE: maybe a dumb idea on how to fix the dns problems i don't know.... Actually, the RFCs (RFC-1034 3.7RFC-1035 4.2, ref RFC-793; Implementation spec in RFC-1035 4.2.2; RFC-2136 2.1 says TCP is "at the discretion of the requestor";) say TCP "Should" be supported. It's optional, but recommended. The source of the guidance to block TCP is misguided "security" folks who confuse self-denial of service with policy enforcement. When security breaks functionality, it usually fails to secure, as users circumvent it, in my not so humble experience. BTW: In RFC 1034 5.3.1 PVM tipped to some of the issues that we are now dealing with, under the title of "Stub Resolvers". > -----Original Message----- > From: Chris Paul [mailto:chris.paul at rexconsulting.net] > Sent: Saturday, August 09, 2008 3:49 PM > Cc: nanog at merit.edu > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > > > Paul Vixie wrote: > > because TCP is considered optional by many authority DNS > server operators. > > > Hey authority DNS server operators. Can you make a change to your > servers to always allow TCP client connections? Would this be > difficult? > What would be the harm? > > it's only required if you expect AXFR or if you ever emit a > TC bit. > > if you don't want to do TCP then you can rule out the TC > bit and AXFR > > and just not do TCP, and you'll be dead-to-rights within > the various DNS protocol RFCs. > > > what RFCs forbid TCP for clients? I thought TCP was an option for > clients. I'm not spending the rest of my sunday though reading > rfcs....... and sure as hell not joining another list because to tell > you the truth, I don't really care as much about the typical angry > Sunday list poster (talk about redundant statement....) > > thanks for the thoughts, though Paul. I'll leave the rest of this > discussion (should it exist) to others in their forum of choice.... > I'm thinking of nice insalade caprese with true mozarella di bufalo > right now.... now That's A Sunday!" > > CP > > -- > Chris Paul > Rex Consulting, Inc > 157 Rainbow Drive #5703, Livingston, TX 77399-1057 > email: chris.paul at rexconsulting.net > web: http://www.rexconsulting.net > phone, direct: +1, 831.706.4211 > phone, toll-free: +1, 888.403.8996 > > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon, this > information by persons or entities other than the intended recipient > is prohibited. > Rex Consulting, Inc. is a California Corporation. > > P Please don't print this e-mail, unless you really need to. > > > > From chris.paul at rexconsulting.net Sun Aug 10 15:06:06 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 13:06:06 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> References: <489E15EC.2060801@credibleinstitution.org> <489E1ECB.9060700@rexconsulting.net> <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> Message-ID: <489F4A2E.1040803@rexconsulting.net> brett watson wrote: >> Hey authority DNS server operators. Can you make a change to your >> servers to always allow TCP client connections? Would this be >> difficult? What would be the harm? > > SYN flooding? > from your clients? We ways of knowing people on our local network are doing this type of thing and turn them off at the switch today. Why are you are doing dns recursion for people outside your network? CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From chris.paul at rexconsulting.net Sun Aug 10 15:14:46 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 13:14:46 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <70D072392E56884193E3D2DE09C097A9F440@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A9F440@pascal.zaphodb.org> Message-ID: <489F4C36.4020606@rexconsulting.net> Tomas L. Byrnes wrote: > > > -----Original Message----- > From: Tomas L. Byrnes > Sent: Saturday, August 09, 2008 9:01 PM > To: 'Chris Paul' > Subject: RE: maybe a dumb idea on how to fix the dns problems i don't > know.... > > Actually, the RFCs (RFC-1034 3.7RFC-1035 4.2, ref RFC-793; > Implementation spec in RFC-1035 4.2.2; RFC-2136 2.1 says TCP is "at the > discretion of the requestor";) say TCP "Should" be supported. It's > optional, but recommended. > > The source of the guidance to block TCP is misguided "security" folks > who confuse self-denial of service with policy enforcement. > Thanks Tomas for doing the research I wasn't about to do on a a weekend.... Dear North American Network Operators, See it isn't a dumb idea after all? Y'all get coding, patching and firewall rule-set changing now! Let's please stop using UDP for DNS resolution. THAT was the dumb idea really... (I know; you old folks that created this wonderful thing didn't think of that back then.... blah blah blah). And SYN flooding? That happens to port 80 and port 25 too right? Most web and mail servers listen to the WORLD, whereas most DNS servers doing recursion do so only for the local network where SYN flooding is less of a risk The experts don't seem to be able to post any rebuttals to my idea in decent enough English to answer why we should not do this. Perhaps I'm just too dumb to understand all you zen masters out there with your desire to use bad grammar, lack of punctuation and capitalization and the most complicated language to obfuscate solutions.... Oh and, ha ha, even though I'm just the ldap dude, I'll take all the fame and money (paypal or send to address below) for coming up with the simple solution to this dns problem. If you really want, my Mom will send some cookies to the next blackhat. (My Grandma taught her how very well but she is dead.) There's really nothing more complicated about this problem than baking cookies, I don't think, but you have to go through many generations iteration and experiment ion to get it right. And sometimes the answers are simple once they are found (hey look what I found out: see what this bicarbonate of soda does!). Oh hey yesterday was Saturday! Duh! Bonus for me!!! . Why on earth did I check my email? I usually don't on weekends at all. I'm sorry...... This change would not even be hard to implement globally, would it? Just SIMPLE code changes, patches, and firewall changes. (OK maybe the last part is not so easy but that to me is just lack of competence out there.) Best, CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From rnspayne at the-paynes.com Sun Aug 10 16:05:04 2008 From: rnspayne at the-paynes.com (Rob Payne) Date: Sun, 10 Aug 2008 17:05:04 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F4A2E.1040803@rexconsulting.net> References: <489E15EC.2060801@credibleinstitution.org> <489E1ECB.9060700@rexconsulting.net> <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> <489F4A2E.1040803@rexconsulting.net> Message-ID: <20080810210504.GA2302@osprey.the-paynes.com> On Sun, Aug 10, 2008 at 01:06:06PM -0700, Chris Paul wrote: > brett watson wrote: > >>Hey authority DNS server operators. Can you make a change to your > >>servers to always allow TCP client connections? Would this be > >>difficult? What would be the harm? > >SYN flooding? > from your clients? We ways of knowing people on our local network are > doing this type of thing and turn them off at the switch today. Why are > you are doing dns recursion for people outside your network? The question isn't whether to offer TCP/53 up at the recursive server. The issue is that for you to use TCP/53 from your recursive server, it has to be offered up at the authoritative end. The authoritative server operators have to offer TCP/53 and the firewall administrators between the recursive server and the authoritative servers have to allow the traffic. -rob From chris.paul at rexconsulting.net Sun Aug 10 16:52:58 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 14:52:58 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <20080810204734.GA15872@pwns.ms> References: <70D072392E56884193E3D2DE09C097A9F440@pascal.zaphodb.org> <489F4C36.4020606@rexconsulting.net> <20080810204734.GA15872@pwns.ms> Message-ID: <489F633A.2060804@rexconsulting.net> list-nanog at pwns.ms wrote: >> (I know; you old folks that created this wonderful thing didn't think of >> that back then.... blah blah blah). >> > > If they had thought of it back then, they would have allowed for a larger TXID, not used TCP. TCP connection setup time is slow; TCP DNS is much slower than UDP DNS. Good point. But we only care about TCP connection setup time in *interactive* sessions (a human using something like the web). If you have a persistent connection to your dns server from your dns resolver on your browser machine, you just send the request.... no TCP setup there at all. You can even pool connections. We do this stuff in LDAP all the time. How does TCP resolution work in most resolver libraries? A TCP connection for each lookup? That is kind of dumb isn't it, speaking of dumb.... I actually don't know. Not much of a coder, so I'll let you coders check your code and get back to me on that... well.. maybe i'll fire up snort or wireshark and check it out later with some different dns libs.... CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From list-nanog at pwns.ms Sun Aug 10 17:01:13 2008 From: list-nanog at pwns.ms (list-nanog at pwns.ms) Date: Sun, 10 Aug 2008 22:01:13 +0000 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F633A.2060804@rexconsulting.net> References: <70D072392E56884193E3D2DE09C097A9F440@pascal.zaphodb.org> <489F4C36.4020606@rexconsulting.net> <20080810204734.GA15872@pwns.ms> <489F633A.2060804@rexconsulting.net> Message-ID: <20080810220113.GA19479@pwns.ms> > But we only care about TCP connection setup time in *interactive* > sessions (a human using something like the web). If you have a > persistent connection to your dns server from your dns resolver on your > browser machine, you just send the request.... no TCP setup there at > all. You can even pool connections. We do this stuff in LDAP all the time. Again, if we can change the DNS protocol, then it's easy to solve. Securing host->recursive name server is, at the moment, not an issue - each host is a small target, and often has little bandwidth available. Furthermore, stopping IP spoofing of one's own hosts within one's networks is, well, not trivial, but not hugely difficult either. From chris.paul at rexconsulting.net Sun Aug 10 17:10:16 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 15:10:16 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <20080810210504.GA2302@osprey.the-paynes.com> References: <489E15EC.2060801@credibleinstitution.org> <489E1ECB.9060700@rexconsulting.net> <2CD297B5-AA9E-47D4-992D-D17CEEFA50D2@the-watsons.org> <489F4A2E.1040803@rexconsulting.net> <20080810210504.GA2302@osprey.the-paynes.com> Message-ID: <489F6748.7040409@rexconsulting.net> > The question isn't whether to offer TCP/53 up at the recursive > server. The issue is that for you to use TCP/53 from your recursive > server, it has to be offered up at the authoritative end. > > The authoritative server operators have to offer TCP/53 and the > firewall administrators between the recursive server and the > authoritative servers have to allow the traffic. > > -rob > Yes. This is true. But with a caching resolver being used for most interactive clients (web surfers), this doesn't cause any problem, other than the initial caching. OK I guess the question is this: How many milliseconds now on average does it take for my local dns server to obtain an address which is uncached using recursion up to the authoritative end using UDP And I guess the second question is: How many milliseconds on average would it take for my local dns server to obtain an address which is uncached using recursion up to the authoritative end using TCP. Once it is cached on my local caching server, its a non-issue if I am using some sort of persistent connection to my (non-authoritative) dns caching server. CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From jgreco at ns.sol.net Sun Aug 10 17:13:54 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Aug 2008 17:13:54 -0500 (CDT) Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F633A.2060804@rexconsulting.net> from "Chris Paul" at Aug 10, 2008 02:52:58 PM Message-ID: <200808102213.m7AMDsmH019592@aurora.sol.net> > But we only care about TCP connection setup time in *interactive* > sessions (a human using something like the web). If you have a > persistent connection to your dns server from your dns resolver on your > browser machine, you just send the request.... no TCP setup there at > all. You can even pool connections. We do this stuff in LDAP all the time. > > How does TCP resolution work in most resolver libraries? A TCP > connection for each lookup? That is kind of dumb isn't it, speaking of > dumb.... I actually don't know. Not much of a coder, so I'll let you > coders check your code and get back to me on that... > > well.. maybe i'll fire up snort or wireshark and check it out later with > some different dns libs.... Pretending for a moment that it was even possible to make such large scale changes and get them pushed into a large enough number of clients to matter, you're talking about meltdown at the recurser level, because it isn't just one connection per _computer_, but one connection per _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to gravitate towards one connection per process), and this just turns into an insane number of sockets you have to manage. For your average ISP recurser where they only have 50,000 people online at any given time, this could still be half a million open sockets. We already know this sort of thing doesn't scale well. This is very broken in any number of other ways. This message is not intended to imply otherwise. ... 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 chris.paul at rexconsulting.net Sun Aug 10 17:36:26 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 15:36:26 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <20080810220113.GA19479@pwns.ms> References: <70D072392E56884193E3D2DE09C097A9F440@pascal.zaphodb.org> <489F4C36.4020606@rexconsulting.net> <20080810204734.GA15872@pwns.ms> <489F633A.2060804@rexconsulting.net> <20080810220113.GA19479@pwns.ms> Message-ID: <489F6D6A.6040004@rexconsulting.net> list-nanog at pwns.ms wrote: >> But we only care about TCP connection setup time in *interactive* >> sessions (a human using something like the web). If you have a >> persistent connection to your dns server from your dns resolver on your >> browser machine, you just send the request.... no TCP setup there at >> all. You can even pool connections. We do this stuff in LDAP all the time. >> > > Again, if we can change the DNS protocol, then it's easy to solve. Wait a min... This isn't changing the DNS protocol to have or allow persistent dns/tcp connections is it? or is it? Yikes, yes the DNS protocol should be changed then, right now, to allow persistent connections, at least from the interactive client (websurfing machine) resolver to caching name server. CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From chris.paul at rexconsulting.net Sun Aug 10 19:21:46 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 17:21:46 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <200808102213.m7AMDsmH019592@aurora.sol.net> References: <200808102213.m7AMDsmH019592@aurora.sol.net> Message-ID: <489F861A.1020901@rexconsulting.net> Joe Greco wrote: >> But we only care about TCP connection setup time in *interactive* >> sessions (a human using something like the web). If you have a >> persistent connection to your dns server from your dns resolver on your >> browser machine, you just send the request.... no TCP setup there at >> all. You can even pool connections. We do this stuff in LDAP all the time. >> >> How does TCP resolution work in most resolver libraries? A TCP >> connection for each lookup? That is kind of dumb isn't it, speaking of >> dumb.... I actually don't know. Not much of a coder, so I'll let you >> coders check your code and get back to me on that... >> >> well.. maybe i'll fire up snort or wireshark and check it out later with >> some different dns libs.... >> > > Pretending for a moment that it was even possible to make such large > scale changes and get them pushed into a large enough number of clients > to matter, you're talking about meltdown at the recurser level, because > it isn't just one connection per _computer_, but one connection per > _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to > gravitate towards one connection per process), and this just turns into > an insane number of sockets you have to manage. > Couldn't the resolver libraries be changed to not use multiple connections? CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul at rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From victor at gsys.se Sun Aug 10 19:26:04 2008 From: victor at gsys.se (Victor Jerlin) Date: Mon, 11 Aug 2008 02:26:04 +0200 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F861A.1020901@rexconsulting.net> References: <200808102213.m7AMDsmH019592@aurora.sol.net> <489F861A.1020901@rexconsulting.net> Message-ID: <489F871C.1040404@gsys.se> Inline.. Chris Paul wrote: > > > Joe Greco wrote: >>> But we only care about TCP connection setup time in *interactive* >>> sessions (a human using something like the web). If you have a >>> persistent connection to your dns server from your dns resolver on >>> your browser machine, you just send the request.... no TCP setup >>> there at all. You can even pool connections. We do this stuff in LDAP >>> all the time. >>> >>> How does TCP resolution work in most resolver libraries? A TCP >>> connection for each lookup? That is kind of dumb isn't it, speaking >>> of dumb.... I actually don't know. Not much of a coder, so I'll let >>> you coders check your code and get back to me on that... >>> >>> well.. maybe i'll fire up snort or wireshark and check it out later >>> with some different dns libs.... >>> >> >> Pretending for a moment that it was even possible to make such large >> scale changes and get them pushed into a large enough number of >> clients to matter, you're talking about meltdown at the recurser >> level, because >> it isn't just one connection per _computer_, but one connection per >> _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to >> gravitate towards one connection per process), and this just turns >> into an insane number of sockets you have to manage. >> > Couldn't the resolver libraries be changed to not use multiple connections? And we'll change to IPv6 tomorrow! > > CP > -- Victor Jerlin, CTO Gr?nsl?sa System GSYS HB Cell#: +356-9999-0125 From jgreco at ns.sol.net Sun Aug 10 20:16:06 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Aug 2008 20:16:06 -0500 (CDT) Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F861A.1020901@rexconsulting.net> from "Chris Paul" at Aug 10, 2008 05:21:46 PM Message-ID: <200808110116.m7B1G6Ed025365@aurora.sol.net> > > Pretending for a moment that it was even possible to make such large > > scale changes and get them pushed into a large enough number of clients > > to matter, you're talking about meltdown at the recurser level, because > > it isn't just one connection per _computer_, but one connection per > > _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to > > gravitate towards one connection per process), and this just turns into > > an insane number of sockets you have to manage. > > Couldn't the resolver libraries be changed to not use multiple connections? I think that the text I wrote clearly assumes that there IS only one connection per resolver instance. The problem is that hostname to IP lookup is pervasive in a modern UNIX system, and is probably pretty common on other platforms, too, so you have potentially hundreds or thousands of processes, each eating up additional system file descriptors for this purpose. I cannot think of any reason that init, getty, sh, cron, or a few other things on a busy system would need to use the resolver library - but that leaves a whole ton of things that can and do. Now, of course, you can /change/ how everything works. Stop holding open connections persistently, and a lot of the trouble is reduced. However, anyone who has done *any* work in the area of TCP services that are open to the public will be happy to stamp "Fraught With Peril" on this little project - and to understand why, I suggest you research all the work that has been put into defending services like http, irc, etc. ... 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 chris.paul at rexconsulting.net Sun Aug 10 20:27:29 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 18:27:29 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <200808110116.m7B1G6Ed025365@aurora.sol.net> References: <200808110116.m7B1G6Ed025365@aurora.sol.net> Message-ID: <489F9581.4010801@rexconsulting.net> Joe Greco wrote: >>> Pretending for a moment that it was even possible to make such large >>> scale changes and get them pushed into a large enough number of clients >>> to matter, you're talking about meltdown at the recurser level, because >>> it isn't just one connection per _computer_, but one connection per >>> _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to >>> gravitate towards one connection per process), and this just turns into >>> an insane number of sockets you have to manage. >>> >> >> Couldn't the resolver libraries be changed to not use multiple connections? >> > > I think that the text I wrote clearly assumes that there IS only one > connection per resolver instance. The problem is that hostname to IP > lookup is pervasive in a modern UNIX system, and is probably pretty > common on other platforms, too, so you have potentially hundreds or > thousands of processes, each eating up additional system file descriptors > for this purpose. Well how I read what you first wrote implied that the resolvers are now going to DOS servers with millions of connections due to each resolver stub making a TCP connection... I say this is something that if true, can and should be changed. Now you say that file descriptors on the client are going to run out Isn't that changing the topic? And is that even really a problem? So each process that needs to do a lookup opens a file descriptor for a TCP connection, right? Whereas with UDP we don't have to do this. Is this what I'm hearing you say? That I understand. (Hmm don't udp connections take sockets too? Not sarcastic here.. just asking...) And it is a good point but is this client file descriptor an insurmountable problem? Also, what about the millions of connections to the server? Is that really necessary for a dns resolver on one system to open more than one TCP connection to its caching dns server? I'm not saying that caching dns servers should keep open TCP connections to authoritative name servers! OK? But how much latency do you increase e on that uncached recursive lookup by changing to TCP? CP -- Chris Paul Rex Consulting, Inc email: chris.paul at rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From chris.paul at rexconsulting.net Sun Aug 10 20:29:00 2008 From: chris.paul at rexconsulting.net (Chris Paul) Date: Sun, 10 Aug 2008 18:29:00 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F871C.1040404@gsys.se> References: <200808102213.m7AMDsmH019592@aurora.sol.net> <489F861A.1020901@rexconsulting.net> <489F871C.1040404@gsys.se> Message-ID: <489F95DC.4010403@rexconsulting.net> Victor Jerlin wrote: >>> >> Couldn't the resolver libraries be changed to not use multiple >> connections? > > And we'll change to IPv6 tomorrow! Total apples and oranges. We all have to patch anyhow. This is just code and firewall rules. IPv6 is way more complicated, friend. -- Chris Paul Rex Consulting, Inc email: chris.paul at rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to. From cat at reptiles.org Sun Aug 10 20:34:26 2008 From: cat at reptiles.org (Cat Okita) Date: Sun, 10 Aug 2008 21:34:26 -0400 (EDT) Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F95DC.4010403@rexconsulting.net> References: <200808102213.m7AMDsmH019592@aurora.sol.net> <489F861A.1020901@rexconsulting.net> <489F871C.1040404@gsys.se> <489F95DC.4010403@rexconsulting.net> Message-ID: <20080810213344.D15677@gecko.reptiles.org> On Sun, 10 Aug 2008, Chris Paul wrote: >> And we'll change to IPv6 tomorrow! > Total apples and oranges. We all have to patch anyhow. This is just code and > firewall rules. IPv6 is way more complicated, friend. No - IPv6 is just code (and not even firewall rules). cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." From jgreco at ns.sol.net Sun Aug 10 21:35:58 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Aug 2008 21:35:58 -0500 (CDT) Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489F9581.4010801@rexconsulting.net> from "Chris Paul" at Aug 10, 2008 06:27:29 PM Message-ID: <200808110235.m7B2Zwxn028353@aurora.sol.net> > > I think that the text I wrote clearly assumes that there IS only one > > connection per resolver instance. The problem is that hostname to IP > > lookup is pervasive in a modern UNIX system, and is probably pretty > > common on other platforms, too, so you have potentially hundreds or > > thousands of processes, each eating up additional system file descriptors > > for this purpose. > > Well how I read what you first wrote implied that the resolvers are now > going to DOS servers with millions of connections due to each resolver > stub making a TCP connection... I say this is something that if true, > can and should be changed. Sure. We can introduce a new feature, called a "local recurser," which will do unified name resolution for all lookups asked for by any process on the box. Now, of course, the box enjoys certain benefits, such as being able to remember who "MX nanog.org" is for the second time without having to bother an external recurser. And a hypothetical ability to forward all requests via TCP to the external recurser. Except, why bother, now that you have the capability right on the box, why be dependent on anything else? Might as well just let it resolve all by itself. Of course, the box also enjoys certain other liabilities, such as the next time that all the name servers in the world need to be upgraded, you now have just that many more recursers that are running on unattended autopilot (because heaven knows, most PC's run without a professional admin to keep things up to snuff, and this last problem wasn't exactly the sort of thing you can just "auto update," because someone actually has to verify that there aren't externalities such as NAT devices, etc!) Sounds like a real fun time. > Now you say that file descriptors on the client are going to run out > Isn't that changing the topic? And is that even really a problem? Actually, it's quite a problem, for the server. Try, sometime, having a few thousand file descriptors all open, and then running select() on that fdset. But it's not even really that pleasant on many clients. It's a kernel consumable. You try to avoid introducing additional requirements without a good reason. > So each process that needs to do a lookup opens a file descriptor for a > TCP connection, right? Whereas with UDP we don't have to do this. Is > this what I'm hearing you say? That I understand. (Hmm don't udp > connections take sockets too? Not sarcastic here.. just asking...) You open and then close it for UDP. You can do that for TCP, too, at a substantial penalty. > And it is a good point but is this client file descriptor an > insurmountable problem? Also, what about the millions of connections to > the server? Is that really necessary for a dns resolver on one system to > open more than one TCP connection to its caching dns server? There is no "DNS resolver on one system" unless you put one there. At which point, you can safely ask the question of why would you then connect to a caching server (there are good reasons, in some cases). The way libresolv works is that it takes those "nameserver" things listed in resolv.conf and sends requests to them. Since any program that uses the network is likely to be linked to libresolv, you can have lots of different programs on a system, each of which may want to resolve different name resources. There is no monolithic "thing" on a box to do name resolution unless you put one there. > I'm not saying that caching dns servers should keep open TCP connections > to authoritative name servers! OK? But how much latency do you increase > e on that uncached recursive lookup by changing to TCP? Since latency would not be extremely high on my list of concerns with this plan, I'll pass and say "I don't really care to speculate." There are many other ways you'll have lit your hair on fire before latency is a big concern. ... 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 jlewis at lewis.org Sun Aug 10 22:15:47 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 10 Aug 2008 23:15:47 -0400 (EDT) Subject: impossible circuit Message-ID: After all the messages recently about how to fix DNS, I was seriously tempted to title this messsage "And now, for something completely different", but impossible circuit is more descriptive. Before you read further, I need everyone to put on their thinking WAY outside the box hats. I've heard from enough people already that I'm nuts and what I'm seeing can't happen, so it must not be happening...even though we see the results of it happening. I've got this private line DS3. It connects cisco 7206 routers in Orlando (at our data center) and in Ocala (a colo rack in the Embarq CO). According to the DLR, it's a real circuit, various portions of it ride varying sized OC circuits, and then it's handed off to us at each end the usual way (copper/coax) and plugged into PA-2T3 cards. Last Tuesday, at about 2:30PM, "something bad happened." We saw a serious jump in traffic to Ocala, and in particular we noticed one customer's connection (a group of load sharing T1s) was just totally full. We quickly assumed it was a DDoS aimed at that customer, but looking at the traffic, we couldn't pinpoint anything that wasn't expected flows. Then we noticed the really weird stuff. Pings to anything in Ocala responded with multiple dupes and ttl exceeded messages from a Level3 IP. Traceroutes to certain IPs in Ocala would get as far our Ocala router, then inexplicably hop onto Sprintlink's network, come back to us over our Level3 transit connection, get to Ocala, then hop over to Sprintlink again, repeating that loop as many times as max TTL would permit. Pings from router to router crossing just the DS3 would work, but we'd see 10 duplicate packets for every 1 expected packet. BTW, the cisco CLI hides dupes unless you turn on ip icmp debugging. I've seen some sort of similar things (though contained within an AS) with MPLS and routing misconfigurations, but traffic jumping off our network (to a network to which we're not directly connected) was seemingly impossible. We did all sorts of things to troubleshoot it (studied our router configs in rancid, temporarily shut every interface on the Ocala side other than the DS3, changed IOS versions, changed out the hardware, opened a ticket with cisco TAC) but then it occurred to me, that if traffic was actually jumping off our network and coming back in via Level3, I could see/block at least some of that using an ACL on our interface to Level3. How do you explain it, when you ping the remote end of a DS3 interface with a single echo request packet and see 5 copies of that echo request arrive at one of your transit provider interfaces? Here's a typical traceroute with the first few hops (from my home internet connection) removed. BTW, hop 9 is a customer router conveniently configured with no ip unreachables. 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms 56.154 ms 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 ms 56.196 ms 9 * * * 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 ms 81.821 ms 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 75.731 ms 75.902 ms 77.128 ms 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 46.548 ms 53.200 ms 45.736 ms 13 vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.918 ms vlan79.csw2.Washington1.Level3.net (4.68.17.126) 55.438 ms vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.693 ms 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 48.935 ms ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 49.317 ms ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 48.865 ms 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 59.642 ms 56.278 ms 56.671 ms 16 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 47.401 ms 62.980 ms 62.640 ms 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 40.300 ms 40.101 ms 42.690 ms 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 40.959 ms 40.963 ms 41.016 ms 19 unknown.Level3.net (63.209.98.66) 246.744 ms 240.826 ms 239.758 ms 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 39.725 ms 37.751 ms 42.262 ms 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 43.524 ms 45.844 ms 43.392 ms 22 * * * 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 63.752 ms 61.648 ms 60.839 ms 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 66.923 ms 65.258 ms 70.609 ms 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 67.106 ms 93.415 ms 73.932 ms 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 88.919 ms 75.306 ms vlan79.csw2.Washington1.Level3.net (4.68.17.126) 75.048 ms 27 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 69.508 ms 68.401 ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 79.128 ms 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 64.048 ms 67.764 ms 67.704 ms 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 68.372 ms 67.025 ms 68.162 ms 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 65.112 ms 65.584 ms 65.525 ms Our circuit provider's support people have basically just maintained that this behavior isn't possible and so there's nothing they can do about it. i.e. that the problem has to be something other than the circuit. I got tired of talking to their brick wall, so I contacted Sprint and was able to confirm with them that the traffic in question really was inexplicably appearing on their network...and not terribly close geographically to the Orlando/Ocala areas. So, I have a circuit that's bleeding duplicate packets onto an unrelated IP network, a circuit provider who's got their head in the sand and keeps telling me "this can't happen, we can't help you", and customers who were getting tired of receiving all their packets in triplicate (or more) saturating their connections and confusing their applications. After a while, I had to give up on finding the problem and focus on just making it stop. After trying a couple of things, the solution I found was to change the encapsulation we use at each end of the DS3. I haven't gotten confirmation of this from Sprint, but I assume they're now seeing massive input errors one the one or more circuits where our packets were/are appearing. The important thing (for me) is that this makes the packets invalid to Sprint's routers and so it keeps them from forwarding the packets to us. Cisco TAC finally got back to us the day after I "fixed" the circuit...but since it was obviously not a problem with our cisco gear, I haven't pursued it with them. The only things I can think of that might be the cause are misconfiguration in a DACS/mux somewhere along the circuit path or perhaps a mishandled lawful intercept. I don't have enough experience with either or enough access to the systems that provide the circuit to do any more than speculate. Has anyone else ever seen anything like this? If someone from Level3 transport can wrap their head around this, I'd love to know what's really going on...but at least it's no longer an urgent problem for me. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From herrin-nanog at dirtside.com Sun Aug 10 22:21:01 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Sun, 10 Aug 2008 23:21:01 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <489E0994.9000100@rexconsulting.net> References: <489E0994.9000100@rexconsulting.net> Message-ID: <3c3e3fca0808102021q5f64733em4cde0b8e00ffb697@mail.gmail.com> On Sat, Aug 9, 2008 at 5:18 PM, Chris Paul wrote: > Sorry if this is real stupid for some reason because I don't think about DNS > all day (I'm the ldap dude) but since we have faster networks and faster > cpus today, what would be the harm in switching to use TCP for DNS clients? > The latency on the web isn't dns anymore ever it seems to me..... Latency on in-addr lookups where you typically traverse multiple forward trees to find the NS servers would seriously suck. At best, a TCP-based lookup performs at about a third of the speed of a UDP lookup. Worse unless your implementation is carefully optimized and you make sure that the OS isn't adding options to the front of the handshake. You have at least the whole syn/synack/ack handshake before you can even ask the question. Then there's the server cost associated with keeping that much state... On Sat, Aug 9, 2008 at 6:10 PM, Matt F wrote: > Why not just require TCP for a lookup if a response with an incorrect TXID > is received? You could require TCP for just the one lookup or for some > configured interval, say 1 hour. That should slow attackers down > substantially. Because the attacker is using a sequence of lookups in order to hit one that lets him poison the cache. That is, he looks up a.google.com, then he looks up b.google.com, then c.google.com, etc. until he gets one where the server accepts his fake DNS server record for google.com. To be an effective defense, you'd have to do TCP lookups for the whole scope ({anything}.google.com) for some period of time following the bad ID. That in turn would open up a potential DOS where an attacker could force the DNS server to fall back on TCP for essentially everything, overwhelming it. On Sat, Aug 9, 2008 at 8:25 PM, brett watson wrote: > On Aug 9, 2008, at 3:48 PM, Chris Paul wrote: >> Hey authority DNS server operators. Can you make a change to your servers >> to always allow TCP client connections? Would this be difficult? What would >> be the harm? > > SYN flooding? SYN flooding is a solved problem. On Sat, Aug 9, 2008 at 6:04 PM, Joe Abley wrote: > TCP works pretty well with anycast too, if you're careful. It's helpful if > your transactions are short-lived. Define "careful." It's always possible for someone to find themselves with an equal cost path to two different servers in the anycast set. Add per-packet load balancing at the fork (which is outside the control of the server operator) and what happens is the request times out and the resovler fails over to the other NS record that isn't anycasted. Though the protocol is simple enough that it might be possible to fake it. Build yourself a DNS-only stateless TCP stack for the anycasted address. Have the server send the syn-ack without creating any state. The request will almost certainly be entirely contained in one packet, so when it arrives reply to it without creating any state. Ship off as many packets as you need to reply followed by a Fin. Blindly ack any packet that looks like it needs it. If any packets are lost, there won't be any retransmit (you haven't really established a TCP connection) so the query will time out and retry. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matt.rice at comcast.net Sun Aug 10 23:06:28 2008 From: matt.rice at comcast.net (Matt Rice) Date: Sun, 10 Aug 2008 21:06:28 -0700 Subject: Impossible Circuit References: Message-ID: <1E44D0B2C1B645F9B79EDDD089E96C44@science> I am not sure about the loop, but wouldn't a static or default static route specifying an outbound interface rather than a next hop router ip address on a multi-access network like Ethernet, frame-relay or ATM with connections to 5 or more routers cause one router to output a stream of packets to a subnet and all five or more receiving routers receiving the packets possibly forwarding them separately causing the duplicate packets? Just a thought, Matt Rice Seattle ----- Original Message ----- From: To: Sent: Sunday, August 10, 2008 8:21 PM Subject: NANOG Digest, Vol 7, Issue 26 > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Chris Paul) > 2. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Chris Paul) > 3. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Cat Okita) > 4. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Joe Greco) > 5. impossible circuit (Jon Lewis) > 6. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (William Herrin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Aug 2008 18:27:29 -0700 > From: Chris Paul > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: nanog at nanog.org > Message-ID: <489F9581.4010801 at rexconsulting.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Joe Greco wrote: >>>> Pretending for a moment that it was even possible to make such large >>>> scale changes and get them pushed into a large enough number of clients >>>> to matter, you're talking about meltdown at the recurser level, because >>>> it isn't just one connection per _computer_, but one connection per >>>> _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to >>>> gravitate towards one connection per process), and this just turns into >>>> an insane number of sockets you have to manage. >>>> >>> >>> Couldn't the resolver libraries be changed to not use multiple >>> connections? >>> >> >> I think that the text I wrote clearly assumes that there IS only one >> connection per resolver instance. The problem is that hostname to IP >> lookup is pervasive in a modern UNIX system, and is probably pretty >> common on other platforms, too, so you have potentially hundreds or >> thousands of processes, each eating up additional system file descriptors >> for this purpose. > > Well how I read what you first wrote implied that the resolvers are now > going to DOS servers with millions of connections due to each resolver > stub making a TCP connection... I say this is something that if true, > can and should be changed. > > Now you say that file descriptors on the client are going to run out > Isn't that changing the topic? And is that even really a problem? > > So each process that needs to do a lookup opens a file descriptor for a > TCP connection, right? Whereas with UDP we don't have to do this. Is > this what I'm hearing you say? That I understand. (Hmm don't udp > connections take sockets too? Not sarcastic here.. just asking...) > > And it is a good point but is this client file descriptor an > insurmountable problem? Also, what about the millions of connections to > the server? Is that really necessary for a dns resolver on one system to > open more than one TCP connection to its caching dns server? > > I'm not saying that caching dns servers should keep open TCP connections > to authoritative name servers! OK? But how much latency do you increase > e on that uncached recursive lookup by changing to TCP? > > CP > > -- > Chris Paul > Rex Consulting, Inc > email: chris.paul at rexconsulting.net > phone, direct: +1, 831.706.4211 > phone, toll-free: +1, 888.403.8996 > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, > or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. > Rex Consulting, Inc. is a California Corporation. > > P Please don't print this e-mail, unless you really need to. > > > > > > ------------------------------ > > Message: 2 > Date: Sun, 10 Aug 2008 18:29:00 -0700 > From: Chris Paul > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: nanog at merit.edu > Message-ID: <489F95DC.4010403 at rexconsulting.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Victor Jerlin wrote: >>>> >>> Couldn't the resolver libraries be changed to not use multiple >>> connections? >> >> And we'll change to IPv6 tomorrow! > Total apples and oranges. We all have to patch anyhow. This is just code > and firewall rules. IPv6 is way more complicated, friend. > > > -- > Chris Paul > Rex Consulting, Inc > email: chris.paul at rexconsulting.net > phone, direct: +1, 831.706.4211 > phone, toll-free: +1, 888.403.8996 > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, > or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. > Rex Consulting, Inc. is a California Corporation. > > P Please don't print this e-mail, unless you really need to. > > > > > > ------------------------------ > > Message: 3 > Date: Sun, 10 Aug 2008 21:34:26 -0400 (EDT) > From: Cat Okita > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: Chris Paul > Cc: nanog at merit.edu > Message-ID: <20080810213344.D15677 at gecko.reptiles.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sun, 10 Aug 2008, Chris Paul wrote: >>> And we'll change to IPv6 tomorrow! >> Total apples and oranges. We all have to patch anyhow. This is just code >> and >> firewall rules. IPv6 is way more complicated, friend. > > No - IPv6 is just code (and not even firewall rules). > > cheers! > ========================================================================== > "A cat spends her life conflicted between a deep, passionate and profound > desire for fish and an equally deep, passionate and profound desire to > avoid getting wet. This is the defining metaphor of my life right now." > > > > ------------------------------ > > Message: 4 > Date: Sun, 10 Aug 2008 21:35:58 -0500 (CDT) > From: Joe Greco > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: chris.paul at rexconsulting.net (Chris Paul) > Cc: nanog at nanog.org > Message-ID: <200808110235.m7B2Zwxn028353 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > >> > I think that the text I wrote clearly assumes that there IS only one >> > connection per resolver instance. The problem is that hostname to IP >> > lookup is pervasive in a modern UNIX system, and is probably pretty >> > common on other platforms, too, so you have potentially hundreds or >> > thousands of processes, each eating up additional system file >> > descriptors >> > for this purpose. >> >> Well how I read what you first wrote implied that the resolvers are now >> going to DOS servers with millions of connections due to each resolver >> stub making a TCP connection... I say this is something that if true, >> can and should be changed. > > Sure. We can introduce a new feature, called a "local recurser," which > will do unified name resolution for all lookups asked for by any process > on the box. > > Now, of course, the box enjoys certain benefits, such as being able to > remember who "MX nanog.org" is for the second time without having to > bother an external recurser. And a hypothetical ability to forward all > requests via TCP to the external recurser. Except, why bother, now that > you have the capability right on the box, why be dependent on anything > else? Might as well just let it resolve all by itself. > > Of course, the box also enjoys certain other liabilities, such as the > next time that all the name servers in the world need to be upgraded, > you now have just that many more recursers that are running on unattended > autopilot (because heaven knows, most PC's run without a professional > admin to keep things up to snuff, and this last problem wasn't exactly > the sort of thing you can just "auto update," because someone actually > has to verify that there aren't externalities such as NAT devices, etc!) > > Sounds like a real fun time. > >> Now you say that file descriptors on the client are going to run out >> Isn't that changing the topic? And is that even really a problem? > > Actually, it's quite a problem, for the server. Try, sometime, having a > few thousand file descriptors all open, and then running select() on that > fdset. But it's not even really that pleasant on many clients. It's a > kernel consumable. You try to avoid introducing additional requirements > without a good reason. > >> So each process that needs to do a lookup opens a file descriptor for a >> TCP connection, right? Whereas with UDP we don't have to do this. Is >> this what I'm hearing you say? That I understand. (Hmm don't udp >> connections take sockets too? Not sarcastic here.. just asking...) > > You open and then close it for UDP. You can do that for TCP, too, at a > substantial penalty. > >> And it is a good point but is this client file descriptor an >> insurmountable problem? Also, what about the millions of connections to >> the server? Is that really necessary for a dns resolver on one system to >> open more than one TCP connection to its caching dns server? > > There is no "DNS resolver on one system" unless you put one there. At > which point, you can safely ask the question of why would you then connect > to a caching server (there are good reasons, in some cases). > > The way libresolv works is that it takes those "nameserver" things listed > in resolv.conf and sends requests to them. Since any program that uses > the network is likely to be linked to libresolv, you can have lots of > different programs on a system, each of which may want to resolve > different name resources. There is no monolithic "thing" on a box to do > name resolution unless you put one there. > >> I'm not saying that caching dns servers should keep open TCP connections >> to authoritative name servers! OK? But how much latency do you increase >> e on that uncached recursive lookup by changing to TCP? > > Since latency would not be extremely high on my list of concerns with this > plan, I'll pass and say "I don't really care to speculate." There are > many > other ways you'll have lit your hair on fire before latency is a big > concern. > > ... 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. > > > > ------------------------------ > > Message: 5 > Date: Sun, 10 Aug 2008 23:15:47 -0400 (EDT) > From: Jon Lewis > Subject: impossible circuit > To: nanog at nanog.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > After all the messages recently about how to fix DNS, I was seriously > tempted to title this messsage "And now, for something completely > different", but impossible circuit is more descriptive. > > Before you read further, I need everyone to put on their thinking WAY > outside the box hats. I've heard from enough people already that I'm nuts > and what I'm seeing can't happen, so it must not be happening...even > though we see the results of it happening. > > I've got this private line DS3. It connects cisco 7206 routers in > Orlando (at our data center) and in Ocala (a colo rack in the Embarq CO). > > According to the DLR, it's a real circuit, various portions of it ride > varying sized OC circuits, and then it's handed off to us at each end the > usual way (copper/coax) and plugged into PA-2T3 cards. > > Last Tuesday, at about 2:30PM, "something bad happened." We saw a serious > jump in traffic to Ocala, and in particular we noticed one customer's > connection (a group of load sharing T1s) was just totally full. We > quickly assumed it was a DDoS aimed at that customer, but looking at the > traffic, we couldn't pinpoint anything that wasn't expected flows. > > Then we noticed the really weird stuff. Pings to anything in Ocala > responded with multiple dupes and ttl exceeded messages from a Level3 IP. > Traceroutes to certain IPs in Ocala would get as far our Ocala router, > then inexplicably hop onto Sprintlink's network, come back to us over our > Level3 transit connection, get to Ocala, then hop over to Sprintlink > again, repeating that loop as many times as max TTL would permit. Pings > from router to router crossing just the DS3 would work, but we'd see 10 > duplicate packets for every 1 expected packet. BTW, the cisco CLI hides > dupes unless you turn on ip icmp debugging. > > I've seen some sort of similar things (though contained within an AS) with > MPLS and routing misconfigurations, but traffic jumping off our network > (to a network to which we're not directly connected) was seemingly > impossible. We did all sorts of things to troubleshoot it (studied our > router configs in rancid, temporarily shut every interface on the Ocala > side other than the DS3, changed IOS versions, changed out the hardware, > opened a ticket with cisco TAC) but then it occurred to me, that if > traffic was actually jumping off our network and coming back in via > Level3, I could see/block at least some of that using an ACL on our > interface to Level3. How do you explain it, when you ping the remote end > of a DS3 interface with a single echo request packet and see 5 copies of > that echo request arrive at one of your transit provider interfaces? > > Here's a typical traceroute with the first few hops (from my home internet > connection) removed. BTW, hop 9 is a customer router conveniently > configured with no ip unreachables. > > 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms > 56.154 ms > 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 ms > 56.196 ms > 9 * * * > 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 ms > 81.821 ms > 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 75.731 ms 75.902 ms > 77.128 ms > 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 46.548 ms > 53.200 ms 45.736 ms > 13 vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.918 ms > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 55.438 ms > vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.693 ms > 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 48.935 ms > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 49.317 ms > ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 48.865 ms > 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 59.642 ms 56.278 ms > 56.671 ms > 16 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 47.401 ms 62.980 ms > 62.640 ms > 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 40.300 ms 40.101 ms > 42.690 ms > 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 40.959 ms 40.963 ms > 41.016 ms > 19 unknown.Level3.net (63.209.98.66) 246.744 ms 240.826 ms 239.758 ms > 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 39.725 ms 37.751 ms > 42.262 ms > 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 43.524 ms 45.844 ms > 43.392 ms > 22 * * * > 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 63.752 ms 61.648 ms > 60.839 ms > 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 66.923 ms 65.258 ms > 70.609 ms > 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 67.106 ms > 93.415 ms 73.932 ms > 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 88.919 ms 75.306 ms > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 75.048 ms > 27 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 69.508 ms 68.401 > ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 79.128 ms > 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 64.048 ms 67.764 ms > 67.704 ms > 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 68.372 ms 67.025 ms > 68.162 ms > 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 65.112 ms 65.584 ms > 65.525 ms > > Our circuit provider's support people have basically just maintained that > this behavior isn't possible and so there's nothing they can do about it. > i.e. that the problem has to be something other than the circuit. > > I got tired of talking to their brick wall, so I contacted Sprint and was > able to confirm with them that the traffic in question really was > inexplicably appearing on their network...and not terribly close > geographically to the Orlando/Ocala areas. > > So, I have a circuit that's bleeding duplicate packets onto an unrelated > IP network, a circuit provider who's got their head in the sand and keeps > telling me "this can't happen, we can't help you", and customers who were > getting tired of receiving all their packets in triplicate (or more) > saturating their connections and confusing their applications. After a > while, I had to give up on finding the problem and focus on just making it > stop. After trying a couple of things, the solution I found was to change > the encapsulation we use at each end of the DS3. I haven't gotten > confirmation of this from Sprint, but I assume they're now seeing massive > input errors one the one or more circuits where our packets were/are > appearing. The important thing (for me) is that this makes the packets > invalid to Sprint's routers and so it keeps them from forwarding the > packets to us. Cisco TAC finally got back to us the day after I "fixed" > the circuit...but since it was obviously not a problem with our cisco > gear, I haven't pursued it with them. > > The only things I can think of that might be the cause are > misconfiguration in a DACS/mux somewhere along the circuit path or perhaps > a mishandled lawful intercept. I don't have enough experience with either > or enough access to the systems that provide the circuit to do any more > than speculate. Has anyone else ever seen anything like this? > > If someone from Level3 transport can wrap their head around this, I'd love > to know what's really going on...but at least it's no longer an urgent > problem for me. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > ------------------------------ > > Message: 6 > Date: Sun, 10 Aug 2008 23:21:01 -0400 > From: "William Herrin" > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: nanog at merit.edu > Message-ID: > <3c3e3fca0808102021q5f64733em4cde0b8e00ffb697 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Aug 9, 2008 at 5:18 PM, Chris Paul > wrote: >> Sorry if this is real stupid for some reason because I don't think about >> DNS >> all day (I'm the ldap dude) but since we have faster networks and faster >> cpus today, what would be the harm in switching to use TCP for DNS >> clients? >> The latency on the web isn't dns anymore ever it seems to me..... > > Latency on in-addr lookups where you typically traverse multiple > forward trees to find the NS servers would seriously suck. At best, a > TCP-based lookup performs at about a third of the speed of a UDP > lookup. Worse unless your implementation is carefully optimized and > you make sure that the OS isn't adding options to the front of the > handshake. You have at least the whole syn/synack/ack handshake before > you can even ask the question. > > Then there's the server cost associated with keeping that much state... > > > On Sat, Aug 9, 2008 at 6:10 PM, Matt F > wrote: >> Why not just require TCP for a lookup if a response with an incorrect >> TXID >> is received? You could require TCP for just the one lookup or for some >> configured interval, say 1 hour. That should slow attackers down >> substantially. > > Because the attacker is using a sequence of lookups in order to hit > one that lets him poison the cache. That is, he looks up a.google.com, > then he looks up b.google.com, then c.google.com, etc. until he gets > one where the server accepts his fake DNS server record for > google.com. > > To be an effective defense, you'd have to do TCP lookups for the whole > scope ({anything}.google.com) for some period of time following the > bad ID. That in turn would open up a potential DOS where an attacker > could force the DNS server to fall back on TCP for essentially > everything, overwhelming it. > > > On Sat, Aug 9, 2008 at 8:25 PM, brett watson > wrote: >> On Aug 9, 2008, at 3:48 PM, Chris Paul wrote: >>> Hey authority DNS server operators. Can you make a change to your >>> servers >>> to always allow TCP client connections? Would this be difficult? What >>> would >>> be the harm? >> >> SYN flooding? > > SYN flooding is a solved problem. > > > On Sat, Aug 9, 2008 at 6:04 PM, Joe Abley wrote: >> TCP works pretty well with anycast too, if you're careful. It's helpful >> if >> your transactions are short-lived. > > Define "careful." It's always possible for someone to find themselves > with an equal cost path to two different servers in the anycast set. > Add per-packet load balancing at the fork (which is outside the > control of the server operator) and what happens is the request times > out and the resovler fails over to the other NS record that isn't > anycasted. > > Though the protocol is simple enough that it might be possible to fake > it. Build yourself a DNS-only stateless TCP stack for the anycasted > address. Have the server send the syn-ack without creating any state. > The request will almost certainly be entirely contained in one packet, > so when it arrives reply to it without creating any state. Ship off as > many packets as you need to reply followed by a Fin. Blindly ack any > packet that looks like it needs it. If any packets are lost, there > won't be any retransmit (you haven't really established a TCP > connection) so the query will time out and retry. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > > End of NANOG Digest, Vol 7, Issue 26 > ************************************ From mike at mtcc.com Sun Aug 10 23:40:20 2008 From: mike at mtcc.com (Michael Thomas) Date: Sun, 10 Aug 2008 21:40:20 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <200808110235.m7B2Zwxn028353@aurora.sol.net> References: <200808110235.m7B2Zwxn028353@aurora.sol.net> Message-ID: <489FC2B4.2060505@mtcc.com> Joe Greco wrote: > Actually, it's quite a problem, for the server. Try, sometime, having a > few thousand file descriptors all open, and then running select() on that > fdset. But it's not even really that pleasant on many clients. It's a > kernel consumable. You try to avoid introducing additional requirements > without a good reason. > > I thought that that was why poll(2) was your friend? Not that I'm saying that TCP is the right thing here, but things have evolved on the kernel interface front too, and I'd think that's even more so with (semi) purpose built OS's. It seems to me that DNS is an important enough service that we shouldn't require it least common denominator to creaky 30 year old API's any more than, oh say, routers should. Mike, it's the recursion argument that's really that seems to me to be what is most persuasive of why this is a lot different than http or ldap or most everything else From tomb at byrneit.net Mon Aug 11 00:01:14 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 10 Aug 2008 22:01:14 -0700 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <200808102213.m7AMDsmH019592@aurora.sol.net> References: <489F633A.2060804@rexconsulting.net> from "Chris Paul" at Aug 10, 2008 02:52:58 PM <200808102213.m7AMDsmH019592@aurora.sol.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F444@pascal.zaphodb.org> Unix machines set up by anyone with half a brain run a local caching server, and use forwarders. IE, the nameserver process can establish a persistent TCP connection to its trusted forwarders, if we just let it. That old sneer we used to use against Windows users of not having a "full featured host" and all. Windows stub resolvers multiplex through AD to a MS DNS server; which can easily use TCP to its trusted forwarders; unless they have no DC, which is not so common; in which case they just use standard queries, presumably to a patched ISP host (often a Nominum box). In both cases, the fix is in the local server, which serves only a few (and in a "full featured host" only one) machines using TCP to its forwarder, and the chain repeating itself. I don't see the problem with going to TCP for the recursive queries here. It's akin to the CDN scaling model, which has worked pretty well. > -----Original Message----- > From: Joe Greco [mailto:jgreco at ns.sol.net] > Sent: Sunday, August 10, 2008 3:14 PM > To: Chris Paul > Cc: nanog at merit.edu > Subject: Re: maybe a dumb idea on how to fix the dns problems > i don't know.... > > > But we only care about TCP connection setup time in *interactive* > > sessions (a human using something like the web). If you have a > > persistent connection to your dns server from your dns resolver on > > your browser machine, you just send the request.... no TCP setup > > there at all. You can even pool connections. We do this > stuff in LDAP all the time. > > > > How does TCP resolution work in most resolver libraries? A TCP > > connection for each lookup? That is kind of dumb isn't it, > speaking of > > dumb.... I actually don't know. Not much of a coder, so > I'll let you > > coders check your code and get back to me on that... > > > > well.. maybe i'll fire up snort or wireshark and check it out later > > with some different dns libs.... > > Pretending for a moment that it was even possible to make > such large scale changes and get them pushed into a large > enough number of clients to matter, you're talking about > meltdown at the recurser level, because it isn't just one > connection per _computer_, but one connection per _resolver > stub_ per _computer_ (which, on a UNIX machine, would tend to > gravitate towards one connection per process), and this just > turns into an insane number of sockets you have to manage. > > For your average ISP recurser where they only have 50,000 > people online at any given time, this could still be half a > million open sockets. We already know this sort of thing > doesn't scale well. > > This is very broken in any number of other ways. This > message is not intended to imply otherwise. > > ... 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 george at montco.net Mon Aug 11 00:24:39 2008 From: george at montco.net (George Carey) Date: Mon, 11 Aug 2008 01:24:39 -0400 Subject: impossible circuit In-Reply-To: References: Message-ID: <489FCD17.6000301@montco.net> A strange one indeed, especially if you have no connectivity to Sprint there. Since your fix was layer 2 you might be onto something. And you have the time it happened, and as we all know - somebody changed somethin' even if they won't fess up. I'm trying to think how you could cause something like that with a conventional DACS or one of the newer packet friendly types that might be more prone to a layer 2 bug since software is fairly new. Course it would make more sense if it was just crossed Ethernet rather than DS3 frames but who knows. There are plenty of carriers putting them in (including us). Shame it's not the kind of thing you can duplicate without being service affecting. George Jon Lewis wrote: > After all the messages recently about how to fix DNS, I was seriously > tempted to title this messsage "And now, for something completely > different", but impossible circuit is more descriptive. > > Before you read further, I need everyone to put on their thinking WAY > outside the box hats. I've heard from enough people already that I'm > nuts and what I'm seeing can't happen, so it must not be > happening...even though we see the results of it happening. > > I've got this private line DS3. It connects cisco 7206 routers in > Orlando (at our data center) and in Ocala (a colo rack in the Embarq CO). > > According to the DLR, it's a real circuit, various portions of it ride > varying sized OC circuits, and then it's handed off to us at each end > the usual way (copper/coax) and plugged into PA-2T3 cards. > > Last Tuesday, at about 2:30PM, "something bad happened." We saw a > serious jump in traffic to Ocala, and in particular we noticed one > customer's connection (a group of load sharing T1s) was just totally > full. We quickly assumed it was a DDoS aimed at that customer, but > looking at the traffic, we couldn't pinpoint anything that wasn't > expected flows. > > Then we noticed the really weird stuff. Pings to anything in Ocala > responded with multiple dupes and ttl exceeded messages from a Level3 > IP. Traceroutes to certain IPs in Ocala would get as far our Ocala > router, then inexplicably hop onto Sprintlink's network, come back to us > over our Level3 transit connection, get to Ocala, then hop over to > Sprintlink again, repeating that loop as many times as max TTL would > permit. Pings from router to router crossing just the DS3 would work, > but we'd see 10 duplicate packets for every 1 expected packet. BTW, the > cisco CLI hides dupes unless you turn on ip icmp debugging. > > I've seen some sort of similar things (though contained within an AS) > with MPLS and routing misconfigurations, but traffic jumping off our > network (to a network to which we're not directly connected) was > seemingly impossible. We did all sorts of things to troubleshoot it > (studied our router configs in rancid, temporarily shut every interface > on the Ocala side other than the DS3, changed IOS versions, changed out > the hardware, opened a ticket with cisco TAC) but then it occurred to > me, that if traffic was actually jumping off our network and coming back > in via Level3, I could see/block at least some of that using an ACL on > our interface to Level3. How do you explain it, when you ping the > remote end of a DS3 interface with a single echo request packet and see > 5 copies of that echo request arrive at one of your transit provider > interfaces? > > Here's a typical traceroute with the first few hops (from my home > internet connection) removed. BTW, hop 9 is a customer router > conveniently configured with no ip unreachables. > > 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms > 56.154 ms > 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 > ms 56.196 ms > 9 * * * > 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 > ms 81.821 ms > 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 75.731 ms 75.902 > ms 77.128 ms > 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 46.548 ms > 53.200 ms 45.736 ms > 13 vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.918 ms > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 55.438 ms > vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.693 ms > 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 48.935 ms > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 49.317 ms > ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 48.865 ms > 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 59.642 ms 56.278 ms > 56.671 ms > 16 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 47.401 ms 62.980 > ms 62.640 ms > 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 40.300 ms 40.101 > ms 42.690 ms > 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 40.959 ms 40.963 ms > 41.016 ms > 19 unknown.Level3.net (63.209.98.66) 246.744 ms 240.826 ms 239.758 ms > 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 39.725 ms 37.751 ms > 42.262 ms > 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 43.524 ms 45.844 > ms 43.392 ms > 22 * * * > 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 63.752 ms 61.648 > ms 60.839 ms > 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 66.923 ms 65.258 > ms 70.609 ms > 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 67.106 ms > 93.415 ms 73.932 ms > 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 88.919 ms 75.306 > ms vlan79.csw2.Washington1.Level3.net (4.68.17.126) 75.048 ms > 27 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 69.508 ms > 68.401 ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 79.128 ms > 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 64.048 ms 67.764 ms > 67.704 ms > 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 68.372 ms 67.025 > ms 68.162 ms > 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 65.112 ms 65.584 > ms 65.525 ms > > Our circuit provider's support people have basically just maintained > that this behavior isn't possible and so there's nothing they can do > about it. i.e. that the problem has to be something other than the circuit. > > I got tired of talking to their brick wall, so I contacted Sprint and > was able to confirm with them that the traffic in question really was > inexplicably appearing on their network...and not terribly close > geographically to the Orlando/Ocala areas. > > So, I have a circuit that's bleeding duplicate packets onto an unrelated > IP network, a circuit provider who's got their head in the sand and > keeps telling me "this can't happen, we can't help you", and customers > who were getting tired of receiving all their packets in triplicate (or > more) saturating their connections and confusing their applications. > After a while, I had to give up on finding the problem and focus on just > making it stop. After trying a couple of things, the solution I found > was to change the encapsulation we use at each end of the DS3. I > haven't gotten confirmation of this from Sprint, but I assume they're > now seeing massive input errors one the one or more circuits where our > packets were/are appearing. The important thing (for me) is that this > makes the packets invalid to Sprint's routers and so it keeps them from > forwarding the packets to us. Cisco TAC finally got back to us the day > after I "fixed" the circuit...but since it was obviously not a problem > with our cisco gear, I haven't pursued it with them. > > The only things I can think of that might be the cause are > misconfiguration in a DACS/mux somewhere along the circuit path or > perhaps a mishandled lawful intercept. I don't have enough experience > with either or enough access to the systems that provide the circuit to > do any more than speculate. Has anyone else ever seen anything like this? > > If someone from Level3 transport can wrap their head around this, I'd > love to know what's really going on...but at least it's no longer an > urgent problem for me. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From jgreco at ns.sol.net Mon Aug 11 07:10:26 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 11 Aug 2008 07:10:26 -0500 (CDT) Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <70D072392E56884193E3D2DE09C097A9F444@pascal.zaphodb.org> from "Tomas L. Byrnes" at Aug 10, 2008 10:01:14 PM Message-ID: <200808111210.m7BCAQSB087205@aurora.sol.net> > Unix machines set up by anyone with half a brain run a local caching > server, and use forwarders. IE, the nameserver process can establish a > persistent TCP connection to its trusted forwarders, if we just let it. Organizations often choose not to do this because doing so involves more risk and more things to update when the next vulnerability appears. In many cases, you are suggesting additional complexity and management requirements. A hosting company, for example, might have 20 racks of machines with 40 machines each, which is 800 servers. If half of those are UNIX, then you're talking about 402 nameservers instead of just 2. Since local bandwidth is "free", this could be seen as a poor engineering choice, and you still had to maintain those two servers for the other (Windows or whatever) boxes anyways. On the upside, you don't need to use a forwarders arrangement unless you really want to... but the benefit of those 400 extra nameserver instances is a bit sketchy. ... 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 karnaugh at karnaugh.za.net Mon Aug 11 07:38:07 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 11 Aug 2008 14:38:07 +0200 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <200808111210.m7BCAQSB087205@aurora.sol.net> References: <200808111210.m7BCAQSB087205@aurora.sol.net> Message-ID: <48A032AF.5020709@karnaugh.za.net> Joe Greco wrote: >> Unix machines set up by anyone with half a brain run a local caching >> server, and use forwarders. IE, the nameserver process can establish a >> persistent TCP connection to its trusted forwarders, if we just let it. > > Organizations often choose not to do this because doing so involves more > risk and more things to update when the next vulnerability appears. In > many cases, you are suggesting additional complexity and management > requirements. A hosting company, for example, might have 20 racks of > machines with 40 machines each, which is 800 servers. If half of those > are UNIX, then you're talking about 402 nameservers instead of just 2. [Customers] <--/UDP/--> [DNS Cache] <--/TCP/--> [DNS servers] Not so? Of course, one shouldn't let the rest of the internet touch your DNS Cache query interface... but that's just obvious. I mentioned this a while ago though, so I demand credit ;P Also, I think there is probably an IETF DNS WG list where this fits on topic (I have no idea what it may be though). From darden at armc.org Mon Aug 11 07:49:00 2008 From: darden at armc.org (Darden, Patrick S.) Date: Mon, 11 Aug 2008 08:49:00 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <200808111210.m7BCAQSB087205@aurora.sol.net> Message-ID: Joe makes some good points here. I'd have to add one caveat though: it depends. It depends on the server. Busy email servers definitely depend on having fast DNS, and benefit *greatly* from a caching DNS server using local sockets instead. Web servers generally don't. Centralized logging servers benefit greatly. Usually, for a pocket of servers like Joe describes, you want some local dedicated DNS servers (e.g. ~800 servers, add 2 more just for local DNS) plus you would want caching DNS servers running directly on your email, logging, etc. servers. Yeah, 400-800 extra caching DNS servers would probably be overkill though! I am intrigued by the idea of persistent connections for those 2 dedicated DNS servers--only for upstream though. You wouldn't need so much security locally (for your 800 clients), I expect. You could use UDP for speed, and not worry too much about poisoning. Expecially if you were using some kind of dedicated professional DNS service that required IPSEC pipes, and had engineers only doing DNS: security, updates, patching, uptime, etc. etc. It would be interesting if such professional services came about Companies that do DNS and that is all they do. Dedicated to the reliability and security of one of the cornerstones of the net. We already went through that with Usenet, email, web hosting, and other of the main services. --Patrick Darden -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Monday, August 11, 2008 8:10 AM To: Tomas L. Byrnes Cc: nanog at merit.edu Subject: Re: maybe a dumb idea on how to fix the dns problems i don't know.... > Unix machines set up by anyone with half a brain run a local caching > server, and use forwarders. IE, the nameserver process can establish a > persistent TCP connection to its trusted forwarders, if we just let it. Organizations often choose not to do this because doing so involves more risk and more things to update when the next vulnerability appears. In many cases, you are suggesting additional complexity and management requirements. A hosting company, for example, might have 20 racks of machines with 40 machines each, which is 800 servers. If half of those are UNIX, then you're talking about 402 nameservers instead of just 2. Since local bandwidth is "free", this could be seen as a poor engineering choice, and you still had to maintain those two servers for the other (Windows or whatever) boxes anyways. On the upside, you don't need to use a forwarders arrangement unless you really want to... but the benefit of those 400 extra nameserver instances is a bit sketchy. ... 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 darden at armc.org Mon Aug 11 07:50:14 2008 From: darden at armc.org (Darden, Patrick S.) Date: Mon, 11 Aug 2008 08:50:14 -0400 Subject: maybe a dumb idea on how to fix the dns problems i don't know.... In-Reply-To: <48A032AF.5020709@karnaugh.za.net> Message-ID: I think Colin just said everything I said, but in 1/10'th the words. And he posted before me. Drats. --Patrick Darden -----Original Message----- From: Colin Alston [mailto:karnaugh at karnaugh.za.net] Sent: Monday, August 11, 2008 8:38 AM To: Joe Greco Cc: nanog at merit.edu Subject: Re: maybe a dumb idea on how to fix the dns problems i don't know.... Joe Greco wrote: >> Unix machines set up by anyone with half a brain run a local caching >> server, and use forwarders. IE, the nameserver process can establish a >> persistent TCP connection to its trusted forwarders, if we just let it. > > Organizations often choose not to do this because doing so involves more > risk and more things to update when the next vulnerability appears. In > many cases, you are suggesting additional complexity and management > requirements. A hosting company, for example, might have 20 racks of > machines with 40 machines each, which is 800 servers. If half of those > are UNIX, then you're talking about 402 nameservers instead of just 2. [Customers] <--/UDP/--> [DNS Cache] <--/TCP/--> [DNS servers] Not so? Of course, one shouldn't let the rest of the internet touch your DNS Cache query interface... but that's just obvious. I mentioned this a while ago though, so I demand credit ;P Also, I think there is probably an IETF DNS WG list where this fits on topic (I have no idea what it may be though). From williams.bruce at gmail.com Mon Aug 11 08:15:45 2008 From: williams.bruce at gmail.com (Bruuce Williams) Date: Mon, 11 Aug 2008 06:15:45 -0700 Subject: Solution vs. Implementation Message-ID: <48a03b87.1e078e0a.09b8.6445@mx.google.com> Could someone who reads "the other lists" on the DNS problem mind posting a summery here? While this list is theorizing a solution, they may be theorizing implementation considerations, so a little back-and-forth communication might be useful. Just a thought... Bruce Williams the first principle is that you must not fool yourself, and you are the easiest person to fool -- Richard P. Feynman From LarrySheldon at cox.net Mon Aug 11 08:27:44 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 11 Aug 2008 08:27:44 -0500 Subject: impossible circuit In-Reply-To: <489FCD17.6000301@montco.net> References: <489FCD17.6000301@montco.net> Message-ID: <48A03E50.7010800@cox.net> George Carey wrote: > Since your fix was layer 2 you might be onto something. And you have the > time it happened, and as we all know - somebody changed somethin' even > if they won't fess up. I have not pencil-and-papered this to see if there is anything to it, but I was wondering what would happened if you put a layer-two bridge into a back-bone fabric and turned off "learning" so every packet is flooded to every port. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From jbates at brightok.net Mon Aug 11 09:41:54 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 11 Aug 2008 09:41:54 -0500 Subject: DNS attacks evolve In-Reply-To: <200808092102.m79L2ZNj031860@aurora.sol.net> References: <200808092102.m79L2ZNj031860@aurora.sol.net> Message-ID: <48A04FB2.4040602@brightok.net> Joe Greco wrote: > > 6) Have someone explain to me the reasoning behind allowing the corruption > of in-cache data, even if the data would otherwise be in-baliwick. I'm > not sure I quite get why this has to be. It would seem to me to be safer > to discard the data. (Does not eliminate the problem, but would seem to > me to reduce it) > I had this question in my post weeks ago. No one bothered to reply. Older poisoning is why the auth data must be within the same zone to be cached, but apparently no one bothered to question the wisdom of altering existing cache data. Wish they'd just fix the fault in the logic and move on. Talking til everyone is blue in the face about protocol changes and encryption doesn't serve operations. There are recursive resolvers that work just fine without the issues some standard resolvers have. The protocol seems to work, some vendors just need to change how they use it and tighten up on cache integrity. > 7) Have someone explain to me the repeated claims I've seen that djbdns and > Nominum's server are not vulnerable to this, and why that is. > PowerDNS has this to say about their non-vulnerability status: http://mailman.powerdns.com/pipermail/pdns-users/2008-July/005536.html I know some very happy providers that haven't had to patch. I hope to be one of them on the next round. Jack From bicknell at ufp.org Mon Aug 11 10:20:07 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Aug 2008 11:20:07 -0400 Subject: DNS attacks evolve In-Reply-To: <48A04FB2.4040602@brightok.net> References: <200808092102.m79L2ZNj031860@aurora.sol.net> <48A04FB2.4040602@brightok.net> Message-ID: <20080811152006.GA17490@ussenterprise.ufp.org> In a message written on Mon, Aug 11, 2008 at 09:41:54AM -0500, Jack Bates wrote: > >7) Have someone explain to me the repeated claims I've seen that djbdns and > > Nominum's server are not vulnerable to this, and why that is. > > PowerDNS has this to say about their non-vulnerability status: > > http://mailman.powerdns.com/pipermail/pdns-users/2008-July/005536.html > > I know some very happy providers that haven't had to patch. I hope to be > one of them on the next round. It's not that they are immune to the attack, and I think a few people deserve to be smacked around for the language they use..... Let's be perfectly clear, without DNSSEC or an alteration to the DNS Protocol THERE IS NO WAY TO PREVENT THIS ATTACK. There are only ways to make the attack harder. So what PowerDNS, DJB and others are telling you is not that you are immune, it is that you're not the low hanging fruit. A more direct way of stating their press releases would be: Everyone else figured out it took 3 minutes to hack their servers and implemented patches to make it take 2 hours. Our server always had the logic to make it take 2 hours, so we were ahead of the game. Great. If your vendor told you that you are not at risk they are wrong, and need to go re-read the Kaminski paper. EVERYONE is vunerable, the only question is if the attack takes 1 second, 1 minute, 1 hour or 1 day. While possibly interesting for short term problem management none of those are long term fixes. I'm not sure your customers care when .COM is poisoned if it took the attacker 1 second or 1 day. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jra at baylink.com Mon Aug 11 10:39:25 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 11 Aug 2008 11:39:25 -0400 Subject: Why *can* cached DNS replies be overwritten? Message-ID: <20080811153925.GP8391@cgi.jachomes.com> On Mon, Aug 11, 2008 at 11:20:07AM -0400, Leo Bicknell wrote: > If your vendor told you that you are not at risk they are wrong, > and need to go re-read the Kaminski paper. EVERYONE is vunerable, > the only question is if the attack takes 1 second, 1 minute, 1 hour > or 1 day. While possibly interesting for short term problem > management none of those are long term fixes. I'm not sure your > customers care when .COM is poisoned if it took the attacker 1 > second or 1 day. Correct me if I'm wrong, Leo, but your assertion turns on the fact that the server will accept an overwriting cache entry for something it already has cacheed, does it not? Do djb and Power in fact do that? If they don't, the window of opportunity to poison something like .com is limited to the period between when that entry expires from the local server's cache and the next time it hears a reply -- which will be the time after that expiry when someone next requests a .com name; IE almost immediately, no? Everyone seems to continue asking "why can poisoning overwrite already cached answer" and no one seems to be answering, and, unless I'm a moron (which is not impossible), that's the crux of this issue. 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. -- (Josef Stalin) From jbates at brightok.net Mon Aug 11 10:46:27 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 11 Aug 2008 10:46:27 -0500 Subject: DNS attacks evolve In-Reply-To: <20080811152006.GA17490@ussenterprise.ufp.org> References: <200808092102.m79L2ZNj031860@aurora.sol.net> <48A04FB2.4040602@brightok.net> <20080811152006.GA17490@ussenterprise.ufp.org> Message-ID: <48A05ED3.5030709@brightok.net> Leo Bicknell wrote: > If your vendor told you that you are not at risk they are wrong, > and need to go re-read the Kaminski paper. EVERYONE is vunerable, > the only question is if the attack takes 1 second, 1 minute, 1 hour > or 1 day. While possibly interesting for short term problem > management none of those are long term fixes. I'm not sure your > customers care when .COM is poisoned if it took the attacker 1 > second or 1 day. EVERYONE with a CACHE MIGHT be vulnerable. Have studies been done to determine if existing cached records will be overwritten on ALL caching resolvers? Poisoning has always and will always be possible until DNSSEC, but the question isn't if you can poison a few off the wall records, but if you can poison the resolver in any meaningful way. If the cache isn't passively overwritten, then the only records you could poison would be records that aren't cached. The operational impact would be a much smaller scope. .COM will be cached constantly and to poison it, the attacker would have to forge the packet in the small window of cache expiry to renewal. This can be mitigated even more if sites give out auth on negative responses, which means for that specific domain, the attacker gets 1 shot to spoof and then the auth info is cached. Obviously there is a downside to sending larger packets, but that is a decision for the domain holder. I'll be happy to add DNSSEC to my operational list as soon as it's actually useful (other people can argue over who signs what). Jack From dot at dotat.at Mon Aug 11 10:58:45 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 11 Aug 2008 16:58:45 +0100 Subject: Why *can* cached DNS replies be overwritten? In-Reply-To: <20080811153925.GP8391@cgi.jachomes.com> References: <20080811153925.GP8391@cgi.jachomes.com> Message-ID: On Mon, 11 Aug 2008, Jay R. Ashworth wrote: > > Everyone seems to continue asking "why can poisoning overwrite already > cached answer" and no one seems to be answering, and, unless I'm a > moron (which is not impossible), that's the crux of this issue. Add me to the list of baffled observers. As far as I can tell this vulnerability to poisoning is mostly forbidden by the trustworthiness ranking in RFC 2181. Tony. -- f.anthony.n.finch http://dotat.at/ VIKING NORTH UTSIRE: SOUTHWEST 5 TO 7 BACKING SOUTHEAST 4 OR 5. ROUGH OR VERY ROUGH, DECREASING MODERATE LATER. RAIN THEN SHOWERS. MODERATE OR POOR BECOMING GOOD. From bicknell at ufp.org Mon Aug 11 10:59:16 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Aug 2008 11:59:16 -0400 Subject: Why *can* cached DNS replies be overwritten? In-Reply-To: <20080811153925.GP8391@cgi.jachomes.com> References: <20080811153925.GP8391@cgi.jachomes.com> Message-ID: <20080811155916.GA24242@ussenterprise.ufp.org> In a message written on Mon, Aug 11, 2008 at 11:39:25AM -0400, Jay R. Ashworth wrote: > Everyone seems to continue asking "why can poisoning overwrite already > cached answer" and no one seems to be answering, and, unless I'm a > moron (which is not impossible), that's the crux of this issue. Let's say you query FOO.COM, and it says "My servers are A, B, and C." So you cache A, B, and C and go on your merry way. Now, before the TTL expires the data center with B and C in it gets hit by a tornado. The FOO.COM admin quickly stands up two new servers in a new data center, and updates FOO.COM to be servers A, D, and E. So you go back and ask for "newname.foo.com" from A, by random chance. A sends you back "it's 1.2.3.4, and A, D, and E know all about it.". What you're advocating is that the server go, humm, that's not what I got the first time and keep using A, B, and C, for which B and C may no longer be authortative, or worse in this example, are completly offline. It would then wait until the TTL expires to get the same data. That's not to say there aren't possibly other checks or rechecks that could be done, but in the vast majority of day to day cases when someone properly gives you additional information it is useful. Authorities are updated all the time. There are thousands of these cache overwrites with new, more up to date info every day. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jra at baylink.com Mon Aug 11 11:09:53 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 11 Aug 2008 12:09:53 -0400 Subject: Why *can* cached DNS replies be overwritten? In-Reply-To: <20080811155916.GA24242@ussenterprise.ufp.org> References: <20080811153925.GP8391@cgi.jachomes.com> <20080811155916.GA24242@ussenterprise.ufp.org> Message-ID: <20080811160953.GZ8391@cgi.jachomes.com> On Mon, Aug 11, 2008 at 11:59:16AM -0400, Leo Bicknell wrote: > Let's say you query FOO.COM, and it says "My servers are A, B, and > C." So you cache A, B, and C and go on your merry way. > > Now, before the TTL expires the data center with B and C in it gets > hit by a tornado. The FOO.COM admin quickly stands up two new > servers in a new data center, and updates FOO.COM to be servers A, > D, and E. So you go back and ask for "newname.foo.com" from A, by > random chance. A sends you back "it's 1.2.3.4, and A, D, and E > know all about it.". > > What you're advocating is that the server go, humm, that's not what > I got the first time and keep using A, B, and C, for which B and C > may no longer be authortative, or worse in this example, are completly > offline. It would then wait until the TTL expires to get the same > data. As long as one of the cached zone servers is still working, no, it would only time out the individual queries. > That's not to say there aren't possibly other checks or rechecks > that could be done, but in the vast majority of day to day cases > when someone properly gives you additional information it is useful. > > Authorities are updated all the time. There are thousands of these > cache overwrites with new, more up to date info every day. It would seem to me that the aggregate amount of trouble that would be caused by handling differently the situation that you posit above is several orders of magnitude smaller in importance than the trouble which would stem from someone cache-poisoning .com on the resovers of the top 10 consumer ISPs. IE: that's a really lame reason to leave it as it is. ;-) 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. -- (Josef Stalin) From jbates at brightok.net Mon Aug 11 11:31:01 2008 From: jbates at brightok.net (Jack Bates) Date: Mon, 11 Aug 2008 11:31:01 -0500 Subject: Why *can* cached DNS replies be overwritten? In-Reply-To: <20080811155916.GA24242@ussenterprise.ufp.org> References: <20080811153925.GP8391@cgi.jachomes.com> <20080811155916.GA24242@ussenterprise.ufp.org> Message-ID: <48A06945.3010107@brightok.net> Leo Bicknell wrote: > That's not to say there aren't possibly other checks or rechecks > that could be done, but in the vast majority of day to day cases > when someone properly gives you additional information it is useful. > > Authorities are updated all the time. There are thousands of these > cache overwrites with new, more up to date info every day. > The problem is, it's not trustworthy. There's lots of heuristics that could be done to determine pre-expiration of cached data, but it should be just that an expiring of the cached data allowing for a new request for it. Possible scenario's: 1) Mismatched auth records causes expiring of the records. Attacker has successfully spoofed a packet and caused a cache dump for the record in question. He must now spoof another packet before the cache is rebuilt. 2) Mismatched auth records are ignored, causing delays in the remote updating to new records. This is a better distrust model, though it may have a longer impact on outage situations. 3) Recognize successive timed out queries to an auth server, marking it as possibly not there, stale out the cache and ask for new information, or allow for cache overwrite only concerning records which appear not to be working. 4) Recognize entries which are receiving forged packet attempts (easiest to do) and do not support cache overwrites for those domains. This supports normal operation unless someone is specifically attacking a domain, and then that domain leaves a trust model to an untrusted model, which may have performance hits in that we will ignore valid updates too, but given that the server cannot tell the forgery from the real update, it should be ignored. This method is vulnerable to the once in a X shot that the first forged packet actually makes it with the right port/id combo. Cache overwrites are dangerous. IMHO, They need to go away or be protected by extensive checks to insure integrity of the cache. Jack From Ed.Lewis at neustar.biz Mon Aug 11 12:30:29 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 11 Aug 2008 10:30:29 -0700 Subject: Why *can* cached DNS replies be overwritten? In-Reply-To: <48A06945.3010107@brightok.net> References: <20080811153925.GP8391@cgi.jachomes.com> <20080811155916.GA24242@ussenterprise.ufp.org> <48A06945.3010107@brightok.net> Message-ID: At 11:31 -0500 8/11/08, Jack Bates wrote: > >Leo Bicknell wrote: > >> Authorities are updated all the time. There are thousands of these >> cache overwrites with new, more up to date info every day. > >The problem is, it's not trustworthy. In the original definition of DNS, there were no or almost no dynamic changes. The protocol wasn't built for that. The result is all of the old sacred texts are written in a context that everything is static (for as least as long as the TTL). The modern operation of the DNS is more dynamic. It isn't a case that the protocol today cannot be (more) dynamic (than the founding engineers thought) but that all of the documented texts upon wish we today base arguments are written along the "old think" lines. So when we get into a battle of RFCs vs. best current practices the two sides are not speaking the same language. The DNS can be more dynamic by liberalizing it's ability to learn new data. It's a sliding curve - more liberal means accepting more stuff, some of which might be the garbage we don't want. The choice is between tight and unbending versus dynamic and less trustworthy. The goal is to strike the right balance. It is possible for a protocol to do what DNS does and also have secure updates. But the DNS as it is in the RFCs, lacks a real good foundation for extension. We can do something, but we will probably never get to the final goal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From justin at justinshore.com Mon Aug 11 15:17:18 2008 From: justin at justinshore.com (Justin Shore) Date: Mon, 11 Aug 2008 15:17:18 -0500 Subject: impossible circuit In-Reply-To: <48A03E50.7010800@cox.net> References: <489FCD17.6000301@montco.net> <48A03E50.7010800@cox.net> Message-ID: <48A09E4E.8000002@justinshore.com> Laurence F. Sheldon, Jr. wrote: > George Carey wrote: > > I have not pencil-and-papered this to see if there is anything to it, > but I was wondering what would happened if you put a layer-two bridge > into a back-bone fabric and turned off "learning" so every packet is > flooded to every port. Though not the same circumstances on having the same symptoms as the OP's problem, I saw this happen once at a University I used to work for. A system's administrator insisted on having a hub between the SP's router and our core campus switch so he could sniff traffic. Since the hub was there and I couldn't eliminate it I went ahead and used it myself for my own traffic capture point in the network with an OS X box running EtherPeek. I did an OS update on the box one morning and went to a meeting. During the meeting it was reported that the network was down. I started looking into the problem at that point. All Internet traffic was dead except SSH connections. So I started sniffing on my NOC server for that server's traffic. All my outbound TCP connections from the NOC were getting a RST from one L2 host and a SYN-ACK from another. The MAC address sending the RST looked familiar but I couldn't identify it. After searching through the network for the MAC I found it on the interface facing our border router and that damn hub. The MAC was my OS X sniffing box. The other MAC was the backside of the provider's router. The OS X update I applied was the one that installed a host-based firewall. The update automatically turned on the FW and permitted all local servers that were configured to run, in my case SSH, with everything else being denied. The FW on the OS X box normally wouldn't see packets not destined for it until you put a nic in promisc mode such as what happens when you run EtherPeek. The OS X box's FW was getting hits from traffic denied by it's ACL and was sending TCP RSTs faster than hosts on the 'Net could respond. It did this for everything except SSH which it permitted (but higher up the IP stack it ignored because the IP packet was address to the local box). This isn't in any way related to the problem at hand but it does demonstrate that weird things happen when devices in unusual places flood out all ports. Justin From jra at baylink.com Mon Aug 11 15:22:28 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 11 Aug 2008 16:22:28 -0400 Subject: impossible circuit In-Reply-To: <48A09E4E.8000002@justinshore.com> References: <489FCD17.6000301@montco.net> <48A03E50.7010800@cox.net> <48A09E4E.8000002@justinshore.com> Message-ID: <20080811202228.GD9550@cgi.jachomes.com> On Mon, Aug 11, 2008 at 03:17:18PM -0500, Justin Shore wrote: > The OS X update I applied was the one that installed a host-based > firewall. The update automatically turned on the FW and permitted all > local servers that were configured to run, in my case SSH, with > everything else being denied. The FW on the OS X box normally wouldn't > see packets not destined for it until you put a nic in promisc mode such > as what happens when you run EtherPeek. The OS X box's FW was getting > hits from traffic denied by it's ACL and was sending TCP RSTs faster > than hosts on the 'Net could respond. It did this for everything except > SSH which it permitted (but higher up the IP stack it ignored because > the IP packet was address to the local box). > > This isn't in any way related to the problem at hand but it does > demonstrate that weird things happen when devices in unusual places > flood out all ports. And this explains why in Bellovin's Wily Hacker book, there's an anecdote about a sniffer machine on which they had to *physically cut the transmit wire* because they could *not* get the machine to not... do something. ARP queries? 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. -- (Josef Stalin) From tkapela at gmail.com Mon Aug 11 15:47:34 2008 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 11 Aug 2008 13:47:34 -0700 Subject: BGP route filtering. You want it. Message-ID: <2e9d8ae50808111347o39d13ef7n5704be5f1fefef35@mail.gmail.com> List, [Apologies in advance for operational content. I Don't mean to distract readers from the usual flamewars about rfc1918, bogon filtering, and some of our favorite posters - gadi and n3td3v.] I'd like to give a heads-up to the NANOG community regarding the talk we recently gave at DEFCON. The slides can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt In a nutshell, we demonstrated that current lack of secure filtering infrastructure not only permits DoS-like attacks, but also full "traffic monitoring" of arbitrary prefixes from essentially anywhere in the world. None of this should come as surprise to the NANOG and operationally-aware crowd - this has been discussed extensively previously before on-list, and extensively at conferences. Additional novelty presented is the returning of traffic back to victim network over Internet (creative as-path prepends & loop detection) and obscuring the 'additional hops' this sort of thing creates with additive ttl. Suggested additional reading below: http://www.nanog.org/mtg-9802/yu.ppt http://www.nanog.org/mtg-0010/ppt/tony.ppt http://www.nanog.org/mtg-0010/ppt/danny.ppt http://www.nanog.org/mtg-0206/ppt/security1.1.pdf http://www.nanog.org/mtg-0501/pdf/tauber.pdf http://www.nanog.org/mtg-0505/pdf/underwood.pdf http://www.nanog.org/mtg-0510/pdf/deleskie.pdf http://www.nanog.org/mtg-0602/pdf/boothe.pdf http://www.nanog.org/mtg-0610/presenter-pdfs/massey.pdf http://www.nanog.org/mtg-0806/presentations/wednesday/DanMcP_Route_Filter_Panel_N43.pdf http://www.nanog.org/mtg-0806/presentations/sunday/BRGREEN_prefix_filtering_N43.ppt http://www.renesys.com/tech/presentations/pdf/menog3-youtube.pdf http://www.renesys.com/tech/presentations/pdf/nanog43-hijack.pdf -Tk/P. From Bourbon.Odenthal at sce.com Mon Aug 11 15:57:13 2008 From: Bourbon.Odenthal at sce.com (Bourbon.Odenthal at sce.com) Date: Mon, 11 Aug 2008 13:57:13 -0700 Subject: BGP route filtering. You want it. Message-ID: I really enjoyed it! Rerouting all of Defcon's traffic thru NY was a nice touch. Hopefully the additional awareness of this will help progress toward getting the issues fixed. Good job! -bb ----- Original Message ----- From: "Anton Kapela" [tkapela at gmail.com] Sent: 08/11/2008 01:47 PM MST To: nanog at nanog.org Subject: BGP route filtering. You want it. List, [Apologies in advance for operational content. I Don't mean to distract readers from the usual flamewars about rfc1918, bogon filtering, and some of our favorite posters - gadi and n3td3v.] I'd like to give a heads-up to the NANOG community regarding the talk we recently gave at DEFCON. The slides can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt In a nutshell, we demonstrated that current lack of secure filtering infrastructure not only permits DoS-like attacks, but also full "traffic monitoring" of arbitrary prefixes from essentially anywhere in the world. None of this should come as surprise to the NANOG and operationally-aware crowd - this has been discussed extensively previously before on-list, and extensively at conferences. Additional novelty presented is the returning of traffic back to victim network over Internet (creative as-path prepends & loop detection) and obscuring the 'additional hops' this sort of thing creates with additive ttl. Suggested additional reading below: http://www.nanog.org/mtg-9802/yu.ppt http://www.nanog.org/mtg-0010/ppt/tony.ppt http://www.nanog.org/mtg-0010/ppt/danny.ppt http://www.nanog.org/mtg-0206/ppt/security1.1.pdf http://www.nanog.org/mtg-0501/pdf/tauber.pdf http://www.nanog.org/mtg-0505/pdf/underwood.pdf http://www.nanog.org/mtg-0510/pdf/deleskie.pdf http://www.nanog.org/mtg-0602/pdf/boothe.pdf http://www.nanog.org/mtg-0610/presenter-pdfs/massey.pdf http://www.nanog.org/mtg-0806/presentations/wednesday/DanMcP_Route_Filter_Panel_N43.pdf http://www.nanog.org/mtg-0806/presentations/sunday/BRGREEN_prefix_filtering_N43.ppt http://www.renesys.com/tech/presentations/pdf/menog3-youtube.pdf http://www.renesys.com/tech/presentations/pdf/nanog43-hijack.pdf -Tk/P. From tkapela at gmail.com Mon Aug 11 18:36:13 2008 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 11 Aug 2008 16:36:13 -0700 Subject: BGP route filtering. You want it. In-Reply-To: <2e9d8ae50808111347o39d13ef7n5704be5f1fefef35@mail.gmail.com> References: <2e9d8ae50808111347o39d13ef7n5704be5f1fefef35@mail.gmail.com> Message-ID: <2e9d8ae50808111636l287707b0vf38cbd3ac3bde4e6@mail.gmail.com> URL works again. I had uploaded an edited version of the talk, but forgot to rename it. It's probably good that only a few of you saw the original, as it wasn't quite the 'professional' text that I'd typically write. Permissible and desired presentation formats and language at DEFCON don't have parallels in this venue. Best, -Tk From deepak at ai.net Mon Aug 11 22:15:49 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 11 Aug 2008 23:15:49 -0400 Subject: Coop Peering Fabric?? Message-ID: <48A10065.4060900@ai.net> Warning: This may actually be operational too. Given Cogent (and others) recent pursuit of sub $4/mb/s transit... and the relatively flat cost of a "paid" peering fabric (even at 10G) and the O(N) costs for cross-connects, the thought of revisiting the old peering coops presented itself again. Assuming 10G PNI model: Assuming even nominal cross-connect fees of $100-$300/month per fiber pair, plus router port costs for each private peer (assuming you aren't at >10% utilization on the port) at a commercial exchange, you are eating a pretty significant cost per megabit you are actually moving. (plug in your numbers here). Assumption: Above 1Gb/s utilization, this makes sense or you are counting on growth. Below 10% you would normally go to a paid peering fabric where you are paying cross connect + a flat port charge + router port for 1->N peers and hoping that enough utilization occurs that you get >10% utilization (to recover capex, opex, etc) and then whatever additional utilization you need to cover the flat port charge or you are counting on growth. A "coop", best-effort switch fabric colo'd at a few sites would allow participants to peer off traffic at a price of the order of a single cross-connect (~$500/month per 10G port is possible, maybe less), private-VLANs all-around, or to only-mutually approved peers (e.g. via an automated web interface, prior art) to avoid many of the /old/ issues. No requirement for multi-lateral peering. You could peer, sell transit, buy transit, multicast, etc. The way I figure it, it removes approximately an order of magnitude from the operational cost of peering with more than a handful of your largest single talkers. Especially as 100G LAN Ethernet becomes production before 100G WAN connections become commonplace. Economic theory (assuming that worked on the Internet) suggests this would allow for the increase in number of peers by approximately an order of magnitude (maybe more). Does this actually improve the present-day "rationale" to peer, or are most operations' costs so far above (from long haul, etc) or so far below (since the cost of transit has dropped so much) that this is no longer a relevant part of the equation? Warning: This may actually be operational too. Deepak Jain AiNET From patrick at ianai.net Mon Aug 11 22:37:58 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Aug 2008 23:37:58 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <48A10065.4060900@ai.net> References: <48A10065.4060900@ai.net> Message-ID: <50010C5E-23D7-40E5-890C-88A494B4F69E@ianai.net> As a big ra-ra guy around peering, I thought this might be interesting, but I do not think I agree with the numbers. On Aug 11, 2008, at 11:15 PM, Deepak Jain wrote: > Given Cogent (and others) recent pursuit of sub $4/mb/s transit... > and the relatively flat cost of a "paid" peering fabric (even at > 10G) and the O(N) costs for cross-connects, the thought of > revisiting the old peering coops presented itself again. The $4/Mbps & under prices is usually reserved for very large CIR or full pipe. With a full pipe, assuming you are very, very, very good, you still pay $5 or more. (I'm assuming a max of 8 Gbps on a 10G pipe, which seems overly optimistic IMHO.) But that's not important to the discussion. > Assuming 10G PNI model: Assuming even nominal cross-connect fees of > $100-$300/month per fiber pair, plus router port costs for each > private peer (assuming you aren't at >10% utilization on the port) > at a commercial exchange, you are eating a pretty significant cost > per megabit you are actually moving. (plug in your numbers here). > Assumption: Above 1Gb/s utilization, this makes sense or you are > counting on growth. Define "significant"? Taking 1 Gbps (10%), and assuming even 20K per 10G port over 2 years, adding in $300/month for the x-conn, you are still looking at barely over $1/Mbps. If you have more than 10% utilization, that number goes down. Is that significant? Compared to what? Transit? I would say a 75% price reduction is pretty significant. Plus you haven't considered CapEx cost for the transit ports. > Below 10% you would normally go to a paid peering fabric where you > are paying cross connect + a flat port charge + router port for 1->N > peers and hoping that enough utilization occurs that you get >10% > utilization (to recover capex, opex, etc) and then whatever > additional utilization you need to cover the flat port charge or you > are counting on growth. Here we agree. The port fee even on european IXes is measured in 1000s of $$ per month. And don't get me started on US or Japanese ports.... > A "coop", best-effort switch fabric colo'd at a few sites would > allow participants to peer off traffic at a price of the order of a > single cross-connect (~$500/month per 10G port is possible, maybe > less), private-VLANs all-around, or to only-mutually approved peers > (e.g. via an automated web interface, prior art) to avoid many of > the /old/ issues. No requirement for multi-lateral peering. You > could peer, sell transit, buy transit, multicast, etc. > > The way I figure it, it removes approximately an order of magnitude > from the operational cost of peering with more than a handful of > your largest single talkers. Especially as 100G LAN Ethernet becomes > production before 100G WAN connections become commonplace. Economic > theory (assuming that worked on the Internet) suggests this would > allow for the increase in number of peers by approximately an order > of magnitude (maybe more). Sorry, I can't get there. First, the "largest single talkers" would not be on a shared fabric, they'd be on dedicated ports, so this idea doesn't help. For the medium to small guys, I think it's a great idea. Look at SIX, TorIX, PaNAP, etc. But shaving an _order of magnitude_ off? No, I don't see it. CapEx alone is more than 10% of your cost. (Well, unless you get Japanese IX ports or the most expensive US IX ports.) Perhaps I'm lost or confused? Can someone help me understand? -- TTFN, patrick From woody at pch.net Mon Aug 11 22:45:08 2008 From: woody at pch.net (Bill Woodcock) Date: Mon, 11 Aug 2008 20:45:08 -0700 (PDT) Subject: Coop Peering Fabric?? In-Reply-To: <48A10065.4060900@ai.net> References: <48A10065.4060900@ai.net> Message-ID: On Mon, 11 Aug 2008, Deepak Jain wrote: > A "coop", best-effort switch fabric colo'd at a few sites would allow > participants to peer off traffic at a price of the order of a single > cross-connect (~$500/month per 10G port is possible, maybe less), $0/month per 10G port is common enough. https://www.seattleix.net/faq.htm Why pay someone else to let you use an Ethernet switch? Presumably if you can configure BGP, plugging into an Ethernet switch is well within your core competency. -Bill From deepak at ai.net Mon Aug 11 23:45:51 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 12 Aug 2008 00:45:51 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <50010C5E-23D7-40E5-890C-88A494B4F69E@ianai.net> References: <48A10065.4060900@ai.net> <50010C5E-23D7-40E5-890C-88A494B4F69E@ianai.net> Message-ID: <48A1157F.2090506@ai.net> Patrick W. Gilmore wrote: > As a big ra-ra guy around peering, I thought this might be interesting, > but I do not think I agree with the numbers. > I think you read this thinking I meant something I didn't mean; perhaps I should have used a different set of prepositions. [deleted the discussion about utilization and CIRs, that is up to everyone to engineer and negotiate, my point shouldn't be so fragile as to require quoting spot pricing in markets @ various commits]. > >> Assuming 10G PNI model: Assuming even nominal cross-connect fees of >> $100-$300/month per fiber pair, plus router port costs for each >> private peer (assuming you aren't at >10% utilization on the port) at >> a commercial exchange, you are eating a pretty significant cost per >> megabit you are actually moving. (plug in your numbers here). >> Assumption: Above 1Gb/s utilization, this makes sense or you are >> counting on growth. > > Define "significant"? If you are running << 1Gb/s per PNI it is "expensive". > Taking 1 Gbps (10%), and assuming even 20K per 10G port over 2 years, > adding in $300/month for the x-conn, you are still looking at barely > over $1/Mbps. If you have more than 10% utilization, that number goes > down. Is that significant? Compared to what? Transit? You have costs. Below 1Gb/s I'm stating they are "significant". The assumption above says it "automatically makes sense" above 1Gb/s or you are counting on growth with a starting point below 1Gb/s. The idea of presenting the PNI case was to avoid this sort of response. Obviously I didn't draw enough attention to the assumptions. > I would say a 75% price reduction is pretty significant. Plus you > haven't considered CapEx cost for the transit ports. > Depends on the business. 75% may not be enough if a network's opex costs (PP&E) are high enough that this doesn't help. Again, I was trying to avoid painting the picture for any particular network, but more of the industry's interested parties as a whole. > >> Below 10% you would normally go to a paid peering fabric where you are >> paying cross connect + a flat port charge + router port for 1->N peers >> and hoping that enough utilization occurs that you get >10% >> utilization (to recover capex, opex, etc) and then whatever additional >> utilization you need to cover the flat port charge or you are counting >> on growth. > > Here we agree. The port fee even on european IXes is measured in 1000s > of $$ per month. And don't get me started on US or Japanese ports.... I was thinking of US ports, but modeling based on LINX pricing. >> A "coop", best-effort switch fabric colo'd at a few sites would allow >> participants to peer off traffic at a price of the order of a single >> cross-connect (~$500/month per 10G port is possible, maybe less), >> private-VLANs all-around, or to only-mutually approved peers (e.g. via >> an automated web interface, prior art) to avoid many of the /old/ >> issues. No requirement for multi-lateral peering. You could peer, sell >> transit, buy transit, multicast, etc. >> >> The way I figure it, it removes approximately an order of magnitude >> from the operational cost of peering with more than a handful of your >> largest single talkers. Especially as 100G LAN Ethernet becomes >> production before 100G WAN connections become commonplace. Economic >> theory (assuming that worked on the Internet) suggests this would >> allow for the increase in number of peers by approximately an order of >> magnitude (maybe more). > > Sorry, I can't get there. > > First, the "largest single talkers" would not be on a shared fabric, > they'd be on dedicated ports, so this idea doesn't help. I excluded "largest single talkers" by saying "more than a handful of your largest single talkers. Semantically, the assumption in PNI was that at 1Gb or above PNI makes sense [or you'd soon get there]." The question I asked was really related to the idea. If you have a few sensible PNIs, presumably you have enough traffic that you could conceivably have many potential peers at levels below the PNI case, but above the degenerate traffic case. (0, maybe 20mb/s, some number that isn't interesting enough to engineer for [or even consider] unless you have a nearly zero marginal cost to approach it) > For the medium to small guys, I think it's a great idea. Look at SIX, > TorIX, PaNAP, etc. But shaving an _order of magnitude_ off? No, I > don't see it. CapEx alone is more than 10% of your cost. (Well, unless > you get Japanese IX ports or the most expensive US IX ports.) > > Perhaps I'm lost or confused? Can someone help me understand? You and Woodcock make a good point (re: SIX @ zero cost). However, ~20Gb/s aggregate is at most saving $80K/month between all participants for the additional traffic, which is pretty academic given the costs of operating networks of any sufficient scale [without looking at the constituency of the participants or the traffic]. If *each* network were saving $80K/month through the use of a few of these in multiple cities, that would be interesting to me. I guess they would be more interesting deployed in Ashburn or some place similar because you could exclude the cost of "bringing" traffic to the exchange if the equipment (and bits) are already transported through that facility. That said, I can't get with "Capex alone is more than 10% of your cost". I see 4 port Cisco WS-6704s with 4 XENPAKs on Ebay for like $3K/port, but hey, YMMV. There is no real reason to use deep buffers as an interface to a low-cost, low latency fabric, especially when you (and the fabric) can just add ports cheaply. So I guess this is now meandering. I can present it differently. Take the most rudimentary part of the SIX model, put it in a few cities where more traffic is exchanged then Seattle, bake, then taste. Wouldn't this be far more preferable (with scale) than the "expensive" US IX ports -- especially for new [rather than existing] traffic -- and as Woodcock mentions, anyone can run it, just requires some scale to be valuable enough; and more importantly, since the effective price of coop IX traffic would be lower than current major IX traffic, wouldn't this encourage more exchange to all participants benefit? Or (back to my original post) are these costs essentially insignificant to the modern business case given the current set of market dynamics? Thanks, Deepak From deepak at ai.net Mon Aug 11 23:51:11 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 12 Aug 2008 00:51:11 -0400 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net> Message-ID: <48A116BF.5090205@ai.net> Bill Woodcock wrote: > On Mon, 11 Aug 2008, Deepak Jain wrote: > > A "coop", best-effort switch fabric colo'd at a few sites would allow > > participants to peer off traffic at a price of the order of a single > > cross-connect (~$500/month per 10G port is possible, maybe less), > > $0/month per 10G port is common enough. > > https://www.seattleix.net/faq.htm > > Why pay someone else to let you use an Ethernet switch? Presumably if > you can configure BGP, plugging into an Ethernet switch is well within > your core competency. > The only point of a fee would be to provide better than "when-we-get-around-to-it" support. Obviously there are ways to achieve this without a fee. There are other benefits too [like the ability to have a real non-profit structure, insurances, and others to address the inevitable subpoena, wire-tapping request, CNN reporter, etc]. The economization of cross-connects (a large percentage of a certain colo provider's gross revenues and profit growth) does NOT occur when each provider sets up its own L2 switch for its peers to connect to -- unless they can peer with each other over that switch too. Which brings you back to a coop. Deepak From jim at reptiles.org Tue Aug 12 02:21:00 2008 From: jim at reptiles.org (Jim Mercer) Date: Tue, 12 Aug 2008 03:21:00 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <48A10065.4060900@ai.net> References: <48A10065.4060900@ai.net> Message-ID: <20080812072100.GA56040@reptiles.org> On Mon, Aug 11, 2008 at 11:15:49PM -0400, Deepak Jain wrote: > A "coop", best-effort switch fabric colo'd at a few sites would allow > participants to peer off traffic at a price of the order of a single > cross-connect (~$500/month per 10G port is possible, maybe less), > private-VLANs all-around, or to only-mutually approved peers (e.g. via > an automated web interface, prior art) to avoid many of the /old/ > issues. No requirement for multi-lateral peering. You could peer, sell > transit, buy transit, multicast, etc. This has been working for years at http://www.torix.net , and on a smaller scale at http://www.ottix.net -- Jim Mercer jim at reptiles.org +971 55 410-5633 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From pauldotwall at gmail.com Tue Aug 12 02:37:15 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 12 Aug 2008 03:37:15 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <48A10065.4060900@ai.net> References: <48A10065.4060900@ai.net> Message-ID: <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> Deepak, If it were as easy as you make it sound, I can assure you people would be doing it. Also, does your Equinix MSA contain a non-compete clause, which could be interpreted to mean you can't run a competing IX (metro fabric, exchange, whatever) out of their facilities? I hear many do. Drive Slow, PAUL WALL On Mon, Aug 11, 2008 at 11:15 PM, Deepak Jain wrote: > Warning: This may actually be operational too. > > Given Cogent (and others) recent pursuit of sub $4/mb/s transit... and the > relatively flat cost of a "paid" peering fabric (even at 10G) and the O(N) > costs for cross-connects, the thought of revisiting the old peering coops > presented itself again. > > Assuming 10G PNI model: Assuming even nominal cross-connect fees of > $100-$300/month per fiber pair, plus router port costs for each private peer > (assuming you aren't at >10% utilization on the port) at a commercial > exchange, you are eating a pretty significant cost per megabit you are > actually moving. (plug in your numbers here). Assumption: Above 1Gb/s > utilization, this makes sense or you are counting on growth. > > Below 10% you would normally go to a paid peering fabric where you are > paying cross connect + a flat port charge + router port for 1->N peers and > hoping that enough utilization occurs that you get >10% utilization (to > recover capex, opex, etc) and then whatever additional utilization you need > to cover the flat port charge or you are counting on growth. > > A "coop", best-effort switch fabric colo'd at a few sites would allow > participants to peer off traffic at a price of the order of a single > cross-connect (~$500/month per 10G port is possible, maybe less), > private-VLANs all-around, or to only-mutually approved peers (e.g. via an > automated web interface, prior art) to avoid many of the /old/ issues. No > requirement for multi-lateral peering. You could peer, sell transit, buy > transit, multicast, etc. > > The way I figure it, it removes approximately an order of magnitude from the > operational cost of peering with more than a handful of your largest single > talkers. Especially as 100G LAN Ethernet becomes production before 100G WAN > connections become commonplace. Economic theory (assuming that worked on the > Internet) suggests this would allow for the increase in number of peers by > approximately an order of magnitude (maybe more). > > Does this actually improve the present-day "rationale" to peer, or are most > operations' costs so far above (from long haul, etc) or so far below (since > the cost of transit has dropped so much) that this is no longer a relevant > part of the equation? > > Warning: This may actually be operational too. > > Deepak Jain > AiNET > > From pfs at cisco.com Tue Aug 12 05:15:14 2008 From: pfs at cisco.com (Philip Smith) Date: Tue, 12 Aug 2008 20:15:14 +1000 Subject: [NANOG-announce] Call for Nominations for NANOG Steering Committee 2008/9 Message-ID: <48A162B2.3000806@cisco.com> Hello everyone, Elections for three of the six elected positions on the NANOG Steering Committee will be held in October 2008. The currently-serving Steering Committee members whose terms are expiring are Joe Provo, Randy Bush and Philip Smith. Randy and Philip have also served two consecutive terms so, as per the charter, they cannot be considered for re-election until October 2009. The NANOG Steering Committee works closely with Merit to promote, support and improve NANOG. The Steering Committee is responsible for the selection of the Program Committee and the Mailing List Committee, and is the community's instrument for ensuring that NANOG as an organisation remains open, relevant and useful. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being an Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/charter.html http://www.nanog.org/sc.current.html HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations at nanog.org. The candidates will be given an opportunity to make brief comments and/or accept questions from the community at the NANOG44 Community Meeting, Sunday, October 12th, beginning at 5:30 PM, PDT. IMPORTANT DATES Tue 2008-08-12 Call for Nominations issued Tue 2008-09-09 Last day for SC Nominations to be received Sun 2008-10-12 Voting for the 2008/2008 NANOG SC opens at Noon PDT Tue 2008-10-14 Voting for the 2008/2009 NANOG SC closes at 1 pm PDT Results will be announced at the close of the meeting Philip Smith (on behalf of the NANOG Steering Committee) -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From list-nanog at pwns.ms Tue Aug 12 06:36:49 2008 From: list-nanog at pwns.ms (list-nanog at pwns.ms) Date: Tue, 12 Aug 2008 11:36:49 +0000 Subject: impossible circuit In-Reply-To: References: Message-ID: <20080812113649.GA4984@pwns.ms> Are dups generated on traffic going over that DS3 from (rather than to) the Ocala side? Does the DS3 cross Sprint's network? > Then we noticed the really weird stuff. Pings to anything in Ocala > responded with multiple dupes and ttl exceeded messages from a Level3 IP. > Traceroutes to certain IPs in Ocala would get as far our Ocala router, > then inexplicably hop onto Sprintlink's network, come back to us over our > Level3 transit connection, get to Ocala, then hop over to Sprintlink > again, repeating that loop as many times as max TTL would permit. Pings > from router to router crossing just the DS3 would work, but we'd see 10 > duplicate packets for every 1 expected packet. BTW, the cisco CLI hides > dupes unless you turn on ip icmp debugging. What would happen if you pinged the Ocala router such that the TTL was 1 when travelling over the DS3? From your traceroute it seems it travelled two IP hops that did not send ICMP error messages, but it might just be that the ICMP errors from the Ocala router are arriving first. > traffic was actually jumping off our network and coming back in via > Level3, I could see/block at least some of that using an ACL on our > interface to Level3. How do you explain it, when you ping the remote end > of a DS3 interface with a single echo request packet and see 5 copies of > that echo request arrive at one of your transit provider interfaces? Just clarifying: 5 duplicates were being generated for every packet that crossed the DS3, not just 1 packet that looped causing 5 duplicates? > Here's a typical traceroute with the first few hops (from my home internet > connection) removed. BTW, hop 9 is a customer router conveniently > configured with no ip unreachables. > 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms > 56.154 ms > 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 ms > 56.196 ms > 9 * * * > 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 ms > 81.821 ms Was the first visibile IP hop of the dups always that Sprint router? > If someone from Level3 transport can wrap their head around this, I'd love > to know what's really going on...but at least it's no longer an urgent > problem for me. Level3 is your circuit provider? From patrick at ianai.net Tue Aug 12 07:32:16 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Aug 2008 08:32:16 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> Message-ID: <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> On Aug 12, 2008, at 3:37 AM, Paul Wall wrote: > If it were as easy as you make it sound, I can assure you people would > be doing it. People are. I (and others) mentioned SIX & TorIX, plus I mentioned PaNAP. Then there's AtlantaIX, although that recently got slurped by TelX. (Hrmmm, could one of the "dangers" of a coop be "borg'ed by for- profit entity looking to rip out every cent they can"? :) Tons of others exist, in big and little markets. There's one in 365 Main SF, there's KleyReX in the same building as DE-CIX, Big APE in 111 8th, NYCx there too, ChicagoIX just opened, etc., etc. Trust me, it _is_ being done. > Also, does your Equinix MSA contain a non-compete clause, which could > be interpreted to mean you can't run a competing IX (metro fabric, > exchange, whatever) out of their facilities? I hear many do. So don't run it in an Equinix or S&D cage. -- TTFN, patrick > On Mon, Aug 11, 2008 at 11:15 PM, Deepak Jain wrote: >> Warning: This may actually be operational too. >> >> Given Cogent (and others) recent pursuit of sub $4/mb/s transit... >> and the >> relatively flat cost of a "paid" peering fabric (even at 10G) and >> the O(N) >> costs for cross-connects, the thought of revisiting the old peering >> coops >> presented itself again. >> >> Assuming 10G PNI model: Assuming even nominal cross-connect fees of >> $100-$300/month per fiber pair, plus router port costs for each >> private peer >> (assuming you aren't at >10% utilization on the port) at a commercial >> exchange, you are eating a pretty significant cost per megabit you >> are >> actually moving. (plug in your numbers here). Assumption: Above 1Gb/s >> utilization, this makes sense or you are counting on growth. >> >> Below 10% you would normally go to a paid peering fabric where you >> are >> paying cross connect + a flat port charge + router port for 1->N >> peers and >> hoping that enough utilization occurs that you get >10% utilization >> (to >> recover capex, opex, etc) and then whatever additional utilization >> you need >> to cover the flat port charge or you are counting on growth. >> >> A "coop", best-effort switch fabric colo'd at a few sites would allow >> participants to peer off traffic at a price of the order of a single >> cross-connect (~$500/month per 10G port is possible, maybe less), >> private-VLANs all-around, or to only-mutually approved peers (e.g. >> via an >> automated web interface, prior art) to avoid many of the /old/ >> issues. No >> requirement for multi-lateral peering. You could peer, sell >> transit, buy >> transit, multicast, etc. >> >> The way I figure it, it removes approximately an order of magnitude >> from the >> operational cost of peering with more than a handful of your >> largest single >> talkers. Especially as 100G LAN Ethernet becomes production before >> 100G WAN >> connections become commonplace. Economic theory (assuming that >> worked on the >> Internet) suggests this would allow for the increase in number of >> peers by >> approximately an order of magnitude (maybe more). >> >> Does this actually improve the present-day "rationale" to peer, or >> are most >> operations' costs so far above (from long haul, etc) or so far >> below (since >> the cost of transit has dropped so much) that this is no longer a >> relevant >> part of the equation? >> >> Warning: This may actually be operational too. >> >> Deepak Jain >> AiNET >> >> > From alex at nac.net Tue Aug 12 08:06:33 2008 From: alex at nac.net (Alex Rubenstein) Date: Tue, 12 Aug 2008 09:06:33 -0400 Subject: Comcast Tech? Message-ID: <000601c8fc7c$3e81d720$bb858560$@net> I am looking for a Comcast tech to help us solve what may be a simple issue. Normal channels have failed. Find me at alex at nac.net please .. thanks! From mike at smashing.net Tue Aug 12 08:28:25 2008 From: mike at smashing.net (Mike Hughes) Date: Tue, 12 Aug 2008 14:28:25 +0100 Subject: Coop Peering Fabric?? In-Reply-To: <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> --On 12 August 2008 08:32 -0400 "Patrick W. Gilmore" wrote: > People are. I (and others) mentioned SIX & TorIX, plus I mentioned > PaNAP. Then there's AtlantaIX, although that recently got slurped by > TelX. (Hrmmm, could one of the "dangers" of a coop be "borg'ed by > for-profit entity looking to rip out every cent they can"? :) Interesting point. Speaking from experience for a minute, firstly one would hope that the co-op members would have to majority vote (hopefully with a reasonable margin) in favour of the borging to happen. If the members of the co-op value it's existence and the services they get from the co-op, they won't vote in favour of a blatantly commercial offer. There is always the threat of the wolf in sheep's clothing, though. One option to avoid that situation, or one where "Turkeys vote for Christmas" (or Thanksgiving, given this is NANOG) could be to put a "poison pill" into whatever legal basis the co-op has, e.g. in the Mem & Arts, to basically kill the thing off if someone tries to carpetbag it. I remember Kurtis telling me about some similar provision in the Foundation which runs Netnod in Sweden, to avoid capture of the organisation. Mike (no hat) From davediaz at gmail.com Tue Aug 12 08:56:17 2008 From: davediaz at gmail.com (David Diaz) Date: Tue, 12 Aug 2008 09:56:17 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: <6A2A03F9-87F8-4880-BD83-FF08552E5EB4@gmail.com> Patrick Love the Borg comment. Great thread. Old topic. It recycles every couple of years. Not to speak for telx or Mike L but I do not think anyone was motivated to Borg anything but to support AIX. 10Gig ports are expensive. I like the idea of more exchange points in that they usually provide more recovery pts and redundancy, allow the sharing of skills and knowledge in the local community, and provide flexibility for growth and change of the internet. How many COs do we have? There has long been the argument of how many IXs are needed, would it be 1 per state? What happens with Voip, IPtv etc. As for coops I think the argument is would the larger traffic players feel comfortable connecting and making it a part of their networks? Who are the anchors and 1st movers? What are the guarantees that any investment in infrastructure needed to get there will be recovered over X years... Will the coop fold before that pt? Wll it have the resources to upgrade. I so not think a poison pill is needed. Perhaps just a group or company championing Coops and giving them booth-space at events, sponsoring conference travels, providing rack space etc. But if it's in the BEST interest of the members to have a larger group come in and take over then what is the harm? What is the alternative, have members pay membership fees? Corp Sponsorship? I agree on much of this. But as with most things it comes down to money. Do members have a financial incentive to join and what is the financial model to keep the Coop moving forward as a success. David D On Aug 12, 2008, at 8:32 AM, Patrick W. Gilmore wrote: > On Aug 12, 2008, at 3:37 AM, Paul Wall wrote: > >> If it were as easy as you make it sound, I can assure you people >> would >> be doing it. > > People are. I (and others) mentioned SIX & TorIX, plus I mentioned > PaNAP. Then there's AtlantaIX, although that recently got slurped > by TelX. (Hrmmm, could one of the "dangers" of a coop be "borg'ed > by for-profit entity looking to rip out every cent they can"? :) > > Tons of others exist, in big and little markets. There's one in 365 > Main SF, there's KleyReX in the same building as DE-CIX, Big APE in > 111 8th, NYCx there too, ChicagoIX just opened, etc., etc. > > Trust me, it _is_ being done. > > >> Also, does your Equinix MSA contain a non-compete clause, which could >> be interpreted to mean you can't run a competing IX (metro fabric, >> exchange, whatever) out of their facilities? I hear many do. > > So don't run it in an Equinix or S&D cage. > > -- > TTFN, > patrick > > >> On Mon, Aug 11, 2008 at 11:15 PM, Deepak Jain wrote: >>> Warning: This may actually be operational too. >>> >>> Given Cogent (and others) recent pursuit of sub $4/mb/s transit... >>> and the >>> relatively flat cost of a "paid" peering fabric (even at 10G) and >>> the O(N) >>> costs for cross-connects, the thought of revisiting the old >>> peering coops >>> presented itself again. >>> >>> Assuming 10G PNI model: Assuming even nominal cross-connect fees of >>> $100-$300/month per fiber pair, plus router port costs for each >>> private peer >>> (assuming you aren't at >10% utilization on the port) at a >>> commercial >>> exchange, you are eating a pretty significant cost per megabit you >>> are >>> actually moving. (plug in your numbers here). Assumption: Above >>> 1Gb/s >>> utilization, this makes sense or you are counting on growth. >>> >>> Below 10% you would normally go to a paid peering fabric where you >>> are >>> paying cross connect + a flat port charge + router port for 1->N >>> peers and >>> hoping that enough utilization occurs that you get >10% >>> utilization (to >>> recover capex, opex, etc) and then whatever additional utilization >>> you need >>> to cover the flat port charge or you are counting on growth. >>> >>> A "coop", best-effort switch fabric colo'd at a few sites would >>> allow >>> participants to peer off traffic at a price of the order of a single >>> cross-connect (~$500/month per 10G port is possible, maybe less), >>> private-VLANs all-around, or to only-mutually approved peers (e.g. >>> via an >>> automated web interface, prior art) to avoid many of the /old/ >>> issues. No >>> requirement for multi-lateral peering. You could peer, sell >>> transit, buy >>> transit, multicast, etc. >>> >>> The way I figure it, it removes approximately an order of >>> magnitude from the >>> operational cost of peering with more than a handful of your >>> largest single >>> talkers. Especially as 100G LAN Ethernet becomes production before >>> 100G WAN >>> connections become commonplace. Economic theory (assuming that >>> worked on the >>> Internet) suggests this would allow for the increase in number of >>> peers by >>> approximately an order of magnitude (maybe more). >>> >>> Does this actually improve the present-day "rationale" to peer, or >>> are most >>> operations' costs so far above (from long haul, etc) or so far >>> below (since >>> the cost of transit has dropped so much) that this is no longer a >>> relevant >>> part of the equation? >>> >>> Warning: This may actually be operational too. >>> >>> Deepak Jain >>> AiNET >>> >>> >> > > From davediaz.tech at gmail.com Tue Aug 12 08:58:57 2008 From: davediaz.tech at gmail.com (David Diaz) Date: Tue, 12 Aug 2008 09:58:57 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> Message-ID: Patrick Love the Borg comment. Great thread. Old topic. It recycles every couple of years. Not to speak for telx or Mike L but I do not think anyone was motivated to Borg anything but to support AIX. 10Gig ports are expensive. I like the idea of more exchange points in that they usually provide more recovery pts and redundancy, allow the sharing of skills and knowledge in the local community, and provide flexibility for growth and change of the internet. How many COs do we have? There has long been the argument of how many IXs are needed, would it be 1 per state? What happens with Voip, IPtv etc. As for coops I think the argument is would the larger traffic players feel comfortable connecting and making it a part of their networks? Who are the anchors and 1st movers? What are the guarantees that any investment in infrastructure needed to get there will be recovered over X years... Will the coop fold before that pt? Wll it have the resources to upgrade. I so not think a poison pill is needed. Perhaps just a group or company championing Coops and giving them booth-space at events, sponsoring conference travels, providing rack space etc. But if it's in the BEST interest of the members to have a larger group come in and take over then what is the harm? What is the alternative, have members pay membership fees? Corp Sponsorship? I agree on much of this. But as with most things it comes down to money. Do members have a financial incentive to join and what is the financial model to keep the Coop moving forward as a success. David D On Aug 12, 2008, at 8:32 AM, Patrick W. Gilmore wrote: On Aug 12, 2008, at 3:37 AM, Paul Wall wrote: If it were as easy as you make it sound, I can assure you people would be doing it. People are. I (and others) mentioned SIX & TorIX, plus I mentioned PaNAP. Then there's AtlantaIX, although that recently got slurped by TelX. (Hrmmm, could one of the "dangers" of a coop be "borg'ed by for-profit entity looking to rip out every cent they can"? :) Tons of others exist, in big and little markets. There's one in 365 Main SF, there's KleyReX in the same building as DE-CIX, Big APE in 111 8th, NYCx there too, ChicagoIX just opened, etc., etc. Trust me, it _is_ being done. Also, does your Equinix MSA contain a non-compete clause, which could be interpreted to mean you can't run a competing IX (metro fabric, exchange, whatever) out of their facilities? I hear many do. So don't run it in an Equinix or S&D cage. -- TTFN, patrick On Mon, Aug 11, 2008 at 11:15 PM, Deepak Jain wrote: Warning: This may actually be operational too. Given Cogent (and others) recent pursuit of sub $4/mb/s transit... and the relatively flat cost of a "paid" peering fabric (even at 10G) and the O(N) costs for cross-connects, the thought of revisiting the old peering coops presented itself again. Assuming 10G PNI model: Assuming even nominal cross-connect fees of $100-$300/month per fiber pair, plus router port costs for each private peer (assuming you aren't at >10% utilization on the port) at a commercial exchange, you are eating a pretty significant cost per megabit you are actually moving. (plug in your numbers here). Assumption: Above 1Gb/s utilization, this makes sense or you are counting on growth. Below 10% you would normally go to a paid peering fabric where you are paying cross connect + a flat port charge + router port for 1->N peers and hoping that enough utilization occurs that you get >10% utilization (to recover capex, opex, etc) and then whatever additional utilization you need to cover the flat port charge or you are counting on growth. A "coop", best-effort switch fabric colo'd at a few sites would allow participants to peer off traffic at a price of the order of a single cross-connect (~$500/month per 10G port is possible, maybe less), private-VLANs all-around, or to only-mutually approved peers (e.g. via an automated web interface, prior art) to avoid many of the /old/ issues. No requirement for multi-lateral peering. You could peer, sell transit, buy transit, multicast, etc. The way I figure it, it removes approximately an order of magnitude from the operational cost of peering with more than a handful of your largest single talkers. Especially as 100G LAN Ethernet becomes production before 100G WAN connections become commonplace. Economic theory (assuming that worked on the Internet) suggests this would allow for the increase in number of peers by approximately an order of magnitude (maybe more). Does this actually improve the present-day "rationale" to peer, or are most operations' costs so far above (from long haul, etc) or so far below (since the cost of transit has dropped so much) that this is no longer a relevant part of the equation? Warning: This may actually be operational too. Deepak Jain AiNET From patrick at ianai.net Tue Aug 12 09:11:13 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Aug 2008 10:11:13 -0400 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> Message-ID: <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> On Aug 12, 2008, at 9:58 AM, David Diaz wrote: > Love the Borg comment. Thanx. > Great thread. Old topic. It recycles every couple of years. Not > to speak > for telx or Mike L but I do not think anyone was motivated to Borg > anything > but to support AIX. 10Gig ports are expensive. > > I like the idea of more exchange points in that they usually provide > more > recovery pts and redundancy, allow the sharing of skills and > knowledge in > the local community, and provide flexibility for growth and change > of the > internet. How many COs do we have? There has long been the argument > of how > many IXs are needed, would it be 1 per state? What happens with > Voip, IPtv > etc. > > As for coops I think the argument is would the larger traffic > players feel > comfortable connecting and making it a part of their networks? Who > are the > anchors and 1st movers? What are the guarantees that any investment > in > infrastructure needed to get there will be recovered over X years... > Will > the coop fold before that pt? Wll it have the resources to upgrade. Who said anything about larger traffic players? What's wrong with a bunch of little guys getting together to trade traffic, for fun and profit? The smaller guys might have a better focus on performance in the local area (gamers anyone?), plus they tend to pay more per Mbps because they don't have scale, which makes moving a little traffic off more economical. All that said, Akamai is a pretty big network and they're present at a lot of these "small" IXen. Ditto for local eyeball networks, e.g. Shaw @ SIX, Rogers @ TorIX, etc. > I so not think a poison pill is needed. Perhaps just a group or > company > championing Coops and giving them booth-space at events, sponsoring > conference travels, providing rack space etc. But if it's in the BEST > interest of the members to have a larger group come in and take over > then > what is the harm? What is the alternative, have members pay > membership fees? > Corp Sponsorship? > > I agree on much of this. But as with most things it comes down to > money. Do > members have a financial incentive to join and what is the financial > model > to keep the Coop moving forward as a success. Several small IXes have grown quite a bit with no or very small membership fees. Look at the ones I mentioned. I think SIX is the largest, but they're all not that tiny. -- TTFN, patrick From davediaz.tech at gmail.com Tue Aug 12 09:23:43 2008 From: davediaz.tech at gmail.com (David Diaz) Date: Tue, 12 Aug 2008 10:23:43 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> Message-ID: Yes you are absolutely correct. Smaller players doing this for fun and experimentation if not only a good idea, I believe it is critical for the internet to grow and change. Ask UUNET how long it takes them to get approval to implement something big....or even small. Two pts thought. First, the cross connects at most of these locations are still going to be a major monthly INVESTMENT unless the colo provider gets involved. As was stated earlier $500 MRC has to be justified be costs savings or other benefits. Second, I have heard a lot of talk about SIX over the last year or so and there is no guarantees that situation won't change. Telx and others can do a fine job. I have not heard Any2 mentioned and their traffic levels have been very good while keeping ports cost effective. Can that model scale? Basically it's about the community deciding to support something. Perhaps it's more about the players then the best model. This business is still run significantly on trust and reputation of the people running the infrastructure. No? David On Tue, Aug 12, 2008 at 10:11 AM, Patrick W. Gilmore wrote: > On Aug 12, 2008, at 9:58 AM, David Diaz wrote: > > Love the Borg comment. >> > > Thanx. > > > Great thread. Old topic. It recycles every couple of years. Not to >> speak >> for telx or Mike L but I do not think anyone was motivated to Borg >> anything >> but to support AIX. 10Gig ports are expensive. >> >> I like the idea of more exchange points in that they usually provide more >> recovery pts and redundancy, allow the sharing of skills and knowledge in >> the local community, and provide flexibility for growth and change of the >> internet. How many COs do we have? There has long been the argument of how >> many IXs are needed, would it be 1 per state? What happens with Voip, >> IPtv >> etc. >> >> As for coops I think the argument is would the larger traffic players feel >> comfortable connecting and making it a part of their networks? Who are >> the >> anchors and 1st movers? What are the guarantees that any investment in >> infrastructure needed to get there will be recovered over X years... Will >> the coop fold before that pt? Wll it have the resources to upgrade. >> > > Who said anything about larger traffic players? What's wrong with a bunch > of little guys getting together to trade traffic, for fun and profit? > > The smaller guys might have a better focus on performance in the local area > (gamers anyone?), plus they tend to pay more per Mbps because they don't > have scale, which makes moving a little traffic off more economical. > > All that said, Akamai is a pretty big network and they're present at a lot > of these "small" IXen. Ditto for local eyeball networks, e.g. Shaw @ SIX, > Rogers @ TorIX, etc. > > > I so not think a poison pill is needed. Perhaps just a group or company >> championing Coops and giving them booth-space at events, sponsoring >> conference travels, providing rack space etc. But if it's in the BEST >> interest of the members to have a larger group come in and take over then >> what is the harm? What is the alternative, have members pay membership >> fees? >> Corp Sponsorship? >> >> I agree on much of this. But as with most things it comes down to money. >> Do >> members have a financial incentive to join and what is the financial model >> to keep the Coop moving forward as a success. >> > > Several small IXes have grown quite a bit with no or very small membership > fees. Look at the ones I mentioned. I think SIX is the largest, but > they're all not that tiny. > > -- > TTFN, > patrick > > > From jlewis at lewis.org Tue Aug 12 09:37:41 2008 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 12 Aug 2008 10:37:41 -0400 (EDT) Subject: impossible circuit In-Reply-To: <20080812113649.GA4984@pwns.ms> References: <20080812113649.GA4984@pwns.ms> Message-ID: On Tue, 12 Aug 2008 list-nanog at pwns.ms wrote: > Are dups generated on traffic going over that DS3 from (rather than to) > the Ocala side? The dupes are only generated in the Orlando->Ocala direction. > Does the DS3 cross Sprint's network? The DS3 enters an Embarq (the telco formerly known as Sprint) central office. AFAIK, the only portion of the circuit handled by Embarq is where it's handed to them in the CO where our gear is colo'd. > What would happen if you pinged the Ocala router such that the TTL was 1 > when travelling over the DS3? From your traceroute it seems it travelled > two IP hops that did not send ICMP error messages, but it might just be > that the ICMP errors from the Ocala router are arriving first. Based on where the dupes are coming from, I assume pinging across the DS3 with TTL tuned to expire at the Ocala side would result in TTL exceeded messages from both Ocala and the Sprint router where the packets are injected into Sprint's network. It doesn't look as if IOS gives the option to set TTL on ping...so I'd try this from a Linux machine in our data center. >> traffic was actually jumping off our network and coming back in via >> Level3, I could see/block at least some of that using an ACL on our >> interface to Level3. How do you explain it, when you ping the remote end >> of a DS3 interface with a single echo request packet and see 5 copies of >> that echo request arrive at one of your transit provider interfaces? > > Just clarifying: 5 duplicates were being generated for every packet that > crossed the DS3, not just 1 packet that looped causing 5 duplicates? Yes. With the ACL on our Level3 transit, I blocked 5 dupes for each echo request sent from the Orlando end of the DS3 to the Ocala end. >> 9 * * * >> 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 ms >> 81.821 ms > > Was the first visibile IP hop of the dups always that Sprint router? No. That's one of the wild things about it. Depending on who's network you trace from (we did traces from a bunch of route servers and looking glasses. Some traces would show a pair of private IP hops before the Sprintlink IPs. Some would simply show a different Sprint router as the first off-net hop. If I break it again some night, I'll collect a few different examples. > Level3 is your circuit provider? Yes. Originally it was a Progress Telecom circuit...but Level3 borged them. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jim at reptiles.org Tue Aug 12 10:09:00 2008 From: jim at reptiles.org (Jim Mercer) Date: Tue, 12 Aug 2008 11:09:00 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> Message-ID: <20080812150900.GA83761@reptiles.org> On Tue, Aug 12, 2008 at 10:11:13AM -0400, Patrick W. Gilmore wrote: > Several small IXes have grown quite a bit with no or very small > membership fees. Look at the ones I mentioned. I think SIX is the > largest, but they're all not that tiny. TorIX, for many years, was financed by announcing an upcoming expediture, and waiting to see if one of the members stepped up (or usually, the member suggesting the expenditure, also covering its cost), and if no-one was willing to foot the entire bill, the hat was passed around until it filled sufficiently. they have since formalized into a not-for-profit (i stepped away, physically and involvement-wise), but my understanding is that financially, it is using the same funding model. TorIX was initially founded by driving a stake (a single Cisco 2900 as i recall) in the ground and inviting all-comers (each having to simply pay to drag connectivity to the stake). the initial membership was small to medium (quasi-large) ISP's, the largest of which were finding they were locked out of the incumbent IX (CanIX) for various financial and political reasons. (that CanIX appears to have vaporized, and its name now taken by some colo provider) some joined for monetary reasons, some for the fun of it, others because it became a cost effective way to shunt packets (even when weighed against the "best-effort" management) TorIX is now sustaining 10Gbps across some 90+ peers, with a decent spectrum of eyeballs, content-only providers and transit providers. i would bet that if someone analyzed the data, that it has maintained 5 9's reliability too, or pretty damn close for a best-effort facility. -- Jim Mercer jim at reptiles.org +971 55 410-5633 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From westligh at ohsu.edu Tue Aug 12 10:27:12 2008 From: westligh at ohsu.edu (Donald J Westlight) Date: Tue, 12 Aug 2008 08:27:12 -0700 Subject: Coop Exchange In-Reply-To: References: Message-ID: <46A6D734CC57E541A13EBB0AA7BEA01D359CB2@EX-BE08.ohsu.edu> The main argument for an exchange is qualitative. Do you want your bits to get where they are going with low latency, jitter, and packet loss? Exchanges are a very practical way to solve the N squared peering problem. Speaking as a founder of a small exchange; it does all come down to money. Quality hardware is expensive, and combining this with the OPEX for co-lo/power, etc. starts to get a bill on the order of $500/mo/gigE port. In my experience, the larger the company, the less likely they will be willing to pay anything to support a shared peering fabric (at least in my market.) Our membership tends to be regional players who are used to cooperating already, and together start to approximate the capability of one of the big carriers. Exchange membership also jumpstarts business with larger carriers when they arrive. I just toured the SIX last month, and I?m really impressed by their operation. Everybody has costs. I am particularly interested in what NANOG would consider fair, and on top of that whether or not a quorum would actually pay. I am particularly concerned that the "race to the bottom" describes cost and quality, as well as limitation of new application development and deployment... If you guys have a blueprint for a community or coop exchange that you'd subscribe to, I strongly suspect that it would happen. I'm happy to talk more about this off list with anybody interested. Don Westlight NWAX.NET, est 2001 Portland Oregon 921 SW Washington 22 Members 1.3gb daily max westligh at ohsu.edu From jgreco at ns.sol.net Tue Aug 12 10:31:35 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 12 Aug 2008 10:31:35 -0500 (CDT) Subject: Coop Peering Fabric?? In-Reply-To: <48A1157F.2090506@ai.net> from "Deepak Jain" at Aug 12, 2008 12:45:51 AM Message-ID: <200808121531.m7CFVZac079620@aurora.sol.net> > I guess they would be more interesting deployed in Ashburn or some place > similar because you could exclude the cost of "bringing" traffic to the > exchange if the equipment (and bits) are already transported through > that facility. Certainly there are some of us who would see this as advantageous. The cost of going through the Equinix public switch is relatively high, high enough that at the point we could justify it, it's cheaper and easier to just run a private connection or ten, and have more peering capacity, which turns into an argument against the Equinix service. Were it just the cost of a cross-connect plus a modest membership fee, with at least some other participants that had a relatively open peering policy, it would be quite interesting. Bonus points for being able to buy transit or routes. I had been working towards doing something like this in the Milwaukee area years ago, but the volume and interest wasn't quite there. I can't easily see it failing in the same way in Ashburn... there are a bunch of people who we exchange traffic with that are in the XXMbps range, maybe not enough to justify a private cross connect, but certainly good enough for a shared switch. ... 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 dhetzel at gmail.com Tue Aug 12 10:47:47 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Tue, 12 Aug 2008 10:47:47 -0500 Subject: Coop Peering Fabric?? In-Reply-To: <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: <2ee691ff0808120847vcb83a56k424cfea8eb68830f@mail.gmail.com> Speaking of AtlantaIX, the new business model seems less attractive for customers than the old one. Can anyone speak to why it got sold? Was it failing financially or someone just wanted to cash out? On 8/12/08, Patrick W. Gilmore wrote: > > On Aug 12, 2008, at 3:37 AM, Paul Wall wrote: > > If it were as easy as you make it sound, I can assure you people would >> be doing it. >> > > People are. I (and others) mentioned SIX & TorIX, plus I mentioned PaNAP. > Then there's AtlantaIX, although that recently got slurped by TelX. > (Hrmmm, could one of the "dangers" of a coop be "borg'ed by for-profit > entity looking to rip out every cent they can"? :) > > Tons of others exist, in big and little markets. There's one in 365 Main > SF, there's KleyReX in the same building as DE-CIX, Big APE in 111 8th, NYCx > there too, ChicagoIX just opened, etc., etc. > > Trust me, it _is_ being done. > > > Also, does your Equinix MSA contain a non-compete clause, which could >> be interpreted to mean you can't run a competing IX (metro fabric, >> exchange, whatever) out of their facilities? I hear many do. >> > > So don't run it in an Equinix or S&D cage. > > -- > TTFN, > patrick > > > On Mon, Aug 11, 2008 at 11:15 PM, Deepak Jain wrote: >> >>> Warning: This may actually be operational too. >>> >>> Given Cogent (and others) recent pursuit of sub $4/mb/s transit... and >>> the >>> relatively flat cost of a "paid" peering fabric (even at 10G) and the >>> O(N) >>> costs for cross-connects, the thought of revisiting the old peering coops >>> presented itself again. >>> >>> Assuming 10G PNI model: Assuming even nominal cross-connect fees of >>> $100-$300/month per fiber pair, plus router port costs for each private >>> peer >>> (assuming you aren't at >10% utilization on the port) at a commercial >>> exchange, you are eating a pretty significant cost per megabit you are >>> actually moving. (plug in your numbers here). Assumption: Above 1Gb/s >>> utilization, this makes sense or you are counting on growth. >>> >>> Below 10% you would normally go to a paid peering fabric where you are >>> paying cross connect + a flat port charge + router port for 1->N peers >>> and >>> hoping that enough utilization occurs that you get >10% utilization (to >>> recover capex, opex, etc) and then whatever additional utilization you >>> need >>> to cover the flat port charge or you are counting on growth. >>> >>> A "coop", best-effort switch fabric colo'd at a few sites would allow >>> participants to peer off traffic at a price of the order of a single >>> cross-connect (~$500/month per 10G port is possible, maybe less), >>> private-VLANs all-around, or to only-mutually approved peers (e.g. via an >>> automated web interface, prior art) to avoid many of the /old/ issues. No >>> requirement for multi-lateral peering. You could peer, sell transit, buy >>> transit, multicast, etc. >>> >>> The way I figure it, it removes approximately an order of magnitude from >>> the >>> operational cost of peering with more than a handful of your largest >>> single >>> talkers. Especially as 100G LAN Ethernet becomes production before 100G >>> WAN >>> connections become commonplace. Economic theory (assuming that worked on >>> the >>> Internet) suggests this would allow for the increase in number of peers >>> by >>> approximately an order of magnitude (maybe more). >>> >>> Does this actually improve the present-day "rationale" to peer, or are >>> most >>> operations' costs so far above (from long haul, etc) or so far below >>> (since >>> the cost of transit has dropped so much) that this is no longer a >>> relevant >>> part of the equation? >>> >>> Warning: This may actually be operational too. >>> >>> Deepak Jain >>> AiNET >>> >>> >>> >> > > From charles at thewybles.com Tue Aug 12 11:10:26 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 12 Aug 2008 09:10:26 -0700 Subject: BGP route filtering. You want it. In-Reply-To: <2e9d8ae50808111636l287707b0vf38cbd3ac3bde4e6@mail.gmail.com> References: <2e9d8ae50808111347o39d13ef7n5704be5f1fefef35@mail.gmail.com> <2e9d8ae50808111636l287707b0vf38cbd3ac3bde4e6@mail.gmail.com> Message-ID: <48A1B5F2.9060205@thewybles.com> Anton Kapela wrote: > URL works again. I had uploaded an edited version of the talk, but > forgot to rename it. It's probably good that only a few of you saw the > original, as it wasn't quite the 'professional' text that I'd > typically write. Permissible and desired presentation formats and > language at DEFCON don't have parallels in this venue. > Hmmm. I don't know about that. I saw some very good presentations at DefCon. In particular the Tor presentations, nmap presentation, and a couple wireless talks I went to were all quite professionally and tastefully done. Oh the Web Application Firewall stuff was good too. -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From patrick at ianai.net Tue Aug 12 11:37:13 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Aug 2008 12:37:13 -0400 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> Message-ID: <2E4AC4E7-D402-4927-8239-BA56AFA2EB91@ianai.net> On Aug 12, 2008, at 10:23 AM, David Diaz wrote: > Second, I have heard a lot of talk about SIX over the last year or > so and there is no guarantees that situation won't change. As a board member of SIX, I can tell you that we are not going away any time soon. -- TTFN, patrick From robert at ufl.edu Tue Aug 12 11:40:58 2008 From: robert at ufl.edu (Robert D. Scott) Date: Tue, 12 Aug 2008 12:40:58 -0400 Subject: Comcast Gets FCC Slap on Wrist In-Reply-To: <2E4AC4E7-D402-4927-8239-BA56AFA2EB91@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <1BD9ECEC09422FF4BD0223F6@MIKE-LAPTOP.dyn.se1.linx.net> <6B0D2E9F-7CDF-45C3-8633-EF2D9B94F2A6@ianai.net> <2E4AC4E7-D402-4927-8239-BA56AFA2EB91@ianai.net> Message-ID: <006001c8fc9a$32dfccb0$989f6610$@edu> http://www.networkworld.com/newsletters/frame/2008/081108wan1.html 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 321-663-0421 Cell From andy at nosignal.org Tue Aug 12 14:13:32 2008 From: andy at nosignal.org (Andy Davidson) Date: Tue, 12 Aug 2008 20:13:32 +0100 Subject: Coop Peering Fabric?? In-Reply-To: <48A10065.4060900@ai.net> References: <48A10065.4060900@ai.net> Message-ID: <90C70AC0-0B12-4216-8F65-E3155BE0D44F@nosignal.org> On 12 Aug 2008, at 04:15, Deepak Jain wrote: > A "coop", best-effort switch fabric colo'd at a few sites would > allow participants to peer off traffic at a price of the order of a > single cross-connect (~$500/month per 10G port is possible, maybe > less) Most of the Internet Exchanges in Europe that quickly spring to mind as successful, are run as co-operative entities, similar to what you describe. Specifically, most (all?) of the larger ones over here run as independent bodies that are owned mutually -- that is to say, owned by all of the participators at the exchange. The model is popular, and many hundreds of GB/s of traffic is exchanged on switches run by mutual organisations in Europe. This works really well because it means there is no commercial/profit motivation to operate significantly above cost-recovery levels. Here, costs mean the CapEx, OpEx, and any community/member sanctioned projects. Where it breaks is when we have to tell a network with lots of traffic that in order to participate at the exchange, they have to become a member (part owner) of the organisation. Due to organisational or even regulatory issues, it may not be legal to sell services (exchange ports) to non members/owners. This doesn't frighten the engineer asking for a connection, but it causes some concern at C*O level ("err, I might have to declare this to shareholders/regulators...") I think my message to you would be that if you have a bunch of colleagues at other organisations near you that want to start peering ... configure a switch, peer, and take it from there as you grow ! I hope your new exchange is successful ! Best wishes Andy Davidson Declared hat - www.lonap.net (London, UK based mutual IX) From woody at pch.net Tue Aug 12 11:32:55 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 12 Aug 2008 09:32:55 -0700 (PDT) Subject: Coop Peering Fabric?? In-Reply-To: <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: On Tue, 12 Aug 2008, Patrick W. Gilmore wrote: > Could one of the "dangers" of a coop be "borg'ed by for-profit > entity looking to rip out every cent they can"? That's one of the reasons many of them incorporate as non-profits... Under the tax laws of most countries, the U.S. and Canada included, non-profits are legaly protected against acquisition by for-profits. -Bill From repstein at chello.at Tue Aug 12 15:30:51 2008 From: repstein at chello.at (Randy Epstein) Date: Tue, 12 Aug 2008 16:30:51 -0400 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net><620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com><62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: <7BD64A18DDB64CE4B944D5F0FBC6AED9@D88CFA77634F40F> > That's one of the reasons many of them incorporate as non-profits... > Under the tax laws of most countries, the U.S. and Canada included, > non-profits are legaly protected against acquisition by for-profits. > -Bill Yes, but it's somewhat easy to convert from non-profit to for-profit anyhow. Hospitals do it all the time. Randy From hannigan at verneglobal.com Tue Aug 12 15:32:26 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 12 Aug 2008 20:32:26 -0000 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net><620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com><62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: > -----Original Message----- > From: Bill Woodcock [mailto:woody at pch.net] > Sent: Tuesday, August 12, 2008 12:33 PM > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: Coop Peering Fabric?? > > On Tue, 12 Aug 2008, Patrick W. Gilmore wrote: > > Could one of the "dangers" of a coop be "borg'ed by for-profit > > entity looking to rip out every cent they can"? > > That's one of the reasons many of them incorporate as non-profits... > Under the tax laws of most countries, the U.S. and Canada included, > non-profits are legaly protected against acquisition by for-profits. > Do any of these operations post their tax returns online? -M< From woody at pch.net Tue Aug 12 11:26:32 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 12 Aug 2008 09:26:32 -0700 (PDT) Subject: Coop Peering Fabric?? In-Reply-To: <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> Message-ID: On Tue, 12 Aug 2008, Paul Wall wrote: > If it were as easy as you make it sound, I can assure you people would > be doing it. Yup, they are. There are a bit over three hundred IXPs in the world, about eighty of them in the U.S., and the vast majority of them were built by ISPs solving problems for themselves, as Deepak is suggesting. -Bill From pauldotwall at gmail.com Tue Aug 12 15:48:13 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 12 Aug 2008 16:48:13 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> On Tue, Aug 12, 2008 at 8:32 AM, Patrick W. Gilmore wrote: > Tons of others exist, in big and little markets. There's one in 365 Main > SF, there's KleyReX in the same building as DE-CIX, Big APE in 111 8th, NYCx > there too, ChicagoIX just opened, etc., etc. Excellent point on Europe. Not so much in the United States. Do SFMIX, BIG APE, NYCX, etc 1) have more than a half dozen participants 2) exchange any traffic other than BGP keep-alives and ARP? :) I think not. When you look at why not, it's usually always predatory practices on the part of various collo and IX operators preventing widespread adoptation. If CHIX were doing real traffic, do you think Equinix would allow them to remain accessible from their suites, and in a cost-effective manner? > Trust me, it _is_ being done. It's being done, just not on a large scale in the United States outside of the SIX. Paul From deepak at ai.net Tue Aug 12 16:06:50 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 12 Aug 2008 17:06:50 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> Message-ID: <48A1FB6A.1090809@ai.net> Paul Wall wrote: > On Tue, Aug 12, 2008 at 8:32 AM, Patrick W. Gilmore wrote: >> Tons of others exist, in big and little markets. There's one in 365 Main >> SF, there's KleyReX in the same building as DE-CIX, Big APE in 111 8th, NYCx >> there too, ChicagoIX just opened, etc., etc. > > Excellent point on Europe. > > Not so much in the United States. Do SFMIX, BIG APE, NYCX, etc 1) > have more than a half dozen participants 2) exchange any traffic other > than BGP keep-alives and ARP? :) I think not. When you look at why > not, it's usually always predatory practices on the part of various > collo and IX operators preventing widespread adoptation. If CHIX were > doing real traffic, do you think Equinix would allow them to remain > accessible from their suites, and in a cost-effective manner? > >> Trust me, it _is_ being done. > > It's being done, just not on a large scale in the United States > outside of the SIX. Is there a more appropriate place for interested parties to discuss the possible creation of such a beast in the WDC area? I know we have about a lot of optical capacity we could help contribute to a stake in the ground between Equinix/Ash and a facility less than 1ms away if there is interest. Deepak From pauldotwall at gmail.com Tue Aug 12 16:11:11 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 12 Aug 2008 17:11:11 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <48A1FB6A.1090809@ai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> <48A1FB6A.1090809@ai.net> Message-ID: <620fd17c0808121411k7973a17fj8ae8fc26fc8a078b@mail.gmail.com> On Tue, Aug 12, 2008 at 5:06 PM, Deepak Jain wrote: > Is there a more appropriate place for interested parties to discuss the > possible creation of such a beast in the WDC area? I know we have about a > lot of optical capacity we could help contribute to a stake in the ground > between Equinix/Ash and a facility less than 1ms away if there is interest. And people in the Equinix campus would connect to this exchange how exactly? I'm not trying to downplay your generous offer, though I'm afraid you're missing the underlying problem. Drive Slow, Paul From deepak at ai.net Tue Aug 12 16:19:26 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 12 Aug 2008 17:19:26 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <620fd17c0808121411k7973a17fj8ae8fc26fc8a078b@mail.gmail.com> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> <48A1FB6A.1090809@ai.net> <620fd17c0808121411k7973a17fj8ae8fc26fc8a078b@mail.gmail.com> Message-ID: <48A1FE5E.5020804@ai.net> Paul Wall wrote: > On Tue, Aug 12, 2008 at 5:06 PM, Deepak Jain wrote: >> Is there a more appropriate place for interested parties to discuss the >> possible creation of such a beast in the WDC area? I know we have about a >> lot of optical capacity we could help contribute to a stake in the ground >> between Equinix/Ash and a facility less than 1ms away if there is interest. > > And people in the Equinix campus would connect to this exchange how exactly? > > I'm not trying to downplay your generous offer, though I'm afraid > you're missing the underlying problem. > Cross-connects to a cabinet @ Equinix same as if the switch were on-site? If Equinix were to block cross-connects inside their facility, that would seem a little farther reaching than a non-compete. Deepak From mliotta at r337.com Tue Aug 12 16:57:48 2008 From: mliotta at r337.com (Matt Liotta) Date: Tue, 12 Aug 2008 17:57:48 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <48A1FB6A.1090809@ai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> <48A1FB6A.1090809@ai.net> Message-ID: On Aug 12, 2008, at 5:06 PM, Deepak Jain wrote: > Is there a more appropriate place for interested parties to discuss > the possible creation of such a beast in the WDC area? I know we > have about a lot of optical capacity we could help contribute to a > stake in the ground between Equinix/Ash and a facility less than 1ms > away if there is interest. > I don't know anything about your optical capacity, but it sure does seem like ANY2 DC has everything you are looking for except for easy access from Ashburn. It seems to me an organization (coop, non-profit, etc) that could enable access to Any2 from Ashburn would be quite interesting. CRG might even help. -Matt From deepak at ai.net Tue Aug 12 17:17:29 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 12 Aug 2008 18:17:29 -0400 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> <48A1FB6A.1090809@ai.net> Message-ID: <48A20BF9.7090607@ai.net> Matt Liotta wrote: > > On Aug 12, 2008, at 5:06 PM, Deepak Jain wrote: > >> Is there a more appropriate place for interested parties to discuss >> the possible creation of such a beast in the WDC area? I know we have >> about a lot of optical capacity we could help contribute to a stake in >> the ground between Equinix/Ash and a facility less than 1ms away if >> there is interest. >> > I don't know anything about your optical capacity, but it sure does seem > like ANY2 DC has everything you are looking for except for easy access > from Ashburn. It seems to me an organization (coop, non-profit, etc) > that could enable access to Any2 from Ashburn would be quite > interesting. CRG might even help. > There are lots of providers that can do connectivity between Any2 and Equinix. It has been suggested privately that some Equinix MSAs may prevent this sort of thing. In fact, to prevent this sort of thing, I suggested providing x-connects from 1275 AND Equinix to another facility to prevent Borg'ing ops in the future. I am not aware of Any2 pricing, but I'm sure the 6 members of CRG K Street's Any2 would be happy to join any new initiative (either a larger Any2 or something new). Deepak From mliotta at r337.com Tue Aug 12 17:29:56 2008 From: mliotta at r337.com (Matt Liotta) Date: Tue, 12 Aug 2008 18:29:56 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <48A20BF9.7090607@ai.net> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> <48A1FB6A.1090809@ai.net> <48A20BF9.7090607@ai.net> Message-ID: On Aug 12, 2008, at 6:17 PM, Deepak Jain wrote: > There are lots of providers that can do connectivity between Any2 > and Equinix. It has been suggested privately that some Equinix MSAs > may prevent this sort of thing. In fact, to prevent this sort of > thing, I suggested providing x-connects from 1275 AND Equinix to > another facility to prevent Borg'ing ops in the future. > > I am not aware of Any2 pricing, but I'm sure the 6 members of CRG K > Street's Any2 would be happy to join any new initiative (either a > larger Any2 or something new). > My understanding is that ports are currently free on Any2. I think I remember that normally they are $1000 annually for GigE. CRG has also indicated that they plan to interconnect their Any2 fabrics in NYC and Miami with DC much like they have done in California. -Matt From jsavageau at crgwest.com Tue Aug 12 17:59:51 2008 From: jsavageau at crgwest.com (John R Savageau) Date: Tue, 12 Aug 2008 16:59:51 -0600 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> <48A1FB6A.1090809@ai.net> <48A20BF9.7090607@ai.net> Message-ID: <00b701c8fccf$2164e7b0$642eb710$@com> Matt Any2 is open to support any initiative that will reinforce development of networks and creativity within the Internet-connected community. There have been somewhat successful initiatives at locations such as the SIX to interconnect exchange points, and Any2 is open to contributing to similar projects. In locations such as California and Washington DC, Equinix and CRG West have many common facility-based and services networks. A tenant in either location should find it fairly easy to interconnect with a 3rd party between the facilities. To my knowledge CRG West, Equinix, S&D, Savvis, nor any other collocation or IXP provider prejudices tenants for interconnections terminating beyond their demarcation point. We certainly do not prevent cross-connects outside of our properties to competitor sites. In a couple of our properties we even facility-manage multiple IXPs within the same building No desire to BORG operations! John -----Original Message----- From: Matt Liotta [mailto:mliotta at r337.com] Sent: Tuesday, August 12, 2008 4:30 PM To: NANOG list Subject: Re: Coop Peering Fabric?? On Aug 12, 2008, at 6:17 PM, Deepak Jain wrote: > There are lots of providers that can do connectivity between Any2 > and Equinix. It has been suggested privately that some Equinix MSAs > may prevent this sort of thing. In fact, to prevent this sort of > thing, I suggested providing x-connects from 1275 AND Equinix to > another facility to prevent Borg'ing ops in the future. > > I am not aware of Any2 pricing, but I'm sure the 6 members of CRG K > Street's Any2 would be happy to join any new initiative (either a > larger Any2 or something new). > My understanding is that ports are currently free on Any2. I think I remember that normally they are $1000 annually for GigE. CRG has also indicated that they plan to interconnect their Any2 fabrics in NYC and Miami with DC much like they have done in California. -Matt From ccaputo at alt.net Tue Aug 12 18:46:42 2008 From: ccaputo at alt.net (Chris Caputo) Date: Tue, 12 Aug 2008 23:46:42 +0000 (UTC) Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net><620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com><62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: On Tue, 12 Aug 2008, Martin Hannigan wrote: > On Tue, 12 Aug 2008, Bill Woodcock wrote: > > On Tue, 12 Aug 2008, Patrick W. Gilmore wrote: > > > Could one of the "dangers" of a coop be "borg'ed by for-profit > > > entity looking to rip out every cent they can"? > > > > That's one of the reasons many of them incorporate as non-profits... > > Under the tax laws of most countries, the U.S. and Canada included, > > non-profits are legaly protected against acquisition by for-profits. > > Do any of these operations post their tax returns online? The Seattle IX (SIX) filings, along with financial reports to the membership, are openly maintained at: http://www.seattleix.net/docs/ Chris From glen.kent at gmail.com Tue Aug 12 18:54:17 2008 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 13 Aug 2008 05:24:17 +0530 Subject: Traceroute and random UDP ports Message-ID: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> Hi, The outgoing packets from traceroute are sent towards the destination using UDP and very high port numbers, typically in the range of 32,768 and higher. This is because no one is gernally expected to run UDP services up there, so when the packet finally reaches the destination, traceroute can tell that it got to the end (because the ICMP changes from "TTL exceeded" to "port unreachable"). My question is: What if the receiver is actually listening on one of the "random" UDP ports? What would happen in such cases? Also, why do we increase the UDP port number with each subsequent traceroute packet that is sent? Thanks, Glen From patrick at ianai.net Tue Aug 12 18:57:21 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Aug 2008 19:57:21 -0400 Subject: Traceroute and random UDP ports In-Reply-To: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> References: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> Message-ID: <4A9952CB-A15B-428A-A66D-401886A15E01@ianai.net> On Aug 12, 2008, at 7:54 PM, Glen Kent wrote: > The outgoing packets from traceroute are sent towards the destination > using UDP and very high port numbers, typically in the range of 32,768 > and higher. This is because no one is gernally expected to run UDP > services up there, so when the packet finally reaches the destination, > traceroute can tell that it got to the end (because the ICMP changes > from "TTL exceeded" to "port unreachable"). > > My question is: What if the receiver is actually listening on one of > the "random" UDP ports? What would happen in such cases? Depends on what is running there. Given people randomizing things like DNS ephemeral ports, if they're not careful, it will probably happen more often. > Also, why do we increase the UDP port number with each subsequent > traceroute packet that is sent? So you know which hop sent the packet back. -- TTFN, patrick From trejrco at gmail.com Tue Aug 12 20:57:33 2008 From: trejrco at gmail.com (TJ) Date: Tue, 12 Aug 2008 21:57:33 -0400 Subject: was bogon filters, now "Brief Segue on 1918" In-Reply-To: References: Message-ID: <005101c8fce7$f4f1a060$ded4e120$@com> Michael - good points all, and saved me typing out a reply. Additionally, using up the RFC1918 space isn't the only problem ... the previously mentioned collision problems between so-called private networks become more and more likely (until almost guaranteed). Only nit: "In any case, IPv4 is yesterday's news. Nowadays everyone is scrambling to integrate IPv6 into their networks and shift services onto IPv6." ... I would say they should be doing so; I wish more were!! /TJ >-----Original Message----- >From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] >Sent: Thursday, August 07, 2008 1:06 PM >To: nanog at nanog.org >Subject: RE: was bogon filters, now "Brief Segue on 1918" > >>Your point seemed to be that >> it is not a large enough allocation of IPs for an international >>enterprise of 80K souls. My rebuttal is: 16.5 million IPs isn't >>enough? > >You don't seem to understand how IPv4 networks are designed and how that >interacts with scale, i.e. the large sprawling networks that international >enterprises have. You don't simply count out x addresses per employee. >Instead, you design a subnet architecture that a) can grow at all levels, >and b) can be cut off the network when you sell off a branch operation or >two. > >This leads to large amounts of IP addresses used up in padding at all >levels, which then leads to these organizations running out of RFC 1918 >space, a more and more common occurence. This, in itself, is a good >incentive to move to IPv6, since the seemingly wasteful subnet architecture >is considered best practice with IPv6, and a ULA prefix or two gives you >lots of space to keep growing. > >> What are we talking >> about then? 100 IPs per person--say each person has 10 PCs, 10 >> printers, 10 automated factory machines, 10 lab instruments, 49 >> servers and the soda machine on their network? > >Nope. We are not talking about people, but about network architecture and >topology. Two people in one office need two addresses. Put them in separate >offices and they need two subnets. Topology dominates the design. > >> I don't think you have that many soda machines. Even on 5 continents. >> Even with your growing Asian market, your suppliers, and the whole >> marketing team. > >I believe the first two companies to run out of RFC 1918 space (or to >project that it would happen) are Comcast, and American cable provider in >one continent, and a Japanese cable provider on a small Pacific island next >to China. > >> //Err. Doing it wrong does not justify doing it wrong. > >Cute sound bites does not make you an expert in anything. > >In any case, IPv4 is yesterday's news. Nowadays everyone is scrambling to >integrate IPv6 into their networks and shift services onto IPv6. > >--Michael Dillon From awacs at ziskind.us Tue Aug 12 21:11:57 2008 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Tue, 12 Aug 2008 22:11:57 -0400 Subject: Coop Peering Fabric?? In-Reply-To: References: <48A10065.4060900@ai.net><620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com><62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> Message-ID: <20080812221157.A26444@egps.egps.com> > > That's one of the reasons many of them incorporate as non-profits... > > Under the tax laws of most countries, the U.S. and Canada included, > > non-profits are legaly protected against acquisition by for-profits. > > > > Do any of these operations post their tax returns online? > > -M< They might be posted at http://www.guidestar.org/ -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From johnl at iecc.com Tue Aug 12 21:43:33 2008 From: johnl at iecc.com (John Levine) Date: 13 Aug 2008 02:43:33 -0000 Subject: Coop Peering Fabric?? In-Reply-To: Message-ID: <20080813024333.20618.qmail@simone.iecc.com> >> That's one of the reasons many of them incorporate as non-profits... >> Under the tax laws of most countries, the U.S. and Canada included, >> non-profits are legaly protected against acquisition by for-profits. > >Do any of these operations post their tax returns online? In the US, every non-profit has to file an annual financial report on form 990 or, for small ones, 990-EZ. These are by law open to public inspection, and if you call, write, fax or e-mail them and ask for a copy they better send you one. The Foundation Center has a fairly good online 990 database: http://tfcny.fdncenter.org/990s/990search/esearch.php If you're wondering what my signature looks like, search for Domain Assurance Council R's, John From patrick at ianai.net Tue Aug 12 21:52:07 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Aug 2008 22:52:07 -0400 Subject: Coop Peering Fabric?? In-Reply-To: <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> References: <48A10065.4060900@ai.net> <620fd17c0808120037g2afc8d78ma93fc95a4d355974@mail.gmail.com> <62B17C65-6082-4D3A-9981-10DC98130317@ianai.net> <620fd17c0808121348w4529bb0m9a7704dbdf095827@mail.gmail.com> Message-ID: <1F7892B8-1E42-4B2D-B96B-A5B300118B48@ianai.net> On Aug 12, 2008, at 4:48 PM, Paul Wall wrote: > On Tue, Aug 12, 2008 at 8:32 AM, Patrick W. Gilmore > wrote: >> Tons of others exist, in big and little markets. There's one in >> 365 Main >> SF, there's KleyReX in the same building as DE-CIX, Big APE in 111 >> 8th, NYCx >> there too, ChicagoIX just opened, etc., etc. > > Excellent point on Europe. > > Not so much in the United States. Do SFMIX, BIG APE, NYCX, etc 1) > have more than a half dozen participants 2) exchange any traffic other > than BGP keep-alives and ARP? :) I think not. When you look at why > not, it's usually always predatory practices on the part of various > collo and IX operators preventing widespread adoptation. If CHIX were > doing real traffic, do you think Equinix would allow them to remain > accessible from their suites, and in a cost-effective manner? I'm guessing the answer to 1 & 2 is yes. Proof of at least participant count: . >> Trust me, it _is_ being done. > > It's being done, just not on a large scale in the United States > outside of the SIX. Define "large". For instance, Atlanta IX had more traffic than PAIX in the same building last I checked. And how large does it need to be to save a network $300/month? -- TTFN, patrick From yskchu at gmail.com Wed Aug 13 00:36:38 2008 From: yskchu at gmail.com (Kelvin Chu) Date: Wed, 13 Aug 2008 15:36:38 +1000 Subject: facebook worm In-Reply-To: <489C7559.2010008@zill.net> References: <489C7559.2010008@zill.net> Message-ID: <85c8f1b00808122236w70d74cfw103598c45969ecc3@mail.gmail.com> On Sat, Aug 9, 2008 at 2:33 AM, Patrick Giagnocavo wrote: > Turning nanog into a rehash of digg's technology section or the front page > of news.com reduces nanog's utility. > > --Patrick > > Are you saying that all network professionals should read digg or news.com? :-) Btw, slashdot seemed to have missed it. From jtk at centergate.net Wed Aug 13 07:56:53 2008 From: jtk at centergate.net (John Kristoff) Date: Wed, 13 Aug 2008 07:56:53 -0500 Subject: Traceroute and random UDP ports In-Reply-To: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> References: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> Message-ID: <20080813075653.2d319ba0@t41-0> On Wed, 13 Aug 2008 05:24:17 +0530 "Glen Kent" wrote: > The outgoing packets from traceroute are sent towards the destination > using UDP and very high port numbers, typically in the range of 32,768 > and higher. This is because no one is gernally expected to run UDP > services up there, so when the packet finally reaches the destination, > traceroute can tell that it got to the end (because the ICMP changes > from "TTL exceeded" to "port unreachable"). Yes, this is correct. Note that this is all the case largely due to historical artifact of how TCP/IP stacks at the time behaved. For example, UDP was chosen simply because some hosts took the notion of not replying to ICMP error messages literally, making the use of an ICMP traceroute tool early on unreliable. This, I believe, is no longer the primary problem now, filtering is. This is often why a TCP-based traceroute to port 80 is so useful these days. > My question is: What if the receiver is actually listening on one of > the "random" UDP ports? What would happen in such cases? You probably won't get a response from that message. Most UDP listeners tend to be silent unless a well formed message arrives that requires a response. So it may look like you have reached the host for at least that one traceroute packet. > Also, why do we increase the UDP port number with each subsequent > traceroute packet that is sent? I don't know definitively, but I have an of educated guess Since by default the original traceroute tool sent three packets per TTL it might not only increase likelihood of one getting through, but also the likelihood of hitting a closed port. For further information I sugguest consulting Stevens TCP/IP Illustrated chapter 8, dated, but still an indispensable resource. John From jaitken at aitken.com Wed Aug 13 08:13:29 2008 From: jaitken at aitken.com (Jeff Aitken) Date: Wed, 13 Aug 2008 13:13:29 +0000 Subject: Traceroute and random UDP ports In-Reply-To: <20080813075653.2d319ba0@t41-0> References: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> <20080813075653.2d319ba0@t41-0> Message-ID: <20080813131329.GA20500@eagle.aitken.com> On Wed, Aug 13, 2008 at 07:56:53AM -0500, John Kristoff wrote: > > Also, why do we increase the UDP port number with each subsequent > > traceroute packet that is sent? > > I don't know definitively, but I have an of educated guess >From /usr/src/contrib/traceroute/traceroute.c: /* * Notes * ----- * [...] * The udp port usage may appear bizarre (well, ok, it is bizarre). * The problem is that an icmp message only contains 8 bytes of * data from the original datagram. 8 bytes is the size of a udp * header so, if we want to associate replies with the original * datagram, the necessary information must be encoded into the * udp header (the ip id could be used but there's no way to * interlock with the kernel's assignment of ip id's and, anyway, * it would have taken a lot more kernel hacking to allow this * code to set the ip id). So, to allow two or more users to * use traceroute simultaneously, we use this task's pid as the * source port (the high bit is set to move the port number out * of the "likely" range). To keep track of which probe is being * replied to (so times and/or hop counts don't get confused by a * reply that was delayed in transit), we increment the destination * port number before each probe. * [...] * -- Van Jacobson (van at ee.lbl.gov) * Tue Dec 20 03:50:13 PST 1988 */ --Jeff From rickfidiot at gmail.com Wed Aug 13 09:40:38 2008 From: rickfidiot at gmail.com (Rick'n Fidiot) Date: Wed, 13 Aug 2008 07:40:38 -0700 Subject: Coin Op Peering Fabric? Message-ID: <8cb994fd0808130740v2a5243eex53654c3c5ebbc1e5@mail.gmail.com> Warning: This may actually be operational too. Given Cogent's (and others) recent pursuit of sub $4/mb/s transit (at least as far as all the bottom feeders and gossippers like to talk about) and the relatively flat cost of a "paid" peering fabric (even on IP8) and the fancy non euclidean name dropping formula costs for cross-connects, the thought of revising current packetized switching model into the historical pay phone model presents itself again. Assuming the Clos switch fabric model, if we simply repudiate all self-evident rights of capitalist business people to compete in a fair market, we should again return to the days of government subsidized monopolies and absolved self-responsibility to avoid the perils of anti-randian unfair competition and a technologically advanced race to the bottom. A "coin-op" best-effort pay as you go switching fabric would be in everyone's best interest (read FAIR and anti-bourgeois classism), and a community designed Clos switch would present no more than 30% blockage on non-peak hours. In this model, people who can't succeed at business could go off and talk about Spam all day, and in their free time they could move cross-connects around, kind of like at the early digital non-NSF funded NAPs. The way I figure it, this would provide a living wage for network engineers that spend all day arguing abstract points in email. You'd simply deposit an American Nickel into the Hawala Peering system. Does this actually improve the quality of the network experience? I dunno. Warning: This may actually have more Merit than other recent posts and the hosting organization of this public discussion list. Yours in contemplation, (f)Rick N. Idiot From andyjohnson at ij.net Wed Aug 13 09:42:15 2008 From: andyjohnson at ij.net (Andy Johnson) Date: Wed, 13 Aug 2008 10:42:15 -0400 Subject: impossible circuit References: Message-ID: <003a01c8fd52$c7ff92e0$0100a8c0@oicu812> > The only things I can think of that might be the cause are > misconfiguration in a DACS/mux somewhere along the circuit path or perhaps > a mishandled lawful intercept. I don't have enough experience with either > or enough access to the systems that provide the circuit to do any more > than speculate. Has anyone else ever seen anything like this? I'm not sure how a DACS/mux misconfiguration would do this. There would have to be some intelligent device grabbing those IP packets and forwarding them on to another IP router, which seems really likely. Have you noticed any unusual shifts in pattern on the internal network of your Ocala office? I wonder if somebody decided it would be clever to start up a VPN tunnel on a host inside your network, and also set the host in promiscuous mode, forwarding every packet it gets back out that tunnel. The only argument I can come up against this tunnel/host, is that when you changed line encapsulation modes, it went away. However, could have just dropped the tunnel or the host that was misbehaving decided it was a good time to stop. From justin at justinshore.com Wed Aug 13 11:02:29 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 13 Aug 2008 11:02:29 -0500 Subject: impossible circuit In-Reply-To: References: Message-ID: <48A30595.2060205@justinshore.com> This is just a WAG but what the hell. Jon Lewis wrote: > I've got this private line DS3. It connects cisco 7206 routers in > Orlando (at our data center) and in Ocala (a colo rack in the Embarq CO). > > According to the DLR, it's a real circuit, various portions of it ride > varying sized OC circuits, and then it's handed off to us at each end > the usual way (copper/coax) and plugged into PA-2T3 cards. Are you sure that they are not crossing some channels in the middle and accidentally handing them to a different customer? You mention above that various portions of the DS3 ride different transport circuits in the middle. That always creates the potential for someone to not put it back together correctly on either end. I've seen DLCs get crossed before. I could easily see a transport provider crossing portions of a circuit, especially if they break it into pieces in the middle and have to put it back together on the ends. I think it makes sense too. Somebody's getting traffic off a T1 that isn't destined for them. Their router sees it, says WTF and sends a ICMP dest unreachable via their default route through Sprint. Same thing goes for a traceroute; it simply follows its default route to reply to your packets with the expiring TTL. Taking a path through a different provider would be expected since it doesn't have a connected route to the source of the traceroute (since it's not the far end of your T1 that you're expecting). The site getting your crossed T1 could be using the T1 as a PtP to a branch office and has Internet through a different circuit that hasn't been hosed. I would be curious to hear if Sprint is having any problems with a circuit connected to sl-bb20-dc-6-0-0.sprintlink.net, what the router is and if any directly connected customers are having T1 problems. If nothing else Sprint should be able to track down the source of the traceroute return packets and contact the customer. The T1 could be part of a bundle at their site and they may not even realize that the bundle dropped a path. > Last Tuesday, at about 2:30PM, "something bad happened." We saw a > serious jump in traffic to Ocala, and in particular we noticed one > customer's connection (a group of load sharing T1s) was just totally > full. We quickly assumed it was a DDoS aimed at that customer, but > looking at the traffic, we couldn't pinpoint anything that wasn't > expected flows. Are you sure that the traffic being received by each of the T1s is their's? Do you have any way to getting flows or packets off of individual T1s and not the bundle as a whole? Tracing through you to your upstream... > 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms > 56.154 ms > 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 > ms 56.196 ms > 9 * * * Circuit gets crossed onto the wrong customer. Wrong site received a packet with an expiring TTL and goes to send a reply. Destination IP isn't on a connected route so the site sends the reply via it's default route on Sprint. > 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 > ms 81.821 ms > 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 75.731 ms 75.902 > ms 77.128 ms Reply traverses Sprint to L3 and on to you. > 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 46.548 ms > 53.200 ms 45.736 ms > 13 vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.918 ms > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 55.438 ms > vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.693 ms > 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 48.935 ms > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 49.317 ms > ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 48.865 ms > 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 59.642 ms 56.278 ms > 56.671 ms > 16 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 47.401 ms 62.980 > ms 62.640 ms > 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 40.300 ms 40.101 > ms 42.690 ms > 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 40.959 ms 40.963 ms > 41.016 ms > 19 unknown.Level3.net (63.209.98.66) 246.744 ms 240.826 ms 239.758 ms > 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 39.725 ms 37.751 ms > 42.262 ms > 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 43.524 ms 45.844 > ms 43.392 ms > 22 * * * > 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 63.752 ms 61.648 > ms 60.839 ms > 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 66.923 ms 65.258 > ms 70.609 ms > 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 67.106 ms > 93.415 ms 73.932 ms > 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 88.919 ms 75.306 > ms vlan79.csw2.Washington1.Level3.net (4.68.17.126) 75.048 ms > 27 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 69.508 ms > 68.401 ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 79.128 ms > 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 64.048 ms 67.764 ms > 67.704 ms > 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 68.372 ms 67.025 > ms 68.162 ms > 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 65.112 ms 65.584 > ms 65.525 ms I can't explain the continuous loop or the dupes. I'm not sure if my theory fits those symptoms or not. > Our circuit provider's support people have basically just maintained > that this behavior isn't possible and so there's nothing they can do > about it. i.e. that the problem has to be something other than the circuit. Can you have them put the circuit into maintenance and have them test it end to end? They can't deny it when their TDR says that there's a problem. > I got tired of talking to their brick wall, so I contacted Sprint and > was able to confirm with them that the traffic in question really was > inexplicably appearing on their network...and not terribly close > geographically to the Orlando/Ocala areas. Which supports with my theory of a crossed circuit. Crossing a DS1 onto the wrong DS3 or OCx could easily make it pop up anywhere. Somewhere is another site that's having T1 problems. > So, I have a circuit that's bleeding duplicate packets onto an unrelated > IP network, a circuit provider who's got their head in the sand and > keeps telling me "this can't happen, we can't help you", and customers > who were getting tired of receiving all their packets in triplicate (or > more) saturating their connections and confusing their applications. > After a while, I had to give up on finding the problem and focus on just > making it stop. After trying a couple of things, the solution I found > was to change the encapsulation we use at each end of the DS3. I > haven't gotten confirmation of this from Sprint, but I assume they're > now seeing massive input errors one the one or more circuits where our > packets were/are appearing. The important thing (for me) is that this > makes the packets invalid to Sprint's routers and so it keeps them from > forwarding the packets to us. Cisco TAC finally got back to us the day > after I "fixed" the circuit...but since it was obviously not a problem > with our cisco gear, I haven't pursued it with them. Right. By changing the encap you've basically killed the circuit. With that T1 effectively down on your end you won't be sending any packets down the problem path and aren't able to see that problem anymore with your traceroutes. However your customer with the bundle of T1s is down a circuit. It makes sense in my mind that it's simply a crossed circuit in the middle. Your transport provider for whatever reason pulled out a DS1 and sent it down a different path. They accidentally crossed DS1s in the middle and are handing your DS1 to a Sprint customer and their DS1 to your customer. That's my theory at least. Justin From jlewis at lewis.org Wed Aug 13 11:29:24 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 13 Aug 2008 12:29:24 -0400 (EDT) Subject: impossible circuit In-Reply-To: <48A30595.2060205@justinshore.com> References: <48A30595.2060205@justinshore.com> Message-ID: On Wed, 13 Aug 2008, Justin Shore wrote: > Are you sure that they are not crossing some channels in the middle and > accidentally handing them to a different customer? You mention above that I can't be sure of anything like that. I don't have access. Those who do haven't been willing to look harder...just repeating "this can't happen, it's a private line DS3" and I'm sure thinking I'm nuts or an idiot. > I would be curious to hear if Sprint is having any problems with a circuit > connected to sl-bb20-dc-6-0-0.sprintlink.net, what the router is and if any I'm very curious too, because at this point, I expect they must be seeing lots of errors (not sure what kind you get when a line running HDLC encounters PPP encapsulated packets...but I bet they're causing input errors of some sort). I'm going to try to make contact again with the guy at Sprint I spoke with last week. > Are you sure that the traffic being received by each of the T1s is their's? > Do you have any way to getting flows or packets off of individual T1s and not > the bundle as a whole? Yeah...I was looking at the output of "show ip cache flow" on the customer's router. The traffic was all expected traffic. The problem was, they were receiving several copies of every expected packet. > Can you have them put the circuit into maintenance and have them test it end > to end? They can't deny it when their TDR says that there's a problem. What problem do you think they'll see if they do intrusive testing? With the circuit taken down and test equipment at both ends, there's no way for the dupe data delivered to Sprint to get back to the circuit. All that might happen is Sprint may experience even more errors on their circuit(s)...but testing on our circuit won't reveal that to the testers. > Right. By changing the encap you've basically killed the circuit. With that > T1 effectively down on your end you won't be sending any packets down the > problem path and aren't able to see that problem anymore with your > traceroutes. However your customer with the bundle of T1s is down a circuit. You've pretty badly misunderstood. The customer with the multiple T1s is irrelevant. Their T1s aren't part of the problem. Their T1s being full was just one symptom of the problem. The problem circuit is our DS3 from Orlando to Ocala. Changing the encaps on that DS3 (at both ends...with no OOB access...kind of scarey) from hdlc to ppp keeps the circuit working, and keeps the dupes from coming back at us, because the ppp encapsulated packets aren't understood by Sprint's routers running [I assume] hdlc...so they can't forward the packets. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jabley at ca.afilias.info Wed Aug 13 10:24:37 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 13 Aug 2008 11:24:37 -0400 Subject: Traceroute and random UDP ports In-Reply-To: <20080813075653.2d319ba0@t41-0> References: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> <20080813075653.2d319ba0@t41-0> Message-ID: <5889714C-92DC-4020-9559-975D13DC23CB@ca.afilias.info> On 13 Aug 2008, at 08:56, John Kristoff wrote: > For further information I > sugguest consulting Stevens TCP/IP Illustrated chapter 8, dated, but > still an indispensable resource. ... or the comments in Van's traceroute.c, which are pleasantly educational. Joe /* * traceroute host - trace the route ip packets follow going to "host". * * Attempt to trace the route an ip packet would follow to some * internet host. We find out intermediate hops by launching probe * packets with a small ttl (time to live) then listening for an * icmp "time exceeded" reply from a gateway. We start our probes * with a ttl of one and increase by one until we get an icmp "port * unreachable" (which means we got to "host") or hit a max (which * defaults to net.inet.ip.ttl hops & can be changed with the -m flag). * Three probes (change with -q flag) are sent at each ttl setting and * a line is printed showing the ttl, address of the gateway and * round trip time of each probe. If the probe answers come from * different gateways, the address of each responding system will * be printed. If there is no response within a 5 sec. timeout * interval (changed with the -w flag), a "*" is printed for that * probe. * * Probe packets are UDP format. We don't want the destination * host to process them so the destination port is set to an * unlikely value (if some clod on the destination is using that * value, it can be changed with the -p flag). * * A sample use might be: * * [yak 71]% traceroute nis.nsf.net. * traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 56 byte packet * 1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms * 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms * 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms * 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms * 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms * 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms * 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms * 8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms * 9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms * 10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms * 11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms * * Note that lines 2 & 3 are the same. This is due to a buggy * kernel on the 2nd hop system -- lbl-csam.arpa -- that forwards * packets with a zero ttl. * * A more interesting example is: * * [yak 72]% traceroute allspice.lcs.mit.edu. * traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max * 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms * 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms * 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms * 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms * 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms * 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms * 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms * 8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms * 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms * 10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms * 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms * 12 * * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms * 14 * * * * 15 * * * * 16 * * * * 17 * * * * 18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms * * (I start to see why I'm having so much trouble with mail to * MIT.) Note that the gateways 12, 14, 15, 16 & 17 hops away * either don't send ICMP "time exceeded" messages or send them * with a ttl too small to reach us. 14 - 17 are running the * MIT C Gateway code that doesn't send "time exceeded"s. God * only knows what's going on with 12. * * The silent gateway 12 in the above may be the result of a bug in * the 4.[23]BSD network code (and its derivatives): 4.x (x <= 3) * sends an unreachable message using whatever ttl remains in the * original datagram. Since, for gateways, the remaining ttl is * zero, the icmp "time exceeded" is guaranteed to not make it back * to us. The behavior of this bug is slightly more interesting * when it appears on the destination system: * * 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms * 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms * 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms * 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms * 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms * 6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms * 7 * * * * 8 * * * * 9 * * * * 10 * * * * 11 * * * * 12 * * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms ! * * Notice that there are 12 "gateways" (13 is the final * destination) and exactly the last half of them are "missing". * What's really happening is that rip (a Sun-3 running Sun OS3.5) * is using the ttl from our arriving datagram as the ttl in its * icmp reply. So, the reply will time out on the return path * (with no notice sent to anyone since icmp's aren't sent for * icmp's) until we probe with a ttl that's at least twice the path * length. I.e., rip is really only 7 hops away. A reply that * returns with a ttl of 1 is a clue this problem exists. * Traceroute prints a "!" after the time if the ttl is <= 1. * Since vendors ship a lot of obsolete (DEC's Ultrix, Sun 3.x) or * non-standard (HPUX) software, expect to see this problem * frequently and/or take care picking the target host of your * probes. * * Other possible annotations after the time are !H, !N, !P (got a host, * network or protocol unreachable, respectively), !S or !F (source * route failed or fragmentation needed -- neither of these should * ever occur and the associated gateway is busted if you see one). If * almost all the probes result in some kind of unreachable, traceroute * will give up and exit. * * Notes * ----- * This program must be run by root or be setuid. (I suggest that * you *don't* make it setuid -- casual use could result in a lot * of unnecessary traffic on our poor, congested nets.) * * This program requires a kernel mod that does not appear in any * system available from Berkeley: A raw ip socket using proto * IPPROTO_RAW must interpret the data sent as an ip datagram (as * opposed to data to be wrapped in a ip datagram). See the README * file that came with the source to this program for a description * of the mods I made to /sys/netinet/raw_ip.c. Your mileage may * vary. But, again, ANY 4.x (x < 4) BSD KERNEL WILL HAVE TO BE * MODIFIED TO RUN THIS PROGRAM. * * The udp port usage may appear bizarre (well, ok, it is bizarre). * The problem is that an icmp message only contains 8 bytes of * data from the original datagram. 8 bytes is the size of a udp * header so, if we want to associate replies with the original * datagram, the necessary information must be encoded into the * udp header (the ip id could be used but there's no way to * interlock with the kernel's assignment of ip id's and, anyway, * it would have taken a lot more kernel hacking to allow this * code to set the ip id). So, to allow two or more users to * use traceroute simultaneously, we use this task's pid as the * source port (the high bit is set to move the port number out * of the "likely" range). To keep track of which probe is being * replied to (so times and/or hop counts don't get confused by a * reply that was delayed in transit), we increment the destination * port number before each probe. * * Don't use this as a coding example. I was trying to find a * routing problem and this code sort-of popped out after 48 hours * without sleep. I was amazed it ever compiled, much less ran. * * I stole the idea for this program from Steve Deering. Since * the first release, I've learned that had I attended the right * IETF working group meetings, I also could have stolen it from Guy * Almes or Matt Mathis. I don't know (or care) who came up with * the idea first. I envy the originators' perspicacity and I'm * glad they didn't keep the idea a secret. * * Tim Seaver, Ken Adelman and C. Philip Wood provided bug fixes and/or * enhancements to the original distribution. * * I've hacked up a round-trip-route version of this that works by * sending a loose-source-routed udp datagram through the destination * back to yourself. Unfortunately, SO many gateways botch source * routing, the thing is almost worthless. Maybe one day... * * -- Van Jacobson (van at ee.lbl.gov) * Tue Dec 20 03:50:13 PST 1988 */ From Crist.Clark at globalstar.com Wed Aug 13 12:02:03 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 13 Aug 2008 10:02:03 -0700 Subject: Traceroute and random UDP ports In-Reply-To: <20080813131329.GA20500@eagle.aitken.com> References: <92c950310808121654m24369d66m3750b63643f081da@mail.gmail.com> <20080813075653.2d319ba0@t41-0> <20080813131329.GA20500@eagle.aitken.com> Message-ID: <48A2B117.8C45.0097.0@globalstar.com> >>> On 8/13/2008 at 6:13 AM, Jeff Aitken wrote: > On Wed, Aug 13, 2008 at 07:56:53AM -0500, John Kristoff wrote: >> > Also, why do we increase the UDP port number with each subsequent >> > traceroute packet that is sent? >> >> I don't know definitively, but I have an of educated guess > >>From /usr/src/contrib/traceroute/traceroute.c: > > /* > * Notes > * ----- > * [...] > * The udp port usage may appear bizarre (well, ok, it is bizarre). > * The problem is that an icmp message only contains 8 bytes of > * data from the original datagram. 8 bytes is the size of a udp > * header so, if we want to associate replies with the original > * datagram, the necessary information must be encoded into the > * udp header (the ip id could be used but there's no way to > * interlock with the kernel's assignment of ip id's and, anyway, > * it would have taken a lot more kernel hacking to allow this > * code to set the ip id). So, to allow two or more users to > * use traceroute simultaneously, we use this task's pid as the > * source port (the high bit is set to move the port number out > * of the "likely" range). To keep track of which probe is being > * replied to (so times and/or hop counts don't get confused by a > * reply that was delayed in transit), we increment the destination > * port number before each probe. > * [...] > * -- Van Jacobson (van at ee.lbl.gov) > * Tue Dec 20 03:50:13 PST 1988 > */ Yep. That explains it pretty well. When I added an option to the FreeBSD traceroute to use a fixed destination port with TCP or UDP traceroutes, I had to overload the source port with the PID and the traceroute sequence number for UDP, http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/traceroute/traceroute.c.diff?r1=1.28;r2=1.29 Not to open a whole new can of worms, but in TCP traceroutes, which most "modern" traceroute implementations offer in addition to UDP and ICMP echo options, you can use the TCP sequence number as payload that will get reflected back in that 8-bytes of IP data that come back in the ICMP time-exceeded (or in the RST if you reach the target host). The overall lesson is that IP traceroutes are a kludge. But a fairly robust (i.e. you can get around/through lots of ACLs and firewalls) one given all of the options available in a good implementation. -- 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 andyjohnson at ij.net Wed Aug 13 13:27:33 2008 From: andyjohnson at ij.net (Andy Johnson) Date: Wed, 13 Aug 2008 14:27:33 -0400 Subject: impossible circuit References: <48A30595.2060205@justinshore.com> Message-ID: <001001c8fd72$43353a40$0100a8c0@oicu812> > working, and keeps the dupes from coming back at us, because the ppp > encapsulated packets aren't understood by Sprint's routers running [I > assume] hdlc...so they can't forward the packets. AFAIK, routers don't just forward IP packets because they "see" them. That destination MAC address needs to be set to something assigned to the router doesn't it? Unless somehow they've crossed you into some sprint router running IRB? That might be the only exception I can think of. From jared at puck.nether.net Wed Aug 13 13:34:06 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 13 Aug 2008 14:34:06 -0400 Subject: impossible circuit In-Reply-To: <001001c8fd72$43353a40$0100a8c0@oicu812> References: <001001c8fd72$43353a40$0100a8c0@oicu812> Message-ID: <20080813183406.GF96695@puck.nether.net> On Wed, Aug 13, 2008 at 02:27:33PM -0400, Andy Johnson wrote: >> working, and keeps the dupes from coming back at us, because the ppp >> encapsulated packets aren't understood by Sprint's routers running [I >> assume] hdlc...so they can't forward the packets. > > AFAIK, routers don't just forward IP packets because they "see" them. > That destination MAC address needs to be set to something assigned to the > router doesn't it? Unless somehow they've crossed you into some sprint > router running IRB? That might be the only exception I can think of. The circuit involved in this case is a DS3, whatever you get will be processed on the other side unless it's blocked by uRPF or some sort of ACL. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From mjl at luckie.org.nz Wed Aug 13 14:29:15 2008 From: mjl at luckie.org.nz (Matthew Luckie) Date: Thu, 14 Aug 2008 07:29:15 +1200 Subject: Traceroute and random UDP ports In-Reply-To: <5889714C-92DC-4020-9559-975D13DC23CB@ca.afilias.info> Message-ID: <20080813192915.GA1349@spandex.luckie.org.nz> These days there are better implementations of traceroute that are less likely to infer false IP paths by not playing games with the source and destination ports. www.paris-traceroute.net Paris traceroute hacks the payload of the UDP probe to use the checksum field as the probe identifier (and also uses the IPID field as a backup since NATs will change the checksum). Paris traceroute also has an ICMP mode. From swmike at swm.pp.se Wed Aug 13 15:04:27 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 13 Aug 2008 22:04:27 +0200 (CEST) Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake Message-ID: The italian courts seem to have told ISPs there to block ThePirateBay (bittorrent tracker), and this evening (CET) LLNW (AS22822) originated 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of Europe. Basically same thing that happened when people tried to block YouTube a few months back (afghanistan?). How do we hinder this in the short term? I know there are a lot of long term solutions that very few is implementing, but would the fact that these mistakes are brought up into the (lime)light by a public shaming list make ISPs shape up and perform less mistakes? I am still waiting for a response from LLNW NOC on the issue. -- Mikael Abrahamsson email: swmike at swm.pp.se From jared at puck.nether.net Wed Aug 13 15:48:18 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 13 Aug 2008 16:48:18 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: Message-ID: <20080813204818.GG19971@puck.nether.net> On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote: > > The italian courts seem to have told ISPs there to block ThePirateBay > (bittorrent tracker), and this evening (CET) LLNW (AS22822) originated > 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of > Europe. > > Basically same thing that happened when people tried to block YouTube a > few months back (afghanistan?). > > How do we hinder this in the short term? I know there are a lot of long > term solutions that very few is implementing, but would the fact that > these mistakes are brought up into the (lime)light by a public shaming > list make ISPs shape up and perform less mistakes? > > I am still waiting for a response from LLNW NOC on the issue. Sure. I'd also like to see providers actually just shut off customers that originate stuff like ms-sql slammer packets still. But it keeps flowing. I'm sure there are smurf amps and other badness still going. codered anyone? these are all issues, but operational? depends. If LLNW is not being filtered by telecom italia, time for 6762 to fix that. If they persist, will you depeer them as a security risk until they clean up their act? I'm still amazed at the AS_PATHs that appear out there and the providers that can't figure out how to route. Why AS174 would listen to 3549 routes from AS12713 is beyond me, but it's there.[1] 221.134.222.0/24 1280 174 12713 3549 2914 9498 9583 - jared 1 - http://puck.nether.net/bgp/leakinfo.cgi - http://puck.nether.net/bgp/stats.cgi?days=3 -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From patrick at ianai.net Wed Aug 13 15:52:46 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Aug 2008 16:52:46 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080813204818.GG19971@puck.nether.net> References: <20080813204818.GG19971@puck.nether.net> Message-ID: On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote: > On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote: >> >> The italian courts seem to have told ISPs there to block ThePirateBay >> (bittorrent tracker), and this evening (CET) LLNW (AS22822) >> originated >> 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of >> Europe. >> >> Basically same thing that happened when people tried to block >> YouTube a >> few months back (afghanistan?). >> >> How do we hinder this in the short term? I know there are a lot of >> long >> term solutions that very few is implementing, but would the fact that >> these mistakes are brought up into the (lime)light by a public >> shaming >> list make ISPs shape up and perform less mistakes? >> >> I am still waiting for a response from LLNW NOC on the issue. > > Sure. I'd also like to see providers actually just shut > off customers that originate stuff like ms-sql slammer > packets still. But it keeps flowing. I'm sure there are > smurf amps and other badness still going. codered anyone? > > these are all issues, but operational? depends. I beg to differ, this is absolutely operational. > If LLNW is not being filtered by telecom italia, time for > 6762 to fix that. If they persist, will you depeer them > as a security risk until they clean up their act? De-peering won't help if someone is propagating it as a transit customer route. Filtering the prefix is all you can do. -- TTFN, patrick P.S. Obligatory BCP38 shout-out, even though it's not exactly on- point. :-) > I'm still amazed at the AS_PATHs that appear > out there and the providers that can't figure out how to > route. > > Why AS174 would listen to 3549 routes from AS12713 > is beyond me, but it's there.[1] > > 221.134.222.0/24 1280 174 12713 3549 2914 9498 9583 > > > - jared > > 1 - http://puck.nether.net/bgp/leakinfo.cgi > - http://puck.nether.net/bgp/stats.cgi?days=3 > > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are > only mine. > From swmike at swm.pp.se Wed Aug 13 15:56:01 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 13 Aug 2008 22:56:01 +0200 (CEST) Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080813204818.GG19971@puck.nether.net> References: <20080813204818.GG19971@puck.nether.net> Message-ID: On Wed, 13 Aug 2008, Jared Mauch wrote: > these are all issues, but operational? depends. If LLNW is not > being filtered by telecom italia, time for 6762 to fix that. If they > persist, will you depeer them as a security risk until they clean up > their act? I just discovered (via bgplay) that 22822 first originated the prefix via 5511 (france telecom), then it was withdrawn a while later, and then originated via 6762, and then withdrawn again. An hour or so between these events. We all know we don't filter our peers (there is no operationally sane way of doing this today), so the question is how to make ISPs filter their customers more sanely. We have prefix-filters on our customer bgp sessions, so that should be fairly safe, but I see no good way of doing this towards peers as there is no uniform way of doing this, and there is no industry consenus how it should be done. -- Mikael Abrahamsson email: swmike at swm.pp.se From karnaugh at karnaugh.za.net Wed Aug 13 16:05:28 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 13 Aug 2008 23:05:28 +0200 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: Message-ID: <48A34C98.1030309@karnaugh.za.net> On 2008/08/13 10:04 PM Mikael Abrahamsson wrote: > > The italian courts seem to have told ISPs there to block ThePirateBay > (bittorrent tracker), and this evening (CET) LLNW (AS22822) originated > 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of Europe. > > Basically same thing that happened when people tried to block YouTube a > few months back (afghanistan?). > > How do we hinder this in the short term? I know there are a lot of long > term solutions that very few is implementing, but would the fact that > these mistakes are brought up into the (lime)light by a public shaming > list make ISPs shape up and perform less mistakes? Can't IANA give $100000 stupidity tax or revoke AS for people that do this? From jared at puck.nether.net Wed Aug 13 16:04:51 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 13 Aug 2008 17:04:51 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> Message-ID: <20080813210451.GI19971@puck.nether.net> On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote: > On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote: >> On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote: >>> >>> The italian courts seem to have told ISPs there to block ThePirateBay >>> (bittorrent tracker), and this evening (CET) LLNW (AS22822) >>> originated >>> 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of >>> Europe. >>> >>> Basically same thing that happened when people tried to block >>> YouTube a >>> few months back (afghanistan?). >>> >>> How do we hinder this in the short term? I know there are a lot of >>> long >>> term solutions that very few is implementing, but would the fact that >>> these mistakes are brought up into the (lime)light by a public >>> shaming >>> list make ISPs shape up and perform less mistakes? >>> >>> I am still waiting for a response from LLNW NOC on the issue. >> >> Sure. I'd also like to see providers actually just shut >> off customers that originate stuff like ms-sql slammer >> packets still. But it keeps flowing. I'm sure there are >> smurf amps and other badness still going. codered anyone? >> >> these are all issues, but operational? depends. > > I beg to differ, this is absolutely operational. So, I should shut down or depeer networks that continue to originate the crap to me? (packets, announcements). >> If LLNW is not being filtered by telecom italia, time for >> 6762 to fix that. If they persist, will you depeer them >> as a security risk until they clean up their act? > > De-peering won't help if someone is propagating it as a transit customer > route. Filtering the prefix is all you can do. Taking this example, if I were to depeer 6762 becuase they can't keep their routing table clean to me, I suspect they would look at how to fix the issue. I could just filter their as-path globally until they contact me to resolve the issue. I'm not saying I would actually do that, but there is a question of what level of action should be taken to resolve these issues, and a timescale for their resolution. I've found some networks excellent to work with, and others "we'll stop leaking to you in a few days once we finish escalating the issue to our tier-n NOC in XXX city". Honestly, I find that to be kinda lazy considering how critical the routing infrasturcture is for our survival as an industry. > P.S. Obligatory BCP38 shout-out, even though it's not exactly on-point. I can't agree with this more, If you're not doing u-RPF on your customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be. The only excuses are broken software or incapable hardware from your vendor. Sadly those last two seem to impair the ability to take these basic network security requirements into account for a network of any size. It'll help reduce the possible attack home-base for various spoofing attacks (including some DNS one, did you hear about it?) - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From sean at donelan.com Wed Aug 13 16:09:54 2008 From: sean at donelan.com (Sean Donelan) Date: Wed, 13 Aug 2008 17:09:54 -0400 (EDT) Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> Message-ID: <200808131708110.2D3A1E03.13969@clifden.donelan.com> On Wed, 13 Aug 2008, Mikael Abrahamsson wrote: > We have prefix-filters on our customer bgp sessions, so that should be fairly > safe, but I see no good way of doing this towards peers as there is no > uniform way of doing this, and there is no industry consenus how it should be > done. Read your peering contract with the other ISP. It should cover what to do if this happens. What? you don't have a peering contract with the other ISP. Well I guess there is no requirement to keep the peering session established if the peer does stuff you don't want on your network. If it hurts when you do something, why do you keep doing it? From randy at psg.com Wed Aug 13 16:11:20 2008 From: randy at psg.com (Randy Bush) Date: Wed, 13 Aug 2008 14:11:20 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <48A34C98.1030309@karnaugh.za.net> References: <48A34C98.1030309@karnaugh.za.net> Message-ID: <48A34DF8.7050403@psg.com> > Can't IANA give $100000 stupidity tax perhaps those of us in glass houses should not suggest a major throwing of stones? :) From patrick at ianai.net Wed Aug 13 16:14:43 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Aug 2008 17:14:43 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080813210451.GI19971@puck.nether.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> Message-ID: On Aug 13, 2008, at 5:04 PM, Jared Mauch wrote: > On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote: >>> Sure. I'd also like to see providers actually just shut >>> off customers that originate stuff like ms-sql slammer >>> packets still. But it keeps flowing. I'm sure there are >>> smurf amps and other badness still going. codered anyone? >>> >>> these are all issues, but operational? depends. >> >> I beg to differ, this is absolutely operational. > > So, I should shut down or depeer networks that > continue to originate the crap to me? (packets, announcements). Saying something is Operational (and on-topic for nanog) does not mean you should de-peer them. That said, I will not stop you from de-peering a network who can't keep its table clean. Your network, your decision. >>> If LLNW is not being filtered by telecom italia, time for >>> 6762 to fix that. If they persist, will you depeer them >>> as a security risk until they clean up their act? >> >> De-peering won't help if someone is propagating it as a transit >> customer >> route. Filtering the prefix is all you can do. > > Taking this example, if I were to depeer 6762 becuase > they can't keep their routing table clean to me, I suspect > they would look at how to fix the issue. I could just filter their > as-path globally until they contact me to resolve the issue. You wield a much bigger hammer than 99.999% of the people here, and you know it. > I'm not saying I would actually do that, but there is > a question of what level of action should be taken to resolve > these issues, and a timescale for their resolution. I've found > some networks excellent to work with, and others "we'll stop > leaking to you in a few days once we finish escalating > the issue to our tier-n NOC in XXX city". > > Honestly, I find that to be kinda lazy considering how > critical the routing infrasturcture is for our survival as an > industry. While I doubt "shame" will work in all but the most extreme cases, I believe brokeness does, eventually have an impact. Let's just hope that impact is not blunted by (for instance) monopoly power, so that "voting with your wallet" will force network to fix things. Too bad we know monopoly power is blunting most of the effects. :( >> P.S. Obligatory BCP38 shout-out, even though it's not exactly on- >> point. > > I can't agree with this more, If you're not doing u-RPF on your > customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be. > The only > excuses are broken software or incapable hardware from your vendor. > > Sadly those last two seem to impair the ability to take these > basic network security requirements into account for a network of any > size. > > It'll help reduce the possible attack home-base for various spoofing > attacks (including some DNS one, did you hear about it?) Just thought I'd say "BCP38" again. -- TTFN, patrick From jared at puck.nether.net Wed Aug 13 16:20:47 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 13 Aug 2008 17:20:47 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <200808131708110.2D3A1E03.13969@clifden.donelan.com> References: <20080813204818.GG19971@puck.nether.net> <200808131708110.2D3A1E03.13969@clifden.donelan.com> Message-ID: <20080813212047.GA56126@puck.nether.net> On Wed, Aug 13, 2008 at 05:09:54PM -0400, Sean Donelan wrote: > On Wed, 13 Aug 2008, Mikael Abrahamsson wrote: >> We have prefix-filters on our customer bgp sessions, so that should be >> fairly safe, but I see no good way of doing this towards peers as there >> is no uniform way of doing this, and there is no industry consenus how >> it should be done. > > Read your peering contract with the other ISP. It should cover what to do > if this happens. > > What? you don't have a peering contract with the other ISP. Well I guess > there is no requirement to keep the peering session established if the > peer does stuff you don't want on your network. > > If it hurts when you do something, why do you keep doing it? two things: 1) I didn't mean to call out any specific provider, we all have challenges. Sorry to my friends at Cogent that may have been offeneded. 2) I think some people have been a bit too lax in enforcing their peering policies on this topic. Letting something leak for a few hours may not matter much for some small business or corner of the world. Leaking something important, or being nasty with it could be really bad. Imagine instead of spoofing some nameserver, annoucing the space and being rogue long enough to push out some huge TTL. Take whitehouse.gov out for the next 30 days.. Would make life interesting. I can think of other badness to do but won't enumerate it here. - Jared (dinner time!) -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From rs at seastrom.com Wed Aug 13 21:17:27 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 13 Aug 2008 22:17:27 -0400 Subject: SMS hinkiness on AT&T? Message-ID: Is anyone else seeing issues with multiple copies and delayed originals for SMSes on the AT&T network? I've been seeing this behavior for about the past 24-36 hours. This is phone-to-phone, not email-gateway stuff. Includes both new iPhones and people on T-Mobile as well as $random_att_handset. Given that our (royal we here) network monitoring is gatewayed directly via a phone... this is of some annoyance, to get interface transition and other alarms hours after the fact. I'm an old AT&T Blue customer if that makes a difference. Anyone? Bueller? -r From aaron at wholesaleinternet.net Wed Aug 13 21:30:43 2008 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Wed, 13 Aug 2008 21:30:43 -0500 Subject: SMS hinkiness on AT&T? In-Reply-To: References: Message-ID: <27a601c8fdb5$c08504b0$418f0e10$@net> I've been seeing the same thing on T-Mobil tonight. Aaron -----Original Message----- From: Robert E. Seastrom [mailto:rs at seastrom.com] Sent: Wednesday, August 13, 2008 9:17 PM To: nanog at nanog.org Cc: rs at seastrom.com Subject: SMS hinkiness on AT&T? Is anyone else seeing issues with multiple copies and delayed originals for SMSes on the AT&T network? I've been seeing this behavior for about the past 24-36 hours. This is phone-to-phone, not email-gateway stuff. Includes both new iPhones and people on T-Mobile as well as $random_att_handset. Given that our (royal we here) network monitoring is gatewayed directly via a phone... this is of some annoyance, to get interface transition and other alarms hours after the fact. I'm an old AT&T Blue customer if that makes a difference. Anyone? Bueller? -r From joelja at bogus.com Wed Aug 13 21:50:22 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 13 Aug 2008 19:50:22 -0700 Subject: SMS hinkiness on AT&T? In-Reply-To: References: Message-ID: <48A39D6E.3040108@bogus.com> Text sent too at&t customers appear ok from tmob or via @txt.att.net... I'm experiencing ~10 minute delays on texts originating on at&t handsets. joelja Robert E. Seastrom wrote: > Is anyone else seeing issues with multiple copies and delayed > originals for SMSes on the AT&T network? I've been seeing this > behavior for about the past 24-36 hours. > > This is phone-to-phone, not email-gateway stuff. Includes both new > iPhones and people on T-Mobile as well as $random_att_handset. Given > that our (royal we here) network monitoring is gatewayed directly via > a phone... this is of some annoyance, to get interface transition and > other alarms hours after the fact. > > I'm an old AT&T Blue customer if that makes a difference. > > Anyone? Bueller? > > -r > > From cmadams at hiwaay.net Wed Aug 13 21:50:55 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 13 Aug 2008 21:50:55 -0500 Subject: SMS hinkiness on AT&T? In-Reply-To: References: Message-ID: <20080814025055.GA1373409@hiwaay.net> Once upon a time, Robert E. Seastrom said: > Is anyone else seeing issues with multiple copies and delayed > originals for SMSes on the AT&T network? I've been seeing this > behavior for about the past 24-36 hours. We still have a monitoring system submitting messages via TAP, and AT&T started failing there as well about the same time. The TAP number we've been using returns busy most of the time and rejects most (but not all) messages when you do get connected. As near as we could tell, AT&T doesn't support TAP, so we've been looking at alternatives (like a GSM modem). However, if the problem is AT&T, I guess we might hold off. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From swmike at swm.pp.se Thu Aug 14 01:03:28 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Aug 2008 08:03:28 +0200 (CEST) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: References: Message-ID: On Wed, 13 Aug 2008, Mikael Abrahamsson wrote: > How do we hinder this in the short term? I know there are a lot of long > term solutions that very few is implementing, but would the fact that > these mistakes are brought up into the (lime)light by a public shaming > list make ISPs shape up and perform less mistakes? My thoughts on the prefix filtering issue would be that we need some kind of system that works along the same principles as DNSSEC and SPF, ie a holder of IP space can publish that they would like everybody to filter in a certain way for announcements for that perticular prefix, and then the other end can do so if they want to. This needs to be automatic and quick, ie a change in RADB policy should be reflected in the real world in minutes (preferrably) or hours (more realistically perhaps) and not in days or months. This might already be in place, I don't know other than RIPE, but in RIPE you can register a route object with a certain IP space, and IP space can have multiple route objects. The thing here is that to implement this policy in IOS creates *huge* rulesets that are really cumbersome and cluttery. Also, people tend not to rebuild these very often, so for customer routes, doing a handover between ISPs when moving PI space might involve outages and days of limited connectivity. Also, change of policy doesn't isn't reflected unless a route is cleared (soft though) which involves re-hashing a lot of routes very often if filters are updated often. I also think that the information in RADB doesn't really contain everything I would need in it, so it might need to be extended, but this is easier than getting a new framework into our routers (routing policy server?) that might work in near realtime. Is there work being done that could realistically be implemented anytime soon? Does benefit outweigh the potential catastrophies that might happen when rolling out and running such a system? Perhaps it's too late for IPv4 in this aspect, but it might be feasable for IPv6? Fewer prefixes and (hopefully) no break-outs, would mean PA blocks could be filtered hard, and if larger ISPs do hard filtering based on RADB, ISPs getting into IPv6 would need to get their prefixes properly registered there before getting IPv6 working to any extent. Anyhow, as people are continuing to use null routes to enforce regulatory demands (likely cause for the latest outages) this problem will most likely escalate. This would also help with problem I guess. -- Mikael Abrahamsson email: swmike at swm.pp.se From karnaugh at karnaugh.za.net Thu Aug 14 01:04:38 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 14 Aug 2008 08:04:38 +0200 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <48A34DF8.7050403@psg.com> References: <48A34C98.1030309@karnaugh.za.net> <48A34DF8.7050403@psg.com> Message-ID: <48A3CAF6.6080300@karnaugh.za.net> On 2008/08/13 11:11 PM Randy Bush wrote: >> Can't IANA give $100000 stupidity tax > > perhaps those of us in glass houses should not suggest a major throwing > of stones? :) Point taken ;) From jared at puck.nether.net Thu Aug 14 07:19:26 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Aug 2008 08:19:26 -0400 Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: References: Message-ID: <20080814121926.GG56126@puck.nether.net> On Thu, Aug 14, 2008 at 08:03:28AM +0200, Mikael Abrahamsson wrote: > On Wed, 13 Aug 2008, Mikael Abrahamsson wrote: > >> How do we hinder this in the short term? I know there are a lot of long >> term solutions that very few is implementing, but would the fact that >> these mistakes are brought up into the (lime)light by a public shaming >> list make ISPs shape up and perform less mistakes? > > My thoughts on the prefix filtering issue would be that we need some kind > of system that works along the same principles as DNSSEC and SPF, ie a > holder of IP space can publish that they would like everybody to filter > in a certain way for announcements for that perticular prefix, and then > the other end can do so if they want to. This needs to be automatic and > quick, ie a change in RADB policy should be reflected in the real world > in minutes (preferrably) or hours (more realistically perhaps) and not in > days or months. There was an idea years ago about utilizing a domain (rdi.int) for this. eg: dig any 267.rdi.int. > This might already be in place, I don't know other than RIPE, but in RIPE > you can register a route object with a certain IP space, and IP space can > have multiple route objects. The thing here is that to implement this Herein is the value, the RIR (RIPE) is also the holder of the policy. With ARIN, this is not the case, there is RADB and a number of other RR's that are out there for varying reasons, some personal and some business. > policy in IOS creates *huge* rulesets that are really cumbersome and > cluttery. Also, people tend not to rebuild these very often, so for > customer routes, doing a handover between ISPs when moving PI space might > involve outages and days of limited connectivity. Also, change of policy > doesn't isn't reflected unless a route is cleared (soft though) which > involves re-hashing a lot of routes very often if filters are updated > often. I think in this web 2.0 world, everything you're speaking of can be a challenge but not be impossible. The problem I see is there are no good tools. Take http://prefix.pch.net/ for example. This can help you audit the routes that are going to be placed in a prefix-list. How do you integrate something like this into your business policy? Have customers submit a web form for their routes? It's easy when your customer is AS267, but what if your customer is something larger like telstra? > Perhaps it's too late for IPv4 in this aspect, but it might be feasable > for IPv6? Fewer prefixes and (hopefully) no break-outs, would mean PA I think it's a matter of having a semi-uniform industry policy that is generally agreeable. I don't want to see the ANS-days case where you could not route without RADB and some fancy scripts probing their bay networks devices with snmp sets. But I do agree that we need a better toolset built. Now the question is, who can/will do this? How can it be shared? If I can make this backend uglyness called "RADB/irrd" invisible to my customers, will that help? > blocks could be filtered hard, and if larger ISPs do hard filtering based > on RADB, ISPs getting into IPv6 would need to get their prefixes properly > registered there before getting IPv6 working to any extent. > > Anyhow, as people are continuing to use null routes to enforce regulatory > demands (likely cause for the latest outages) this problem will most > likely escalate. > > This would also help with > problem I guess. Yeah, the challenge here is those that are unwilling to take action threaten the entire industry as it only takes a few bad actors to disrupt the network currently, and if you do it correctly, who is going to trust the infrastructure that we operate? - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jbates at brightok.net Thu Aug 14 07:39:10 2008 From: jbates at brightok.net (Jack Bates) Date: Thu, 14 Aug 2008 07:39:10 -0500 Subject: SMS hinkiness on AT&T? In-Reply-To: <20080814025055.GA1373409@hiwaay.net> References: <20080814025055.GA1373409@hiwaay.net> Message-ID: <48A4276E.4070806@brightok.net> > > As near as we could tell, AT&T doesn't support TAP, so we've been > looking at alternatives (like a GSM modem). However, if the problem is > AT&T, I guess we might hold off. > Not sure what you are using, but the official TAP number I found seems to always answer, but it does require that you have the enterprise paging service on the phone (which is like 10 bucks). A search of enterprise paging in AT&T's stuff gives you the info on TAP, as well as the various internet protocol's supported (which I prefer with TAP as fallback). Jack From eslerj at gmail.com Thu Aug 14 08:08:02 2008 From: eslerj at gmail.com (Joel Esler) Date: Thu, 14 Aug 2008 09:08:02 -0400 Subject: SMS hinkiness on AT&T? In-Reply-To: <48A4276E.4070806@brightok.net> References: <20080814025055.GA1373409@hiwaay.net> <48A4276E.4070806@brightok.net> Message-ID: <8c643a500808140608q7cbf3ac5of57f10602e4563e4@mail.gmail.com> Yes, I was getting delayed messages from AIM -> iPhone and back as well. (via sms).. On Thu, Aug 14, 2008 at 8:39 AM, Jack Bates wrote: > >> As near as we could tell, AT&T doesn't support TAP, so we've been >> looking at alternatives (like a GSM modem). However, if the problem is >> AT&T, I guess we might hold off. >> >> > Not sure what you are using, but the official TAP number I found seems to > always answer, but it does require that you have the enterprise paging > service on the phone (which is like 10 bucks). A search of enterprise paging > in AT&T's stuff gives you the info on TAP, as well as the various internet > protocol's supported (which I prefer with TAP as fallback). > > Jack > > -- --Joel Esler ISC Incident Handler http://www.joelesler.net From brandon at rd.bbc.co.uk Thu Aug 14 08:38:03 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 14 Aug 2008 14:38:03 +0100 (BST) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) Message-ID: <200808141338.OAA11603@sunf10.rd.bbc.co.uk> > > My thoughts on the prefix filtering issue would be that we need some kind > > of system that works along the same principles as DNSSEC and SPF, ie a > > holder of IP space can publish that they would like everybody to filter > > in a certain way for announcements for that perticular prefix, and then > > the other end can do so if they want to. http://blog.wired.com/27bstroke6/2008/08/experts-accuse.html "The Internet Assigned Numbers Authority -- which coordinates the internet -- has been prototyping a system to sign the root-zone file for the last year, but they can't do the same for the internet's top servers without approval from the Department of Commerce" Sounds like some work that could be recycled (and save being wasted if it's decided to have Verisign do the dnssec instead) > Herein is the value, the RIR (RIPE) is also the holder of the policy. > With ARIN, this is not the case, there is RADB and a number of other RR's > that are out there for varying reasons, some personal and some business. Yes, RIPE rock. Please make it all not suck. > I think in this web 2.0 world, everything you're speaking of > can be a challenge but not be impossible. The problem I see is there are > no good tools. In 2.0 world someone would make routetubebookparty and sell out to Google for millions, VCs line up here (the owner is as close to owning the internet as anyone) > This can help you audit the routes that are going to be placed > in a prefix-list. How do you integrate something like this into your > business policy? Have customers submit a web form for their routes? It's > easy when your customer is AS267, but what if your customer is something > larger like telstra? probably signed lumps of XML, people can make it however they want > If I can make this backend uglyness called "RADB/irrd" invisible > to my customers, will that help? I presume this would replace all the old stuff brandon From jared at puck.nether.net Thu Aug 14 09:56:58 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Aug 2008 10:56:58 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> Message-ID: <20080814145658.GD53528@puck.nether.net> On Wed, Aug 13, 2008 at 05:14:43PM -0400, Patrick W. Gilmore wrote: > Saying something is Operational (and on-topic for nanog) does not mean > you should de-peer them. If it's active and persistent, it would qualify as operational. Then I can classify the risk. I'm openly wondering if there should be more aggressive "turn the bad stuff off" happening. > That said, I will not stop you from de-peering a network who can't keep > its table clean. Your network, your decision. I'm still seeing persistent leaks, generally over 10k/day that are unresolved after a year of collecting this data. > You wield a much bigger hammer than 99.999% of the people here, and you > know it. I'm not posting as my employer, nor purporting to represent them, but at the same time, wonder what the impact would be if there were more consistent actions taken by networks when there was badness, either routing leak or otherwise. > While I doubt "shame" will work in all but the most extreme cases, I > believe brokeness does, eventually have an impact. Let's just hope that > impact is not blunted by (for instance) monopoly power, so that "voting > with your wallet" will force network to fix things. I certainly agree on the impact. If there were clear and predictable reactions to the brokeness, would people actually take actions to repair the problem? eg: 200.1.15.0/24 2914 6762 27648 3561 5511 6505 27782 What If I were to respond with a bgp notify (invalid as-path) to 6762 when they send this route to 2914? Doesn't matter if they're a customer or a peer, i may not want to get 3561 routes from you. > Just thought I'd say "BCP38" again. Router#conf t Router(config)#interface customer0/1 Router(config)# ip verify unicast source reachable-via rx - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From randy at psg.com Thu Aug 14 10:03:55 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2008 08:03:55 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080814145658.GD53528@puck.nether.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> Message-ID: <48A4495B.5020904@psg.com> ok, i can not hold my tongue. sorry. might there be a formally rigorous approach to this problem? we keep having it. perhaps there is something solid and real we could do, as opposed to temp hack after temp hack. randy From christian at broknrobot.com Thu Aug 14 10:34:42 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 14 Aug 2008 11:34:42 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <48A4495B.5020904@psg.com> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> Message-ID: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.8 (Darwin) Comment: http://getfiregpg.org owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857 s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0 yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2 IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx 6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn 1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu 7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0 Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq 4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD 4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc 6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm 6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw== =TITY -----END PGP MESSAGE----- On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush wrote: > ok, i can not hold my tongue. sorry. > > might there be a formally rigorous approach to this problem? we keep > having it. perhaps there is something solid and real we could do, as > opposed to temp hack after temp hack. > > randy > > From christian at broknrobot.com Thu Aug 14 10:37:36 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 14 Aug 2008 11:37:36 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> Message-ID: apologies for the encrypted email, pgp acting up.. --- pardon my ignorance, as i may not have the experience _most_ of you do in the SP community.. but, why wouldn't something like formally requiring customers/peers/transits/etc to have radb objects as a 'requirement' for peering/customer bgp services if you are a new customer and you sign up for bgp, it is clearly stated in the contract, the customer/provider requesting this service must maintain objects radb.. in the install process, if the customer does not have radb objects, bgp sessions remain shutdown until the provider verifies this and generates filters with rpsl tool same goes for peers.. if you don't require contracts as not all networks do, just require irr /radb objects, this one may be more of a pain, but thats why we go to scripts and automation.. maybe some more work would need to be done to ensure proper ownership and delegation of number resources in radb, but i dont think that would be so difficult, would it? if larger networks adapted to something like this, i think people would start to follow, as they would have no choice because they would be cut off from certain routes christian On Thu, Aug 14, 2008 at 11:34 AM, Christian Koch wrote: > -----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: http://getfiregpg.org > > owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857 > s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub > ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd > fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0 > yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj > jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ > vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q > bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2 > IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx > 6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok > MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF > eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc > kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn > 1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT > R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw > UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu > 7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL > kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU > q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0 > Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq > 4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O > rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD > 4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso > Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP > bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc > 6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt > UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm > 6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw== > =TITY > -----END PGP MESSAGE----- > > On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush wrote: >> ok, i can not hold my tongue. sorry. >> >> might there be a formally rigorous approach to this problem? we keep >> having it. perhaps there is something solid and real we could do, as >> opposed to temp hack after temp hack. >> >> randy >> >> > From virendra.rode at gmail.com Thu Aug 14 10:38:32 2008 From: virendra.rode at gmail.com (virendra rode //) Date: Thu, 14 Aug 2008 08:38:32 -0700 Subject: SMS hinkiness on AT&T? In-Reply-To: References: Message-ID: <48A45178.20309@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert E. Seastrom wrote: > Is anyone else seeing issues with multiple copies and delayed > originals for SMSes on the AT&T network? I've been seeing this > behavior for about the past 24-36 hours. - ----------------------- Some reported sbc outage on outages mailing list. Not sure if this has anything to do with the latency what you and others have and are experiencing. regards, /virendra > > This is phone-to-phone, not email-gateway stuff. Includes both new > iPhones and people on T-Mobile as well as $random_att_handset. Given > that our (royal we here) network monitoring is gatewayed directly via > a phone... this is of some annoyance, to get interface transition and > other alarms hours after the fact. > > I'm an old AT&T Blue customer if that makes a difference. > > Anyone? Bueller? > > -r > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIpFF4pbZvCIJx1bcRAl5sAJ92F4C4Dqy5XV5wzduAF/9thI9dUwCg6D6f qj0L7dcl11KOj/reuzCHXEE= =e78H -----END PGP SIGNATURE----- From jra at baylink.com Thu Aug 14 10:46:47 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 14 Aug 2008 11:46:47 -0400 Subject: SMS hinkiness on AT&T? In-Reply-To: <48A39D6E.3040108@bogus.com> References: <48A39D6E.3040108@bogus.com> Message-ID: <20080814154647.GG27167@cgi.jachomes.com> On Wed, Aug 13, 2008 at 07:50:22PM -0700, Joel Jaeggli wrote: > Text sent too at&t customers appear ok from tmob or via @txt.att.net... > I'm experiencing ~10 minute delays on texts originating on at&t handsets. I see intermittent but very regular delays myself from my Nextel Blackberry (MMS, not SMS), to and from several other networks, sometimes up to *hours*. I've always assumed that whatever gateway service connects the various carriers is simply incompetent. This might be better discussed on [outages]. 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. -- (Josef Stalin) From randy at psg.com Thu Aug 14 11:02:08 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2008 09:02:08 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> Message-ID: <48A45700.70302@psg.com> bottom line: the irr is a hack, not a formal solution. rand From brett at the-watsons.org Thu Aug 14 11:47:24 2008 From: brett at the-watsons.org (brett watson) Date: Thu, 14 Aug 2008 09:47:24 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <48A45700.70302@psg.com> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A45700.70302@psg.com> Message-ID: <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> On Aug 14, 2008, at 9:02 AM, Randy Bush wrote: > bottom line: the irr is a hack, not a formal solution. I don't think the IRR is so much a hack (it's a tool), but we're lacking the process and infrastructure to vet/validate that a given ASN is *authorized* to originate a prefix, and all of the policy bits (which the IRR has if you use it) associated with which ASNs should propagate the prefix, etc... We're lacking the authority and delegation model that DNS has, I think? -b From drc at virtualized.org Thu Aug 14 11:52:55 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 14 Aug 2008 09:52:55 -0700 Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: <200808141338.OAA11603@sunf10.rd.bbc.co.uk> References: <200808141338.OAA11603@sunf10.rd.bbc.co.uk> Message-ID: <95329A2C-5E2C-4BE9-ADB8-82FBEA52DE42@virtualized.org> Hi, On Aug 14, 2008, at 6:38 AM, Brandon Butterworth wrote: > http://blog.wired.com/27bstroke6/2008/08/experts-accuse.html > > "The Internet Assigned Numbers Authority -- which coordinates the > internet -- has been prototyping a system to sign the root-zone file > for the last year, but they can't do the same for the internet's top > servers without approval from the Department of Commerce" > > Sounds like some work that could be recycled (and save being wasted > if it's decided to have Verisign do the dnssec instead) Just to be clear, the stuff at https://ns.iana.org/dnssec/status.html will be used for more than the root, e.g., .ARPA, children of .ARPA, IANA.ORG, etc., regardless of who ends up signing the root. Regards, -drc From hannigan at verneglobal.com Thu Aug 14 12:01:26 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 14 Aug 2008 17:01:26 -0000 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com><48A45700.70302@psg.com> <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> Message-ID: > -----Original Message----- > From: brett watson [mailto:brett at the-watsons.org] > Sent: Thursday, August 14, 2008 12:47 PM > To: nanog at nanog.org > Subject: Re: Public shaming list for ISPs announcing other ISPs IP > space bymistake > > > On Aug 14, 2008, at 9:02 AM, Randy Bush wrote: > > > bottom line: the irr is a hack, not a formal solution. > > I don't think the IRR is so much a hack (it's a tool), but we're > lacking the process and infrastructure to vet/validate that a given > ASN is *authorized* to originate a prefix, and all of the policy bits > (which the IRR has if you use it) associated with which ASNs should > propagate the prefix, etc... > > We're lacking the authority and delegation model that DNS has, I think? Some of the RIR's have been working diligently on this stuff and you can see proposals, at least in the ARIN region, where there is a concerted effort at credentialing allocations. If you read between the lines and know the people and their funding sources, you can assume that there is a high level of attention to this, contrary to what we read in the press about DHS et. Al. Some of this activity is likely to tie into RIR transfer process i.e. the titling of ip address allocations. At least I think so. Disclaimer: This is a personal opinion only and I invite mailbox flames correcting. Best, -M< From andree+nanog at toonk.nl Thu Aug 14 12:04:01 2008 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 14 Aug 2008 19:04:01 +0200 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899BCB2.6050808@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> Message-ID: <20080814170401.GC25281@toonk.nl> Hi Randy, .-- My secret spy satellite informs me that at Thu, 07 Aug 2008, Randy Bush wrote: > serious curiosity: > > what is the proportion of bad stuff coming from unallocated space vs > allocated space? real measurements, please. and are there longitudinal > data on this? > > are the uw folk, gatech, vern, ... measuring? I did some measurements in The Netherlands (SURFnet) using netflow around 1,5 years ago. During this project around 86 million 'Bogon flows' were analyzed. This was not more then 0.1% (probably even lower) of all flows during that 1 week period. The majority of these flows were actually from/to RFC1918 address space. One of the things (amongst others) we looked at was SMTP traffic from / to bogons, to verify the theory that spammers announce a bogon prefix to sent spam. From the 86 million bogon flows analyzed, 12 SMTP flows were found, very minimal. Other things we looked at, were type of traffic (applications) & protocols and the sources of those flows. We saw some strange (interesting) things, but that was really just a few flows in many many many milions of flows. Anyways, if you're interested the research report can be found here: http://www.toonk.nl/bogon-traffic-analysis.pdf There's also a presentation http://www.toonk.nl/presentations.php Cheers, Andree -- Andree Toonk http://www.toonk.ca/blog/ From tkapela at gmail.com Thu Aug 14 12:06:55 2008 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 14 Aug 2008 12:06:55 -0500 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A45700.70302@psg.com> <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> Message-ID: <2e9d8ae50808141006k7e776d4cka308afbcc81015a2@mail.gmail.com> On Thu, Aug 14, 2008 at 11:47 AM, brett watson wrote: > We're lacking the authority and delegation model that DNS has, I think? Depends who you ask. Some think applying the dns model to bgp (i.e. within protocol) will ultimately place too great a burden on routing hardware & associated 'state' infrastructure. I tend to agree with that position. Perhaps the model we ought to be considering is something more akin to an external mechanism that automated systems (i.e. things to crank out prefix-lists/as-path lists) could draw from during 'refresh' periods, solely dedicated to authorizing prefixes against origin asn and/or as path (or name your $permutation_here). I.e. if said new system were to fail, it'd be great if it didn't affect routing in any way (we can live with a few days of stale lists, I think). Greene/Schiller, pipe up - this is your torch, right? -Tk From mleber at he.net Thu Aug 14 12:07:30 2008 From: mleber at he.net (Mike Leber) Date: Thu, 14 Aug 2008 10:07:30 -0700 Subject: [Fwd: Re: DNS attacks evolve] Message-ID: <48A46652.3050301@he.net> FYI. There was some question here about whether PowerDNS was vulnerable or not and what it was doing, so I asked Bert Hubert about it. Here is his answer: -------- Original Message -------- Subject: Re: [Fwd: Re: DNS attacks evolve] Date: Wed, 13 Aug 2008 21:29:50 +0200 From: bert hubert To: Mike Leber References: <48A08113.6010801 at he.net> On Mon, Aug 11, 2008 at 11:12:35AM -0700, Mike Leber wrote: > Is there any post anywhere that provides more technical detail about how > the PowerDNS cache is not vulnerable? Mike, very briefly, PowerDNS implements two things: source port randomization + near miss detection. Near miss detection is documented here: http://doc.powerdns.com/built-in-recursor.html spoof-nearmiss-max If set to non-zero, PowerDNS will assume it is being spoofed after seeing this many answers with the wrong id. Defaults to 20. Some more is in: http://doc.powerdns.com/recursor-details.html > I'll post a link to it and provide other operators a better answer than > the equivalent of "because I say so". The answer could be anything such > as "we reject updates to glue when", or "it takes 10 years based on > these calculations...". Calculations on how long it will take are on http://blog.netherlabs.nl/articles/2008/08/05/calculating-the-chance-of-spoofing-an-agile-source-port-randomised-resolver These calculations go beyond what powerdns 3.1.7 does however. > > If your vendor told you that you are not at risk they are wrong, > and need to go re-read the Kaminski paper. EVERYONE is vunerable, > the only question is if the attack takes 1 second, 1 minute, 1 hour > or 1 day. While possibly interesting for short term problem Or 1 year, or 2 years or a century. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- +---------------- 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 AS6939 | | mleber at he.net Internet Backbone & Colocation http://he.net | +---------------------------------------------------------------------+ From drc at virtualized.org Thu Aug 14 12:30:34 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 14 Aug 2008 10:30:34 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A45700.70302@psg.com> <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> Message-ID: <277AB04C-F387-42E6-B355-0CC10D730EC6@virtualized.org> On Aug 14, 2008, at 9:47 AM, brett watson wrote: > We're lacking the authority and delegation model that DNS has, I > think? If one were to ignore layer 9 politics, it could be argued the authority/delegation models between DNS and address space are quite analogous. DNS: IANA maintains "." ("dig @ns.iana.org . axfr") and delegates portions of the namespace to top-level domain registries Top-level domain registries delegate parts of their namespaces to second-level domain registries (typically end users) Address space: IANA maintains the top-level address registry (http://www.iana.org/assignments/ipv4-address-space/ and http://www.iana.org/assignments/ipv6-unicast-address- assignments) and delegates portions of the address space to RIRs. RIRs delegate parts of their address space to LIRs/ISPs/end users. Of course, ignoring layer 9 politics can be a bit challenging. Regards, -drc From david.freedman at uk.clara.net Thu Aug 14 13:21:41 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 14 Aug 2008 19:21:41 +0100 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> Message-ID: <48A477B5.1080803@uk.clara.net> > but, why wouldn't something like formally requiring > customers/peers/transits/etc to have radb objects as a 'requirement' > for peering/customer bgp services > Step 1 : Enforce IRR for customers *now*. Step 2 : Enforce trusted replacement for IRR when available Step 3 : Profit Not progressing to step 1 today because you think IRR isn't the best solution is like not deploying IPv6 because you sat on your arse not deploying it all these years and justify yourself by denouncing the protocol on every mailing list and IRC channel at every available opportunity. Dave. From michael.dillon at bt.com Thu Aug 14 13:09:38 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Aug 2008 19:09:38 +0100 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: Message-ID: > but, why wouldn't something like formally requiring > customers/peers/transits/etc to have radb objects as a 'requirement' > for peering/customer bgp services 'Cause there ain't nobody out there to "formally require" this. Other than ISPs, of course. And that means there will be umpteen different sets of rules, one set for each ISP. > if you are a new customer and you sign up for bgp, it is > clearly stated in the contract, the customer/provider > requesting this service must maintain objects radb.. In that case, no problem. But what about the contracts that do NOT state this? Who will change them? What language will they use? Who will coordinate the changes so that there is something halfway consistent? This is the problem Randy refers to when he talks about formal rigour. > if larger networks adapted to something like this, i think > people would start to follow, as they would have no choice > because they would be cut off from certain routes Larger peers started this way back about 15 years ago. Very few followed suit. What makes you think this will change? Operationally, the Internet is an anarchy. There is no formal organization of network providers that will set up working groups to define best practices in routing, in peering, etc. Instead, we have some areas where there *ARE* organizations applying formal rigor like email with MAAWG but that only happens with the real hot button issues. Everything else is left to simmer away in the anarchy. In Europe, the network operators that are also in the telecoms business, formed an organization called ETSI http://www.etsi.org to address a whole raft of inter-operator issues primarily focused on standards. There is no good reason why operators with Internet transit businesses should not form a similar organization to tackle the problems that come back again and again on the NANOG list, with only half measure and short term bandaid fixes being developed. You will note, that when ETSI was formed there was already an international telecom standards organization in operation called the ITU. But it had issues, and so folks went off and set up something that was more workable. When will NANOG participants smell the coffee and do likewise? The FCC will not rescue you. --Michael Dillon From michael.dillon at bt.com Thu Aug 14 13:13:50 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Aug 2008 19:13:50 +0100 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> Message-ID: > I don't think the IRR is so much a hack (it's a tool), but > we're lacking the process and infrastructure to vet/validate > that a given ASN is *authorized* to originate a prefix, and > all of the policy bits (which the IRR has if you use it) > associated with which ASNs should propagate the prefix, etc... > > We're lacking the authority and delegation model that DNS > has, I think? ARIN holds the top of that authority and delegation hierarchy because they give out the ASnums and IP address blocks. They also operate a suggestion box here: click the yellow button that says "Submit a Suggestion". There is a formal evaluation process behind that suggestion box so if there is one or more specific actions that you believe ARIN should take, then file a suggestion for each separate action that you want them to do. To everybody on the list, please do consider making formal suggestions to ARIN. --Michael Dillon From randy at psg.com Thu Aug 14 13:22:10 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2008 11:22:10 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <48A477B5.1080803@uk.clara.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> Message-ID: <48A477D2.6030806@psg.com> > Step 1 : Enforce IRR for customers *now*. > > Step 2 : Enforce trusted replacement for IRR when available > > Step 3 : Profit > > Not progressing to step 1 today because you think IRR isn't the best > solution is like not deploying IPv6 because you sat on your arse not > deploying it all these years and justify yourself by denouncing the > protocol on every mailing list and IRC channel at every available > opportunity. [ sorry for preaching. i know you are a fellow choir member ] for me it separates in to two things o what i do with my routers today. as you know, i have been pushing the irr and programmatic configuration since the mid '90s. that is your step 1. we have known how to do this for a decade. we don't need a bunch of talk. we need to shut up and hack. o what i do with my time. i don't have enough time to spend on both hacks and rigor, so i concentrate on the design and implementation of long-term formal and rigorous solutions, to which you allude in step 2. randy From brett at the-watsons.org Thu Aug 14 13:32:28 2008 From: brett at the-watsons.org (brett watson) Date: Thu, 14 Aug 2008 11:32:28 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <48A477B5.1080803@uk.clara.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> Message-ID: On Aug 14, 2008, at 11:21 AM, David Freedman wrote: > >> but, why wouldn't something like formally requiring >> customers/peers/transits/etc to have radb objects as a 'requirement' >> for peering/customer bgp services >> > > Step 1 : Enforce IRR for customers *now*. Right, but I think the bigger issue is not just that "data is in the IRR" but rather "the data is there, and "some organization" has validated that 1) the "owner" is authentic, 2) they own the prefixes they entered, 3) they are authorized to originate the prefixes, and 4) the policies they entered are valid and agreed to by the other parties." We have to be able to *trust* the data in the IRR, which I assume is one of the biggest impediments to being used by everyone: who's going to validate all that data and how will they do it? -b From drc at virtualized.org Thu Aug 14 13:54:57 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 14 Aug 2008 11:54:57 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: References: Message-ID: On Aug 14, 2008, at 11:13 AM, wrote: > ARIN holds the top of that authority and delegation hierarchy > because they give out the ASnums and IP address blocks. And here I thought IANA handed out ASnums and IP address blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and the IETF for specific protocol requirements)... Regards, -drc From jared at puck.nether.net Thu Aug 14 14:09:18 2008 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Aug 2008 15:09:18 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> Message-ID: <20080814190917.GI53528@puck.nether.net> On Thu, Aug 14, 2008 at 11:32:28AM -0700, brett watson wrote: > On Aug 14, 2008, at 11:21 AM, David Freedman wrote: > >> >>> but, why wouldn't something like formally requiring >>> customers/peers/transits/etc to have radb objects as a 'requirement' >>> for peering/customer bgp services >>> >> >> Step 1 : Enforce IRR for customers *now*. > > Right, but I think the bigger issue is not just that "data is in the > IRR" but rather "the data is there, and "some organization" has > validated that 1) the "owner" is authentic, 2) they own the prefixes > they entered, 3) they are authorized to originate the prefixes, and 4) > the policies they entered are valid and agreed to by the other parties." > > We have to be able to *trust* the data in the IRR, which I assume is one > of the biggest impediments to being used by everyone: who's going to > validate all that data and how will they do it? You're missing a step: janitor. No really, the reason for some leaks isn't because so-and-so was never a customer, they were. 5 years ago. nobody removed the routes from the IRR or AS-SET or and now the route is learned via some other location and it's bypassed your perimiter security and infiltrated your BGP. There's many simple things that makes it seem like it's an impossible task, but there's a saying, if you're not progressing you're regressing. If the toolset is too complex or doesn't work, what are YOU doing to make it better for you and/or your customers? - jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From bert.hubert at netherlabs.nl Thu Aug 14 14:06:08 2008 From: bert.hubert at netherlabs.nl (bert hubert) Date: Thu, 14 Aug 2008 21:06:08 +0200 Subject: [Fwd: Re: DNS attacks evolve] In-Reply-To: <48A46652.3050301@he.net> References: <48A46652.3050301@he.net> Message-ID: <20080814190607.GA25041@outpost.ds9a.nl> On Thu, Aug 14, 2008 at 10:07:30AM -0700, Mike Leber wrote: > FYI. There was some question here about whether PowerDNS was vulnerable > or not and what it was doing, so I asked Bert Hubert about it. Here is > his answer: And my additional nuance: By the way - just to nuance things, I'm sure PowerDNS can be spoofed too if enough effort is thrown into it. I'm working hard to implement the features that will allow me to state PowerDNS won't be spoofed "in a million years of trying". But I'm not there yet :-) Cheers, Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services From michael.dillon at bt.com Thu Aug 14 14:15:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Aug 2008 20:15:42 +0100 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: Message-ID: > On Aug 14, 2008, at 11:13 AM, > wrote: > > ARIN holds the top of that authority and delegation > hierarchy because > > they give out the ASnums and IP address blocks. > > And here I thought IANA handed out ASnums and IP address > blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and > the IETF for specific protocol requirements)... We are talking Internet operations, not Internet politics. You are right as far as that goes but it is ARIN et al. who hand out ASNums and IP addresses to the network operators who actually *USE* these numbers in operational networks. People don't care where the numbers came from, they care who actually got the rights to use them, and then what those orgs did with the rights, i.e. an IP addr block owner may delegate the rights to announce a subset of their space to a specific ASnum holder. Etc. --Michael Dillon From drc at virtualized.org Thu Aug 14 14:29:59 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 14 Aug 2008 12:29:59 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: References: Message-ID: <3BEED0C5-D6F2-4B8B-938A-9D67DCA14821@virtualized.org> On Aug 14, 2008, at 12:15 PM, wrote: >> And here I thought IANA handed out ASnums and IP address >> blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and >> the IETF for specific protocol requirements)... > We are talking Internet operations, not Internet politics. Indeed. > People don't care where the numbers came from, they care > who actually got the rights to use them, and then what > those orgs did with the rights, i.e. an IP addr block owner > may delegate the rights to announce a subset of their space > to a specific ASnum holder. Yep. And as with DNSSEC, you, as a network operator, get a choice. You can configure a single trust anchor corresponding to the actual address allocation flow and follow a chain of authority down to the leaf (end user or ISP) allocation or you can configure a number of trust anchors and figure out how to deal with cross-certifications resulting from the multiple roots. Ignoring politics, the technically and architecturally cleaner approach is obvious to me. However, as I mentioned, it is challenging to ignore the layer 9 politics. Regards, -drc From fernando at gont.com.ar Thu Aug 14 14:34:54 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 14 Aug 2008 16:34:54 -0300 Subject: Security Assessment of the Internet Protocol Message-ID: <200808141938.m7EJcfwH014853@venus.xmundo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, folks, The United Kingdom's Centre for the Protection of National Infrastructure has just released the document "Security Assessment of the Internet Protocol", on which I have had the pleasure to work during the last year or so. The motivation to produce this document is explained in the Preface of the document as follows: - ---- cut here ---- The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them. While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications. Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols. The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published. Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability. As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past. Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols. There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness. This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies. Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community. Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered. - ---- cut here ---- The document is available at CPNI's web site: http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx Any comments will be more than welcome. Kind regards, Fernando Gont -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) - not licensed for commercial use: www.pgp.com wsBVAwUBSKSBzGl+Jnd3SMmAAQhJPAgAq4SY+PG0ONFUsJDMWmadjKnG+LUSbyg6 Fnr/Up7HF59Z61r6/NXUG2TiUccu8u/ZE2ew7aUteAvbRM4sUWuQBlGXTRwgtv6S PKxOCQ5luLJjxDN9cKCN5KfpMmkCazoUXgno1PblKQH9CSxmZJxipsDWDLTMJHfU sGIwtX0bpgj4kWw+S3ycAwTRiwBApVYAZbzC58HwxhFbxZdLohGNdaAv8yuKskFP hzsEOfKSvcmoqLVE3kvm/8prjZhfocBcc/7Pr5RFugbP0dhUkLxye6GOiyY/tEzL XL3sDKc9lygfr/l1hk5ZDFpZcp0Rjw6REMo8MlojiM4+3qR1L2Ib8g== =xJ/e -----END PGP SIGNATURE----- -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dwendlan at cs.cmu.edu Thu Aug 14 14:57:11 2008 From: dwendlan at cs.cmu.edu (Dan Wendlandt) Date: Thu, 14 Aug 2008 12:57:11 -0700 Subject: New Tool for SSH and self-signed HTTPS Authentication Message-ID: <2dde77d60808141257u3d8b96d1n5c7a3b5693564ab@mail.gmail.com> Hi NANOG, Our research group at Carnegie Mellon has created a new tool called Perspectives to help authenticate remote hosts without requiring a full-blown PKI. Given the increased vulnerability to "man-in-the-middle" attacks due to the recent DNS issue, this tool seems relevant to anyone using SSH or HTTPS with self-signed certificates (It also can help clients avoid the annoying security error page Firefox 3 now shows for all sites using self-signed SSL certificates). http://www.cs.cmu.edu/~perspectives/ How it works: Perspectives uses network probes from multiple network locations and over time to get a better idea if the unauthenticated key your SSH client or browser received from the network is in fact the server's valid key. We have a few such probing servers, which we call "network notaries", scattered through the Internet, meaning that you can easily check if a key is likely to be valid even if it has not been signed by a certificate authority. The first time a notary is queried for a particular destination, they probe "on-demand" and return information about the key currently used by that sever. Once they know about a server, the notary will contact it daily to build up a history of the keys that server has used over time. Subsequent client queries can take advantage of historical key information as well. You can play with this approach using one of three "clients" we've created: * a web interface which shows a graphical timeline of the keys used by a server ( http://moo.cmcl.cs.cmu.edu/perspectives/ ) * a modified version of openSSH that contacts notaries and reports the results when the key received from the remove server differs from the cached key (http://www.cs.cmu.edu/~perspectives/openssh.html ) * a firefox extension (version 3+ only) that queries notaries and can override the annoying security error page firefox gives you for any self-signed certificate. ( http://www.cs.cmu.edu/~perspectives/firefox.html ) An academic paper and more general information is available at: http://www.cs.cmu.edu/~perspectives/ All the code is open-source and we welcome feedback. Thanks for your time, Dan Wendlandt & the Perspectives Team -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt 650-906-2650 http://www.cs.cmu.edu/~dwendlan/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vixie at isc.org Thu Aug 14 16:53:36 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 14 Aug 2008 21:53:36 +0000 Subject: ARIN is currently seeking nominations... Message-ID: <71823.1218750816@nsa.vix.com> ARIN encourages eligible members of the internet community to take part in nominating and electing candidates for its Board of Trustees, Advisory Council, and representatives on the Number Resource Organization Number Council. Please take the time to nominate qualified candidates for these positions. The call for nominations closes at 17:00 ET on Wednesday, 20 August 2008. ARIN is currently seeking nominations for the following positions: * Two (2) seats on the ARIN Board of Trustees * Five (5) seats on the ARIN Advisory Council * One (1) seat on the Number Resource Organization (NRO) Number Council Board of Trustees and Advisory Council: You must be a Trustee or ARIN General Member in good standing to make nominations for the Board of Trustees and Advisory Council. However, those nominated do not need to be ARIN members. Self-nominations are permitted. A petition process is available to nonmembers seeking to nominate themselves for the Board of Trustees. NRO Number Council: Any individual residing within the ARIN service region may be nominated, with the exception of Regional Internet Registry staff members. Self-nominations are permitted. Nominators are not required to be ARIN General Members in good standing. All nominees are subject to the Nomination and Appointment Conflict of Interest List at: http://www.arin.net/elections/electionguidelines.html#conflicts The nomination form is available through ARIN?s online Election Headquarters at: https://app.arin.net/election/ Regards, ARIN NomCom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jfmezei at vaxination.ca Thu Aug 14 21:42:04 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Thu, 14 Aug 2008 22:42:04 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: References: Message-ID: <48A4ECFC.5030109@vaxination.ca> Pardon my ignorance here, but wouldn't it be much simpler if the so called "tier 1" networks were to do the filtering work so that none of downstream BGP peers would see the bad announcements ? If some network in italy sends out some bogus route for a site, this should be blocked by a few tier 1 networks instead of by everybody at the bottom of the tree. Yeah, that would mean that folks in italy and whoever would have direct connections to that italian network would accept those bad BGP announcements, but the rest of the world would continue to work. "tier 1" networks like to brag about their importance within the internet, perhaps filtering bad announcments should be a responsability assigned to them, and which would further differentiate them from lesser networks. From smb at cs.columbia.edu Thu Aug 14 21:55:21 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 14 Aug 2008 22:55:21 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: <48A4ECFC.5030109@vaxination.ca> References: <48A4ECFC.5030109@vaxination.ca> Message-ID: <20080814225521.7d0ec2b7@cs.columbia.edu> On Thu, 14 Aug 2008 22:42:04 -0400 Jean-Fran__ois Mezei wrote: > Pardon my ignorance here, but wouldn't it be much simpler if the so > called "tier 1" networks were to do the filtering work so that none of > downstream BGP peers would see the bad announcements ? > > If some network in italy sends out some bogus route for a site, this > should be blocked by a few tier 1 networks instead of by everybody at > the bottom of the tree. Yeah, that would mean that folks in italy and > whoever would have direct connections to that italian network would > accept those bad BGP announcements, but the rest of the world would > continue to work. > > "tier 1" networks like to brag about their importance within the > internet, perhaps filtering bad announcments should be a > responsability assigned to them, and which would further > differentiate them from lesser networks. > Many of them -- most of them? -- do filter, to the extent that they can. However, they're in a poor position to do a complete job. If your peer is an end site, it's easy to filter what they send you; you know (or should know) what address blocks they have. (Verifying that they actually have the right to announce such blocks is a separate and difficult question, but I won't get into that here.) But what if your peer is another Tier 1, or even a lower-level ISP? How can you filter then? Another ISP can, will, and should announce routes to all of its customers, and it's quite hard (impossible, really) for the Tier 1s to track their peers' customers. Worse yet, some of these customers may themselves be ISPs, with their own customers. And if the peer of a Tier 1 is another Tier 1, it's not even possible to imagine how they'd know. --Steve Bellovin, http://www.cs.columbia.edu/~smb From danny at tcb.net Thu Aug 14 22:29:59 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 21:29:59 -0600 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <277AB04C-F387-42E6-B355-0CC10D730EC6@virtualized.org> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A45700.70302@psg.com> <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> <277AB04C-F387-42E6-B355-0CC10D730EC6@virtualized.org> Message-ID: <9E5C09B3-E508-43E9-A8B8-7BBEAC338248@tcb.net> On Aug 14, 2008, at 11:30 AM, David Conrad wrote: > On Aug 14, 2008, at 9:47 AM, brett watson wrote: >> We're lacking the authority and delegation model that DNS has, I >> think? > > > If one were to ignore layer 9 politics, it could be argued the > authority/delegation models between DNS and address space are quite > analogous. > TODAY IANA has an operational role in DNS, they don't have an operational role in Internet routing. This is certainly not layer 9, and most certainly the most fundamental change to the Internet routing system that RPKI or similar systems would introduce. To be clear: IANA and RIRs allocate or assign address space today, they don't control any routing on the Internet (and their own internal ASNs and IPs don't count). -danny From danny at tcb.net Thu Aug 14 22:30:32 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 21:30:32 -0600 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080814190917.GI53528@puck.nether.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> Message-ID: <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> On Aug 14, 2008, at 1:09 PM, Jared Mauch wrote: > > You're missing a step: > > janitor. > > No really, the reason for some leaks isn't because so-and-so was > never a customer, they were. 5 years ago. nobody removed the > routes from > the IRR or AS-SET or and now the route is > learned via > some other location and it's bypassed your perimiter security and > infiltrated your BGP. I agree, how many of you folks that use IRRs have ever deleted an IRR object? Heck, some ISPs even add them based on existence of advertised routes. -danny From danny at tcb.net Thu Aug 14 22:32:21 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 21:32:21 -0600 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: <48A4ECFC.5030109@vaxination.ca> References: <48A4ECFC.5030109@vaxination.ca> Message-ID: <859E39E4-0324-4B63-821A-24943D4C8CFF@tcb.net> On Aug 14, 2008, at 8:42 PM, Jean-Fran?ois Mezei wrote: > Pardon my ignorance here, but wouldn't it be much simpler if the so > called "tier 1" networks were to do the filtering work so that none of > downstream BGP peers would see the bad announcements ? > > If some network in italy sends out some bogus route for a site, this > should be blocked by a few tier 1 networks instead of by everybody at > the bottom of the tree. Yeah, that would mean that folks in italy and > whoever would have direct connections to that italian network would > accept those bad BGP announcements, but the rest of the world would > continue to work. Fine idea - how do they build these filter lists? > "tier 1" networks like to brag about their importance within the > internet, perhaps filtering bad announcments should be a > responsability > assigned to them, and which would further differentiate them from > lesser > networks. Tragedy of the commons... -danny From danny at tcb.net Thu Aug 14 22:43:31 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 21:43:31 -0600 Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: <20080814225521.7d0ec2b7@cs.columbia.edu> References: <48A4ECFC.5030109@vaxination.ca> <20080814225521.7d0ec2b7@cs.columbia.edu> Message-ID: <36C79002-121B-4C96-91CD-C828966E6831@tcb.net> A sneak-peek at some (NOT FINAL) relevant data points from the *ongoing* Infrastructure Security Survey related to this topic (see below for participation information, if so inclined). Draw your own conclusions, we'll make ours known in the final report. -danny --- Self classified respondent network type (approaching 50 responses): Tier 1: 13.95% Tier 2: 27.91% Pure Content Network: 11.63% Hosting Provider: 6.98% Education or Academic Network: 13.95% Enterprise or Hybrid Network: 2.33% Other: 23.26% --- Do you register routes you originate in an Internet routing registry (IRR)? Yes, our internal IRR: 13.95% Yes, a third-party IRR: 60.47% We use another type of internal database: 2.33% No, we do not register our routes: 18.60% Other: 4.65% --- Do you require your customers to register their routes in an IRR before you will accept them? Yes, our IRR: 9.30% Yes, a third-party IRR: 27.91% No, we use another type of route database: 9.30% No, we do not require customers to register routes they announce to us: 20.93% Other: 32.56% --- Do you explicitly filter routes announced to you by customers? Yes: 67.44% No: 20.93% Other: 11.63% --- Do you explicitly filter routes announced to you by peers (not customer peers)? Yes: 44.19% No: 41.86% Other: 13.95% --- Should prefixes allocated by RIRs be allowed to be used outside of the geographic area that the RIR is responsible for? Yes: 55.81% No: 30.23% Other: 13.95% ---------------------------- [snip] Folks, The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: I've added many questions this time from past participants of the survey, this should be evidenced throughout. Thanks to all those that reviewed and provided questions explicitly for this edition. The survey response window will be ~2 weeks. We hope to make the results available by the end of September at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2007 edition of the survey is available here: Or on the Arbor web site (reg required): Thanks in advance for your participation! -danny From danny at tcb.net Thu Aug 14 23:09:58 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 22:09:58 -0600 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <4899BCB2.6050808@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> Message-ID: <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> On Aug 6, 2008, at 9:01 AM, Randy Bush wrote: > > serious curiosity: > > what is the proportion of bad stuff coming from unallocated space vs > allocated space? real measurements, please. and are there > longitudinal > data on this? > > are the uw folk, gatech, vern, ... measuring? Some data from our anonymous stats program (currently ~90 ISPs) included below. In short, ~3% of 727k attacks we've seen over the last 631 days employed bogon source addresses. (definition of what constitutes "attack" is subjected to reporting participant operational policy, but these are primarily rate-based DDoS attacks) -danny --- General Statistics total_days 631 total_attacks 1137265 avg_attacks_day 1802 avg_collectors_day 47 avg_attacks_collector_day 38 total_good_attacks 727410 63.96% --- Bogon Summary bogon block attacks % of attacks 0.0.0.0/7 65 0.01 2.0.0.0/8 3 0.00 5.0.0.0/8 3 0.00 10.0.0.0/8 8794 1.21 23.0.0.0/8 4 0.00 27.0.0.0/8 7 0.00 92.0.0.0/6 101 0.01 100.0.0.0/6 374 0.05 104.0.0.0/5 303 0.04 112.0.0.0/5 775 0.11 120.0.0.0/8 45 0.01 127.0.0.0/8 6 0.00 172.16.0.0/12 3646 0.50 174.0.0.0/7 1 0.00 176.0.0.0/5 1 0.00 192.168.0.0/16 7451 1.02 223.0.0.0/8 10 0.00 224.0.0.0/3 8 0.00 bogonTotal 21597 2.97 From randy at psg.com Thu Aug 14 23:16:48 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Aug 2008 21:16:48 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> Message-ID: <48A50330.6060902@psg.com> > bogon block attacks % of attacks > 0.0.0.0/7 65 0.01 > 2.0.0.0/8 3 0.00 > 5.0.0.0/8 3 0.00 > 10.0.0.0/8 8794 1.21 > 23.0.0.0/8 4 0.00 > 27.0.0.0/8 7 0.00 > 92.0.0.0/6 101 0.01 > 100.0.0.0/6 374 0.05 > 104.0.0.0/5 303 0.04 > 112.0.0.0/5 775 0.11 > 120.0.0.0/8 45 0.01 > 127.0.0.0/8 6 0.00 > 172.16.0.0/12 3646 0.50 > 174.0.0.0/7 1 0.00 > 176.0.0.0/5 1 0.00 > 192.168.0.0/16 7451 1.02 > 223.0.0.0/8 10 0.00 > 224.0.0.0/3 8 0.00 well, we can see why andree wanted to look behind the 1918 stuff. it is the elephant. thanks, danny! randy From danny at tcb.net Thu Aug 14 23:55:17 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 22:55:17 -0600 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808061354530.28CAECBD.21371@clifden.donelan.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <200808061354530.28CAECBD.21371@clifden.donelan.com> Message-ID: On Aug 6, 2008, at 12:01 PM, Sean Donelan wrote: > > Attacks or misconfigured leaks? > > Leaks of RFC1918 stuff is pretty common, just ask any of the root > server operators how many packets they see from RFC1918 leaking > networks or do a > traceroute across several residential cable network backbones. > > Attacks aren't as common because there is enough (not 100%) anti- > spoofing (good) and/or bogon-filters (not as good) in different > parts of the Internet it requires more thought to launch a spoofed > DDOS than it does just to use tens of thousands of non-spoofed bots > to launch a DDOS. > > Arbor Networks has some data. I shared some data on bogon source appearances in *observed* attacks in another email. Orthogonal of that, here's the current Infrastructure Security Survey (again: see below for participation information, if so inclined) totals for questions related to BCP 38 and uRPF application among respondents. A pointer to a complete set of data across ~70 ISPs from last years survey is provided below. (Note: it's my opinion that one should assume at least a slightly more clue-dense respondent base than the larger network operator pool - i.e., the actual BCP 38/uRPF numbers are likely lower, and you're more clueful if you complete the survey :-) -danny ----- Self-classified respondent network type (approaching 50 responses): Tier 1: 13.33% Tier 2: 28.89% Pure Content Network: 11.11% Hosting Provider: 8.89% Education or Academic Network: 13.33% Enterprise or Hybrid Network: 2.22% Other: 22.22% --- Do you employ strict uRPF or BCP 38 on the dedicated customer edge of your network? Yes: 51.11% No: 33.33% Other: 15.56% --- Do you employ strict uRPF or BCP 38 style filters on the broadband edge of your network? Yes: 40.00% No: 33.33% Other: 26.67% --- Do you employ uRPF or BCP 38 style filters on the peering edge of your network? Yes: 46.67% No: 46.67% Other: 6.67% ---------------------------- [snip] Folks, The 2008 Infrastructure Security Survey is up and available for input. You can register to complete the survey at this URL: I've added many questions this time from past participants of the survey, this should be evidenced throughout. Thanks to all those that reviewed and provided questions explicitly for this edition. The survey response window will be ~2 weeks. We hope to make the results available by the end of September at the latest. Also, please recall that NO personally (or organizationally) identifiable information will be shared in any manner. The 2007 edition of the survey is available here: Or on the Arbor web site (reg required): Thanks in advance for your participation! -danny From drc at virtualized.org Thu Aug 14 23:59:40 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 14 Aug 2008 21:59:40 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <9E5C09B3-E508-43E9-A8B8-7BBEAC338248@tcb.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A45700.70302@psg.com> <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> <277AB04C-F387-42E6-B355-0CC10D730EC6@virtualized.org> <9E5C09B3-E508-43E9-A8B8-7BBEAC338248@tcb.net> Message-ID: <8B5DEEED-97ED-4318-AAC3-EB8C0BB032C7@virtualized.org> Danny, On Aug 14, 2008, at 8:29 PM, Danny McPherson wrote: >> On Aug 14, 2008, at 9:47 AM, brett watson wrote: >>> We're lacking the authority and delegation model that DNS has, I >>> think? >> If one were to ignore layer 9 politics, it could be argued the >> authority/delegation models between DNS and address space are quite >> analogous. > TODAY IANA has an operational role in DNS, they don't have > an operational role in Internet routing. Yep. IANA does indeed have a limited operational role in the DNS (in that currently IANA directly operates .int, ip6.arpa, urn.arpa, uri.arpa, and iris.arpa) and no direct operational role in routing. Of course, the statement was about the authority and delegation model, not about operational roles. > This is certainly not layer > 9, and most certainly the most fundamental change to the Internet > routing system that RPKI or similar systems would introduce. Not sure it is 'the most fundamental change', but it is indeed a significant change. That's sort of the point: RPKI is designed to allow for validation which isn't possible now. > To be clear: IANA and RIRs allocate or assign address space > today, they don't control any routing on the Internet (and their > own internal ASNs and IPs don't count). Indeed. And if RPKI is deployed in a way that is useful for validation of routing announcements in real time, this will obviously change, regardless of whether there is a single root for the address space or multiple roots. However, it seems to me that the decision as to whether there is a single root or multiple roots is deeply rooted (pun intended) in layer 9. But perhaps that's just me. Regards, -drc From pekkas at netcore.fi Fri Aug 15 00:06:01 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 15 Aug 2008 08:06:01 +0300 (EEST) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: <200808141338.OAA11603@sunf10.rd.bbc.co.uk> References: <200808141338.OAA11603@sunf10.rd.bbc.co.uk> Message-ID: On Thu, 14 Aug 2008, Brandon Butterworth wrote: >> Herein is the value, the RIR (RIPE) is also the holder of the policy. >> With ARIN, this is not the case, there is RADB and a number of other RR's >> that are out there for varying reasons, some personal and some business. > > Yes, RIPE rock. Please make it all not suck. Unfortunately, RIPE DB will allow anyone to add any route objects for prefixes that are not under the RIPE management :-(. For example, anyone could add route objects for most of DNS root server prefixes. For those prefixes that are managed by RIPE, it's good. But the above feature dilutes the trustworthiness of RIPE DB slightly... -- 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 danny at tcb.net Fri Aug 15 00:07:31 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 23:07:31 -0600 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <8B5DEEED-97ED-4318-AAC3-EB8C0BB032C7@virtualized.org> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A45700.70302@psg.com> <4AA0274E-6D92-4657-9273-4B74571D837C@the-watsons.org> <277AB04C-F387-42E6-B355-0CC10D730EC6@virtualized.org> <9E5C09B3-E508-43E9-A8B8-7BBEAC338248@tcb.net> <8B5DEEED-97ED-4318-AAC3-EB8C0BB032C7@virtualized.org> Message-ID: <14C7B541-ECDB-483F-BE6B-B1CFA46D0F70@tcb.net> On Aug 14, 2008, at 10:59 PM, David Conrad wrote: > > Yep. IANA does indeed have a limited operational role in the DNS > (in that currently IANA directly operates .int, ip6.arpa, urn.arpa, > uri.arpa, and iris.arpa) and no direct operational role in routing. > > Of course, the statement was about the authority and delegation > model, not about operational roles. > ... > Not sure it is 'the most fundamental change', but it is indeed a > significant change. That's sort of the point: RPKI is designed to > allow for validation which isn't possible now. > ... > Indeed. And if RPKI is deployed in a way that is useful for > validation of routing announcements in real time, this will > obviously change, regardless of whether there is a single root for > the address space or multiple roots. However, it seems to me that > the decision as to whether there is a single root or multiple roots > is deeply rooted (pun intended) in layer 9. > > But perhaps that's just me. OK, so we were talking past one another. I agree with everything you said above, and simply meant to highlight the fact that RPKI validation will change things (quite necessarily, IMO), and folks need to be paying attention to this. -danny From brandon at rd.bbc.co.uk Fri Aug 15 00:36:16 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 15 Aug 2008 06:36:16 +0100 (BST) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) Message-ID: <200808150536.GAA28924@sunf10.rd.bbc.co.uk> > > Yes, RIPE rock. Please make it all not suck. > > Unfortunately, RIPE DB will allow anyone to add any route objects for > prefixes that are not under the RIPE management :-(. For example, > anyone could add route objects for most of DNS root server prefixes. Little details get used to avoid fixing bigger problems, see the please stop sucking bit. If there was somewhere else the aliens had to be registered then they could be dropped from RIPE brandon From fergdawg at netzero.net Fri Aug 15 00:37:56 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Fri, 15 Aug 2008 05:37:56 GMT Subject: Public shaming list for ISPs announcing other ISPs IP space by mis take Message-ID: <20080814.223756.21174.0@webmail19.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Danny McPherson wrote: >OK, so we were talking past one another. I agree with everything >you said above, and simply meant to highlight the fact that RPKI >validation will change things (quite necessarily, IMO), and folks >need to be paying attention to this. Okay, I admit I haven't paid the closest attention to RPKI, but I have to ask: Is this a two-way shared-key issue, or (worse) a case where we need to rely on a central entity to be a key clearinghouse? The reason why I mention this is obvious -- the entire PKI effort has been stalled (w.r.t. authority) because of this particular issue. Any thoughts on that? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIpRYsq1pz9mNUZTMRArLnAKC5C6uLw3khwDreYlWw3m3vEmYJAACg81By z3hYv0xseQegh/2yzYbeARw= =/xK7 -----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 danny at tcb.net Fri Aug 15 00:44:50 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 14 Aug 2008 23:44:50 -0600 Subject: Public shaming list for ISPs announcing other ISPs IP space by mis take In-Reply-To: <20080814.223756.21174.0@webmail19.vgs.untd.com> References: <20080814.223756.21174.0@webmail19.vgs.untd.com> Message-ID: On Aug 14, 2008, at 11:37 PM, Paul Ferguson wrote: >> > Okay, I admit I haven't paid the closest attention to RPKI, but I > have to ask: Is this a two-way shared-key issue, or (worse) a case > where we need to rely on a central entity to be a key clearinghouse? > > The reason why I mention this is obvious -- the entire PKI effort > has been stalled (w.r.t. authority) because of this particular > issue. > > Any thoughts on that? See Randy et al's presentation here: In short, the latter, which is precisely DRC's point. -danny From swmike at swm.pp.se Fri Aug 15 02:01:27 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 15 Aug 2008 09:01:27 +0200 (CEST) Subject: Public shaming list for ISPs announcing other ISPs IP space bymistake In-Reply-To: <20080814225521.7d0ec2b7@cs.columbia.edu> References: <48A4ECFC.5030109@vaxination.ca> <20080814225521.7d0ec2b7@cs.columbia.edu> Message-ID: On Thu, 14 Aug 2008, Steven M. Bellovin wrote: > Many of them -- most of them? -- do filter, to the extent that they can. > However, they're in a poor position to do a complete job. What I would like is to be able to filter prefixes on the basis of the AS-path/prefix combination, and have this in a signed fashion. So let's say an ISP has AS1 and their upstreams are AS2 and AS3. They have 10.0.5.0/16. They will then publish a routing policy that AS* (any AS) should only accept 10.0.5.0/16 originated from AS1, and no more specifics, but AS2 and AS3 should accept more specifics down to /24 (for granular traffic control). For this to be secure, I guess the announcement needs some kind of cryptographic verification, but I don't know much about that, but that should be used as well, but even without it we stop the possibility of human error announcing breakouts or that /16 by someone else. Now, building existing prefix/AS-path lists based on the above information isn't feasable. We have ~30k ASN live and 270k prefixes so the amount of lines in a config is just unfeasable, which means we need some kind of new strategy to handle all this policy information. I guess having some kind of policy server which receives routes and then can tell routers to ignore them if they don't adhere to policy might work if the routes seen which is not according to policy are few, but if they become many then we run into the same scaling problem again. So perhaps this problem can't be solved by anything existing, but instead we need new functionality in our routers to handle this problem? So time to market on this is in the years, but if we don't start work on it it'll never get done. But I do feel that any long-term solution needs to be distributed and implemented on a per ASN basis, where participating ASNs doesn't have to be directly connected to each other... -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Fri Aug 15 04:39:22 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 15 Aug 2008 10:39:22 +0100 Subject: Validating rights to announce a prefix (was: Public shaming...) In-Reply-To: <9E5C09B3-E508-43E9-A8B8-7BBEAC338248@tcb.net> Message-ID: > To be clear: IANA and RIRs allocate or assign address space > today, they don't control any routing on the Internet (and > their own internal ASNs and IPs don't count). And that gets to the heart of the issue that I raised. Since the RIRs allocate ASnums and IP address blocks, they are in a position to validate who has the right to use the numbers. And if you want to validate who has the right to announce a specific address prefix, you really want to start by determining who owns the prefix, and then go to them and find out what rights they have delegated. This puts the RIRs at the root of the validation chain. Although you could attempt to build the rest of the system, without formal validation by the RIRs, you still have holes that you can drive a truck through. That is the experience of projects like IRR/RADB etc. Rather than rushing off and hacking up some code, is it possible for a group of network operators to meet formally, in some venue or other, and set out the requirements for such a system and the architecture of such a system? --Michael Dillon From michael.dillon at bt.com Fri Aug 15 04:54:39 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 15 Aug 2008 10:54:39 +0100 Subject: Validating rights to announce a prefix (was: Public shaming...) In-Reply-To: <20080814.223756.21174.0@webmail19.vgs.untd.com> Message-ID: > Okay, I admit I haven't paid the closest attention to RPKI, > but I have to ask: Is this a two-way shared-key issue, or > (worse) a case where we need to rely on a central entity to > be a key clearinghouse? > > The reason why I mention this is obvious -- the entire PKI > effort has been stalled (w.r.t. authority) because of this > particular issue. Who says there needs to be a PKI infrastructure in order to do this? There are other ways of authenticating data. For instance ARIN could hold the data that they have validated on their own servers and people could use HTTPS queries to ensure that they get the answers that they thought they would get. As for how the address owner delegates the right to announce a prefix, they could either operate their own database and ARIN would have a pointer to it, or they could register the data in ARIN's database by some secure means. There is no reason why "secure means" could not include various out of band authentication systems. People are too hung up on cryotographically secure PKI systems which are way overkill for this problem. In fact, it should be possible to design an architecture that allows for an easy upgrade to PKI if it should be determined at some future date, that PKI is necessary. --Michael Dillon From robert at ripe.net Fri Aug 15 05:09:07 2008 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 15 Aug 2008 12:09:07 +0200 Subject: Validating rights to announce a prefix In-Reply-To: References: Message-ID: <48A555C3.3050805@ripe.net> michael.dillon at bt.com wrote: > Rather than rushing off and hacking up some code, is it possible > for a group of network operators to meet formally, in some venue > or other, and set out the requirements for such a system and the > architecture of such a system? > > --Michael Dillon > You might want to take a look at the IETF SIDR working group's efforts. Robert From robert at ripe.net Fri Aug 15 05:17:17 2008 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 15 Aug 2008 12:17:17 +0200 Subject: Validating rights to announce a prefix In-Reply-To: References: Message-ID: <48A557AD.5030409@ripe.net> michael.dillon at bt.com wrote: >> Okay, I admit I haven't paid the closest attention to RPKI, >> but I have to ask: Is this a two-way shared-key issue, or >> (worse) a case where we need to rely on a central entity to >> be a key clearinghouse? >> >> The reason why I mention this is obvious -- the entire PKI >> effort has been stalled (w.r.t. authority) because of this >> particular issue. > > Who says there needs to be a PKI infrastructure in order to > do this? There are other ways of authenticating data. For instance > ARIN could hold the data that they have validated on their own > servers and people could use HTTPS queries to ensure that they > get the answers that they thought they would get. I must point out that HTTPS is still in PKI land - it's just "another one", inviting otherwise unrelated parties (like Verisign et al.) into the system. > As for how the address owner delegates the right to announce > a prefix, they could either operate their own database and > ARIN would have a pointer to it, or they could register the > data in ARIN's database by some secure means. There is no > reason why "secure means" could not include various out of > band authentication systems. The principles for this are included in the SIDR efforts. > People are too hung up on cryotographically secure PKI systems > which are way overkill for this problem. In fact, it should be > possible to design an architecture that allows for an easy upgrade > to PKI if it should be determined at some future date, that PKI > is necessary. It's hard to switch to a more secure method later on if you start with a less secure one. So, "upgrading" to PKI from something else only makes sense if that previous system was secure enough - but then why would you want to change? Robert > --Michael Dillon From michael.dillon at bt.com Fri Aug 15 05:29:25 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 15 Aug 2008 11:29:25 +0100 Subject: Validating rights to announce a prefix In-Reply-To: <48A557AD.5030409@ripe.net> Message-ID: > It's hard to switch to a more secure method later on if you > start with a less secure one. So, "upgrading" to PKI from > something else only makes sense if that previous system was > secure enough - but then why would you want to change? If the delegation information expires, which it should to ensure that it still is current, then it should not be so hard to upgrade the security of the system. As for why, that's so that people will actually start using the system instead of fretting about who holds the keys to it all. Similarly, this should all be about OSS systems, and not touch any routers or BGP processes at all. It is up to the individual ISP to decide how they want to use the information and how and when they want to push it into their BGP speaking routers. --Michael Dillon From pekkas at netcore.fi Fri Aug 15 05:56:09 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 15 Aug 2008 13:56:09 +0300 (EEST) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: <200808150536.GAA28924@sunf10.rd.bbc.co.uk> References: <200808150536.GAA28924@sunf10.rd.bbc.co.uk> Message-ID: On Fri, 15 Aug 2008, Brandon Butterworth wrote: >>> Yes, RIPE rock. Please make it all not suck. >> Unfortunately, RIPE DB will allow anyone to add any route objects for >> prefixes that are not under the RIPE management :-(. For example, >> anyone could add route objects for most of DNS root server prefixes. > > Little details get used to avoid fixing bigger problems, see the > please stop sucking bit. > > If there was somewhere else the aliens had to be registered then they > could be dropped from RIPE I'm not sure I follow. Many of these aliens are in fact registered in RADB, so AFAICS, there that is no reason for them to be registered in RIPE DB. On the other hand, some want to register them in RIPE DB because some operators just want to use RIPE DB e.g. for data consistency etc. reasons. But putting data without practically any authorization in RIPE DB doesn't seem to be a useful model in the long run. -- 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 jmalcolm at uraeus.com Fri Aug 15 06:53:23 2008 From: jmalcolm at uraeus.com (Joe Malcolm) Date: Fri, 15 Aug 2008 11:53:23 +0000 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080814190917.GI53528@puck.nether.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> Message-ID: <18597.28211.273810.703403@shoggoth.uraeus.com> Jared Mauch writes: > No really, the reason for some leaks isn't because so-and-so was >never a customer, they were. 5 years ago. nobody removed the routes from >the IRR or AS-SET or and now the route is learned via >some other location and it's bypassed your perimiter security and >infiltrated your BGP. The issue of cleaning up legacy state for former customers applies to many things beyond route announcements - though the latter may be one of the more visible remnants. I suspect relatively few companies can accurately and completely track the state associated with a customer such that it can be removed once the customer billing stops. (Or they stop paying.) This really needs to be automated and the backend databases need a way to associate records with particular billing entities, or else you will find yourself slowly cleaning up after past customers at inconvenient moments for years. Joe From cidr-report at potaroo.net Fri Aug 15 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Aug 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200808151200.m7FC0438063811@wattle.apnic.net> BGP Update Report Interval: 14-Jul-08 -to- 14-Aug-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 95373 1.5% 19.0 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS1803 87115 1.4% 68.2 -- ICMNET-5 - Sprint 3 - AS9583 84127 1.3% 67.0 -- SIFY-AS-IN Sify Limited 4 - AS6298 75314 1.2% 35.7 -- COX-PHX - Cox Communications Inc. 5 - AS5691 74595 1.2% 6781.4 -- MITRE-AS-5 - The MITRE Corporation 6 - AS9051 69280 1.1% 441.3 -- IDM Autonomous System 7 - AS10396 66996 1.1% 1339.9 -- COQUI-NET - DATACOM CARIBE, INC. 8 - AS4766 50082 0.8% 56.7 -- KIXS-AS-KR Korea Telecom 9 - AS17488 48207 0.8% 34.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 10 - AS33783 46405 0.7% 281.2 -- EEPAD 11 - AS8151 46142 0.7% 30.2 -- Uninet S.A. de C.V. 12 - AS4788 40621 0.6% 18.9 -- TMNET-AS-AP TM Net, Internet Service Provider 13 - AS8866 39117 0.6% 122.2 -- BTC-AS Bulgarian Telecommunication Company Plc. 14 - AS17974 38238 0.6% 58.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 15 - AS14522 34635 0.6% 169.0 -- Satnet 16 - AS3464 33796 0.5% 90.4 -- ASC-NET - Alabama Supercomputer Network 17 - AS9929 33628 0.5% 106.8 -- CNCNET-CN China Netcom Corp. 18 - AS18231 29153 0.5% 118.0 -- EXATT-AS-AP IOL NETCOM LTD 19 - AS7738 28702 0.5% 107.5 -- Telecomunicacoes da Bahia S.A. 20 - AS47467 26561 0.4% 13280.5 -- GRIFFEL Griffel AB TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47467 26561 0.4% 13280.5 -- GRIFFEL Griffel AB 2 - AS27245 14296 0.2% 7148.0 -- HEIDRICK-CHICAGO - HEIDRICK 3 - AS5691 74595 1.2% 6781.4 -- MITRE-AS-5 - The MITRE Corporation 4 - AS29910 6463 0.1% 6463.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS22678 3947 0.1% 3947.0 -- OSDE 6 - AS39105 3891 0.1% 3891.0 -- CLASS-AS SC Class Computers And Service SRL 7 - AS23082 18722 0.3% 3744.4 -- MPHI - Michigan Public Health Institute 8 - AS40627 7463 0.1% 3731.5 -- RC-COLO1 - RingCentral Inc 9 - AS28361 3288 0.1% 3288.0 -- 10 - AS28194 18411 0.3% 2301.4 -- 11 - AS30929 2039 0.0% 2039.0 -- HUTCB Hidrotechnical Faculty - Technical University 12 - AS39748 2035 0.0% 2035.0 -- VITAS VITAS LLC 13 - AS5382 2001 0.0% 2001.0 -- TELESYSTEM-NET Planet Service Srl 14 - AS30969 20206 0.3% 1836.9 -- TAN-NET TransAfrica Networks 15 - AS28542 1750 0.0% 1750.0 -- Gobierno del Estado de Coahuila 16 - AS39794 1684 0.0% 1684.0 -- EL-KOZIENICE-AS Elektrownia Kozienice S.A. 17 - AS44194 1656 0.0% 1656.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 18 - AS39244 1655 0.0% 1655.0 -- TEQNOBASE-AS Teqnobase AS 19 - AS23917 1616 0.0% 1616.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 20 - AS42380 1605 0.0% 1605.0 -- ERGOLT-AS ERGO LIETUVA UADB TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 74455 1.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 63100 0.9% AS9583 -- SIFY-AS-IN Sify Limited 3 - 194.126.143.0/24 61857 0.9% AS9051 -- IDM Autonomous System 4 - 83.228.71.0/24 31718 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.128.192.0/18 25501 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 72.50.96.0/20 24581 0.4% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 7 - 196.42.0.0/20 15045 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 8 - 62.182.216.0/21 13290 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 9 - 91.203.160.0/22 13281 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 10 - 63.84.91.0/24 13136 0.2% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 11 - 203.63.26.0/24 10669 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 196.27.104.0/21 10087 0.1% AS30969 -- TAN-NET TransAfrica Networks AS8668 -- TELONE-AS TelOne Zimbabwe P/L 13 - 196.27.108.0/22 9846 0.1% AS30969 -- TAN-NET TransAfrica Networks 14 - 83.239.192.0/21 8961 0.1% AS42362 -- ALANIA-AS Sevosetinelectrosvyaz 15 - 216.255.56.0/21 8955 0.1% AS7106 -- OHIOBRIGHTNET - Com Net, Inc. 16 - 202.150.80.0/20 8752 0.1% AS9251 -- SPEEDNET-AP PT Speed Internet Digital 17 - 196.42.48.0/20 8109 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 18 - 72.50.112.0/20 8046 0.1% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 19 - 203.202.140.128/ 6993 0.1% AS7474 -- OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 20 - 148.208.211.0/24 6962 0.1% AS8151 -- Uninet S.A. de C.V. 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 Aug 15 07:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Aug 2008 22:00:01 +1000 (EST) Subject: The Cidr Report Message-ID: <200808151200.m7FC01tt063793@wattle.apnic.net> This report has been generated at Fri Aug 15 21:17:41 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 08-08-08 275536 174033 09-08-08 277076 174082 10-08-08 277111 174109 11-08-08 277184 174315 12-08-08 277411 174839 13-08-08 277665 175560 14-08-08 278090 175338 15-08-08 277664 174543 AS Summary 29073 Number of ASes in routing system 12284 Number of ASes announcing only one prefix 5013 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88346112 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'). --- 15Aug08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 277853 174589 103264 37.2% All ASes AS4538 5013 877 4136 82.5% ERX-CERNET-BKB China Education and Research Network Center AS6389 3200 260 2940 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2893 668 2225 76.9% ASN-QWEST - Qwest AS4755 1701 292 1409 82.8% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS17488 1300 328 972 74.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1045 108 937 89.7% COVAD - Covad Communications Co. AS8151 1509 595 914 60.6% Uninet S.A. de C.V. AS6298 2004 1104 900 44.9% COX-PHX - Cox Communications Inc. AS22773 959 91 868 90.5% CCINET-2 - Cox Communications Inc. AS4323 1489 704 785 52.7% TWTC - tw telecom holdings, inc. AS1785 1454 741 713 49.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS11492 1214 501 713 58.7% CABLEONE - CABLE ONE AS19262 937 242 695 74.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1563 913 650 41.6% INS-AS - AT&T Data Communications Services AS9498 674 106 568 84.3% BBIL-AP BHARTI Airtel Ltd. AS6478 1034 486 548 53.0% ATT-INTERNET3 - AT&T WorldNet Services AS18101 692 163 529 76.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6197 954 477 477 50.0% BATI-ATL - BellSouth Network Solutions, Inc AS4766 884 417 467 52.8% KIXS-AS-KR Korea Telecom AS4808 617 154 463 75.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS22047 565 129 436 77.2% VTR BANDA ANCHA S.A. AS855 591 157 434 73.4% CANET-ASN-4 - Bell Aliant AS9443 523 91 432 82.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1432 1007 425 29.7% ATT-INTERNET4 - AT&T WorldNet Services AS4134 836 421 415 49.6% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 564 152 412 73.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7029 536 135 401 74.8% WINDSTREAM - Windstream Communications Inc AS4780 720 324 396 55.0% SEEDNET Digital United Inc. AS17676 524 142 382 72.9% GIGAINFRA BB TECHNOLOGY Corp. AS3602 450 78 372 82.7% AS3602-RTI - Rogers Telecom Inc. Total 37877 11863 26014 68.7% Top 30 total Possible Bogus Routes 14.14.14.0/24 AS577 BACOM - Bell Canada 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.53.86.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.55.0.0/18 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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 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.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 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 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.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.101.80.0/20 AS42926 RADORETELEKOM Radore Autonomous System 94.101.96.0/23 AS44836 SU155-AS SU-155 JSC 94.101.98.0/23 AS44836 SU155-AS SU-155 JSC 94.101.100.0/23 AS44836 SU155-AS SU-155 JSC 94.101.102.0/23 AS44836 SU155-AS SU-155 JSC 94.101.104.0/23 AS44836 SU155-AS SU-155 JSC 94.101.106.0/23 AS44836 SU155-AS SU-155 JSC 94.101.108.0/23 AS44836 SU155-AS SU-155 JSC 94.101.110.0/23 AS44836 SU155-AS SU-155 JSC 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 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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/16 AS8546 YOUR-COMMS-UK-AS Your Communications Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 AS2018 TENET-1 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.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.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 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.254.192.0/19 AS2116 ASN-CATCHCOM Catch Communications 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.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 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.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.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 - tw telecom holdings, 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.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, 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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.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. 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 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 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.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 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 rs at seastrom.com Fri Aug 15 07:22:56 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 08:22:56 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A50330.6060902@psg.com> (Randy Bush's message of "Thu, 14 Aug 2008 21:16:48 -0700") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> Message-ID: <86tzdmzcv3.fsf@seastrom.com> Randy Bush writes: >> bogon block attacks % of attacks >> 0.0.0.0/7 65 0.01 >> 2.0.0.0/8 3 0.00 >> 5.0.0.0/8 3 0.00 >> 10.0.0.0/8 8794 1.21 >> 23.0.0.0/8 4 0.00 >> 27.0.0.0/8 7 0.00 >> 92.0.0.0/6 101 0.01 >> 100.0.0.0/6 374 0.05 >> 104.0.0.0/5 303 0.04 >> 112.0.0.0/5 775 0.11 >> 120.0.0.0/8 45 0.01 >> 127.0.0.0/8 6 0.00 >> 172.16.0.0/12 3646 0.50 >> 174.0.0.0/7 1 0.00 >> 176.0.0.0/5 1 0.00 >> 192.168.0.0/16 7451 1.02 >> 223.0.0.0/8 10 0.00 >> 224.0.0.0/3 8 0.00 > > well, we can see why andree wanted to look behind the 1918 stuff. it is > the elephant. > > thanks, danny! > > randy In other words, our earlier estimate of 60% was way off... you can get 92.1% effectiveness at bogon filtering by just dropping 1918 addresses, a filter that you will never have to change. What's the operational cost trade-off with going after that remaining 7.9%? I'll betcha it's not justifiable. Maybe it's time to change the best current practices we recommend so that they stop biting us in the ass every time a chunk of our ever-dwindling pool of unused address space goes into play. My uncle used to tell this joke: Q: Why did the man hit himself in the head with a hammer? A: Because it felt so good when he stopped? -r From brandon at rd.bbc.co.uk Fri Aug 15 08:16:01 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 15 Aug 2008 14:16:01 +0100 (BST) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) Message-ID: <200808151316.OAA10074@sunf10.rd.bbc.co.uk> > I'm not sure I follow. I agreed with you. > Many of these aliens are in fact registered in > RADB, so AFAICS, there that is no reason for them to be registered in > RIPE DB. > > On the other hand, some want to register them in RIPE DB because some > operators just want to use RIPE DB e.g. for data consistency etc. > reasons. But putting data without practically any authorization in > RIPE DB doesn't seem to be a useful model in the long run. As the reason they should not be in RIPE is RIPE doesn't hold the ownership data I suggested they move to a RIPE alike which does hold their ownership, afaik RADB doesn't Seems pretty simple, RIPE delegates the space and maintains owners so is a natural place for their owner to record their allowed use. So ARIN and others need to do the same, thus all space is covered and then can me munged into whatever will enforce the use be it router based signed advertisements or an out of band system that applies controls to the routers directly or via a humanoid. brandon From randy at psg.com Fri Aug 15 08:24:52 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 06:24:52 -0700 Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: References: <200808150536.GAA28924@sunf10.rd.bbc.co.uk> Message-ID: <48A583A4.1010607@psg.com> > I'm not sure I follow. Many of these aliens are in fact registered in > RADB, so AFAICS, there that is no reason for them to be registered in > RIPE DB. when ripe will not mirror the irr segment in which they do register. randy From randy at psg.com Fri Aug 15 08:26:44 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 06:26:44 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <86tzdmzcv3.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> Message-ID: <48A58414.5090704@psg.com> > In other words, our earlier estimate of 60% was way off... you can > get 92.1% effectiveness at bogon filtering by just dropping 1918 > addresses, a filter that you will never have to change. my read is that the 60% was an alleged 60% of attacks came from *all* bogon space. this now seems in the low single digit percentge. of that, the majority is from 1918 space. randy From sandy at tislabs.com Fri Aug 15 08:27:42 2008 From: sandy at tislabs.com (Sandy Murphy) Date: Fri, 15 Aug 2008 09:27:42 -0400 (EDT) Subject: Public shaming list for ISPs announcing other ISPs IP space by mis take In-Reply-To: Message-ID: <20080815132742.45A713F4A3@pecan.tislabs.com> On Thu, 14 Aug 2008 23:44:50 -0600, Danny McPherson wrote: >> Okay, I admit I haven't paid the closest attention to RPKI, but I >> have to ask: Is this a two-way shared-key issue, or (worse) a case >> where we need to rely on a central entity to be a key clearinghouse? >In short, the latter, which is precisely DRC's point. Presuming that you meant to say that the RPKI is a centralized system, I'd quibble that it is certainly a rooted system, but not centralized. Like: DNS is rooted, but I'd not call it centralized. The RPKI is hierarchical and distributed all over everywhere. --Sandy From randy at psg.com Fri Aug 15 08:33:17 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 06:33:17 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mis take In-Reply-To: <20080815132742.45A713F4A3@pecan.tislabs.com> References: <20080815132742.45A713F4A3@pecan.tislabs.com> Message-ID: <48A5859D.8090300@psg.com> > The RPKI is hierarchical and distributed all over everywhere. yes, hierarchic. but the guess is that it is distributed more like the irr, some dozens of folk will run it, not millions such as the dns. randy From tme at multicasttech.com Fri Aug 15 08:33:45 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 15 Aug 2008 09:33:45 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A58414.5090704@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> Message-ID: <7EEAF47A-4307-4584-A7E2-3798B72E94C2@multicasttech.com> On Aug 15, 2008, at 9:26 AM, Randy Bush wrote: >> In other words, our earlier estimate of 60% was way off... you can >> get 92.1% effectiveness at bogon filtering by just dropping 1918 >> addresses, a filter that you will never have to change. > > my read is that the 60% was an alleged 60% of attacks came from *all* > bogon space. this now seems in the low single digit percentge. of > that, the majority is from 1918 space. > If (trying to reverse engineer this thread) previously 60% of all attacks came from bogonspace, and now only 2.96% do, that does not mean that if the bogon filters are removed, that number will stay at < 3 %. It may just mean that the filtering is effective. Regards Marshall > randy > From rs at seastrom.com Fri Aug 15 08:34:48 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 09:34:48 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A58414.5090704@psg.com> (Randy Bush's message of "Fri, 15 Aug 2008 06:26:44 -0700") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> Message-ID: <863al6xuyv.fsf@seastrom.com> Randy Bush writes: >> In other words, our earlier estimate of 60% was way off... you can >> get 92.1% effectiveness at bogon filtering by just dropping 1918 >> addresses, a filter that you will never have to change. > > my read is that the 60% was an alleged 60% of attacks came from *all* > bogon space. this now seems in the low single digit percentge. of > that, the majority is from 1918 space. so is there any case to be made for filtering bogons on upstream/peering ingress at all anymore? (this discussion is orthogonal to bcp38/urpf, which i think we all agree is a good thing and would be great if we could get it further deployed) ---rob From sandy at tislabs.com Fri Aug 15 08:39:30 2008 From: sandy at tislabs.com (Sandy Murphy) Date: Fri, 15 Aug 2008 09:39:30 -0400 (EDT) Subject: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake) In-Reply-To: Message-ID: <20080815133930.A5C963F43E@pecan.tislabs.com> On Fri, 15 Aug 2008 13:56:09 +0300 (EEST), Pekka Savola wrote: >I'm not sure I follow. Many of these aliens are in fact registered in >RADB, so AFAICS, there that is no reason for them to be registered in >RIPE DB. > >On the other hand, some want to register them in RIPE DB because some >operators just want to use RIPE DB e.g. for data consistency etc. >reasons. But putting data without practically any authorization in >RIPE DB doesn't seem to be a useful model in the long run. As I understand things, the "without practically any authorization" model holds for *everything* registered in the RADB. Right? If that's not a useful model for the RIPE DB, what about the RADB? --Sandy P.S. Not to pick on the RADB. Most IRRs, as I understand it, enforce little in the way of authorization. It's just that the RADB was mentioned. From randy at psg.com Fri Aug 15 08:42:01 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 06:42:01 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <863al6xuyv.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> Message-ID: <48A587A9.6070403@psg.com> >>> In other words, our earlier estimate of 60% was way off... you can >>> get 92.1% effectiveness at bogon filtering by just dropping 1918 >>> addresses, a filter that you will never have to change. >> my read is that the 60% was an alleged 60% of attacks came from *all* >> bogon space. this now seems in the low single digit percentge. of >> that, the majority is from 1918 space. > so is there any case to be made for filtering bogons on > upstream/peering ingress at all anymore? maybe low percent is because it is effective. maybe not --- man walks into shrink's office waving open newspaper wildly. shrink asks "why are you waving the newspaper?" man replies, "it keeps the elephants away." shrink says, "elephants? there aren't any elephants for hundreds of kilometers." man replies, "pretty effective, isn't it!" --- personal guess: i suspect that at least rfc1918 filters are worthwhile if only because we make mistakes. randy From sean at donelan.com Fri Aug 15 08:49:38 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Aug 2008 09:49:38 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A58414.5090704@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> Message-ID: <200808150932430.32BF5B92.19528@clifden.donelan.com> On Fri, 15 Aug 2008, Randy Bush wrote: > my read is that the 60% was an alleged 60% of attacks came from *all* > bogon space. this now seems in the low single digit percentge. of > that, the majority is from 1918 space. Although I've disagreed with Rob about the configuration of bogon filters, especially on unmanaged (or semi-managed) routers, it is important to remember attacks and bogus packets are not naturally occuring phenomenon. The attacker chooses the attack vector and target, usually based on effectiveness and vulnerability but often on ease for the attacker. Packet and especially source address hygiene can be very useful for highly managed equipement. However, bogon filters have often become more a source of recurring security consultant maintenance revenue than effective packet controls. Understanding the operational maintenance demands is also an important part of implementing good security controls. For unmanaged and semi-managed routers, I'd suggest strict out-bound packet controls (i.e. be conservative in what you send) because you already need to make operational updates when they change. But consider using inbound controls that require less extensive recurring maintenance, e.g. only filtering martians (i.e. 0/8, 127/8, 255.255.255.255/32, etc) instead of updating bogons (i.e. changing reserved and unallocated) every few months. From Jon.Kibler at aset.com Fri Aug 15 08:55:51 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 15 Aug 2008 09:55:51 -0400 Subject: WebEx Message-ID: <48A58AE7.9000905@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yesterday, Cisco announced a critical vulnerability in WebEx: http://www.cisco.com/warp/public/707/cisco-sa-20080814-webex.shtml The interesting thing about this vulnerability is that you can clean up all of your WebEx installs, but as soon as you create a session with a WebEx server that has not been upgraded, you are once again vulnerable. In other words, you are at the mercy of your WebEx presenter. BTW, despite the fact that Cisco says exploits are available, there is not the first mention of this vulnerability on the WebEx web site. 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 iEYEARECAAYFAkiliucACgkQUVxQRc85QlMpJgCgiCPz+nXKOFrVsWkI/7o0HnHI OhAAnRVH6X9IU3+oc/TRnDrFOqAkadmo =aulb -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From sean at donelan.com Fri Aug 15 09:06:36 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Aug 2008 10:06:36 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <863al6xuyv.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> Message-ID: <200808150951010.28CAECBD.19528@clifden.donelan.com> On Fri, 15 Aug 2008, Robert E. Seastrom wrote: > so is there any case to be made for filtering bogons on > upstream/peering ingress at all anymore? Depends on where and how. On highly managed routers at highly managed interconnection points around the Internet, having some basic packet hygiene checks can serve as a "fire breaks" to keep the effectiveness of large scale attacks with reserved/unallocated address low. Unlike BCP38/uRPF/SAVI, it doesn't need 100% deployment; just enough to make it less attractive as an attack vector compared to other things. Even within a single provider, you might not deploy it everywhere. Maybe just between different continents or regions, depending on your hardware and operational capabilities. For highly managed routers, operational management of allocation updates is more limited because you only need to keep track of IANA changes (or use some of Team Cymru's tools) rather than figure out which peer or customer is authorized to use unallocated source addresses. Again, I think bogon filters are a bad idea for unmanaged or semi-managed routers (or inclusion as a "default" in anything, i.e. Cisco's auto-secure). > (this discussion is orthogonal to bcp38/urpf, which i think we all > agree is a good thing and would be great if we could get it further > deployed) I agree. From david.freedman at uk.clara.net Fri Aug 15 09:49:46 2008 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 15 Aug 2008 15:49:46 +0100 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> Message-ID: <48A5978A.7010209@uk.clara.net> Danny McPherson wrote: > > On Aug 14, 2008, at 1:09 PM, Jared Mauch wrote: >> >> You're missing a step: >> >> janitor. >> >> No really, the reason for some leaks isn't because so-and-so was >> never a customer, they were. 5 years ago. nobody removed the routes >> from >> the IRR or AS-SET or and now the route is learned >> via >> some other location and it's bypassed your perimiter security and >> infiltrated your BGP. > > I agree, how many of you folks that use IRRs have > ever deleted an IRR object? Heck, some ISPs even > add them based on existence of advertised routes. Agree, IRR objects do get dirty and require cleaning up, The company I work for makes a good effort at this which starts by measuring how dirty they are: http://noc.eu.clara.net/routing.php The problem is caused by a combination of both us and our downstreams not cleaning properly. Over the past few months I've been working on a personal project to clean our IRR objects by making the system which generates them talk closer to the system which bills people. (*) Part of this work has meant going through the pain of providing an internal WHOIS service since we decided that it was the best way of storing data without re-inventing the wheel. This said, if you are not using IRR (at least for your customers) then PLEASE START DOING SO, you'll have plenty of time to worry about keeping it up to date once you can get you or your organisation to grips with it. Dave. * if you are interested you can compare AS-CLARANET macro in the ripedb with AS-CLARANET macro in the ripe testdb (test-whois.ripe.net), This object will launch in the next few weeks. > > -danny > > From smb at cs.columbia.edu Fri Aug 15 09:41:22 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 15 Aug 2008 10:41:22 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808150932430.32BF5B92.19528@clifden.donelan.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <200808150932430.32BF5B92.19528@clifden.donelan.com> Message-ID: <20080815104122.7823c963@cs.columbia.edu> On Fri, 15 Aug 2008 09:49:38 -0400 (EDT) Sean Donelan wrote: > On Fri, 15 Aug 2008, Randy Bush wrote: > > my read is that the 60% was an alleged 60% of attacks came from > > *all* bogon space. this now seems in the low single digit > > percentge. of that, the majority is from 1918 space. > > Although I've disagreed with Rob about the configuration of bogon > filters, especially on unmanaged (or semi-managed) routers, it is > important to remember attacks and bogus packets are not naturally > occuring phenomenon. The attacker chooses the attack vector and > target, usually based on effectiveness and vulnerability but often on > ease for the attacker. > > Packet and especially source address hygiene can be very useful for > highly managed equipement. However, bogon filters have often become > more a source of recurring security consultant maintenance revenue > than effective packet controls. Understanding the operational > maintenance demands is also an important part of implementing good > security controls. > > For unmanaged and semi-managed routers, I'd suggest strict out-bound > packet controls (i.e. be conservative in what you send) because you > already need to make operational updates when they change. But > consider using inbound controls that require less extensive recurring > maintenance, e.g. only filtering martians (i.e. 0/8, 127/8, > 255.255.255.255/32, etc) instead of updating bogons (i.e. changing > reserved and unallocated) every few months. > Martians plus 1918 space, I'd say, though that requires knowing which are border interfaces. Other than that, I agree 100% -- bogon filters have little security relevance for most sites. Furthermore, as the allocated address space increases, the percentage of actual bogon space decreases and the rate of false positives -- packets that are rejected that shouldn't be -- will increase. Security? Remember that availability is a security issue, too. --Steve Bellovin, http://www.cs.columbia.edu/~smb From sean at donelan.com Fri Aug 15 09:52:15 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Aug 2008 10:52:15 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080815104122.7823c963@cs.columbia.edu> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <200808150932430.32BF5B92.19528@clifden.donelan.com> <20080815104122.7823c963@cs.columbia.edu> Message-ID: <200808151043500.32BF5B92.19858@clifden.donelan.com> On Fri, 15 Aug 2008, Steven M. Bellovin wrote: > Martians plus 1918 space, I'd say, though that requires knowing which > are border interfaces. Whether you include or exclude rfc1918 addresses is another issue. Whack the martians first :-) Unfortunately, enough ISPs use rfc1918 addresses on their backbone links filtering rfc1918 also breaks traceroute (* * *) and people use rfc1918 internally enough that rfc1918 requires more professional thought about configuring those filters. >From an operational perspective, whacking martians has fewer caveats for amateur network operators or default equipment configuration settings. > Other than that, I agree 100% -- bogon filters have little security > relevance for most sites. Furthermore, as the allocated address space > increases, the percentage of actual bogon space decreases and the rate > of false positives -- packets that are rejected that shouldn't be -- > will increase. Security? Remember that availability is a security > issue, too. Violent agreement. From Skywing at valhallalegends.com Fri Aug 15 09:56:05 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 15 Aug 2008 09:56:05 -0500 Subject: Validating rights to announce a prefix (was: Public shaming...) In-Reply-To: References: <20080814.223756.21174.0@webmail19.vgs.untd.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD96BA7696@caralain.haven.nynaeve.net> "Easy upgrade" to PKI after the fact might as well be a misnomer. In particular, there will likely be no way to ensure that nobody uses the old system instead of the new, spiffy and "secure"-ified system. This means that support for the old, "insecure" system must be kept around indefinitely, for all practical considerations - which opens you to downgrade attacks and all sorts of other unpleasantness from the backwards compatibility baggage involved. Now, it may well be that we don't need a full blown PKI here, but I think that we should be extremely wary of any scheme that proposes to be future upgradeable to be "more secure", especially when we are talking about a mostly decentralized system where there isn't going to be much of a practical push to force people to upgrade. At the risk of opening the door to much flame-age, consider that with dnssec, my understanding here is that we will *still* have to keep around support for non-secured queries for a very, very long time until everyone (or some level of "everyone" that we consider "good enough", which is also unlikely to be the case for a very long time) runs dnssec-ified authoritative name servers for their domains. This means that the non-secured "plain" DNS path will continue to remain open for attack for years to come, even if everyone on this list, and the root/gTLDs/cccTLDs magically stopped what they were doing right now and somehow rolled out dnssec tomorrow. Being forced to keep this code around leaves you open to downgrade attacks. To give a quick example off the top of my head of why this can be dangerous, consider the following back-of-the-napkin scenario: Even with signature expiration times in place in dnssec to try and prevent replaying of old signed zones that would allow downgrade attacks for any domains not listed as supporting dnssec, an adversary in your packet path can still (probably) have a reasonable shot at successfully forcing a downgrade attack and subsequently spoofing data using "plain" DNS fallback. For example, to validate validity timestamps on signatures, you need to have valid local system time, and how do you update your local system time? Do you use NTP over the public Internet? If so, an attacker in your packet path can change your system time and replay old dnssec signatures, thus allowing downgrade attacks for domains that were previously not using dnssec by taking advantage of "plain" DNS fallback code. Now, I'm not really trying to bash dnssec here, but rather point out that "upgrading" to something that's secure later on should be considered practically a non-option in a (mostly) decentralized scenario like how the global routing DFZ is managed. I'm also not trying to bash your proposal specifically (or the level of security it provides), but rather just call attention to the uncomfortableness to anything that provides "soft" security from the get-go with a later option for upgrade to "hard" security. Now, it may well be that we really don't need PKI here for reasonable security (and I am explicitly *not* commenting on whether this is or is the case here), but we had better be damn sure that we make the right call there before rolling anything like this out, or we'll be dealing with the security consequences for a very long time to come. There are just *so* many things that make handling a "secure" upgrade to a well-entrenched protocol that provides "hard" security, while keeping reasonable functionality an extremely difficult task (to say the least), that you would likely almost be better scrapping the existing (well, new) protocol entirely and coming up with a new one from scratch should such prove necessary. - S -----Original Message----- From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] Sent: Friday, August 15, 2008 5:55 AM To: nanog at nanog.org Subject: RE: Validating rights to announce a prefix (was: Public shaming...) > Okay, I admit I haven't paid the closest attention to RPKI, > but I have to ask: Is this a two-way shared-key issue, or > (worse) a case where we need to rely on a central entity to > be a key clearinghouse? > > The reason why I mention this is obvious -- the entire PKI > effort has been stalled (w.r.t. authority) because of this > particular issue. Who says there needs to be a PKI infrastructure in order to do this? There are other ways of authenticating data. For instance ARIN could hold the data that they have validated on their own servers and people could use HTTPS queries to ensure that they get the answers that they thought they would get. As for how the address owner delegates the right to announce a prefix, they could either operate their own database and ARIN would have a pointer to it, or they could register the data in ARIN's database by some secure means. There is no reason why "secure means" could not include various out of band authentication systems. People are too hung up on cryotographically secure PKI systems which are way overkill for this problem. In fact, it should be possible to design an architecture that allows for an easy upgrade to PKI if it should be determined at some future date, that PKI is necessary. --Michael Dillon From rs at seastrom.com Fri Aug 15 10:08:07 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 11:08:07 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808150932430.32BF5B92.19528@clifden.donelan.com> (Sean Donelan's message of "Fri, 15 Aug 2008 09:49:38 -0400 (EDT)") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <200808150932430.32BF5B92.19528@clifden.donelan.com> Message-ID: <86k5eitiy0.fsf@seastrom.com> Sean Donelan writes: > For unmanaged and semi-managed routers, I'd suggest strict out-bound > packet controls (i.e. be conservative in what you send) because you > already need to make operational updates when they change. But > consider using inbound controls that require less extensive > recurring maintenance, e.g. only filtering martians (i.e. 0/8, > 127/8, 255.255.255.255/32, etc) instead of updating bogons > (i.e. changing reserved and unallocated) every few months. I think we're in violent agreement here. -r From rs at seastrom.com Fri Aug 15 10:12:06 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 11:12:06 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808150951010.28CAECBD.19528@clifden.donelan.com> (Sean Donelan's message of "Fri, 15 Aug 2008 10:06:36 -0400 (EDT)") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> Message-ID: <86fxp6tird.fsf@seastrom.com> Sean Donelan writes: > On Fri, 15 Aug 2008, Robert E. Seastrom wrote: >> so is there any case to be made for filtering bogons on >> upstream/peering ingress at all anymore? > > Depends on where and how. > > On highly managed routers at highly managed interconnection points around > the Internet, having some basic packet hygiene checks can serve as a > "fire breaks" to keep the effectiveness of large scale attacks with > reserved/unallocated address low. > ...> > Again, I think bogon filters are a bad idea for unmanaged or > semi-managed routers (or inclusion as a "default" in anything, > i.e. Cisco's auto-secure). You make a very good point about the difference between routers that are being routinely maintained by highly clueful people and routers that are in the field and untouched/unloved for months to years at a time. The latter is the situation that I was thinking of when I was talking about the operational hit from the overzealous bogon filters. Problem is, when we post BCPs they tend to assume a flat application space (which is a bad plan) or people tend to assume that they are more clueful or the routers will be better maintained than they actually will be (the "airport diamond security lane for expert travelers" problem). ---Rob From randy at psg.com Fri Aug 15 10:18:14 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 08:18:14 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <86fxp6tird.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> Message-ID: <48A59E36.6070104@psg.com> >> Again, I think bogon filters are a bad idea for unmanaged or >> semi-managed routers (or inclusion as a "default" in anything, >> i.e. Cisco's auto-secure). > > You make a very good point about the difference between routers that > are being routinely maintained by highly clueful people and routers > that are in the field and untouched/unloved for months to years at a > time. in the field != untouched/unloved i contend that all one's routers should be rigorously configured as programmatically as possible. randy From randy at psg.com Fri Aug 15 10:19:27 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 08:19:27 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080815104122.7823c963@cs.columbia.edu> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <200808150932430.32BF5B92.19528@clifden.donelan.com> <20080815104122.7823c963@cs.columbia.edu> Message-ID: <48A59E7F.4000303@psg.com> as a mutual friend who pretends he does not read nanog emailed privately "rfc1918 filters, like bcp38 filters, could be construed as topological assertions rather than bogon filters per se. certainly they are for edge routers, but even in the dfz, "i don't think we're in rfc 1918 space anymore, toto."" randy From LarrySheldon at cox.net Fri Aug 15 10:31:44 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Fri, 15 Aug 2008 10:31:44 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A59E36.6070104@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> Message-ID: <48A5A160.6020608@cox.net> Randy Bush wrote: > in the field != untouched/unloved > > i contend that all one's routers should be rigorously configured as > programmatically as possible. It seems to me that those are the routers where the filtering of both packets and routes is easiest and most effective. If every such router (which almost be definition knows what source addresses and routes are legitimate) filtered out all the crap, there would not be much crap getting to the DFZ. Too hard. I don't think so. When I administered a /16 with "only" a hundred or so such routers, a simple skeleton config-file-base allowed quick construction of a config file at installation--which was then rarely touched ever again. (We did log at a central location and used SNMP monitors for supervison.) -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From michael.dillon at bt.com Fri Aug 15 10:39:04 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 15 Aug 2008 16:39:04 +0100 Subject: Validating rights to announce a prefix (was: Public shaming...) In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BD96BA7696@caralain.haven.nynaeve.net> Message-ID: > "Easy upgrade" to PKI after the fact might as well be a > misnomer. In particular, there will likely be no way to > ensure that nobody uses the old system instead of the new, > spiffy and "secure"-ified system. This means that support > for the old, "insecure" system must be kept around > indefinitely, for all practical considerations This is nonsense. If I can shut down my gopher server, then why can't someone stop accepting delegation notifications that don't meet the requirements of version x+1 for some value of x? For that matter, since cleanliness of data is a major problem in this type of database, why can't all records expire 6 months after they are entered? That would avoid the garbage that collects in IRR or whois databases. If an entity is not active and does not refresh their delegation of prefix announcement rights, then after 6 months, their connectivity will begin to crumble as the various providers refresh their route filters from their OSS systems. > Now, it may well be that we don't need a full blown PKI here, > but I think that we should be extremely wary of any scheme > that proposes to be future upgradeable to be "more secure", > especially when we are talking about a mostly decentralized > system where there isn't going to be much of a practical push > to force people to upgrade. You mean version incompatibility leading to an inability to refresh your expired data, is not enough of a push? If that is so, then why are you routing their traffic? > At the risk of opening the door to much flame-age, consider > that with dnssec, my understanding here is that we will > *still* have to keep around support for non-secured queries > for a very, very long time until everyone That is a different situation even though there are similarities. > To give a quick example off the top of my head of why this > can be dangerous, consider the following back-of-the-napkin scenario: > > Even with signature expiration times in place in dnssec to > try and prevent replaying of old signed zones that would > allow downgrade attacks for any domains not listed as > supporting dnssec, an adversary in your packet path can still > (probably) have a reasonable shot at successfully forcing a > downgrade attack and subsequently spoofing data using "plain" > DNS fallback. For example, to validate validity timestamps > on signatures, you need to have valid local system time, and > how do you update your local system time? Do you use NTP > over the public Internet? If so, an attacker in your packet > path can change your system time and replay old dnssec > signatures, thus allowing downgrade attacks for domains that > were previously not using dnssec by taking advantage of > "plain" DNS fallback code. This is why these fully automated crypto PKI solutions make me uneasy. There is too darn much complexity and too little experience with them in the real world. If you move the problem to a different space where OSS systems check route delegations, and only update router configs after some human intervention then there is less chance of wierd attack vectors succeeding. > I'm also not trying to bash your proposal > specifically (or the level of security it provides), but > rather just call attention to the uncomfortableness to > anything that provides "soft" security from the get-go with a > later option for upgrade to "hard" security. If I agreed with you, I never would have set up an ISP back in 1994 because of the fundamental insecurity of an IPv4 Internet without IPSEC support baked into the fundamental protocol. > There are just *so* many things that make handling a "secure" > upgrade to a well-entrenched protocol that provides "hard" > security, while keeping reasonable functionality an extremely > difficult task (to say the least), that you would likely > almost be better scrapping the existing (well, new) protocol > entirely and coming up with a new one from scratch should > such prove necessary. See, there is a straightforward upgrade route after all. Even more straighforward if we walk into this with clear requirements and a clear documented architecture so that everyone knows what the boundaries are and fewer people bake things into hard-to-upgrade places. --Michael Dillon From rs at seastrom.com Fri Aug 15 10:50:50 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 11:50:50 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080815104122.7823c963@cs.columbia.edu> (Steven M. Bellovin's message of "Fri, 15 Aug 2008 10:41:22 -0400") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <200808150932430.32BF5B92.19528@clifden.donelan.com> <20080815104122.7823c963@cs.columbia.edu> Message-ID: <864p5ms2ed.fsf@seastrom.com> "Steven M. Bellovin" writes: > Security? Remember that availability is a security issue, too. It never ceases to amaze me how many "security people" walk around oblivious to this basic notion. -r From LarrySheldon at cox.net Fri Aug 15 10:53:27 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Fri, 15 Aug 2008 10:53:27 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <864p5ms2ed.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <200808150932430.32BF5B92.19528@clifden.donelan.com> <20080815104122.7823c963@cs.columbia.edu> <864p5ms2ed.fsf@seastrom.com> Message-ID: <48A5A677.90100@cox.net> Robert E. Seastrom wrote: > "Steven M. Bellovin" writes: > >> Security? Remember that availability is a security issue, too. > > It never ceases to amaze me how many "security people" walk around > oblivious to this basic notion. But of course! The most secure object is one nobody knows about and can't get to anyway. That is the whole point! From rs at seastrom.com Fri Aug 15 10:54:48 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 11:54:48 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A59E36.6070104@psg.com> (Randy Bush's message of "Fri, 15 Aug 2008 08:18:14 -0700") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> Message-ID: <86zlneqnnb.fsf@seastrom.com> Randy Bush writes: >>> Again, I think bogon filters are a bad idea for unmanaged or >>> semi-managed routers (or inclusion as a "default" in anything, >>> i.e. Cisco's auto-secure). >> >> You make a very good point about the difference between routers that >> are being routinely maintained by highly clueful people and routers >> that are in the field and untouched/unloved for months to years at a >> time. > > in the field != untouched/unloved That's why I used the conjunction "and". > i contend that all one's routers should be rigorously configured as > programmatically as possible. Not sure what you mean by this, but the painful reality is that most stuff, once deployed, gets promptly forgotten about, much the same as you might ignore a wall wart power supply under your desk until it started smelling funny or stopped delivering electricity. Thus, I contend that one's routers should be configured to avoid ticking time bombs. As smb so eloquently just asserted, "availability is a security issue too". -r From randy at psg.com Fri Aug 15 10:56:27 2008 From: randy at psg.com (Randy Bush) Date: Fri, 15 Aug 2008 08:56:27 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <86zlneqnnb.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> <86zlneqnnb.fsf@seastrom.com> Message-ID: <48A5A72B.50305@psg.com> > Not sure what you mean by this, but the painful reality is that most > stuff, once deployed, gets promptly forgotten about, much the same as > you might ignore a wall wart power supply under your desk until it > started smelling funny or stopped delivering electricity. Thus, I > contend that one's routers should be configured to avoid ticking time > bombs. and i am saying that you should use a router configuration *system* that avoids ticking time bombs. no router should be neglected and unloved. randy From rs at seastrom.com Fri Aug 15 11:12:32 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 15 Aug 2008 12:12:32 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A5A72B.50305@psg.com> (Randy Bush's message of "Fri, 15 Aug 2008 08:56:27 -0700") References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> <86zlneqnnb.fsf@seastrom.com> <48A5A72B.50305@psg.com> Message-ID: <86skt6p89b.fsf@seastrom.com> Randy Bush writes: >> Not sure what you mean by this, but the painful reality is that most >> stuff, once deployed, gets promptly forgotten about, much the same as >> you might ignore a wall wart power supply under your desk until it >> started smelling funny or stopped delivering electricity. Thus, I >> contend that one's routers should be configured to avoid ticking time >> bombs. > > and i am saying that you should use a router configuration *system* that > avoids ticking time bombs. no router should be neglected and unloved. I agree 100%, I'm just acknowledging reality and suggesting that we should not promulgate practices which don't take into account the skew between best-implementation-and-followthrough and oversight-by-PHB. -r From Jon.Kibler at aset.com Fri Aug 15 11:17:08 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 15 Aug 2008 12:17:08 -0400 Subject: WebEx In-Reply-To: <48A58AE7.9000905@aset.com> References: <48A58AE7.9000905@aset.com> Message-ID: <48A5AC04.5080407@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Kibler wrote: > BTW, despite the fact that Cisco says exploits are available, there is > not the first mention of this vulnerability on the WebEx web site. I really hate to reply to my own postings, but in this case I will make an exception. I just got an email from a Cisco PSIRT manager who said that they were working with WebEx to address the issue that WebEx does not have an announcement of the vulnerability on its web site, and Cisco will try to ensure a similar omission does not happen again. I am glad to see that Cisco is headed on the right track! Jon - -- 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 iEYEARECAAYFAkilrAQACgkQUVxQRc85QlPyAACdFx63Q4MaOpKYBch8SqiS9ToD jQIAniwFX/qsbWMvzdTuZxfn0IWVdWge =0mWf -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From smb at cs.columbia.edu Fri Aug 15 11:17:36 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 15 Aug 2008 12:17:36 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A5A72B.50305@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> <86zlneqnnb.fsf@seastrom.com> <48A5A72B.50305@psg.com> Message-ID: <20080815121736.0ba27533@cs.columbia.edu> On Fri, 15 Aug 2008 08:56:27 -0700 Randy Bush wrote: > > Not sure what you mean by this, but the painful reality is that most > > stuff, once deployed, gets promptly forgotten about, much the same > > as you might ignore a wall wart power supply under your desk until > > it started smelling funny or stopped delivering electricity. Thus, > > I contend that one's routers should be configured to avoid ticking > > time bombs. > > and i am saying that you should use a router configuration *system* > that avoids ticking time bombs. no router should be neglected and > unloved. > That, I think, is why he distinguished between routers run by "highly clueful people" and routers run by others. I think we all agree on your basic point; it's just that too many people aren't clueful enough to realize that they even have a problem, let alone know how to solve it. (Of course, you and I both have a background in programming languages and compilers, which is why we naturally think of router configurations as a form of assembler language that only a compiler should every emit.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From Skywing at valhallalegends.com Fri Aug 15 11:50:03 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 15 Aug 2008 11:50:03 -0500 Subject: Validating rights to announce a prefix (was: Public shaming...) In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BD96BA7696@caralain.haven.nynaeve.net> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD96BA7699@caralain.haven.nynaeve.net> I respectfully disagree that it's nonsense. You can shut off your Gopher server, because, for some set of "nobody" that you care about, nobody uses Gopher anymore. There are several basic ways for an old protocol to get replaced: - Nobody has a use for it any more, for a sufficient level of "nobody" (e.g. Gopher). In the case of Gopher, it could be argued that it never really caught on to the degree that things like, say, HTTP did. - Everyone moves on to a newer version, typically because somebody forces it on them (vendor ceasing support of old protocol, centralized that can enforce such things mandates it, etc). The problem here, that I see with deploying a new protocol version, is that operators will be loathe to create a policy saying that "I don't accept delegation notifications of version less than x+1" until doing so does not mean that they will be cutting off things that their customers care about reaching. In this situation, flipping the big red switch to turn off protocol version x is externalized and dependent upon everyone that a particular operator's customers care about having started using version x+1. There isn't a particularly great way right now for said operator to force other networks to deploy version x+1, at least not without trying to do something along the lines of playing chicken between their customers walking and said other networks getting their act together by cutting off version x. (If this perception is not entirely accurate, according to your beliefs, please feel free to explain.) If you leave version x+1 as optional, then you're going to be waiting a very, very long time for it to naturally "die out" as long as there is still a sizable user base that you care about. Again, there may not be an exact, down-to-the-line analogue to this particular problem, but there are a whole lot of things on the 'net out there which have some degree of similarity and tend to demonstrate that on average, without some authoritative centralized body somehow forcing action to be taken, old protocols that are "good enough" tend to stick around forever (even when "good enough" often really means "not really, truly secure"). I think that it would be wise to avoid getting ourselves mired into that mess going forward. Cutting remarks aside, it seems like you tend to find this preferable as well after all ("Even more straighforward if we walk into this with clear requirements and a clear documented architecture so that everyone knows what the boundaries are and fewer people bake things into hard-to-upgrade places."), unless I am misunderstanding you :) [ Not commenting on the matter of expiring IRR database entries, as my posting was, again only discussing the matter of the pitfalls of assuming that protocol upgrades will be particularly workable to provide "add-on" security later in the game. ] - S -----Original Message----- From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] Sent: Friday, August 15, 2008 11:39 AM To: nanog at nanog.org Subject: RE: Validating rights to announce a prefix (was: Public shaming...) > "Easy upgrade" to PKI after the fact might as well be a > misnomer. In particular, there will likely be no way to > ensure that nobody uses the old system instead of the new, > spiffy and "secure"-ified system. This means that support > for the old, "insecure" system must be kept around > indefinitely, for all practical considerations This is nonsense. If I can shut down my gopher server, then why can't someone stop accepting delegation notifications that don't meet the requirements of version x+1 for some value of x? For that matter, since cleanliness of data is a major problem in this type of database, why can't all records expire 6 months after they are entered? That would avoid the garbage that collects in IRR or whois databases. If an entity is not active and does not refresh their delegation of prefix announcement rights, then after 6 months, their connectivity will begin to crumble as the various providers refresh their route filters from their OSS systems. > Now, it may well be that we don't need a full blown PKI here, > but I think that we should be extremely wary of any scheme > that proposes to be future upgradeable to be "more secure", > especially when we are talking about a mostly decentralized > system where there isn't going to be much of a practical push > to force people to upgrade. You mean version incompatibility leading to an inability to refresh your expired data, is not enough of a push? If that is so, then why are you routing their traffic? > At the risk of opening the door to much flame-age, consider > that with dnssec, my understanding here is that we will > *still* have to keep around support for non-secured queries > for a very, very long time until everyone That is a different situation even though there are similarities. > To give a quick example off the top of my head of why this > can be dangerous, consider the following back-of-the-napkin scenario: > > Even with signature expiration times in place in dnssec to > try and prevent replaying of old signed zones that would > allow downgrade attacks for any domains not listed as > supporting dnssec, an adversary in your packet path can still > (probably) have a reasonable shot at successfully forcing a > downgrade attack and subsequently spoofing data using "plain" > DNS fallback. For example, to validate validity timestamps > on signatures, you need to have valid local system time, and > how do you update your local system time? Do you use NTP > over the public Internet? If so, an attacker in your packet > path can change your system time and replay old dnssec > signatures, thus allowing downgrade attacks for domains that > were previously not using dnssec by taking advantage of > "plain" DNS fallback code. This is why these fully automated crypto PKI solutions make me uneasy. There is too darn much complexity and too little experience with them in the real world. If you move the problem to a different space where OSS systems check route delegations, and only update router configs after some human intervention then there is less chance of wierd attack vectors succeeding. > I'm also not trying to bash your proposal > specifically (or the level of security it provides), but > rather just call attention to the uncomfortableness to > anything that provides "soft" security from the get-go with a > later option for upgrade to "hard" security. If I agreed with you, I never would have set up an ISP back in 1994 because of the fundamental insecurity of an IPv4 Internet without IPSEC support baked into the fundamental protocol. > There are just *so* many things that make handling a "secure" > upgrade to a well-entrenched protocol that provides "hard" > security, while keeping reasonable functionality an extremely > difficult task (to say the least), that you would likely > almost be better scrapping the existing (well, new) protocol > entirely and coming up with a new one from scratch should > such prove necessary. See, there is a straightforward upgrade route after all. Even more straighforward if we walk into this with clear requirements and a clear documented architecture so that everyone knows what the boundaries are and fewer people bake things into hard-to-upgrade places. --Michael Dillon From sean at donelan.com Fri Aug 15 12:06:43 2008 From: sean at donelan.com (Sean Donelan) Date: Fri, 15 Aug 2008 13:06:43 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080815121736.0ba27533@cs.columbia.edu> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> <86zlneqnnb.fsf@seastrom.com> <48A5A72B.50305@psg.com> <20080815121736.0ba27533@cs.columbia.edu> Message-ID: <200808151259140.32BF5B92.20463@clifden.donelan.com> On Fri, 15 Aug 2008, Steven M. Bellovin wrote: >> and i am saying that you should use a router configuration *system* >> that avoids ticking time bombs. no router should be neglected and >> unloved. >> > That, I think, is why he distinguished between routers run by "highly > clueful people" and routers run by others. I think we all agree on > your basic point; it's just that too many people aren't clueful enough > to realize that they even have a problem, let alone know how to solve > it. (Of course, you and I both have a background in programming > languages and compilers, which is why we naturally think of router > configurations as a form of assembler language that only a compiler > should every emit.) To avoid people feeling individually insulted, I sometimes try to distinguish between the purposes of equipment rather than the capabilities of the person maintaining it. A NASCAR racing team may perform extensive monitoring and maintenance on their racing cars; but that doesn't mean I should need a team of 5 mechanics to keep my regular street car operating safely with a few idiot lights on the dashboard. From jra at baylink.com Fri Aug 15 12:15:28 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 15 Aug 2008 13:15:28 -0400 Subject: facebook worm In-Reply-To: <4b6ee9310808081427v1c535cd0ub92105eda4b0428e@mail.gmail.com> References: <489C7559.2010008@zill.net> <4b6ee9310808081427v1c535cd0ub92105eda4b0428e@mail.gmail.com> Message-ID: <20080815171528.GL31879@cgi.jachomes.com> On Fri, Aug 08, 2008 at 10:27:33PM +0100, n3td3v wrote: > He's ruining Nanog, just so he can get self glorification and self > gratification in > himself as some kind of leader of internet security industry when he > really is just a sad fat person who is a nobody. > > All the best, Clearly not. Moderators? Personal attacks are off topic, right? Cheers, -- jr '"self gratification in himself". furrfu' a -- 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. -- (Josef Stalin) From cscora at apnic.net Fri Aug 15 13:08:24 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Aug 2008 04:08:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200808151808.m7FI8OJ7019471@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 16 Aug, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 266031 Prefixes after maximum aggregation: 129676 Deaggregation factor: 2.05 Unique aggregates announced to Internet: 129417 Total ASes present in the Internet Routing Table: 28943 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25197 Origin ASes announcing only one prefix: 12205 Transit ASes present in the Internet Routing Table: 3746 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 581 Unregistered ASNs in the Routing Table: 214 Number of 32-bit ASNs allocated by the RIRs: 57 Prefixes from 32-bit ASNs in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 814 Number of addresses announced to Internet: 1891631072 Equivalent to 112 /8s, 191 /16s and 255 /24s Percentage of available address space announced: 51.0 Percentage of allocated address space announced: 62.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.2 Total number of prefixes smaller than registry allocations: 130342 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 61134 Total APNIC prefixes after maximum aggregation: 22712 APNIC Deaggregation factor: 2.69 Prefixes being announced from the APNIC address blocks: 58105 Unique aggregates announced from the APNIC address blocks: 26152 APNIC Region origin ASes present in the Internet Routing Table: 3328 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 878 APNIC Region transit ASes present in the Internet Routing Table: 514 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 371611424 Equivalent to 22 /8s, 38 /16s and 87 /24s Percentage of available APNIC address space announced: 79.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, 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: 121924 Total ARIN prefixes after maximum aggregation: 65148 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 91111 Unique aggregates announced from the ARIN address blocks: 34743 ARIN Region origin ASes present in the Internet Routing Table: 12358 ARIN Prefixes per ASN: 7.37 ARIN Region origin ASes announcing only one prefix: 4754 ARIN Region transit ASes present in the Internet Routing Table: 1184 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 360325024 Equivalent to 21 /8s, 122 /16s and 31 /24s Percentage of available ARIN address space announced: 74.1 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: 57391 Total RIPE prefixes after maximum aggregation: 34803 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 52507 Unique aggregates announced from the RIPE address blocks: 35275 RIPE Region origin ASes present in the Internet Routing Table: 11737 RIPE Prefixes per ASN: 4.47 RIPE Region origin ASes announcing only one prefix: 6169 RIPE Region transit ASes present in the Internet Routing Table: 1778 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 369143104 Equivalent to 22 /8s, 0 /16s and 173 /24s Percentage of available RIPE address space announced: 84.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 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: 21007 Total LACNIC prefixes after maximum aggregation: 5308 LACNIC Deaggregation factor: 3.96 Prefixes being announced from the LACNIC address blocks: 19258 Unique aggregates announced from the LACNIC address blocks: 10747 LACNIC Region origin ASes present in the Internet Routing Table: 981 LACNIC Prefixes per ASN: 19.63 LACNIC Region origin ASes announcing only one prefix: 324 LACNIC Region transit ASes present in the Internet Routing Table: 169 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 54404608 Equivalent to 3 /8s, 62 /16s and 38 /24s Percentage of available LACNIC address space announced: 54.0 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: 3993 Total AfriNIC prefixes after maximum aggregation: 1225 AfriNIC Deaggregation factor: 3.26 Prefixes being announced from the AfriNIC address blocks: 4347 Unique aggregates announced from the AfriNIC address blocks: 1868 AfriNIC Region origin ASes present in the Internet Routing Table: 248 AfriNIC Prefixes per ASN: 17.53 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12726016 Equivalent to 0 /8s, 194 /16s and 47 /24s Percentage of available AfriNIC address space announced: 37.9 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 1693 537 180 Videsh Sanchar Nigam Ltd. Aut 17488 1300 89 99 Hathway IP Over Cable Interne 9583 1176 92 493 Sify Limited 4766 858 6390 351 Korea Telecom (KIX) 4134 836 13523 339 CHINANET-BACKBONE 23577 823 35 698 Korea Telecom (ATM-MPLS) 4780 714 353 61 Digital United Inc. 18101 692 167 33 Reliance Infocom Ltd Internet 9498 674 291 54 BHARTI BT INTERNET LTD. 4808 616 1109 135 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 6389 3198 3358 208 bellsouth.net, inc. 209 2881 3857 619 Qwest 6298 2004 323 735 Cox Communicatons 2386 1562 692 899 AT&T Data Communications Serv 4323 1491 1078 379 Time Warner Telecom 1785 1454 478 100 AppliedTheory Corporation 7018 1412 5830 988 AT&T WorldNet Services 11492 1214 151 22 Cable One 20115 1113 1080 573 Charter Communications 18566 1045 296 10 Covad 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 414 1776 372 TDC Tele Danmark 3215 371 2756 106 France Telecom Transpac 8452 357 188 11 TEDATA 3301 332 1444 303 TeliaNet Sweden 3320 323 7047 271 Deutsche Telekom AG 8866 317 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 289 270 39 Bezeq International 680 274 2047 264 DFN-IP service G-WiN 6746 269 126 243 Dynamic Network Technologies, 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 1517 2592 222 UniNet S.A. de C.V. 11830 664 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 479 236 65 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 417 85 48 ENTEL CHILE S.A. 11172 410 118 72 Servicios Alestra S.A de C.V 10620 371 99 90 TVCABLE BOGOTA 14117 348 23 9 Telefonica del Sur S.A. 28573 318 432 33 NET Servicos de Comunicao S.A 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 496 64 28 LINKdotNET AS number 20858 402 34 3 EgyNet 3741 267 855 224 The Internet Solution 2018 211 213 130 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 136 10 13 EEPAD TISP TELECOM & INTERNET 5713 129 540 74 Telkom SA Ltd 5536 120 8 17 Internet Egypt Network 33776 119 6 3 Starcomms Nigeria Limited 29571 107 13 8 Ci Telecom Autonomous system 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 3198 3358 208 bellsouth.net, inc. 209 2881 3857 619 Qwest 6298 2004 323 735 Cox Communicatons 4755 1693 537 180 Videsh Sanchar Nigam Ltd. Aut 2386 1562 692 899 AT&T Data Communications Serv 8151 1517 2592 222 UniNet S.A. de C.V. 4323 1491 1078 379 Time Warner Telecom 1785 1454 478 100 AppliedTheory Corporation 7018 1412 5830 988 AT&T WorldNet Services 17488 1300 89 99 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 209 2881 2262 Qwest 4755 1693 1513 Videsh Sanchar Nigam Ltd. Aut 1785 1454 1354 AppliedTheory Corporation 8151 1517 1295 UniNet S.A. de C.V. 6298 2004 1269 Cox Communicatons 17488 1300 1201 Hathway IP Over Cable Interne 11492 1214 1192 Cable One 4323 1491 1112 Time Warner Telecom 18566 1045 1035 Covad Communications 22773 959 897 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 65530 PRIVATE 8.7.233.0/24 20473 Net Transactions LLC 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 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 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.53.86.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.55.0.0/18 20001 HoldCo LLC - Road Runner 24.75.160.0/19 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 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:17 /11:45 /12:146 /13:293 /14:527 /15:1055 /16:10032 /17:4359 /18:7547 /19:16006 /20:18673 /21:18275 /22:22986 /23:24093 /24:139274 /25:834 /26:1018 /27:722 /28:85 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2035 3198 bellsouth.net, inc. 6298 1977 2004 Cox Communicatons 209 1645 2881 Qwest 2386 1240 1562 AT&T Data Communications Serv 11492 1195 1214 Cable One 17488 1107 1300 Hathway IP Over Cable Interne 1785 1069 1454 AppliedTheory Corporation 4755 1042 1693 Videsh Sanchar Nigam Ltd. Aut 9583 1032 1176 Sify Limited 18566 1026 1045 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:133 12:2100 13:2 14:1 15:22 16:3 17:5 18:13 20:35 24:1083 32:59 38:482 40:92 41:703 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:526 59:505 60:453 61:983 62:1198 63:2032 64:3211 65:2365 66:3426 67:1226 68:767 69:2280 70:863 71:131 72:2039 73:6 74:1101 75:165 76:307 77:757 78:817 79:225 80:979 81:844 82:605 83:379 84:573 85:982 86:399 87:707 88:338 89:1309 90:33 91:1417 92:243 93:766 94:109 96:54 97:50 98:307 99:3 114:90 115:40 116:941 117:331 118:195 119:459 120:73 121:587 122:816 123:375 124:893 125:1178 128:355 129:201 130:135 131:410 132:70 133:9 134:188 135:33 136:223 137:94 138:145 139:94 140:503 141:103 142:407 143:340 144:398 145:51 146:372 147:156 148:517 149:197 150:129 151:183 152:144 153:136 154:10 155:278 156:173 157:288 158:166 159:294 160:273 161:118 162:262 163:155 164:518 165:456 166:362 167:333 168:626 169:139 170:426 171:33 172:10 173:12 188:1 189:473 190:2121 192:5794 193:4126 194:3239 195:2554 196:1016 198:3728 199:3312 200:5579 201:1521 202:7683 203:8093 204:3953 205:2146 206:2369 207:2759 208:3489 209:3419 210:2607 211:1075 212:1425 213:1610 214:179 215:50 216:4375 217:1203 218:346 219:429 220:1060 221:455 222:310 End of report From jmalcolm at uraeus.com Fri Aug 15 16:43:40 2008 From: jmalcolm at uraeus.com (Joe Malcolm) Date: Fri, 15 Aug 2008 21:43:40 +0000 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <86zlneqnnb.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com> <863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com> <86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> <86zlneqnnb.fsf@seastrom.com> Message-ID: <18597.63628.21797.8786@shoggoth.uraeus.com> Robert E. Seastrom writes: >Not sure what you mean by this, but the painful reality is that most >stuff, once deployed, gets promptly forgotten about, much the same as >you might ignore a wall wart power supply under your desk until it >started smelling funny or stopped delivering electricity. Thus, I >contend that one's routers should be configured to avoid ticking time >bombs. As smb so eloquently just asserted, "availability is a >security issue too". This is particularly but not exclusively true if they are implementing an "overhead" function - i.e., if they are not directly in the money-generating path. If they are, they at least have some chance at getting some attention when not on fire. Otherwise, they will likely be ignored until failure. Joe From ray at oneunified.net Fri Aug 15 19:08:55 2008 From: ray at oneunified.net (Ray Burkholder) Date: Fri, 15 Aug 2008 21:08:55 -0300 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A59E36.6070104@psg.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com><86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com><863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com><86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> Message-ID: <094101c8ff34$470632f0$660a0a0a@oneunified.local> > i contend that all one's routers should be rigorously > configured as programmatically as possible. > What sort of tools do you use to facilitate this? Ray. -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean. From mksmith at adhost.com Sat Aug 16 10:28:26 2008 From: mksmith at adhost.com (Michael Smith) Date: Sat, 16 Aug 2008 08:28:26 -0700 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> Message-ID: >> >> janitor. >> >> No really, the reason for some leaks isn't because so-and-so was >> never a customer, they were. 5 years ago. nobody removed the >> routes from >> the IRR or AS-SET or and now the route is >> learned via >> some other location and it's bypassed your perimiter security and >> infiltrated your BGP. > > I agree, how many of you folks that use IRRs have > ever deleted an IRR object? Heck, some ISPs even > add them based on existence of advertised routes. > > -danny > Even better, how many have tried to get another provider to remove legacy objects from days gone by when someone was adding objects on your behalf? I have objects that date back to 1998 that are completely bogus and I can't do squat about it. Mike From tomb at byrneit.net Sat Aug 16 12:53:51 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 16 Aug 2008 10:53:51 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <86tzdmzcv3.fsf@seastrom.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com><20080806130937.GA99520@ussenterprise.ufp.org><4899B502.1090407@cymru.com><1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net><4899BCB2.6050808@psg.com><606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net><48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> Since there are ways to dynamically filter the bogons, using BGP or DNS, I don't really see the need to stop doing so. If you're managing your routing and firewall filters manually, you have bigger problems than the release of Bogon space. It's not just the number of attacks that is the issue, but the potential severity of them. Traffic sourced from Bogon space (REAL Bogon space) is 100% guaranteed to be traffic you DON'T want to receive. It could be advertised bogon space, in which case it is likely criminal, and thus something you REALLY don't want to see. Prioritization of defense effort is based on a product of probability and severity divided by a factor that takes the cost and unfavorable consequences of the mitigation strategy into account. For any given threat, you can choose methods that decrease or increase any factor, and address those with the highest payoff first. An example would be Thermonuclear attack: low probability, very high severity, with fairly significant cost and unpleasant side consequences, yet the result, total annihilation, is so high that we have ICBMs, Submarines, Bombers, and ABM technology, which taken together cost a lot more than the efforts spent on blocking SPAM, which is very probable, but unlikely to kill anyone. Applying Bogon filters, using dynamic sources, is a very low cost way to block attacks that can be of high severity, while unlikely to have adverse consequences, and so is a BCP. Filtering RFC1918 space at the edge has always been a BCP, independent of Bogon filters. You neither want to accept if from outside, or let any of yours leak. That should be part of the static filter set/null route table in any router. > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Friday, August 15, 2008 5:23 AM > To: Randy Bush > Cc: NANOG list > Subject: Re: Is it time to abandon bogon prefix filters? > > > Randy Bush writes: > > >> bogon block attacks % of attacks > >> 0.0.0.0/7 65 0.01 > >> 2.0.0.0/8 3 0.00 > >> 5.0.0.0/8 3 0.00 > >> 10.0.0.0/8 8794 1.21 > >> 23.0.0.0/8 4 0.00 > >> 27.0.0.0/8 7 0.00 > >> 92.0.0.0/6 101 0.01 > >> 100.0.0.0/6 374 0.05 > >> 104.0.0.0/5 303 0.04 > >> 112.0.0.0/5 775 0.11 > >> 120.0.0.0/8 45 0.01 > >> 127.0.0.0/8 6 0.00 > >> 172.16.0.0/12 3646 0.50 > >> 174.0.0.0/7 1 0.00 > >> 176.0.0.0/5 1 0.00 > >> 192.168.0.0/16 7451 1.02 > >> 223.0.0.0/8 10 0.00 > >> 224.0.0.0/3 8 0.00 > > > > well, we can see why andree wanted to look behind the 1918 > stuff. it > > is the elephant. > > > > thanks, danny! > > > > randy > > In other words, our earlier estimate of 60% was way off... > you can get 92.1% effectiveness at bogon filtering by just > dropping 1918 addresses, a filter that you will never have to change. > > What's the operational cost trade-off with going after that > remaining 7.9%? I'll betcha it's not justifiable. Maybe > it's time to change the best current practices we recommend > so that they stop biting us in the ass every time a chunk of > our ever-dwindling pool of unused address space goes into play. > > My uncle used to tell this joke: > > Q: Why did the man hit himself in the head with a hammer? > A: Because it felt so good when he stopped? > > -r > > > > From tomb at byrneit.net Sat Aug 16 12:58:02 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sat, 16 Aug 2008 10:58:02 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808151259140.32BF5B92.20463@clifden.donelan.com> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com><20080806130937.GA99520@ussenterprise.ufp.org><4899B502.1090407@cymru.com><1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net><4899BCB2.6050808@psg.com><606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net><48A50330.6060902@psg.com><86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com><863al6xuyv.fsf@seastrom.com><200808150951010.28CAECBD.19528@clifden.donelan.com><86fxp6tird.fsf@seastrom.com><48A59E36.6070104@psg.com> <86zlneqnnb.fsf@seastrom.com><48A5A72B.50305@psg.com> <20080815121736.0ba27533@cs.columbia.edu> <200808151259140.32BF5B92.20463@clifden.donelan.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F493@pascal.zaphodb.org> In the case of routers and firewalls, managing your block lists dynamically is akin to checking the oil. Which is something too few car owners do as well. It's also relatively easy to do: For firewalls, I came up with ThreatSTOP to make this simple for everyone. Team Cymru has been doing this for routers forever. > -----Original Message----- > From: Sean Donelan [mailto:sean at donelan.com] > Sent: Friday, August 15, 2008 10:07 AM > To: Steven M. Bellovin > Cc: NANOG list > Subject: Re: Is it time to abandon bogon prefix filters? > > On Fri, 15 Aug 2008, Steven M. Bellovin wrote: > >> and i am saying that you should use a router configuration > *system* > >> that avoids ticking time bombs. no router should be neglected and > >> unloved. > >> > > That, I think, is why he distinguished between routers run > by "highly > > clueful people" and routers run by others. I think we all agree on > > your basic point; it's just that too many people aren't > clueful enough > > to realize that they even have a problem, let alone know > how to solve > > it. (Of course, you and I both have a background in programming > > languages and compilers, which is why we naturally think of router > > configurations as a form of assembler language that only a compiler > > should every emit.) > > > To avoid people feeling individually insulted, I sometimes > try to distinguish between the purposes of equipment rather > than the capabilities of the person maintaining it. > > A NASCAR racing team may perform extensive monitoring and > maintenance on their racing cars; but that doesn't mean I > should need a team of 5 mechanics to keep my regular street > car operating safely with a few idiot lights on the dashboard. > > > From randy at psg.com Sat Aug 16 20:55:45 2008 From: randy at psg.com (Randy Bush) Date: Sat, 16 Aug 2008 18:55:45 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <094101c8ff34$470632f0$660a0a0a@oneunified.local> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com> <20080806130937.GA99520@ussenterprise.ufp.org> <4899B502.1090407@cymru.com> <1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net> <4899BCB2.6050808@psg.com> <606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net> <48A50330.6060902@psg.com><86tzdmzcv3.fsf@seastrom.com> <48A58414.5090704@psg.com><863al6xuyv.fsf@seastrom.com> <200808150951010.28CAECBD.19528@clifden.donelan.com><86fxp6tird.fsf@seastrom.com> <48A59E36.6070104@psg.com> <094101c8ff34$470632f0$660a0a0a@oneunified.local> Message-ID: <48A78521.6000101@psg.com> >> i contend that all one's routers should be rigorously >> configured as programmatically as possible. > What sort of tools do you use to facilitate this? ntt/verio, level(3), ... have sophisticated locally developed systems. they see these as competitive advantage, so sharing is extremely unlikely. and, as they are home grown, they likely do not have a portable layer of indirection to corporate back-end data. some large telcos seem proud that "the network is the database of record" and are proud of it. i wish all my competitors thought that. for my own use, i use m4, python and perl, and peval() randy From jlewis at lewis.org Sun Aug 17 01:08:09 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 17 Aug 2008 02:08:09 -0400 (EDT) Subject: impossible circuit In-Reply-To: References: <20080812113649.GA4984@pwns.ms> Message-ID: On Tue, 12 Aug 2008, Jon Lewis wrote: >> What would happen if you pinged the Ocala router such that the TTL was 1 >> when travelling over the DS3? From your traceroute it seems it travelled >> two IP hops that did not send ICMP error messages, but it might just be >> that the ICMP errors from the Ocala router are arriving first. > > Based on where the dupes are coming from, I assume pinging across the DS3 > with TTL tuned to expire at the Ocala side would result in TTL exceeded > messages from both Ocala and the Sprint router where the packets are injected > into Sprint's network. It doesn't look as if IOS gives the option to set TTL > on ping...so I'd try this from a Linux machine in our data center. I just went ahead and "re-broke" the circuit for a bit by turning it back to hdlc to see if the issue is still there and to run some additional tests. Someone is still cross connecting our Orlando->Ocala traffic over to Sprint. I did your suggested ping with short TTL and the result was close to what I expected. $ traceroute ocalflxa-br-1 traceroute to ocalflxa-br-1.atlantic.net (209.208.6.229), 30 hops max, 38 byte packets 1 209.208.25.165 (209.208.25.165) 0.539 ms 0.426 ms 0.388 ms 2 69.28.72.162 (69.28.72.162) 0.246 ms 0.351 ms 0.223 ms 3 andc-br-3-f2-0 (209.208.9.138) 0.559 ms 0.435 ms 0.471 ms 4 ocalflxa-br-1-s1-0 (209.208.112.98) 2.735 ms * 2.656 ms So, I need a TTL of 4 to get there from this machine. $ ping -t4 ocalflxa-br-1 PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 time=2.68 ms 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 time=2.72 ms 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=2 ttl=252 time=2.88 ms Decrease ttl by one, and I get the expected ttl exceeded from the Orlando side of the circuit. $ ping -t 3 ocalflxa-br-1 PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. >From andc-br-3-f2-0.atlantic.net (209.208.9.138) icmp_seq=0 Time to live exceeded Now, here's a mild surprise. You'll notice that in the above -t4 trace, I didn't hear back from Sprint. $ ping -t 5 ocalflxa-br-1 PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 time=2.89 ms 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 time=3.10 ms 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=2 ttl=252 time=2.97 ms hmm...still no ttl exceeded from Sprint? $ ping -t 6 ocalflxa-br-1 PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 time=2.95 ms >From sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) icmp_seq=0 Time to live exceeded 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 time=2.78 ms >From sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) icmp_seq=1 Time to live exceeded $ ping -t 7 ocalflxa-br-1 PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 time=2.88 ms >From sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) icmp_seq=0 Time to live exceeded 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 time=2.84 ms >From sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) icmp_seq=1 Time to live exceeded Is it just coincidence that there are 2 private IP hops in some traceroutes between us and Sprint? i.e. Look at this trace from cogent: Tracing the route to 209.208.33.1 1 fa0-8.na01.b005944-0.dca01.atlas.cogentco.com (66.250.56.189) 0 msec 4 msec 4 msec 2 gi3-9.3507.core01.dca01.atlas.cogentco.com (66.28.67.225) 160 msec 4 msec 8 msec 3 te3-1.ccr02.dca01.atlas.cogentco.com (154.54.3.158) 0 msec 0 msec 4 msec 4 vl3493.mpd01.dca02.atlas.cogentco.com (154.54.7.230) 28 msec 4 msec te4-1.mpd01.dca02.atlas.cogentco.com (154.54.2.182) 52 msec 5 vl3494.mpd01.iad01.atlas.cogentco.com (154.54.5.42) 4 msec 4 msec vl3497.mpd01.iad01.atlas.cogentco.com (154.54.5.66) 4 msec 6 timewarner.iad01.atlas.cogentco.com (154.54.13.250) 4 msec peer-01-ge-3-1-2-13.asbn.twtelecom.net (66.192.252.217) 4 msec 12 msec 7 66-194-200-202.static.twtelecom.net (66.194.200.202) 28 msec 28 msec 32 msec 8 66-194-200-202.static.twtelecom.net (66.194.200.202) 32 msec 32 msec 28 msec 9 andc-br-3-f2-0.atlantic.net (209.208.9.138) 32 msec 32 msec 32 msec 10 172.22.122.1 32 msec 32 msec 32 msec 11 10.247.28.205 32 msec 32 msec 32 msec 12 sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) 32 msec 32 msec 28 msec 13 sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) 28 msec 32 msec 32 msec 14 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 32 msec 32 msec 28 msec 15 vlan79.csw2.Washington1.Level3.net (4.68.17.126) 28 msec vlan89.csw3.Washington1.Level3.net (4.68.17.190) 32 msec vlan79.csw2.Washington1.Level3.net (4.68.17.126) 40 msec 16 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 28 msec ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 28 msec ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 32 msec 17 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 48 msec 48 msec 56 msec 18 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 44 msec 48 msec ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 52 msec 19 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 56 msec 104 msec 56 msec 20 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 52 msec 52 msec 56 msec 21 unknown.Level3.net (63.209.98.66) 52 msec 52 msec 56 msec 22 andc-br-3-f2-0.atlantic.net (209.208.9.138) 52 msec 52 msec 56 msec 23 172.22.122.1 52 msec 56 msec 52 msec 24 10.247.28.205 52 msec 52 msec 56 msec 25 sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) 52 msec 56 msec 52 msec 26 sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) 56 msec 56 msec 56 msec 27 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 52 msec 52 msec 52 msec 28 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 52 msec vlan69.csw1.Washington1.Level3.net (4.68.17.62) 56 msec vlan89.csw3.Washington1.Level3.net (4.68.17.190) 56 msec 29 ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 64 msec ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 52 msec 56 msec 30 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 76 msec 72 msec 72 msec I've seen the 172.22.122.1 & 10.247.28.205 hops before. They occasionally show up in traces when the traffic is jumping over to Sprint. Sometimes they don't show up though. i.e. Tracing from my house: traceroute to 209.208.33.1 (209.208.33.1), 30 hops max, 40 byte packets 1 172.31.0.1 (172.31.0.1) 0.336 ms 0.272 ms 0.268 ms 2 10.210.160.1 (10.210.160.1) 10.109 ms 11.719 ms 14.265 ms 3 gig7-0-4-101.orldflaabv-rtr1.cfl.rr.com (24.95.232.100) 15.302 ms 15.324 ms 16.687 ms 4 198.228.95.24.cfl.res.rr.com (24.95.228.198) 16.688 ms 18.812 ms 18.816 ms 5 te-3-3.car1.Orlando1.Level3.net (4.79.116.145) 20.084 ms 19.946 ms te-3-1.car1.Orlando1.Level3.net (4.79.116.137) 21.328 ms 6 unknown.Level3.net (63.209.98.66) 19.900 ms 14.714 ms 14.689 ms 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 104.058 ms 11.932 ms 13.584 ms 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 15.872 ms 15.886 ms 17.238 ms 9 * * * 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 41.277 ms 41.964 ms 41.955 ms 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 43.360 ms 44.578 ms 35.635 ms 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 37.035 ms 37.062 ms 33.185 ms 13 vlan89.csw3.Washington1.Level3.net (4.68.17.190) 44.060 ms 44.057 ms vlan99.csw4.Washington1.Level3.net (4.68.17.254) 39.603 ms 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 38.123 ms ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 39.546 ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 38.115 ms 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 46.284 ms 46.275 ms 46.274 ms 16 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 52.523 ms ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 53.338 ms ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 53.299 ms 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 34.964 ms 39.582 ms 38.088 ms 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 36.701 ms 38.144 ms 36.949 ms 19 unknown.Level3.net (63.209.98.66) 36.902 ms 37.750 ms 37.717 ms 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 37.729 ms 35.812 ms 35.048 ms 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 37.485 ms 37.601 ms 36.495 ms 22 * * * 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 56.459 ms 56.449 ms 57.709 ms 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 57.694 ms 57.692 ms 60.243 ms 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 103.257 ms 100.829 ms 82.571 ms 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 70.401 ms vlan89.csw3.Washington1.Level3.net (4.68.17.190) 69.262 ms vlan99.csw4.Washington1.Level3.net (4.68.17.254) 82.700 ms 27 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 74.132 ms ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 74.135 ms ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 75.540 ms 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 58.656 ms 60.838 ms 54.346 ms 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 59.323 ms ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 59.336 ms ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 63.323 ms 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 127.652 ms 57.884 ms 57.851 ms >From the traces I've seen, it seems if the first Sprint hop is sl-bb20-dc, the private IP hops don't show up. If the first Sprint hop is sl-crs2-dc, then the private IP hops are there. I wonder if anyone from Sprint can shed some light on that? Unfortunately, the Sprint engineer I intitially made contact with who was helpful and seemed curious about the issue seems to have vanished and isn't returning my calls or emails. Anyone else from Sprintlink care to play? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From list-nanog at pwns.ms Sun Aug 17 01:36:23 2008 From: list-nanog at pwns.ms (list-nanog at pwns.ms) Date: Sun, 17 Aug 2008 06:36:23 +0000 Subject: impossible circuit In-Reply-To: References: <20080812113649.GA4984@pwns.ms> Message-ID: <20080817063623.GA23736@pwns.ms> > >From the traces I've seen, it seems if the first Sprint hop is sl-bb20-dc, > the private IP hops don't show up. If the first Sprint hop is sl-crs2-dc, > then the private IP hops are there. I wonder if anyone from Sprint can > shed some light on that? That's an interesting correlation, but maybe they don't appear because a router in the path is dropping packets sourced from private IPs? From jay at west.net Sun Aug 17 01:57:06 2008 From: jay at west.net (Jay Hennigan) Date: Sat, 16 Aug 2008 23:57:06 -0700 Subject: impossible circuit In-Reply-To: <20080817063623.GA23736@pwns.ms> References: <20080812113649.GA4984@pwns.ms> <20080817063623.GA23736@pwns.ms> Message-ID: <48A7CBC2.7040804@west.net> Is this only happening in one direction? One possibility is that the carrier has a different circuit that is provisioned up, HDLC, with no physical connection. A short-circuit in a DACS or MUX is bridging the transmit interface towards your destination with a transmit interface on the unused but active circuit. This would cause your traffic in that direction to fork both on the desired path and some rogue path that eventually gets routed to your destination. The ethernet equivalent would be a SPAN monitor port plumbed to a transmit-only interface on a different network. Definitely a strange one. If I'm correct, when the other circuit starts to get customer traffic things will probably break completely for either the new customer seeing your PPP traffic or for both of you. -- 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 jlewis at lewis.org Sun Aug 17 14:44:40 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 17 Aug 2008 15:44:40 -0400 (EDT) Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> References: <20080813204818.GG19971@puck.nether.net> <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> Message-ID: On Thu, 14 Aug 2008, Danny McPherson wrote: > I agree, how many of you folks that use IRRs have > ever deleted an IRR object? Heck, some ISPs even > add them based on existence of advertised routes. On that topic, how do you delete IRR objects when the person who created them used a unique maintainer object and is no longer around to provide the password for the maintainer object? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jared at puck.nether.net Sun Aug 17 14:55:51 2008 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 17 Aug 2008 15:55:51 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> Message-ID: <20080817195551.GA70344@puck.nether.net> On Sun, Aug 17, 2008 at 03:44:40PM -0400, Jon Lewis wrote: > On Thu, 14 Aug 2008, Danny McPherson wrote: > >> I agree, how many of you folks that use IRRs have >> ever deleted an IRR object? Heck, some ISPs even >> add them based on existence of advertised routes. > > On that topic, how do you delete IRR objects when the person who created > them used a unique maintainer object and is no longer around to provide > the password for the maintainer object? This is what the human at most db-admin aliases is for. I know that we staff humans behind our alias to respond to such queries. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nenolod at systeminplace.net Sun Aug 17 18:36:48 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Sun, 17 Aug 2008 18:36:48 -0500 Subject: RouterOS performance? Message-ID: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> Hi, We're looking at using Mikrotik's RouterOS for some some sort of software routing solution as part of our network in combination with supervised layer3 switching doing most likely some sort of limited BGP. Does anyone else here run it? Is it any good? Is it better than e.g. vyatta? If RouterOS and Vyatta both suck, is there any decent software routing solution? Our network is small (4 /24s) and we only need to push roughly 1-2gbit at the moment. Experiences with both would be appreciated. Thanks! William From joelja at bogus.com Sun Aug 17 19:16:31 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 17 Aug 2008 17:16:31 -0700 Subject: RouterOS performance? In-Reply-To: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> Message-ID: <48A8BF5F.70402@bogus.com> William Pitcock wrote: > Hi, > > We're looking at using Mikrotik's RouterOS for some some sort of > software routing solution as part of our network in combination with > supervised layer3 switching doing most likely some sort of limited BGP. > > Does anyone else here run it? Is it any good? Is it better than e.g. > vyatta? vyatta has some issues, but it's ok for a router optimizied linux distro... > If RouterOS and Vyatta both suck, is there any decent software routing > solution? Our network is small (4 /24s) and we only need to push roughly > 1-2gbit at the moment. > > Experiences with both would be appreciated. Thanks! haven't used routeros in a while but at the time it was inoffensive, it's not derived from a general purpose system so it's not something you bolt additional bits on if you need them. I actually use freebsd as a router on soekris, but I do need a general purpose os on the system as well. > William > > From thegameiam at yahoo.com Sun Aug 17 19:34:22 2008 From: thegameiam at yahoo.com (David Barak) Date: Sun, 17 Aug 2008 17:34:22 -0700 (PDT) Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080817195551.GA70344@puck.nether.net> Message-ID: <194298.29067.qm@web31808.mail.mud.yahoo.com> --- On Sun, 8/17/08, Jared Mauch wrote: > On Sun, Aug 17, 2008 at 03:44:40PM -0400, Jon Lewis wrote: > > On that topic, how do you delete IRR objects when the > person who created > > them used a unique maintainer object and is no longer > around to provide > > the password for the maintainer object? > > This is what the human at most db-admin aliases is for. > > I know that we staff humans behind our alias to respond to > such queries. Or this points to the utility of creating your own internal RRd server, and peering with the public IRRs. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From petelists at templin.org Sun Aug 17 19:57:25 2008 From: petelists at templin.org (Pete Templin) Date: Sun, 17 Aug 2008 19:57:25 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com><20080806130937.GA99520@ussenterprise.ufp.org><4899B502.1090407@cymru.com><1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net><4899BCB2.6050808@psg.com><606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net><48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> Message-ID: <48A8C8F5.7080102@templin.org> Tomas L. Byrnes wrote: > Since there are ways to dynamically filter the bogons, using BGP or DNS, > I don't really see the need to stop doing so. If you're managing your > routing and firewall filters manually, you have bigger problems than the > release of Bogon space. Can you share the Cisco configuration snippet you recommend to dynamically FILTER bogons using BGP or DNS? Not just inserting null-routes for the bogon aggregates, but preventing the acceptance of more-specifics that transits/peers/customers have managed to sneak past someone's filters (or lack thereof), please. (Without an offline configuration generator, I postulate that it can't be done.) pt From charles at thewybles.com Sun Aug 17 20:45:59 2008 From: charles at thewybles.com (Charles Wyble) Date: Sun, 17 Aug 2008 18:45:59 -0700 Subject: RouterOS performance? In-Reply-To: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> Message-ID: <48A8D457.60205@thewybles.com> William Pitcock wrote: > Hi, > > We're looking at using Mikrotik's RouterOS for some some sort of > software routing solution as part of our network in combination with > supervised layer3 switching doing most likely some sort of limited BGP. > > Does anyone else here run it? Is it any good? Is it better than e.g. > vyatta? > Hmmm...... the last time someone brought this subject up (hmmm mid July this year or so I think) it resulted in a 200 message thread. At least it felt like that. :) Anyway the thread was pretty informative. Check the archives for details. Check out quagga, xorp, click (a ucla project). Vyataa has evidently changed from Xorp to Quagga for the control plane if I read the messages and changelogs/release notes correctly. Feel free to post back with what you find or if you need additional resources. I'm sure others will post as well and give ya an earful :) -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From tomb at byrneit.net Sun Aug 17 22:36:09 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 17 Aug 2008 20:36:09 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A8C8F5.7080102@templin.org> References: <00ae01c8f71f$0f397610$d135190a@mediacomcorp.com><20080806130937.GA99520@ussenterprise.ufp.org><4899B502.1090407@cymru.com><1169F62F-3043-4D15-80C3-2D083744C22D@ianai.net><4899BCB2.6050808@psg.com><606BDFAE-F6B5-4756-9BA5-C3B17B96368A@tcb.net><48A50330.6060902@psg.com> <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> Message-ID: <70D072392E56884193E3D2DE09C097A9F4A4@pascal.zaphodb.org> ACLs > -----Original Message----- > From: Pete Templin [mailto:petelists at templin.org] > Sent: Sunday, August 17, 2008 5:57 PM > To: Tomas L. Byrnes > Cc: NANOG list > Subject: Re: Is it time to abandon bogon prefix filters? > > Tomas L. Byrnes wrote: > > Since there are ways to dynamically filter the bogons, using BGP or > > DNS, I don't really see the need to stop doing so. If > you're managing > > your routing and firewall filters manually, you have bigger > problems > > than the release of Bogon space. > > Can you share the Cisco configuration snippet you recommend > to dynamically FILTER bogons using BGP or DNS? Not just > inserting null-routes for the bogon aggregates, but > preventing the acceptance of more-specifics that > transits/peers/customers have managed to sneak past someone's > filters (or lack thereof), please. > > (Without an offline configuration generator, I postulate that > it can't be done.) > > pt > From nanog at daork.net Sun Aug 17 23:45:59 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 18 Aug 2008 16:45:59 +1200 Subject: RouterOS performance? In-Reply-To: <48A8BF5F.70402@bogus.com> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> Message-ID: <0EED1D4F-0059-4907-835B-C3B2E14036D9@daork.net> On 18/08/2008, at 12:16 PM, Joel Jaeggli wrote: > haven't used routeros in a while but at the time it was inoffensive, > it's not derived from a general purpose system so it's not something > you bolt additional bits on if you need them. RouterOS is Linux based. You're correct though, you can't bolt extra stuff on to it, though I'm pretty sure they do their own 'packages', so maybe 3rd parties can bolt stuff on that way? I dunno. > I actually use freebsd as a router on soekris, but I do need a > general purpose os on the system as well. I do this as well, works fantastically. I've got some build scripts that build NET4x01 images. Kernel and root filesystem in a single file, boot off a FAT32 formatted compact flash card with GRUB installed on it. Config in a single file (a filesystem image that gets mounted at boot time). IPv6 support. Packages go in a separate filesystem image per package, and get mounted at boot time, and added in to PATH etc. Package upgrades are a single file. Packages include Quagga, for example. XORP works as well, but it's super slow on 133Mhz Soekris hardware. Takes about 20MB on a CF card. Upgrade is much like any other embedded device - upload a single file, tweak your boot loader, reboot. Everything is nice and read only, so you don't have to worry about people fiddling with stuff they shouldn't and having it break on upgrade. Every bit of config is in the config image. Not really wanting to give it away publicly as I don't want to have to deal with supporting it, but if anyone wants it as a basis for your own thing drop me an email (nward at braintrust.co.nz please). ps. before someone accuses me of trying to sell stuff, I mean free as in beer. Cheers, -- Nathan Ward From darkuncle at gmail.com Mon Aug 18 00:20:45 2008 From: darkuncle at gmail.com (Scott Francis) Date: Sun, 17 Aug 2008 22:20:45 -0700 Subject: RouterOS performance? In-Reply-To: <0EED1D4F-0059-4907-835B-C3B2E14036D9@daork.net> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> <0EED1D4F-0059-4907-835B-C3B2E14036D9@daork.net> Message-ID: <171423de0808172220j21621784yd8b2fb99d807f4bc@mail.gmail.com> On Sun, Aug 17, 2008 at 9:45 PM, Nathan Ward wrote: > On 18/08/2008, at 12:16 PM, Joel Jaeggli wrote: > >> haven't used routeros in a while but at the time it was inoffensive, it's >> not derived from a general purpose system so it's not something you bolt >> additional bits on if you need them. > > RouterOS is Linux based. > You're correct though, you can't bolt extra stuff on to it, though I'm > pretty sure they do their own 'packages', so maybe 3rd parties can bolt > stuff on that way? I dunno. > >> I actually use freebsd as a router on soekris, but I do need a general >> purpose os on the system as well. > > > I do this as well, works fantastically. > > I've got some build scripts that build NET4x01 images. Kernel and root > filesystem in a single file, boot off a FAT32 formatted compact flash card > with GRUB installed on it. Config in a single file (a filesystem image that > gets mounted at boot time). IPv6 support. [snip] sounds a lot like Chris Cappuccio's flashdist[0], although that's OpenBSD-specific. (worth noting that I'm partial to OpenBSD here, for both the security track record and tools like pf(4), carp(4), OpenBGPD, etc.) [0]http://www.nmedia.net/flashdist/ -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From nanog at daork.net Mon Aug 18 00:56:07 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 18 Aug 2008 17:56:07 +1200 Subject: RouterOS performance? In-Reply-To: <171423de0808172220j21621784yd8b2fb99d807f4bc@mail.gmail.com> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> <0EED1D4F-0059-4907-835B-C3B2E14036D9@daork.net> <171423de0808172220j21621784yd8b2fb99d807f4bc@mail.gmail.com> Message-ID: <58DFB2E4-887D-4F58-B8BF-5DA9054DB059@daork.net> On 18/08/2008, at 5:20 PM, Scott Francis wrote: > sounds a lot like Chris Cappuccio's flashdist[0], although that's > OpenBSD-specific. > > (worth noting that I'm partial to OpenBSD here, for both the security > track record and tools like pf(4), carp(4), OpenBGPD, etc.) Yep, but no 6to4, which I needed. Also OpenBGPd/OpenOSPFd are a bit weird because OpenBGPd can't use the IGP metric in the path selection algorithm, as the kernel doesn't support metrics on routes. Quagga can do this obviously, as it is a single thing (well, all the kernel interface goes through zebrad). I also had some weird problem with how it would resolve recursive next hops, but I was using 6to4 addresses as next-hops, so I think that was part of the problem. Again, worked perfectly on Quagga. Oh yeah, it was trying to be too smart and resolve the recursive next-hop before installing the route in to the kernel, instead of installing the route and letting the kernel resolve it as it was forwarding packets. That broke because of how 6to4 and the routing table works in FreeBSD. Anyway, long story short, quagga did the job. Fine if you're doing vanilla BGP on a border router or something though, but doesn't work for me in a complex network. One cool thing about OpenBGPd is bgpctl irrfilter, which pulls in RPSL and does the business with it, and stuffs it in to your live BGP daemon. -- Nathan Ward From michael.dillon at bt.com Mon Aug 18 03:51:20 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Aug 2008 09:51:20 +0100 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A78521.6000101@psg.com> Message-ID: > for my own use, i use m4, python and perl, and peval() m4 is a macro processor that you probably should not bother learning since you can do everything that it does by using Python and regular expressions, or one of the Python parsing modules. For instance PLY supports conditional lexing and start conditions which you need to change parsing rules depending on which config section you are in. There is also a package called ciscoconfparse which I don't know much about http://ciscoconfparse.wiki.sourceforge.net/ peval() is part of the IRRToolSet which can be found here: http://www.isc.org/index.pl?/sw/IRRToolSet/ --Michael Dillon From michael.dillon at bt.com Mon Aug 18 03:53:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Aug 2008 09:53:27 +0100 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A8C8F5.7080102@templin.org> Message-ID: > (Without an offline configuration generator, I postulate that > it can't be done.) Doesn't everyone use an offline config generator these days? After all, there is a lot more CPU power and database capacity outside of the routers than there is inside. --Michael Dillon From jaitken at aitken.com Mon Aug 18 07:25:02 2008 From: jaitken at aitken.com (Jeff Aitken) Date: Mon, 18 Aug 2008 12:25:02 +0000 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: References: <48A78521.6000101@psg.com> Message-ID: <20080818122502.GA26832@eagle.aitken.com> On Mon, Aug 18, 2008 at 09:51:20AM +0100, michael.dillon at bt.com wrote: > m4 is a macro processor that you probably should not bother > learning since you can do everything that it does by using Python Oh, Abley is gonna have fun with this... and for the record, my money is on Joe. He could probably implement python *IN* m4 if you offered enough beer! --Jeff From jared at puck.nether.net Mon Aug 18 07:33:08 2008 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Aug 2008 08:33:08 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A8C8F5.7080102@templin.org> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> Message-ID: <20080818123308.GA47385@puck.nether.net> On Sun, Aug 17, 2008 at 07:57:25PM -0500, Pete Templin wrote: > Tomas L. Byrnes wrote: >> Since there are ways to dynamically filter the bogons, using BGP or DNS, >> I don't really see the need to stop doing so. If you're managing your >> routing and firewall filters manually, you have bigger problems than the >> release of Bogon space. > > Can you share the Cisco configuration snippet you recommend to > dynamically FILTER bogons using BGP or DNS? On a router with full routes (ie: no default) the command is: Router(config-if)#ip verify unicast source reachable-via any Go ahead and try it out. you can view the resulting drop counter via the 'show ip int ' command. While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From petelists at templin.org Mon Aug 18 08:21:38 2008 From: petelists at templin.org (Pete Templin) Date: Mon, 18 Aug 2008 08:21:38 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080818123308.GA47385@puck.nether.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> Message-ID: <48A97762.1000104@templin.org> Jared Mauch wrote: > On a router with full routes (ie: no default) the command > is: > > Router(config-if)#ip verify unicast source reachable-via any None of these suggestions (including the wisecrack "ACLs") provide full filtering: If a miscreant originates a route in bogon space, their transit provider(s) doesn't filter their customers, and you or your peer/transit doesn't filter their peers/transits, your router will accept the route in bogon space and will accept the bogon packets. Filtering has not been accomplished, and the bogon attack vector remains open. Rather than hoping that everyone filters their customers or that all of my transits filter every peer, if I want to protect my network from bogon packets, I need to ensure that my routers won't accept any prefixes in bogon space. The Team Cymru BGP feed does NOT provide this function; it merely provides a way to inject null routes for bogon aggregates. And no, I don't have offline configuration generators. We don't have the coding experience in-house. Oh well. pt From sam_mailinglists at spacething.org Mon Aug 18 09:01:00 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Mon, 18 Aug 2008 15:01:00 +0100 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A97762.1000104@templin.org> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48A97762.1000104@templin.org> Message-ID: <48A9809C.1010708@spacething.org> Pete Templin wrote: > Jared Mauch wrote: > >> On a router with full routes (ie: no default) the command >> is: >> >> Router(config-if)#ip verify unicast source reachable-via any > > None of these suggestions (including the wisecrack "ACLs") provide > full filtering: > > If a miscreant originates a route in bogon space, their transit > provider(s) doesn't filter their customers, and you or your > peer/transit doesn't filter their peers/transits, your router will > accept the route in bogon space and will accept the bogon packets. > Filtering has not been accomplished, and the bogon attack vector > remains open. > > Rather than hoping that everyone filters their customers or that all > of my transits filter every peer, if I want to protect my network from > bogon packets, I need to ensure that my routers won't accept any > prefixes in bogon space. The Team Cymru BGP feed does NOT provide > this function; it merely provides a way to inject null routes for > bogon aggregates. I think you misunderstand the meaning of the "ip verify unicasr source reachable-via any" command. When a packet arrives the router will drop it if it doesn't have a valid return path for the source. Since the source is a bogon, and routed to Null0, then the inbound packet is dropped. Sam From nanog at daork.net Mon Aug 18 09:15:51 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 19 Aug 2008 02:15:51 +1200 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A9809C.1010708@spacething.org> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48A97762.1000104@templin.org> <48A9809C.1010708@spacething.org> Message-ID: On 19/08/2008, at 2:01 AM, Sam Stickland wrote: > I think you misunderstand the meaning of the "ip verify unicasr > source reachable-via any" command. When a packet arrives the router > will drop it if it doesn't have a valid return path for the source. > Since the source is a bogon, and routed to Null0, then the inbound > packet is dropped. If you read his post, I think you'll find that he understands perfectly. He is talking about both packet filtering, and prefix filtering. Scenario (exactly what Pete describes, but a bit more verbose): - We have bogon filtering using the method you describe. It works great, because we don't have any routes for things that are in bogon space, so we drop those packets on the floor. - Attacker has a BGP session with a carrier that, for whatever reason, doesn't filter their customer's announcements. Attacker advertises a longer prefix in bogon space than we have null routed, and that advertisement makes it on to the the wider network. - Because we now have an advertisement, we're going to accept packets sourced from that prefix. BGP triggered bogon filtering is no longer working for us, for that particular prefix. The question is, is this scenario really that likely, and if it is, is it going to happen often enough for it to be a problem? I would say that with the decrease in attackers using false source IPv4 addresses (because they all have big bot nets with throwaway nodes, so why bother hiding where those nodes are?), then this sort of attack loses value. Then again, not everyone who does these attacks thinks them through, so who knows? It's also obviously very easy to trace the source of these announcements, however that doesn't necessarily find the guilty party, in the case of a hacked router for example. I agree that bogon filtering with a Team Cymru BGP feed is good - it will do the job most of the time. However, it cannot be considered a complete solution. -- Nathan Ward From cmadams at hiwaay.net Mon Aug 18 09:29:52 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 18 Aug 2008 09:29:52 -0500 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48A9809C.1010708@spacething.org> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48A97762.1000104@templin.org> <48A9809C.1010708@spacething.org> Message-ID: <20080818142952.GB1302536@hiwaay.net> Once upon a time, Sam Stickland said: > I think you misunderstand the meaning of the "ip verify unicasr source > reachable-via any" command. When a packet arrives the router will drop > it if it doesn't have a valid return path for the source. Since the > source is a bogon, and routed to Null0, then the inbound packet is dropped. First, that is only true on Cisco routers (all the world is not a Cisco). Second, you are missing the point: you have bogon route for 10/8, but rouge route for 10.1/16 (or even 10.0/9 and 10.128/9) arrives; it is more specific and your automatic bogon filter is useless. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jra at baylink.com Mon Aug 18 12:09:22 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 18 Aug 2008 13:09:22 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum Message-ID: <20080818170922.GB10900@cgi.jachomes.com> http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html Well, on reading it, it's more an "IPv6: It's great -- ask for it by name!" piece. 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. -- (Josef Stalin) From james at jdfogg.com Mon Aug 18 13:09:22 2008 From: james at jdfogg.com (james) Date: Mon, 18 Aug 2008 13:09:22 -0500 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum Message-ID: <48a9bad2.207.f88.13668@jdfogg.com> http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html > > Well, on reading it, it's more an "IPv6: It's great -- ask > for it by name!" piece. IPv6 gives me brain ache. I hear I'm not alone in that. I'd v6 tomorrow if I didn't have to think about it so hard. From deepak at ai.net Mon Aug 18 13:19:01 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 18 Aug 2008 14:19:01 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48a9bad2.207.f88.13668@jdfogg.com> References: <48a9bad2.207.f88.13668@jdfogg.com> Message-ID: <48A9BD15.2030407@ai.net> james wrote: > http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html >> Well, on reading it, it's more an "IPv6: It's great -- ask >> for it by name!" piece. > > > IPv6 gives me brain ache. I hear I'm not alone in that. I'd > v6 tomorrow if I didn't have to think about it so hard. You just need 96 more bits in your head everywhere you store IPv4 techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4 gave us brain ache when it was new to us too. I'm sure there are already folks in environs that are mostly IPv6 that can spit off binary to hex to decimal IPv6 addresses. The US tends not to be one of those environs. It'll come. operational content: Is anyone significantly redesigning the way they route/etc to take advantage of any hooks that IPv6 provides-for (even if its a proprietary implementation)? As far as I can tell, most people are just implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, etc). I know we aren't use auto-config on critical server architecture and instead nailing in addressing like we would in IPv4. (an address hopping firewall is not necessarily a good thing ;) ). Deepak From trejrco at gmail.com Mon Aug 18 13:42:53 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 14:42:53 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48A9BD15.2030407@ai.net> References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> Message-ID: <009501c90162$39fd8ab0$adf8a010$@com> >-----Original Message----- >From: Deepak Jain [mailto:deepak at ai.net] >Sent: Monday, August 18, 2008 2:19 PM >To: james >Cc: nanog at nanog.org >Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum > > > >james wrote: >> http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4 >> -addresses-time-for-ipv6-really.html >>> Well, on reading it, it's more an "IPv6: It's great -- ask for it by >>> name!" piece. >> >> >> IPv6 gives me brain ache. I hear I'm not alone in that. I'd >> v6 tomorrow if I didn't have to think about it so hard. > >You just need 96 more bits in your head everywhere you store IPv4 >techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4 >gave us brain ache when it was new to us too. A little software and/or memory upgrade to support dual-stack? > >I'm sure there are already folks in environs that are mostly IPv6 that can >spit off binary to hex to decimal IPv6 addresses. The US tends not to be one >of those environs. Indeed, we do exist! And it does become natural, given enough time & practice. (And yes, some of us are even in the US ... but not that many, yet (... which is good for business ...)) > >It'll come. > >operational content: Is anyone significantly redesigning the way they >route/etc to take advantage of any hooks that IPv6 provides-for (even if its >a proprietary implementation)? As far as I can tell, most people are just >implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, >etc). >From what I have seen, no. I have seen no interest what-so-ever in redesigning the networks; most see it as enough work to get IPv6 into their environment and don't want to complicate the project with any "above and beyond" work. Additionally, most are keeping IPv4 for just a bit longer so would be hampered in redoing their architecture by that little factor. > >I know we aren't use auto-config on critical server architecture and instead >nailing in addressing like we would in IPv4. (an address hopping firewall is >not necessarily a good thing ;) ). As a general rule, most clients are following the "If we gave them static IPv4 addresses we will give them static IPv6 addresses" (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit related) conversation ... > >Deepak /TJ From billn at billn.net Mon Aug 18 13:52:54 2008 From: billn at billn.net (Bill Nash) Date: Mon, 18 Aug 2008 11:52:54 -0700 (MST) Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: <20080817195551.GA70344@puck.nether.net> References: <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> <20080817195551.GA70344@puck.nether.net> Message-ID: On Sun, 17 Aug 2008, Jared Mauch wrote: >>> I agree, how many of you folks that use IRRs have >>> ever deleted an IRR object? Heck, some ISPs even >>> add them based on existence of advertised routes. >> >> On that topic, how do you delete IRR objects when the person who created >> them used a unique maintainer object and is no longer around to provide >> the password for the maintainer object? > > This is what the human at most db-admin aliases is for. > > I know that we staff humans behind our alias to respond to > such queries. > Absent any kind of network wide enforcement, why don't you just roll participation and compliance with this into your peering contracts, with propagation? Require your peers to have it, and ask that they pass the requirement on. This isn't rocket science, clearly, because even I understand it. All it takes it a couple of larger entities to set the bar, and drag everyone up. Some of this may amount to teaching your peers to fish, but if everyone wins, thanks for contributing. Require peers to support IRR objects. Require them to have an alias that points at an always existing human. Require them to maintain their entries. And then do it yourself so they can see how it's done. - billn From swmike at swm.pp.se Mon Aug 18 13:57:27 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 18 Aug 2008 20:57:27 +0200 (CEST) Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48A9BD15.2030407@ai.net> References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> Message-ID: On Mon, 18 Aug 2008, Deepak Jain wrote: > operational content: Is anyone significantly redesigning the way they > route/etc to take advantage of any hooks that IPv6 provides-for (even if its > a proprietary implementation)? As far as I can tell, most people are just > implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, > etc). Yes, there are those of us who want to save number of routes and "spending" IPv6 addresses to save on TCAM and convergence time. Using /112 for link networks to make the last octet ::1 and ::2 for links also makes sense from the human perspective. Also, I try to involve myself in IETF ipv6ops-wg via their mailing list, and they're definitely interested in getting more people involved. Doing IPv6 in the core is easy, it's in the access that there is much work to be done for all access methods. If you're doing PPPoE you're probably home free, most of the rest just isn't operationally sane yet for ISP environment (stop customers doing rouge RA, man in the middle, spoofing). For instance, I (and a few others) have been advocating that ISP core IPv6 space and customer IPv6 space should be separate, with link-local in between (so core can be "protected" at borders, and also to save on TCAM in the access devices (doing routing+antispoofing if there is only single /48 to the customer uses less router resources than doing /48 + link network)). Other people have other opinions. A lot of this is happening now, so if you want something down the road, please put in the effort now. -- Mikael Abrahamsson email: swmike at swm.pp.se From deepak at ai.net Mon Aug 18 14:04:13 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 18 Aug 2008 15:04:13 -0400 Subject: Public shaming list for ISPs announcing other ISPs IP space by mistake In-Reply-To: References: <20080813210451.GI19971@puck.nether.net> <20080814145658.GD53528@puck.nether.net> <48A4495B.5020904@psg.com> <48A477B5.1080803@uk.clara.net> <20080814190917.GI53528@puck.nether.net> <31B6767F-E4D1-46BC-9F92-73B40AFA87DD@tcb.net> <20080817195551.GA70344@puck.nether.net> Message-ID: <48A9C7AD.3060400@ai.net> > Absent any kind of network wide enforcement, why don't you just roll > participation and compliance with this into your peering contracts, with > propagation? Require your peers to have it, and ask that they pass the > requirement on. This isn't rocket science, clearly, because even I > understand it. All it takes it a couple of larger entities to set the > bar, and drag everyone up. Some of this may amount to teaching your > peers to fish, but if everyone wins, thanks for contributing. > > Require peers to support IRR objects. > Require them to have an alias that points at an always existing human. > Require them to maintain their entries. > > And then do it yourself so they can see how it's done. The business process would read: "New procedures will reduce the operational cost of our operations by xx%". "All peering contracts renewed or executed after [date] will comply to document xxxx". Revised customer IP provisioning procedures: "Insert new customer IP info into our local IRR. Customer IPs will not work if this is not done." "Press here to cause us to spin our configuration builder." Deepak From ejensen at jensenresearch.com Mon Aug 18 14:09:42 2008 From: ejensen at jensenresearch.com (Eric Jensen) Date: Mon, 18 Aug 2008 15:09:42 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: Message-ID: <5.1.0.14.2.20080818145743.00364728@mail.jrc.lan> > >Message: 3 >Date: Mon, 18 Aug 2008 08:21:38 -0500 >From: Pete Templin >Subject: Re: Is it time to abandon bogon prefix filters? > >None of these suggestions (including the wisecrack "ACLs") provide full >filtering: > >If a miscreant originates a route in bogon space, their transit >provider(s) doesn't filter their customers, and you or your peer/transit >doesn't filter their peers/transits, your router will accept the route >in bogon space and will accept the bogon packets. Filtering has not >been accomplished, and the bogon attack vector remains open. We recently expanded our network, separating our multi-homed transit network from our corporate and 'network services' LANs. We use BGP sessions between our transit and services networks to trade internal (RFC1918) routes as well as supply a default route. We do not trade external routes over these news sessions. A happy side-effect of this is that our black-hole router, with a cymru bogon feed, now populates the corporate routing table, rather than our full transit table, and by using strict URPF all bogon traffic gets dropped (inbound), and no more-specific routes learned by the transit routers will override our BH routes. - Eric AS17103 From streiner at cluebyfour.org Mon Aug 18 14:18:05 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 18 Aug 2008 15:18:05 -0400 (EDT) Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48A9BD15.2030407@ai.net> References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> Message-ID: On Mon, 18 Aug 2008, Deepak Jain wrote: > operational content: Is anyone significantly redesigning the way they > route/etc to take advantage of any hooks that IPv6 provides-for (even if its > a proprietary implementation)? As far as I can tell, most people are just > implementing it as IPv4 with a lot of bits (i.e. /126s for link interfaces, > etc). There seem to be differing schools of thought on this, but personally I'm leaning in this direction at least for network infrastructure. Just because IPv6 provides boatloads more space doesn't mean that I like wasting addresses :) jms From tomb at byrneit.net Mon Aug 18 14:28:44 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 18 Aug 2008 12:28:44 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080818142952.GB1302536@hiwaay.net> References: <86tzdmzcv3.fsf@seastrom.com><70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org><48A8C8F5.7080102@templin.org><20080818123308.GA47385@puck.nether.net><48A97762.1000104@templin.org> <48A9809C.1010708@spacething.org> <20080818142952.GB1302536@hiwaay.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F4AE@pascal.zaphodb.org> If all you're using is BGP null routes, that's true. I would posit that BCP include Prefix filtering and ACLs as well, with dynamic updates. YMMV. > -----Original Message----- > From: Chris Adams [mailto:cmadams at hiwaay.net] > Sent: Monday, August 18, 2008 7:30 AM > To: NANOG list > Subject: Re: Is it time to abandon bogon prefix filters? > > Once upon a time, Sam Stickland > said: > > I think you misunderstand the meaning of the "ip verify > unicasr source > > reachable-via any" command. When a packet arrives the > router will drop > > it if it doesn't have a valid return path for the source. Since the > > source is a bogon, and routed to Null0, then the inbound > packet is dropped. > > First, that is only true on Cisco routers (all the world is > not a Cisco). > > Second, you are missing the point: you have bogon route for > 10/8, but rouge route for 10.1/16 (or even 10.0/9 and > 10.128/9) arrives; it is more specific and your automatic > bogon filter is useless. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From danny at tcb.net Mon Aug 18 14:29:06 2008 From: danny at tcb.net (Danny McPherson) Date: Mon, 18 Aug 2008 13:29:06 -0600 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080818123308.GA47385@puck.nether.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> Message-ID: <2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> On Aug 18, 2008, at 6:33 AM, Jared Mauch wrote: > > On a router with full routes (ie: no default) the command > is: > > Router(config-if)#ip verify unicast source reachable-via any > > Go ahead and try it out. you can view the resulting > drop counter via the 'show ip int ' command. > > While you're at it, you also placed the reachable-via rx on > all your customer interfaces. If you're paranoid, start with the > 'any' > rpf and then move to the strict rpf. The strict rpf also helps with > routing loops. That's a good point. My problem with "loose mode" RPF is that it subjects a packet's source address to ANY FIB entry existence only mitigates spoofing of non-routed ranges. All the interesting attacks today that employ spoofing (and the majority of the less-interesting ones that employ spoofing) are usually relying on existence of the source as part of the attack vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS reflective amplification attacks, etc..), and as a result, loose mode gives folks a false sense of protection/action. -danny From surfer at mauigateway.com Mon Aug 18 14:33:46 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Aug 2008 12:33:46 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 Message-ID: <20080818123346.9AC36924@resin13.mta.everyone.net> ---------- trejrco at gmail.com wrote: ------------ From: "TJ" As a general rule, most clients are following the "If we gave them static IPv4 addresses we will give them static IPv6 addresses" (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit related) conversation ... ---------------------------------------------------- I'm still an IPv6 wussie and would like to learn more before moving forward, so would anyone care to share info on experiences with this decision? scott From hcb at netcases.net Mon Aug 18 14:42:29 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Mon, 18 Aug 2008 15:42:29 -0400 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <20080818123346.9AC36924@resin13.mta.everyone.net> References: <20080818123346.9AC36924@resin13.mta.everyone.net> Message-ID: <007b01c9016a$8cd72180$020fa8c0@HDESK1> To try to stay operational about this, I have a reality testing question I've used in IPv4 and, for that matter, bridged networks: If you want to test a resource, be it the end user or an infrastructure interface, how do you know how to foo it (foo being some value of ping, traceroute, look it up in SNMP/NetFlow, etc)? I submit that if you use dynamic assignment of any sort, you really have to have DNS dynamic update, so you can use a known name to query the function that's indexed by address. Otherwise, static addresses become rather necessary if you want to check a resource. This was especially a question when L2 was "in" and routing was out: how do you ping a MAC address? Howard -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Monday, August 18, 2008 3:34 PM To: nanog at nanog.org Subject: SLAAC(autoconfig) vs DHCPv6 ---------- trejrco at gmail.com wrote: ------------ From: "TJ" As a general rule, most clients are following the "If we gave them static IPv4 addresses we will give them static IPv6 addresses" (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit related) conversation ... ---------------------------------------------------- I'm still an IPv6 wussie and would like to learn more before moving forward, so would anyone care to share info on experiences with this decision? scott From simon at darkmere.gen.nz Mon Aug 18 14:44:48 2008 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Tue, 19 Aug 2008 07:44:48 +1200 Subject: NANOG List Monthly Post. Message-ID: General Information =================== About NANOG: http://www.nanog.org/about.html NANOG News: http://www.nanog.org/ The NANOG list: http://www.nanog.org/mailinglist.html NANOG List AUP: http://www.nanog.org/aup.html NANOG List FAQ: http://www.nanog.org/listfaq.html To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the BB-Outage mailing lists http://www.dataoutages.com/ * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendees - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists is at the end of the FAQ here: http://www.nanog.org/listfaq.html#pointers From surfer at mauigateway.com Mon Aug 18 14:52:50 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 18 Aug 2008 12:52:50 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 Message-ID: <20080818125250.9AC36D2A@resin13.mta.everyone.net> -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] ---------- trejrco at gmail.com wrote: ------------ As a general rule, most clients are following the "If we gave them static IPv4 addresses we will give them static IPv6 addresses" (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit related) conversation ... ---------------------------------------------------- I'm still an IPv6 wussie and would like to learn more before moving forward, so would anyone care to share info on experiences with this decision? -- hcb at netcases.net wrote: From: "Howard C. Berkowitz" To try to stay operational about this ------------------------ Seeing Howard's quick response saying "To try to stay operational about this..." makes me realize I may have inadvertently invited a religious flame fest. Please! Operational content and hands-on experiences only to the best of your ability. I want to learn from this, not delete the whole thread. scott From dwcarder at wisc.edu Mon Aug 18 15:23:58 2008 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon, 18 Aug 2008 15:23:58 -0500 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <20080818123346.9AC36924@resin13.mta.everyone.net> References: <20080818123346.9AC36924@resin13.mta.everyone.net> Message-ID: <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> Hey Scott, On Aug 18, 2008, at 2:33 PM, Scott Weeks wrote: > From: "TJ" > > As a general rule, most clients are following the "If we gave them > static > IPv4 addresses we will give them static IPv6 > addresses" (infrastructure, > servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate > (albeit > related) conversation ... > ---------------------------------------------------- > > I'm still an IPv6 wussie and would like to learn more before moving > forward, so would anyone care to share info on experiences with this > decision? Here's some pro's and con's to both SLAAC: - widely implemented in host v6 stacks that have shipped - widely implemented on v6 routers - really, really, really broken: it didn't support handing out any DNS info until RFC 5006, thus SLAAC still requires human intervention on a client to make "teh v6 interwebs" work. It will probably be a painful wait until 5006 gets more widely implemented on hosts (if ever, for some) & routers. - probably "faster" than dhcpv6 w/ tuning timers. Could be better for mobile thingys. - supports RFC 3041 "security by obscurity" extensions. DHCPv6 - doesn't ship w/ some OS's - new (danger code), not all features implemented - router support for dhcpv6 relay very limited - advanced things like prefix delegation don't really seem to have been ironed out. In case you weren't confused enough between the two, they are not mutually exclusive. You can run both SLAAC and DHCPv6 at the same time on the same L2. Links for (2) dhcpv6 implementations: http://klub.com.pl/dhcpv6/ http://www.isc.org/index.pl?/sw/dhcp/dhcp4_0.php Cheers, Dale From trejrco at gmail.com Mon Aug 18 15:28:20 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 16:28:20 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> Message-ID: <00e201c90170$f574fea0$e05efbe0$@com> >-----Original Message----- >From: Justin M. Streiner [mailto:streiner at cluebyfour.org] >Sent: Monday, August 18, 2008 3:18 PM >To: nanog at nanog.org >Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum > >On Mon, 18 Aug 2008, Deepak Jain wrote: > >> operational content: Is anyone significantly redesigning the way they >> route/etc to take advantage of any hooks that IPv6 provides-for (even >> if its a proprietary implementation)? As far as I can tell, most >> people are just implementing it as IPv4 with a lot of bits (i.e. /126s >> for link interfaces, etc). > >There seem to be differing schools of thought on this, but personally I'm >leaning in this direction at least for network infrastructure. Just because >IPv6 provides boatloads more space doesn't mean that I like wasting >addresses :) Another side of that argument is operational complexity ... /126's do make the addresses harder (as a previous poster mentioned) as well as inducing other potential headaches (reserved address to watch out for, requiring another route to get to a client's network, etc). That is why the official answer is to always use /64s, even on PtP links. This is one area where the real world and the IETF don't always agree, and in this case that can be OK. > >jms /TJ From charles at thewybles.com Mon Aug 18 14:52:06 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 18 Aug 2008 12:52:06 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <007b01c9016a$8cd72180$020fa8c0@HDESK1> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <007b01c9016a$8cd72180$020fa8c0@HDESK1> Message-ID: <48A9D2E6.3010507@thewybles.com> Howard C. Berkowitz wrote: > To try to stay operational about this, Hmmmm. I think this is an operational topic, but I can see how it would be seen as more of a strategic item. > I have a reality testing question > I've used in IPv4 and, for that matter, bridged networks: > > > I submit that if you use dynamic assignment of any sort, you really have to > have DNS dynamic update, so you can use a known name to query the function > that's indexed by address. Otherwise, static addresses become rather > necessary if you want to check a resource. > Naturally. DNS name would be required, or a static address. In an ISP/service provider environment I imagine that being able to hand out dynamic ranges would be useful. Having to handle that statically would be painful. :) > This was especially a question when L2 was "in" and routing was out: how do > you ping a MAC address? > l2ping works on bluetooth devices on Linux. Might work for other stuff as well. Not sure what Cisco offers in this regard. -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From trejrco at gmail.com Mon Aug 18 15:34:01 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 16:34:01 -0400 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <20080818123346.9AC36924@resin13.mta.everyone.net> References: <20080818123346.9AC36924@resin13.mta.everyone.net> Message-ID: <00e301c90171$c087fe80$4197fb80$@com> >-----Original Message----- >From: Scott Weeks [mailto:surfer at mauigateway.com] >Sent: Monday, August 18, 2008 3:34 PM >To: nanog at nanog.org >Subject: SLAAC(autoconfig) vs DHCPv6 > > > >---------- trejrco at gmail.com wrote: ------------ >From: "TJ" > >As a general rule, most clients are following the "If we gave them static >IPv4 addresses we will give them static IPv6 addresses" (infrastructure, >servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit >related) conversation ... >---------------------------------------------------- > > >I'm still an IPv6 wussie and would like to learn more before moving forward, >so would anyone care to share info on experiences with this decision? Which one? "If we gave them static IPv4 addresses we will give them static IPv6 addresses" Or "SLAAC(autoconfig) vs DHCPv6" For the first ... at the simplest, it is familiar and comfortable. In general: Servers, Routers, Firewalls, Switches (atleast those with L3 addresses) == static address Hosts == dynamic ... either SLAAC or DHCPv6. Manual Configuration of hosts is a non-starter for most environments. For the latter ... that gets more involved. Many (most?) platforms do not support DHCPv6 client functionality. Ditto on the server side. OTOH, SLAAC alone cannot currently give you DNS information ... a possible deal-breaker, that. (Some work under way to change that, or the environment can cheat 0 rely on IPv4 transport for DNS :) ) > >scott HTH! /TJ From trejrco at gmail.com Mon Aug 18 15:41:08 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 16:41:08 -0400 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <007b01c9016a$8cd72180$020fa8c0@HDESK1> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <007b01c9016a$8cd72180$020fa8c0@HDESK1> Message-ID: <00ea01c90172$be9f9a00$3bdece00$@com> >-----Original Message----- >From: Howard C. Berkowitz [mailto:hcb at netcases.net] >Sent: Monday, August 18, 2008 3:42 PM >To: nanog at nanog.org >Subject: RE: SLAAC(autoconfig) vs DHCPv6 > >To try to stay operational about this, I have a reality testing question >I've used in IPv4 and, for that matter, bridged networks: > >If you want to test a resource, be it the end user or an infrastructure >interface, how do you know how to foo it (foo being some value of ping, >traceroute, look it up in SNMP/NetFlow, etc)? > >I submit that if you use dynamic assignment of any sort, you really have to >have DNS dynamic update, so you can use a known name to query the function >that's indexed by address. Otherwise, static addresses become rather >necessary if you want to check a resource. While I mostly agree, replace Dynamic DNS with "dynamic name resolution services" (or, perhaps, a stable endpoint address) and I agree even more :). Aside from static addresses, Dynamic DNS is one approach (currently the most common). PNRP, LLMNR are other possible solutions (depending on the scope we are talking about). WRT the "stable endpoint" piece, tunneling can work here. Mobile IPv6, for example, starts off with my machine always being reachable at the same address. Some tunnel providers also allocate stable addressing - i.e. wherever I am in IPv4-land I still have the same IPv6 address. > >This was especially a question when L2 was "in" and routing was out: how do >you ping a MAC address? I prefer Layer 11 - the money :) (8 = people, 9-politics, 10=religion, 11=money) > >Howard /TJ From trejrco at gmail.com Mon Aug 18 15:46:13 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 16:46:13 -0400 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> Message-ID: <00eb01c90173$744a8f40$5cdfadc0$@com> >-----Original Message----- >From: Dale W. Carder [mailto:dwcarder at wisc.edu] >Sent: Monday, August 18, 2008 4:24 PM >To: surfer at mauigateway.com >Cc: nanog at nanog.org >Subject: Re: SLAAC(autoconfig) vs DHCPv6 > > >Hey Scott, > >On Aug 18, 2008, at 2:33 PM, Scott Weeks wrote: >> From: "TJ" >> >> As a general rule, most clients are following the "If we gave them >> static >> IPv4 addresses we will give them static IPv6 addresses" >> (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 >> is a separate (albeit >> related) conversation ... >> ---------------------------------------------------- >> >> I'm still an IPv6 wussie and would like to learn more before moving >> forward, so would anyone care to share info on experiences with this >> decision? > >Here's some pro's and con's to both > >SLAAC: >- widely implemented in host v6 stacks that have shipped >- widely implemented on v6 routers >- really, really, really broken: it didn't support handing out > any DNS info until RFC 5006, thus SLAAC still requires human > intervention on a client to make "teh v6 interwebs" work. It > will probably be a painful wait until 5006 gets more widely > implemented on hosts (if ever, for some) & routers. Or rely on IPv4 to do the DNS part. I call this "cheating", but do not mean to include the negative connotations that come with that word :). >- probably "faster" than dhcpv6 w/ tuning timers. Could be > better for mobile thingys. >- supports RFC 3041 "security by obscurity" extensions. > >DHCPv6 >- doesn't ship w/ some OS's And some vendors have publicly stated that they would never support DHCPv6. While I may not fully believe them (never is a long time), that is atleast an indication not to expect it "soon". >- new (danger code), not all features implemented >- router support for dhcpv6 relay very limited >- advanced things like prefix delegation don't really seem to > have been ironed out. > >In case you weren't confused enough between the two, they are not mutually >exclusive. You can run both SLAAC and DHCPv6 at the same time on the same >L2. Indeed, Stateless DHCPv6 is exactly that. I should have mentioned that by now - sorry! > >Links for (2) dhcpv6 implementations: >http://klub.com.pl/dhcpv6/ >http://www.isc.org/index.pl?/sw/dhcp/dhcp4_0.php > >Cheers, >Dale /TJ From pauldotwall at gmail.com Mon Aug 18 15:46:29 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 18 Aug 2008 16:46:29 -0400 Subject: impossible circuit In-Reply-To: References: <20080812113649.GA4984@pwns.ms> Message-ID: <620fd17c0808181346v20b6a10fo466d8c46b471d164@mail.gmail.com> Jon, I think we can safely conclude from the information provided that you're looking at some sort of a misconfigured traffic mirroring or [un]lawful intercept. Sadly, as neither Sprint nor your loop provider will fess up, I don't think you're going to get much further on here. Probably best to order a new loop and cancel the existing one. Drive Slow, Paul - Original message - I just went ahead and "re-broke" the circuit ... On 8/17/08, Jon Lewis wrote: > On Tue, 12 Aug 2008, Jon Lewis wrote: > >>> What would happen if you pinged the Ocala router such that the TTL was 1 >>> when travelling over the DS3? From your traceroute it seems it travelled >>> two IP hops that did not send ICMP error messages, but it might just be >>> that the ICMP errors from the Ocala router are arriving first. >> >> Based on where the dupes are coming from, I assume pinging across the DS3 >> with TTL tuned to expire at the Ocala side would result in TTL exceeded >> messages from both Ocala and the Sprint router where the packets are >> injected >> into Sprint's network. It doesn't look as if IOS gives the option to set >> TTL >> on ping...so I'd try this from a Linux machine in our data center. > > I just went ahead and "re-broke" the circuit for a bit by turning it back > to hdlc to see if the issue is still there and to run some additional > tests. Someone is still cross connecting our Orlando->Ocala traffic over > to Sprint. > > I did your suggested ping with short TTL and the result was close to what > I expected. > > $ traceroute ocalflxa-br-1 > traceroute to ocalflxa-br-1.atlantic.net (209.208.6.229), 30 hops max, 38 > byte packets > 1 209.208.25.165 (209.208.25.165) 0.539 ms 0.426 ms 0.388 ms > 2 69.28.72.162 (69.28.72.162) 0.246 ms 0.351 ms 0.223 ms > 3 andc-br-3-f2-0 (209.208.9.138) 0.559 ms 0.435 ms 0.471 ms > 4 ocalflxa-br-1-s1-0 (209.208.112.98) 2.735 ms * 2.656 ms > > So, I need a TTL of 4 to get there from this machine. > > $ ping -t4 ocalflxa-br-1 > PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 > time=2.68 ms > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 > time=2.72 ms > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=2 ttl=252 > time=2.88 ms > > Decrease ttl by one, and I get the expected ttl exceeded from the Orlando > side of the circuit. > > $ ping -t 3 ocalflxa-br-1 > PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. > >From andc-br-3-f2-0.atlantic.net (209.208.9.138) icmp_seq=0 Time to live > exceeded > > Now, here's a mild surprise. You'll notice that in the above -t4 trace, I > didn't hear back from Sprint. > > $ ping -t 5 ocalflxa-br-1 > PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 > time=2.89 ms > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 > time=3.10 ms > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=2 ttl=252 > time=2.97 ms > hmm...still no ttl exceeded from Sprint? > > $ ping -t 6 ocalflxa-br-1 > PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 > time=2.95 ms > >From sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) icmp_seq=0 Time to > live exceeded > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 > time=2.78 ms > >From sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) icmp_seq=1 Time to > live exceeded > > $ ping -t 7 ocalflxa-br-1 > PING ocalflxa-br-1.atlantic.net (209.208.6.229) 56(84) bytes of data. > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=0 ttl=252 > time=2.88 ms > >From sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) icmp_seq=0 Time to > live exceeded > 64 bytes from ocalflxa-br-1.atlantic.net (209.208.6.229): icmp_seq=1 ttl=252 > time=2.84 ms > >From sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) icmp_seq=1 Time to > live exceeded > > Is it just coincidence that there are 2 private IP hops in some > traceroutes between us and Sprint? i.e. Look at this trace from cogent: > > Tracing the route to 209.208.33.1 > > 1 fa0-8.na01.b005944-0.dca01.atlas.cogentco.com (66.250.56.189) 0 msec 4 > msec 4 msec > 2 gi3-9.3507.core01.dca01.atlas.cogentco.com (66.28.67.225) 160 msec 4 > msec 8 msec > 3 te3-1.ccr02.dca01.atlas.cogentco.com (154.54.3.158) 0 msec 0 msec 4 > msec > 4 vl3493.mpd01.dca02.atlas.cogentco.com (154.54.7.230) 28 msec 4 msec > te4-1.mpd01.dca02.atlas.cogentco.com (154.54.2.182) 52 msec > 5 vl3494.mpd01.iad01.atlas.cogentco.com (154.54.5.42) 4 msec 4 msec > vl3497.mpd01.iad01.atlas.cogentco.com (154.54.5.66) 4 msec > 6 timewarner.iad01.atlas.cogentco.com (154.54.13.250) 4 msec > peer-01-ge-3-1-2-13.asbn.twtelecom.net (66.192.252.217) 4 msec 12 msec > 7 66-194-200-202.static.twtelecom.net (66.194.200.202) 28 msec 28 msec 32 > msec > 8 66-194-200-202.static.twtelecom.net (66.194.200.202) 32 msec 32 msec 28 > msec > 9 andc-br-3-f2-0.atlantic.net (209.208.9.138) 32 msec 32 msec 32 msec > 10 172.22.122.1 32 msec 32 msec 32 msec > 11 10.247.28.205 32 msec 32 msec 32 msec > 12 sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) 32 msec 32 msec 28 > msec > 13 sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) 28 msec 32 msec 32 > msec > 14 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 32 msec 32 msec 28 > msec > 15 vlan79.csw2.Washington1.Level3.net (4.68.17.126) 28 msec > vlan89.csw3.Washington1.Level3.net (4.68.17.190) 32 msec > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 40 msec > 16 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 28 msec > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 28 msec > ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 32 msec > 17 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 48 msec 48 msec 56 msec > 18 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 44 msec 48 msec > ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 52 msec > 19 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 56 msec 104 msec 56 msec > 20 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 52 msec 52 msec 56 msec > 21 unknown.Level3.net (63.209.98.66) 52 msec 52 msec 56 msec > 22 andc-br-3-f2-0.atlantic.net (209.208.9.138) 52 msec 52 msec 56 msec > 23 172.22.122.1 52 msec 56 msec 52 msec > 24 10.247.28.205 52 msec 52 msec 56 msec > 25 sl-crs2-dc-0-5-3-0.sprintlink.net (144.232.19.93) 52 msec 56 msec 52 > msec > 26 sl-st20-ash-9-0-0.sprintlink.net (144.232.18.228) 56 msec 56 msec 56 > msec > 27 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 52 msec 52 msec 52 > msec > 28 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 52 msec > vlan69.csw1.Washington1.Level3.net (4.68.17.62) 56 msec > vlan89.csw3.Washington1.Level3.net (4.68.17.190) 56 msec > 29 ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 64 msec > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 52 msec 56 msec > 30 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 76 msec 72 msec 72 msec > > I've seen the 172.22.122.1 & 10.247.28.205 hops before. They occasionally > show up in traces when the traffic is jumping over to Sprint. Sometimes > they don't show up though. i.e. Tracing from my house: > > traceroute to 209.208.33.1 (209.208.33.1), 30 hops max, 40 byte packets > 1 172.31.0.1 (172.31.0.1) 0.336 ms 0.272 ms 0.268 ms > 2 10.210.160.1 (10.210.160.1) 10.109 ms 11.719 ms 14.265 ms > 3 gig7-0-4-101.orldflaabv-rtr1.cfl.rr.com (24.95.232.100) 15.302 ms > 15.324 ms 16.687 ms > 4 198.228.95.24.cfl.res.rr.com (24.95.228.198) 16.688 ms 18.812 ms > 18.816 ms > 5 te-3-3.car1.Orlando1.Level3.net (4.79.116.145) 20.084 ms 19.946 ms > te-3-1.car1.Orlando1.Level3.net (4.79.116.137) 21.328 ms > 6 unknown.Level3.net (63.209.98.66) 19.900 ms 14.714 ms 14.689 ms > 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 104.058 ms 11.932 ms > 13.584 ms > 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 15.872 ms 15.886 ms > 17.238 ms > 9 * * * > 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 41.277 ms 41.964 ms > 41.955 ms > 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 43.360 ms 44.578 ms > 35.635 ms > 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 37.035 ms 37.062 > ms 33.185 ms > 13 vlan89.csw3.Washington1.Level3.net (4.68.17.190) 44.060 ms 44.057 ms > vlan99.csw4.Washington1.Level3.net (4.68.17.254) 39.603 ms > 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 38.123 ms > ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 39.546 ms > ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 38.115 ms > 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 46.284 ms 46.275 ms > 46.274 ms > 16 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 52.523 ms > ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 53.338 ms > ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 53.299 ms > 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 34.964 ms 39.582 ms > 38.088 ms > 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 36.701 ms 38.144 ms > 36.949 ms > 19 unknown.Level3.net (63.209.98.66) 36.902 ms 37.750 ms 37.717 ms > 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 37.729 ms 35.812 ms > 35.048 ms > 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 37.485 ms 37.601 ms > 36.495 ms > 22 * * * > 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 56.459 ms 56.449 ms > 57.709 ms > 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 57.694 ms 57.692 ms > 60.243 ms > 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 103.257 ms > 100.829 ms 82.571 ms > 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 70.401 ms > vlan89.csw3.Washington1.Level3.net (4.68.17.190) 69.262 ms > vlan99.csw4.Washington1.Level3.net (4.68.17.254) 82.700 ms > 27 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 74.132 ms > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 74.135 ms > ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 75.540 ms > 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 58.656 ms 60.838 ms > 54.346 ms > 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 59.323 ms > ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 59.336 ms > ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 63.323 ms > 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 127.652 ms 57.884 ms > 57.851 ms > > >From the traces I've seen, it seems if the first Sprint hop is sl-bb20-dc, > the private IP hops don't show up. If the first Sprint hop is sl-crs2-dc, > then the private IP hops are there. I wonder if anyone from Sprint can > shed some light on that? > > Unfortunately, the Sprint engineer I intitially made contact with who was > helpful and seemed curious about the issue seems to have vanished and > isn't returning my calls or emails. Anyone else from Sprintlink care to > play? > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -- Sent from Gmail for mobile | mobile.google.com From iljitsch at muada.com Mon Aug 18 16:01:22 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 18 Aug 2008 23:01:22 +0200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> Message-ID: <60CFE179-BEC0-4E3C-90E1-EC9ED1E07C60@muada.com> On 18 aug 2008, at 21:18, Justin M. Streiner wrote: > Just because IPv6 provides boatloads more space doesn't mean that I > like wasting addresses :) That kind of thinking can easily lead you in the wrong direction. For instance, hosting businesses that cater to small customers generally have a lot of problems with their IPv4 address provisioning: for a customer that only needs one or a few IPv4 addresses, it's not feasible to create a separate subnet, because that wastes a lot of addresses. But invariably, these customers on shared subnets grow, so over time the logical subnet gathers more and more IPv4 address blocks that are shared by a relatively large number of customers, and because of resistance to renumbering, it's impossible to fix this later on. With IPv6 on the other hand, you can easily give each customer their own prefix which they'll pretty much never grow out of, and not be forced to artificially keep lots of customers in the same VLAN. The extra 96 bits do make a difference. From tony at lava.net Mon Aug 18 16:08:41 2008 From: tony at lava.net (Antonio Querubin) Date: Mon, 18 Aug 2008 11:08:41 -1000 (HST) Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <00e201c90170$f574fea0$e05efbe0$@com> References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> <00e201c90170$f574fea0$e05efbe0$@com> Message-ID: On Mon, 18 Aug 2008, TJ wrote: > other potential headaches (reserved address to watch out for, requiring > another route to get to a client's network, etc). That is why the official > answer is to always use /64s, even on PtP links. This is one area where the Depends on who you consider 'official' :) Antonio Querubin whois: AQ7-ARIN From iljitsch at muada.com Mon Aug 18 16:11:16 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 18 Aug 2008 23:11:16 +0200 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> Message-ID: <75659347-C756-42F0-A993-C04D00837A64@muada.com> On 18 aug 2008, at 22:23, Dale W. Carder wrote: > - really, really, really broken: it didn't support handing out > any DNS info until RFC 5006, thus SLAAC still requires human > intervention on a client to make "teh v6 interwebs" work. While I agree that it is bad that the DNS configuration issue took so long to fix, I wouldn't consider this a flaw of stateless autoconfiguration, which works extremely well. There have been many times that I was at conferences where the IPv4 DHCP wouldn't work so it was impossible to go online, while stateless autoconfig rarely creates any problems. (Although there could be connectivity problems upstream, though.) > DHCPv6 > - doesn't ship w/ some OS's Forget about it on XP, but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?) but Mac is a problem for prospective DHCPv6 users because the network configuration mechanisms are fairly proprietary and DHCPv6 isn't likely to be supported any time soon. > - new (danger code), not all features implemented > - router support for dhcpv6 relay very limited > - advanced things like prefix delegation don't really seem to > have been ironed out. Actually the prefix delegation has worked just fine for me. This is the redeeming feature in DHCPv6. In my opinion, DHCPv6 was severely misdesigned. For instance, there are stateful and stateless variations, and the _client_ has to choose which to use. DHCPv6 also doesn't give you a subnet prefix length or a default gateway, so you still need router advertisements (that are also used for stateless autoconfig). The latter can be considered a feature, but I'm guessing the lack of a subnet prefix other than the assumption that the whole world uses /64 has been giving DHCPv6 server implementers a lot of headaches. > In case you weren't confused enough between the two, they are not > mutually exclusive. You can run both SLAAC and DHCPv6 at the same > time on the same L2. Of course there's no telling what exactly the clients are going to do in that case... Iljitsch From David_Hankins at isc.org Mon Aug 18 16:24:49 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Mon, 18 Aug 2008 14:24:49 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <20080818125250.9AC36D2A@resin13.mta.everyone.net> References: <20080818125250.9AC36D2A@resin13.mta.everyone.net> Message-ID: <20080818212448.GD3250@isc.org> On Mon, Aug 18, 2008 at 12:52:50PM -0700, Scott Weeks wrote: > Seeing Howard's quick response saying "To try to stay operational > about this..." makes me realize I may have inadvertently invited a > religious flame fest. I guess that rules me out. :( > Please! Operational content and hands-on experiences only to the > best of your ability. I want to learn from this, not delete the > whole thread. The short and simple "Where we are Today" is that the only DHCPv6 clients you are likely to encounter in your networks are either DOCSIS modems or Windows Vista. So if you are going to deploy IPv6 to customers, you are generally going to use SLAAC today, and all the headaches that entails. Although there's now an option for domain name servers and search paths in router advertisements, you'll have an even worse time finding client support. So the current state of the art is to run dual stack so that DHCPv4 can reliably provide IPv4 nameservers, which you can use to find AAAA records, enabling SLAAC'd IPv6 access. For extra credit you can supply IPv6 nameserver information statelessly, but then you're only complicating things even more. One of the little talked about issues is the potential support cost when a customer wants to resolve some issue. "My web isn't working." "Are you using v4 or v6?" "Netscape." And of course it's a non-starter for anyone who needs to assign and approve the client's configuration, let us imagine because of differing product levels, rather than letting them pick whatever they feel like. I think the above can reasonably be said to be an accurate, if brief, depiction of current IPv6 operations. If you wanted to gaze into the future, I think that isn't precisely possible without welcoming the related philosophical (not religious) debates. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From charles at thewybles.com Mon Aug 18 16:27:56 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 18 Aug 2008 14:27:56 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <75659347-C756-42F0-A993-C04D00837A64@muada.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> Message-ID: <48A9E95C.6060806@thewybles.com> Iljitsch van Beijnum wrote: > On 18 aug 2008, at 22:23, Dale W. Carder wrote: > >> DHCPv6 >> - doesn't ship w/ some OS's > > Forget about it on XP, Hmmm. MS says otherwise: http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx > but it's in Vista. You can add it to BSD/Linux without too much > trouble (are there good, bugfree implementations for those yet?) Bugfree? Nothing is bugfree :) > but Mac is a problem for prospective DHCPv6 users because the network > configuration mechanisms are fairly proprietary and DHCPv6 isn't > likely to be supported any time soon. Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac now I should try in my lab later). What auto configuration mechanisms are you referring to? Bonjour? Isn't there an RFC or two for Zeroconf? -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From streiner at cluebyfour.org Mon Aug 18 16:28:36 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 18 Aug 2008 17:28:36 -0400 (EDT) Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <60CFE179-BEC0-4E3C-90E1-EC9ED1E07C60@muada.com> References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> <60CFE179-BEC0-4E3C-90E1-EC9ED1E07C60@muada.com> Message-ID: On Mon, 18 Aug 2008, Iljitsch van Beijnum wrote: > On 18 aug 2008, at 21:18, Justin M. Streiner wrote: > >> Just because IPv6 provides boatloads more space doesn't mean that I like >> wasting addresses :) > > That kind of thinking can easily lead you in the wrong direction. > > For instance, hosting businesses that cater to small customers generally have > a lot of problems with their IPv4 address provisioning: for a customer that > only needs one or a few IPv4 addresses, it's not feasible to create a > separate subnet, because that wastes a lot of addresses. But invariably, > these customers on shared subnets grow, so over time the logical subnet > gathers more and more IPv4 address blocks that are shared by a relatively > large number of customers, and because of resistance to renumbering, it's > impossible to fix this later on. I don't have a problem with assigning customers a /64 of v6 space. My earlier comments were focused on network infrastructure comprised of mainly point-to-point links with statically assigned interface addresses. In that case, provisioning point-to-point links much larger than a /126, or at the maximum a /120 seems rather wasteful and doesn't make much sense. jms From iljitsch at muada.com Mon Aug 18 16:35:26 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 18 Aug 2008 23:35:26 +0200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> <60CFE179-BEC0-4E3C-90E1-EC9ED1E07C60@muada.com> Message-ID: <23C9EE9C-62BB-4CCC-BDB3-63516F820FB7@muada.com> On 18 aug 2008, at 23:28, Justin M. Streiner wrote: > I don't have a problem with assigning customers a /64 of v6 space. My > earlier comments were focused on network infrastructure comprised of > mainly > point-to-point links with statically assigned interface addresses. > In that case, provisioning point-to-point links much larger than a / > 126, or at the maximum a /120 seems rather wasteful and doesn't make > much sense. Well, the choice is really between /64 or not-/64. If the latter, you can number all your point-to-point links from a single /64 whether you give them a /96 or a /127. I recommend /112 because that way the subnet boundary falls on a colon. /120 or longer has some potential issues that are too boring to explain for the 50th time. But since IPv6 routing protocols work on link locals, you really don't need _any_ global addresses on your point-to-point links... From trejrco at gmail.com Mon Aug 18 16:41:53 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 17:41:53 -0400 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <48A9E95C.6060806@thewybles.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> <48A9E95C.6060806@thewybles.com> Message-ID: <011001c9017b$3b8d4910$b2a7db30$@com> >-----Original Message----- >From: Charles Wyble [mailto:charles at thewybles.com] >Sent: Monday, August 18, 2008 5:28 PM >To: nanog at merit.edu >Subject: Re: SLAAC(autoconfig) vs DHCPv6 > >Iljitsch van Beijnum wrote: >> On 18 aug 2008, at 22:23, Dale W. Carder wrote: >> >>> DHCPv6 >>> - doesn't ship w/ some OS's >> >> Forget about it on XP, > >Hmmm. MS says otherwise: >http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx Did you see somewhere on that site, that WinXP does DHCPv6? I don't. And it would be wrong, to boot. (Not just IPv6 support - that is one simple command ...) >> but it's in Vista. You can add it to BSD/Linux without too much >> trouble (are there good, bugfree implementations for those yet?) > >Bugfree? Nothing is bugfree :) >> but Mac is a problem for prospective DHCPv6 users because the network >> configuration mechanisms are fairly proprietary and DHCPv6 isn't >> likely to be supported any time soon. > >Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac >now I should try in my lab later). What auto configuration mechanisms are >you referring to? Bonjour? Isn't there an RFC or two for Zeroconf? No, I believe he is referring to the actual network configuration. Not the (almost) automatic/automated service/device discovery ... > >-- >Charles Wyble (818) 280 - 7059 /TJ From trejrco at gmail.com Mon Aug 18 16:43:20 2008 From: trejrco at gmail.com (TJ) Date: Mon, 18 Aug 2008 17:43:20 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> <60CFE179-BEC0-4E3C-90E1-EC9ED1E07C60@muada.com> Message-ID: <011101c9017b$6f1322a0$4d3967e0$@com> >-----Original Message----- >From: Justin M. Streiner [mailto:streiner at cluebyfour.org] >Sent: Monday, August 18, 2008 5:29 PM >To: Iljitsch van Beijnum >Cc: nanog at nanog.org >Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum > >On Mon, 18 Aug 2008, Iljitsch van Beijnum wrote: > >> On 18 aug 2008, at 21:18, Justin M. Streiner wrote: >> >>> Just because IPv6 provides boatloads more space doesn't mean that I >>> like wasting addresses :) >> >> That kind of thinking can easily lead you in the wrong direction. >> >> For instance, hosting businesses that cater to small customers >> generally have a lot of problems with their IPv4 address provisioning: >> for a customer that only needs one or a few IPv4 addresses, it's not >> feasible to create a separate subnet, because that wastes a lot of >> addresses. But invariably, these customers on shared subnets grow, so >> over time the logical subnet gathers more and more IPv4 address blocks >> that are shared by a relatively large number of customers, and because >> of resistance to renumbering, it's impossible to fix this later on. > >I don't have a problem with assigning customers a /64 of v6 space. My >earlier comments were focused on network infrastructure comprised of mainly >point-to-point links with statically assigned interface addresses. In that >case, provisioning point-to-point links much larger than a /126, or at the >maximum a /120 seems rather wasteful and doesn't make much sense. Actually, in most cases - you would assign customers more than a /64. *Hopefully* a /56 as the smallest ... ~/48 for enterprises ... > >jms /TJ From Sean.Siler at microsoft.com Mon Aug 18 16:52:16 2008 From: Sean.Siler at microsoft.com (Sean Siler) Date: Mon, 18 Aug 2008 14:52:16 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <011001c9017b$3b8d4910$b2a7db30$@com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> <48A9E95C.6060806@thewybles.com> <011001c9017b$3b8d4910$b2a7db30$@com> Message-ID: Nope. XP does not support DHCPv6 - only Vista/Windows Server 2008 (and later) can do that. Sean -----Original Message----- From: TJ [mailto:trejrco at gmail.com] Sent: Monday, August 18, 2008 2:42 PM To: nanog at merit.edu Subject: RE: SLAAC(autoconfig) vs DHCPv6 >-----Original Message----- >From: Charles Wyble [mailto:charles at thewybles.com] >Sent: Monday, August 18, 2008 5:28 PM >To: nanog at merit.edu >Subject: Re: SLAAC(autoconfig) vs DHCPv6 > >Iljitsch van Beijnum wrote: >> On 18 aug 2008, at 22:23, Dale W. Carder wrote: >> >>> DHCPv6 >>> - doesn't ship w/ some OS's >> >> Forget about it on XP, > >Hmmm. MS says otherwise: >http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx Did you see somewhere on that site, that WinXP does DHCPv6? I don't. And it would be wrong, to boot. (Not just IPv6 support - that is one simple command ...) >> but it's in Vista. You can add it to BSD/Linux without too much >> trouble (are there good, bugfree implementations for those yet?) > >Bugfree? Nothing is bugfree :) >> but Mac is a problem for prospective DHCPv6 users because the network >> configuration mechanisms are fairly proprietary and DHCPv6 isn't >> likely to be supported any time soon. > >Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac >now I should try in my lab later). What auto configuration mechanisms are >you referring to? Bonjour? Isn't there an RFC or two for Zeroconf? No, I believe he is referring to the actual network configuration. Not the (almost) automatic/automated service/device discovery ... > >-- >Charles Wyble (818) 280 - 7059 /TJ From oberman at es.net Mon Aug 18 16:54:30 2008 From: oberman at es.net (Kevin Oberman) Date: Mon, 18 Aug 2008 14:54:30 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: Your message of "Mon, 18 Aug 2008 14:27:56 PDT." <48A9E95C.6060806@thewybles.com> Message-ID: <20080818215430.624744501D@ptavv.es.net> > Date: Mon, 18 Aug 2008 14:27:56 -0700 > From: Charles Wyble > > Iljitsch van Beijnum wrote: > > On 18 aug 2008, at 22:23, Dale W. Carder wrote: > > > >> DHCPv6 > >> - doesn't ship w/ some OS's > > > > Forget about it on XP, > > Hmmm. MS says otherwise: > http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx No. MS says that support for DHCPv6 is new in Vista and Server 2008 which rather strongly implies that it is not present in XP. (And it isn't.) -- 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 charles at thewybles.com Mon Aug 18 16:55:17 2008 From: charles at thewybles.com (Charles Wyble) Date: Mon, 18 Aug 2008 14:55:17 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> <48A9E95C.6060806@thewybles.com> <011001c9017b$3b8d4910$b2a7db30$@com> Message-ID: <48A9EFC5.9040900@thewybles.com> Sean Siler wrote: > Nope. XP does not support DHCPv6 - only Vista/Windows Server 2008 (and later) can do that. > > Sean http://internecine.eu/systems/windows_xp-ipv6.html and http://internecine.eu/software/dibbler_dhcpv6.html discuss how to deploy dhcpv6 on xp. It's 3rd party but doable. From tony at lava.net Mon Aug 18 17:01:50 2008 From: tony at lava.net (Antonio Querubin) Date: Mon, 18 Aug 2008 12:01:50 -1000 (HST) Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <48A9E95C.6060806@thewybles.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> <48A9E95C.6060806@thewybles.com> Message-ID: On Mon, 18 Aug 2008, Charles Wyble wrote: >> Forget about it on XP, > > Hmmm. MS says otherwise: > http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx None of the XP systems here (even with all the latest service packs installed) seem to do DHCPv6. >> but it's in Vista. You can add it to BSD/Linux without too much trouble >> (are there good, bugfree implementations for those yet?) > Bugfree? Nothing is bugfree :) Indeed. The Vista client has some real problems with retaining DNS info. Antonio Querubin whois: AQ7-ARIN From Sean.Siler at microsoft.com Mon Aug 18 17:02:30 2008 From: Sean.Siler at microsoft.com (Sean Siler) Date: Mon, 18 Aug 2008 15:02:30 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <48A9EFC5.9040900@thewybles.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> <48A9E95C.6060806@thewybles.com> <011001c9017b$3b8d4910$b2a7db30$@com> <48A9EFC5.9040900@thewybles.com> Message-ID: Yep - absolutely. I was referring to built-in support from the stack. Dibbler is the primary third party provider we have seen for DHCPv6 support on downlevel clients. Sean -----Original Message----- From: Charles Wyble [mailto:charles at thewybles.com] Sent: Monday, August 18, 2008 2:55 PM To: nanog at merit.edu Subject: Re: SLAAC(autoconfig) vs DHCPv6 Sean Siler wrote: > Nope. XP does not support DHCPv6 - only Vista/Windows Server 2008 (and later) can do that. > > Sean http://internecine.eu/systems/windows_xp-ipv6.html and http://internecine.eu/software/dibbler_dhcpv6.html discuss how to deploy dhcpv6 on xp. It's 3rd party but doable. From tony at lava.net Mon Aug 18 17:04:08 2008 From: tony at lava.net (Antonio Querubin) Date: Mon, 18 Aug 2008 12:04:08 -1000 (HST) Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <48A9EFC5.9040900@thewybles.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> <48A9E95C.6060806@thewybles.com> <011001c9017b$3b8d4910$b2a7db30$@com> <48A9EFC5.9040900@thewybles.com> Message-ID: On Mon, 18 Aug 2008, Charles Wyble wrote: > http://internecine.eu/systems/windows_xp-ipv6.html and > http://internecine.eu/software/dibbler_dhcpv6.html discuss how to deploy > dhcpv6 on xp. It's 3rd party but doable. Hmmm I'm getting "You don't have permission to access /systems/windows_xp-ipv6.html on this server." Antonio Querubin whois: AQ7-ARIN From justin at justinshore.com Mon Aug 18 17:15:52 2008 From: justin at justinshore.com (Justin Shore) Date: Mon, 18 Aug 2008 17:15:52 -0500 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <48A9D2E6.3010507@thewybles.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <007b01c9016a$8cd72180$020fa8c0@HDESK1> <48A9D2E6.3010507@thewybles.com> Message-ID: <48A9F498.4030508@justinshore.com> Charles Wyble wrote: >> This was especially a question when L2 was "in" and routing was out: >> how do >> you ping a MAC address? >> > > l2ping works on bluetooth devices on Linux. Might work for other stuff > as well. Not sure what Cisco offers in this regard. The ideal solution would be OAM. Of course not everything supports that and it's not on by default either. Of all the things to turn off by default, this is one thing that I'd like to see on. Justin From David_Hankins at isc.org Mon Aug 18 17:17:08 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Mon, 18 Aug 2008 15:17:08 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <75659347-C756-42F0-A993-C04D00837A64@muada.com> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <3CAD8609-BB92-4169-9DD0-3D31E82B0C07@wisc.edu> <75659347-C756-42F0-A993-C04D00837A64@muada.com> Message-ID: <20080818221708.GE3250@isc.org> On Mon, Aug 18, 2008 at 11:11:16PM +0200, Iljitsch van Beijnum wrote: > Forget about it on XP, but it's in Vista. You can add it to BSD/Linux > without too much trouble (are there good, bugfree implementations for those > yet?) If anyone is aware of any bugs in ISC dhclient -6, please submit them to dhcp-bugs at isc.org. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jra at baylink.com Mon Aug 18 18:47:07 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 18 Aug 2008 19:47:07 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48a9bad2.207.f88.13668@jdfogg.com> <48A9BD15.2030407@ai.net> Message-ID: <20080818234707.GB13867@cgi.jachomes.com> On Mon, Aug 18, 2008 at 08:57:27PM +0200, Mikael Abrahamsson wrote: > >operational content: Is anyone significantly redesigning the way they > >route/etc to take advantage of any hooks that IPv6 provides-for (even if > >its a proprietary implementation)? As far as I can tell, most people are > >just implementing it as IPv4 with a lot of bits (i.e. /126s for link > >interfaces, etc). > > Yes, there are those of us who want to save number of routes and > "spending" IPv6 addresses to save on TCAM and convergence time. > > Using /112 for link networks to make the last octet ::1 and ::2 for links > also makes sense from the human perspective. Well, if y'all want a place to put this hints, I got a whole IPv6y section over here: http://bestpractices.wikia.com 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 vixie at isc.org Mon Aug 18 20:15:10 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 19 Aug 2008 01:15:10 +0000 Subject: labovitz: "The End is Near, but is IPv6?" (seen on slashdot today) Message-ID: <12378.1219108510@nsa.vix.com> http://asert.arbornetworks.com/2008/08/the-end-is-near-but-is-ipv6/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mike.lyon at gmail.com Mon Aug 18 20:32:48 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 18 Aug 2008 18:32:48 -0700 Subject: Smallest netblock that providers will accept? Message-ID: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> Hello All, I am curious as to the routing polices of the bigger providers such as ATT, L3, Internap, Qwest, Etc Etc... Is there a standard size netblock that these providers will accept? For instance, if customer "A" gets a /22 from ARIN and his upstream provider is ATT and L3, what would the smallest block be that those providers would accept from customer "A"? Would they accept something as small as a /24? Thanks, Mike From christian at broknrobot.com Mon Aug 18 21:01:22 2008 From: christian at broknrobot.com (Christian Koch) Date: Mon, 18 Aug 2008 22:01:22 -0400 Subject: Smallest netblock that providers will accept? In-Reply-To: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> References: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> Message-ID: a lot of providers have their bgp/routing policy published somewhere online/in their community guide for instance, you can find L3's policy in their irr objects ( whois -h whois.radb.net as3356) there are also plenty of community guides available here - http://www.onesc.net/communities/ Christian On Mon, Aug 18, 2008 at 9:32 PM, Mike Lyon wrote: > Hello All, > > I am curious as to the routing polices of the bigger providers such as > ATT, L3, Internap, Qwest, Etc Etc... Is there a standard size > netblock that these providers will accept? For instance, if customer > "A" gets a /22 from ARIN and his upstream provider is ATT and L3, what > would the smallest block be that those providers would accept from > customer "A"? Would they accept something as small as a /24? > > Thanks, > Mike > > From john at internetassociatesllc.com Mon Aug 18 21:17:33 2008 From: john at internetassociatesllc.com (John Lee) Date: Mon, 18 Aug 2008 21:17:33 -0500 Subject: SLAAC(autoconfig) vs DHCPv6 vs IP Address Lifecycle Management Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159ADB@MEMEXG1.HOST.local> Scott, There are solutions that support both static, quasi-static, also driving DHCPv6 servers and Dynamic DNS updates. There are networks that have deployed IPal to automate and consolidate their IPv4 and IPv6 block allocations and interface assignments. Router Prefix delegation, SLAAC and DHCPv6 were implemented to have a more automated method of IPv6 address assignments because of the large potential number of IPv6 addresses to be assigned in a next generation network. IPal does address block assignments for Prefix delegation, SLAAC and DHCPv6 support. It does IPv6 interface assignments of /64 EUI-64, /64 random, /126, /127 and /128 and generate the Dynamic DNS updates for those assignments. E-mail me off list if you want any additional information. John (ISDN) Lee ________________________________________ From: Howard C. Berkowitz [hcb at netcases.net] Sent: Monday, August 18, 2008 3:42 PM To: nanog at nanog.org Subject: RE: SLAAC(autoconfig) vs DHCPv6 To try to stay operational about this, I have a reality testing question I've used in IPv4 and, for that matter, bridged networks: If you want to test a resource, be it the end user or an infrastructure interface, how do you know how to foo it (foo being some value of ping, traceroute, look it up in SNMP/NetFlow, etc)? I submit that if you use dynamic assignment of any sort, you really have to have DNS dynamic update, so you can use a known name to query the function that's indexed by address. Otherwise, static addresses become rather necessary if you want to check a resource. This was especially a question when L2 was "in" and routing was out: how do you ping a MAC address? Howard -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Monday, August 18, 2008 3:34 PM To: nanog at nanog.org Subject: SLAAC(autoconfig) vs DHCPv6 ---------- trejrco at gmail.com wrote: ------------ From: "TJ" As a general rule, most clients are following the "If we gave them static IPv4 addresses we will give them static IPv6 addresses" (infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit related) conversation ... ---------------------------------------------------- I'm still an IPv6 wussie and would like to learn more before moving forward, so would anyone care to share info on experiences with this decision? scott From blackham at gmail.com Mon Aug 18 22:05:15 2008 From: blackham at gmail.com (Kevin Blackham) Date: Mon, 18 Aug 2008 21:05:15 -0600 Subject: Smallest netblock that providers will accept? In-Reply-To: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> References: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> Message-ID: Your assumption is generally true with most any provider. They may even accept something smaller, but it won't make it very far if less than /24. It's also a good idea to announce a covering prefix in case some peer network filters on IRR minimums. On 8/18/08, Mike Lyon wrote: > Hello All, > > I am curious as to the routing polices of the bigger providers such as > ATT, L3, Internap, Qwest, Etc Etc... Is there a standard size > netblock that these providers will accept? For instance, if customer > "A" gets a /22 from ARIN and his upstream provider is ATT and L3, what > would the smallest block be that those providers would accept from > customer "A"? Would they accept something as small as a /24? > > Thanks, > Mike > > -- Sent from Gmail for mobile | mobile.google.com From joe at sumless.net Mon Aug 18 22:50:08 2008 From: joe at sumless.net (Joe Blanchard) Date: Mon, 18 Aug 2008 23:50:08 -0400 Subject: OT:Please excuse the noise In-Reply-To: <20080818170922.GB10900@cgi.jachomes.com> Message-ID: <007f01c901ae$adbe7fd0$1401a8c0@E520> I'm dealing with Hughsnet and have observed the following issue/ SOA is me for testing 72.169.156.122 Upstream router seems to be a public IP Number: 15942 Date: 18Aug2008 Time: 23:03:21 Product: FireWall-1 Interface: eth0 Origin: rockgate (192.168.1.1) Type: Log Action: Accept Protocol: udp Service: 2016 Source: upstream_router (72.169.156.121) Destination: Firewall_external (72.169.156.122) Rule: 10 Source Port: domain-udp (53) Problem is that target port is not 53, in otherwords asking for a DNS response on an odd port while sourcing port 53. Is this normal, am I missing something that a bigger ISP knows? This would be Hughesnet. so I should be concerned? I have a ticket opened with them, #15048812 but am getting the run around with them. I understand that the normal recourse is to "Reboot the modem" but in this case I think it's a bit more than that. Can anyone point me in the right direction? Thanks in advance, Again sorry for the noise Joe Blanchard 906-384=6525 From oberman at es.net Mon Aug 18 23:34:08 2008 From: oberman at es.net (Kevin Oberman) Date: Mon, 18 Aug 2008 21:34:08 -0700 Subject: OT:Please excuse the noise In-Reply-To: Your message of "Mon, 18 Aug 2008 23:50:08 EDT." <007f01c901ae$adbe7fd0$1401a8c0@E520> Message-ID: <20080819043408.DF9A24500F@ptavv.es.net> > From: "Joe Blanchard" > Date: Mon, 18 Aug 2008 23:50:08 -0400 > > > I'm dealing with Hughsnet and have observed the following issue/ > > SOA is me for testing 72.169.156.122 > > Upstream router seems to be a public IP > Number: 15942 > Date: 18Aug2008 > Time: 23:03:21 > Product: FireWall-1 > Interface: eth0 > Origin: rockgate (192.168.1.1) > Type: Log > Action: Accept > Protocol: udp > Service: 2016 > Source: upstream_router (72.169.156.121) > Destination: Firewall_external (72.169.156.122) > Rule: 10 > Source Port: domain-udp (53) > > > Problem is that target port is not 53, in otherwords asking for a DNS > response on an odd port while sourcing port 53. > Is this normal, am I missing something that a bigger ISP knows? This would > be Hughesnet. so I should be concerned? I have a ticket opened with them, > #15048812 but am getting the run around with them. > I understand that the normal recourse is to "Reboot the modem" but in this > case I think it's a bit more than that. > Can anyone point me in the right direction? Thanks in advance, Are they asking for a DNS or is this a reply? Replies are from 53 to an ephemeral destination. If your firewall is set up correctly and not losing state too quickly for DNS responses, this may be backscatter. I see a bit of this from time to time and dark space monitoring systems see a lot of it. With the cache poisoning attacks, I'd expect to see more t it. -- 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 nanog at daork.net Mon Aug 18 23:56:33 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 19 Aug 2008 16:56:33 +1200 Subject: uTorrent, IPv6 Message-ID: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Sit up and pay attention, even if you don't now run IPv6, or even if you don't ever intend to run IPv6. Your off-net bandwidth is going to increase, unless you put some relays in. As a friend of mine just said to me: "Welcome to your v6-enabled transit network, whether you like it or not ;-)". uTorrent 1.8 is out, as of Aug 9. uTorrent actively enables IPv6 on XP SP2 and Vista machines in the install process (by default, it can be turned off). IPv6 is turned on, on lots of PCs. uTorrent does DHT, so that uTorrent users will talk to eachother to exchange peers - IPv6 does not require tracker support. uTorrent (as far as I understand) knows how to set IPV6_PROTECTION_LEVEL appropriately on sockets, so that Teredo is actually used. What does this mean? It means that many uTorrent end users will have Teredo addresses, and many will have 6to4 addresses. As we roll out IPv6 globally, more and more uTorrent users will have non-tunnelled IPv6 addresses. uTorrent users move **LOTS** of data. This means relay load. There are very few 6to4 relays around the world. There are fewer Teredo relays. If you run a network today and do not have 6to4 and Teredo relays, traffic between a 6to4 end user and a Teredo end user will go off-net. That costs you money. So, if you run a network today, deploy 6to4 and Teredo relays, regardless of whether you have customer facing IPv6 or not. If you serve IPv6 content, you are already running Teredo and 6to4 relays, so that Windows Vista users get near to IPv4-speed access to your IPv6 content, right? Right... Azureus does IPv6 now, but does not turn on IPv6, and does not set the IPV6_PROTECTION_LEVEL (as far as I understand), so Teredo is not used. Windows uses 6to4 if you have a non-RFC1918 address, and it uses Teredo if you do not (typically, this means you are behind NAT). With the huge amount of end users behind NAT, this means that uTorrent will have a much wider effect than Azureus has had. Running a relay *does not* mean that people outside your network can use it. - Who uses your 6to4 relay is controlled by how far you advertise the well known IPv4 and IPv6 prefixes. - Your Teredo relay is used only by Teredo clients trying to get to your non-Teredo connected users (ie your 6to4 or natively connected users). 6to4 relays can be Cisco boxes, Juniper NetScreen, FreeBSD, Linux, etc. OpenBSD does not have 6to4 support. Teredo relays can be Windows boxes, or Linux/FreeBSD/etc. boxes running `Miredo'. I have pre-built FreeBSD images that run both 6to4 and Teredo relays, and can talk BGP to your network. They are about 30MB, so will run on a compact flash card, and will happily run on anything from a 133Mhz 468 (ie. Soekris net4501) through to whatever top of the line server you have. They can also optionally do this "Tui" thing, which uses 6to4 and BGP to build direct IPv6 over IPv4 tunnels to everyone else with one of these boxes, without you having to configure each tunnel manually - I have some central route-servers. Optional, experimental, YMMV, etc. Thankfully, both Teredo and 6to4 use anycast for relay discovery, so if you have load problems you can deploy more of these for the cost of a server. As per usual, I'm giving it away free, see the following URL, or contact me off list: http://www.braintrust.co.nz/tui/ If you don't care about the "Tui" stuff, ignore those parts of the document, the rest will work just fine. ps. I'm looking at packet dumps of things right now, captured from torrent clients from the last wee while. I'll be rambling about this and pointing at pretty graphs in about a week at APNIC26. -- Nathan Ward From tkapela at gmail.com Tue Aug 19 00:26:21 2008 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 19 Aug 2008 00:26:21 -0500 Subject: Smallest netblock that providers will accept? In-Reply-To: References: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> Message-ID: <2e9d8ae50808182226j1ad16eeape9b0f11fbd0d10a3@mail.gmail.com> On Mon, Aug 18, 2008 at 10:05 PM, Kevin Blackham wrote: > Your assumption is generally true with most any provider. They may > even accept something smaller, but it won't make it very far if less > than /24. It's also a good idea to announce a covering prefix in case > some peer network filters on IRR minimums. The part that Kevin spares you from reading is the "please don't" part. If your goal is to provide HA or DR-like aspects to some $single_application end-site and all you can justify is a one-time allocation of a /24, consider other options. There are already enough /24's in the DFZ both from end-site multihomers and wreckless deaggregation (and those who refuse to build a backbone and/or insist that POP-level convergence towards their network is everyone elses problem, not theirs). Instead of going down this road, I would suggest that you: -call up cisco and purchase a GSS (global dns lb with application availability probes, etc) or -attach your site to a pair of willing upstreams who already have a larger prefix aggregate set aside (say a /18 or something) for end-site multihoming, in which it is expected that the prefix will be originated from disparate AS's (neither of which is the actual end-site). -Tk From swmike at swm.pp.se Tue Aug 19 01:28:39 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 19 Aug 2008 08:28:39 +0200 (CEST) Subject: uTorrent, IPv6 In-Reply-To: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Message-ID: On Tue, 19 Aug 2008, Nathan Ward wrote: > uTorrent actively enables IPv6 on XP SP2 and Vista machines in the install > process (by default, it can be turned off). IPv6 is turned on, on lots of > PCs. We looked into this, and IPv6 is not mentioned in the install process, and it's not selected by default as far as we can see. There is a button in Preferences->general that says "install IPv6/Teredo", so yes, it supports it but it's not on by default, at least not here. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at daork.net Tue Aug 19 01:34:00 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 19 Aug 2008 18:34:00 +1200 Subject: uTorrent, IPv6 In-Reply-To: References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Message-ID: On 19/08/2008, at 6:28 PM, Mikael Abrahamsson wrote: > On Tue, 19 Aug 2008, Nathan Ward wrote: > >> uTorrent actively enables IPv6 on XP SP2 and Vista machines in the >> install process (by default, it can be turned off). IPv6 is turned >> on, on lots of PCs. > > We looked into this, and IPv6 is not mentioned in the install > process, and it's not selected by default as far as we can see. > There is a button in Preferences->general that says "install IPv6/ > Teredo", so yes, it supports it but it's not on by default, at least > not here. Oh? I looked in to this in a beta, and it was on by default. I'll have another look. -- Nathan Ward From nanog at daork.net Tue Aug 19 01:42:12 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 19 Aug 2008 18:42:12 +1200 Subject: uTorrent, IPv6 In-Reply-To: References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Message-ID: On 19/08/2008, at 6:34 PM, Nathan Ward wrote: > On 19/08/2008, at 6:28 PM, Mikael Abrahamsson wrote: > >> On Tue, 19 Aug 2008, Nathan Ward wrote: >> >>> uTorrent actively enables IPv6 on XP SP2 and Vista machines in the >>> install process (by default, it can be turned off). IPv6 is turned >>> on, on lots of PCs. >> >> We looked into this, and IPv6 is not mentioned in the install >> process, and it's not selected by default as far as we can see. >> There is a button in Preferences->general that says "install IPv6/ >> Teredo", so yes, it supports it but it's not on by default, at >> least not here. > > Oh? I looked in to this in a beta, and it was on by default. > I'll have another look. Yep, you're right, as I say, that's changed from a previous beta I think. Anyway, it'll still use Teredo/6to4/native IPv6 if it's already enabled - Vista has these enabled by default. My guess would be that a large percentage of uTorrent users are Vista users. -- Nathan Ward From michael.dillon at bt.com Tue Aug 19 02:10:43 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 19 Aug 2008 08:10:43 +0100 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: Message-ID: > I don't have a problem with assigning customers a /64 of v6 > space. Why so little? Normally customers get a /48 except for residential customers who can be given a /56 if you want to keep track of different block sizes. If ARIN will give you a /48 for every customer, then why be miserly with addresses? --Michael Dillon From michael.dillon at bt.com Tue Aug 19 02:15:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 19 Aug 2008 08:15:42 +0100 Subject: uTorrent, IPv6 In-Reply-To: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Message-ID: > So, if you run a network today, deploy 6to4 and Teredo > relays, regardless of whether you have customer facing IPv6 or not. > If you serve IPv6 content, you are already running Teredo and > 6to4 relays, so that Windows Vista users get near to > IPv4-speed access to your IPv6 content, right? Right... You can find info on how to set up relays at ARIN's IPv6 wiki --Michael Dillon From Jon.Kibler at aset.com Tue Aug 19 04:23:48 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Tue, 19 Aug 2008 05:23:48 -0400 Subject: Open Source CA / PKI Message-ID: <48AA9124.7010608@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I am looking at deploying an open source CA/PKI for a client. It would be only for internal users and systems. It would have to manage a few hundred certificates against the organization's self-signed root cert. It would be installed on a CentOS 5.x platform. I have looked at OpenCA and Dogtag. Any other packages I should look at? Does anyone have any opinions as to the pros and cons of either of these packages or thoughts/comments/experience with other similar packages? I would especially be interested in your experience with building / installing the package and your opinion of the documentation available. TIA for your help! 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 iEYEARECAAYFAkiqkSQACgkQUVxQRc85QlPlGACgoAFitZXNLnEJfxKXgah00Vi8 dl4AniBPAJ3zy6krTKkFY3JQRdHAU6b9 =PGoy -----END PGP SIGNATURE----- From rs at seastrom.com Tue Aug 19 06:32:20 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 19 Aug 2008 07:32:20 -0400 Subject: RouterOS performance? In-Reply-To: <48A8BF5F.70402@bogus.com> (Joel Jaeggli's message of "Sun, 17 Aug 2008 17:16:31 -0700") References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> Message-ID: <86y72tjl4r.fsf@seastrom.com> Joel Jaeggli writes: > I actually use freebsd as a router on soekris, but I do need a general > purpose os on the system as well. Speaking of Soekris (and the PCEngines ALIX by extension, of which I have several): Does anyone know of a comparable small SBC that doesn't have crummy NICs? Not a big fan of those VT6105M chips. Extra points for the ability to do baby jumbo frames. Also, from time to time I have to reflash these to repurpose them (NanoBSD vs. pfSense vs. AskoziaPBX). It's a complete pain to disassemble their enclosures so I can get at the CF cards. I've often thought that if someone had whipped up a memory-resident image of something (anything, linux/bsd/whatever) that I could pxeboot, then I could just dd the new image in over the net. Haven't gotten around to doing that yet. Has anyone else? -r From nanog at daork.net Tue Aug 19 06:54:29 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 19 Aug 2008 23:54:29 +1200 Subject: RouterOS performance? In-Reply-To: <86y72tjl4r.fsf@seastrom.com> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> <86y72tjl4r.fsf@seastrom.com> Message-ID: <722AAB18-6D54-466B-A4F3-730B95B56D81@daork.net> On 19/08/2008, at 11:32 PM, Robert E. Seastrom wrote: > Also, from time to time I have to reflash these to repurpose them > (NanoBSD vs. pfSense vs. AskoziaPBX). It's a complete pain to > disassemble their enclosures so I can get at the CF cards. I've often > thought that if someone had whipped up a memory-resident image of > something (anything, linux/bsd/whatever) that I could pxeboot, then I > could just dd the new image in over the net. Haven't gotten around to > doing that yet. Has anyone else? My thing is memory resident, the kernel and root fs are all in one file. That's not exactly hard to do. Not quite what you're looking for though, as config (including passwd etc.) isn't. Wouldn't be difficult to change though. Having said that, I strongly recommend getting your stuff to the point where it's a FAT formatted CF card, with a couple of files - 1 kernel, 1 filesystem image. Filesystem images are good. That way, you can mount your CF card somewhere, and 'reflash' from a live system. Just like, for example, a Cisco router. Upgrades are easy, just copy a new root FS+kernel on there. -- Nathan Ward From laird at pando.com Tue Aug 19 06:58:45 2008 From: laird at pando.com (Laird Popkin) Date: Tue, 19 Aug 2008 07:58:45 -0400 Subject: uTorrent, IPv6 In-Reply-To: References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Message-ID: <14367823-5A82-45A9-AA2C-C6491B15F67C@pando.com> My recollection is that there were complaints about them reconfiguring people's TCP stacks and uTorrent stopped enabling IPv6. - Laird Popkin, CTO, Pando Networks http://www.pandonetworks.com 520 Broadway, 10th Floor, NY, NY, 10012 laird at pando.com, 646/465-0570. Sent from my iPhone. Apologies in advance for typo's. On Aug 19, 2008, at 2:34 AM, Nathan Ward wrote: > On 19/08/2008, at 6:28 PM, Mikael Abrahamsson wrote: > >> On Tue, 19 Aug 2008, Nathan Ward wrote: >> >>> uTorrent actively enables IPv6 on XP SP2 and Vista machines in the >>> install process (by default, it can be turned off). IPv6 is turned >>> on, on lots of PCs. >> >> We looked into this, and IPv6 is not mentioned in the install >> process, and it's not selected by default as far as we can see. >> There is a button in Preferences->general that says "install IPv6/ >> Teredo", so yes, it supports it but it's not on by default, at >> least not here. > > Oh? I looked in to this in a beta, and it was on by default. > I'll have another look. > > -- > Nathan Ward > > > > > From darden at armc.org Tue Aug 19 07:40:36 2008 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 19 Aug 2008 08:40:36 -0400 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <007b01c9016a$8cd72180$020fa8c0@HDESK1> Message-ID: 1. I think ARP is effectively a ping for a mac. It verifies connectivity on level 2 between two hosts. You have to be on the same segment though.... To make it work, you would have to know the mac address of the remote host, clear the arp table the local host, then send the ARP request out. This would still require that each host have IP stacks in place with functioning IP addresses. Although ARP acts under IP, it still requires IP to function. 2. I think you might be able to fudge it using RARP, if you just look for signals sent to that address. 3. A kind of constant ping might be... if you knew the remote's MAC address you could poison the ARP table with an announcement, spoof the MAC locally, then do MITM stuff and relay communications. 4. Ok, after all that craziness I did a google search and found ARPING: http://en.wikipedia.org/wiki/Arping ARPING still seems to rely upon a proper IP stack and address on both hosts. Meh, your best bet might be just to scan your arp tables for the mac you are interested in. I think all NICs broadcast periodically saying "I am here". Passive ping. --p -----Original Message----- From: Howard C. Berkowitz [mailto:hcb at netcases.net] Sent: Monday, August 18, 2008 3:42 PM To: nanog at nanog.org Subject: RE: SLAAC(autoconfig) vs DHCPv6 This was especially a question when L2 was "in" and routing was out: how do you ping a MAC address? From vixie at isc.org Tue Aug 19 07:48:50 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 19 Aug 2008 12:48:50 +0000 Subject: RouterOS performance? In-Reply-To: <86y72tjl4r.fsf@seastrom.com> (Robert E. Seastrom's message of "Tue\, 19 Aug 2008 07\:32\:20 -0400") References: <48A8BF5F.70402@bogus.com> <86y72tjl4r.fsf@seastrom.com> Message-ID: rs at seastrom.com ("Robert E. Seastrom") writes: > Joel Jaeggli writes: > >> I actually use freebsd as a router on soekris, but I do need a general >> purpose os on the system as well. > > Speaking of Soekris (and the PCEngines ALIX by extension, of which I > have several): > > Does anyone know of a comparable small SBC that doesn't have crummy > NICs? Not a big fan of those VT6105M chips. Extra points for the > ability to do baby jumbo frames. http://www.plathome.com/products/microserver/obs/ -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rs at seastrom.com Tue Aug 19 09:28:23 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 19 Aug 2008 10:28:23 -0400 Subject: RouterOS performance? In-Reply-To: <722AAB18-6D54-466B-A4F3-730B95B56D81@daork.net> (Nathan Ward's message of "Tue, 19 Aug 2008 23:54:29 +1200") References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> <86y72tjl4r.fsf@seastrom.com> <722AAB18-6D54-466B-A4F3-730B95B56D81@daork.net> Message-ID: <861w0ljczc.fsf@seastrom.com> Nathan Ward writes: > On 19/08/2008, at 11:32 PM, Robert E. Seastrom wrote: >> Also, from time to time I have to reflash these to repurpose them >> (NanoBSD vs. pfSense vs. AskoziaPBX). It's a complete pain to >> disassemble their enclosures so I can get at the CF cards. I've often >> thought that if someone had whipped up a memory-resident image of >> something (anything, linux/bsd/whatever) that I could pxeboot, then I >> could just dd the new image in over the net. Haven't gotten around to >> doing that yet. Has anyone else? > > My thing is memory resident, the kernel and root fs are all in one > file. That's not exactly hard to do. > Not quite what you're looking for though, as config (including passwd > etc.) isn't. > Wouldn't be difficult to change though. > > Having said that, I strongly recommend getting your stuff to the point > where it's a FAT formatted CF card, with a couple of files - 1 kernel, > 1 filesystem image. Filesystem images are good. > That way, you can mount your CF card somewhere, and 'reflash' from a > live system. Just like, for example, a Cisco router. Upgrades are > easy, just copy a new root FS+kernel on there. I already have filesystem images (both from other people and of my own manufacture). I'm not sure I'm down with the fat32 cf card concept though I can see where it could be useful. What I want to do is have a minimal functionality netbootable image that is sufficient to set up network interfaces and then do: ftp> get pfsense.img "| dd of=/dev/ad0" and completely blow away what's on the flash and replace it with something new (even via serial console over a networked console server from my desk, without getting up and going to my lab where I have a small herd of these puppies as packet pushers), but particularly without having to break out a screwdriver and a nut driver and pull four sheet metal screws, four machine screws, and two rs232 retaining screw standoffs. There is pxe in the bios on the ALIX... perhaps you know of something that's already pxebootable that will do this? ---rob From kloch at kl.net Tue Aug 19 10:35:18 2008 From: kloch at kl.net (Kevin Loch) Date: Tue, 19 Aug 2008 11:35:18 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080818123308.GA47385@puck.nether.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> Message-ID: <48AAE836.5050002@kl.net> Jared Mauch wrote: > While you're at it, you also placed the reachable-via rx on > all your customer interfaces. If you're paranoid, start with the 'any' > rpf and then move to the strict rpf. The strict rpf also helps with > routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. - Kevin From streiner at cluebyfour.org Tue Aug 19 10:47:12 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 19 Aug 2008 11:47:12 -0400 (EDT) Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: Message-ID: On Tue, 19 Aug 2008, michael.dillon at bt.com wrote: >> I don't have a problem with assigning customers a /64 of v6 >> space. > > Why so little? Normally customers get a /48 except for residential > customers who can be given a /56 if you want to keep track of > different block sizes. If ARIN will give you a /48 for every > customer, then why be miserly with addresses? I don't operate an ISP network (not anymore, anyway...). My customers are departments within my organization, so a /64 per department/VLAN is more sane/reasonable for my environment. jms From stb at lassitu.de Tue Aug 19 11:35:18 2008 From: stb at lassitu.de (Stefan Bethke) Date: Tue, 19 Aug 2008 18:35:18 +0200 Subject: RouterOS performance? In-Reply-To: <861w0ljczc.fsf@seastrom.com> References: <1219016208.6853.716.camel@petrie.sacredspiral.co.uk> <48A8BF5F.70402@bogus.com> <86y72tjl4r.fsf@seastrom.com> <722AAB18-6D54-466B-A4F3-730B95B56D81@daork.net> <861w0ljczc.fsf@seastrom.com> Message-ID: Am 19.08.2008 um 16:28 schrieb Robert E. Seastrom: > What I want to do is have a minimal functionality netbootable image > that is sufficient to set up network interfaces and then do: > > ftp> get pfsense.img "| dd of=/dev/ad0" > > and completely blow away what's on the flash and replace it with > something new[...] > > There is pxe in the bios on the ALIX... perhaps you know of something > that's already pxebootable that will do this? FreeBSD (or alike) will happily boot from PXE, either with NFS root or with an in-kernel RAM disk image. Booting a kernel directly (instead of via loader(8)) is not officially supported anymore, but the last time I tried (around 6.2) it was still working. Stefan -- Stefan Bethke Fon +49 170 346 0140 From David_Hankins at isc.org Tue Aug 19 11:57:20 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Tue, 19 Aug 2008 09:57:20 -0700 Subject: SLAAC(autoconfig) vs DHCPv6 In-Reply-To: <007b01c9016a$8cd72180$020fa8c0@HDESK1> References: <20080818123346.9AC36924@resin13.mta.everyone.net> <007b01c9016a$8cd72180$020fa8c0@HDESK1> Message-ID: <20080819165720.GA29373@isc.org> On Mon, Aug 18, 2008 at 03:42:29PM -0400, Howard C. Berkowitz wrote: > If you want to test a resource, be it the end user or an infrastructure > interface, how do you know how to foo it (foo being some value of ping, > traceroute, look it up in SNMP/NetFlow, etc)? > > I submit that if you use dynamic assignment of any sort, you really have to > have DNS dynamic update, so you can use a known name to query the function > that's indexed by address. Otherwise, static addresses become rather > necessary if you want to check a resource. That's close. If you use dynamic assignment via DHCP (v4 or v6), then you have a handy database of all the IPv4 addresses assigned and whatever information you want to discern them by (if not by hostname) that was available to the DHCP server at the time of assignment. Strictly speaking, Dynamic DNS isn't even necessary, but it could be reasonably handy (because IPv6 addresses do not pass 'the phone test'). With technologies like SLAAC, tho, you are right. You're going to have to give devices a means to register with the network independently of their IP address allocation, because it only takes one client to Router Solicit to configure multiple clients upon the broadcast Router Advertisement reply. Unless you start sniffing for their neighbor discovery probes (part of SLAAC is to ensure the new address is not already in use), there's no transaction where the resource(s) are assigned. There is quite obviously a key distribution problem with that kind of model, and if you have to manually configure a system to configure itself dynamically, there is a significantly diminished reward. At this point in the excercise, you may as well do what the rest of us in the current SLAAC-only world have done; disable SLAAC and set v6 addresses (and DNS) manually. Welcome to 1985, the era DHCPv4 saved us from. But this leads you back to today's IPv6 operational problem; if you need registered clients, then you can install any DHCPv6 software you can find to get it via either its database or Dynamic DNS (quite a lot of DHCPv6 server software supports Dynamic DNS). But you still wont' have any DHCPv6 clients outside of Vista. This is where the chicken meets the egg on our faces. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mike at mtcc.com Tue Aug 19 12:25:49 2008 From: mike at mtcc.com (Michael Thomas) Date: Tue, 19 Aug 2008 10:25:49 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: Message-ID: <48AB021D.40508@mtcc.com> Justin M. Streiner wrote: > On Tue, 19 Aug 2008, michael.dillon at bt.com wrote: > >>> I don't have a problem with assigning customers a /64 of v6 >>> space. >> >> Why so little? Normally customers get a /48 except for residential >> customers who can be given a /56 if you want to keep track of >> different block sizes. If ARIN will give you a /48 for every >> customer, then why be miserly with addresses? > > I don't operate an ISP network (not anymore, anyway...). My customers > are departments within my organization, so a /64 per department/VLAN is > more sane/reasonable for my environment. Uh, the lower 64 bits of an IP6 address aren't used for routing you know? They're essentially the mac address, or some other sort of autoconf'd host identifier. Last I heard, the smallest allocation is supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was speaking of, though I'm not surprised. There's 64 bits for routing... no need to be so stingy :) Mike From randy at psg.com Tue Aug 19 12:33:01 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 10:33:01 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB021D.40508@mtcc.com> References: <48AB021D.40508@mtcc.com> Message-ID: <48AB03CD.7010305@psg.com> > Uh, the lower 64 bits of an IP6 address aren't used for routing they are. the /64 boundary is not in harwhere randy From nanog at daork.net Tue Aug 19 12:36:33 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 20 Aug 2008 05:36:33 +1200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB021D.40508@mtcc.com> References: <48AB021D.40508@mtcc.com> Message-ID: On 20/08/2008, at 5:25 AM, Michael Thomas wrote: > Justin M. Streiner wrote: >> On Tue, 19 Aug 2008, michael.dillon at bt.com wrote: >>>> I don't have a problem with assigning customers a /64 of v6 >>>> space. >>> >>> Why so little? Normally customers get a /48 except for residential >>> customers who can be given a /56 if you want to keep track of >>> different block sizes. If ARIN will give you a /48 for every >>> customer, then why be miserly with addresses? >> I don't operate an ISP network (not anymore, anyway...). My >> customers are departments within my organization, so a /64 per >> department/VLAN is more sane/reasonable for my environment. > > Uh, the lower 64 bits of an IP6 address aren't used for routing you > know? They're essentially the mac address, or some other sort of > autoconf'd host identifier. Last I heard, the smallest allocation is > supposed to be a /48 -- I hadn't heard of the /56 thing that Michael > was speaking of, though I'm not surprised. There's 64 bits for > routing... no need to be so stingy :) 64 bits is not a magical boundary. 112 bits is widely recommended for linknets, for example. 64 bits is common, because of EUI-64 and friends. That's it. There is nothing, anywhere, that says that the first 64 bits is for routing. -- Nathan Ward From sethm at rollernet.us Tue Aug 19 12:37:42 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 19 Aug 2008 10:37:42 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB021D.40508@mtcc.com> References: <48AB021D.40508@mtcc.com> Message-ID: <48AB04E6.4010700@rollernet.us> Michael Thomas wrote: > Justin M. Streiner wrote: >> On Tue, 19 Aug 2008, michael.dillon at bt.com wrote: >> >>>> I don't have a problem with assigning customers a /64 of v6 >>>> space. >>> >>> Why so little? Normally customers get a /48 except for residential >>> customers who can be given a /56 if you want to keep track of >>> different block sizes. If ARIN will give you a /48 for every >>> customer, then why be miserly with addresses? >> >> I don't operate an ISP network (not anymore, anyway...). My customers >> are departments within my organization, so a /64 per department/VLAN >> is more sane/reasonable for my environment. > > Uh, the lower 64 bits of an IP6 address aren't used for routing you > know? They're essentially the mac address, or some other sort of > autoconf'd host identifier. Last I heard, the smallest allocation is > supposed to be a /48 -- I hadn't heard of the /56 thing that Michael > was speaking of, though I'm not surprised. There's 64 bits for > routing... no need to be so stingy :) > Last time I asked about this on the ipv6 list I got smacked for thinking about using anything other than a /64 for subnets, even on point to point links. ~Seth From alain_durand at cable.comcast.com Tue Aug 19 12:45:49 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Tue, 19 Aug 2008 13:45:49 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: Message-ID: On 8/19/08 1:36 PM, "Nathan Ward" wrote: > 64 bits is not a magical boundary. > > 112 bits is widely recommended for linknets, for example. > > 64 bits is common, because of EUI-64 and friends. That's it. > There is nothing, anywhere, that says that the first 64 bits is for > routing. Actually, there is text that says so: RFC4291: IPv6 Addressing Architecture, section 2.5.1 " For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." The fact that most implementations ignore this is a different story. In practice, many routers require the packet to go twice in the hardware if the prefix length is > 64 bits, so even though it is a total waste of space, it is not stupid to use /64 for point-to-point links and even for loopbacks! - Alain. From randy at psg.com Tue Aug 19 12:50:14 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 10:50:14 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: Message-ID: <48AB07D6.3030203@psg.com> > In practice, many routers require the packet to go twice in the hardware if > the prefix length is > 64 bits, so even though it is a total waste of space, > it is not stupid to use /64 for point-to-point links and even for loopbacks! some of us remember when we thought similarly for /24s for p2p links, especially when using rip. and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127. randy From dot at dotat.at Tue Aug 19 13:05:37 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 19 Aug 2008 19:05:37 +0100 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB021D.40508@mtcc.com> References: <48AB021D.40508@mtcc.com> Message-ID: On Tue, 19 Aug 2008, Michael Thomas wrote: > Justin M. Streiner wrote: > > > > I don't operate an ISP network (not anymore, anyway...). My customers > > are departments within my organization, so a /64 per department/VLAN > > is more sane/reasonable for my environment. > > Uh, the lower 64 bits of an IP6 address aren't used for routing you > know? They're essentially the mac address, or some other sort of > autoconf'd host identifier. Last I heard, the smallest allocation is > supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was > speaking of, though I'm not surprised. There's 64 bits for routing... no > need to be so stingy :) It doesn't make sense to allocate a /48 to a (V)LAN. Address autoconfiguration is based on the assumption that the only reason for having more than one global /64 prefix on a LAN is during renumbering. Tony. -- f.anthony.n.finch http://dotat.at/ HEBRIDES BAILEY FAIR ISLE FAEROES: NORTH OR NORTHEAST 5 OR 6 DECREASING 4 OR 5, BECOMING VARIABLE 3 IN NORTH BAILEY AND WEST FAEROES LATER. MODERATE OR ROUGH. MAINLY FAIR. MODERATE OR GOOD. From trejrco at gmail.com Tue Aug 19 13:28:00 2008 From: trejrco at gmail.com (TJ) Date: Tue, 19 Aug 2008 14:28:00 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48AB021D.40508@mtcc.com> Message-ID: <000c01c90229$51585d30$f4091790$@com> >-----Original Message----- >>> On Tue, 19 Aug 2008, michael.dillon at bt.com wrote: >>>>> I don't have a problem with assigning customers a /64 of v6 space. >>>> >>>> Why so little? Normally customers get a /48 except for residential >>>> customers who can be given a /56 if you want to keep track of >>>> different block sizes. If ARIN will give you a /48 for every >>>> customer, then why be miserly with addresses? >>> I don't operate an ISP network (not anymore, anyway...). My >>> customers are departments within my organization, so a /64 per >>> department/VLAN is more sane/reasonable for my environment. >> >> Uh, the lower 64 bits of an IP6 address aren't used for routing you >> know? They're essentially the mac address, or some other sort of >> autoconf'd host identifier. Last I heard, the smallest allocation is >> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael >> was speaking of, though I'm not surprised. There's 64 bits for >> routing... no need to be so stingy :) > > >64 bits is not a magical boundary. > >112 bits is widely recommended for linknets, for example. > >64 bits is common, because of EUI-64 and friends. That's it. >There is nothing, anywhere, that says that the first 64 bits is for routing. Just to be clear - this http://tools.ietf.org/html/rfc4291#section-2.5.4 does say: " All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field." (And again - this is a case where the real world and the IETF may not agree 100% ...) /TJ From alain_durand at cable.comcast.com Tue Aug 19 13:30:38 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Tue, 19 Aug 2008 14:30:38 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <20080819.195043.41651487.sthaug@nethelp.no> Message-ID: On 8/19/08 1:50 PM, "sthaug at nethelp.no" wrote: >> In practice, many routers require the packet to go twice in the hardware if >> the prefix length is > 64 bits, so even though it is a total waste of space, >> it is not stupid to use /64 for point-to-point links and even for loopbacks! > > Could you provide some documentation on this? First I've heard about it. Ask your favorite router vendor. This has been confirmed to me by at least 3 major one we use. - Alain. From jra at baylink.com Tue Aug 19 13:39:51 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 19 Aug 2008 14:39:51 -0400 Subject: uTorrent, IPv6 In-Reply-To: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> Message-ID: <20080819183951.GC22115@cgi.jachomes.com> On Tue, Aug 19, 2008 at 04:56:33PM +1200, Nathan Ward wrote: > Sit up and pay attention, even if you don't now run IPv6, or even if > you don't ever intend to run IPv6. Your off-net bandwidth is going to > increase, unless you put some relays in. As a friend of mine just said > to me: "Welcome to your v6-enabled transit network, whether you like > it or not ;-)". So you're saying Slashdot *lies*? http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss :-) 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 joe at sumless.net Tue Aug 19 13:47:52 2008 From: joe at sumless.net (Joe Blanchard) Date: Tue, 19 Aug 2008 14:47:52 -0400 Subject: OT: Again, sorry for the noise Message-ID: <004d01c9022c$1718d610$1401a8c0@E520> Hughes Net DNS issue. I am 72.169.156.122. Notice the Source is port 53, destination is 20xx. Because I am not a large company like McDonalds this apparently cannot be resolved. No. Time Source Destination Protocol Info 190 51.553317 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 190 (122 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: raid-sf (2014) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 191 51.553759 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 191 (150 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 192 51.643105 194.72.238.11 72.169.156.122 DNS Standard query response A 83.138.190.203 Frame 192 (96 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 194.72.238.11 (194.72.238.11), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: 11603 (11603) Domain Name System (response) No. Time Source Destination Protocol Info 193 51.648410 192.168.1.20 83.138.190.203 TCP vsat-control > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 193 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.190.203 (83.138.190.203) Transmission Control Protocol, Src Port: vsat-control (1880), Dst Port: http (80), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 194 51.650140 83.138.190.203 72.169.156.122 TCP http > 23230 [SYN, ACK] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 Frame 194 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 83.138.190.203 (83.138.190.203), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23230 (23230), Seq: 0, Ack: 0, Len: 0 No. Time Source Destination Protocol Info 195 51.650489 192.168.1.20 83.138.190.203 TCP vsat-control > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 Frame 195 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.190.203 (83.138.190.203) Transmission Control Protocol, Src Port: vsat-control (1880), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 196 51.651024 192.168.1.20 83.138.190.203 HTTP GET /site_report?url=http://www.rocknyou.c [Packet size limited during capture] Frame 196 (728 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.190.203 (83.138.190.203) Transmission Control Protocol, Src Port: vsat-control (1880), Dst Port: http (80), Seq: 1, Ack: 1, Len: 674 Hypertext Transfer Protocol [Packet size limited during capture: HTTP truncated] No. Time Source Destination Protocol Info 197 51.753050 83.138.190.203 72.169.156.122 TCP http > 23230 [ACK] Seq=1 Ack=674 Win=8192 Len=0 Frame 197 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 83.138.190.203 (83.138.190.203), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23230 (23230), Seq: 1, Ack: 674, Len: 0 No. Time Source Destination Protocol Info 198 51.882510 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 198 (122 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: bootclient (2017) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 199 51.882889 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 199 (150 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 200 52.292437 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 200 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: rellpack (2018) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 201 52.292895 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 201 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 202 53.168141 192.168.1.52 64.233.179.9 DNS Standard query A sb.l.google.com Frame 202 (86 bytes on wire, 86 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.52 (192.168.1.52), Dst: 64.233.179.9 (64.233.179.9) User Datagram Protocol, Src Port: 32876 (32876), Dst Port: domain (53) Domain Name System (query) No. Time Source Destination Protocol Info 203 53.302397 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 203 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: raid-cs (2015) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 204 53.302775 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 204 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 205 53.313593 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 205 (122 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: about (2019) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 206 53.313916 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 206 (150 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 207 53.972359 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 207 (122 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: emce (2004) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 208 53.972751 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 208 (150 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 209 53.992561 64.233.179.9 72.169.156.122 DNS Standard query response A 209.85.135.136 Frame 209 (91 bytes on wire, 91 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 64.233.179.9 (64.233.179.9), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: 11604 (11604) Domain Name System (response) No. Time Source Destination Protocol Info 210 53.994612 192.168.1.20 209.85.135.136 TCP ibm-mqseries2 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 210 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 209.85.135.136 (209.85.135.136) Transmission Control Protocol, Src Port: ibm-mqseries2 (1881), Dst Port: http (80), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 211 53.996267 209.85.135.136 72.169.156.122 TCP http > 23231 [SYN, ACK] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460 Frame 211 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 209.85.135.136 (209.85.135.136), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23231 (23231), Seq: 0, Ack: 0, Len: 0 No. Time Source Destination Protocol Info 212 53.996581 192.168.1.20 209.85.135.136 TCP ibm-mqseries2 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0 Frame 212 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 209.85.135.136 (209.85.135.136) Transmission Control Protocol, Src Port: ibm-mqseries2 (1881), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 213 53.997152 192.168.1.20 209.85.135.136 HTTP GET /safebrowsing/update?client=navclient- [Packet size limited during capture] Frame 213 (858 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 209.85.135.136 (209.85.135.136) Transmission Control Protocol, Src Port: ibm-mqseries2 (1881), Dst Port: http (80), Seq: 1, Ack: 1, Len: 804 Hypertext Transfer Protocol [Packet size limited during capture: HTTP truncated] No. Time Source Destination Protocol Info 214 54.092336 209.85.135.136 72.169.156.122 TCP http > 23231 [ACK] Seq=1 Ack=804 Win=8192 Len=0 Frame 214 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 209.85.135.136 (209.85.135.136), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23231 (23231), Seq: 1, Ack: 804, Len: 0 No. Time Source Destination Protocol Info 215 54.242631 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 215 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: wizard (2001) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 216 54.242992 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 216 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 217 55.342315 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 217 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: raid-ac (2012) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 218 55.342717 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 218 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 219 55.352865 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 219 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: raid-cd (2006) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 220 55.353181 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 220 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 221 55.702595 83.138.189.101 72.169.156.122 TCP http > 23229 [FIN, ACK] Seq=641 Ack=489 Win=8192 Len=0 Frame 221 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 83.138.189.101 (83.138.189.101), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23229 (23229), Seq: 641, Ack: 489, Len: 0 No. Time Source Destination Protocol Info 222 55.702868 192.168.1.20 83.138.189.101 TCP nettgain-nms > http [ACK] Seq=490 Ack=642 Win=64895 Len=0 Frame 222 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.189.101 (83.138.189.101) Transmission Control Protocol, Src Port: nettgain-nms (1879), Dst Port: http (80), Seq: 490, Ack: 642, Len: 0 No. Time Source Destination Protocol Info 223 55.927018 209.85.135.136 72.169.156.122 HTTP HTTP/1.1 200 OK [Packet size limited during capture] Frame 223 (277 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 209.85.135.136 (209.85.135.136), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23231 (23231), Seq: 1, Ack: 804, Len: 223 Hypertext Transfer Protocol [Packet size limited during capture: HTTP truncated] No. Time Source Destination Protocol Info 224 56.102125 192.168.1.20 209.85.135.136 TCP ibm-mqseries2 > http [ACK] Seq=805 Ack=224 Win=65312 Len=0 Frame 224 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 209.85.135.136 (209.85.135.136) Transmission Control Protocol, Src Port: ibm-mqseries2 (1881), Dst Port: http (80), Seq: 805, Ack: 224, Len: 0 No. Time Source Destination Protocol Info 225 56.549076 Intel_a6:bb:04 HughesNe_b1:d4:3a ARP Who has 72.169.156.121? Tell 72.169.156.122 Frame 225 (42 bytes on wire, 42 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Address Resolution Protocol (request) No. Time Source Destination Protocol Info 226 56.549636 HughesNe_b1:d4:3a Intel_a6:bb:04 ARP 72.169.156.121 is at 00:80:ae:b1:d4:3a Frame 226 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Address Resolution Protocol (reply) No. Time Source Destination Protocol Info 227 56.739182 192.168.1.20 83.138.189.101 TCP nettgain-nms > http [FIN, ACK] Seq=490 Ack=642 Win=64895 Len=0 Frame 227 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.189.101 (83.138.189.101) Transmission Control Protocol, Src Port: nettgain-nms (1879), Dst Port: http (80), Seq: 490, Ack: 642, Len: 0 No. Time Source Destination Protocol Info 228 56.740833 83.138.189.101 72.169.156.122 TCP http > 23229 [ACK] Seq=642 Ack=490 Win=8192 Len=0 Frame 228 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 83.138.189.101 (83.138.189.101), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23229 (23229), Seq: 642, Ack: 490, Len: 0 No. Time Source Destination Protocol Info 229 57.422373 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 229 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: terminaldb (2008) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 230 57.422849 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 230 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 231 57.536738 192.168.1.52 192.203.230.10 DNS Standard query PTR 9.179.233.64.in-addr.arpa Frame 231 (96 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.52 (192.168.1.52), Dst: 192.203.230.10 (192.203.230.10) User Datagram Protocol, Src Port: 32876 (32876), Dst Port: domain (53) Domain Name System (query) No. Time Source Destination Protocol Info 232 57.537106 192.168.1.52 192.203.230.10 DNS Standard query PTR 136.135.85.209.in-addr.arpa[Packet size limited during capture] Frame 232 (98 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.52 (192.168.1.52), Dst: 192.203.230.10 (192.203.230.10) User Datagram Protocol, Src Port: 32876 (32876), Dst Port: domain (53) Domain Name System (query) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 233 58.242859 192.203.230.10 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 233 (265 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 192.203.230.10 (192.203.230.10), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: 11583 (11583) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 234 58.452318 192.203.230.10 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 234 (244 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 192.203.230.10 (192.203.230.10), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: 11583 (11583) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 235 58.453303 192.168.1.52 216.239.36.10 DNS Standard query PTR 136.135.85.209.in-addr.arpa[Packet size limited during capture] Frame 235 (98 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.52 (192.168.1.52), Dst: 216.239.36.10 (216.239.36.10) User Datagram Protocol, Src Port: 32876 (32876), Dst Port: domain (53) Domain Name System (query) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 236 59.262026 216.239.36.10 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 236 (269 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 216.239.36.10 (216.239.36.10), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: 11598 (11598) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 237 59.461851 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 237 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: raid-am (2007) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 238 59.462284 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 238 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 239 59.471614 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 239 (122 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: bootserver (2016) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 240 59.471954 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 240 (150 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 241 60.921159 209.85.135.136 72.169.156.122 TCP http > 23231 [FIN, ACK] Seq=224 Ack=804 Win=8192 Len=0 Frame 241 (64 bytes on wire, 64 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 209.85.135.136 (209.85.135.136), Dst: 72.169.156.122 (72.169.156.122) Transmission Control Protocol, Src Port: http (80), Dst Port: 23231 (23231), Seq: 224, Ack: 804, Len: 0 No. Time Source Destination Protocol Info 242 60.921564 192.168.1.20 209.85.135.136 TCP ibm-mqseries2 > http [ACK] Seq=805 Ack=225 Win=65312 Len=0 Frame 242 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 209.85.135.136 (209.85.135.136) Transmission Control Protocol, Src Port: ibm-mqseries2 (1881), Dst Port: http (80), Seq: 805, Ack: 225, Len: 0 No. Time Source Destination Protocol Info 243 61.351603 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 243 (111 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: globe (2002) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 244 61.352031 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 244 (139 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 245 61.361436 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 245 (126 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: raid-cd (2013) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 246 61.361771 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 246 (154 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 247 61.381786 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 247 (122 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: servserv (2011) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 248 61.382100 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 248 (150 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] No. Time Source Destination Protocol Info 249 63.311326 72.169.156.121 72.169.156.122 DNS Standard query response[Packet size limited during capture] Frame 249 (126 bytes on wire, 96 bytes captured) Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04 (00:d0:b7:a6:bb:04) Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122 (72.169.156.122) User Datagram Protocol, Src Port: domain (53), Dst Port: oracle (2005) Domain Name System (response) [Packet size limited during capture: DNS truncated] No. Time Source Destination Protocol Info 250 63.311777 72.169.156.122 72.169.156.121 ICMP Destination unreachable (Port unreachable)[Packet size limited during capture] Frame 250 (154 bytes on wire, 96 bytes captured) Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a) Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121 (72.169.156.121) Internet Control Message Protocol [Packet size limited during capture: IP truncated] From swmike at swm.pp.se Tue Aug 19 13:57:02 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 19 Aug 2008 20:57:02 +0200 (CEST) Subject: uTorrent, IPv6 In-Reply-To: <20080819183951.GC22115@cgi.jachomes.com> References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> <20080819183951.GC22115@cgi.jachomes.com> Message-ID: On Tue, 19 Aug 2008, Jay R. Ashworth wrote: > http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss Well, IPv6 usage is actually increasing fairly rapidly, anyway: So, still, usage is not very impressive (and some of that might be NNTP traffic), but slant of the yearly graph actually is. -- Mikael Abrahamsson email: swmike at swm.pp.se From morrowc.lists at gmail.com Tue Aug 19 14:22:46 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Aug 2008 15:22:46 -0400 Subject: OT: Again, sorry for the noise In-Reply-To: <004d01c9022c$1718d610$1401a8c0@E520> References: <004d01c9022c$1718d610$1401a8c0@E520> Message-ID: <75cb24520808191222r63f2e219q358aa0027e637676@mail.gmail.com> On Tue, Aug 19, 2008 at 2:47 PM, Joe Blanchard wrote: > Hughes Net DNS issue. I am 72.169.156.122. Notice the Source is port 53, > destination is 20xx. > Because I am not a large company like McDonalds this apparently cannot be > resolved. wow that was a lot of really hard to read packet capture.. .maybe next time just use tcpdump?? What exactly is the problem you are seeing and one assumes you called your ISP for an attempted resolution? It seems like your 122 host is spending a goodly amount of time making DNS requests to .121, is .121 your default-gw + dns-server + dhcp-server ? (and thus supposed to be getting this traffic?) -Chris From oberman at es.net Tue Aug 19 15:22:57 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 19 Aug 2008 13:22:57 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: Your message of "Tue, 19 Aug 2008 14:30:38 EDT." Message-ID: <20080819202257.0B9304500F@ptavv.es.net> > Date: Tue, 19 Aug 2008 14:30:38 -0400 > From: Alain Durand > > On 8/19/08 1:50 PM, "sthaug at nethelp.no" wrote: > > >> In practice, many routers require the packet to go twice in the hardware if > >> the prefix length is > 64 bits, so even though it is a total waste of space, > >> it is not stupid to use /64 for point-to-point links and even for loopbacks! > > > > Could you provide some documentation on this? First I've heard about it. > > Ask your favorite router vendor. This has been confirmed to me by at least 3 > major one we use. Odd. I have asked both of our router vendors and they have confirmed that they route in the ASIC based on the full address, not just the first 64 bits. (I believe one of them based on actual testing. I am suspicious of the other.) That said, one does use a few bits for something else (port) and does not load them into the FIB, so I believe they route on 120 bits, not 128. I'd love to get complete verification of the real facts of this. -- 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 kloch at kl.net Tue Aug 19 15:29:12 2008 From: kloch at kl.net (Kevin Loch) Date: Tue, 19 Aug 2008 16:29:12 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB07D6.3030203@psg.com> References: <48AB07D6.3030203@psg.com> Message-ID: <48AB2D18.3070203@kl.net> Randy Bush wrote: >> In practice, many routers require the packet to go twice in the hardware if >> the prefix length is > 64 bits, so even though it is a total waste of space, >> it is not stupid to use /64 for point-to-point links and even for loopbacks! > > some of us remember when we thought similarly for /24s for p2p links, > especially when using rip. > > and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the > prudent operational advice today is to use a /127. I thought there was an issue with duplicate address detection with /127 (RFC3627)? /126 should work and lots of folks use /112 which is a more human-friendly bit boundary. /112 is also good for multiple access vlans and just about anything that isn't using autoconfig. - Kevin From alain_durand at cable.comcast.com Tue Aug 19 15:28:10 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Tue, 19 Aug 2008 16:28:10 -0400 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <20080819202257.0B9304500F@ptavv.es.net> Message-ID: What I was told is that, yes, the packet get routed through the ASIC, but it has to go there twice... Hence reducing the pps by a factor of 2 compare to IPv4. Some vendors had shortcuts that, if the prefix len was < 64, only one pass was necessary. Caveat, this may not be true for all vendors or all models of all vendors. YMMV. - Alain. On 8/19/08 4:22 PM, "Kevin Oberman" wrote: >> Date: Tue, 19 Aug 2008 14:30:38 -0400 >> From: Alain Durand >> >> On 8/19/08 1:50 PM, "sthaug at nethelp.no" wrote: >> >>>> In practice, many routers require the packet to go twice in the hardware if >>>> the prefix length is > 64 bits, so even though it is a total waste of >>>> space, >>>> it is not stupid to use /64 for point-to-point links and even for >>>> loopbacks! >>> >>> Could you provide some documentation on this? First I've heard about it. >> >> Ask your favorite router vendor. This has been confirmed to me by at least 3 >> major one we use. > > Odd. I have asked both of our router vendors and they have confirmed > that they route in the ASIC based on the full address, not just the > first 64 bits. (I believe one of them based on actual testing. I am > suspicious of the other.) > > That said, one does use a few bits for something else (port) and does > not load them into the FIB, so I believe they route on 120 bits, not > 128. > > I'd love to get complete verification of the real facts of this. From mikael.lind at hexago.com Tue Aug 19 16:21:34 2008 From: mikael.lind at hexago.com (Mikael Lind) Date: Tue, 19 Aug 2008 17:21:34 -0400 Subject: uTorrent, IPv6 In-Reply-To: References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> <20080819183951.GC22115@cgi.jachomes.com> Message-ID: <009401c90241$8e96b120$abc41360$@lind@hexago.com> We have seen the same growth curve on the Freenet6.net tunnelling service. There hasn't been a peak in number of users so it seems people are just using it more. Our link has actually been maxed out the last two months but hopefully we will add more capacity soon and then we will see if the trend continues. If anyone wants to help drive more IPv6 traffic and wants host a tunnel gateway for Freenet6 please contact me off list. Mikael Lind > > On Tue, 19 Aug 2008, Jay R. Ashworth wrote: > > > http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss > > Well, IPv6 usage is actually increasing fairly rapidly, anyway: > > > > So, still, usage is not very impressive (and some of that might be NNTP > traffic), but slant of the yearly graph actually is. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From herrin-nanog at dirtside.com Tue Aug 19 16:28:25 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 19 Aug 2008 17:28:25 -0400 Subject: Smallest netblock that providers will accept? In-Reply-To: <2e9d8ae50808182226j1ad16eeape9b0f11fbd0d10a3@mail.gmail.com> References: <1b5c1c150808181832x667820aat7840b081ea8806a6@mail.gmail.com> <2e9d8ae50808182226j1ad16eeape9b0f11fbd0d10a3@mail.gmail.com> Message-ID: <3c3e3fca0808191428v28dd0bfcy1eb198b341a91386@mail.gmail.com> On Tue, Aug 19, 2008 at 1:26 AM, Anton Kapela wrote: > The part that Kevin spares you from reading is the "please don't" > part. [...] Instead of going down this road, I would suggest that you: > > -call up cisco and purchase a GSS (global dns lb with application > availability probes, etc) Anton, By the time many folks consider redundant network links for reliability they've already made design decisions which preclude this path. My employer is in such a situation. They'd pay the $8k or so annual systemic cost of a prefix if only there was someone they could pay. But there isn't and even if we could afford the manpower to alter our system to rely exclusively on DNS, our customers and the other vendors involved have long since built systems that expect to reference ours by IP address. > -attach your site to a pair of willing upstreams who already have a > larger prefix aggregate set aside (say a /18 or something) for > end-site multihoming, in which it is expected that the prefix will be > originated from disparate AS's (neither of which is the actual > end-site). Does someone offer such a service? Who? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Tue Aug 19 20:31:15 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 18:31:15 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: Message-ID: <48AB73E3.8090908@psg.com> matsuzaki-san's preso, i think the copy he will present next week at apops: http://www.attn.jp/presentation/apnic26-maz-ipv6-p2p.pdf randy From nanog at daork.net Tue Aug 19 23:42:29 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 20 Aug 2008 16:42:29 +1200 Subject: uTorrent, IPv6 In-Reply-To: <20080819183951.GC22115@cgi.jachomes.com> References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> <20080819183951.GC22115@cgi.jachomes.com> Message-ID: On 20/08/2008, at 6:39 AM, Jay R. Ashworth wrote: > On Tue, Aug 19, 2008 at 04:56:33PM +1200, Nathan Ward wrote: >> Sit up and pay attention, even if you don't now run IPv6, or even if >> you don't ever intend to run IPv6. Your off-net bandwidth is going to >> increase, unless you put some relays in. As a friend of mine just >> said >> to me: "Welcome to your v6-enabled transit network, whether you like >> it or not ;-)". > > So you're saying Slashdot *lies*? > > http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss They don't intentionally lie, but the study they are reporting on is uninformed. For example: "Our research looked at all IPv6 traffic?both native and tunneled, including Teredo, which encapsulates IPv4 traffic in UDP datagrams using UDP port 3544. We found a peak of only 12 Mbps of Teredo traffic, representing around 10 percent of the I P protocol 41 traffic." Teredo uses 3544/UDP to for Client<->Server communication. That is for relay discovery when needed, and the qualification procedure - not much traffic. Client<->Relay communication MAY use 3544/UDP, Client<- >Client communication MAY use 3544/UDP. In my experience (packets I have been analysing in the last 24 hours for example) suggests that not many actual data packets are on UDP/3544. I'll get some exact numbers on that in a few hours if you like. Also that report only includes data up until July 2008. uTorrent with Teredo and IPv6 stuff was released 9 August - which is the intention for my original message. -- Nathan Ward From nanog at daork.net Tue Aug 19 23:48:06 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 20 Aug 2008 16:48:06 +1200 Subject: uTorrent, IPv6 In-Reply-To: References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> <20080819183951.GC22115@cgi.jachomes.com> Message-ID: <1FB1FC35-C059-4901-AAF1-090A806AC574@daork.net> On 20/08/2008, at 6:57 AM, Mikael Abrahamsson wrote: > On Tue, 19 Aug 2008, Jay R. Ashworth wrote: > >> http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss > > Well, IPv6 usage is actually increasing fairly rapidly, anyway: > > > > So, still, usage is not very impressive (and some of that might be > NNTP traffic), but slant of the yearly graph actually is. Yep, and you're only seeing native data there. Do you have any bead on how much of the IPv4 data is protocol 41 (I.e. IPv6 tunnelled over IPv4)? I'm not going to ask you to find out how much of it is Teredo - that requires stateful DPI - but I expect it to be a non-insignificant number. Those numbers can't be added together, because depending on a couple of factors (ie public relays and things), tunnelled traffic could be counted twice - once when encapsulated, once when native. -- Nathan Ward From nanog at studio442.com.au Wed Aug 20 00:09:13 2008 From: nanog at studio442.com.au (Julien Goodwin) Date: Wed, 20 Aug 2008 15:09:13 +1000 Subject: Open Source CA / PKI In-Reply-To: <48AA9124.7010608@aset.com> References: <48AA9124.7010608@aset.com> Message-ID: <48ABA6F9.7020708@studio442.com.au> On 19/08/08 19:23, Jon Kibler wrote: > I am looking at deploying an open source CA/PKI for a client. It would > be only for internal users and systems. It would have to manage a few > hundred certificates against the organization's self-signed root cert. > It would be installed on a CentOS 5.x platform. > > I have looked at OpenCA and Dogtag. Any other packages I should look at? I've used pyca on debian, however it needs a few scripts to better automate bits of key management, unfortunately I didn't get those released by my former employer (although I'm sure I could arrange it). It's really lightweight and for the few dozen certs was easy for the sysadmins to self-manage. From pekkas at netcore.fi Wed Aug 20 00:24:35 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 20 Aug 2008 08:24:35 +0300 (EEST) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48AAE836.5050002@kl.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48AAE836.5050002@kl.net> Message-ID: On Tue, 19 Aug 2008, Kevin Loch wrote: >> While you're at it, you also placed the reachable-via rx on >> all your customer interfaces. If you're paranoid, start with the 'any' >> rpf and then move to the strict rpf. The strict rpf also helps with >> routing loops. > > Be careful not to enable strict rpf on multihomed customers. This includes > any bgp customer unless you know for sure they are single homed to you and > that will not > change. Strict uRPF (feasible paths variant, RFC3704) works just fine with multihomed customers here. But we don't allow TE more specifics either from the customer or from peers, so the longest prefix matching doesn't get messed up. And with certain kind of p2p link numbering, you may need to add a dummy static route. But it works. For more see especially Section 3 of: http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-03.txt (comments are also welcome.) -- 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 michael.dillon at bt.com Wed Aug 20 03:40:31 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Aug 2008 09:40:31 +0100 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: Message-ID: > I don't operate an ISP network (not anymore, anyway...). My > customers are departments within my organization, so a /64 > per department/VLAN is more sane/reasonable for my environment. Some time ago there was a discussion on IPv6 addressing plans spread out over a couple of days. I incorporated all the comments in this ARIN wiki page so you might want to review it and see how your overall plans fit in. --Michael Dillon From iljitsch at muada.com Wed Aug 20 03:47:39 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 20 Aug 2008 10:47:39 +0200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB2D18.3070203@kl.net> References: <48AB07D6.3030203@psg.com> <48AB2D18.3070203@kl.net> Message-ID: <4F07255C-5A45-493D-AB4A-24C03B618CEA@muada.com> On 19 aug 2008, at 22:29, Kevin Loch wrote: > I thought there was an issue with duplicate address detection with / > 127 > (RFC3627)? Don't know about that, but the all-zeroes address is supposed to be the all-routers anycast address. Cisco doesn't implement this, so /127 works on those, but there are some other vendors that do, so /127 won't work on those boxes. (And wouldn't it be funny if Cisco decided to start implementing the all-routers anycast address...) > /126 should work and lots of folks use /112 which is a more > human-friendly bit boundary. /112 is also good for multiple access > vlans and just about anything that isn't using autoconfig. I like using EUI-64 addressing, i.e.: ! interface vlan666 ipv6 address 2002:dead:beaf:666::/64 eui-64 ! This has the advantage that you don't have to explicitly assign an address to each router, it all works out automatically and you can copy/paste configs from one box to the other. I also like to put the VLAN ID in bits 48 - 63. This makes the IPv6 addressing plan REALLY simple... From iljitsch at muada.com Wed Aug 20 03:54:26 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 20 Aug 2008 10:54:26 +0200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB73E3.8090908@psg.com> References: <48AB73E3.8090908@psg.com> Message-ID: <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> On 20 aug 2008, at 3:31, Randy Bush wrote: > matsuzaki-san's preso, i think the copy he will present next week at > apops: > http://www.attn.jp/presentation/apnic26-maz-ipv6-p2p.pdf He (she?) says packets will ping-pong across the link if they are addressed to an address on the p2p subnet that isn't used. However, this is only true if there is no address resolution on the subnet, which would be the normal mode of operation with IPv4 on p2p links because those links don't have addresses and there is no ARP. With v6 on the other hand, ND can work on all link types and PPP does negotiate an address of sorts. So whether this actually happens on a true point-to-point link is open with IPv6, and if it's a point-to-point ethernet or similar link you only get some neighbor discovery traffic that goes nowhere, not an increase in actual traffic. From michael.dillon at bt.com Wed Aug 20 03:57:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Aug 2008 09:57:40 +0100 Subject: IPv6 point-to-point was: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB73E3.8090908@psg.com> Message-ID: > matsuzaki-san's preso, i think the copy he will present next > week at apops: To summarize, using /64 on a link opens the door to a DOS problem that we need to pressure the vendors to fix. Obviously, this matters more to people who are running full-blown production IPv6 networks right now than it does to people in the planning stages. But everyone should really contact their vendor and find out when this issue will be fixed. What could vendors do? They could have an implied packet filter builtin to the router code, or they could treat all odd addresses from a /64 as implicitly assigned to the :1 end and all even ones as implicitly assigned to the :2 end. Workarounds are to use /64 on the link from a link-local address range, or to filter incoming traffic that could trigger the problem or to use a /127 on the link. In the latter case, you should read and understand the implications documented in RFC 3627 In any case, IPv6 is not cut and dried. The landscape is still shifting and the only way for you to learn what works and what doesn't is to deploy it seriously. --Michael Dillon From kloch at kl.net Wed Aug 20 09:00:30 2008 From: kloch at kl.net (Kevin Loch) Date: Wed, 20 Aug 2008 10:00:30 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48AAE836.5050002@kl.net> Message-ID: <48AC237E.8010300@kl.net> Pekka Savola wrote: > On Tue, 19 Aug 2008, Kevin Loch wrote: >>> While you're at it, you also placed the reachable-via rx on >>> all your customer interfaces. If you're paranoid, start with the 'any' >>> rpf and then move to the strict rpf. The strict rpf also helps with >>> routing loops. >> >> Be careful not to enable strict rpf on multihomed customers. This >> includes >> any bgp customer unless you know for sure they are single homed to you >> and that will not >> change. > > Strict uRPF (feasible paths variant, RFC3704) works just fine with > multihomed customers here. > > But we don't allow TE more specifics either from the customer or from > peers, so the longest prefix matching doesn't get messed up. And with > certain kind of p2p link numbering, you may need to add a dummy static > route. But it works. It doesn't look like the feasible paths rpf handles the situation where your bgp customer is not announcing all or any of their prefixes to you. This can be done for TE or debugging an inbound routing issue. Announcing prefixes to me and then blackholing the traffic is not something I would appreciate as a customer. If you do this (or strict rpf) on BGP customers at least warn them up front that if they ever stop announcing prefixes to you then traffic they send you will get dropped. - Kevin From joe.johnson at inwk.com Wed Aug 20 09:31:23 2008 From: joe.johnson at inwk.com (Johnson, Joe) Date: Wed, 20 Aug 2008 09:31:23 -0500 Subject: Problems Communicating with Network Solutions Message-ID: <730AEB5ADF0DA54EA9317BF5E9A5224AFCAE9C@iwex1.IWPrint.net> Is there anyone at XO or Network Solutions that can help me with a little problem we're having? About two days ago we lost the ability to pass all traffic with Network Solutions hosted email and their main website from our main office. It keeps dying at a router in DC. Here's a trace from our Chicago office: Tracing route to 205.178.149.7 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 38.98.154.1 2 1 ms 1 ms 2 ms fa0-7.na01.b002327-0.ord01.atlas.cogentco.com [38.99.215.81] 3 <1 ms <1 ms 1 ms gi0-7.3542.core01.ord01.atlas.cogentco.com [66.250.11.189] 4 <1 ms 1 ms <1 ms te4-1.mpd01.ord01.atlas.cogentco.com [154.54.1.98] 5 1 ms 1 ms 1 ms vl3488.mpd01.ord03.atlas.cogentco.com [154.54.5.26] 6 <1 ms <1 ms <1 ms xo.ord03.atlas.cogentco.com [154.54.12.230] 7 2 ms 1 ms 1 ms te-3-1-0.rar3.chicago-il.us.xo.net [65.106.1.42] 8 4 ms 1 ms 1 ms ge7-0-0d0.rar1.chicago-il.us.xo.net [65.106.1.41] 9 28 ms 27 ms 28 ms p6-0-0.rar2.washington-dc.us.xo.net [65.106.0.46] 10 * * * Request timed out. (repeats until time-out) Here's one from an external Chicago looking glass: traceroute to 205.178.149.7 (205.178.149.7), 30 hops max, 38 byte packets 1 10.255.255.253 (10.255.255.253) 7.190 ms 5.022 ms 4.763 ms 2 vl-993.gw-core-a.whn.oneandone.net (217.160.229.45) 0.489 ms 0.487 ms 0.392 ms 3 ge-3-2-0-0.bb-a.tla.nyc.us.oneandone.net (217.160.229.65) 0.692 ms 0.655 ms 0.588 ms 4 so-1-0-0-0.bb-a.cr.chi.us.oneandone.net (74.208.1.32) 22.206 ms 22.133 ms 22.070 ms 5 p12-3.IR1.Chicago2-IL.us.xo.net (206.111.2.9) 22.309 ms 22.431 ms 22.723 ms 6 * te-3-1-0.rar3.chicago-il.us.xo.net (65.106.1.42) 24.414 ms 23.019 ms 7 ge7-0-0d0.rar1.chicago-il.us.xo.net (65.106.1.41) 23.002 ms 22.910 ms 22.918 ms 8 p6-0-0.RAR2.Washington-DC.us.xo.net (65.106.0.46) 39.504 ms 39.471 ms 39.363 ms 9 p7-0-0.MAR2.Washington5-DC.us.xo.net (65.106.3.206) 40.099 ms 40.297 ms 40.144 ms 10 71.5.190.110.ptr.us.xo.net (71.5.190.110) 40.350 ms 40.047 ms 40.093 ms 11 64.244.254.238 (64.244.254.238) 41.792 ms 41.528 ms 41.304 ms 12 edg-r-01-vlan12.net.dc2.netsol.com (205.178.191.14) 40.998 ms 41.624 ms 40.978 ms 13 205.178.182.6 (205.178.182.6) 41.389 ms 41.045 ms 41.121 ms 14 mail.networksolutionsemail.com (205.178.149.7) 41.339 ms 41.517 ms 41.291 ms Any thoughts? I also opened a ticket with Cogent, our provider in the main office. Thanks! Joe Johnson Senior Systems Engineer InnerWorkings, Inc. Managed Print & Promotional Solutions 600 West Chicago Avenue, Suite 850 Chicago, IL 60654 Phone: 312.676.6873 Fax: 312.604.5487 joe.johnson at inwk.com www.inwk.com NASDAQ: INWK From jeroen at unfix.org Wed Aug 20 09:38:15 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 20 Aug 2008 16:38:15 +0200 Subject: IPv6 point-to-point was: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: Message-ID: <48AC2C57.9050908@spaghetti.zurich.ibm.com> michael.dillon at bt.com wrote: >> matsuzaki-san's preso, i think the copy he will present next >> week at apops: > > To summarize, using /64 on a link opens the door to a DOS > problem that we need to pressure the vendors to fix. How is this not an obvious 'duh' kind of situation that just depends on doing ones configuration correctly? A similar problem occurs when one assigns a /48 down the P2P link and the downstream user has a default route back upstream but doesn't route the /48 to a loopback, but only routes a part of it (eg a /64 or two). eg: { Internet} - { ISP } - { p2p-link } - { customer } - { c1 } \ { c2 } p2p-link = 2001:db8:1000::/64 (::1 == ISP, ::2 == Customer) customer = 2001:db8:2000::/48 via 2001:db8:1000::2 c1 = 2001:db8:2000:1::/64 c2 = 2001:db8:2000:1::/64 Packets from $internet to 2001:db8:2000:1234::1 will travel down to the customer, who routes it with it's default back up to the p2p-link, where your correctly configured box will see a source address of $internet and icmp admin reject it because that is an invalid source address. Indeed the packet will bounce back up and a third packet (the icmp) will be sent thus you have an amplification of 3x, but who cares? that is at the customer link, they should configure that link correctly, and they are paying you for that link anyway -> their problem, your cash $$$ :) RPF saves the day here yet again. Remember boys and girls to configure at least your boxes correctly, don't trust other people to do the same ;) There are various number of "ISP's" who of course don't do this and which allow full spoofing from any prefix as they don't do RPF or even something simple as a "source != 2001:db8::/32" or whatever they have as their own prefix on their core routers. There of course also "ISP's" which think they are transits and tunnel to everybody they can find, these "ISP's" then of course also don't do any spoofing-filtering and generally have 'customers' that exhibit the same problem, as those just set a default back upstream. Take a small guess how easy it is to take those networks off the Internet.... better start fixing that broken setup ;) 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 glen.kent at gmail.com Wed Aug 20 11:13:44 2008 From: glen.kent at gmail.com (Glen Kent) Date: Wed, 20 Aug 2008 21:43:44 +0530 Subject: IP Fragmentation Message-ID: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> Hi, Do transit routers in the wild actually get to do IP fragmentation these days? I was wondering if routers actually do it or not, because the source usually discovers the path MTU and sends its data with the least supported MTU. Is this true? Even if this is, then this would break for multicast IP. The source cannot determine which receivers would get interested in the traffic and what capacities the links connecting them would support. So, a source would send IP packets with some size, and theres a chance that one of the routers *may* have to fragment those IP packets before passing it on to the next router. I would wager that the vendors and operators would want to avoid IP fragmentation since thats usually done in SW (unless you've got a very powerful ASIC or your box is NP based). Thanks, Glen From nanog at daork.net Wed Aug 20 12:10:36 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 21 Aug 2008 05:10:36 +1200 Subject: uTorrent, IPv6 In-Reply-To: References: <1775B568-7E63-4941-876D-9EF90D979DE5@daork.net> <20080819183951.GC22115@cgi.jachomes.com> Message-ID: <84CB0021-7179-40F1-9064-2E994EB47D0A@daork.net> On 20/08/2008, at 4:42 PM, Nathan Ward wrote: > Teredo uses 3544/UDP to for Client<->Server communication. That is > for relay discovery when needed, and the qualification procedure - > not much traffic. Client<->Relay communication MAY use 3544/UDP, > Client<->Client communication MAY use 3544/UDP. > > In my experience (packets I have been analysing in the last 24 hours > for example) suggests that not many actual data packets are on UDP/ > 3544. > I'll get some exact numbers on that in a few hours if you like. Over a 16 hour period, I captured Teredo encapsulated packets. I run my own Teredo server and so on, so I can statically set what my Teredo IPv6 address is. I'm running Azureus on this, and also on a 6to4 address on the same host. Running DHT so I talk to as many peers as possible. Azureus DHT uses lots of very small UDP over IPv6 packets (100b or so), so those are my "data" packets. The rest is just Teredo maintenance stuff. My numbers here are actually low, because of various 6to4 routing things that I don't really care to go in to in too much detail. I estimate that I'm missing 40-50% of the traffic that I'd normally see if I had IPv6 over only Teredo. I'll re-run this test properly when I get a chance, but it'll only make the numbers bigger. I exchanged packets with a total of 4177 IPv6 hosts. - 767 hosts were on Teredo. - 2657 hosts were on 6to4. - 753 hosts were on neither Teredo or 6to4. (I have a whole other rant around these vs. IPv4 as well.) The stats in the document produced by Arbor that was posted on Slashdot suggest 12Mbit/s of Teredo traffic. Their method for determining "Teredo" was to look for 3544/UDP and 3545/UDP. Of my total 96,148 packets, 27,676 were UDP over IPv6 data packets (ie not teredo maintenance). They are all very small. - 24,175 (87%) of those 27,676 UDP over IPv6 data packets were on non- well known Teredo ports. o 18,436 (76%) of those 24,175 are going through a relay somewhere. 57,624 (59.9%) of the total 96,148 packets were on non-well known Teredo ports. (including Teredo maintenance stuff). - 34,766 (60%) of those 57,624 are going through a relay somewhere. So, somewhere in the region of 60%-87% of Teredo packets were missed by the report. 60%-76% of those packets missed are going through relays.[1] So, assuming that all Teredo users do small packets, and talk to a large number of hosts like I do (100b or so packets, lots and lots of Teredo maintenance packets), the report misses about 17.9Mbit of data. If we go to the other end of the scale, and assume that most users do more data than I do (say, they load web pages, do file transfers and things), and talk to fewer hosts, we trend towards the 87% mark, in which case the report misses 80Mbit of data. So: 1) The report misses 18-80Mbit of total Teredo traffic. 2) The report misses 11-61Mbit of Teredo traffic going through relays. (a sub-set of the total Teredo traffic). The report observes approx 150Mbit/s peak IPv6 traffic. 18-80Mbit of data is not an insignificant error: 12% - 53%. So, we know that Teredo is currently under-estimated. This is when I'm talking IPv6 to other end hosts running an application that doesn't know how to talk to the Teredo stack on Windows hosts[2] (the majority of the remote ends). So, now that uTorrent 1.8 is out, with it's ability to use the Teredo stack, are we likely to see an increase in that 60-87% percentage, because of Teredo<->Teredo direct communication? Yes, Teredo<->Teredo communication always goes on non-well-known ports. This Arbor report is going to even more out of date, fast. If you're deploying non-Teredo IPv6 service (native, 6to4, whatever), you're going to have your end users talking to Teredo users, and 6to4 users. This number is going to grow. Get some relays, because the publicly available ones are going to start hurting soon, and any traffic you push through them is going to go slow. Whether you are pushing bittorrent or not, other people will be, and your non- bittorrent traffic will suffer. ps. maths might be broken, it's late in my part of the world. -- Nathan Ward [1] Because the packets I miss (the 40-50% that I estimate) are me -> 6to4 connected end host packets, they would go through a relay as well, so this number would be higher if I was catching all those packets. [2] My understanding is that Azureus can't talk to the Teredo stuff, I'll have to ask some Java coder friends to confirm that. From JamesL at Lugoj.com Wed Aug 20 12:19:31 2008 From: JamesL at Lugoj.com (Jim Logajan) Date: Wed, 20 Aug 2008 10:19:31 -0700 Subject: IP Fragmentation In-Reply-To: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> Message-ID: <48AC5223.7060807@Lugoj.com> Glen Kent wrote: > Do transit routers in the wild actually get to do IP fragmentation > these days? I was wondering if routers actually do it or not, because > the source usually discovers the path MTU and sends its data with the > least supported MTU. Is this true? I believe that is only true for TCP over IPv4. UDP over IPv4 per se doesn't involve any MTU path discovery. Some UDP applications may in fact attempt MTU discovery and self-limit teh size of their packets, but that's not part of the UDP protocol. A hypothetical specific "real world" example of where very large UDP packets might occur is SNMP. An SNMP "get" or "set" operation generally has to fit inside a UDP packet. But UDP allows up to 64k bytes in the datagram. If an SNMP object value is a really long string (say 2000 bytes long), then it will exceed the typical 1500 MTU most Ethernet interfaces expect. So I believe fragmentation will occur at the originating system. On the other hand, some systems support Ethernet jumbograms, so I believe it is possible that a default gateway router would be the first network element forced to fragment the datagram. IPv6 is a different (and more complex) story of course - fragmentation is only supposed to occur on end points - even for UDP. Quick experiment you can try if you have a Unix-like system handy: use ping (and/or ping6 or an IPv6 aware ping) and supply it with a "-s" data size parameter of, say, 2000. That makes a larger than normal packet that can't fit into a standard Ethernet frame. Use wireshark or ethereal to see what happens. If your Ethernet cards support jumbograms, use the mtu parameter of ifconfig and set it up larger than 1500. Repeat the experiment with the large data sized pings with both locally and remote systems. > Even if this is, then this would break for multicast IP. The source > cannot determine which receivers would get interested in the traffic > and what capacities the links connecting them would support. So, a > source would send IP packets with some size, and theres a chance that > one of the routers *may* have to fragment those IP packets before > passing it on to the next router. > > I would wager that the vendors and operators would want to avoid IP > fragmentation since thats usually done in SW (unless you've got a very > powerful ASIC or your box is NP based). I'm not sure how to address the above points since there appear to be some incorrect assumptions at play. It all depends on whether the Don't Fragment (DF) bit is set in IPv4 and how the source application responds to any resulting ICMP error responses (if the DF is set and one of the routes requires fragmentation). From bicknell at ufp.org Wed Aug 20 12:24:40 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Aug 2008 13:24:40 -0400 Subject: IP Fragmentation In-Reply-To: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> Message-ID: <20080820172440.GA48291@ussenterprise.ufp.org> In a message written on Wed, Aug 20, 2008 at 09:43:44PM +0530, Glen Kent wrote: > Do transit routers in the wild actually get to do IP fragmentation > these days? I was wondering if routers actually do it or not, because > the source usually discovers the path MTU and sends its data with the > least supported MTU. Is this true? Yes. A GigE jumbo frames host (9120) to a standard POS interface (4420) to a DS3 customer (1500) happens, and the GigE->POS and POS->DS3 routers must both do fragmentation. > I would wager that the vendors and operators would want to avoid IP > fragmentation since thats usually done in SW (unless you've got a very > powerful ASIC or your box is NP based). As far as I know the "big" routers all do it in hardware with no real performance penality; but I haven't studied in detail. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From nanog at shankland.org Wed Aug 20 12:48:47 2008 From: nanog at shankland.org (Jim Shankland) Date: Wed, 20 Aug 2008 10:48:47 -0700 Subject: IP Fragmentation In-Reply-To: <20080820172440.GA48291@ussenterprise.ufp.org> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20080820172440.GA48291@ussenterprise.ufp.org> Message-ID: <48AC58FF.4010306@shankland.org> Leo Bicknell wrote: > In a message written on Wed, Aug 20, 2008 at 09:43:44PM +0530, Glen Kent wrote: >> Do transit routers in the wild actually get to do IP fragmentation >> these days? [...] > > Yes. > > A GigE jumbo frames host (9120) to a standard POS interface (4420) > to a DS3 customer (1500) happens, and the GigE->POS and POS->DS3 > routers must both do fragmentation. From the application (as opposed to network operator) point of view, the big problem with fragmentation is that if you lose one fragment in transit, all the fragments eventually get discarded, even if they've made it all the way to the destination. This hurts performance and wastes resources. So you may be better off not sending those jumbo frames in the first place. If your packet loss rate, end-to-end, is epsilon, and epsilon is so small that even several times epsilon is negligible, then maybe you don't care. But you're clearly now relying on a higher standard of performance from the network fabric than you otherwise would be. Way back when, before my beard was gray, Sun came out with the Sun-4 servers, based on the new SPARC architecture. These were then widely deployed as NFS servers for Sun-3 desktops. The default NFS blocksize was 8K, the default (maybe only) transport was UDP. Sun-3 would make a read request, Sun-4 would send an 8K+ UDP response, which would get fragmented into a burst of 6 IP fragments, Sun-3 would get the first 3 or 4 before falling behind (this was, after all, the blistering fast 10 megabit Ethernet) and dropping a fragment. Eventually, the reassembly would time out, all the received fragments would get discarded, NFS would resend ... lather, rinse, repeat. Setting the NFS read and write sizes to 1460 fixed this by avoiding fragmentation. This concludes today's presentation from the history channel. Jim Shankland From Valdis.Kletnieks at vt.edu Wed Aug 20 13:04:13 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 20 Aug 2008 14:04:13 -0400 Subject: IP Fragmentation In-Reply-To: Your message of "Wed, 20 Aug 2008 21:43:44 +0530." <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> Message-ID: <20580.1219255453@turing-police.cc.vt.edu> On Wed, 20 Aug 2008 21:43:44 +0530, Glen Kent said: > Do transit routers in the wild actually get to do IP fragmentation > these days? I was wondering if routers actually do it or not, because > the source usually discovers the path MTU and sends its data with the > least supported MTU. Is this true? Hypothetically true. Unfortunately, enough places do bozo firewalling and drop the ICMP Frag Needed packets to severely limit the utility of PMTU Discovery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From iljitsch at muada.com Wed Aug 20 13:09:32 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 20 Aug 2008 20:09:32 +0200 Subject: IP Fragmentation In-Reply-To: <20580.1219255453@turing-police.cc.vt.edu> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20580.1219255453@turing-police.cc.vt.edu> Message-ID: <010F38F3-2B20-4707-9A29-0950D61C9CC5@muada.com> On 20 aug 2008, at 20:04, Valdis.Kletnieks at vt.edu wrote: > Hypothetically true. Unfortunately, enough places do bozo > firewalling and drop > the ICMP Frag Needed packets to severely limit the utility of PMTU > Discovery. Yet all OSes have it enabled and there is no fallback to fragmentation in PMTUD: if your system doesn't get the ICMP messages, your session is dead in the water. From john at internetassociatesllc.com Wed Aug 20 13:10:32 2008 From: john at internetassociatesllc.com (John Lee) Date: Wed, 20 Aug 2008 13:10:32 -0500 Subject: IP Fragmentation In-Reply-To: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159AE0@MEMEXG1.HOST.local> Glen, With the v4 networks that I have worked on in the past, they did not do end to end MTU discovery before sending packets. The TTL had to be set appropriately so that if you had low speed links, for example, the packet and response would get through in time. On our DS3 (T3) and OC-3c packet links we did 4k, 9k, and 16k packet sizes for video and file transfers. At the other end of the spectrum are civilian and military systems with tactical links, both wired and radio, with low bit rates and header compression on IP and TCP packets. Speeds range from 300 -9,600 bps, 16k, 32k, 64k and Nx64k bps links that can do packet fragmentation and adding proprietary ECC codes for the radio links. Some systems strip the IP packet and use standard or non-standard link layer protocols across the mediums. Some of these systems are store and forward so that the computer/router that is connected to the low speed link will ack the packet for the high speed network connection and buffer it up until it can be sent on the lower speed system. IMHO current IPv6 protocols ignore the lower end segment by specifying the lowest MTU for the circuit be the MTU for the entire circuit and not allow fragmentation. I do not see this as an efficient use of high speed network resources and local link management can handle fragmentation just fine. John (ISDN) Lee A slightly different History Channel. ________________________________________ From: Glen Kent [glen.kent at gmail.com] Sent: Wednesday, August 20, 2008 12:13 PM To: OPS Gurus Subject: IP Fragmentation Hi, Do transit routers in the wild actually get to do IP fragmentation these days? I was wondering if routers actually do it or not, because the source usually discovers the path MTU and sends its data with the least supported MTU. Is this true? Even if this is, then this would break for multicast IP. The source cannot determine which receivers would get interested in the traffic and what capacities the links connecting them would support. So, a source would send IP packets with some size, and theres a chance that one of the routers *may* have to fragment those IP packets before passing it on to the next router. I would wager that the vendors and operators would want to avoid IP fragmentation since thats usually done in SW (unless you've got a very powerful ASIC or your box is NP based). Thanks, Glen From Crist.Clark at globalstar.com Wed Aug 20 13:34:36 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 20 Aug 2008 11:34:36 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> References: <48AB73E3.8090908@psg.com> <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> Message-ID: <48AC0144.8C45.0097.0@globalstar.com> >>> On 8/20/2008 at 1:54 AM, Iljitsch van Beijnum wrote: > On 20 aug 2008, at 3:31, Randy Bush wrote: > >> matsuzaki-san's preso, i think the copy he will present next week at >> apops: > >> http://www.attn.jp/presentation/apnic26-maz-ipv6-p2p.pdf > > He (she?) says packets will ping-pong across the link if they are > addressed to an address on the p2p subnet that isn't used. However, > this is only true if there is no address resolution on the subnet, > which would be the normal mode of operation with IPv4 on p2p links > because those links don't have addresses and there is no ARP. With v6 > on the other hand, ND can work on all link types and PPP does > negotiate an address of sorts. > > So whether this actually happens on a true point-to-point link is open > with IPv6, and if it's a point-to-point ethernet or similar link you > only get some neighbor discovery traffic that goes nowhere, not an > increase in actual traffic. On a "true" P-to-P link, there is no netmask, no? A netmask is a concept that applies to broadcast media, like Ethernet. Even if you only have two hosts on an Ethernet link, it's not really P-to-P in the strict sense. For example, my IPv6-over-IPv4 tunnel from home (thank you HE, tunnelbroker.net) terminating on a Soekris net5501 running FreeBSD 7.0 (im s0 l33t!!11), gif0: flags=8051 metric 0 mtu 1280 tunnel inet 24.6.175.101 --> 72.52.104.74 inet6 fe80::200:24ff:feca:91b4%gif0 prefixlen 64 scopeid 0x7 inet6 2001:470:1f04:2fc::2 --> 2001:470:1f04:2fc::1 prefixlen 128 Note the prefixlen on the P-to-P portion inet6 configuration, 128. And the IPv4 tunnel part doesn't bother with a netmask. It doesn't make sense for a P-to-P. But the link-local on the gif(4)... well, hmmm. But as for how ND works over a P-to-P, the FreeBSD stack seems to be a little odd. I see, IP6 2001:470:1f04:2fc::2 > 2001:470:1f04:2fc::1: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::1, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor advertisement, tgt is 2001:470:1f04:2fc::1, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::2, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::2, length 24 IP6 2001:470:1f04:2fc::1 > 2001:470:1f04:2fc::2: ICMP6, neighbor solicitation, who has 2001:470:1f04:2fc::2, length 24 My FreeBSD 7.0 occasionally will attempt gratuitous ND, and the other end responds, but when the remote tries to find us... silence. I don't think it's my ipf ruleset either. I tried to figure out if this is a bug or feature, but digging in src/sys/netinet6... well, it's been several years since I was last in there and it made my brain hurt. But despite all of that, it all works pretty sweetly. This is from a FreeBSD 6.2 host that does autoconf to the tunnel endpoint in my tunnelbroker.net /48 (and uses temporary, privacy extension addresses, m4d l33tnes), $ /sbin/ping6 www.freebsd.org PING6(56=40+8+8 bytes) 2001:470:8045:0:7034:f7e7:3d02:c41a --> 2001:4f8:fff6::21 16 bytes from 2001:4f8:fff6::21, icmp_seq=0 hlim=56 time=16.844 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=1 hlim=56 time=17.674 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=2 hlim=56 time=15.692 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=3 hlim=56 time=45.123 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=4 hlim=56 time=116.619 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=5 hlim=56 time=22.286 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=6 hlim=56 time=18.861 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=7 hlim=56 time=15.797 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=8 hlim=56 time=15.391 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=9 hlim=56 time=19.165 ms 16 bytes from 2001:4f8:fff6::21, icmp_seq=10 hlim=56 time=47.429 ms ^C --- www.freebsd.org ping6 statistics --- 11 packets transmitted, 11 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 15.391/31.898/116.619/28.985 ms 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 john at internetassociatesllc.com Wed Aug 20 13:34:55 2008 From: john at internetassociatesllc.com (John Lee) Date: Wed, 20 Aug 2008 13:34:55 -0500 Subject: IP Fragmentation (correction) Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159AE1@MEMEXG1.HOST.local> Correction. TTL needs to be set to sufficiently large number of hops to allow the packet to get through the number of hops and the timers need to be set to allow the packet to transit the network and the low speed links before timing out and retransmitting the packet. John (ISDN) Lee ________________________________________ From: John Lee [john at internetassociatesllc.com] Sent: Wednesday, August 20, 2008 2:10 PM To: Glen Kent; OPS Gurus Subject: RE: IP Fragmentation Glen, With the v4 networks that I have worked on in the past, they did not do end to end MTU discovery before sending packets. The TTL had to be set appropriately so that if you had low speed links, for example, the packet and response would get through in time. On our DS3 (T3) and OC-3c packet links we did 4k, 9k, and 16k packet sizes for video and file transfers. At the other end of the spectrum are civilian and military systems with tactical links, both wired and radio, with low bit rates and header compression on IP and TCP packets. Speeds range from 300 -9,600 bps, 16k, 32k, 64k and Nx64k bps links that can do packet fragmentation and adding proprietary ECC codes for the radio links. Some systems strip the IP packet and use standard or non-standard link layer protocols across the mediums. Some of these systems are store and forward so that the computer/router that is connected to the low speed link will ack the packet for the high speed network connection and buffer it up until it can be sent on the lower speed system. IMHO current IPv6 protocols ignore the lower end segment by specifying the lowest MTU for the circuit be the MTU for the entire circuit and not allow fragmentation. I do not see this as an efficient use of high speed network resources and local link management can handle fragmentation just fine. John (ISDN) Lee A slightly different History Channel. ________________________________________ From: Glen Kent [glen.kent at gmail.com] Sent: Wednesday, August 20, 2008 12:13 PM To: OPS Gurus Subject: IP Fragmentation Hi, Do transit routers in the wild actually get to do IP fragmentation these days? I was wondering if routers actually do it or not, because the source usually discovers the path MTU and sends its data with the least supported MTU. Is this true? Even if this is, then this would break for multicast IP. The source cannot determine which receivers would get interested in the traffic and what capacities the links connecting them would support. So, a source would send IP packets with some size, and theres a chance that one of the routers *may* have to fragment those IP packets before passing it on to the next router. I would wager that the vendors and operators would want to avoid IP fragmentation since thats usually done in SW (unless you've got a very powerful ASIC or your box is NP based). Thanks, Glen From karnaugh at karnaugh.za.net Wed Aug 20 13:57:21 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 20 Aug 2008 20:57:21 +0200 Subject: IP Fragmentation In-Reply-To: <20580.1219255453@turing-police.cc.vt.edu> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20580.1219255453@turing-police.cc.vt.edu> Message-ID: <48AC6911.1060506@karnaugh.za.net> On 2008/08/20 08:04 PM Valdis.Kletnieks at vt.edu wrote: > On Wed, 20 Aug 2008 21:43:44 +0530, Glen Kent said: >> Do transit routers in the wild actually get to do IP fragmentation >> these days? I was wondering if routers actually do it or not, because >> the source usually discovers the path MTU and sends its data with the >> least supported MTU. Is this true? > > Hypothetically true. Unfortunately, enough places do bozo firewalling and drop > the ICMP Frag Needed packets to severely limit the utility of PMTU Discovery. > Well obviously, ICMP is only used by hackers to DDoS you. Everyone knows that, especially all the banks. It's even more important to obliterate PMTU discovery when you're using HTTPS - for security, you know. Sorry, I spent the better part of today bashing my head against the wall trying to fix MSS and PMTU issues somewhere which was being aggravated by the tragic programming of Linux l2tpns package... From iljitsch at muada.com Wed Aug 20 13:57:46 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 20 Aug 2008 20:57:46 +0200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AC0144.8C45.0097.0@globalstar.com> References: <48AB73E3.8090908@psg.com> <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> <48AC0144.8C45.0097.0@globalstar.com> Message-ID: On 20 aug 2008, at 20:34, Crist Clark wrote: > On a "true" P-to-P link, there is no netmask, no? A netmask is a > concept that applies to broadcast media, like Ethernet. Even if > you only have two hosts on an Ethernet link, it's not really > P-to-P in the strict sense. An interface needs a prefix length (subnet mask for those of us stuck in the '90s) so the system knows which addresses are directly connected through the interface in question. Whether the link is point- to-point, broadcast or NBMA doesn't matter for that purpose. > But as for how ND works over a P-to-P, the FreeBSD stack seems > to be a little odd. [...] > But despite all of that, it all works pretty sweetly. There have been compatibility issues with PPP for IPv6 in the past because some implementations would do ND and others wouldn't... From joe.johnson at inwk.com Wed Aug 20 14:13:02 2008 From: joe.johnson at inwk.com (Johnson, Joe) Date: Wed, 20 Aug 2008 14:13:02 -0500 Subject: RESOLVED: Problems Communicating with Network Solutions In-Reply-To: <730AEB5ADF0DA54EA9317BF5E9A5224AFCAE9C@iwex1.IWPrint.net> References: <730AEB5ADF0DA54EA9317BF5E9A5224AFCAE9C@iwex1.IWPrint.net> Message-ID: <730AEB5ADF0DA54EA9317BF5E9A5224AFCAF38@iwex1.IWPrint.net> Thank you to the people who replied off-list, especially Eric Mort of XO and Jim Arrows of Network Solutions in helping find the cause of this problem. Joe Johnson Senior Systems Engineer InnerWorkings, Inc. Managed Print & Promotional Solutions 600 West Chicago Avenue, Suite 850 Chicago, IL 60654 Phone: 312.676.6873 Fax: 312.604.5487 joe.johnson at inwk.com www.inwk.com NASDAQ: INWK From Crist.Clark at globalstar.com Wed Aug 20 14:33:25 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Wed, 20 Aug 2008 12:33:25 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: References: <48AB73E3.8090908@psg.com> <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> <48AC0144.8C45.0097.0@globalstar.com> Message-ID: <48AC0F0D.8C45.0097.0@globalstar.com> >>> On 8/20/2008 at 11:57 AM, Iljitsch van Beijnum wrote: > On 20 aug 2008, at 20:34, Crist Clark wrote: > >> On a "true" P-to-P link, there is no netmask, no? A netmask is a >> concept that applies to broadcast media, like Ethernet. Even if >> you only have two hosts on an Ethernet link, it's not really >> P-to-P in the strict sense. > > An interface needs a prefix length (subnet mask for those of us stuck > in the '90s) so the system knows which addresses are directly > connected through the interface in question. Whether the link is point- > to-point, broadcast or NBMA doesn't matter for that purpose. No, that's my point. On a true point-to-point link, there is only one other address on the link. That's what point-to-point means. And no, that does not really mean there is an implied /32 (for IPv4) or /128 (for IPv6) on the link since that would tell the system its the only address on the link. For example, on the IPv4 ends gif(4) tunnel in my previous message, gif0: flags=8051 metric 0 mtu 1280 tunnel inet 24.6.175.101 --> 72.52.104.74 inet6 fe80::200:24ff:feca:91b4%gif0 prefixlen 64 scopeid 0x7 inet6 2001:470:1f04:2fc::2 --> 2001:470:1f04:2fc::1 prefixlen 128 A netmask doesn't make sense. They're not on the same LAN since there is no LAN on a point-to-point tunnel. (The most specific mask those two share is 0x8000000.) As for the IPv6 portion, the two endpoints happen to be adjacent, they look like they are "on the same network," but there is no reason that has to be in the general case just like the IPv4 case. There is no LAN. It's point-to-point. It could be, 2001:470:8045:0:2b0:d0ff:fe2c:982d --> 2001:470:1f04:2fc::1 (That only happen share the /16 belonging to the ISP, not even on the same /64) and everything would be fine. Right? Or is something different about IPv6? I'm wondering if all of this confusion is about people calling an Ethernet, or other broadcast media, link with only two interfaces on it point-to-point. It's not. 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 tims at donet.com Wed Aug 20 15:37:27 2008 From: tims at donet.com (Tim Sanderson) Date: Wed, 20 Aug 2008 16:37:27 -0400 Subject: IP Fragmentation In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159AE0@MEMEXG1.HOST.local> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <53A6C7E936ED8544B1A2BC990D254F942BF6159AE0@MEMEXG1.HOST.local> Message-ID: The "network" may not but the end hosts may try. Many client operating systems perform PMTU by default. Some also do blackhole probing that can also change the MTU. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: John Lee [mailto:john at internetassociatesllc.com] Sent: Wednesday, August 20, 2008 2:11 PM To: Glen Kent; OPS Gurus Subject: RE: IP Fragmentation Glen, With the v4 networks that I have worked on in the past, they did not do end to end MTU discovery before sending packets. The TTL had to be set appropriately so that if you had low speed links, for example, the packet and response would get through in time. On our DS3 (T3) and OC-3c packet links we did 4k, 9k, and 16k packet sizes for video and file transfers. At the other end of the spectrum are civilian and military systems with tactical links, both wired and radio, with low bit rates and header compression on IP and TCP packets. Speeds range from 300 -9,600 bps, 16k, 32k, 64k and Nx64k bps links that can do packet fragmentation and adding proprietary ECC codes for the radio links. Some systems strip the IP packet and use standard or non-standard link layer protocols across the mediums. Some of these systems are store and forward so that the computer/router that is connected to the low speed link will ack the packet for the high speed network connection and buffer it up until it can be sent on the lower speed system. IMHO current IPv6 protocols ignore the lower end segment by specifying the lowest MTU for the circuit be the MTU for the entire circuit and not allow fragmentation. I do not see this as an efficient use of high speed network resources and local link management can handle fragmentation just fine. John (ISDN) Lee A slightly different History Channel. ________________________________________ From: Glen Kent [glen.kent at gmail.com] Sent: Wednesday, August 20, 2008 12:13 PM To: OPS Gurus Subject: IP Fragmentation Hi, Do transit routers in the wild actually get to do IP fragmentation these days? I was wondering if routers actually do it or not, because the source usually discovers the path MTU and sends its data with the least supported MTU. Is this true? Even if this is, then this would break for multicast IP. The source cannot determine which receivers would get interested in the traffic and what capacities the links connecting them would support. So, a source would send IP packets with some size, and theres a chance that one of the routers *may* have to fragment those IP packets before passing it on to the next router. I would wager that the vendors and operators would want to avoid IP fragmentation since thats usually done in SW (unless you've got a very powerful ASIC or your box is NP based). Thanks, Glen From Chris.Neitzert at redfin.com Wed Aug 20 17:03:49 2008 From: Chris.Neitzert at redfin.com (Chris Neitzert) Date: Wed, 20 Aug 2008 15:03:49 -0700 Subject: AOL NOC CONTACT? Message-ID: <082D8A131DF72A4D88C908A1AD3DEB2204A2DB4C@mail-1.rf.lan> Hi, Does anyone have AOL NOC Contact information? Thanks Chris -- Christopher Neitzert? Director Information Technology & Data Center Operations Redfin Corporation http://www.redfin.com From sam_mailinglists at spacething.org Wed Aug 20 17:07:22 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Wed, 20 Aug 2008 23:07:22 +0100 Subject: IP Fragmentation In-Reply-To: <010F38F3-2B20-4707-9A29-0950D61C9CC5@muada.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20580.1219255453@turing-police.cc.vt.edu> <010F38F3-2B20-4707-9A29-0950D61C9CC5@muada.com> Message-ID: <48AC959A.7030203@spacething.org> Iljitsch van Beijnum wrote: > On 20 aug 2008, at 20:04, Valdis.Kletnieks at vt.edu wrote: > >> Hypothetically true. Unfortunately, enough places do bozo >> firewalling and drop >> the ICMP Frag Needed packets to severely limit the utility of PMTU >> Discovery. > > Yet all OSes have it enabled and there is no fallback to fragmentation > in PMTUD: if your system doesn't get the ICMP messages, your session > is dead in the water. > Windows Vista/2007 has black hole detection enabled by default. It's not massively elegant, but it will keep sessions up (falls back to 536 byte MTU). http://support.microsoft.com/kb/925280 Sam From Chris.Neitzert at redfin.com Wed Aug 20 18:08:55 2008 From: Chris.Neitzert at redfin.com (Chris Neitzert) Date: Wed, 20 Aug 2008 16:08:55 -0700 Subject: AOL NOC CONTACT? In-Reply-To: <082D8A131DF72A4D88C908A1AD3DEB2204A2DB4C@mail-1.rf.lan> References: <082D8A131DF72A4D88C908A1AD3DEB2204A2DB4C@mail-1.rf.lan> Message-ID: <082D8A131DF72A4D88C908A1AD3DEB2204A2DC06@mail-1.rf.lan> Thanks to those who responded off list. Much appreciated. -----Original Message----- From: Chris Neitzert [mailto:Chris.Neitzert at redfin.com] Sent: Wednesday, August 20, 2008 3:04 PM To: nanog at nanog.org Subject: AOL NOC CONTACT? Hi, Does anyone have AOL NOC Contact information? Thanks Chris -- Christopher Neitzert? Director Information Technology & Data Center Operations Redfin Corporation http://www.redfin.com From iljitsch at muada.com Thu Aug 21 03:09:58 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 21 Aug 2008 10:09:58 +0200 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AC0F0D.8C45.0097.0@globalstar.com> References: <48AB73E3.8090908@psg.com> <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> <48AC0144.8C45.0097.0@globalstar.com> <48AC0F0D.8C45.0097.0@globalstar.com> Message-ID: <9494DF2B-66BF-496F-9E0F-759D2832905B@muada.com> On 20 aug 2008, at 21:33, Crist Clark wrote: > No, that's my point. On a true point-to-point link, there is > only one other address on the link. That's what point-to-point > means. > For example, on the IPv4 ends gif(4) tunnel in my previous message, > > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 24.6.175.101 --> 72.52.104.74 > inet6 fe80::200:24ff:feca:91b4%gif0 prefixlen 64 scopeid 0x7 > inet6 2001:470:1f04:2fc::2 --> 2001:470:1f04:2fc::1 prefixlen > 128 Note that this interface doesn't _have_ any IPv4 addresses: the IPv4 addresses that you see are the tunnel endpoints. However, the IPv6 addresses do what you say: there is a local one and a remote one and they don't share a subnet. Obviously it's possible to do this, but in my opinion, this is just an implementation variation, not the natural state of point-to-point links. It makes much more sense to have one set of behaviors that applies to all interfaces. And what is a point-to-point link, anyway? In theory gigabit ethernet is CSMA/CD, but I don't think anyone ever bothered to implement that, in practice it's point-to-point on layer 1, but layer 2 is point-to- multipoint... From sam_mailinglists at spacething.org Thu Aug 21 08:32:04 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Thu, 21 Aug 2008 14:32:04 +0100 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AB07D6.3030203@psg.com> References: <48AB07D6.3030203@psg.com> Message-ID: <48AD6E54.6070704@spacething.org> Randy Bush wrote: > and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the > prudent operational advice today is to use a /127. > > randy > > Can you provide some more information on this vulnerability? My google-fu appears to be weak. Sam From mkohno at juniper.net Thu Aug 21 09:02:35 2008 From: mkohno at juniper.net (Miya Kohno) Date: Thu, 21 Aug 2008 22:02:35 +0800 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AD6E54.6070704@spacething.org> References: <48AB07D6.3030203@psg.com> <48AD6E54.6070704@spacething.org> Message-ID: A very old one:) http://atm.tut.fi/list-archive/ipng/msg00163.html Miya > -----Original Message----- > From: Sam Stickland [mailto:sam_mailinglists at spacething.org] > Sent: Thursday, August 21, 2008 10:32 PM > To: Randy Bush > Cc: nanog list > Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum > > Randy Bush wrote: > > and consider matsuzaki-san's dos vulnerability on a /64 p2p > link. the > > prudent operational advice today is to use a /127. > > > > randy > > > > > Can you provide some more information on this vulnerability? > My google-fu appears to be weak. > > Sam > > > From jrhett at netconsonance.com Thu Aug 21 17:01:20 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 21 Aug 2008 15:01:20 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48AC237E.8010300@kl.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48AAE836.5050002@kl.net> <48AC237E.8010300@kl.net> Message-ID: On Aug 20, 2008, at 7:00 AM, Kevin Loch wrote: > It doesn't look like the feasible paths rpf handles the situation > where > your bgp customer is not announcing all or any of their prefixes to > you. > This can be done for TE or debugging an inbound routing > issue. Announcing prefixes to me and then blackholing the traffic > is not something I would appreciate as a customer. > > If you do this (or strict rpf) on BGP customers at least warn them > up front > that if they ever stop announcing prefixes to you then traffic they > send > you will get dropped. Clueful BGP admins know how to send their routes with no-advertise on them. There are fairly good reasons to require your direct customers always advertise their routes to you, even if you won't be readvertising them. uRPF is one. Not paying transit both inbound and out for multi- gig DoS attacks is my favorite. Etc. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From cmills at accessdc.com Thu Aug 21 17:10:45 2008 From: cmills at accessdc.com (Mills, Charles) Date: Thu, 21 Aug 2008 18:10:45 -0400 Subject: Anyone from VisionNet AS8057 on list? Message-ID: <58E0B21FC367B24485855A1DBD96B0BB0DCA881A@adc-prd-exch1.internal.accessdc.com> I'd like to talk to someone about a problem with some prefixes no longer working through your network. Please contact off list (email best) Thanks....Chuck Charles L. Mills Senior Network Engineer Access Data Corporation / Pittsburgh, PA 15238 Cmills at accessdc dot com This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From sean at donelan.com Thu Aug 21 19:03:19 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 21 Aug 2008 20:03:19 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <48AAE836.5050002@kl.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48AAE836.5050002@kl.net> Message-ID: <200808211955080.32BF5B92.10438@clifden.donelan.com> On Tue, 19 Aug 2008, Kevin Loch wrote: >> While you're at it, you also placed the reachable-via rx on >> all your customer interfaces. If you're paranoid, start with the 'any' >> rpf and then move to the strict rpf. The strict rpf also helps with >> routing loops. > > Be careful not to enable strict rpf on multihomed customers. This includes > any bgp customer unless you know for sure they are single homed to you and > that will not > change. Isn't it time to change the assumption that sending arbitrary source IP addresses without checking is Ok? Unless the customer has specifically told their ISP about all the IP addresses they intend to use as source IP addresses, shouldn't the default be to drop those packets. If those multi-homed customers have not told their upstream ISPs about additional source IP addresses (hopefully also registered/authorized for use by the same customer) why can they still send packets with those source addresses? Instead shouldn't you say "Be careful if you are a using source IP addresses without informing your upstream." In practice, how many multi-homed customers send packets with unannounced source IP addresses? And for those customers which do, why is the ISP unable to implement any of the alternative source IP checking options, such as using a ACL with uRPF or on the interface? From sean at donelan.com Thu Aug 21 19:18:37 2008 From: sean at donelan.com (Sean Donelan) Date: Thu, 21 Aug 2008 20:18:37 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> Message-ID: <200808212006370.32BF5B92.10507@clifden.donelan.com> On Mon, 18 Aug 2008, Danny McPherson wrote: > All the interesting attacks today that employ spoofing (and the > majority of the less-interesting ones that employ spoofing) are > usually relying on existence of the source as part of the attack > vector (e.g., DNS cache poisoning, BGP TCP RST attacks, > DNS reflective amplification attacks, etc..), and as a result, loose > mode gives folks a false sense of protection/action. Yep. Same thing with bogon filters. Any attacker which can source packets with bogon addresses, can by definition, source packets with any "valid" IP address too. Great as an academic exercise, but the bad guys are going to send evil packets without the evil bit nor using bogon addresses. If the bad guys are using spoofed addresses, they don't care about the reply packets to either valid or unallocated addresses. However, seeing packets with unallocated IP addresses on the Internet is evidence of a broken network. Just like when a network trips "max prefix" on a BGP session, shouldn't a broken network be shutdown until the problem is fixed. If you don't want to risk your network peers turning off the connections, make sure your network doesn't source spoofed packets. From cidr-report at potaroo.net Fri Aug 22 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Aug 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200808221200.m7MC04ax059067@wattle.apnic.net> BGP Update Report Interval: 21-Jul-08 -to- 21-Aug-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS1803 101579 1.7% 79.9 -- ICMNET-5 - Sprint 2 - AS9583 97193 1.6% 77.9 -- SIFY-AS-IN Sify Limited 3 - AS5691 75123 1.2% 6829.4 -- MITRE-AS-5 - The MITRE Corporation 4 - AS8151 72284 1.2% 33.4 -- Uninet S.A. de C.V. 5 - AS9051 65181 1.1% 415.2 -- IDM Autonomous System 6 - AS4538 52352 0.9% 10.4 -- ERX-CERNET-BKB China Education and Research Network Center 7 - AS6298 49858 0.8% 23.6 -- COX-PHX - Cox Communications Inc. 8 - AS4766 49472 0.8% 55.4 -- KIXS-AS-KR Korea Telecom 9 - AS10396 49127 0.8% 982.5 -- COQUI-NET - DATACOM CARIBE, INC. 10 - AS17488 46416 0.8% 33.0 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 11 - AS33783 45829 0.8% 277.8 -- EEPAD 12 - AS17974 35642 0.6% 47.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS8866 35217 0.6% 109.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 14 - AS3464 34905 0.6% 93.6 -- ASC-NET - Alabama Supercomputer Network 15 - AS14522 34899 0.6% 170.2 -- Satnet 16 - AS9299 34608 0.6% 27.0 -- IPG-AS-AP Philippine Long Distance Telephone Company 17 - AS9929 33532 0.6% 108.5 -- CNCNET-CN China Netcom Corp. 18 - AS6389 29256 0.5% 9.0 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 19 - AS18231 27819 0.5% 112.6 -- EXATT-AS-AP IOL NETCOM LTD 20 - AS28194 27639 0.5% 3454.9 -- TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS47467 26587 0.4% 13293.5 -- GRIFFEL Griffel AB 2 - AS14593 7662 0.1% 7662.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 3 - AS29910 6883 0.1% 6883.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 4 - AS5691 75123 1.2% 6829.4 -- MITRE-AS-5 - The MITRE Corporation 5 - AS27245 10824 0.2% 5412.0 -- HEIDRICK-CHICAGO - HEIDRICK 6 - AS40627 7519 0.1% 3759.5 -- RC-COLO1 - RingCentral Inc 7 - AS23082 18520 0.3% 3704.0 -- MPHI - Michigan Public Health Institute 8 - AS28194 27639 0.5% 3454.9 -- 9 - AS30969 26003 0.4% 2363.9 -- TAN-NET TransAfrica Networks 10 - AS30929 2313 0.0% 2313.0 -- HUTCB Hidrotechnical Faculty - Technical University 11 - AS39748 2127 0.0% 2127.0 -- VITAS VITAS LLC 12 - AS23917 1783 0.0% 1783.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 13 - AS39794 1776 0.0% 1776.0 -- EL-KOZIENICE-AS Elektrownia Kozienice S.A. 14 - AS28542 1737 0.0% 1737.0 -- Gobierno del Estado de Coahuila 15 - AS11268 1720 0.0% 1720.0 -- WNM-ORG - Walls New Media 16 - AS39105 1705 0.0% 1705.0 -- CLASS-AS SC Class Computers And Service SRL 17 - AS5382 1679 0.0% 1679.0 -- TELESYSTEM-NET Planet Service Srl 18 - AS39244 1653 0.0% 1653.0 -- TEQNOBASE-AS Teqnobase AS 19 - AS42795 1600 0.0% 1600.0 -- XEROX-GENERAL-AS Xerox General Services 20 - AS31567 15908 0.3% 1590.8 -- AKSORAN Aksoran LCC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 74993 1.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 194.126.143.0/24 61617 0.9% AS9051 -- IDM Autonomous System 3 - 221.134.222.0/24 61228 0.9% AS9583 -- SIFY-AS-IN Sify Limited 4 - 83.228.71.0/24 28095 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.128.192.0/18 25349 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 72.50.96.0/20 24364 0.4% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 7 - 196.42.0.0/20 14651 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 8 - 62.182.216.0/21 13303 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 9 - 91.203.160.0/22 13294 0.2% AS35706 -- NAO Net at Once AS47467 -- GRIFFEL Griffel AB 10 - 196.27.104.0/21 12920 0.2% AS30969 -- TAN-NET TransAfrica Networks AS8668 -- TELONE-AS TelOne Zimbabwe P/L 11 - 196.27.108.0/22 12680 0.2% AS30969 -- TAN-NET TransAfrica Networks 12 - 203.63.26.0/24 10557 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 13 - 89.38.98.0/23 10092 0.1% AS6663 -- EUROWEBRO Euroweb Romania SA 14 - 63.84.91.0/24 9959 0.1% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 15 - 83.239.192.0/21 9930 0.1% AS42362 -- ALANIA-AS Sevosetinelectrosvyaz 16 - 202.150.80.0/20 8757 0.1% AS9251 -- SPEEDNET-AP PT Speed Internet Digital 17 - 202.52.245.0/24 8405 0.1% AS4613 -- MOS-NP Mercantile Office Systems 18 - 12.8.7.0/24 7662 0.1% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 19 - 189.90.80.0/20 7129 0.1% AS28194 -- 20 - 205.106.88.0/22 7099 0.1% AS5237 -- DODNIC - DoD Network Information Center 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 Aug 22 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Aug 2008 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200808221200.m7MC02bR059049@wattle.apnic.net> This report has been generated at Fri Aug 22 21:19: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 15-08-08 277664 174550 16-08-08 277570 174851 17-08-08 277931 175052 18-08-08 277784 175249 19-08-08 278028 175381 20-08-08 278005 175961 21-08-08 278259 174641 22-08-08 276915 170272 AS Summary 29174 Number of ASes in routing system 12319 Number of ASes announcing only one prefix 5015 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88350208 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'). --- 22Aug08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 278686 170389 108297 38.9% All ASes AS4538 5015 879 4136 82.5% ERX-CERNET-BKB China Education and Research Network Center AS6389 3202 260 2942 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2897 657 2240 77.3% ASN-QWEST - Qwest AS4755 1710 231 1479 86.5% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS6298 1981 753 1228 62.0% COX-PHX - Cox Communications Inc. AS18566 1045 41 1004 96.1% COVAD - Covad Communications Co. AS17488 1317 326 991 75.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1648 666 982 59.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS4323 1490 512 978 65.6% TWTC - tw telecom holdings, inc. AS8151 1519 583 936 61.6% Uninet S.A. de C.V. AS22773 961 66 895 93.1% CCINET-2 - Cox Communications Inc. AS19262 942 170 772 82.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1214 500 714 58.8% CABLEONE - CABLE ONE AS2386 1563 913 650 41.6% INS-AS - AT&T Data Communications Services AS6478 1113 536 577 51.8% ATT-INTERNET3 - AT&T WorldNet Services AS9498 675 107 568 84.1% BBIL-AP BHARTI Airtel Ltd. AS18101 693 129 564 81.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4766 894 395 499 55.8% KIXS-AS-KR Korea Telecom AS855 589 112 477 81.0% CANET-ASN-4 - Bell Aliant AS4808 618 147 471 76.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS6197 943 477 466 49.4% BATI-ATL - BellSouth Network Solutions, Inc AS7011 978 514 464 47.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4134 836 381 455 54.4% CHINANET-BACKBONE No.31,Jin-rong Street AS22047 563 126 437 77.6% VTR BANDA ANCHA S.A. AS9443 523 91 432 82.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1432 1004 428 29.9% ATT-INTERNET4 - AT&T WorldNet Services AS7029 538 111 427 79.4% WINDSTREAM - Windstream Communications Inc AS24560 570 154 416 73.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 683 274 409 59.9% LGNET-AS-KR LG CNS AS4780 722 322 400 55.4% SEEDNET Digital United Inc. Total 38874 11437 27437 70.6% Top 30 total Possible Bogus Routes 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.53.86.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.55.0.0/18 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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 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.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 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 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 83.167.224.0/19 AS24971 MASTER-AS Master Internet s.r.o / Czech Republic / www.master.cz 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 91.208.160.0/24 AS42442 ADACOR-AS Adacor Hosting GmbH 94.155.0.0/16 AS9070 ITD ITD Network Bulgarian ISP 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 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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/16 AS8546 YOUR-COMMS-UK-AS Your Communications Ltd 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 AS2018 TENET-1 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.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.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 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.254.192.0/19 AS2116 ASN-CATCHCOM Ventelo 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 - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 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.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 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.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.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 - tw telecom holdings, 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.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, 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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 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. 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 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 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.127.124.0/23 AS2828 XO-AS15 - XO Communications 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.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 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 MatlockK at exempla.org Fri Aug 22 09:34:05 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Fri, 22 Aug 2008 08:34:05 -0600 Subject: Force10 Gear - Opinions Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> Sorry for the off-topic post. Does anyone here have real-world experience with Force 10 gear (Specifically their E-Series and C-Series)? They came and did their whole dog and pony show today, but I wanted to get real-world feedback on their gear. I need to know about their 1) Reliability 2) Performance 3) Support staff (how knowledgeable are they?) 4) Price (higher/lower/comparable to comparable Cisco gear) We're exclusively a Cisco shop here right now (mostly Cat6500s), so changing out some of our core gear with Force 10 is a bit 'scary', but if it meets our needs, maybe... Contact me off-list please. Thanks! Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org From jared at puck.nether.net Fri Aug 22 09:43:15 2008 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 22 Aug 2008 10:43:15 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> Message-ID: <20080822144315.GK76625@puck.nether.net> On Fri, Aug 22, 2008 at 08:34:05AM -0600, Matlock, Kenneth L wrote: > Sorry for the off-topic post. > > Does anyone here have real-world experience with Force 10 gear > (Specifically their E-Series and C-Series)? They came and did their > whole dog and pony show today, but I wanted to get real-world feedback > on their gear. shameless-plug=on Hi, You may want to consider asking on force10-nsp as well. http://puck.nether.net/mailman/listinfo/force10-nsp - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From cscora at apnic.net Fri Aug 22 13:08:11 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Aug 2008 04:08:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200808221808.m7MI8Bh6007358@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 23 Aug, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 266564 Prefixes after maximum aggregation: 129847 Deaggregation factor: 2.05 Unique aggregates announced to Internet: 129767 Total ASes present in the Internet Routing Table: 29013 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25251 Origin ASes announcing only one prefix: 12229 Transit ASes present in the Internet Routing Table: 3762 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: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 571 Unregistered ASNs in the Routing Table: 212 Number of 32-bit ASNs allocated by the RIRs: 58 Prefixes from 32-bit ASNs in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 765 Number of addresses announced to Internet: 1893845344 Equivalent to 112 /8s, 225 /16s and 201 /24s Percentage of available address space announced: 51.1 Percentage of allocated address space announced: 62.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.2 Total number of prefixes smaller than registry allocations: 130756 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 61188 Total APNIC prefixes after maximum aggregation: 22742 APNIC Deaggregation factor: 2.69 Prefixes being announced from the APNIC address blocks: 58158 Unique aggregates announced from the APNIC address blocks: 26203 APNIC Region origin ASes present in the Internet Routing Table: 3337 APNIC Prefixes per ASN: 17.43 APNIC Region origin ASes announcing only one prefix: 879 APNIC Region transit ASes present in the Internet Routing Table: 514 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 372857376 Equivalent to 22 /8s, 57 /16s and 90 /24s Percentage of available APNIC address space announced: 79.4 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: 122269 Total ARIN prefixes after maximum aggregation: 65261 ARIN Deaggregation factor: 1.87 Prefixes being announced from the ARIN address blocks: 91444 Unique aggregates announced from the ARIN address blocks: 34942 ARIN Region origin ASes present in the Internet Routing Table: 12396 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4764 ARIN Region transit ASes present in the Internet Routing Table: 1180 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 17 Number of ARIN addresses announced to Internet: 360765536 Equivalent to 21 /8s, 128 /16s and 216 /24s Percentage of available ARIN address space announced: 74.1 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: 57552 Total RIPE prefixes after maximum aggregation: 34846 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 52673 Unique aggregates announced from the RIPE address blocks: 35376 RIPE Region origin ASes present in the Internet Routing Table: 11754 RIPE Prefixes per ASN: 4.48 RIPE Region origin ASes announcing only one prefix: 6181 RIPE Region transit ASes present in the Internet Routing Table: 1797 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 369446912 Equivalent to 22 /8s, 5 /16s and 80 /24s Percentage of available RIPE address space announced: 84.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: 20959 Total LACNIC prefixes after maximum aggregation: 5284 LACNIC Deaggregation factor: 3.97 Prefixes being announced from the LACNIC address blocks: 19219 Unique aggregates announced from the LACNIC address blocks: 10731 LACNIC Region origin ASes present in the Internet Routing Table: 986 LACNIC Prefixes per ASN: 19.49 LACNIC Region origin ASes announcing only one prefix: 325 LACNIC Region transit ASes present in the Internet Routing Table: 168 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 54552832 Equivalent to 3 /8s, 64 /16s and 105 /24s Percentage of available LACNIC address space announced: 54.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: 4024 Total AfriNIC prefixes after maximum aggregation: 1236 AfriNIC Deaggregation factor: 3.26 Prefixes being announced from the AfriNIC address blocks: 4368 Unique aggregates announced from the AfriNIC address blocks: 1935 AfriNIC Region origin ASes present in the Internet Routing Table: 250 AfriNIC Prefixes per ASN: 17.47 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 52 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12627712 Equivalent to 0 /8s, 192 /16s and 175 /24s Percentage of available AfriNIC address space announced: 37.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 1703 537 179 Videsh Sanchar Nigam Ltd. Aut 17488 1334 88 101 Hathway IP Over Cable Interne 9583 1184 93 496 Sify Limited 4766 868 6407 355 Korea Telecom (KIX) 4134 835 13521 338 CHINANET-BACKBONE 23577 823 35 698 Korea Telecom (ATM-MPLS) 4780 715 353 61 Digital United Inc. 18101 693 167 33 Reliance Infocom Ltd Internet 9498 675 291 54 BHARTI BT INTERNET LTD. 4808 618 1112 137 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 6389 3200 3358 207 bellsouth.net, inc. 209 2881 3857 620 Qwest 6298 1981 319 726 Cox Communicatons 1785 1647 710 155 AppliedTheory Corporation 2386 1505 692 900 AT&T Data Communications Serv 4323 1495 1073 376 Time Warner Telecom 7018 1410 5816 983 AT&T WorldNet Services 11492 1214 151 22 Cable One 6478 1114 237 174 AT&T Worldnet Services 20115 1113 1080 576 Charter 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 414 1776 372 TDC Tele Danmark 3215 396 2756 106 France Telecom Transpac 8452 354 188 11 TEDATA 3301 333 1444 304 TeliaNet Sweden 3320 323 7047 271 Deutsche Telekom AG 8866 316 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 288 270 38 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 6746 270 126 244 Dynamic Network Technologies, 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 1520 2592 225 UniNet S.A. de C.V. 11830 664 299 9 Instituto Costarricense de El 22047 563 270 14 VTR PUNTO NET S.A. 7303 477 235 67 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 420 85 48 ENTEL CHILE S.A. 11172 409 118 72 Servicios Alestra S.A de C.V 10620 383 102 74 TVCABLE BOGOTA 14117 345 23 9 Telefonica del Sur S.A. 28573 325 440 28 NET Servicos de Comunicao S.A 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 497 64 29 LINKdotNET AS number 20858 402 34 3 EgyNet 3741 273 857 226 The Internet Solution 2018 224 213 131 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 136 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 118 539 70 Telkom SA Ltd 33776 115 6 3 Starcomms Nigeria Limited 29571 107 13 8 Ci Telecom Autonomous system 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 3200 3358 207 bellsouth.net, inc. 209 2881 3857 620 Qwest 6298 1981 319 726 Cox Communicatons 4755 1703 537 179 Videsh Sanchar Nigam Ltd. Aut 1785 1647 710 155 AppliedTheory Corporation 8151 1520 2592 225 UniNet S.A. de C.V. 2386 1505 692 900 AT&T Data Communications Serv 4323 1495 1073 376 Time Warner Telecom 7018 1410 5816 983 AT&T WorldNet Services 17488 1334 88 101 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 209 2881 2261 Qwest 4755 1703 1524 Videsh Sanchar Nigam Ltd. Aut 1785 1647 1492 AppliedTheory Corporation 8151 1520 1295 UniNet S.A. de C.V. 6298 1981 1255 Cox Communicatons 17488 1334 1233 Hathway IP Over Cable Interne 11492 1214 1192 Cable One 4323 1495 1119 Time Warner Telecom 18566 1045 1035 Covad Communications 6478 1114 940 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 7018 AT&T WorldNet Servic 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 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.53.86.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.55.0.0/18 20001 HoldCo LLC - Road Runner 24.75.160.0/19 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 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:17 /11:45 /12:146 /13:293 /14:530 /15:1058 /16:10041 /17:4382 /18:7591 /19:16021 /20:18706 /21:18315 /22:23079 /23:24200 /24:139428 /25:839 /26:1022 /27:718 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2037 3200 bellsouth.net, inc. 6298 1954 1981 Cox Communicatons 209 1647 2881 Qwest 11492 1195 1214 Cable One 2386 1184 1505 AT&T Data Communications Serv 17488 1142 1334 Hathway IP Over Cable Interne 1785 1116 1647 AppliedTheory Corporation 4755 1043 1703 Videsh Sanchar Nigam Ltd. Aut 9583 1040 1184 Sify Limited 6478 1027 1114 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:134 12:2126 13:2 15:22 16:3 17:5 18:13 20:35 24:1085 32:59 38:496 40:92 41:700 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:529 59:512 60:453 61:983 62:1212 63:2052 64:3236 65:2362 66:3436 67:1228 68:776 69:2298 70:860 71:135 72:2012 73:6 74:1117 75:165 76:313 77:765 78:820 79:228 80:975 81:871 82:586 83:378 84:573 85:990 86:402 87:719 88:339 89:1314 90:34 91:1414 92:255 93:793 94:75 96:57 97:60 98:312 99:3 114:96 115:33 116:971 117:337 118:197 119:460 120:74 121:584 122:819 123:380 124:846 125:1186 128:353 129:202 130:135 131:409 132:70 133:9 134:188 135:33 136:223 137:94 138:141 139:93 140:506 141:103 142:406 143:311 144:404 145:51 146:373 147:156 148:517 149:199 150:128 151:183 152:144 153:136 154:10 155:281 156:171 157:288 158:165 159:251 160:272 161:131 162:264 163:156 164:517 165:458 166:361 167:332 168:623 169:141 170:430 171:33 172:10 173:16 188:1 189:488 190:2081 192:5800 193:4133 194:3251 195:2566 196:1025 198:3734 199:3307 200:5535 201:1523 202:7660 203:8074 204:3953 205:2149 206:2369 207:2759 208:3515 209:3435 210:2597 211:1079 212:1423 213:1619 214:180 215:50 216:4379 217:1205 218:345 219:429 220:1060 221:455 222:311 End of report From matthew at eeph.com Fri Aug 22 16:24:18 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 22 Aug 2008 14:24:18 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <20080818170922.GB10900@cgi.jachomes.com> References: <20080818170922.GB10900@cgi.jachomes.com> Message-ID: <48AF2E82.3090602@eeph.com> Jay R. Ashworth wrote: > http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html > > Well, on reading it, it's more an "IPv6: It's great -- ask for > it by name!" piece. > This article reminded me that I really needed to stop relying on a tunnel over my backup DSL line for IPv6 and spend the time to get my own ISP on the road to deploying IPv6. Step 1: Request address space from ARIN Took <1 day to get a reply that we'd be getting the space that day, a few more hours to receive a /32. That was easy. Step 2: Get set up for IPv6 peering and transit Took 30 minutes for Equinix to tell me that all I need to do is fill out a form and I'm all set. Even quicker than ARIN. Took a little over 2 days for my transit provider (Abovenet) to tell me that they don't offer IPv6 transit and don't know when they will. Native IPv6 isn't important enough for me to spend money on a new transit provider on yet, so I guess maybe next year we'll try this again and see what's changed. In the meantime, I need to upgrade some routers (including some that went EOL before IPv6 support came along) anyway. Matthew Kaufman http://www.matthew.at From charles at thewybles.com Fri Aug 22 16:45:24 2008 From: charles at thewybles.com (Charles Wyble) Date: Fri, 22 Aug 2008 14:45:24 -0700 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AF2E82.3090602@eeph.com> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> Message-ID: <48AF3374.2020702@thewybles.com> Matthew Kaufman wrote: > Jay R. Ashworth wrote: >> http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html >> >> > > This article reminded me that I really needed to stop relying on a > tunnel over my backup DSL line for IPv6 and spend the time to get my > own ISP on the road to deploying IPv6. > > Step 1: Request address space from ARIN > > Took <1 day to get a reply that we'd be getting the space that day, a > few more hours to receive a /32. That was easy. Did you have existing IPv4 space with ARIN? If so, I have to wonder if I would get the same speedy service from ARIN as a new entrant without existing ipv4 space? :) I'm looking at building a large network with Ipv6 in the Los Angeles metro area, to serve a number of small businesses via a large scale wireless network. Essentially a large scale private WAN, with globally routable addresses (for a VoIP/IPTV roll out later) So I'm not exactly a traditional ISP or colocation customer, but share characteristics with them. Does this matter? Should I just submit my request and see what happens? -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From jra at baylink.com Fri Aug 22 17:39:52 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 22 Aug 2008 18:39:52 -0400 Subject: Native v6 with Level(3)? In-Reply-To: <48AF2E82.3090602@eeph.com> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> Message-ID: <20080822223952.GC14582@cgi.jachomes.com> On Fri, Aug 22, 2008 at 02:24:18PM -0700, Matthew Kaufman wrote: > Jay R. Ashworth wrote: > >http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html > > > >Well, on reading it, it's more an "IPv6: It's great -- ask for > >it by name!" piece. > > > > This article reminded me that I really needed to stop relying on a > tunnel over my backup DSL line for IPv6 and spend the time to get my own > ISP on the road to deploying IPv6. Well, funny you should say that. I'm a masochist, so next week, I'm going to look into getting L3 to extend native IPv6 down my 10Mb/s uplink. My edge machines are Linux 2.6.mumble, but the one that faces L3 is at the end of another 10Mb/s tail circuit to me from a colo cage, so it's going to be Even More Fun. Has anyone already done the Edge IPv6 dance with L3? 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. -- (Josef Stalin) From jlewis at lewis.org Fri Aug 22 17:54:45 2008 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 22 Aug 2008 18:54:45 -0400 (EDT) Subject: Native v6 with Level(3)? In-Reply-To: <20080822223952.GC14582@cgi.jachomes.com> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> Message-ID: On Fri, 22 Aug 2008, Jay R. Ashworth wrote: > Has anyone already done the Edge IPv6 dance with L3? I've been meaning to do this too for some time...only our GigE circuit to L3 was going into cisco gear with no v6 support. We moved the circuit recently to a Sup720-3bxl...so in theory, we should be able to turn up v6 with them. How painful should that be? We do already have our own v6 /32 and of course are doing ipv4 BGP with them. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kyle at forest.net Fri Aug 22 18:22:41 2008 From: kyle at forest.net (Kyle Murray) Date: Fri, 22 Aug 2008 16:22:41 -0700 Subject: Native v6 with Level(3)? In-Reply-To: References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> Message-ID: <48AF4A41.8050107@forest.net> Here is the response I got from L3 when I inquired about IPV6: "The answer to your questions is "no", we have not yet inplemented IPV6 for our customers yet. IPV4 is the de facto on our backbone nad alledge router on which customers connectc." Poor spelling aside, it seems they have not implemented it yet. If someone manages to get them to implement, I would really like to hear about it. -kyle Kyle Murray Network Manager Digital Forest, Inc. Jon Lewis wrote: > On Fri, 22 Aug 2008, Jay R. Ashworth wrote: > >> Has anyone already done the Edge IPv6 dance with L3? > > I've been meaning to do this too for some time...only our GigE circuit > to L3 was going into cisco gear with no v6 support. We moved the > circuit recently to a Sup720-3bxl...so in theory, we should be able to > turn up v6 with them. How painful should that be? We do already have > our own v6 /32 and of course are doing ipv4 BGP with them. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From craigp at tozz.net Fri Aug 22 18:51:08 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Fri, 22 Aug 2008 17:51:08 -0600 Subject: Native v6 with Level(3)? In-Reply-To: <48AF4A41.8050107@forest.net> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> Message-ID: <3D830665-F64E-4C94-83ED-F35DDC181ED5@tozz.net> No native service available but there is a trial tunneled IPv6 service with best effort support with *no SLA* available to current Level 3 Internet customers. IPv6 is currently being provided via IPv4 tunnels to the customer's existing router and supported by a handful of engineers. There is a simple service agreement addendum and form to fill out for relevant config bits. -Craig On Aug 22, 2008, at 5:22 PM, Kyle Murray wrote: > Here is the response I got from L3 when I inquired about IPV6: > > "The answer to your questions is "no", we have not yet inplemented > IPV6 for our customers yet. IPV4 is the de facto on our backbone > nad alledge router on which customers connectc." > > Poor spelling aside, it seems they have not implemented it yet. If > someone manages to get them to implement, I would really like to > hear about it. > > -kyle > > Kyle Murray > Network Manager > Digital Forest, Inc. From justin at justinshore.com Fri Aug 22 19:57:42 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 22 Aug 2008 19:57:42 -0500 Subject: Native v6 with Level(3)? In-Reply-To: <3D830665-F64E-4C94-83ED-F35DDC181ED5@tozz.net> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> <3D830665-F64E-4C94-83ED-F35DDC181ED5@tozz.net> Message-ID: <48AF6086.1030406@justinshore.com> That's good to know. Do you know if there are any rate-limits that would apply to this trial service? Any idea where the tunnel head-end is? Will they do a backup tunnel to another router? I'll have to give them a holler as soon as I'm ready to make the IPv6 jump. Thanks Justin Craig Pierantozzi wrote: > No native service available but there is a trial tunneled IPv6 service > with best effort support with *no SLA* available to current Level 3 > Internet customers. IPv6 is currently being provided via IPv4 tunnels > to the customer's existing router and supported by a handful of engineers. > > There is a simple service agreement addendum and form to fill out for > relevant config bits. > > -Craig > > On Aug 22, 2008, at 5:22 PM, Kyle Murray wrote: > >> Here is the response I got from L3 when I inquired about IPV6: >> >> "The answer to your questions is "no", we have not yet inplemented >> IPV6 for our customers yet. IPV4 is the de facto on our backbone nad >> alledge router on which customers connectc." >> >> Poor spelling aside, it seems they have not implemented it yet. If >> someone manages to get them to implement, I would really like to hear >> about it. >> >> -kyle >> >> Kyle Murray >> Network Manager >> Digital Forest, Inc. > > From tozz at tozz.net Fri Aug 22 21:14:31 2008 From: tozz at tozz.net (Craig Pierantozzi) Date: Fri, 22 Aug 2008 22:14:31 -0400 Subject: Native v6 with Level(3)? In-Reply-To: <48AF6086.1030406@justinshore.com> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> <3D830665-F64E-4C94-83ED-F35DDC181ED5@tozz.net> <48AF6086.1030406@justinshore.com> Message-ID: <20080823021431.GA19460@eagle.deardorff.com> No rate limits, tunnel termination in DC, San Jose, Dallas, Amsterdam, London. You can request termination to multiple routers for diversity. * Justin Shore was thought to have said: > That's good to know. Do you know if there are any rate-limits that > would apply to this trial service? Any idea where the tunnel head-end > is? Will they do a backup tunnel to another router? I'll have to give > them a holler as soon as I'm ready to make the IPv6 jump. From nanog at ian.co.uk Sat Aug 23 20:41:16 2008 From: nanog at ian.co.uk (Ian Mason) Date: Sun, 24 Aug 2008 02:41:16 +0100 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <9494DF2B-66BF-496F-9E0F-759D2832905B@muada.com> References: <48AB73E3.8090908@psg.com> <7E865F2B-5F4A-47A2-8A10-3DF3716C4B2B@muada.com> <48AC0144.8C45.0097.0@globalstar.com> <48AC0F0D.8C45.0097.0@globalstar.com> <9494DF2B-66BF-496F-9E0F-759D2832905B@muada.com> Message-ID: <8BD31EC1-0FC6-485F-BD30-9B4531A11957@ian.co.uk> On 21 Aug 2008, at 09:09, Iljitsch van Beijnum wrote: > On 20 aug 2008, at 21:33, Crist Clark wrote: > >> No, that's my point. On a true point-to-point link, there is >> only one other address on the link. That's what point-to-point >> means. > >> For example, on the IPv4 ends gif(4) tunnel in my previous message, > >> >> gif0: flags=8051 metric 0 mtu 1280 >> tunnel inet 24.6.175.101 --> 72.52.104.74 >> inet6 fe80::200:24ff:feca:91b4%gif0 prefixlen 64 scopeid 0x7 >> inet6 2001:470:1f04:2fc::2 --> 2001:470:1f04:2fc::1 >> prefixlen 128 > > Note that this interface doesn't _have_ any IPv4 addresses: the > IPv4 addresses that you see are the tunnel endpoints. > > However, the IPv6 addresses do what you say: there is a local one > and a remote one and they don't share a subnet. Obviously it's > possible to do this, but in my opinion, this is just an > implementation variation, not the natural state of point-to-point > links. It makes much more sense to have one set of behaviors that > applies to all interfaces. > > And what is a point-to-point link, anyway? In theory gigabit > ethernet is CSMA/CD, but I don't think anyone ever bothered to > implement that, in practice it's point-to-point on layer 1, but > layer 2 is point-to-multipoint... > > 1000BASE-PX10 and 1000BASE-PX20 are both point to multipoint at layer 1. From pauldotwall at gmail.com Sun Aug 24 00:52:55 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Sun, 24 Aug 2008 01:52:55 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> Message-ID: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> On Fri, Aug 22, 2008 at 10:34 AM, Matlock, Kenneth L wrote: > Sorry for the off-topic post. Don't be; it was acutely on-topic. > Does anyone here have real-world experience with Force 10 gear > (Specifically their E-Series and C-Series)? They came and did their > whole dog and pony show today, but I wanted to get real-world feedback > on their gear. > > > > I need to know about their > > > > 1) Reliability > > 2) Performance EANTC did a comprehensive study of the E-series: http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_failover_video_ftos_6211.html http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/EANTC_Full_Report.pdf http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/Section_8.pdf > 3) Support staff (how knowledgeable are they?) I'm not a customer, so I can't speak to this. > 4) Price (higher/lower/comparable to comparable Cisco gear) Comparing list pricing, it looks like Force 10 would have you pay more for less features. As a box designed with the enterprise datacenter in mind, the E-series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing. http://www.force10networks.com/news/pressreleases/2007/pr-2007-02-05.asp https://www.force10networks.com/CSPortal20/KnowledgeBase/DOCUMENTATION/CLIConfig/FTOS/E_CONFIG_6.5.4.0_7-Feb-08.pdf Paul From Joel.Snyder at Opus1.COM Sun Aug 24 09:11:37 2008 From: Joel.Snyder at Opus1.COM (Joel Snyder) Date: Sun, 24 Aug 2008 07:11:37 -0700 Subject: Force10 Gear - Opinions In-Reply-To: References: Message-ID: <48B16C19.5020004@opus1.com> > Subject: Force10 Gear - Opinions > > Does anyone here have real-world experience with Force 10 gear > (Specifically their E-Series and C-Series)? They came and did their > whole dog and pony show today, but I wanted to get real-world feedback > on their gear. I was at a customer site doing a NAC deployment study recently ( <6 months ago) and there was some Force10 edge gear in place. We had to drop the Force10 gear out of the picture because it didn't support any of the rich features that we needed to get NAC up and running. The customer was perfectly happy with the ability of the stuff to pass packets and act as a not-very-smart edge switch, and hadn't evaluated the feature set for anything beyond that. My conclusion was that if you want to use it at the edge to pass a lot of packets at 'enterprise' line rates and don't care about anything else (we were looking at good 802.1X support with ACLs and all of the other miscellaneous bits that make NAC work, YMMV) then it seems to be fine per this customer's experience. If you want something with a stronger feature set for future expansion, there seem to be other companies that have more experience. In David Newman's test of 10G edge switches (http://www.networkworld.com/reviews/2008/032408-switch-test.html) Force10 elected not to participate, which is often telling. jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From tomb at byrneit.net Mon Aug 25 01:21:23 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 24 Aug 2008 23:21:23 -0700 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808212006370.32BF5B92.10507@clifden.donelan.com> References: <86tzdmzcv3.fsf@seastrom.com><70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org><48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net><2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> <200808212006370.32BF5B92.10507@clifden.donelan.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a site hosted in such IP space. So, Bogon filtering has value beyond mere spoofed source rejection. > -----Original Message----- > From: Sean Donelan [mailto:sean at donelan.com] > Sent: Thursday, August 21, 2008 5:19 PM > To: NANOG list > Subject: Re: Is it time to abandon bogon prefix filters? > > On Mon, 18 Aug 2008, Danny McPherson wrote: > > All the interesting attacks today that employ spoofing (and the > > majority of the less-interesting ones that employ spoofing) are > > usually relying on existence of the source as part of the attack > > vector (e.g., DNS cache poisoning, BGP TCP RST attacks, DNS > reflective > > amplification attacks, etc..), and as a result, loose mode > gives folks > > a false sense of protection/action. > > Yep. Same thing with bogon filters. Any attacker which can > source packets with bogon addresses, can by definition, > source packets with any "valid" IP address too. Great as an > academic exercise, but the bad guys are going to send evil > packets without the evil bit nor using bogon addresses. If > the bad guys are using spoofed addresses, they don't care > about the reply packets to either valid or unallocated addresses. > > However, seeing packets with unallocated IP addresses on the > Internet is evidence of a broken network. Just like when a > network trips "max prefix" on a BGP session, shouldn't a > broken network be shutdown until the problem is fixed. If > you don't want to risk your network peers turning off the > connections, make sure your network doesn't source spoofed packets. > > > From ahmed at simula.no Mon Aug 25 05:16:33 2008 From: ahmed at simula.no (ahmed at simula.no) Date: Mon, 25 Aug 2008 12:16:33 +0200 (CEST) Subject: BGP Timers Configuration Message-ID: <3071.194.209.131.192.1219659393.squirrel@webmail.uio.no> Folks, We are pursuing some work along the lines of studying BGP scalability in terms of churn evolution. One of the key mechanisms used by BGP to dampen the churn is the MRAI timer (Minimum Route Advertisement Interval). >From different vendors' specifications we find that: 1- Cisco enables MRAI by default for both route announcements and route withdrawals. 2- Juniper has a similar parameter called out-delay which is disabled by default. Of course these are default configurations, and we don't know if ISPs use them without any change. We would appreciate any input on the following questions: A- Is it common that ISPs change MRAI default configurations? If yes, then what decides the MRAI settings for both e-BGP and i-BGP sessions? B- Does anybody use a configuration where only route announcements are rate limited, and not explicit route withdrawals? C- Are there configurations where rate limiting is applied only to a subset of session? Best regards, Ahmed Elmokashfi Simula Research Laboratory. From fernando at gont.com.ar Mon Aug 25 05:27:34 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 25 Aug 2008 07:27:34 -0300 Subject: IP Fragmentation In-Reply-To: <48AC959A.7030203@spacething.org> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20580.1219255453@turing-police.cc.vt.edu> <010F38F3-2B20-4707-9A29-0950D61C9CC5@muada.com> <48AC959A.7030203@spacething.org> Message-ID: <200808251035.m7PAZtXv003025@venus.xmundo.net> At 07:07 p.m. 20/08/2008, Sam Stickland wrote: >>Yet all OSes have it enabled and there is no fallback to >>fragmentation in PMTUD: if your system doesn't get the ICMP >>messages, your session is dead in the water. >Windows Vista/2007 has black hole detection enabled by default. It's >not massively elegant, but it will keep sessions up (falls back to >536 byte MTU). > >http://support.microsoft.com/kb/925280 IPv4 minimum MTU is 68 bytes, not 536. 536 is the minimum fragment re-assembly buffer size. Falling back to 536-byte packets does not guarantee that sessions will be kept up. Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch at muada.com Mon Aug 25 05:56:34 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 25 Aug 2008 12:56:34 +0200 Subject: IP Fragmentation In-Reply-To: <200808251035.m7PAZtXv003025@venus.xmundo.net> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20580.1219255453@turing-police.cc.vt.edu> <010F38F3-2B20-4707-9A29-0950D61C9CC5@muada.com> <48AC959A.7030203@spacething.org> <200808251035.m7PAZtXv003025@venus.xmundo.net> Message-ID: On 25 aug 2008, at 12:27, Fernando Gont wrote: >> http://support.microsoft.com/kb/925280 > IPv4 minimum MTU is 68 bytes, That's kind of like "a human being can live without food for four to six weeks". It's not a recommendation. > 536 is the minimum fragment re-assembly buffer size. Falling back to > 536-byte packets does not guarantee that sessions will be kept up. But: "PMTU black hole router detection is triggered on a TCP connection when TCP starts retransmitting full-sized segments with the DF flag set. TCP resets the PTMU for the connection to 536 bytes. Then, TCP retransmits its segments when the DF flag is clear." From rekordmeister at gmail.com Mon Aug 25 07:34:00 2008 From: rekordmeister at gmail.com (MKS) Date: Mon, 25 Aug 2008 12:34:00 +0000 Subject: YAOTM Message-ID: Yet another of topic message;) I'm looking for IP transit in Newfoundland, since I'm not familiar with that territory, I was hoping that someone could message me offline for available options. Regards MKS From Valdis.Kletnieks at vt.edu Mon Aug 25 08:32:45 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Aug 2008 09:32:45 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: Your message of "Sun, 24 Aug 2008 23:21:23 PDT." <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> <200808212006370.32BF5B92.10507@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> Message-ID: <12441.1219671165@turing-police.cc.vt.edu> On Sun, 24 Aug 2008 23:21:23 PDT, "Tomas L. Byrnes" said: > You're missing one of the basic issues with bogon sources: they are > often advertised bogons, IE the bad guy DOES care about getting the > packets back, and has, in fact, created a way to do so. But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore? At that point, you're not worrying about bogon filtering, you're worrying about sanity-checking what BGP advertisements you accept. Also a worthy thing to do, but different from bogon filtering. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From cmarlatt at rxsec.com Mon Aug 25 08:38:00 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Mon, 25 Aug 2008 09:38:00 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <12441.1219671165@turing-police.cc.vt.edu> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> <200808212006370.32BF5B92.10507@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> <12441.1219671165@turing-police.cc.vt.edu> Message-ID: <48B2B5B8.9000707@rxsec.com> Valdis.Kletnieks at vt.edu wrote: > On Sun, 24 Aug 2008 23:21:23 PDT, "Tomas L. Byrnes" said: >> You're missing one of the basic issues with bogon sources: they are >> often advertised bogons, IE the bad guy DOES care about getting the >> packets back, and has, in fact, created a way to do so. > > But if you've seen a BGP announcement with a prefix that covers the source, > is it really a bogon anymore? > IIRC "bogon" is specific to unallocated space. Whether it be advertised or not should not matter. Regards, Chris From jared at puck.nether.net Mon Aug 25 09:22:28 2008 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Aug 2008 10:22:28 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <200808211955080.32BF5B92.10438@clifden.donelan.com> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48AAE836.5050002@kl.net> <200808211955080.32BF5B92.10438@clifden.donelan.com> Message-ID: <20080825142228.GF363@puck.nether.net> On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: > On Tue, 19 Aug 2008, Kevin Loch wrote: >>> While you're at it, you also placed the reachable-via rx on >>> all your customer interfaces. If you're paranoid, start with the 'any' >>> rpf and then move to the strict rpf. The strict rpf also helps with >>> routing loops. >> >> Be careful not to enable strict rpf on multihomed customers. This includes >> any bgp customer unless you know for sure they are single homed to you >> and that will not >> change. > > Isn't it time to change the assumption that sending arbitrary source IP > addresses without checking is Ok? > > Unless the customer has specifically told their ISP about all the IP > addresses they intend to use as source IP addresses, shouldn't the > default be to drop those packets. > > If those multi-homed customers have not told their upstream ISPs about > additional source IP addresses (hopefully also registered/authorized for > use by the same customer) why can they still send packets with those > source addresses? Instead shouldn't you say "Be careful if you are a > using source IP addresses without informing your upstream." > > In practice, how many multi-homed customers send packets with unannounced > source IP addresses? And for those customers which do, why is the ISP > unable to implement any of the alternative source IP checking options, > such as using a ACL with uRPF or on the interface? I certainly believe that this is the trap people fall into. I can't manage it, nor do I want to spend the effort telling my provider, peer, etc.. that I stole their customer from them, so I'm better off making the global network less secure. With all the concern about DNS cache integrity, network abuse, etc.. networks that are not taking afirmative action to implement better policies, systems are going to continue to lower their overall value. If you think I'm wrong, I do suggest you sit back and ignore your network and customers further. When they are unable to trust your network to deliver the correct response to a dns query, they will ask for credits and will leave. If I were any sort of a bank, I would insist that my provider take actions to prevent my customers from being redirected to a phishing site. The interesting thing is the effort put into dns patching, dnssec, etc.. could all be helped by the networks doing u-rpf. Not 100% mitigated against, but the difference would be huge. this is no longer a ddos issue of people spoofing packets. That's gone, it's easier to take over a million desktops with malware than one on a fe/ge. But the ability to use those machines to brute-force or reconfigure the resolver settings to someplace bad, that risk is truly tangible and possibly severely disruptive to the industry. If I can't trust that I am reaching my bank, email, etc.. what impact will that have? If you've not factored these things into your business process, hardware acquisition, I think you will end up with a bad situation. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From tme at multicasttech.com Mon Aug 25 09:28:40 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 25 Aug 2008 10:28:40 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <20080825142228.GF363@puck.nether.net> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <48AAE836.5050002@kl.net> <200808211955080.32BF5B92.10438@clifden.donelan.com> <20080825142228.GF363@puck.nether.net> Message-ID: On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote: > On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: >> On Tue, 19 Aug 2008, Kevin Loch wrote: >>>> While you're at it, you also placed the reachable-via rx on >>>> all your customer interfaces. If you're paranoid, start with the >>>> 'any' >>>> rpf and then move to the strict rpf. The strict rpf also helps >>>> with >>>> routing loops. >>> >>> Be careful not to enable strict rpf on multihomed customers. This >>> includes >>> any bgp customer unless you know for sure they are single homed to >>> you >>> and that will not >>> change. >> >> Isn't it time to change the assumption that sending arbitrary >> source IP >> addresses without checking is Ok? >> >> Unless the customer has specifically told their ISP about all the IP >> addresses they intend to use as source IP addresses, shouldn't the >> default be to drop those packets. >> >> If those multi-homed customers have not told their upstream ISPs >> about >> additional source IP addresses (hopefully also registered/ >> authorized for >> use by the same customer) why can they still send packets with those >> source addresses? Instead shouldn't you say "Be careful if you are a >> using source IP addresses without informing your upstream." >> >> In practice, how many multi-homed customers send packets with >> unannounced >> source IP addresses? And for those customers which do, why is the >> ISP >> unable to implement any of the alternative source IP checking >> options, >> such as using a ACL with uRPF or on the interface? > > I certainly believe that this is the trap people fall into. > > I can't manage it, nor do I want to spend the effort telling > my provider, peer, etc.. that I stole their customer from them, so > I'm better off making the global network less secure. > > With all the concern about DNS cache integrity, network abuse, etc.. > networks that are not taking afirmative action to implement better > policies, > systems are going to continue to lower their overall value. > > If you think I'm wrong, I do suggest you sit back and ignore your > network and customers further. When they are unable to trust your > network > to deliver the correct response to a dns query, they will ask for > credits > and will leave. If I were any sort of a bank, I would insist that > my provider > take actions to prevent my customers from being redirected to a > phishing > site. The interesting thing is the effort put into dns patching, > dnssec, etc.. > could all be helped by the networks doing u-rpf. Not 100% mitigated > against, but > the difference would be huge. > > this is no longer a ddos issue of people spoofing packets. That's > gone, it's easier to take over a million desktops with malware than > one > on a fe/ge. But the ability to use those machines to brute-force or > reconfigure > the resolver settings to someplace bad, that risk is truly tangible > and > possibly severely disruptive to the industry. If I can't trust that > I am > reaching my bank, email, etc.. what impact will that have? My Bank (Bank of America) put in something to mitigate against this about 2 years ago (IIRC), so they were clearly anticipating something like this. Not only do you have to verify that you are you, you also have to verify that the bank is the bank. Regards Marshall > > > If you've not factored these things into your business process, > hardware acquisition, I think you will end up with a bad situation. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are > only mine. > From Valdis.Kletnieks at vt.edu Mon Aug 25 10:08:03 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Aug 2008 11:08:03 -0400 Subject: Is it time to abandon bogon prefix filters? In-Reply-To: Your message of "Mon, 25 Aug 2008 09:38:00 EDT." <48B2B5B8.9000707@rxsec.com> References: <86tzdmzcv3.fsf@seastrom.com> <70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org> <48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net> <2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> <200808212006370.32BF5B92.10507@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> <12441.1219671165@turing-police.cc.vt.edu> <48B2B5B8.9000707@rxsec.com> Message-ID: <18794.1219676883@turing-police.cc.vt.edu> On Mon, 25 Aug 2008 09:38:00 EDT, Chris Marlatt said: > IIRC "bogon" is specific to unallocated space. Whether it be advertised > or not should not matter. Right. Tell that to everybody who's ever been at the wrong end of a bogon filter for 69/8, 70/8, 71/8... I'll go out on a limb and say that if you see a BGP announcement for a prefix you think is a bogon, it's *more* likely that the space is no longer unallocated and you didn't get the memo, than it's still unallocated but being pirated by somebody. (Which raises a question - what % of sites that are doing bogon filtering but *not* listening to something like Team Cymru's bogon feed? If it's nearly ubiquitous, it's not a big problem. But given the number of places that have problems with bogon filters, only a small percentage seem to be doing so...) At the point that you're doing bogon filtering, you have no way to disambiguate those two cases. Which is why I said it's a BGP announcement filtering issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jrhett at netconsonance.com Mon Aug 25 18:20:01 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 25 Aug 2008 16:20:01 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> Message-ID: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> On Aug 23, 2008, at 10:52 PM, Paul Wall wrote: > EANTC did a comprehensive study of the E-series: > > http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_failover_video_ftos_6211.html > > http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/EANTC_Full_Report.pdf > > http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/Section_8.pdf Did you read these? They appear to be nonsense. They were bought and paid for by Cisco, and including nonsense things like "if you leave a slot open the chassis will burn up" as a decrement, which is also true in pretty much every big iron vendor. They also deliberately detuned the force10 configuration. They re-ran the tests using the recommended configuration and got very different numbers -- which you can request from them, but they won't publish on the website. I'm not trying to be a Force10 advocate here (although I like their stuff) so much as trying to point at an incredibly biased and non- vendor-neutral report. It is entirely funny the amount they tried to make nonsensical stuff sound important. > Comparing list pricing, it looks like Force 10 would have you pay more > for less features. Based on what? For E and C series boxes, Cisco is never cheaper. S- series are a different story. > As a box designed with the enterprise datacenter in mind, the E-series > looks to be missing several key service provider features, including > MPLS and advanced control plane filtering/policing. Ah, because Cisco does either of these in hardware? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Mon Aug 25 18:26:55 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 25 Aug 2008 16:26:55 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> Message-ID: On Aug 22, 2008, at 7:34 AM, Matlock, Kenneth L wrote: > 1) Reliability Very good. Across our entire business we've lost 1 RPM module in ~2 years. > 2) Performance [Note: we have no 10g interfaces, so I can only speak to a many- singleg-port environment] Much higher than Cisco. So good at dealing with traffic problems that we have had multi-gig DoS attacks that we wouldn't have known about without having an IDS running on a mirroring port. > 3) Support staff (how knowledgeable are they?) Significantly higher than Cisco, and escalation is easier. On par with Juniper. > 4) Price (higher/lower/comparable to comparable Cisco gear) 80% of the Cisco of a comparable Cisco solution, and the support contracts are cheaper too. > We're exclusively a Cisco shop here right now (mostly Cat6500s), so > changing out some of our core gear with Force 10 is a bit 'scary', but > if it meets our needs, maybe... If you go from Juniper to Force10 you might find some things lacking, but Cisco to Force10 is only an improvement. You'll never have to wonder if the command you're typing will throw the unit into software routing mode, as Cisco bugs have usually done. (not possible in the FTOS architecture) These things are so very solid that I rarely spend any time doing network work any more. Gigabit line-speed BCP38 makes life easier for the abuse helpdesk too. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From rubensk at gmail.com Mon Aug 25 18:45:27 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Mon, 25 Aug 2008 20:45:27 -0300 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> Message-ID: <6bb5f5b10808251645kfcc045dq305503d6e8baae95@mail.gmail.com> >> 2) Performance > > [Note: we have no 10g interfaces, so I can only speak to a many-singleg-port > environment] > Much higher than Cisco. So good at dealing with traffic problems that we > have had multi-gig DoS attacks that we wouldn't have known about without > having an IDS running on a mirroring port. Do they have something with a few singleg-ports (could be only 2) but can route a large FIB (half a million, million routes) and some large RIBs (3 full-routing views, a hundred peers) ? Rubens From pfs at cisco.com Mon Aug 25 18:54:48 2008 From: pfs at cisco.com (Philip Smith) Date: Tue, 26 Aug 2008 09:54:48 +1000 Subject: [NANOG-announce] 2008 Elections Reminder... Message-ID: <48B34648.8090701@cisco.com> Hello everyone, Just a friendly reminder! Nominations for the NANOG Steering Committee, are due by Tuesday, 9th September. If you have not yet nominated someone and wish to do so, or if you have been asked to serve and have not yet accepted, please do so as soon as you can by sending a note to nominations at nanog.org. Please refer to the 2008 elections page at http://www.nanog.org/elections08.html for more information. IMPORTANT DATES Tue 2008-08-12 Call for Nominations issued Tue 2008-09-09 Last day for SC Nominations to be received Sun 2008-10-12 Voting for the 2008/2008 NANOG SC opens at Noon PDT Tue 2008-10-14 Voting for the 2008/2009 NANOG SC closes at 1 pm PDT Best wishes, Philip Smith (on behalf of the NANOG Steering Committee) -- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From marka at isc.org Mon Aug 25 19:39:03 2008 From: marka at isc.org (Mark Andrews) Date: Tue, 26 Aug 2008 10:39:03 +1000 (EST) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: Message-ID: <200808260039.m7Q0d3nM039376@drugs.dv.isc.org> In article you write: > >On Aug 25, 2008, at 10:22 AM, Jared Mauch wrote: > >> On Thu, Aug 21, 2008 at 08:03:19PM -0400, Sean Donelan wrote: >> >> With all the concern about DNS cache integrity, network abuse, etc.. >> networks that are not taking afirmative action to implement better >> policies, >> systems are going to continue to lower their overall value. >> >> If you think I'm wrong, I do suggest you sit back and ignore your >> network and customers further. When they are unable to trust your >> network >> to deliver the correct response to a dns query, they will ask for >> credits >> and will leave. If I were any sort of a bank, I would insist that >> my provider >> take actions to prevent my customers from being redirected to a >> phishing >> site. The interesting thing is the effort put into dns patching, >> dnssec, etc.. >> could all be helped by the networks doing u-rpf. Not 100% mitigated >> against, but >> the difference would be huge. >> >> this is no longer a ddos issue of people spoofing packets. That's >> gone, it's easier to take over a million desktops with malware than >> one >> on a fe/ge. But the ability to use those machines to brute-force or >> reconfigure >> the resolver settings to someplace bad, that risk is truly tangible >> and >> possibly severely disruptive to the industry. If I can't trust that >> I am >> reaching my bank, email, etc.. what impact will that have? > >My Bank (Bank of America) put in something to mitigate against this >about 2 years ago (IIRC), so they >were clearly anticipating something like this. Not only do you have to >verify that you are you, you >also have to verify that the bank is the bank. > >Regards >Marshall While some people with some protocols have solutions to detect when the communication path has been compromised. Not all people with all protocols have a solution to this problem. There is no panecea to this problem, however *everyone* should do their best to reduce the problem. Any operator not implemting BCP 38 is potentially aiding and abetting some criminal. BCP 38 is over 10 years old. There is no excuse for not having equipment in place to handle the processing needs of BCP 38. Mark >> If you've not factored these things into your business process, >> hardware acquisition, I think you will end up with a bad situation. >> >> - Jared From james at towardex.com Mon Aug 25 22:29:31 2008 From: james at towardex.com (James Jun) Date: Mon, 25 Aug 2008 23:29:31 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> Message-ID: <00c401c9072b$f46a38c0$dd3eaa40$@com> > > > As a box designed with the enterprise datacenter in mind, the E- > series > > looks to be missing several key service provider features, including > > MPLS and advanced control plane filtering/policing. > > > Ah, because Cisco does either of these in hardware? Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/Router 7600 series perform both of these features in hardware. The article mentioned in this thread compares Force10 E against the 6500 series. james From joelja at bogus.com Tue Aug 26 00:22:23 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 25 Aug 2008 22:22:23 -0700 Subject: Tools Bof nanog 44 Message-ID: <48B3930F.3030104@bogus.com> Greetings, It's not to late to think about sharing with your peers... Got a tool you use to monitor dns or ip hijacking, got some practices for monitoring your prefixes for anonlous events, have a commercial product you use that does one of these really well? Have some experience managing ipv6 addresses, or a dnssec toolkit? I'm sure your peers would love to hear about any of the above. Other topics are encouraged and invited. thanks joel From morrowc.lists at gmail.com Tue Aug 26 00:33:41 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Aug 2008 01:33:41 -0400 Subject: Native v6 with Level(3)? In-Reply-To: <48AF4A41.8050107@forest.net> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> Message-ID: <75cb24520808252233y5fb8e46v874e72e33d8db09c@mail.gmail.com> On 8/22/08, Kyle Murray wrote: > Here is the response I got from L3 when I inquired about IPV6: > > "The answer to your questions is "no", we have not yet inplemented IPV6 for > our customers yet. IPV4 is the de facto on our backbone nad alledge router > on which customers connectc." > > Poor spelling aside, it seems they have not implemented it yet. If someone > manages to get them to implement, I would really like to hear about it. > wow that is odd.. since stewart bamford has been off giving ipv6 deployment talks to various conferences (including this one: http://www.nanog.org/mtg-0510/bamford.html ) maybe L3's support staff should check their internal documentation?? Slide 17 says: "Deployment completed Q3 2005"... so, they apparently have it, can get it to you and do 6PE (or did 6PE a bit ago). Maybe ask again and aim the nay-sayer to the nanog preso and ask them to call stewart up directly? -chris From james at iroute.org Tue Aug 26 00:44:27 2008 From: james at iroute.org (James Spenceley) Date: Tue, 26 Aug 2008 15:44:27 +1000 Subject: Native v6 with Level(3)? In-Reply-To: <75cb24520808252233y5fb8e46v874e72e33d8db09c@mail.gmail.com> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> <75cb24520808252233y5fb8e46v874e72e33d8db09c@mail.gmail.com> Message-ID: <59BB3249-22EF-4073-BD0D-A7739DFE7F12@iroute.org> On 26/08/2008, at 3:33 PM, Christopher Morrow wrote: > > wow that is odd.. since stewart bamford has been off giving ipv6 > deployment talks to various conferences (including this one: > http://www.nanog.org/mtg-0510/bamford.html ) > It might be odd but its consistent. I had the response that there is no native support for transit, but there are some "customer trials" using tunnels. > maybe L3's support staff should check their internal documentation?? > Slide 17 says: "Deployment completed Q3 2005"... so, they apparently > have it, can get it to you and do 6PE (or did 6PE a bit ago). Maybe > ask again and aim the nay-sayer to the nanog preso and ask them to > call stewart up directly? In the end, we talked to he.net that was a far simpler process :-) -- James From jay at west.net Tue Aug 26 00:47:00 2008 From: jay at west.net (Jay Hennigan) Date: Mon, 25 Aug 2008 22:47:00 -0700 Subject: Native v6 with Level(3)? In-Reply-To: <75cb24520808252233y5fb8e46v874e72e33d8db09c@mail.gmail.com> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> <75cb24520808252233y5fb8e46v874e72e33d8db09c@mail.gmail.com> Message-ID: <48B398D4.9070605@west.net> Christopher Morrow wrote: > On 8/22/08, Kyle Murray wrote: >> Here is the response I got from L3 when I inquired about IPV6: >> >> "The answer to your questions is "no", we have not yet inplemented IPV6 for >> our customers yet. IPV4 is the de facto on our backbone nad alledge router >> on which customers connectc." >> >> Poor spelling aside, it seems they have not implemented it yet. If someone >> manages to get them to implement, I would really like to hear about it. >> > > wow that is odd.. since stewart bamford has been off giving ipv6 > deployment talks to various conferences (including this one: > http://www.nanog.org/mtg-0510/bamford.html ) > > maybe L3's support staff should check their internal documentation?? > Slide 17 says: "Deployment completed Q3 2005"... so, they apparently > have it, can get it to you and do 6PE (or did 6PE a bit ago). Maybe > ask again and aim the nay-sayer to the nanog preso and ask them to > call stewart up directly? We had the same issue when we inquired initially. Apparently Level(1) support at Level(3) has Level(0) clue as to their capabilities. I responded to Kyle off-list as to the email address for getting to the people with the answers. Stewart is still on the team and they had us up and running on IPv6 within a couple of days once I contacted the right people. -- 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 pauldotwall at gmail.com Tue Aug 26 02:18:16 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 26 Aug 2008 03:18:16 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> Message-ID: <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> On Mon, Aug 25, 2008 at 7:20 PM, Jo Rhett wrote: >> http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_failover_video_ftos_6211.html >> >> >> http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/EANTC_Full_Report.pdf >> >> >> http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/Section_8.pdf > > Did you read these? Yes. > They appear to be nonsense. They were bought and paid > for by Cisco, and including nonsense things like "if you leave a slot open > the chassis will burn up" as a decrement, which is also true in pretty much > every big iron vendor. Current-generation Cisco and Juniper hardware don't seem to have this problem. I don't think the "remove one SFM and all the others go offline" failure mode is commonplace among other vendors either. > They also deliberately detuned the force10 > configuration. They re-ran the tests using the recommended configuration > and got very different numbers -- which you can request from them, but they > won't publish on the website. I'd be interested in seeing this. Mind putting them up somewhere and sharing the URL? > Based on what? For E and C series boxes, Cisco is never cheaper. S-series > are a different story. I was comparing list pricing for the E-series up against Catalyst 6500, Supervisor 720-3BXL, 6700 blades with CFC... which I consider a fair comparison. >> As a box designed with the enterprise datacenter in mind, the E-series >> looks to be missing several key service provider features, including >> MPLS and advanced control plane filtering/policing. > > > Ah, because Cisco does either of these in hardware? Yes, they do, on the s720-3B and better. Drive Slow, Paul Wall From pauldotwall at gmail.com Tue Aug 26 02:26:05 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 26 Aug 2008 03:26:05 -0400 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> Message-ID: <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> On Mon, Aug 25, 2008 at 7:26 PM, Jo Rhett wrote: >> 1) Reliability > > Very good. Across our entire business we've lost 1 RPM module in ~2 years. How many boxes in total? Losing a single routing engine in two years is not a bad MTBF, though I wonder if we're talking about one chassis or one thousand. >> 2) Performance > > [Note: we have no 10g interfaces, so I can only speak to a many-singleg-port > environment] > Much higher than Cisco. So good at dealing with traffic problems that we > have had multi-gig DoS attacks that we wouldn't have known about without > having an IDS running on a mirroring port. Routing n*GE at line rate isn't difficult these days, even with all 64-byte packets and other "DoS" conditions. Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 switches sold at Fry's for a couple benjamins a pop. :) Now mind you, this is all traffic through the router. I'd imagine Force 10 would have a problem with traffic aimed at its interface or loopback IPs, given their lack of control plane policing/filtering, unlike say: http://aharp.ittns.northwestern.edu/papers/copp.html >> 3) Support staff (how knowledgeable are they?) > > Significantly higher than Cisco, and escalation is easier. On par with > Juniper. This is good, though not necessarily hard when you have a small pool of TAC people. Then again, I've always had a good support experience with Extreme, but I'm not about to run out and replace my core with Black Diamonds. :) > These things are so very solid that I rarely spend any time doing network > work any more. Gigabit line-speed BCP38 makes life easier for the abuse > helpdesk too. I'm unaware of any hardware-forwarding-based platforms which can't do this. Though if I find any, I'll be sure to steer clear! Paul Wall From sean at donelan.com Tue Aug 26 02:28:04 2008 From: sean at donelan.com (Sean Donelan) Date: Tue, 26 Aug 2008 03:28:04 -0400 (EDT) Subject: Is it time to abandon bogon prefix filters? In-Reply-To: <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> References: <86tzdmzcv3.fsf@seastrom.com><70D072392E56884193E3D2DE09C097A9F492@pascal.zaphodb.org><48A8C8F5.7080102@templin.org> <20080818123308.GA47385@puck.nether.net><2A5F6B38-9A5F-4043-96ED-3FF006409D00@tcb.net> <200808212006370.32BF5B92.10507@clifden.donelan.com> <70D072392E56884193E3D2DE09C097A9F4E8@pascal.zaphodb.org> Message-ID: <200808260325180.32BF5B92.25185@clifden.donelan.com> On Sun, 24 Aug 2008, Tomas L. Byrnes wrote: > You're missing one of the basic issues with bogon sources: they are > often advertised bogons, IE the bad guy DOES care about getting the > packets back, and has, in fact, created a way to do so. > > This is usually VERY BAD traffic, and EVEN WORSE if a user goes TO a > site hosted in such IP space. > > So, Bogon filtering has value beyond mere spoofed source rejection. Unmanaged (or semi-managed) routers probably should not be running BGP or other exterior routing protocols. Unmanaged routers with BGP provide more opportunities to create havoc and mischief. From criling at gmail.com Tue Aug 26 02:33:37 2008 From: criling at gmail.com (Chris Riling) Date: Tue, 26 Aug 2008 03:33:37 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> Message-ID: <8c829ec10808260033y169ce63cl907b296652d59711@mail.gmail.com> "Then again, I've always had a good support experience with Extreme, but I'm not about to run out and replace my core with Black Diamonds. :)" I once worked at a place where we had BD 6808's at the core; one of them consistently had hardware issues, and it took me the better part of a year of fighting with Extreme to get them to replace the chassis, but when they did, the problems went away, imagine that. I suppose similar isolated incidents could happen with anyone occasionally though. Chris On Tue, Aug 26, 2008 at 3:26 AM, Paul Wall wrote: > On Mon, Aug 25, 2008 at 7:26 PM, Jo Rhett > wrote: > >> 1) Reliability > > > > Very good. Across our entire business we've lost 1 RPM module in ~2 > years. > > How many boxes in total? Losing a single routing engine in two years > is not a bad MTBF, though I wonder if we're talking about one chassis > or one thousand. > > >> 2) Performance > > > > [Note: we have no 10g interfaces, so I can only speak to a > many-singleg-port > > environment] > > Much higher than Cisco. So good at dealing with traffic problems that we > > have had multi-gig DoS attacks that we wouldn't have known about without > > having an IDS running on a mirroring port. > > Routing n*GE at line rate isn't difficult these days, even with all > 64-byte packets and other "DoS" conditions. > > Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 > switches sold at Fry's for a couple benjamins a pop. :) > > Now mind you, this is all traffic through the router. I'd imagine > Force 10 would have a problem with traffic aimed at its interface or > loopback IPs, given their lack of control plane policing/filtering, > unlike say: > > http://aharp.ittns.northwestern.edu/papers/copp.html > > >> 3) Support staff (how knowledgeable are they?) > > > > Significantly higher than Cisco, and escalation is easier. On par with > > Juniper. > > This is good, though not necessarily hard when you have a small pool > of TAC people. > > Then again, I've always had a good support experience with Extreme, > but I'm not about to run out and replace my core with Black Diamonds. > :) > > > These things are so very solid that I rarely spend any time doing network > > work any more. Gigabit line-speed BCP38 makes life easier for the abuse > > helpdesk too. > > I'm unaware of any hardware-forwarding-based platforms which can't do this. > > Though if I find any, I'll be sure to steer clear! > > Paul Wall > > From swmike at swm.pp.se Tue Aug 26 02:47:52 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Aug 2008 09:47:52 +0200 (CEST) Subject: Force10 Gear - Opinions In-Reply-To: <8c829ec10808260033y169ce63cl907b296652d59711@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> <8c829ec10808260033y169ce63cl907b296652d59711@mail.gmail.com> Message-ID: On Tue, 26 Aug 2008, Chris Riling wrote: > I once worked at a place where we had BD 6808's at the core; one of them > consistently had hardware issues, and it took me the better part of a > year of fighting with Extreme to get them to replace the chassis, but > when they did, the problems went away, imagine that. I suppose similar > isolated incidents could happen with anyone occasionally though. If you've worked long enough, you will have had everything happen to you. I've had power supply problems where it was actually the SUP720-3BXL that was the issue (discovered after first replacing PSU, then chassis, then finally the SUP). We have a GSR where we have replaced everything so far (including chassis), problem still persists. What do to then? Ask to replace everything again but do this in one bang? Must be interesting to work as a TAC engineer, they must see a lot of weird things. -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Tue Aug 26 05:03:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 26 Aug 2008 11:03:40 +0100 Subject: It's Ars Tech's turn to bang the IPv4 exhaustion drum In-Reply-To: <48AF3374.2020702@thewybles.com> Message-ID: > I'm looking at building a large network with Ipv6 in the Los > Angeles metro area, to serve a number of small businesses via > a large scale wireless network. Essentially a large scale > private WAN, with globally routable addresses (for a > VoIP/IPTV roll out later) So I'm not exactly a traditional > ISP or colocation customer, but share characteristics with > them. Does this matter? Should I just submit my request and > see what happens? Yes, you should just submit your request and see what happens. If there isn't enough documentation or you filled out something incorrectly, ARIN generally contacts you and explains what you need to provide in order to justify your request. It is pretty painless really. At worst, because your business model is out of the ordinary, you might spend a week or two going back and forth explaining things. --Michael Dillon From morrowc.lists at gmail.com Tue Aug 26 08:32:33 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Aug 2008 09:32:33 -0400 Subject: Native v6 with Level(3)? In-Reply-To: <48B398D4.9070605@west.net> References: <20080818170922.GB10900@cgi.jachomes.com> <48AF2E82.3090602@eeph.com> <20080822223952.GC14582@cgi.jachomes.com> <48AF4A41.8050107@forest.net> <75cb24520808252233y5fb8e46v874e72e33d8db09c@mail.gmail.com> <48B398D4.9070605@west.net> Message-ID: <75cb24520808260632p44f3fa87u5f7ec898c4258d6@mail.gmail.com> On Tue, Aug 26, 2008 at 1:47 AM, Jay Hennigan wrote: > Christopher Morrow wrote: >> www.nanog.org/mtg-0510/bamford.html ) >> >> maybe L3's support staff should check their internal documentation?? >> Slide 17 says: "Deployment completed Q3 2005"... so, they apparently >> have it, can get it to you and do 6PE (or did 6PE a bit ago). Maybe >> ask again and aim the nay-sayer to the nanog preso and ask them to >> call stewart up directly? > > We had the same issue when we inquired initially. Apparently Level(1) > support at Level(3) has Level(0) clue as to their capabilities. > This is, sadly, not different from a bunch of ISP's (I think vzb is still in a wierd state where getting their sales/install/support folks to put v6 on your link is harder than it ought to be) > I responded to Kyle off-list as to the email address for getting to the > people with the answers. Stewart is still on the team and they had us up > and running on IPv6 within a couple of days once I contacted the right > people. hurray! :) what's the email address so other folks searching might be able to find it? Looking at the ARIN contact info for: 2001:1900::/32 doesn't produce something that seems ipv6 specific (which is probably good). -chris From jim at tgasolutions.com Tue Aug 26 09:40:17 2008 From: jim at tgasolutions.com (Jim McBurnett) Date: Tue, 26 Aug 2008 10:40:17 -0400 Subject: Domain Security risk? Message-ID: Hey folks, I have a customer that owns a domain and has owned it for years. Out of the blue they got an email from Asia Internet Network Information Center. They claim to be an approved Domain name dispute resolution committee member. When I researched it: http://www.adndrc.org/adndrc/index.html They do not appear to be "approved". Has anyone had dealings with them? Currently I am pushing this to ICANN and Network Solutions (domain registrar). Comments? Ideas? Thanks, Jim McBurnett Senior Network Engineer CCNP,CCVP, CCDA Thomas Glover Associates, Inc. 864-473-1200 x 106 office 864-641-5863 Cell From michael.dillon at bt.com Tue Aug 26 09:41:21 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 26 Aug 2008 15:41:21 +0100 Subject: Native v6 with Level(3)? In-Reply-To: <75cb24520808260632p44f3fa87u5f7ec898c4258d6@mail.gmail.com> Message-ID: > This is, sadly, not different from a bunch of ISP's (I think > vzb is still in a wierd state where getting their > sales/install/support folks to put v6 on your link is harder > than it ought to be) > > > I responded to Kyle off-list as to the email address for getting to > > the people with the answers. Stewart is still on the team and they > > had us up and running on IPv6 within a couple of days once > I contacted > > the right people. > > hurray! :) what's the email address so other folks searching > might be able to find it? Please go to the ARIN IPv6 wiki and add any ISP contact info to this page: --Michael Dillon From stephen at sprunk.org Tue Aug 26 09:55:52 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 26 Aug 2008 09:55:52 -0500 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> Message-ID: <48B41978.9040201@sprunk.org> Paul Wall wrote: > On Fri, Aug 22, 2008 at 10:34 AM, Matlock, Kenneth L > wrote: > >> Does anyone here have real-world experience with Force 10 gear >> (Specifically their E-Series and C-Series)? They came and did their >> whole dog and pony show today, but I wanted to get real-world feedback >> on their gear. >> >> I need to know about their >> >> 1) Reliability >> 2) Performance >> > > EANTC did a comprehensive study of the E-series: > > http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_failover_video_ftos_6211.html > > http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/EANTC_Full_Report.pdf > > http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-Force10/Section_8.pdf > Standard benchmarketing. Not that I blame Cisco or EANTC for that, since they were debunking some benchmarketing done by Force10 and Tolly, but consider the source (and follow the money) when reading any "independent" test and what that means for accuracy. 80% of the EANTC report can be summed up as "The default CAM profile didn't do what we wanted, and we didn't bother asking Force10 for the commands to make it work." There are indeed some interesting product weaknesses, like any vendor has, but the fact that Force10's CAM can be partitioned to match the buyer's needs, rather than having a fixed configuration that all customers are forced to use, is an advantage in my book. S (Disclosure: I am a former employee of both Cisco and Force10, but have no ties to either today.) From hannigan at verneglobal.com Tue Aug 26 10:03:09 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 26 Aug 2008 15:03:09 -0000 Subject: Domain Security risk? In-Reply-To: References: Message-ID: Looks like they are to me: http://www.icann.org/en/announcements/announcement-03dec01.htm http://www.icann.org/en/dndr/tdrp/approved-providers.htm -M< -- Martin Hannigan http://www.verneglobal.com/ Senior Director e: hannigan at verneglobal.com Verne Global Datacenters c: +16178216079 Keflavik, Iceland f: +16172347098 > -----Original Message----- > From: Jim McBurnett [mailto:jim at tgasolutions.com] > Sent: Tuesday, August 26, 2008 10:40 AM > To: nanog at nanog.org > Subject: Domain Security risk? > > Hey folks, > I have a customer that owns a domain and has owned it for years. > Out of the blue they got an email from Asia Internet Network > Information Center. > They claim to be an approved Domain name dispute resolution committee > member. > When I researched it: http://www.adndrc.org/adndrc/index.html > They do not appear to be "approved". > > Has anyone had dealings with them? > Currently I am pushing this to ICANN and Network Solutions (domain > registrar). > > Comments? > Ideas? > > > > Thanks, > > > Jim McBurnett > Senior Network Engineer > CCNP,CCVP, CCDA > Thomas Glover Associates, Inc. > 864-473-1200 x 106 office > 864-641-5863 Cell From markjr at easydns.com Tue Aug 26 11:08:53 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 26 Aug 2008 12:08:53 -0400 Subject: Domain Security risk? In-Reply-To: References: Message-ID: I would ignore it Any real challenge against the domain (assuming it's .cnobi) and you'll be hearing from either WIPO or the national arbitration forum and your registrar ( plus your domain will have placed on registrar hold) I see all kinds of strange domain related spams and scams coming out of Asia, I think they're all the same outfit. Sent from my iPhone On Aug 26, 2008, at 10:40 AM, Jim McBurnett wrote: > Hey folks, > I have a customer that owns a domain and has owned it for years. > Out of the blue they got an email from Asia Internet Network > Information Center. > They claim to be an approved Domain name dispute resolution > committee member. > When I researched it: http://www.adndrc.org/adndrc/index.html > They do not appear to be "approved". > > Has anyone had dealings with them? > Currently I am pushing this to ICANN and Network Solutions (domain > registrar). > > Comments? > Ideas? > > > > Thanks, > > > Jim McBurnett > Senior Network Engineer > CCNP,CCVP, CCDA > Thomas Glover Associates, Inc. > 864-473-1200 x 106 office > 864-641-5863 Cell > From pauldotwall at gmail.com Tue Aug 26 11:41:44 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 26 Aug 2008 12:41:44 -0400 Subject: OT but funny: shades of gallery.colofinder.net Message-ID: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com> Not to pick on the Democrats unduly - they just went first in terms of giving us crummy cabling as a metaphor for crummy government; inshallah the Republicans will give us something as good or better when they have their turn next week... http://www.wired.com/techbiz/media/multimedia/2008/08/gallery_dnc_tech?slide=7&slideView=4 Is anyone still running a cabling horror show photo rogue's gallery? Drive Slow, Paul Wall From owen at delong.com Tue Aug 26 11:46:53 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Aug 2008 09:46:53 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <48B41978.9040201@sprunk.org> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: > Standard benchmarketing. Not that I blame Cisco or EANTC for that, > since they were debunking some benchmarketing done by Force10 and > Tolly, but consider the source (and follow the money) when reading > any "independent" test and what that means for accuracy. > > 80% of the EANTC report can be summed up as "The default CAM profile > didn't do what we wanted, and we didn't bother asking Force10 for > the commands to make it work." There are indeed some interesting > product weaknesses, like any vendor has, but the fact that Force10's > CAM can be partitioned to match the buyer's needs, rather than > having a fixed configuration that all customers are forced to use, > is an advantage in my book. Having delved a bit deeper into F10's "partitioning" scheme, actually, it's not as flexible as one might hope. There are a very small number of relatively large pages and you have to partition on page boundaries which leaves you with only limited flexibility when it comes to the CAM partitioning. Bottom line, in a few years, everyone carrying full tables with F10 gear will probably need to upgrade all of their line cards to quad-cam. Another thing to note (as near as I can tell, this applies to all vendors). All line cards will function only at the lowest common denominator line card CAM level. IOW, if you have single, dual, and quad-cam cards in your F10 chassis, they'll all act like single-CAM cards. Owen From dhetzel at gmail.com Tue Aug 26 11:50:56 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Tue, 26 Aug 2008 12:50:56 -0400 Subject: speaking of slightly OT but perhaps still operational content Message-ID: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> I noticed where the democrats plan to ask a stadium full of people to all use their cellphones at the same time (on Thursday, I believe) Any thoughts on how useable cell service will or wont be in the vicinity of this event? :) -Dorn From tme at multicasttech.com Tue Aug 26 11:54:17 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 26 Aug 2008 12:54:17 -0400 Subject: speaking of slightly OT but perhaps still operational content In-Reply-To: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> References: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> Message-ID: <034856BC-3913-40EE-95F0-71D6FCCA87D8@multicasttech.com> On Aug 26, 2008, at 12:50 PM, Dorn Hetzel wrote: > I noticed where the democrats plan to ask a stadium full of people > to all > use their cellphones at the same time (on Thursday, I believe) > > Any thoughts on how useable cell service will or wont be in the > vicinity of > this event? :) I don't know, but I have heard complaints about the wireless service in the Convention Center. Regards Marshall > > > -Dorn From john at internetassociatesllc.com Tue Aug 26 13:51:15 2008 From: john at internetassociatesllc.com (John Lee) Date: Tue, 26 Aug 2008 13:51:15 -0500 Subject: speaking of slightly OT but perhaps still operational content In-Reply-To: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> References: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159AF1@MEMEXG1.HOST.local> Unless they have installed a DAS system for cell signal transport or a number of micro or nano cells in the building they will have congestion. But what is a political convention without a little congestion. John (ISDN) Lee ________________________________________ From: Dorn Hetzel [dhetzel at gmail.com] Sent: Tuesday, August 26, 2008 12:50 PM To: NANOG list Subject: speaking of slightly OT but perhaps still operational content I noticed where the democrats plan to ask a stadium full of people to all use their cellphones at the same time (on Thursday, I believe) Any thoughts on how useable cell service will or wont be in the vicinity of this event? :) -Dorn From amir at aeon.pk Tue Aug 26 14:04:47 2008 From: amir at aeon.pk (Aamir Jamil) Date: Wed, 27 Aug 2008 01:04:47 +0600 Subject: speaking of slightly OT but perhaps still operational content In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159AF1@MEMEXG1.HOST.local> References: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> <53A6C7E936ED8544B1A2BC990D254F942BF6159AF1@MEMEXG1.HOST.local> Message-ID: <004a01c907ae$9f40fc70$ddc2f550$@pk> Probably very less amount of users will be able to call and the rest in that cell site coverage will get congestion. -amir -----Original Message----- From: John Lee [mailto:john at internetassociatesllc.com] Sent: Wednesday, August 27, 2008 12:51 AM To: Dorn Hetzel; NANOG list Subject: RE: speaking of slightly OT but perhaps still operational content Unless they have installed a DAS system for cell signal transport or a number of micro or nano cells in the building they will have congestion. But what is a political convention without a little congestion. John (ISDN) Lee ________________________________________ From: Dorn Hetzel [dhetzel at gmail.com] Sent: Tuesday, August 26, 2008 12:50 PM To: NANOG list Subject: speaking of slightly OT but perhaps still operational content I noticed where the democrats plan to ask a stadium full of people to all use their cellphones at the same time (on Thursday, I believe) Any thoughts on how useable cell service will or wont be in the vicinity of this event? :) -Dorn Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.4/1615 - Release Date: 8/16/2008 7:11 AM From herrin-nanog at dirtside.com Tue Aug 26 14:22:51 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 26 Aug 2008 15:22:51 -0400 Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com> References: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com> Message-ID: <3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com> On Tue, Aug 26, 2008 at 12:41 PM, Paul Wall wrote: > Not to pick on the Democrats unduly - they just went first in terms of > giving us crummy cabling as a metaphor for crummy government; > http://www.wired.com/techbiz/media/multimedia/2008/08/gallery_dnc_tech?slide=7&slideView=4 Paul, One makes difference choices when it only has to last 7 days. Here's what it looks like at DNC headquarters in DC where it has to last from year to year: http://bill.herrin.us/cables-sm.jpg Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From deepak at ai.net Tue Aug 26 14:33:18 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 26 Aug 2008 15:33:18 -0400 Subject: speaking of slightly OT but perhaps still operational content In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159AF1@MEMEXG1.HOST.local> References: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> <53A6C7E936ED8544B1A2BC990D254F942BF6159AF1@MEMEXG1.HOST.local> Message-ID: <48B45A7E.3040503@ai.net> Perhaps I'm wrong, but I thought its fairly typical for large events such as these (with lots of communications assets being deployed, not unlike a Superbowl, etc) for Cell companies to roll in COWs (Cell-on-wheels) type deployments to support additional capacity. Am I living in a fantasy land? Deepak John Lee wrote: > Unless they have installed a DAS system for cell signal transport or a number of micro or nano cells in the building they will have congestion. But what is a political convention without a little congestion. > > John (ISDN) Lee > > ________________________________________ > From: Dorn Hetzel [dhetzel at gmail.com] > Sent: Tuesday, August 26, 2008 12:50 PM > To: NANOG list > Subject: speaking of slightly OT but perhaps still operational content > > I noticed where the democrats plan to ask a stadium full of people to all > use their cellphones at the same time (on Thursday, I believe) > > Any thoughts on how useable cell service will or wont be in the vicinity of > this event? :) > > -Dorn > > > From pauldotwall at gmail.com Tue Aug 26 14:56:54 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 26 Aug 2008 15:56:54 -0400 Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: <3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com> References: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com> <3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com> Message-ID: <620fd17c0808261256k70117bb0h1a4a464d2267d724@mail.gmail.com> On Tue, Aug 26, 2008 at 3:22 PM, William Herrin wrote: > > One makes difference choices when it only has to last 7 days. Here's > what it looks like at DNC headquarters in DC where it has to last from > year to year: But of course. Hope you're not killing yourself out in Denver; event networking can be a bear. > http://bill.herrin.us/cables-sm.jpg Who knew that the Rainbow Coalition's day job was in IT at the DNC? Drive Slow, Paul Wall From jake at nobistech.net Tue Aug 26 15:00:42 2008 From: jake at nobistech.net (Jake Mertel) Date: Tue, 26 Aug 2008 15:00:42 -0500 Subject: Where to put our router Message-ID: <48B460EA.3070707@nobistech.net> Good afternoon (or whatever it is for you ;), We have just finished moving a large amount of equipment to a new facility outside of downtown Chicago. At present we have an uplink via a point-to-point to Equinox downtown. We are preparing to add another provider, and are debating where we should put our router. The two options would be in Equinox downtown (co-located with our existing provider) or at the new facility. Were we to do the former we would turn our existing point-to-point into our connection from our edge router to our distribution switch and add a second point-to-point for redundancy from the distro switch back to the router. Were we to do the latter we would get a second point-to-point direct from our new provider to their network and connect it to our router where it is now. The major advantage I can think of to having it in Equinox is the availability of cross connects to just about anyone. There are a few providers in the new facility, but not many. The major disadvantage is that if we suddenly need a large amount of transport (i.e. a new large client, a definitive short-term possibility) we would either need to get a new or additional point-to-point from downtown to the facility or would need to get another router to utilize at the new facility (were we to meet up with one of the in-building providers instead of getting the point-to-point transport). Any thoughts related to the advantages or disadvantages of doing one or the other would be greatly appreciated. Thanks in advance. Kind regards, Jake Mertel Nobis Technology Group, L.L.C. From bogstad at pobox.com Tue Aug 26 15:53:24 2008 From: bogstad at pobox.com (Bill Bogstad) Date: Tue, 26 Aug 2008 16:53:24 -0400 Subject: US government mandates? use of DNSSEC by federal agencies Message-ID: <2d6a9f6f0808261353p2f71545nfac0056f47c886b7@mail.gmail.com> Not sure what this will actually mean in the long run, but it's at least worth noting. http://www.gcn.com/online/vol1_no1/46987-1.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf Bill Bogstad From brunner at nic-naa.net Tue Aug 26 16:12:39 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 26 Aug 2008 17:12:39 -0400 Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: <620fd17c0808261256k70117bb0h1a4a464d2267d724@mail.gmail.com> References: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com> <3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com> <620fd17c0808261256k70117bb0h1a4a464d2267d724@mail.gmail.com> Message-ID: <48B471C7.3090803@nic-naa.net> After the first and second InterOps our cable plant for networks that lasted a week were considerably better organized. The short duration isn't that compelling for ... pasta panic. Paul Wall wrote: > On Tue, Aug 26, 2008 at 3:22 PM, William Herrin > wrote: > >> One makes difference choices when it only has to last 7 days. Here's >> what it looks like at DNC headquarters in DC where it has to last from >> year to year: >> > > But of course. Hope you're not killing yourself out in Denver; event > networking can be a bear. > > >> http://bill.herrin.us/cables-sm.jpg >> > > Who knew that the Rainbow Coalition's day job was in IT at the DNC? > > Drive Slow, > Paul Wall > > > > From jra at baylink.com Tue Aug 26 16:19:20 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 26 Aug 2008 17:19:20 -0400 Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: <48B471C7.3090803@nic-naa.net> References: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com> <3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com> <620fd17c0808261256k70117bb0h1a4a464d2267d724@mail.gmail.com> <48B471C7.3090803@nic-naa.net> Message-ID: <20080826211920.GV31438@cgi.jachomes.com> On Tue, Aug 26, 2008 at 05:12:39PM -0400, Eric Brunner-Williams wrote: > After the first and second InterOps our cable plant for networks that > lasted a week were considerably better organized. The short duration > isn't that compelling for ... pasta panic. I got to go to one Interop; way back in Atlanta when Cabletron and whomever else turned into Bay Networks were still separate companies. It seemed pretty clean to me; which one was that? 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. -- (Josef Stalin) From kwallace at pcconnection.com Tue Aug 26 16:26:50 2008 From: kwallace at pcconnection.com (Wallace Keith) Date: Tue, 26 Aug 2008 17:26:50 -0400 Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: <20080826211920.GV31438@cgi.jachomes.com> References: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com><3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com><620fd17c0808261256k70117bb0h1a4a464d2267d724@mail.gmail.com><48B471C7.3090803@nic-naa.net> <20080826211920.GV31438@cgi.jachomes.com> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB10313C436@MKA134.pcc.int> Cabletron != baynetworks, that was Wellfleet and Synoptics that merged to become Bay, that became Nortel..... I've been around too long. -Keith -----Original Message----- From: Jay R. Ashworth [mailto:jra at baylink.com] Sent: Tuesday, August 26, 2008 5:19 PM To: nanog at nanog.org Subject: Re: OT but funny: shades of gallery.colofinder.net On Tue, Aug 26, 2008 at 05:12:39PM -0400, Eric Brunner-Williams wrote: > After the first and second InterOps our cable plant for networks that > lasted a week were considerably better organized. The short duration > isn't that compelling for ... pasta panic. I got to go to one Interop; way back in Atlanta when Cabletron and whomever else turned into Bay Networks were still separate companies. It seemed pretty clean to me; which one was that? 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. -- (Josef Stalin) From simon.leinen at switch.ch Tue Aug 26 16:40:17 2008 From: simon.leinen at switch.ch (Simon Leinen) Date: Tue, 26 Aug 2008 23:40:17 +0200 Subject: IP Fragmentation In-Reply-To: <48AC959A.7030203@spacething.org> (Sam Stickland's message of "Wed, 20 Aug 2008 23:07:22 +0100") References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <20580.1219255453@turing-police.cc.vt.edu> <010F38F3-2B20-4707-9A29-0950D61C9CC5@muada.com> <48AC959A.7030203@spacething.org> Message-ID: Sam Stickland writes: > Iljitsch van Beijnum wrote: >> Yet all OSes have it enabled and there is no fallback to >> fragmentation in PMTUD: if your system doesn't get the ICMP >> messages, your session is dead in the water. >> > Windows Vista/2007 has black hole detection enabled by default. It's > not massively elegant, but it will keep sessions up (falls back to > 536 byte MTU). > http://support.microsoft.com/kb/925280 Note that there's a new IETF specification (RFC 4821) for ("Packetization Layer") Path MTU discovery, which doesn't rely on ICMP messages to work. If what I wrote here http://kb.pert.geant2.net/PERTKB/PathMTU is correct, this has been implemented in recent (>= 2.6.17) Linux kernels. I don't know of any other OSes that have this yet - not that they'd tell me (but they could go and edit the page above, that's why it's a Wiki). -- Simon. From scott.berkman at reignmaker.net Tue Aug 26 16:40:21 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Tue, 26 Aug 2008 17:40:21 -0400 (EDT) Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: <0E8773C725A1674E9F7B35EABB5EEEB10313C436@MKA134.pcc.int> References: <620fd17c0808260941x79106a51sa80485d0b39a2ddf@mail.gmail.com><3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com><620fd17c0808261256k70117bb0h1a4a464d2267d724@mail.gmail.com><48B471C7.3090803@nic-naa.net> <20080826211920.GV31438@cgi.jachomes.com> <0E8773C725A1674E9F7B35EABB5EEEB10313C436@MKA134.pcc.int> Message-ID: <026b01c907c4$68f6f7d0$3ae4e770$@berkman@reignmaker.net> Or you may be thinking of the mergers, etc..., with Cabletron, Riverstone, and Yago and then all that into Lucent. -Scott -----Original Message----- From: Wallace Keith [mailto:kwallace at pcconnection.com] Sent: Tuesday, August 26, 2008 5:27 PM To: Jay R. Ashworth; nanog at nanog.org Subject: RE: OT but funny: shades of gallery.colofinder.net Cabletron != baynetworks, that was Wellfleet and Synoptics that merged to become Bay, that became Nortel..... I've been around too long. -Keith -----Original Message----- From: Jay R. Ashworth [mailto:jra at baylink.com] Sent: Tuesday, August 26, 2008 5:19 PM To: nanog at nanog.org Subject: Re: OT but funny: shades of gallery.colofinder.net On Tue, Aug 26, 2008 at 05:12:39PM -0400, Eric Brunner-Williams wrote: > After the first and second InterOps our cable plant for networks that > lasted a week were considerably better organized. The short duration > isn't that compelling for ... pasta panic. I got to go to one Interop; way back in Atlanta when Cabletron and whomever else turned into Bay Networks were still separate companies. It seemed pretty clean to me; which one was that? 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. -- (Josef Stalin) From dhetzel at gmail.com Tue Aug 26 16:54:59 2008 From: dhetzel at gmail.com (Dorn Hetzel) Date: Tue, 26 Aug 2008 17:54:59 -0400 Subject: speaking of slightly OT but perhaps still operational content In-Reply-To: <48B45A7E.3040503@ai.net> References: <2ee691ff0808260950w54cf7b01o91909e9be4fce0a8@mail.gmail.com> <53A6C7E936ED8544B1A2BC990D254F942BF6159AF1@MEMEXG1.HOST.local> <48B45A7E.3040503@ai.net> Message-ID: <2ee691ff0808261454x1715fa19j28358d8278c9fc0c@mail.gmail.com> Even with a COW, I'm not sure all the providers together have anywhere near enough spectrum to service 75,000 geographically coincident calls :) On Tue, Aug 26, 2008 at 3:33 PM, Deepak Jain wrote: > Perhaps I'm wrong, but I thought its fairly typical for large events such > as these (with lots of communications assets being deployed, not unlike a > Superbowl, etc) for Cell companies to roll in COWs (Cell-on-wheels) type > deployments to support additional capacity. > > Am I living in a fantasy land? > > Deepak > > > John Lee wrote: > >> Unless they have installed a DAS system for cell signal transport or a >> number of micro or nano cells in the building they will have congestion. But >> what is a political convention without a little congestion. >> >> John (ISDN) Lee >> >> ________________________________________ >> From: Dorn Hetzel [dhetzel at gmail.com] >> Sent: Tuesday, August 26, 2008 12:50 PM >> To: NANOG list >> Subject: speaking of slightly OT but perhaps still operational content >> >> I noticed where the democrats plan to ask a stadium full of people to all >> use their cellphones at the same time (on Thursday, I believe) >> >> Any thoughts on how useable cell service will or wont be in the vicinity >> of >> this event? :) >> >> -Dorn >> >> >> >> From dhubbard at dino.hostasaurus.com Tue Aug 26 17:44:55 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 26 Aug 2008 18:44:55 -0400 Subject: Level 3 TPA routing today? Message-ID: Anyone seeing issues with Level 3 between anywhere and Tampa, particularly Atlanta and Dallas? We've seen lots of outbound issues and customers calling about their sites being down or slow. Ultimately turned our two links to them off and then everyone says looks better. I opened a ticket with them and of course they say no one has reported any issues whatsoever. I sent them a bunch of traces and will try turning them back on later tonight since these non-issues tend to resolve themselves if I wait for a single homed customer to yell loud enough for them to fix it. Thanks, David From chip.gwyn at gmail.com Tue Aug 26 17:48:58 2008 From: chip.gwyn at gmail.com (chip) Date: Tue, 26 Aug 2008 18:48:58 -0400 Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: <64a8ad980808261548h5837876exc2455a7397907a18@mail.gmail.com> On Tue, Aug 26, 2008 at 6:44 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Anyone seeing issues with Level 3 between anywhere > and Tampa, particularly Atlanta and Dallas? We've > seen lots of outbound issues and customers calling > about their sites being down or slow. Ultimately > turned our two links to them off and then everyone > says looks better. I opened a ticket with them and > of course they say no one has reported any issues > whatsoever. I sent them a bunch of traces and will > try turning them back on later tonight since these > non-issues tend to resolve themselves if I wait for > a single homed customer to yell loud enough for them > to fix it. > > Thanks, > > David > > David, I'm seeing the same thing in the Atlanta market. I can trace to 1 IP in a prefix but not another. Almost like maybe there's some FIB horkage across a multi-path link or something. Fired off an e-mail, awaiting status for now. --chip -- Just my $.02, your mileage may vary, batteries not included, etc.... From oberman at es.net Tue Aug 26 17:56:42 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 26 Aug 2008 15:56:42 -0700 Subject: OT but funny: shades of gallery.colofinder.net In-Reply-To: Your message of "Tue, 26 Aug 2008 15:22:51 EDT." <3c3e3fca0808261222h4356d928x529d092ecba07d9f@mail.gmail.com> Message-ID: <20080826225642.320D74500F@ptavv.es.net> > Date: Tue, 26 Aug 2008 15:22:51 -0400 > From: "William Herrin" > > On Tue, Aug 26, 2008 at 12:41 PM, Paul Wall wrote: > > Not to pick on the Democrats unduly - they just went first in terms of > > giving us crummy cabling as a metaphor for crummy government; > > http://www.wired.com/techbiz/media/multimedia/2008/08/gallery_dnc_tech?slide=7&slideView=4 > > Paul, > > One makes difference choices when it only has to last 7 days. Here's > what it looks like at DNC headquarters in DC where it has to last from > year to year: > > http://bill.herrin.us/cables-sm.jpg When you build a network for a week, it's just not a good investment in time to be too neat. After all, in a week, it is all gone. Fun is networking a large show where the network is in a big, transparent room at the center of everything with lots of press taking pictures. Thee you have to build fast, debug fast, tear down really fast, and have everything look pretty. At Supercomputing every fall the net work has external connections of about 20 OC-192s and probably over 150 fiber links handled by a variety of different routers and switches all of which the NOC staff has to be able to work with. Last time I did SC was 2005 in Seattle. Pics at https://scinet.supercomp.org/gallery2/v/SC2005_Seattle/Mitch_Kutzko/ Look at the Tuesday November 15th page for pictures of the NOC. No single picture can really show the whole thing. A few are less than tidy...I guess Jim R. was not watching closely enough. I'll admit that most don't look quite as good as the DNC, but they were built rather more quickly and all by volunteers, albeit mostly seriously over-qualified ones. I retired from SCinet after 2005, but I miss if every November and I'd love to be in Austin this November to help build it again. -- 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 oberman at es.net Tue Aug 26 18:03:31 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 26 Aug 2008 16:03:31 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: Your message of "Tue, 26 Aug 2008 16:53:24 EDT." <2d6a9f6f0808261353p2f71545nfac0056f47c886b7@mail.gmail.com> Message-ID: <20080826230331.D74464500F@ptavv.es.net> > Date: Tue, 26 Aug 2008 16:53:24 -0400 > From: "Bill Bogstad" > > Not sure what this will actually mean in the long run, but it's at > least worth noting. > > http://www.gcn.com/online/vol1_no1/46987-1.html > http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf It will mean something in the medium term as '.gov' and '.org' will be signed very soon and OMB might be able to even get the root signed. (Since OMB can pull funding, no one argues with them much.) All of this will increase pressure on Verisign to deal with '.com' and '.net'. Note that this only has an impact on '.gov' and the zones immediately below it, but I suspect most sub-domains of *.gov will be signed as a result of this, even if it is not required. -- 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 jscott at gravityfree.com Tue Aug 26 18:06:29 2008 From: jscott at gravityfree.com (Justin D. Scott) Date: Tue, 26 Aug 2008 19:06:29 -0400 Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: <1460B0B010024BEA9A9E1053E31634D9@lain> > Anyone seeing issues with Level 3 between anywhere > and Tampa, particularly Atlanta and Dallas? We just have co-lo in Tampa, but our upstream's connectivity is through Level3 and we've been seeing intermittent packet loss up there all day. We alerted our upstream but no updates so far. It hasn't been bad enough for our customers to call and complain though. -- Justin Scott | GravityFree Network Administrator 1960 Stickney Point Road, Suite 210 Sarasota | FL | 34231 | 800.207.4431 941.927.7674 x115 | f 941.923.5429 www.GravityFree.com From drais at icantclick.org Tue Aug 26 18:27:40 2008 From: drais at icantclick.org (david raistrick) Date: Tue, 26 Aug 2008 23:27:40 +0000 (UTC) Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: On Tue, 26 Aug 2008, David Hubbard wrote: > Anyone seeing issues with Level 3 between anywhere > and Tampa, particularly Atlanta and Dallas? We've Internap just reported problems with L3 out of Miami: "we are seeing latency, minor packet loss and path problems to a number of destinations and other PNAPs via our Level3 (AS3356) upstream connection in the MIA003 PNAP. " --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From steve at ibctech.ca Tue Aug 26 18:48:23 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 26 Aug 2008 19:48:23 -0400 Subject: BGP, ebgp-multihop and multiple peers Message-ID: <48B49647.3050106@ibctech.ca> Hi everyone, This question comes after likely overlooking an IETF document or BCP that describes what I'm after. Given that I am looking for advice from someone who is more experienced operationally in this regard than me, and that this technically is an implementation-neutral question, I wanted to ask here. Taking one router I have as an example, I have four IPv6 BGP peers (two are for true routing, the other two for route server projects), and five IPv4 BGP peers. Two of the v4 peers are Cymru for BOGONS, the other three are purely outbound to route server projects. All five v4 peers are ebgp-multihop. I'm looking for advice on the configuration of the peers with ebgp-multihop (IPv4). I have a reserved block carved out of my allocation specifically for /32s on loopbacks, and when I light up a new peer, I configure a new looopback interface for that peer, and subsequently give it the next available IP from the reserved /32 block. There are numerous drawbacks to doing it this way... waste of IPv4 addresses, additional keystrokes on the router for interface config, documentation, expanded margin for error et-al. There are a few benefits to doing it this way (IMHO), but I see obvious benefits of using a single loopback interface and single IP for ALL of these multihop peers. Before I state good/bad, or get any wrong idea in my head, I'd like to ask the real experts here which way they would/do this type of thing, and why. - single loopback/single IP for all peers, or; - each peer with its own loopback/IP? Thanks, Steve From beckman at angryox.com Tue Aug 26 20:39:59 2008 From: beckman at angryox.com (Peter Beckman) Date: Tue, 26 Aug 2008 21:39:59 -0400 Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: On Tue, 26 Aug 2008, david raistrick wrote: > On Tue, 26 Aug 2008, David Hubbard wrote: > >> Anyone seeing issues with Level 3 between anywhere >> and Tampa, particularly Atlanta and Dallas? We've > > Internap just reported problems with L3 out of Miami: > > "we are seeing latency, minor packet loss and path problems to a > number of destinations and other PNAPs via our Level3 (AS3356) upstream > connection in the MIA003 PNAP. " I've been seeing 30-70% packet loss between Cox Business and Level3 from DC to NY since 8:17pm EDT. Maybe via Internap? Loss% Snt Last Avg Best Wrst StDev 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 100 2.4 5.1 2.2 51.9 8.3 4. xe-9-2-0.edge1.Washington1.L 67.0% 100 2.5 6.8 2.4 41.6 8.6 5. vlan99.csw4.Washington1.Leve 69.0% 100 2.7 8.3 2.6 23.7 5.0 6. ae-93-93.ebr3.Washington1.Le 68.0% 100 3.0 9.9 2.7 30.9 6.3 7. ae-3.ebr3.NewYork1.Level3.ne 70.0% 100 10.5 15.8 8.1 44.2 8.8 8. ae-83-83.csw3.NewYork1.Level 71.0% 100 18.9 14.2 8.1 42.0 7.1 9. ae-31-89.car1.NewYork1.Level 66.0% 100 8.6 25.7 8.5 165.4 41.7 Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From truman at suspicious.org Tue Aug 26 20:40:05 2008 From: truman at suspicious.org (Truman Boyes) Date: Tue, 26 Aug 2008 21:40:05 -0400 Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: <48B49647.3050106@ibctech.ca> References: <48B49647.3050106@ibctech.ca> Message-ID: <438788E6-4831-40DD-A3F5-92BA0A0552FC@suspicious.org> Steve, You ask a very good question because I have seen some providers embark on the multiple loopback approach for numerous reasons. I suggest a single loopback per routing-instance whenever possible. The cost savings in OSS and integration in routing configurations with a single repeatable block of configuration per peer/peer group is far more beneficial than some corner case technical benefit of having multiple loopback addresses. I have been forced for other feature support to deploy multiple loopback interfaces, but have always opted to keep all EBGP peering with a single loopback interface per routing-instance. Kind regards, Truman On 26/08/2008, at 7:48 PM, Steve Bertrand wrote: > Hi everyone, > > This question comes after likely overlooking an IETF document or BCP > that describes what I'm after. Given that I am looking for advice > from someone who is more experienced operationally in this regard > than me, and that this technically is an implementation-neutral > question, I wanted to ask here. > > Taking one router I have as an example, I have four IPv6 BGP peers > (two are for true routing, the other two for route server projects), > and five IPv4 BGP peers. Two of the v4 peers are Cymru for BOGONS, > the other three are purely outbound to route server projects. All > five v4 peers are ebgp-multihop. > > I'm looking for advice on the configuration of the peers with ebgp- > multihop (IPv4). > > I have a reserved block carved out of my allocation specifically > for /32s on loopbacks, and when I light up a new peer, I configure a > new looopback interface for that peer, and subsequently give it the > next available IP from the reserved /32 block. > > There are numerous drawbacks to doing it this way... waste of IPv4 > addresses, additional keystrokes on the router for interface config, > documentation, expanded margin for error et-al. > > There are a few benefits to doing it this way (IMHO), but I see > obvious benefits of using a single loopback interface and single IP > for ALL of these multihop peers. Before I state good/bad, or get any > wrong idea in my head, I'd like to ask the real experts here which > way they would/do this type of thing, and why. > > - single loopback/single IP for all peers, or; > - each peer with its own loopback/IP? > > Thanks, > > Steve > > > > > > > > From scott.berkman at reignmaker.net Wed Aug 27 00:37:38 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Wed, 27 Aug 2008 01:37:38 -0400 (EDT) Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: <029901c90807$16004700$4200d500$@berkman@reignmaker.net> We've also been seeing some "weird" (hard to track down) issues all day with Level 3 in both Tampa and Atlanta, especially from our NMS systems monitoring systems all over the place. My contact at Level 3 didn't know of anything going on and couldn't really find anything. Anyone else have a Level 3 response? -Scott -----Original Message----- From: Peter Beckman [mailto:beckman at angryox.com] Sent: Tuesday, August 26, 2008 9:40 PM To: nanog at merit.edu Subject: Re: Level 3 TPA routing today? On Tue, 26 Aug 2008, david raistrick wrote: > On Tue, 26 Aug 2008, David Hubbard wrote: > >> Anyone seeing issues with Level 3 between anywhere >> and Tampa, particularly Atlanta and Dallas? We've > > Internap just reported problems with L3 out of Miami: > > "we are seeing latency, minor packet loss and path problems to a > number of destinations and other PNAPs via our Level3 (AS3356) upstream > connection in the MIA003 PNAP. " I've been seeing 30-70% packet loss between Cox Business and Level3 from DC to NY since 8:17pm EDT. Maybe via Internap? Loss% Snt Last Avg Best Wrst StDev 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 100 2.4 5.1 2.2 51.9 8.3 4. xe-9-2-0.edge1.Washington1.L 67.0% 100 2.5 6.8 2.4 41.6 8.6 5. vlan99.csw4.Washington1.Leve 69.0% 100 2.7 8.3 2.6 23.7 5.0 6. ae-93-93.ebr3.Washington1.Le 68.0% 100 3.0 9.9 2.7 30.9 6.3 7. ae-3.ebr3.NewYork1.Level3.ne 70.0% 100 10.5 15.8 8.1 44.2 8.8 8. ae-83-83.csw3.NewYork1.Level 71.0% 100 18.9 14.2 8.1 42.0 7.1 9. ae-31-89.car1.NewYork1.Level 66.0% 100 8.6 25.7 8.5 165.4 41.7 Beckman -------------------------------------------------------------------------- - Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ -------------------------------------------------------------------------- - From pauldotwall at gmail.com Wed Aug 27 00:58:40 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 27 Aug 2008 01:58:40 -0400 Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: <48B49647.3050106@ibctech.ca> References: <48B49647.3050106@ibctech.ca> Message-ID: <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> On Tue, Aug 26, 2008 at 7:48 PM, Steve Bertrand wrote: > There are a few benefits to doing it this way (IMHO), but I see obvious > benefits of using a single loopback interface and single IP for ALL of these > multihop peers. Before I state good/bad, or get any wrong idea in my head, > I'd like to ask the real experts here which way they would/do this type of > thing, and why. > > - single loopback/single IP for all peers, or; > - each peer with its own loopback/IP? You should use caution when using loopback IP addresses and building external multihop BGP sessions. By permitting external devices to transmit packets to your loopback(s), you open the door to spoof/denial of service attacks. However, if you must establish sessions to something external, it would be best to do so from a dedicated IP address for external peering that you can poke a hole into your ACLs and apply the appropriate rate-limiting/filtering/CoPP controls. Ideally, if you have an allocation for loopbacks, I would hope you wouldn't allow the Internet fling packets at them. Most frequently loopback peering is used when aggregating multiple physical interfaces and is used in conjunction with static routes to load balance traffic over the interfaces. From pauldotwall at gmail.com Wed Aug 27 01:11:35 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 27 Aug 2008 02:11:35 -0400 Subject: Level 3 TPA routing today? In-Reply-To: <7609926309947544466@unknownmsgid> References: <7609926309947544466@unknownmsgid> Message-ID: <620fd17c0808262311o4c945e0ap5e22ea2bf791c08c@mail.gmail.com> Confirmed outage on their side. Should be resolved now. Drive Slow, Paul Wall On Wed, Aug 27, 2008 at 1:37 AM, Scott Berkman wrote: > We've also been seeing some "weird" (hard to track down) issues all day > with Level 3 in both Tampa and Atlanta, especially from our NMS systems > monitoring systems all over the place. > > My contact at Level 3 didn't know of anything going on and couldn't really > find anything. Anyone else have a Level 3 response? > > -Scott > > -----Original Message----- > From: Peter Beckman [mailto:beckman at angryox.com] > Sent: Tuesday, August 26, 2008 9:40 PM > To: nanog at merit.edu > Subject: Re: Level 3 TPA routing today? > > On Tue, 26 Aug 2008, david raistrick wrote: > >> On Tue, 26 Aug 2008, David Hubbard wrote: >> >>> Anyone seeing issues with Level 3 between anywhere >>> and Tampa, particularly Atlanta and Dallas? We've >> >> Internap just reported problems with L3 out of Miami: >> >> "we are seeing latency, minor packet loss and path problems to a >> number of destinations and other PNAPs via our Level3 (AS3356) upstream >> connection in the MIA003 PNAP. " > > I've been seeing 30-70% packet loss between Cox Business and Level3 from > DC to NY since 8:17pm EDT. Maybe via Internap? > > Loss% Snt Last Avg Best Wrst > StDev > 3. mrfddsrj01-ge706.rd.dc.cox.n 0.0% 100 2.4 5.1 2.2 51.9 > 8.3 > 4. xe-9-2-0.edge1.Washington1.L 67.0% 100 2.5 6.8 2.4 41.6 > 8.6 > 5. vlan99.csw4.Washington1.Leve 69.0% 100 2.7 8.3 2.6 23.7 > 5.0 > 6. ae-93-93.ebr3.Washington1.Le 68.0% 100 3.0 9.9 2.7 30.9 > 6.3 > 7. ae-3.ebr3.NewYork1.Level3.ne 70.0% 100 10.5 15.8 8.1 44.2 > 8.8 > 8. ae-83-83.csw3.NewYork1.Level 71.0% 100 18.9 14.2 8.1 42.0 > 7.1 > 9. ae-31-89.car1.NewYork1.Level 66.0% 100 8.6 25.7 8.5 165.4 > 41.7 > > Beckman > -------------------------------------------------------------------------- > - > Peter Beckman Internet > Guy > beckman at angryox.com > http://www.angryox.com/ > -------------------------------------------------------------------------- > - > > > From iljitsch at muada.com Wed Aug 27 02:48:01 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 27 Aug 2008 09:48:01 +0200 Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> References: <48B49647.3050106@ibctech.ca> <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> Message-ID: <648F6AC0-ACC3-4DCC-B839-079873482523@muada.com> On 27 aug 2008, at 7:58, Paul Wall wrote: >> - single loopback/single IP for all peers, or; >> - each peer with its own loopback/IP? > You should use caution when using loopback IP addresses and building > external multihop BGP sessions. By permitting external devices to > transmit packets to your loopback(s), you open the door to > spoof/denial of service attacks. [...] Indeed. I would use two loopbacks, one for internal stuff that is unreachable from the outside, another one from another range that allows the external sessions. But that's more a question of ease of management than of risk, because if people can do something bad using one loopback address, it really doesn't matter much that additional ones are better protected. From peterkcc2001 at gmail.com Wed Aug 27 06:11:41 2008 From: peterkcc2001 at gmail.com (kcc) Date: Wed, 27 Aug 2008 07:11:41 -0400 Subject: interger to I P address Message-ID: Hi all ls it possible t convert the interger to ip Thank you From simon at slimey.org Wed Aug 27 06:13:04 2008 From: simon at slimey.org (Simon Lockhart) Date: Wed, 27 Aug 2008 12:13:04 +0100 Subject: interger to I P address In-Reply-To: References: Message-ID: <20080827111304.GL16377@virtual.bogons.net> On Wed Aug 27, 2008 at 07:11:41AM -0400, kcc wrote: > ls it possible t convert the interger to ip Yes. Simon From peterkcc2001 at gmail.com Wed Aug 27 06:14:37 2008 From: peterkcc2001 at gmail.com (kcc) Date: Wed, 27 Aug 2008 07:14:37 -0400 Subject: interger to I P address In-Reply-To: <20080827111304.GL16377@virtual.bogons.net> References: <20080827111304.GL16377@virtual.bogons.net> Message-ID: I search google but couldn't get any solution Can you send me information? Thank you On Wed, Aug 27, 2008 at 7:13 AM, Simon Lockhart wrote: > On Wed Aug 27, 2008 at 07:11:41AM -0400, kcc wrote: > > ls it possible t convert the interger to ip > > Yes. > > Simon > From jeroen at unfix.org Wed Aug 27 06:20:13 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Aug 2008 13:20:13 +0200 Subject: interger to I P address In-Reply-To: <20080827111304.GL16377@virtual.bogons.net> References: <20080827111304.GL16377@virtual.bogons.net> Message-ID: <48B5386D.6050000@spaghetti.zurich.ibm.com> Simon Lockhart wrote: > On Wed Aug 27, 2008 at 07:11:41AM -0400, kcc wrote: >> ls it possible t convert the interger to ip > > Yes. If you are using 128-bit integers, which according to some will also change some day, thus one should be using "struct addrinfo" and: getaddrinfo() getnameinfo() as those are the girlfriends of programmers. Note that one should effectively avoid inet_pton/inet_ntop as they still require the programmer to know about address families, the get*info() ones ignore all those details. Also see Itojun's (RIP :( ) excellent document at: http://www.kame.net/newsletter/19980604/ and of course Eva's document at: http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html 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 karnaugh at karnaugh.za.net Wed Aug 27 06:21:26 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 27 Aug 2008 13:21:26 +0200 Subject: interger to I P address In-Reply-To: References: <20080827111304.GL16377@virtual.bogons.net> Message-ID: <48B538B6.6030209@karnaugh.za.net> kcc wrote: > I search google but couldn't get any solution > > Can you send me information? Sure! http://www.catb.org/~esr/faqs/smart-questions.html From steve at ibctech.ca Wed Aug 27 07:16:01 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Aug 2008 08:16:01 -0400 Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: <648F6AC0-ACC3-4DCC-B839-079873482523@muada.com> References: <48B49647.3050106@ibctech.ca> <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> <648F6AC0-ACC3-4DCC-B839-079873482523@muada.com> Message-ID: <48B54581.5090808@ibctech.ca> Iljitsch van Beijnum wrote: > On 27 aug 2008, at 7:58, Paul Wall wrote: > >>> - single loopback/single IP for all peers, or; >>> - each peer with its own loopback/IP? > >> You should use caution when using loopback IP addresses and building >> external multihop BGP sessions. By permitting external devices to >> transmit packets to your loopback(s), you open the door to >> spoof/denial of service attacks. > > [...] > > Indeed. I would use two loopbacks, one for internal stuff that is > unreachable from the outside, another one from another range that allows > the external sessions. > > But that's more a question of ease of management than of risk, because > if people can do something bad using one loopback address, it really > doesn't matter much that additional ones are better protected. Thanks for the feedback. The only reason I use loopbacks for eBGP multihop is so that if one of my physical interfaces goes down taking a transit link with it, these particular sessions will attempt to re-establish via another path. Would someone be so kind as to point me in the direction of some documentation that describes the drawbacks (regarding the mentioned possibility of DoS/spoof attacks) of externally accessible loopbacks? I'm drawing a blank on why this is any more risky than having a peering session (multihop) on a physical interface. Would it be best if I configured the peering sessions on a physical interface instead? Steve From MatlockK at exempla.org Wed Aug 27 07:18:48 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Wed, 27 Aug 2008 06:18:48 -0600 Subject: interger to I P address References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> Easiest way. Take the integer, plug it into windows 'calc'. Go to 'View: Scientific'. Hit 'Hex'. That will show you the hex representation of the integer. Notice that it's either 7 or 8 characters long. If it's 7, prepend it with a 0. Break that into 4 groups of 2. Those are the hex values for the four dotted quads. Make sure 'Hex' is still selected, and put in the first 2 characters, then hit 'binary'. That's your first part of the IP. Repeat for the other 3. For example, you have 1089055123 for an integer. In Hex thats 40E9A993. 40 Hex = 64 E9 Hex = 233 A9 Hex = 169 94 Hex = 147 So your IP is 64.233.169.147 Ken ________________________________ From: Colin Alston [mailto:karnaugh at karnaugh.za.net] Sent: Wed 8/27/2008 5:21 AM To: kcc Cc: nanog at nanog.org Subject: Re: interger to I P address kcc wrote: > I search google but couldn't get any solution > > Can you send me information? Sure! http://www.catb.org/~esr/faqs/smart-questions.html From iljitsch at muada.com Wed Aug 27 07:25:40 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 27 Aug 2008 14:25:40 +0200 Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: <48B54581.5090808@ibctech.ca> References: <48B49647.3050106@ibctech.ca> <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> <648F6AC0-ACC3-4DCC-B839-079873482523@muada.com> <48B54581.5090808@ibctech.ca> Message-ID: On 27 aug 2008, at 14:16, Steve Bertrand wrote: > The only reason I use loopbacks for eBGP multihop is so that if one > of my physical interfaces goes down taking a transit link with it, > these particular sessions will attempt to re-establish via another > path. Actually they should stay up. > Would someone be so kind as to point me in the direction of some > documentation that describes the drawbacks (regarding the mentioned > possibility of DoS/spoof attacks) of externally accessible loopbacks? Apart from general vulnerabilities that are possible on services open to the internet and password brute forcing it's mainly a question of TCP RST packets on the BGP session, which an MD5 password will protect you from. But then an attacker can try to bring down your route processor CPU because the MD5 calculations use much more CPU time than they should. Or simply overload the input buffers. (If someone with this level of knowledge is out to get you you're pretty much screwed whatever you do, though...) > I'm drawing a blank on why this is any more risky than having a > peering session (multihop) on a physical interface. It isn't. > Would it be best if I configured the peering sessions on a physical > interface instead? No, physical interfaces can go down. The advantage of a separate loopback address is that if you ever have any trouble, you can simply remove that address and the trouble is gone, too. This wouldn't work for the loopback address you also use for iBGP or a physical interface. From iljitsch at muada.com Wed Aug 27 07:27:24 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 27 Aug 2008 14:27:24 +0200 Subject: interger to I P address In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> Message-ID: <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> On 27 aug 2008, at 14:18, Matlock, Kenneth L wrote: > Easiest way. $ ping 1089055123 PING 1089055123 (64.233.169.147): 56 data bytes 64 bytes from 64.233.169.147: icmp_seq=0 ttl=242 time=105.418 ms 64 bytes from 64.233.169.147: icmp_seq=1 ttl=242 time=105.891 ms ^C --- 1089055123 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 105.418/105.655/105.891/0.236 ms :-) From steve at ibctech.ca Wed Aug 27 07:39:10 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Aug 2008 08:39:10 -0400 Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: References: <48B49647.3050106@ibctech.ca> <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> <648F6AC0-ACC3-4DCC-B839-079873482523@muada.com> <48B54581.5090808@ibctech.ca> Message-ID: <48B54AEE.40007@ibctech.ca> Iljitsch van Beijnum wrote: > The advantage of a separate loopback address is that if you ever have > any trouble, you can simply remove that address and the trouble is gone, > too. This wouldn't work for the loopback address you also use for iBGP > or a physical interface. Ok. It probably would have made much more sense in my original post to clarify that each eBGP multihop peer session is configured on separate loopback interfaces, apart from the ones I use internally. Generally, I leave lo0 as-is, lo1 for internal, then configure each eBGP multihop peer on an incremental loopback basis thereafter. So, in essence, I'll continue to use a loopback (separate from internal functions) for ebgp-multihop peers, but instead of each session having its own interface/IP, I'll share one for all of them. Thanks everyone! Steve From bortzmeyer at nic.fr Wed Aug 27 08:08:56 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 27 Aug 2008 15:08:56 +0200 Subject: interger to I P address In-Reply-To: <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> Message-ID: <20080827130856.GA7292@nic.fr> On Wed, Aug 27, 2008 at 02:27:24PM +0200, Iljitsch van Beijnum wrote a message of 14 lines which said: >> Easiest way. > > $ ping 1089055123 > PING 1089055123 (64.233.169.147): 56 data bytes It relies on an undocumented feature (it is not in RFC 791, nor in getaddrinfo() manual) :-) From MatlockK at exempla.org Wed Aug 27 08:46:36 2008 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Wed, 27 Aug 2008 07:46:36 -0600 Subject: interger to I P address In-Reply-To: <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> Huh, learn something new every day! Well, at least my method shows the underlying theory behind how the conversion works :) Thanks! Ken Matlock Network Analyst (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] Sent: Wednesday, August 27, 2008 6:27 AM To: Matlock, Kenneth L Cc: Colin Alston; kcc; nanog at nanog.org Subject: Re: interger to I P address On 27 aug 2008, at 14:18, Matlock, Kenneth L wrote: > Easiest way. $ ping 1089055123 PING 1089055123 (64.233.169.147): 56 data bytes 64 bytes from 64.233.169.147: icmp_seq=0 ttl=242 time=105.418 ms 64 bytes from 64.233.169.147: icmp_seq=1 ttl=242 time=105.891 ms ^C --- 1089055123 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 105.418/105.655/105.891/0.236 ms :-) From robert at ufl.edu Wed Aug 27 08:55:37 2008 From: robert at ufl.edu (Robert D. Scott) Date: Wed, 27 Aug 2008 09:55:37 -0400 Subject: interger to I P address In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> Message-ID: <013101c9084c$9568a650$c039f2f0$@edu> The harder way: Decimal: 1089055123 Hex (dashes inserted at octals): 40-E9-A9-93 Decimal (of each octet): 64-233-169-147 IP Address: 64.233.169.147 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 321-663-0421 Cell -----Original Message----- From: Matlock, Kenneth L [mailto:MatlockK at exempla.org] Sent: Wednesday, August 27, 2008 9:47 AM To: Iljitsch van Beijnum Cc: nanog at nanog.org Subject: RE: interger to I P address Huh, learn something new every day! Well, at least my method shows the underlying theory behind how the conversion works :) Thanks! Ken Matlock Network Analyst (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] Sent: Wednesday, August 27, 2008 6:27 AM To: Matlock, Kenneth L Cc: Colin Alston; kcc; nanog at nanog.org Subject: Re: interger to I P address On 27 aug 2008, at 14:18, Matlock, Kenneth L wrote: > Easiest way. $ ping 1089055123 PING 1089055123 (64.233.169.147): 56 data bytes 64 bytes from 64.233.169.147: icmp_seq=0 ttl=242 time=105.418 ms 64 bytes from 64.233.169.147: icmp_seq=1 ttl=242 time=105.891 ms ^C --- 1089055123 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 105.418/105.655/105.891/0.236 ms :-) From karnaugh at karnaugh.za.net Wed Aug 27 09:04:29 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 27 Aug 2008 16:04:29 +0200 Subject: interger to I P address In-Reply-To: <013101c9084c$9568a650$c039f2f0$@edu> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> <013101c9084c$9568a650$c039f2f0$@edu> Message-ID: <48B55EED.4070700@karnaugh.za.net> Robert D. Scott wrote: > The harder way: > > Decimal: 1089055123 > Hex (dashes inserted at octals): 40-E9-A9-93 > Decimal (of each octet): 64-233-169-147 > IP Address: 64.233.169.147 The Python way >>> import socket, struct >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) '64.233.169.147' From michael.holstein at csuohio.edu Wed Aug 27 09:13:13 2008 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 27 Aug 2008 10:13:13 -0400 Subject: interger to I P address In-Reply-To: References: Message-ID: <48B560F9.4050605@csuohio.edu> > ls it possible t convert the interger to ip > #!/usr/local/bin/perl # Perl script to convert between numeric and dotted quad IPs. # give credit to Paul Gregg for this one while () { chomp; $input = $_; if (/\./) { ($a, $b, $c, $d) = split(/\./); $decimal = $d + ($c * 256) + ($b * 256**2) + ($a * 256**3); } else { $decimal = $_; $d = $_ % 256; $_ -= $d; $_ /= 256; $c = $_ % 256; $_ -= $c; $_ /= 256; $b = $_ % 256; $_ -= $b; $_ /= 256; $a = $_; } if ( ($a>255) || ($b>255) || ($c>255) || ($d>255) ) { print "$0: Invalid input: $input\n"; } else { printf ("Address: %d.%d.%d.%d is %u (Hex:%02x%02x%02x%02x)\n", $a,$b,$c,$d, $decimal,$a,$b,$c,$d); } } From peter at peter-dambier.de Wed Aug 27 09:19:26 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Wed, 27 Aug 2008 16:19:26 +0200 Subject: interger to I P address In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> Message-ID: <48B5626E.5070906@peter-dambier.de> For the curious, have a look at the IASON tools http://iason.site.voila.fr/ and try c:~$ natnum 1089055123 host_look("64.233.169.147","1089055123","1089055123"). host_name("64.233.169.147","yo-in-f147.google.com"). natnum takes a hostname, an integer or an IPv4 address and shows you the IPv4 address, the integer and the hostname. If you do maintain your /etc/hosts it will tell you the aliases too. Most of the stuff is unix only, but I guess you can compile natnum even for windows. Kind regards Peter Matlock, Kenneth L wrote: > Easiest way. > > Take the integer, plug it into windows 'calc'. > > Go to 'View: Scientific'. > > Hit 'Hex'. That will show you the hex representation of the integer. Notice that it's either 7 or 8 characters long. > > If it's 7, prepend it with a 0. > > Break that into 4 groups of 2. Those are the hex values for the four dotted quads. > > Make sure 'Hex' is still selected, and put in the first 2 characters, then hit 'binary'. That's your first part of the IP. Repeat for the other 3. > > For example, you have 1089055123 for an integer. > > In Hex thats 40E9A993. > > 40 Hex = 64 > E9 Hex = 233 > A9 Hex = 169 > 94 Hex = 147 > > So your IP is 64.233.169.147 > > Ken > > > ________________________________ > > From: Colin Alston [mailto:karnaugh at karnaugh.za.net] > Sent: Wed 8/27/2008 5:21 AM > To: kcc > Cc: nanog at nanog.org > Subject: Re: interger to I P address > > > > kcc wrote: >> I search google but couldn't get any solution >> >> Can you send me information? > > Sure! > > http://www.catb.org/~esr/faqs/smart-questions.html > > > -- 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 eric at atlantech.net Wed Aug 27 09:35:37 2008 From: eric at atlantech.net (Eric Van Tol) Date: Wed, 27 Aug 2008 10:35:37 -0400 Subject: interger to I P address In-Reply-To: References: Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC378@exchange.aoihq.local> > -----Original Message----- > From: kcc [mailto:peterkcc2001 at gmail.com] > Sent: Wednesday, August 27, 2008 7:12 AM > To: nanog at nanog.org > Subject: interger to I P address > > Hi all > > ls it possible t convert the interger to ip > > Thank you My two cents: # ping 1089055123 PING 1089055123 (64.233.169.147) 56(84) bytes of data. 64 bytes from 64.233.169.147: icmp_seq=1 ttl=248 time=2.55 ms 64 bytes from 64.233.169.147: icmp_seq=2 ttl=248 time=2.00 ms To do in reverse, you can use 'sipcalc': # sipcalc 64.233.169.147 -[ipv4 : 64.233.169.147] - 0 [CIDR] Host address - 64.233.169.147 Host address (decimal) - 1089055123 Host address (hex) - 40E9A993 Network address - 64.233.169.147 Network mask - 255.255.255.255 Network mask (bits) - 32 Network mask (hex) - FFFFFFFF Broadcast address - 64.233.169.147 Cisco wildcard - 0.0.0.0 Addresses in network - 1 Network range - 64.233.169.147 - 64.233.169.147 -evt From shadow at apollo.gti.net Wed Aug 27 09:25:10 2008 From: shadow at apollo.gti.net (Shadow) Date: Wed, 27 Aug 2008 10:25:10 -0400 (EDT) Subject: interger to I P address In-Reply-To: <48B55EED.4070700@karnaugh.za.net> Message-ID: <20080827101756.K71371-100000@apollo.gti.net> Robert D. Scott wrote: > The harder way: > > Decimal: 1089055123 > Hex (dashes inserted at octals): 40-E9-A9-93 > Decimal (of each octet): 64-233-169-147 > IP Address: 64.233.169.147 The "this could take all day" way : (in bc with scale=0 for integer portions only) 1089055123/(2^24)%(2^8) 64 1089055123/(2^16)%(2^8) 233 1089055123/(2^8)%(2^8) 169 1089055123/(2^0)%(2^8) 147 (Note: 2^0=1 & x/1=x so last line could reduce to 1089055123%(2^8).) -Nicholas shadow at gti.net From davei at otd.com Wed Aug 27 10:22:14 2008 From: davei at otd.com (Dave Israel) Date: Wed, 27 Aug 2008 11:22:14 -0400 Subject: interger to I P address In-Reply-To: <20080827101756.K71371-100000@apollo.gti.net> References: <20080827101756.K71371-100000@apollo.gti.net> Message-ID: <48B57126.6060402@otd.com> Normally, I don't participate in this sort of thing, but I'm a sucker for a "there's more than one way to do it" challenge. Shadow wrote: > Robert D. Scott wrote: > >> The harder way: >> >> Decimal: 1089055123 >> Hex (dashes inserted at octals): 40-E9-A9-93 >> Decimal (of each octet): 64-233-169-147 >> IP Address: 64.233.169.147 >> > > > The "this could take all day" way : > > (in bc with scale=0 for integer portions only) > > 1089055123/(2^24)%(2^8) > 64 > 1089055123/(2^16)%(2^8) > 233 > 1089055123/(2^8)%(2^8) > 169 > 1089055123/(2^0)%(2^8) > 147 > > (Note: 2^0=1 & x/1=x so last line could reduce to 1089055123%(2^8).) > > -Nicholas > shadow at gti.net > > The "ugly, please adjust according to your endianness, etc" way: int *dec; unsigned char *oct1, *oct2, *oct3, *oct4; main(int argc, char **argv) { dec = malloc(sizeof(int)); *dec = 1089055123; oct4 = dec; oct3 = oct4 + sizeof(char); oct2 = oct3 + sizeof(char); oct1 = oct2 + sizeof(char); printf("dec: %lu ip: %hu.%hu.%hu.%hu\n", *dec, *oct1, *oct2, *oct3, *oct4); } From andree+nanog at toonk.nl Wed Aug 27 10:50:44 2008 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 27 Aug 2008 17:50:44 +0200 Subject: interger to I P address In-Reply-To: <48B55EED.4070700@karnaugh.za.net> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> <013101c9084c$9568a650$c039f2f0$@edu> <48B55EED.4070700@karnaugh.za.net> Message-ID: <20080827155044.GB24576@toonk.nl> .-- My secret spy satellite informs me that at Wed, 27 Aug 2008, Colin Alston wrote: >> The harder way: >> >> Decimal: 1089055123 >> Hex (dashes inserted at octals): 40-E9-A9-93 >> Decimal (of each octet): 64-233-169-147 >> IP Address: 64.233.169.147 > > The Python way > > >>> import socket, struct > >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) > '64.233.169.147' The Perl way: sub ntoa { my $one = shift; my $four = $one & 0xff; $one >>= 8; my $three = $one & 0xff; $one >>= 8; my $two = $one & 0xff; $one >>= 8; return "$one.$two.$three.$four"; } #or in one line, like ipcalc does: sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } print ntoa(1089055123) . "\n"; print ntoa_in_one_line(1089055123) . "\n"; Cheers, Andree -- Andree Toonk http://www.toonk.ca/blog/ From ernst at easystreet.com Wed Aug 27 11:00:21 2008 From: ernst at easystreet.com (Rick Ernst) Date: Wed, 27 Aug 2008 09:00:21 -0700 (PDT) Subject: BGP, ebgp-multihop and multiple peers In-Reply-To: <48B54AEE.40007@ibctech.ca> References: <48B49647.3050106@ibctech.ca> <620fd17c0808262258i5208641cjd4808091795a46e1@mail.gmail.com> <648F6AC0-ACC3-4DCC-B839-079873482523@muada.com> <48B54581.5090808@ibctech.ca> <48B54AEE.40007@ibctech.ca> Message-ID: <47254.69.30.17.85.1219852821.squirrel@www.woofpaws.com> If you keep a separate peering/loopback-IP for each peer, you can move individual peering sessions to other devices if needed. On Wed, August 27, 2008 05:39, Steve Bertrand wrote: > Iljitsch van Beijnum wrote: > >> The advantage of a separate loopback address is that if you ever have >> any trouble, you can simply remove that address and the trouble is gone, >> too. This wouldn't work for the loopback address you also use for iBGP >> or a physical interface. > > Ok. It probably would have made much more sense in my original post to > clarify that each eBGP multihop peer session is configured on separate > loopback interfaces, apart from the ones I use internally. > > Generally, I leave lo0 as-is, lo1 for internal, then configure each eBGP > multihop peer on an incremental loopback basis thereafter. > > So, in essence, I'll continue to use a loopback (separate from internal > functions) for ebgp-multihop peers, but instead of each session having > its own interface/IP, I'll share one for all of them. > > Thanks everyone! > > Steve > From bepstein at ias.edu Wed Aug 27 11:11:34 2008 From: bepstein at ias.edu (Brian Epstein) Date: Wed, 27 Aug 2008 12:11:34 -0400 Subject: interger to I P address In-Reply-To: <20080827155044.GB24576@toonk.nl> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> <013101c9084c$9568a650$c039f2f0$@edu> <48B55EED.4070700@karnaugh.za.net> <20080827155044.GB24576@toonk.nl> Message-ID: <48B57CB6.8030500@ias.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/2008 11:50 AM, Andree Toonk wrote: | #or in one line, like ipcalc does: | sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } For completeness: sub aton_in_one_line { unpack('N',pack('C4',split(/\./,$_[0]))); } Thanks, ep - -- Brian Epstein +1 609-734-8179 Network and Security Officer Institute for Advanced Study Key fingerprint = 128A 38F4 4CFA 5EDB 99CE 4734 6117 4C25 0371 C12A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFItXy2YRdMJQNxwSoRAvVpAJwIZSnjfTxXKRo0IR4JykMfxFECRwCgzDMS EUi/2U9FwoaIEnygJIWIV1o= =dQ4q -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3296 bytes Desc: S/MIME Cryptographic Signature URL: From michael.holstein at csuohio.edu Wed Aug 27 11:16:51 2008 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 27 Aug 2008 12:16:51 -0400 Subject: interger to I P address In-Reply-To: <48B57CB6.8030500@ias.edu> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> <013101c9084c$9568a650$c039f2f0$@edu> <48B55EED.4070700@karnaugh.za.net> <20080827155044.GB24576@toonk.nl> <48B57CB6.8030500@ias.edu> Message-ID: <48B57DF3.1040903@csuohio.edu> In MySQL : mysql> SELECT INET_NTOA(ip_in_decimal) AS ipa; .. or the reverse : mysql> SELECT INET_ATON('dotted.quad') AS ipn; From mike at mtcc.com Wed Aug 27 11:22:40 2008 From: mike at mtcc.com (Michael Thomas) Date: Wed, 27 Aug 2008 09:22:40 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <20080826230331.D74464500F@ptavv.es.net> References: <20080826230331.D74464500F@ptavv.es.net> Message-ID: <48B57F50.2040506@mtcc.com> Kevin Oberman wrote: >> Date: Tue, 26 Aug 2008 16:53:24 -0400 >> From: "Bill Bogstad" >> >> Not sure what this will actually mean in the long run, but it's at >> least worth noting. >> >> http://www.gcn.com/online/vol1_no1/46987-1.html >> http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf > > It will mean something in the medium term as '.gov' and '.org' will be > signed very soon and OMB might be able to even get the root > signed. (Since OMB can pull funding, no one argues with them much.) > All of this will increase pressure on Verisign to deal with '.com' and > '.net'. > > Note that this only has an impact on '.gov' and the zones immediately > below it, but I suspect most sub-domains of *.gov will be signed as a > result of this, even if it is not required. So the question I have is... will operators (ISP, etc) turn on DNSsec checking? Or a more basic question of whether you even _could_ turn on checking if you were so inclined? Mike From jared at puck.nether.net Wed Aug 27 11:33:31 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Aug 2008 12:33:31 -0400 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <48B57F50.2040506@mtcc.com> References: <20080826230331.D74464500F@ptavv.es.net> <48B57F50.2040506@mtcc.com> Message-ID: <20080827163331.GA53580@puck.nether.net> On Wed, Aug 27, 2008 at 09:22:40AM -0700, Michael Thomas wrote: > Kevin Oberman wrote: >>> Date: Tue, 26 Aug 2008 16:53:24 -0400 >>> From: "Bill Bogstad" >>> >>> Not sure what this will actually mean in the long run, but it's at >>> least worth noting. >>> >>> http://www.gcn.com/online/vol1_no1/46987-1.html >>> http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf >> >> It will mean something in the medium term as '.gov' and '.org' will be >> signed very soon and OMB might be able to even get the root >> signed. (Since OMB can pull funding, no one argues with them much.) >> All of this will increase pressure on Verisign to deal with '.com' and >> '.net'. >> >> Note that this only has an impact on '.gov' and the zones immediately >> below it, but I suspect most sub-domains of *.gov will be signed as a >> result of this, even if it is not required. > > So the question I have is... will operators (ISP, etc) turn on DNSsec > checking? Or a more basic question of whether you even _could_ turn on > checking if you were so inclined? I know that we made sure it was turned on as part of our patch process for our customer facing resolvers. IIRC the default may have changed in bind as well if you actually read the changelog. 2405. [cleanup] The default value for dnssec-validation was changed to "yes" in 9.5.0-P1 and all subsequent releases; this was inadvertently omitted from CHANGES at the time. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From Benjamin.R.Boyd at windstream.com Wed Aug 27 11:38:27 2008 From: Benjamin.R.Boyd at windstream.com (Boyd, Benjamin R) Date: Wed, 27 Aug 2008 11:38:27 -0500 Subject: interger to I P address Message-ID: <3F045502966C304B963C72E3C442750EB8C86F@scarlitnt840.windstream.com> >>> The harder way: >>> >>> Decimal: 1089055123 >>> Hex (dashes inserted at octals): 40-E9-A9-93 Decimal (of >each octet): >>> 64-233-169-147 IP Address: 64.233.169.147 >> >> The Python way >> >> >>> import socket, struct >> >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) >> '64.233.169.147' > >The Perl way: > >sub ntoa >{ > my $one = shift; > my $four = $one & 0xff; > $one >>= 8; > my $three = $one & 0xff; > $one >>= 8; > my $two = $one & 0xff; > $one >>= 8; > return "$one.$two.$three.$four"; >} > >#or in one line, like ipcalc does: >sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } > >print ntoa(1089055123) . "\n"; >print ntoa_in_one_line(1089055123) . "\n"; > > The PHP way: function convertIntegerToIpv4($integer) { $max_value = pow(2,32); //4,294,967,296 $bug_fix = 0; settype($integer, float); if($integer > 2147483647) $bug_fix = 16777216; if(is_numeric($integer)) { if ($integer >= $max_value || $integer < 0) { return ('Not a valid IPv4 integer'); } $ip = (sprintf("%u.%u.%u.%u", $integer / 16777216, (($integer % 16777216) + $bug_fix) / 65536, (($integer % 65536) + $bug_fix / 256) / 256, ($integer % 256) + $bug_fix / 256 / 256 ) ); return($ip); } else { return(''); } } *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From bfeeny at mac.com Wed Aug 27 11:47:13 2008 From: bfeeny at mac.com (bfeeny at mac.com) Date: Wed, 27 Aug 2008 16:47:13 +0000 Subject: interger to I P address Message-ID: <1253439078-1219855603-cardhu_decombobulator_blackberry.rim.net-2072996636-@bxe106.bisx.prod.on.blackberry> The NANOG way: www.google.com ------Original Message------ From: Boyd, Benjamin R To: Andree Toonk To: nanog at nanog.org Sent: Aug 27, 2008 12:38 PM Subject: RE: interger to I P address >>> The harder way: >>> >>> Decimal: 1089055123 >>> Hex (dashes inserted at octals): 40-E9-A9-93 Decimal (of >each octet): >>> 64-233-169-147 IP Address: 64.233.169.147 >> >> The Python way >> >> >>> import socket, struct >> >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) >> '64.233.169.147' > >The Perl way: > >sub ntoa >{ > my $one = shift; > my $four = $one & 0xff; > $one >>= 8; > my $three = $one & 0xff; > $one >>= 8; > my $two = $one & 0xff; > $one >>= 8; > return "$one.$two.$three.$four"; >} > >#or in one line, like ipcalc does: >sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } > >print ntoa(1089055123) . "\n"; >print ntoa_in_one_line(1089055123) . "\n"; > > The PHP way: function convertIntegerToIpv4($integer) { $max_value = pow(2,32); //4,294,967,296 $bug_fix = 0; settype($integer, float); if($integer > 2147483647) $bug_fix = 16777216; if(is_numeric($integer)) { if ($integer >= $max_value || $integer < 0) { return ('Not a valid IPv4 integer'); } $ip = (sprintf("%u.%u.%u.%u", $integer / 16777216, (($integer % 16777216) + $bug_fix) / 65536, (($integer % 65536) + $bug_fix / 256) / 256, ($integer % 256) + $bug_fix / 256 / 256 ) ); return($ip); } else { return(''); } } *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. Sent from my Verizon Wireless BlackBerry From bygg at cafax.se Wed Aug 27 18:51:27 2008 From: bygg at cafax.se (Johnny Eriksson) Date: Wed, 27 Aug 2008 18:51:27 WET DST Subject: interger to I P address In-Reply-To: Your message of Wed, 27 Aug 2008 16:04:29 +0200 Message-ID: > Robert D. Scott wrote: > > The harder way: > > > > Decimal: 1089055123 > > Hex (dashes inserted at octals): 40-E9-A9-93 > > Decimal (of each octet): 64-233-169-147 > > IP Address: 64.233.169.147 > > The Python way > > >>> import socket, struct > >>> socket.inet_ntoa(struct.pack('>l', 1089055123)) > '64.233.169.147' The Tops-10/DDT way: .r ddt DDT 0! 1089055123. lsh 4$x <> $10r$8o0/ 64.,233.,169.,147.,0. ^Z . --Johnny From oberman at es.net Wed Aug 27 11:53:26 2008 From: oberman at es.net (Kevin Oberman) Date: Wed, 27 Aug 2008 09:53:26 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: Your message of "Wed, 27 Aug 2008 09:22:40 PDT." <48B57F50.2040506@mtcc.com> Message-ID: <20080827165326.E0D204500F@ptavv.es.net> > Date: Wed, 27 Aug 2008 09:22:40 -0700 > From: Michael Thomas > > Kevin Oberman wrote: > >> Date: Tue, 26 Aug 2008 16:53:24 -0400 > >> From: "Bill Bogstad" > >> > >> Not sure what this will actually mean in the long run, but it's at > >> least worth noting. > >> > >> http://www.gcn.com/online/vol1_no1/46987-1.html > >> http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf > > > > It will mean something in the medium term as '.gov' and '.org' will be > > signed very soon and OMB might be able to even get the root > > signed. (Since OMB can pull funding, no one argues with them much.) > > All of this will increase pressure on Verisign to deal with '.com' and > > '.net'. > > > > Note that this only has an impact on '.gov' and the zones immediately > > below it, but I suspect most sub-domains of *.gov will be signed as a > > result of this, even if it is not required. > > So the question I have is... will operators (ISP, etc) turn on DNSsec > checking? Or a more basic question of whether you even _could_ turn on > checking if you were so inclined? As far as I can see, at least with bind-9.5, operators would have to turn it off. It looks to me like dnssec-validation defaults to on. It also appears that bind-9.4 defaults to 'off'. -- 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 karnaugh at karnaugh.za.net Wed Aug 27 12:01:02 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 27 Aug 2008 19:01:02 +0200 Subject: interger to I P address In-Reply-To: <48B57126.6060402@otd.com> References: <20080827101756.K71371-100000@apollo.gti.net> <48B57126.6060402@otd.com> Message-ID: <48B5884E.9040703@karnaugh.za.net> On 2008/08/27 05:22 PM Dave Israel wrote: > > Normally, I don't participate in this sort of thing, but I'm a sucker > for a "there's more than one way to do it" challenge. Aww come on, C gets way more "fun" than that ;) #define _u8 unsigned char #define _u32 unsigned long int main(void) { _u32 ipn = 1089055123; _u8 ipa[3]; _u8 oct = 0; for (oct=0; oct <4; oct++){ ipa[oct] = (char)( (ipn & (0xFF000000 >> (8*oct))) >> (8*(3-oct)) ); } printf("%d.%d.%d.%d\n", ipa[0], ipa[1], ipa[2], ipa[3]); return 0; } From chartley at oar.net Wed Aug 27 12:00:41 2008 From: chartley at oar.net (chartley at oar.net) Date: Wed, 27 Aug 2008 13:00:41 -0400 (EDT) Subject: interger to I P address Message-ID: <20080827170047.40951BBB84@rebma.osc.edu> Sorry to be continuing this thread, but I find a certain kind of elegance in bash which isn't actually there, but helps me sleep at night. bash# iptoint(){ oct1=`echo $1|awk -F\. '{print $1}'`; oct2=`echo $1|awk -F\. '{print $2}'`; oct3=`echo $1|awk -F\. '{print $3}'`; oct4=`echo $1|awk -F\. '{print $4}'`; echo $[($oct1<<24)+($oct2<<16 )+($oct3<<8)+$oct4 ];} bash# inttoip(){ echo $[$1>>24].$[($1>>16)&255].$[($1>>8)&255].$[$1&255]; } bash# inttoip 1089055123 64.233.169.147 bash# iptoint 64.233.169.147 1089055123 Chris From robert at ripe.net Wed Aug 27 12:07:21 2008 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 27 Aug 2008 19:07:21 +0200 Subject: interger to I P address In-Reply-To: <48B5884E.9040703@karnaugh.za.net> References: <20080827101756.K71371-100000@apollo.gti.net> <48B57126.6060402@otd.com> <48B5884E.9040703@karnaugh.za.net> Message-ID: <48B589C9.4040006@ripe.net> Colin Alston wrote: > On 2008/08/27 05:22 PM Dave Israel wrote: >> >> Normally, I don't participate in this sort of thing, but I'm a sucker >> for a "there's more than one way to do it" challenge. > > Aww come on, C gets way more "fun" than that ;) > > #define _u8 unsigned char > #define _u32 unsigned long > > int main(void) { > _u32 ipn = 1089055123; > _u8 ipa[3]; > _u8 oct = 0; > > > for (oct=0; oct <4; oct++){ > ipa[oct] = (char)( > (ipn & (0xFF000000 >> (8*oct))) >> (8*(3-oct)) > ); > } > > printf("%d.%d.%d.%d\n", ipa[0], ipa[1], ipa[2], ipa[3]); > > return 0; > } Actually, who needs loops for that? #include int main() { unsigned i = 1089055123; printf("%d.%d.%d.%d\n", (unsigned char)(((char*)&i)[3]), (unsigned char)(((char*)&i)[2]), (unsigned char)(((char*)&i)[1]), (unsigned char)(((char*)&i)[0]) ); return 0; } Robert From smb at cs.columbia.edu Wed Aug 27 12:13:42 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 27 Aug 2008 13:13:42 -0400 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <20080827165326.E0D204500F@ptavv.es.net> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> Message-ID: <20080827131342.371009ae@cs.columbia.edu> On Wed, 27 Aug 2008 09:53:26 -0700 "Kevin Oberman" wrote: > > > > So the question I have is... will operators (ISP, etc) turn on > > DNSsec checking? Or a more basic question of whether you even > > _could_ turn on checking if you were so inclined? > > As far as I can see, at least with bind-9.5, operators would have to > turn it off. It looks to me like dnssec-validation defaults to on. It > also appears that bind-9.4 defaults to 'off'. Right. The real questions are the clients and the trust anchor -- what root key do you support? --Steve Bellovin, http://www.cs.columbia.edu/~smb From drc at virtualized.org Wed Aug 27 12:14:48 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Aug 2008 10:14:48 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <20080827163331.GA53580@puck.nether.net> References: <20080826230331.D74464500F@ptavv.es.net> <48B57F50.2040506@mtcc.com> <20080827163331.GA53580@puck.nether.net> Message-ID: On Aug 27, 2008, at 9:33 AM, Jared Mauch wrote: >> So the question I have is... will operators (ISP, etc) turn on DNSsec >> checking? Some ISPs already do (I believe Telia-Sonera in SE in one). >> Or a more basic question of whether you even _could_ turn on >> checking if you were so inclined? You can turn on DNSSEC if you are running BIND 9, Unbound, or Nominum CNS as a caching server. If you are running DJB's dnscache, PowerDNS, or using OpenDNS's service, you don't have the option. If you're running BIND 8 or BIND 4, kill yourself now. > I know that we made sure it was turned on as part of our > patch process for our customer facing resolvers. IIRC the default > may have changed in bind as well if you actually read the changelog. > > 2405. [cleanup] The default value for dnssec-validation was > changed to > "yes" in 9.5.0-P1 and all subsequent releases; this > was inadvertently omitted from CHANGES at the time. In BIND, there appear to be 3 things that have to be configured for DNSSEC to do anything useful: options { dnssec-enable yes; dnssec-validation yes; }; and trusted-keys { ; }; If all of these aren't set correctly, DNSSEC might as well be off. I'm told, however, that BIND (since version 9.1) and Unbound default to always sending the "DNSSEC OK" bit on so if the zone you're talking to is signed, DNSSEC cruft will be returned regardless of whether your caching server is configured to do anything with it. In some future and/or alternate universe, all you'll need is a single trust anchor for the root after it gets signed. Until that time, you have to list the trust anchors for all the zones you want to validate. Right now, there are 4 signed TLDs (SE, BR, PR, BG) and the RIPE in-addr.arpa/ip6.arpa trees are signed. There are also a few other scattered zones that are signed, see http:// secspider.cs.ucla.edu/ for a list. Note that if you do turn on DNSSEC, you're going to have to make sure the trust anchors you configure get updated. Trust anchors have a validity period and if they're not updated before they expire validation will fail (which will appear to users of the resolver pretty much like a DNS failure for all the names in the signed zone). "Be careful out there." Regards, -drc From scott at sonic.net Wed Aug 27 12:21:23 2008 From: scott at sonic.net (Scott Doty) Date: Wed, 27 Aug 2008 10:21:23 -0700 Subject: interger to I P address In-Reply-To: <20080827101756.K71371-100000@apollo.gti.net> References: <48B55EED.4070700@karnaugh.za.net> <20080827101756.K71371-100000@apollo.gti.net> Message-ID: <20080827172123.GA19397@ponzo.net> On Wed, Aug 27, 2008 at 10:25:10AM -0400, Shadow wrote: > > Robert D. Scott wrote: > > The harder way: > > > > Decimal: 1089055123 > > Hex (dashes inserted at octals): 40-E9-A9-93 > > Decimal (of each octet): 64-233-169-147 > > IP Address: 64.233.169.147 > > > The "this could take all day" way : > > (in bc with scale=0 for integer portions only) > > 1089055123/(2^24)%(2^8) > 64 > 1089055123/(2^16)%(2^8) > 233 > 1089055123/(2^8)%(2^8) > 169 > 1089055123/(2^0)%(2^8) > 147 > > (Note: 2^0=1 & x/1=x so last line could reduce to 1089055123%(2^8).) $ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. obase=256 1089055123 064 233 169 147 -Scott From bicknell at ufp.org Wed Aug 27 12:24:05 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Aug 2008 17:24:05 +0000 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: References: <20080826230331.D74464500F@ptavv.es.net> <48B57F50.2040506@mtcc.com> <20080827163331.GA53580@puck.nether.net> Message-ID: <20080827172405.GA96276@ussenterprise.ufp.org> In a message written on Wed, Aug 27, 2008 at 10:14:48AM -0700, David Conrad wrote: > Note that if you do turn on DNSSEC, you're going to have to make sure > the trust anchors you configure get updated. Trust anchors have a > validity period and if they're not updated before they expire > validation will fail (which will appear to users of the resolver > pretty much like a DNS failure for all the names in the signed zone). > "Be careful out there." While signing the root is the best solution, an alternate solution until that happens is DLV, as documented in RFC 4431. You can run your own setup, or trust someone to do it for you. Note that ISC runs a DLV registry, if you wanted to trust them: https://secure.isc.org/index.pl?/ops/dlv/ -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jeroen at unfix.org Wed Aug 27 12:25:03 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Aug 2008 19:25:03 +0200 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <20080827131342.371009ae@cs.columbia.edu> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> <20080827131342.371009ae@cs.columbia.edu> Message-ID: <48B58DEF.2000400@spaghetti.zurich.ibm.com> Steven M. Bellovin wrote: > On Wed, 27 Aug 2008 09:53:26 -0700 > "Kevin Oberman" wrote: > >>> So the question I have is... will operators (ISP, etc) turn on >>> DNSsec checking? Or a more basic question of whether you even >>> _could_ turn on checking if you were so inclined? >> As far as I can see, at least with bind-9.5, operators would have to >> turn it off. It looks to me like dnssec-validation defaults to on. It >> also appears that bind-9.4 defaults to 'off'. > > Right. The real questions are the clients and the trust anchor -- what > root key do you support? A distributed one. I personally don't really see an issue with downloading a public key for every TLD out there. These keys could come in a pack even by an OS distribution, nicely PGP signed et all... Nobody in his right mind manages this per box anymore anyway, and packages for distributions and auto-updates are well-present anyway. The presence of a key file can also mean to the resolver that one can/has_to check dnssec results. 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 jgreco at ns.sol.net Wed Aug 27 12:29:00 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 27 Aug 2008 12:29:00 -0500 (CDT) Subject: interger to I P address In-Reply-To: <20080827170047.40951BBB84@rebma.osc.edu> from "chartley@oar.net" at Aug 27, 2008 01:00:41 PM Message-ID: <200808271729.m7RHT0q7090054@aurora.sol.net> > Sorry to be continuing this thread, but I find a certain kind of elegance in > bash which isn't actually there, but helps me sleep at night. > > bash# iptoint(){ oct1=`echo $1|awk -F\. '{print $1}'`; oct2=`echo $1|awk -F\. '{print $2}'`; oct3=`echo $1|awk -F\. '{print $3}'`; oct4=`echo $1|awk -F\. '{print $4}'`; echo $[($oct1<<24)+($oct2<<16 )+($oct3<<8)+$oct4 ];} > bash# inttoip(){ echo $[$1>>24].$[($1>>16)&255].$[($1>>8)&255].$[$1&255]; } > > bash# inttoip 1089055123 > 64.233.169.147 BASH? Hahaha. Real Admins use sh. More portable(*). Simple: v=$1;for n in 4 3 2;do eval o$n=`expr $v % 256`;v=`expr $v / 256` done; echo $v.$o2.$o3.$o4 Needlessly complex (just to keep up sh's reputation for complexity): v4=$1;for n in 4 3 2;do eval o$n=`eval expr \\$v$n % 256`;eval v`expr $n - 1`=`eval expr \\$v$n / 256` done; echo $v1.$o2.$o3.$o4 $ ipscript 1089055123 64.233.169.147 $ (*) Not a claim of actual portability of this code. Just having fun writing UGLY shell code. ... 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 darden at armc.org Wed Aug 27 12:31:50 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 27 Aug 2008 13:31:50 -0400 Subject: interger to I P address In-Reply-To: <200808271729.m7RHT0q7090054@aurora.sol.net> Message-ID: Somebody's going to bring in Emacs now. Then somebody else will claim VI can do it faster and using less memory.... Argh. ;-) --p -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Wednesday, August 27, 2008 1:29 PM To: chartley at oar.net Cc: nanog at nanog.org Subject: Re: interger to I P address > bash# iptoint(){ oct1=`echo $1|awk -F\. '{print $1}'`; oct2=`echo $1|awk -F\. '{print $2}'`; oct3=`echo $1|awk -F\. '{print $3}'`; oct4=`echo $1|awk -F\. '{print $4}'`; echo $[($oct1<<24)+($oct2<<16 )+($oct3<<8)+$oct4 ];} > bash# inttoip(){ echo $[$1>>24].$[($1>>16)&255].$[($1>>8)&255].$[$1&255]; } > > bash# inttoip 1089055123 > 64.233.169.147 BASH? Hahaha. Real Admins use sh. More portable(*). From oberman at es.net Wed Aug 27 12:35:03 2008 From: oberman at es.net (Kevin Oberman) Date: Wed, 27 Aug 2008 10:35:03 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: Your message of "Wed, 27 Aug 2008 19:25:03 +0200." <48B58DEF.2000400@spaghetti.zurich.ibm.com> Message-ID: <20080827173503.BCDE04500F@ptavv.es.net> > Date: Wed, 27 Aug 2008 19:25:03 +0200 > From: Jeroen Massar > > Steven M. Bellovin wrote: > > On Wed, 27 Aug 2008 09:53:26 -0700 > > "Kevin Oberman" wrote: > > > >>> So the question I have is... will operators (ISP, etc) turn on > >>> DNSsec checking? Or a more basic question of whether you even > >>> _could_ turn on checking if you were so inclined? > >> As far as I can see, at least with bind-9.5, operators would have to > >> turn it off. It looks to me like dnssec-validation defaults to on. It > >> also appears that bind-9.4 defaults to 'off'. > > > > Right. The real questions are the clients and the trust anchor -- what > > root key do you support? > > A distributed one. I personally don't really see an issue with > downloading a public key for every TLD out there. These keys could come > in a pack even by an OS distribution, nicely PGP signed et all... > Nobody in his right mind manages this per box anymore anyway, and > packages for distributions and auto-updates are well-present anyway. > > The presence of a key file can also mean to the resolver that one > can/has_to check dnssec results. How do you propose to establish the initial trust for these keys? How will they be updated? NIST recommends rolling the zone keys every month and the key signing key annually. Files in distributions are way too static for these intervals. (I think NIST's recommendations are extremely excessive, but I am required to comply with them or explain to OMB why not.) This is the reason for the DLV concept and it will be needed (in some form) at least until the root is signed and most likely until .com and .net are signed. -- 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 karnaugh at karnaugh.za.net Wed Aug 27 12:38:59 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 27 Aug 2008 19:38:59 +0200 Subject: interger to I P address In-Reply-To: <48B589C9.4040006@ripe.net> References: <20080827101756.K71371-100000@apollo.gti.net> <48B57126.6060402@otd.com> <48B5884E.9040703@karnaugh.za.net> <48B589C9.4040006@ripe.net> Message-ID: <48B59133.9060201@karnaugh.za.net> On 2008/08/27 07:07 PM Robert Kisteleki wrote: > (unsigned char)(((char*)&i)[3]), Ahh yes, I was trying to remember that pattern. I saw it in an embedded device long ago :P From karnaugh at karnaugh.za.net Wed Aug 27 12:42:16 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Wed, 27 Aug 2008 19:42:16 +0200 Subject: interger to I P address In-Reply-To: <20080827170047.40951BBB84@rebma.osc.edu> References: <20080827170047.40951BBB84@rebma.osc.edu> Message-ID: <48B591F8.2000302@karnaugh.za.net> On 2008/08/27 07:00 PM chartley at oar.net wrote: > Sorry to be continuing this thread, but I find a certain kind of elegance in > bash which isn't actually there, but helps me sleep at night. siza # ping -c 1 1089055123 | head -n 1 | awk '{{{print $3}}}' | sed 's/(\(.*\))/\1/' 64.233.169.147 Ok I'm out of bad ideas so I'll shut up now ;) From jeroen at unfix.org Wed Aug 27 12:51:30 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Aug 2008 19:51:30 +0200 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <20080827173503.BCDE04500F@ptavv.es.net> References: <20080827173503.BCDE04500F@ptavv.es.net> Message-ID: <48B59422.5020905@spaghetti.zurich.ibm.com> Kevin Oberman wrote: [..] >>> Right. The real questions are the clients and the trust anchor -- what >>> root key do you support? >> A distributed one. I personally don't really see an issue with >> downloading a public key for every TLD out there. These keys could come >> in a pack even by an OS distribution, nicely PGP signed et all... >> Nobody in his right mind manages this per box anymore anyway, and >> packages for distributions and auto-updates are well-present anyway. >> >> The presence of a key file can also mean to the resolver that one >> can/has_to check dnssec results. > > How do you propose to establish the initial trust for these keys? One already trusts the distribution, taking Debian as an example, all packages are signed by their key. I am already trusting them that they don't install backdoors on my boxes (or make weak keys :) by installing packages I install from their servers. Thus having them provide me with those keys is simple for them, just package them up (which mean they sign it), and let bind/resolver depend on that package. This would even upgrade boxes which don't have the package yet, eg similar to the ssh-vulnkey package which is now on all updated Debian and Ubuntu boxes worldwide. This takes care of all the distribution work, all the infrastructure is there already. Same for Fedora/SUSE/Windows etc etc. You will need to get the vendor to support this thing though, but if the vendor doesn't do it, you won't either have a resolver which supports it, unless you start doing custom installs. Note that one can already easily make a package and put it in a local repository which does exactly this. Which could allow one to have local packages with keys for other domains, thus avoiding problems when a higher key breaks, avoiding any disaster down the line. > How will they be updated? NIST recommends rolling the zone keys > every month and the key signing key annually. Files in distributions are > way too static for these intervals. (I think NIST's recommendations are > extremely excessive, but I am required to comply with them or explain to > OMB why not.) Never heard of apt-get update? :) People who don't upgrade their boxes (even only the security updates, which this would fall under) don't deserve to be on the Internet IMHO anyway. I am pretty sure that for these kind of 'force-upgrades' which, if not upgraded, would definitely break things, that there can be a mechanism (which can be turned of) that auto-updates the package without intervention. As for the interval, a month is not too bad for this, one should do security upgrades the day they come out. There is one problem though, and that is that keys should be 'overlapping', thus that there is no hole where no single key is valid, give it at least a week or two for everybody to upgrade. > This is the reason for the DLV concept and it will be needed (in some > form) at least until the root is signed and most likely until .com and > .net are signed. Having per-TLD keys distributed in this way would not even require that. DLV's are a good thing though if they are not there yet, but you still need to install a config snippet, having distributions do that would save a lot of overhead/reinvention. 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 henry at AegisInfoSys.com Wed Aug 27 12:54:47 2008 From: henry at AegisInfoSys.com (Henry Yen) Date: Wed, 27 Aug 2008 13:54:47 -0400 Subject: interger to I P address In-Reply-To: <20080827170047.40951BBB84@rebma.osc.edu>; from chartley@oar.net on Wed, Aug 27, 2008 at 13:00:41PM -0400 References: <20080827170047.40951BBB84@rebma.osc.edu> Message-ID: <20080827135447.D13562@AegisInfoSys.com> On Wed, Aug 27, 2008 at 13:00:41PM -0400, chartley at oar.net wrote: > Sorry to be continuing this thread, but I find a certain kind of elegance in > bash which isn't actually there, but helps me sleep at night. the (well, one of many, probably) REXX way: PARSE VALUE D2X(ARG(1)) WITH a 3 b 5 c 7 d . SAY X2D(a)"."X2D(b)"."X2D(c)"."X2D(d) -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From mike at mtcc.com Wed Aug 27 13:03:49 2008 From: mike at mtcc.com (Michael Thomas) Date: Wed, 27 Aug 2008 11:03:49 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <48B58DEF.2000400@spaghetti.zurich.ibm.com> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> <20080827131342.371009ae@cs.columbia.edu> <48B58DEF.2000400@spaghetti.zurich.ibm.com> Message-ID: <48B59705.8040804@mtcc.com> Jeroen Massar wrote: > Steven M. Bellovin wrote: >> On Wed, 27 Aug 2008 09:53:26 -0700 >> "Kevin Oberman" wrote: >> >>>> So the question I have is... will operators (ISP, etc) turn on >>>> DNSsec checking? Or a more basic question of whether you even >>>> _could_ turn on checking if you were so inclined? >>> As far as I can see, at least with bind-9.5, operators would have to >>> turn it off. It looks to me like dnssec-validation defaults to on. It >>> also appears that bind-9.4 defaults to 'off'. >> Right. The real questions are the clients and the trust anchor -- what >> root key do you support? > > A distributed one. I personally don't really see an issue with > downloading a public key for every TLD out there. These keys could come > in a pack even by an OS distribution, nicely PGP signed et all... > Nobody in his right mind manages this per box anymore anyway, and > packages for distributions and auto-updates are well-present anyway. > > The presence of a key file can also mean to the resolver that one > can/has_to check dnssec results. Heh, maybe you could manage root key update like any other security alert/update on your host OS... Of course embedded frobs that don't auto-update like, oh say, your favorite router could be problematic. And I'd assume that those key parts of the infrastructure are probably not too keen on trusting their upstream resolver to do the checking for them. In any case, the point of my first question was really about the concern of false positives. Do we really have any idea what will happen if you hard fail dnssec failures? If I were running a large site, I'd want to monitor the failures for a while. If nothing else, dnssec is a complicated beast and bakeoffs can only flush so many bugs out. Mike From mike at damm.com Wed Aug 27 13:08:27 2008 From: mike at damm.com (Mike Damm) Date: Wed, 27 Aug 2008 11:08:27 -0700 Subject: interger to I P address In-Reply-To: <3F045502966C304B963C72E3C442750EB8C86F@scarlitnt840.windstream.com> References: <3F045502966C304B963C72E3C442750EB8C86F@scarlitnt840.windstream.com> Message-ID: <48B5981B.6050702@damm.com> The PHP way: echo long2ip('1089055123'); Boyd, Benjamin R wrote: > The PHP way: > function convertIntegerToIpv4($integer) > { > $max_value = pow(2,32); //4,294,967,296 > $bug_fix = 0; > settype($integer, float); > > if($integer > 2147483647) $bug_fix = 16777216; > > if(is_numeric($integer)) > { > if ($integer >= $max_value || $integer < 0) > { > return ('Not a valid IPv4 integer'); > } > $ip = (sprintf("%u.%u.%u.%u", > $integer / 16777216, > (($integer % 16777216) + $bug_fix) / 65536, > (($integer % 65536) + $bug_fix / 256) / 256, > ($integer % 256) + $bug_fix / 256 / 256 > ) > ); > return($ip); > } > else { > return(''); > } > } > From dgc at uchicago.edu Wed Aug 27 13:27:06 2008 From: dgc at uchicago.edu (David Champion) Date: Wed, 27 Aug 2008 13:27:06 -0500 Subject: interger to I P address In-Reply-To: <48B589C9.4040006@ripe.net> <20080827172123.GA19397@ponzo.net> References: <20080827101756.K71371-100000@apollo.gti.net> <48B57126.6060402@otd.com> <48B5884E.9040703@karnaugh.za.net> <48B589C9.4040006@ripe.net> <48B55EED.4070700@karnaugh.za.net> <20080827101756.K71371-100000@apollo.gti.net> <20080827172123.GA19397@ponzo.net> Message-ID: <20080827182706.GN16311@monkey.uchicago.edu> > Actually, who needs loops for that? > ... > (unsigned char)(((char*)&i)[3]), > (unsigned char)(((char*)&i)[2]), > (unsigned char)(((char*)&i)[1]), > (unsigned char)(((char*)&i)[0]) Let data structures work for you. #include main(int argc, char *argv[]) { union { unsigned int i; unsigned char c[4]; } ip; int i = 0; ip.i = 1089055123; /* endian-neutral iteration: */ printf("%d.%d.%d.%d\n", ip.c[i++], ip.c[i++], ip.c[i++], ip.c[i++]); return 0; } > $ bc > bc 1.06 > Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > obase=256 > 1089055123 > 064 233 169 147 Curse you with your large number bases. But if you don't do GNU: dc < Anyone with leads on contact info for them? The POC for the ORG: JAM, WM110-ARIN , has an invalid phone number (goes to general delivery ATT handler) the email seems to go nowhere as well. Its listed as: Name: Manning, Bill Handle: WM110-ARIN Company: Address: PO 12317 City: Marina del Rey StateProv: CA PostalCode: 90295 Country: US Comment: RegDate: Updated: 2001-12-17 Phone: +1-310-322-8102 (Office) Email: bmanning at karoshi.com Seems to me its a rather large allocation (/15 & /16) not to have contact info for? A customer of mine purchased a block from them some time back and I still need them(JAM) to get rDNS setup. Any help is much appreciated. Regards, Chris From jeroen at unfix.org Wed Aug 27 13:41:24 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Aug 2008 20:41:24 +0200 Subject: Invalid contact for EP.net / OrgName: JAM In-Reply-To: <48B59ECE.5010600@gmail.com> References: <48B59ECE.5010600@gmail.com> Message-ID: <48B59FD4.6000408@spaghetti.zurich.ibm.com> Chris Stebner wrote: [..] > A customer of mine purchased a block from them some time back and I > still need them(JAM) to get rDNS setup. I didn't know that you could BUY address space, then again you are probably talking about some old legacy block. As you say 'purchased' there was probably money involved, I would say: follow the money. I do hope that you actually where talking to the right people and didn't give cash to some random folks, then again, if you where not, you deserve that for not dealing with it properly ;) Maybe you should be getting your address space from ARIN? 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 chris.stebner at gmail.com Wed Aug 27 13:56:21 2008 From: chris.stebner at gmail.com (Chris Stebner) Date: Wed, 27 Aug 2008 11:56:21 -0700 Subject: Invalid contact for EP.net / OrgName: JAM In-Reply-To: <48B59FD4.6000408@spaghetti.zurich.ibm.com> References: <48B59ECE.5010600@gmail.com> <48B59FD4.6000408@spaghetti.zurich.ibm.com> Message-ID: <48B5A355.2020400@gmail.com> Very much agreed on all points (leased may have been more appropriate). It was a customer, im just the techie in this instance. Certified letters have been sent and contracts signed, that phone number used to work. I spoke with the ORG handle over the phone, since then its looks like he's disappeared. Im merely attempting to do my due diligence for my employ and this is without a doubt the de facto standard for contacting the un-contactable. Jeroen Massar wrote > I didn't know that you could BUY address space, then again you are > probably talking about some old legacy block. As you say 'purchased' > there was probably money involved, I would say: follow the money. > I do hope that you actually where talking to the right people and didn't > give cash to some random folks, then again, if you where not, you > deserve that for not dealing with it properly ;) > > Maybe you should be getting your address space from ARIN? > > Greets, > Jeroen > > From owen at delong.com Wed Aug 27 14:38:47 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Aug 2008 12:38:47 -0700 Subject: interger to I P address In-Reply-To: <48B589C9.4040006@ripe.net> References: <20080827101756.K71371-100000@apollo.gti.net> <48B57126.6060402@otd.com> <48B5884E.9040703@karnaugh.za.net> <48B589C9.4040006@ripe.net> Message-ID: OK... I'll bite... The pedantic way: No. IP addresses are already integers. All conversation on this topic has been about how to convert between different methods of representing integers, but, at the end of the day, IP addresses are either 32 (IPv4) or 128 (IPv6) bit integers. There is no conversion possible or required between IP addresses and integers as the set of {IP Addresses} is a true subset of the set {integers}. Owen On Aug 27, 2008, at 10:07 AM, Robert Kisteleki wrote: > Colin Alston wrote: >> On 2008/08/27 05:22 PM Dave Israel wrote: >>> >>> Normally, I don't participate in this sort of thing, but I'm a >>> sucker for a "there's more than one way to do it" challenge. >> Aww come on, C gets way more "fun" than that ;) >> #define _u8 unsigned char >> #define _u32 unsigned long >> int main(void) { >> _u32 ipn = 1089055123; >> _u8 ipa[3]; >> _u8 oct = 0; >> for (oct=0; oct <4; oct++){ >> ipa[oct] = (char)( >> (ipn & (0xFF000000 >> (8*oct))) >> (8*(3-oct)) >> ); >> } >> printf("%d.%d.%d.%d\n", ipa[0], ipa[1], ipa[2], ipa[3]); >> return 0; >> } > > Actually, who needs loops for that? > > #include > > int main() > { > unsigned i = 1089055123; > printf("%d.%d.%d.%d\n", > (unsigned char)(((char*)&i)[3]), > (unsigned char)(((char*)&i)[2]), > (unsigned char)(((char*)&i)[1]), > (unsigned char)(((char*)&i)[0]) > ); > return 0; > } > > > Robert From jra at baylink.com Wed Aug 27 14:57:48 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 27 Aug 2008 15:57:48 -0400 Subject: Level 3 TPA routing today? In-Reply-To: <1460B0B010024BEA9A9E1053E31634D9@lain> References: <1460B0B010024BEA9A9E1053E31634D9@lain> Message-ID: <20080827195748.GK4558@cgi.jachomes.com> On Tue, Aug 26, 2008 at 07:06:29PM -0400, Justin D. Scott wrote: > > Anyone seeing issues with Level 3 between anywhere > > and Tampa, particularly Atlanta and Dallas? > > We just have co-lo in Tampa, but our upstream's connectivity is through > Level3 and we've been seeing intermittent packet loss up there all day. We > alerted our upstream but no updates so far. It hasn't been bad enough for > our customers to call and complain though. I too have a cage at Hampton Oaks, 10M up and 10M tail to me over OC-12, and I had problems 15-1630ish to wired.com and zimbra.com, among other sites; mtr had no appreciable loss tracing, but upper layer protocols were hincky. It was clear by the next morning... 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. -- (Josef Stalin) From jra at baylink.com Wed Aug 27 14:57:48 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 27 Aug 2008 15:57:48 -0400 Subject: Level 3 TPA routing today? In-Reply-To: <1460B0B010024BEA9A9E1053E31634D9@lain> References: <1460B0B010024BEA9A9E1053E31634D9@lain> Message-ID: <20080827195748.GK4558@cgi.jachomes.com> On Tue, Aug 26, 2008 at 07:06:29PM -0400, Justin D. Scott wrote: > > Anyone seeing issues with Level 3 between anywhere > > and Tampa, particularly Atlanta and Dallas? > > We just have co-lo in Tampa, but our upstream's connectivity is through > Level3 and we've been seeing intermittent packet loss up there all day. We > alerted our upstream but no updates so far. It hasn't been bad enough for > our customers to call and complain though. I too have a cage at Hampton Oaks, 10M up and 10M tail to me over OC-12, and I had problems 15-1630ish to wired.com and zimbra.com, among other sites; mtr had no appreciable loss tracing, but upper layer protocols were hincky. It was clear by the next morning... 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. -- (Josef Stalin) From jlewis at lewis.org Wed Aug 27 15:20:25 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 27 Aug 2008 16:20:25 -0400 (EDT) Subject: Level 3 TPA routing today? In-Reply-To: <20080827195748.GK4558@cgi.jachomes.com> References: <1460B0B010024BEA9A9E1053E31634D9@lain> <20080827195748.GK4558@cgi.jachomes.com> Message-ID: On Wed, 27 Aug 2008, Jay R. Ashworth wrote: > I too have a cage at Hampton Oaks, 10M up and 10M tail to me over OC-12, > and I had problems 15-1630ish to wired.com and zimbra.com, among other > sites; mtr had no appreciable loss tracing, but upper layer protocols > were hincky. It was clear by the next morning... We have gigE to Level3 in Orlando, and saw something happen around 1pm today. Customers were complaining of latency and packet loss, and our traffic to/from L3 dropped noticably if only for a few minutes. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dhubbard at dino.hostasaurus.com Wed Aug 27 15:40:13 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 27 Aug 2008 16:40:13 -0400 Subject: Level 3 TPA routing today? Message-ID: From: Jon Lewis [mailto:jlewis at lewis.org] > > We have gigE to Level3 in Orlando, and saw something happen > around 1pm today. Customers were complaining of latency and > packet loss, and our traffic to/from L3 dropped noticably if > only for a few minutes. It sounded like based on Craig's post yesterday they did have some known issue and were working to resolve it around that time, ~8 pm EST. I turned our gig link to them back on around 4 AM EST and have not had any complaints so far today. Traffic is up compared to yesterday afternoon too, back where it would normally be. The tech I spoke to this morning said he had no knowledge of any issues yesterday, of course my ticket also had none of the information I sent in to them yesterday or even a clear description of what the problem was.... Dave From izaac at setec.org Wed Aug 27 16:07:40 2008 From: izaac at setec.org (Izaac) Date: Wed, 27 Aug 2008 17:07:40 -0400 Subject: interger to I P address In-Reply-To: <20080827155044.GB24576@toonk.nl> References: <20080827111304.GL16377@virtual.bogons.net> <48B538B6.6030209@karnaugh.za.net> <4288131ED5E3024C9CD4782CECCAD2C70489E733@LMC-MAIL2.exempla.org> <927635FD-B59B-472E-83BD-95C8B6086CF5@muada.com> <4288131ED5E3024C9CD4782CECCAD2C7037AF79C@LMC-MAIL2.exempla.org> <013101c9084c$9568a650$c039f2f0$@edu> <48B55EED.4070700@karnaugh.za.net> <20080827155044.GB24576@toonk.nl> Message-ID: <20080827210725.GA6668@abbott.setec.org> On Wed, Aug 27, 2008 at 05:50:44PM +0200, Andree Toonk wrote: > The Perl way: > sub ntoa_in_one_line { join(".", unpack("CCCC", pack("N", $_[0]))); } > print ntoa_in_one_line(1089055123) . "\n"; dec2ip awk '{ print int($1 / 16777216) "." int($1 % 16777216 / 65536) "." int($1 % 65536 / 256) "." int($1 % 256) }' ip2dec awk '{ split($1, a, "."); print a[1]*16777216 + a[2]*65536 + a[3]*256 + a[4] }' -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__ From chip.gwyn at gmail.com Wed Aug 27 16:16:07 2008 From: chip.gwyn at gmail.com (chip) Date: Wed, 27 Aug 2008 17:16:07 -0400 Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: <64a8ad980808271416r33fe98a9s24345227b0798633@mail.gmail.com> On Wed, Aug 27, 2008 at 4:40 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > From: Jon Lewis [mailto:jlewis at lewis.org] > > > > We have gigE to Level3 in Orlando, and saw something happen > > around 1pm today. Customers were complaining of latency and > > packet loss, and our traffic to/from L3 dropped noticably if > > only for a few minutes. > > It sounded like based on Craig's post yesterday they > did have some known issue and were working to resolve > it around that time, ~8 pm EST. I turned our gig link > to them back on around 4 AM EST and have not had any > complaints so far today. Traffic is up compared to > yesterday afternoon too, back where it would normally > be. The tech I spoke to this morning said he had no > knowledge of any issues yesterday, of course my ticket > also had none of the information I sent in to them > yesterday or even a clear description of what the > problem was.... > > Dave > > The speicific issue we were seeing yesterday seems to have been resolved last night some time and we aren't seeing any instances of it any longer. --chip -- Just my $.02, your mileage may vary, batteries not included, etc.... From Valdis.Kletnieks at vt.edu Wed Aug 27 16:42:14 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 Aug 2008 17:42:14 -0400 Subject: interger to I P address In-Reply-To: Your message of "Wed, 27 Aug 2008 18:51:27 -0000." References: Message-ID: <43338.1219873334@turing-police.cc.vt.edu> On Wed, 27 Aug 2008 18:51:27 -0000, Johnny Eriksson said: > The Tops-10/DDT way: > > .r ddt Gonna be hard to top that one for sheer old-skool geekitude. (No, it's OK, the monitor needed cleaning anyhow... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From gem at rellim.com Wed Aug 27 17:02:02 2008 From: gem at rellim.com (Gary E. Miller) Date: Wed, 27 Aug 2008 15:02:02 -0700 (PDT) Subject: interger to I P address In-Reply-To: <48B560F9.4050605@csuohio.edu> References: <48B560F9.4050605@csuohio.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo All! > ls it possible t convert the interger to ip # php -r 'echo ip2long("196.3.39.209"), "\n";' RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFItc7dBmnRqz71OvMRAshNAKCoM8Lifs17RI7vwfF6ACF1ZiDTxgCgt6Sh H6JRMLnsX8n/Hs8fCLhguqA= =hwxF -----END PGP SIGNATURE----- From astounding at gmail.com Wed Aug 27 17:05:32 2008 From: astounding at gmail.com (Aaron Gifford) Date: Wed, 27 Aug 2008 16:05:32 -0600 Subject: interger to I P address In-Reply-To: References: Message-ID: Ruby's IPAddr class is quite handy for IPv4 and IPv6 integer representation conversions. For IP to integer, whether IPv4 or IPv6, ruby code: require 'ipaddr' print "#{IPAddr.new('10.0.0.55').to_i}\n" print "#{IPAddr.new('2001:0db8:85a3:08d3:1319:8a2e:0370:7334').to_i}\n" Results in: 167772215 42540766452641195744311209248773141300 And for integer to IPv4, ruby code: require "ipaddr" print "#{IPAddr.new(167772215,Socket::AF_INET)}\n" Results in: 10.0.0.55 And for integer to IPv6, ruby code: require 'ipaddr' print "#{IPAddr.new(42540766452641195744311209248773141300, Socket::AF_INET6)}\n" Results in: 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 Aaron out. From gem at rellim.com Wed Aug 27 17:08:30 2008 From: gem at rellim.com (Gary E. Miller) Date: Wed, 27 Aug 2008 15:08:30 -0700 (PDT) Subject: interger to I P address In-Reply-To: References: <48B560F9.4050605@csuohio.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo All! On Wed, 27 Aug 2008, Gary E. Miller wrote: > > ls it possible t convert the interger to ip > # php -r 'echo ip2long("196.3.39.209"), "\n";' Whoops, wrong way. # php -r 'echo long2ip("3288541137"), "\n";' RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFItdBgBmnRqz71OvMRAlpDAKCd+G4Qtj/d/65bSLx2vWXEM6XesACgnc5/ f9BdpC6mwrOYV0X5VzRVKQw= =hHcZ -----END PGP SIGNATURE----- From if at xip.at Wed Aug 27 17:59:21 2008 From: if at xip.at (Ingo Flaschberger) Date: Thu, 28 Aug 2008 00:59:21 +0200 (CEST) Subject: sharktech.net hosts irc-server for botnets Message-ID: Dear community, sharktech.net hosts irc-server for botnets and does not respond to abuse notifications. Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 --------------------------- From jlewis at lewis.org Wed Aug 27 18:02:06 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 27 Aug 2008 19:02:06 -0400 (EDT) Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: On Wed, 27 Aug 2008, David Hubbard wrote: > be. The tech I spoke to this morning said he had no > knowledge of any issues yesterday, of course my ticket > also had none of the information I sent in to them > yesterday or even a clear description of what the > problem was.... We opened a ticket for today's event and got the same response. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From randy at psg.com Wed Aug 27 18:08:30 2008 From: randy at psg.com (Randy Bush) Date: Thu, 28 Aug 2008 11:08:30 +1200 Subject: interger to I P address In-Reply-To: References: Message-ID: <48B5DE6E.5000109@psg.com> her at the apnic meeting, we are indulging for a bit into the deep topic of how ot textually represent 32-bit AS numbers. is it xxxx.xxxx or xxxxxxxx? while we readily admit that a deep many year discussion of a dot is clearly a topic for the ietf, we do have to allocate these things, so actually need an answer. on the other hand, i wonder if this ingenious community could come up with the extraodinarily difficult programming task of routines to convert between the two notations. randy From drc at virtualized.org Wed Aug 27 18:16:41 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Aug 2008 16:16:41 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <48B58DEF.2000400@spaghetti.zurich.ibm.com> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> <20080827131342.371009ae@cs.columbia.edu> <48B58DEF.2000400@spaghetti.zurich.ibm.com> Message-ID: <44CC7BA2-7AAA-45D4-AB41-38956B8E75E5@virtualized.org> On Aug 27, 2008, at 10:25 AM, Jeroen Massar wrote: >> Right. The real questions are the clients and the trust anchor -- >> what >> root key do you support? > A distributed one. I personally don't really see an issue with > downloading a public key for every TLD out there. These keys could > come > in a pack even by an OS distribution, nicely PGP signed et all... https://par.icann.org/files/paris/IANAReportKim_24Jun08.pdf, slides 3 through 11. Regards, -drc From drc at virtualized.org Wed Aug 27 18:30:14 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Aug 2008 16:30:14 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <20080827173503.BCDE04500F@ptavv.es.net> References: <20080827173503.BCDE04500F@ptavv.es.net> Message-ID: <13B33456-0B8A-4CE4-82A4-86C066547601@virtualized.org> Just speaking of the IANA ITAR... On Aug 27, 2008, at 10:35 AM, Kevin Oberman wrote: > How do you propose to establish the initial trust for these keys? Current plan: - The IANA ITAR will be reachable via HTTPS, so you could trust the CA IANA uses for that website (don't know who that is offhand). - The IANA ITAR will be PGP signed, so you could trust the IANA PGP key you obtained via some out of band mechanism. The data used in the IANA ITAR will be vetted the same way IANA vets NS changes. > How will they be updated? Not sure I understand this question. If you mean how frequently will the trust anchors within the IANA ITAR be updated, that's up to the TLD admins. If you mean how will the set of trust anchors be updated, I would imagine folks would have a cron job to pull down the trust anchors periodically or something. The data is relatively static and could be Akamaized (or equivalent) or something if load becomes a problem (not something I'd personally be expecting in the foreseeable future). > This is the reason for the DLV concept and it will be needed (in some > form) at least until the root is signed and most likely until .com and > .net are signed. The downside of DLV is that it puts the DLV registry into the name resolution path, with all that implies in terms of data privacy as well as reliability. Regards, -drc From newton at internode.com.au Wed Aug 27 18:14:36 2008 From: newton at internode.com.au (Mark Newton) Date: Thu, 28 Aug 2008 08:44:36 +0930 Subject: interger to I P address In-Reply-To: <48B5DE6E.5000109@psg.com> References: <48B5DE6E.5000109@psg.com> Message-ID: <225EDA8D-5C52-494D-A95B-C395E2AF7123@internode.com.au> On 28/08/2008, at 8:38 AM, Randy Bush wrote: > her at the apnic meeting, we are indulging for a bit into the deep > topic > of how ot textually represent 32-bit AS numbers. is it xxxx.xxxx or > xxxxxxxx? while we readily admit that a deep many year discussion > of a > dot is clearly a topic for the ietf, we do have to allocate these > things, so actually need an answer. At AusNOG last week, it was pointed out that using a "." in the middle of an AS number wrecks AS path regexes in RPSL. So those of us using IRR's have to go back and rewrite all our policies. And IRRToolSet needs to be updated, which is probably an even worse proposition :-) I'm strongly in favour of ASPLAIN. I reckon the people who advocate using dots because they think 32-bit ASNs up to 4 billion are too long to remember are probably getting old :-) - 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 drc at virtualized.org Wed Aug 27 18:41:20 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Aug 2008 16:41:20 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <48B59705.8040804@mtcc.com> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> <20080827131342.371009ae@cs.columbia.edu> <48B58DEF.2000400@spaghetti.zurich.ibm.com> <48B59705.8040804@mtcc.com> Message-ID: <10DD8F65-5093-4CF3-A9EB-8738A5FC2740@virtualized.org> On Aug 27, 2008, at 11:03 AM, Michael Thomas wrote: > Of course embedded frobs that don't > auto-update like, oh say, your favorite router could be problematic. You have a router that supports DNSSEC that can't be made to do some form of auto-update? > In any case, the point of my first question was really about the > concern of false positives. Do we really have any idea what will > happen if you hard fail dnssec failures? As far as I'm aware, there is no 'soft fail' for DNSSEC failures. In the caching servers I'm familiar with, if a name fails to validate, it used to be that it doesn't get cached and SERVFAIL is returned. Maybe that's been fixed? Regards, -drc From mysidia at gmail.com Wed Aug 27 18:59:23 2008 From: mysidia at gmail.com (James Hess) Date: Wed, 27 Aug 2008 18:59:23 -0500 Subject: interger to I P address In-Reply-To: <48B560F9.4050605@csuohio.edu> References: <48B560F9.4050605@csuohio.edu> Message-ID: <6eb799ab0808271659i7f73b6aak8681ce877640a4a1@mail.gmail.com> Perl provides some cleaner methods for interpreting/displaying IPs. There isn't a formal standard notation for an IP that looks like a string of decimal digits with no dots though. I.e. no RFC will define the host byte order and tell you that "127.0.0.1" corresponds to the decimal integer 2130706433; I might be little-endian and argue that the right human-readable integer to call that ip is 16777343. There are a vast number of different numerical representations the very same ip address could be converted to, because a string of bits has no inherent representation. Displaying an IP in a novel format seems dangerous. Ips have only a binary notation and.. in recent years dots-and-decimals are formalized. In general, rather than just in the context of SMTP. Still conflicting conventions exists that haven't been fixed, for example try pinging "127.1" (hint: it's an old abbreviation mechanism not merely a "bug") In any case, to get from quad-octet notation to a decimal integer representation you may be thinking of (if you interpret those octets in the network byte order used for other items such as port numbers): $ perl -e 'use IO::Socket; print unpack("N",inet_aton("127.0.0.1"))."\n"' 2130706433 $ perl -e 'use IO::Socket; print inet_ntoa(pack("N",2130706433))."\n";' 127.0.0.1 $ perl -e 'use IO::Socket; print inet_ntoa(pack("N",2066563929))."\n";' 123.45.67.89 And of course... $ perl -e 'print "",(123<<24)|(45<<16)|(89<<8),"\n"' 2066569472 Or if you don't like one-liners, 3 separate short scripts: ipv4-to-hex: #!/usr/bin/perl use IO::Socket; printf("%x\n", unpack("N",inet_aton($ARGV[0]))); ipv4-to-integer: #!/usr/bin/perl use IO::Socket; printf("%d\n", unpack("N",inet_aton($ARGV[0]))); hex-to-ipv4: #!/usr/bin/perl use IO::Socket; print inet_ntoa(pack("N",hex($ARGV[0]))); On Wed, Aug 27, 2008 at 9:13 AM, Michael Holstein wrote: > >> ls it possible t convert the interger to ip >> > > #!/usr/local/bin/perl > # Perl script to convert between numeric and dotted quad IPs. > # give credit to Paul Gregg for this one > while () { > chomp; $input = $_; > if (/\./) { > ($a, $b, $c, $d) = split(/\./); > $decimal = $d + ($c * 256) + ($b * 256**2) + ($a * 256**3); > } else { > $decimal = $_; > $d = $_ % 256; $_ -= $d; $_ /= 256; > $c = $_ % 256; $_ -= $c; $_ /= 256; > $b = $_ % 256; $_ -= $b; $_ /= 256; > $a = $_; > } > > if ( ($a>255) || ($b>255) || ($c>255) || ($d>255) ) { > print "$0: Invalid input: $input\n"; > } else { > printf ("Address: %d.%d.%d.%d is %u (Hex:%02x%02x%02x%02x)\n", > $a,$b,$c,$d, $decimal,$a,$b,$c,$d); > } > } > > From mike at mtcc.com Wed Aug 27 19:15:01 2008 From: mike at mtcc.com (Michael Thomas) Date: Wed, 27 Aug 2008 17:15:01 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <10DD8F65-5093-4CF3-A9EB-8738A5FC2740@virtualized.org> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> <20080827131342.371009ae@cs.columbia.edu> <48B58DEF.2000400@spaghetti.zurich.ibm.com> <48B59705.8040804@mtcc.com> <10DD8F65-5093-4CF3-A9EB-8738A5FC2740@virtualized.org> Message-ID: <48B5EE05.1080708@mtcc.com> David Conrad wrote: > On Aug 27, 2008, at 11:03 AM, Michael Thomas wrote: > In any case, the point of my first question was really about the >> concern of false positives. Do we really have any idea what will >> happen if you hard fail dnssec failures? > > As far as I'm aware, there is no 'soft fail' for DNSSEC failures. In > the caching servers I'm familiar with, if a name fails to validate, it > used to be that it doesn't get cached and SERVFAIL is returned. Maybe > that's been fixed? Sure, but my point is that if DNSsec all of a sudden has some relevance which is not the case today, any false positives are going to come into pretty stark relief. As in, .gov could quite possibly setting themselves up for self-inflicted denial of service given buginess in the signers, the verifiers or both. Given how integral DNS is to everything, it seems a little scary to just trust that all of that software across many, many vendors is going to interoperate at *scale*. It seems that some training wheels like an accept-failure-but-log mode with feedback like "your domain failed" to the domain's admins might be safer. At least for a while, as this new treadmill's operational care and feeding is established. Mike From craigp at tozz.net Wed Aug 27 19:23:51 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Wed, 27 Aug 2008 18:23:51 -0600 Subject: Level 3 TPA routing today? In-Reply-To: References: Message-ID: <46B6E31D-706E-4261-87BD-CF21493E7343@tozz.net> Most likely the issue was communication between the NOC and the service management center. The NOC deals with the core facing events versus the SMC which takes the incoming calls from the customers. In this case the issue was identified and resolved in the NOC. Perhaps the RFO was not posted internally or whomever you talked with didn't check the status updates or something. Lot's of things could have resulted in a tech not knowing about this type of issue. Anyway, to tie up loose ends, there was a problem on a core router that was isolated and then repaired in Atlanta. regards -Craig On Aug 27, 2008, at 5:02 PM, Jon Lewis wrote: > On Wed, 27 Aug 2008, David Hubbard wrote: > >> be. The tech I spoke to this morning said he had no >> knowledge of any issues yesterday, of course my ticket >> also had none of the information I sent in to them >> yesterday or even a clear description of what the >> problem was.... > > We opened a ticket for today's event and got the same response. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From drc at virtualized.org Wed Aug 27 19:26:58 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Aug 2008 17:26:58 -0700 Subject: US government mandates? use of DNSSEC by federal agencies In-Reply-To: <48B5EE05.1080708@mtcc.com> References: <48B57F50.2040506@mtcc.com> <20080827165326.E0D204500F@ptavv.es.net> <20080827131342.371009ae@cs.columbia.edu> <48B58DEF.2000400@spaghetti.zurich.ibm.com> <48B59705.8040804@mtcc.com> <10DD8F65-5093-4CF3-A9EB-8738A5FC2740@virtualized.org> <48B5EE05.1080708@mtcc.com> Message-ID: <13362E07-4032-4C77-BE65-04E015A49F64@virtualized.org> Michael, On Aug 27, 2008, at 5:15 PM, Michael Thomas wrote: > Sure, but my point is that if DNSsec all of a sudden has some > relevance > which is not the case today, any false positives are going to come > into > pretty stark relief. Yep. > As in, .gov could quite possibly setting themselves > up for self-inflicted denial of service given buginess in the signers, > the verifiers or both. Given how long the signers and verifiers have been around, I suspect a more likely failure mode is folks running caching servers forgetting to update trust anchors and/or signers forgetting to resign before the validity period expires. However, bugs do happen... > Given how integral DNS is to everything, it seems a little scary to > just > trust that all of that software across many, many vendors is going to > interoperate at *scale*. It seems that some training wheels like an > accept-failure-but-log mode with feedback like "your domain failed" > to the domain's admins might be safer. At least for a while, as > this new treadmill's operational care and feeding is established. I agree and I know for certain this has been suggested in the past for at least one of the validating caching servers. However, I gather this hasn't been implemented.... Regards, -drc From wrl at express.org Wed Aug 27 19:42:24 2008 From: wrl at express.org (William R. Lorenz) Date: Wed, 27 Aug 2008 20:42:24 -0400 (EDT) Subject: Level 3 TPA routing today? In-Reply-To: <46B6E31D-706E-4261-87BD-CF21493E7343@tozz.net> References: <46B6E31D-706E-4261-87BD-CF21493E7343@tozz.net> Message-ID: Has anyone noticed significant Level3 transit issues this evening? [wrl@ ~]$ traceroute ae-23-52.car3.Chicago1.Level3.net traceroute to ae-23-52.car3.Chicago1.Level3.net (4.68.101.39), 30 hops max, 40 byte packets [...] 4 ge-6-1-101.hsa1.Cleveland1.Level3.net (64.156.66.29) 2.627 ms !H [wrl@ ~]$ [wrl@ ~]$ traceroute vlan79.csw2.Dallas1.Level3.net traceroute to vlan79.csw2.Dallas1.Level3.net (4.68.19.126), 30 hops max, 40 byte packets [...] 4 ge-6-1-101.hsa1.Cleveland1.Level3.net (64.156.66.29) 3.166 ms !H * * [wrl@ ~]$ [root@ ~]# traceroute www.he.net traceroute to www.he.net (216.218.186.2), 30 hops max, 40 byte packets [...] 3 te-3-1.car1.Cincinnati1.Level3.net (4.78.216.9) 29.279 ms 18.127 ms te-3-2.car1.Cincinnati1.Level3.net (4.78.216.13) 20.737 ms 4 ae-2-5.bar1.Cincinnati1.Level3.net (4.69.132.206) 20.193 ms 24.019 ms 24.360 ms 5 ae-10-10.ebr2.Chicago1.Level3.net (4.69.136.214) 35.255 ms 35.884 ms 35.595 ms 6 ae-23-56.car3.Chicago1.Level3.net (4.68.101.167) 28.672 ms ae-23-54.car3.Chicago1.Level3.net (4.68.101.103) 30.715 ms ae-23-56.car3.Chicago1.Level3.net (4.68.101.167) 32.160 ms 7 glbx-level3-te.Chicago1.level3.net (4.68.110.194) 97.377 ms 97.080 ms 96.625 ms 8 * * * 9 * * * [root@ ~]# On Wed, 27 Aug 2008, Craig Pierantozzi wrote: > Most likely the issue was communication between the NOC and the service > management center. The NOC deals with the core facing events versus the SMC > which takes the incoming calls from the customers. In this case the issue was > identified and resolved in the NOC. > > Perhaps the RFO was not posted internally or whomever you talked with didn't > check the status updates or something. Lot's of things could have resulted in > a tech not knowing about this type of issue. > > Anyway, to tie up loose ends, there was a problem on a core router that was > isolated and then repaired in Atlanta. > > regards > -Craig > > On Aug 27, 2008, at 5:02 PM, Jon Lewis wrote: > >> On Wed, 27 Aug 2008, David Hubbard wrote: >> >> > be. The tech I spoke to this morning said he had no >> > knowledge of any issues yesterday, of course my ticket >> > also had none of the information I sent in to them >> > yesterday or even a clear description of what the >> > problem was.... >> >> We opened a ticket for today's event and got the same response. >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> > -- William R. Lorenz "Whether you think you can or think you can't, your right." -- Henry Ford From fsmendoza at gmail.com Wed Aug 27 19:47:15 2008 From: fsmendoza at gmail.com (Frank) Date: Thu, 28 Aug 2008 08:47:15 +0800 Subject: Revealed: The Internet's Biggest Security Hole Message-ID: http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky discloseda serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness. "It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger," said Peiter "Mudge" Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. "I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail." The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network. Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one AT&T customer to another. The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs. BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton "Tony" Kapela, data center and network director at 5Nines Data , and Alex Pilosov, CEO of Pilosoft , showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas. The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works. "We're not doing anything out of the ordinary," Kapela told Wired.com. "There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working." The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic. Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks -- also known as Autonomous Systems, or ASes -- declaring the range of IP addresses, or IP prefixes, to which they'll deliver traffic. The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix "wins" the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one. To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network. The attack is called an IP hijack and, on its face, isn't new. But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That's what occurred earlier this year when Pakistan Telecom inadvertentlyhijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss. Pilosov's innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs. Ordinarily, this shouldn't work -- the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients. "Everyone ... has assumed until now that you have to break something for a hijack to be useful," Kapela said. "But what we showed here is that you don't have to break anything. And if nothing breaks, who notices?" Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago. Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data. A handful of academic groups collect BGP routing information from cooperating ASes to monitor BGP updates that change traffic's path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another -- say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But "when the internet has a bad hair day," Kent said, "the rate of (BGP path) updates goes up by a factor of 200 to 400." Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it "breaks it for the rest of us," he said. "Providers can prevent our attack absolutely 100 percent," Kapela said. "They simply don't because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive." Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors. Filtering isn't the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don't just send traffic to whoever requests it. Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so. The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an eavesdropper from hijacking the second or third hop. For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop. "That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path," Kent said. The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven't demanded it, due to the cost and man hours involved in swapping out routers. Douglas Maughan, cybersecurity research program manager for the DHS's Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs and router vendors to take steps to secure BGP. "We haven't seen the attacks, and so a lot of times people don't start working on things and trying to fix them until they get attacked," Maughan said. "(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did." ISPs, he said, have been holding their breath, "hoping that people don't discover (this) and exploit it." "The only thing that can force them (to fix BGP) is if their customers ... start to demand security solutions," Maughan said. From ge at linuxbox.org Wed Aug 27 19:54:26 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 27 Aug 2008 19:54:26 -0500 (CDT) Subject: Revealed: The Internet's Biggest Security Hole In-Reply-To: References: Message-ID: hehe "new". hehe Maybe something will change now' though, it was a great and impressive presentation, hijacking the defcon network and tweaking TTL to hide it. On Thu, 28 Aug 2008, Frank wrote: > http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html > > Two security researchers have demonstrated a new technique to stealthily > intercept internet traffic on a scale previously presumed to be unavailable > to anyone outside of intelligence agencies like the National Security > Agency. > > The tactic exploits the internet routing protocol BGP (Border Gateway > Protocol) to let an attacker surreptitiously monitor unencrypted internet > traffic anywhere in the world, and even modify it before it reaches its > destination. > > The demonstration is only the latest attack to highlight fundamental > security weaknesses in some of the internet's core protocols. Those > protocols were largely developed in the 1970s with the assumption that every > node on the then-nascent network would be trustworthy. The world was > reminded of the quaintness of that assumption in July, when researcher Dan > Kaminsky discloseda > serious vulnerability in the DNS system. Experts say the new > demonstration > targets a potentially larger weakness. > > "It's a huge issue. It's at least as big an issue as the DNS issue, if not > bigger," said Peiter "Mudge" Zatko, noted computer security expert and > former member of the L0pht hacking group, who testified to Congress in 1998 > that he could bring down the internet in 30 minutes using a similar BGP > attack, and disclosed privately to government agents how BGP could also be > exploited to eavesdrop. "I went around screaming my head about this about > ten or twelve years ago.... We described this to intelligence agencies and > to the National Security Council, in detail." > > The man-in-the-middle attack exploits BGP to fool routers into re-directing > data to an eavesdropper's network. > > Anyone with a BGP router (ISPs, large corporations or anyone with space at a > carrier hotel) > could intercept data headed to a target IP address or group of addresses. > The attack intercepts only traffic headed *to* target addresses, not from > them, and it can't always vacuum in traffic within a network -- say, from > one AT&T customer to another. > > The method conceivably could be used for corporate espionage, nation-state > spying or even by intelligence agencies looking to mine internet data > without needing the cooperation of ISPs. > > BGP eavesdropping has long been a theoretical weakness, but no one is known > to have publicly demonstrated it until Anton "Tony" Kapela, data center and > network director at 5Nines Data , and Alex > Pilosov, CEO of Pilosoft , showed their technique > at the recent DefCon hacker conference. The pair successfully intercepted > traffic bound for the conference network and redirected it to a system they > controlled in New York before routing it back to DefCon in Las Vegas. > > The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It > simply exploits the natural way BGP works. > > "We're not doing anything out of the ordinary," Kapela told Wired.com. > "There's no vulnerabilities, no protocol errors, there are no software > problems. The problem arises (from) the level of interconnectivity that's > needed to maintain this mess, to keep it all working." > > The issue exists because BGP's architecture is based on trust. To make it > easy, say, for e-mail from Sprint customers in California to reach > Telefonica customers in Spain, networks for these companies and others > communicate through BGP routers to indicate when they're the quickest, most > efficient route for the data to reach its destination. But BGP assumes that > when a router says it's the best path, it's telling the truth. That > gullibility makes it easy for eavesdroppers to fool routers into sending > them traffic. > > Here's how it works. When a user types a website name into his browser or > clicks "send" to launch an e-mail, a Domain Name System server produces an > IP address for the destination. A router belonging to the user's ISP then > consults a BGP table for the best route. That table is built from > announcements, or "advertisements," issued by ISPs and other networks -- > also known as Autonomous Systems, or ASes -- declaring the range of IP > addresses, or IP prefixes, to which they'll deliver traffic. > > The routing table searches for the destination IP address among those > prefixes. If two ASes deliver to the address, the one with the more specific > prefix "wins" the traffic. For example, one AS may advertise that it > delivers to a group of 90,000 IP addresses, while another delivers to a > subset of 24,000 of those addresses. If the destination IP address falls > within both announcements, BGP will send data to the narrower, more specific > one. > > To intercept data, an eavesdropper would advertise a range of IP addresses > he wished to target that was narrower than the chunk advertised by other > networks. The advertisement would take just minutes to propagate worldwide, > before data headed to those addresses would begin arriving to his network. > > The attack is called an IP hijack and, on its face, isn't new. > > But in the past, known IP hijacks have created outages, which, because they > were so obvious, were quickly noticed and fixed. That's what occurred > earlier this year when Pakistan Telecom > inadvertentlyhijacked > YouTube traffic from around the world. The traffic hit a dead-end > in Pakistan, so it was apparent to everyone trying to visit YouTube that > something was amiss. > > Pilosov's innovation is to forward the intercepted data silently to the > actual destination, so that no outage occurs. > > Ordinarily, this shouldn't work -- the data would boomerang back to the > eavesdropper. But Pilosov and Kapela use a method called AS path prepending > that causes a select number of BGP routers to reject their deceptive > advertisement. They then use these ASes to forward the stolen data to its > rightful recipients. > > "Everyone ... has assumed until now that you have to break something for a > hijack to be useful," Kapela said. "But what we showed here is that you > don't have to break anything. And if nothing breaks, who notices?" > > Stephen Kent, chief scientist for information security at BBN Technologies, > who has been working on solutions to fix the issue, said he demonstrated a > similar BGP interception privately for the Departments of Defense and > Homeland Security a few years ago. > > Kapela said network engineers might notice an interception if they knew how > to read BGP routing tables, but it would take expertise to interpret the > data. > > A handful of academic groups collect BGP > routing information from > cooperating ASes to monitor BGP updates that change traffic's path. But > without context, it can be difficult to distinguish a legitimate change from > a malicious hijacking. There are reasons traffic that ordinarily travels one > path could suddenly switch to another -- say, if companies with separate > ASes merged, or if a natural disaster put one network out of commission and > another AS adopted its traffic. On good days, routing paths can remain > fairly static. But "when the internet has a bad hair day," Kent said, "the > rate of (BGP path) updates goes up by a factor of 200 to 400." > > Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to > allow only authorized peers to draw traffic from their routers, and only for > specific IP prefixes. But filtering is labor intensive, and if just one ISP > declines to participate, it "breaks it for the rest of us," he said. > > "Providers can prevent our attack absolutely 100 percent," Kapela said. > "They simply don't because it takes work, and to do sufficient filtering to > prevent these kinds of attacks on a global scale is cost prohibitive." > > Filtering also requires ISPs to disclose the address space for all their > customers, which is not information they want to hand competitors. > > Filtering isn't the only solution, though. Kent and others are devising > processes to authenticate ownership of IP blocks, and validate the > advertisements that ASes send to routers so they don't just send traffic to > whoever requests it. > > Under the scheme, the five regional internet address registries would issue > signed certificates to ISPs attesting to their address space and AS numbers. > The ASes would then sign an authorization to initiate routes for their > address space, which would be stored with the certificates in a repository > accessible to all ISPs. If an AS advertised a new route for an IP prefix, it > would be easy to verify if it had the right to do so. > > The solution would authenticate only the first hop in a route to prevent > unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an > eavesdropper from hijacking the second or third hop. > > For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would > require BGP routers to digitally sign with a private key any prefix > advertisement they propagated. An ISP would give peer routers certificates > authorizing them to route its traffic; each peer on a route would sign a > route advertisement and forward it to the next authorized hop. > > "That means that nobody could put themselves into the chain, into the path, > unless they had been authorized to do so by the preceding AS router in the > path," Kent said. > > The drawback to this solution is that current routers lack the memory and > processing power to generate and validate signatures. And router vendors > have resisted upgrading them because their clients, ISPs, haven't demanded > it, due to the cost and man hours involved in swapping out routers. > > Douglas Maughan, cybersecurity research program manager for the DHS's > Science and Technology Directorate, has helped fund research at BBN and > elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs > and router vendors to take steps to secure BGP. > > "We haven't seen the attacks, and so a lot of times people don't start > working on things and trying to fix them until they get attacked," Maughan > said. "(But) the YouTube (case) is the perfect example of an attack where > somebody could have done much worse than what they did." > > ISPs, he said, have been holding their breath, "hoping that people don't > discover (this) and exploit it." > > "The only thing that can force them (to fix BGP) is if their customers ... > start to demand security solutions," Maughan said. > From craigp at tozz.net Wed Aug 27 20:30:13 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Wed, 27 Aug 2008 19:30:13 -0600 Subject: Level 3 TPA routing today? In-Reply-To: References: <46B6E31D-706E-4261-87BD-CF21493E7343@tozz.net> Message-ID: <647A708D-A3B7-4BEF-B1A2-0D30E768778F@tozz.net> Some infrastructure blocks are not routed to portions of the network but should not affect ultimate reachability as long as the correct loopbacks and directly connected networks are advertised properly. regards On Aug 27, 2008, at 6:42 PM, William R. Lorenz wrote: > Has anyone noticed significant Level3 transit issues this evening? > > [wrl@ ~]$ traceroute ae-23-52.car3.Chicago1.Level3.net > traceroute to ae-23-52.car3.Chicago1.Level3.net (4.68.101.39), 30 > hops max, 40 byte packets > [...] > 4 ge-6-1-101.hsa1.Cleveland1.Level3.net (64.156.66.29) 2.627 ms !H > [wrl@ ~]$ > > > [wrl@ ~]$ traceroute vlan79.csw2.Dallas1.Level3.net > traceroute to vlan79.csw2.Dallas1.Level3.net (4.68.19.126), 30 hops > max, 40 byte packets > [...] > 4 ge-6-1-101.hsa1.Cleveland1.Level3.net (64.156.66.29) 3.166 ms !H > * * > [wrl@ ~]$ > From sra+nanog at hactrn.net Wed Aug 27 20:39:09 2008 From: sra+nanog at hactrn.net (Rob Austein) Date: Wed, 27 Aug 2008 21:39:09 -0400 Subject: interger to I P address In-Reply-To: Message-ID: <20080828013909.589322282B@thrintun.hactrn.net> At Wed, 27 Aug 2008 18:51:27 WET DST, Johnny Eriksson wrote: > > The Tops-10/DDT way: Hmm, ITS TECO is a bit more verbose in this case: 1089055123u14d$$ From marcus.sachs at verizon.com Wed Aug 27 20:40:26 2008 From: marcus.sachs at verizon.com (marcus.sachs at verizon.com) Date: Wed, 27 Aug 2008 21:40:26 -0400 Subject: Revealed: The Internet's Biggest Security Hole Message-ID: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A59@FHDP1CCMXCV02.us.one.verizon.com> Nothing will change. You think DNSSEC is hard? Try getting support for the deployment of S-BGP or soBGP. Without a trust anchor and lots of community support it will remain largely an academic interest area. Marc ------Original Message------ From: Gadi Evron To: Frank Cc: NANOG list Sent: Aug 27, 2008 20:54 Subject: Re: Revealed: The Internet's Biggest Security Hole hehe "new". hehe Maybe something will change now' though, it was a great and impressive presentation, hijacking the defcon network and tweaking TTL to hide it. On Thu, 28 Aug 2008, Frank wrote: > http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html > > Two security researchers have demonstrated a new technique to stealthily > intercept internet traffic on a scale previously presumed to be unavailable > to anyone outside of intelligence agencies like the National Security > Agency. > > The tactic exploits the internet routing protocol BGP (Border Gateway > Protocol) to let an attacker surreptitiously monitor unencrypted internet > traffic anywhere in the world, and even modify it before it reaches its > destination. > > The demonstration is only the latest attack to highlight fundamental > security weaknesses in some of the internet's core protocols. Those > protocols were largely developed in the 1970s with the assumption that every > node on the then-nascent network would be trustworthy. The world was > reminded of the quaintness of that assumption in July, when researcher Dan > Kaminsky discloseda > serious vulnerability in the DNS system. Experts say the new > demonstration > targets a potentially larger weakness. > > "It's a huge issue. It's at least as big an issue as the DNS issue, if not > bigger," said Peiter "Mudge" Zatko, noted computer security expert and ------Original Message Truncated------ -------------------------- Marcus H. Sachs Verizon 202 515 2463 Sent from my BlackBerry From ge at linuxbox.org Wed Aug 27 20:42:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 27 Aug 2008 20:42:59 -0500 (CDT) Subject: Revealed: The Internet's Biggest Security Hole In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A59@FHDP1CCMXCV02.us.one.verizon.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A59@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: On Wed, 27 Aug 2008 marcus.sachs at verizon.com wrote: > Nothing will change. You think DNSSEC is hard? Try getting support for the deployment of S-BGP or soBGP. Without a trust anchor and lots of community support it will remain largely an academic interest area. I guess it will just remain a "cool" presentation than, and boy was it cool. You were there, any special impressions? Gadi. > Marc > > ------Original Message------ > From: Gadi Evron > To: Frank > Cc: NANOG list > Sent: Aug 27, 2008 20:54 > Subject: Re: Revealed: The Internet's Biggest Security Hole > > hehe > "new". hehe > > Maybe something will change now' though, it was a great and impressive > presentation, hijacking the defcon network and tweaking TTL to hide it. > > > > > > On Thu, 28 Aug 2008, Frank wrote: > >> http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html >> >> Two security researchers have demonstrated a new technique to stealthily >> intercept internet traffic on a scale previously presumed to be unavailable >> to anyone outside of intelligence agencies like the National Security >> Agency. >> >> The tactic exploits the internet routing protocol BGP (Border Gateway >> Protocol) to let an attacker surreptitiously monitor unencrypted internet >> traffic anywhere in the world, and even modify it before it reaches its >> destination. >> >> The demonstration is only the latest attack to highlight fundamental >> security weaknesses in some of the internet's core protocols. Those >> protocols were largely developed in the 1970s with the assumption that every >> node on the then-nascent network would be trustworthy. The world was >> reminded of the quaintness of that assumption in July, when researcher Dan >> Kaminsky discloseda >> serious vulnerability in the DNS system. Experts say the new >> demonstration >> targets a potentially larger weakness. >> >> "It's a huge issue. It's at least as big an issue as the DNS issue, if not >> bigger," said Peiter "Mudge" Zatko, noted computer security expert and > > ------Original Message Truncated------ > > -------------------------- > Marcus H. Sachs > Verizon > 202 515 2463 > > Sent from my BlackBerry > From marcus.sachs at verizon.com Wed Aug 27 20:52:19 2008 From: marcus.sachs at verizon.com (marcus.sachs at verizon.com) Date: Wed, 27 Aug 2008 21:52:19 -0400 Subject: Revealed: The Internet's Biggest Security Hole Message-ID: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A5A@FHDP1CCMXCV02.us.one.verizon.com> Yes, wonderful preso! My biggest take-away was the fact that the vast majority of the attendees did not understand the gravity of the demo. The same thing could be said about Dan's talk. It was over the heads of most attendees. Marc ------Original Message------ From: Gadi Evron To: Sachs, Marcus H. (Marc) Cc: fsmendoza at gmail.com Cc: nanog at merit.edu Sent: Aug 27, 2008 21:42 Subject: Re: Revealed: The Internet's Biggest Security Hole On Wed, 27 Aug 2008 marcus.sachs at verizon.com wrote: > Nothing will change. You think DNSSEC is hard? Try getting support for the deployment of S-BGP or soBGP. Without a trust anchor and lots of community support it will remain largely an academic interest area. I guess it will just remain a "cool" presentation than, and boy was it cool. You were there, any special impressions? Gadi. > Marc > > ------Original Message------ > From: Gadi Evron > To: Frank > Cc: NANOG list > Sent: Aug 27, 2008 20:54 > Subject: Re: Revealed: The Internet's Biggest Security Hole > > hehe > "new". hehe > > Maybe something will change now' though, it was a great and impressive > presentation, hijacking the defcon network and tweaking TTL to hide it. > > > > > > On Thu, 28 Aug 2008, Frank wrote: > >> http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html >> >> Two security researchers have demonstrated a new technique to stealthily >> intercept internet traffic on a scale previously presumed to be unavailable >> to anyone outside of intelligence agencies like the National Security >> Agency. >> >> The tactic exploits the internet routing protocol BGP (Border Gateway >> Protocol) to let an attacker surreptitiously monitor unencrypted internet >> traffic anywhere in the world, and even modify it before it reaches its >> destination. >> >> The demonstration is only the latest attack to highlight fundamental >> security weaknesses in some of the internet's ------Original Message Truncated------ -------------------------- Marcus H. Sachs Verizon 202 515 2463 Sent from my BlackBerry From algorythm at gmail.com Wed Aug 27 21:21:12 2008 From: algorythm at gmail.com (Jason Ross) Date: Wed, 27 Aug 2008 22:21:12 -0400 Subject: Revealed: The Internet's Biggest Security Hole In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A5A@FHDP1CCMXCV02.us.one.verizon.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A5A@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <355c7d900808271921w68b25024xef68a3a8c2e272cd@mail.gmail.com> On Wed, Aug 27, 2008 at 9:52 PM, wrote: > Yes, wonderful preso! My biggest take-away was the fact that the > vast majority of the attendees did not understand the gravity of the > demo. Agreed on both counts: the presentation was great, and largely not understood it seemed. >> >> hehe >> "new". hehe >> >> Maybe something will change now' though, it was a great and >> impressive presentation, hijacking the defcon network and tweaking >> TTL to hide it. >> Notably, Alex and Tony both mentioned that the BGP tricks were not new during the presentation, and commented that it would essentially not be surprising to anyone that groks routing at the level that most of the folks on this list does. What was new though according to their presentation (and it was new to me certainly, but I'm still fairly green) was the AS Path prepending to complete the circuit, and as you mentioned, the TTL magicks to hide the hops. I was suitably impressed at that. -- Jason From marcus.sachs at verizon.com Wed Aug 27 21:30:05 2008 From: marcus.sachs at verizon.com (marcus.sachs at verizon.com) Date: Wed, 27 Aug 2008 22:30:05 -0400 Subject: Revealed: The Internet's Biggest Security Hole Message-ID: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A5C@FHDP1CCMXCV02.us.one.verizon.com> I'll have to admit that the TTL manipulation was something I had not thought about. But why not? If you are going to purloin EVERY packet then why not re-write byte 8 in every IP header to a value of your choosing? Very cool. Marc ------Original Message------ From: Jason Ross To: Sachs, Marcus H. (Marc) Cc: Gadi Evron Cc: nanog at merit.edu Sent: Aug 27, 2008 22:21 Subject: Re: Revealed: The Internet's Biggest Security Hole On Wed, Aug 27, 2008 at 9:52 PM, wrote: > Yes, wonderful preso! My biggest take-away was the fact that the > vast majority of the attendees did not understand the gravity of the > demo. Agreed on both counts: the presentation was great, and largely not understood it seemed. >> >> hehe >> "new". hehe >> >> Maybe something will change now' though, it was a great and >> impressive presentation, hijacking the defcon network and tweaking >> TTL to hide it. >> Notably, Alex and Tony both mentioned that the BGP tricks were not new during the presentation, and commented that it would essentially not be surprising to anyone that groks routing at the level that most of the folks on this list does. What was new though according to their presentation (and it was new to me certainly, but I'm still fairly green) was the AS Path prepending to complete the circuit, and as you mentioned, the TTL magicks to hide the hops. I was suitably impressed at that. -- Jason -------------------------- Marcus H. Sachs Verizon 202 515 2463 Sent from my BlackBerry From bmanning at vacation.karoshi.com Wed Aug 27 21:41:04 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 28 Aug 2008 02:41:04 +0000 Subject: interger to I P address In-Reply-To: References: Message-ID: <20080828024104.GA26314@vacation.karoshi.com.> On Wed, Aug 27, 2008 at 07:11:41AM -0400, kcc wrote: > Hi all > > ls it possible t convert the interger to ip > > Thank you sure. how do you want that IP? hex? octal, decimal, binary? (*) v4 or v6? * other bases by request.... --bill From tbeecher at localnet.com Wed Aug 27 21:58:29 2008 From: tbeecher at localnet.com (tbeecher at localnet.com) Date: Wed, 27 Aug 2008 22:58:29 -0400 (EDT) Subject: ATT.net Message-ID: <50628.72.88.60.179.1219892309.squirrel@newmail.core.com> Any known issues across AT&T's network? Got a couple calls for some access issues, I'm seeing roughly 15% loss at a couple of paths at the AT&T network edge. From ABass at arise.com Wed Aug 27 22:04:01 2008 From: ABass at arise.com (Allen Bass) Date: Wed, 27 Aug 2008 23:04:01 -0400 Subject: Revealed: The Internet's Biggest Security Hole In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A5C@FHDP1CCMXCV02.us.one.verizon.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A5C@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: I'm thinking and afraid that by reading this thread we have opened Pandora's box even further than it was opened! * * * * * Allen Bass Manager, Technology Operations Arise Virtual Solutions Inc. 3450 Lakeside Drive, Suite 620 Miramar, Florida 33027 www.arise.com -----Original Message----- From: marcus.sachs at verizon.com [mailto:marcus.sachs at verizon.com] Sent: Wednesday, August 27, 2008 10:30 PM To: algorythm at gmail.com Cc: nanog at merit.edu Subject: Re: Revealed: The Internet's Biggest Security Hole I'll have to admit that the TTL manipulation was something I had not thought about. But why not? If you are going to purloin EVERY packet then why not re-write byte 8 in every IP header to a value of your choosing? Very cool. Marc ------Original Message------ From: Jason Ross To: Sachs, Marcus H. (Marc) Cc: Gadi Evron Cc: nanog at merit.edu Sent: Aug 27, 2008 22:21 Subject: Re: Revealed: The Internet's Biggest Security Hole On Wed, Aug 27, 2008 at 9:52 PM, wrote: > Yes, wonderful preso! My biggest take-away was the fact that the > vast majority of the attendees did not understand the gravity of the > demo. Agreed on both counts: the presentation was great, and largely not understood it seemed. >> >> hehe >> "new". hehe >> >> Maybe something will change now' though, it was a great and >> impressive presentation, hijacking the defcon network and tweaking >> TTL to hide it. >> Notably, Alex and Tony both mentioned that the BGP tricks were not new during the presentation, and commented that it would essentially not be surprising to anyone that groks routing at the level that most of the folks on this list does. What was new though according to their presentation (and it was new to me certainly, but I'm still fairly green) was the AS Path prepending to complete the circuit, and as you mentioned, the TTL magicks to hide the hops. I was suitably impressed at that. -- Jason -------------------------- Marcus H. Sachs Verizon 202 515 2463 Sent from my BlackBerry From john at internetassociatesllc.com Wed Aug 27 22:07:20 2008 From: john at internetassociatesllc.com (John Lee) Date: Wed, 27 Aug 2008 22:07:20 -0500 Subject: Revealed: The Internet's well known BGP behavior Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> 1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living. 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where. 3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops. 4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack. And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch. John (ISDN) Lee :) ________________________________________ From: Frank [fsmendoza at gmail.com] Sent: Wednesday, August 27, 2008 8:47 PM To: NANOG list Subject: Revealed: The Internet's Biggest Security Hole http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. The demonstration is only the latest attack to highlight fundamental security weaknesses in some of the internet's core protocols. Those protocols were largely developed in the 1970s with the assumption that every node on the then-nascent network would be trustworthy. The world was reminded of the quaintness of that assumption in July, when researcher Dan Kaminsky discloseda serious vulnerability in the DNS system. Experts say the new demonstration targets a potentially larger weakness. "It's a huge issue. It's at least as big an issue as the DNS issue, if not bigger," said Peiter "Mudge" Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. "I went around screaming my head about this about ten or twelve years ago.... We described this to intelligence agencies and to the National Security Council, in detail." The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network. Anyone with a BGP router (ISPs, large corporations or anyone with space at a carrier hotel) could intercept data headed to a target IP address or group of addresses. The attack intercepts only traffic headed *to* target addresses, not from them, and it can't always vacuum in traffic within a network -- say, from one AT&T customer to another. The method conceivably could be used for corporate espionage, nation-state spying or even by intelligence agencies looking to mine internet data without needing the cooperation of ISPs. BGP eavesdropping has long been a theoretical weakness, but no one is known to have publicly demonstrated it until Anton "Tony" Kapela, data center and network director at 5Nines Data , and Alex Pilosov, CEO of Pilosoft , showed their technique at the recent DefCon hacker conference. The pair successfully intercepted traffic bound for the conference network and redirected it to a system they controlled in New York before routing it back to DefCon in Las Vegas. The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It simply exploits the natural way BGP works. "We're not doing anything out of the ordinary," Kapela told Wired.com. "There's no vulnerabilities, no protocol errors, there are no software problems. The problem arises (from) the level of interconnectivity that's needed to maintain this mess, to keep it all working." The issue exists because BGP's architecture is based on trust. To make it easy, say, for e-mail from Sprint customers in California to reach Telefonica customers in Spain, networks for these companies and others communicate through BGP routers to indicate when they're the quickest, most efficient route for the data to reach its destination. But BGP assumes that when a router says it's the best path, it's telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic. Here's how it works. When a user types a website name into his browser or clicks "send" to launch an e-mail, a Domain Name System server produces an IP address for the destination. A router belonging to the user's ISP then consults a BGP table for the best route. That table is built from announcements, or "advertisements," issued by ISPs and other networks -- also known as Autonomous Systems, or ASes -- declaring the range of IP addresses, or IP prefixes, to which they'll deliver traffic. The routing table searches for the destination IP address among those prefixes. If two ASes deliver to the address, the one with the more specific prefix "wins" the traffic. For example, one AS may advertise that it delivers to a group of 90,000 IP addresses, while another delivers to a subset of 24,000 of those addresses. If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one. To intercept data, an eavesdropper would advertise a range of IP addresses he wished to target that was narrower than the chunk advertised by other networks. The advertisement would take just minutes to propagate worldwide, before data headed to those addresses would begin arriving to his network. The attack is called an IP hijack and, on its face, isn't new. But in the past, known IP hijacks have created outages, which, because they were so obvious, were quickly noticed and fixed. That's what occurred earlier this year when Pakistan Telecom inadvertentlyhijacked YouTube traffic from around the world. The traffic hit a dead-end in Pakistan, so it was apparent to everyone trying to visit YouTube that something was amiss. Pilosov's innovation is to forward the intercepted data silently to the actual destination, so that no outage occurs. Ordinarily, this shouldn't work -- the data would boomerang back to the eavesdropper. But Pilosov and Kapela use a method called AS path prepending that causes a select number of BGP routers to reject their deceptive advertisement. They then use these ASes to forward the stolen data to its rightful recipients. "Everyone ... has assumed until now that you have to break something for a hijack to be useful," Kapela said. "But what we showed here is that you don't have to break anything. And if nothing breaks, who notices?" Stephen Kent, chief scientist for information security at BBN Technologies, who has been working on solutions to fix the issue, said he demonstrated a similar BGP interception privately for the Departments of Defense and Homeland Security a few years ago. Kapela said network engineers might notice an interception if they knew how to read BGP routing tables, but it would take expertise to interpret the data. A handful of academic groups collect BGP routing information from cooperating ASes to monitor BGP updates that change traffic's path. But without context, it can be difficult to distinguish a legitimate change from a malicious hijacking. There are reasons traffic that ordinarily travels one path could suddenly switch to another -- say, if companies with separate ASes merged, or if a natural disaster put one network out of commission and another AS adopted its traffic. On good days, routing paths can remain fairly static. But "when the internet has a bad hair day," Kent said, "the rate of (BGP path) updates goes up by a factor of 200 to 400." Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to allow only authorized peers to draw traffic from their routers, and only for specific IP prefixes. But filtering is labor intensive, and if just one ISP declines to participate, it "breaks it for the rest of us," he said. "Providers can prevent our attack absolutely 100 percent," Kapela said. "They simply don't because it takes work, and to do sufficient filtering to prevent these kinds of attacks on a global scale is cost prohibitive." Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors. Filtering isn't the only solution, though. Kent and others are devising processes to authenticate ownership of IP blocks, and validate the advertisements that ASes send to routers so they don't just send traffic to whoever requests it. Under the scheme, the five regional internet address registries would issue signed certificates to ISPs attesting to their address space and AS numbers. The ASes would then sign an authorization to initiate routes for their address space, which would be stored with the certificates in a repository accessible to all ISPs. If an AS advertised a new route for an IP prefix, it would be easy to verify if it had the right to do so. The solution would authenticate only the first hop in a route to prevent unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an eavesdropper from hijacking the second or third hop. For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would require BGP routers to digitally sign with a private key any prefix advertisement they propagated. An ISP would give peer routers certificates authorizing them to route its traffic; each peer on a route would sign a route advertisement and forward it to the next authorized hop. "That means that nobody could put themselves into the chain, into the path, unless they had been authorized to do so by the preceding AS router in the path," Kent said. The drawback to this solution is that current routers lack the memory and processing power to generate and validate signatures. And router vendors have resisted upgrading them because their clients, ISPs, haven't demanded it, due to the cost and man hours involved in swapping out routers. Douglas Maughan, cybersecurity research program manager for the DHS's Science and Technology Directorate, has helped fund research at BBN and elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs and router vendors to take steps to secure BGP. "We haven't seen the attacks, and so a lot of times people don't start working on things and trying to fix them until they get attacked," Maughan said. "(But) the YouTube (case) is the perfect example of an attack where somebody could have done much worse than what they did." ISPs, he said, have been holding their breath, "hoping that people don't discover (this) and exploit it." "The only thing that can force them (to fix BGP) is if their customers ... start to demand security solutions," Maughan said. From patrick at ianai.net Wed Aug 27 22:18:25 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 27 Aug 2008 23:18:25 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> Message-ID: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> On Aug 27, 2008, at 11:07 PM, John Lee wrote: > 1. The technique is not new it is well known BGP behavior and not > stealthy to people who route for a living. Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?) > 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can > control what packets are going where. No, you cannot. You can only ensure your end points are the end points you think they are. In no way, shape, or form do things like IPsec, SSL, etc. verify or control the intermediate hops. > 3. When you are running some number of trace routes per hour to see > how and where your packets are going you spot the additional hops. The presentation specifically shows hiding the hops by re-writing TTLs. Perhaps you do not understand this attack as well as you thought? > 4. If you do cold potatoe routing and know where you peering points > are and what the acls and peering policies are it is more difficult > to hijack. Would that network operators were so diligent. > And finally you use high speed optical paths or broad band ISDN > (ATM) why route when you can deterministically switch. Because people want to be able to reach the entire planet with a single port and without "deterministically" creating paths to every single end point. Why use ISDN (ATM) when you can do something useful? -- TTFN, patrick From christian at broknrobot.com Wed Aug 27 22:24:05 2008 From: christian at broknrobot.com (Christian Koch) Date: Wed, 27 Aug 2008 23:24:05 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> Message-ID: what do mpls, ipsec tunnels, ssl have anything to do with someone announcing your address space and hijacking youre prefixes?? i think we all know this is not new.. and these guys didnt claim it to be.. they're not presenting this to a 'xNOG' crowd, defcon has a different type of audience..im not saying they dont know about this kind of insecurity, but it is nice to see this material being presented, and exposing it to different 'groups' especially with a live demo... christian On Wed, Aug 27, 2008 at 11:07 PM, John Lee wrote: > 1. The technique is not new it is well known BGP behavior and not stealthy to people who route for a living. > > 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what packets are going where. > > 3. When you are running some number of trace routes per hour to see how and where your packets are going you spot the additional hops. > > 4. If you do cold potatoe routing and know where you peering points are and what the acls and peering policies are it is more difficult to hijack. > > And finally you use high speed optical paths or broad band ISDN (ATM) why route when you can deterministically switch. > > John (ISDN) Lee :) > > ________________________________________ > From: Frank [fsmendoza at gmail.com] > Sent: Wednesday, August 27, 2008 8:47 PM > To: NANOG list > Subject: Revealed: The Internet's Biggest Security Hole > > http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html > > Two security researchers have demonstrated a new technique to stealthily > intercept internet traffic on a scale previously presumed to be unavailable > to anyone outside of intelligence agencies like the National Security > Agency. > > The tactic exploits the internet routing protocol BGP (Border Gateway > Protocol) to let an attacker surreptitiously monitor unencrypted internet > traffic anywhere in the world, and even modify it before it reaches its > destination. > > The demonstration is only the latest attack to highlight fundamental > security weaknesses in some of the internet's core protocols. Those > protocols were largely developed in the 1970s with the assumption that every > node on the then-nascent network would be trustworthy. The world was > reminded of the quaintness of that assumption in July, when researcher Dan > Kaminsky discloseda > serious vulnerability in the DNS system. Experts say the new > demonstration > targets a potentially larger weakness. > > "It's a huge issue. It's at least as big an issue as the DNS issue, if not > bigger," said Peiter "Mudge" Zatko, noted computer security expert and > former member of the L0pht hacking group, who testified to Congress in 1998 > that he could bring down the internet in 30 minutes using a similar BGP > attack, and disclosed privately to government agents how BGP could also be > exploited to eavesdrop. "I went around screaming my head about this about > ten or twelve years ago.... We described this to intelligence agencies and > to the National Security Council, in detail." > > The man-in-the-middle attack exploits BGP to fool routers into re-directing > data to an eavesdropper's network. > > Anyone with a BGP router (ISPs, large corporations or anyone with space at a > carrier hotel) > could intercept data headed to a target IP address or group of addresses. > The attack intercepts only traffic headed *to* target addresses, not from > them, and it can't always vacuum in traffic within a network -- say, from > one AT&T customer to another. > > The method conceivably could be used for corporate espionage, nation-state > spying or even by intelligence agencies looking to mine internet data > without needing the cooperation of ISPs. > > BGP eavesdropping has long been a theoretical weakness, but no one is known > to have publicly demonstrated it until Anton "Tony" Kapela, data center and > network director at 5Nines Data , and Alex > Pilosov, CEO of Pilosoft , showed their technique > at the recent DefCon hacker conference. The pair successfully intercepted > traffic bound for the conference network and redirected it to a system they > controlled in New York before routing it back to DefCon in Las Vegas. > > The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It > simply exploits the natural way BGP works. > > "We're not doing anything out of the ordinary," Kapela told Wired.com. > "There's no vulnerabilities, no protocol errors, there are no software > problems. The problem arises (from) the level of interconnectivity that's > needed to maintain this mess, to keep it all working." > > The issue exists because BGP's architecture is based on trust. To make it > easy, say, for e-mail from Sprint customers in California to reach > Telefonica customers in Spain, networks for these companies and others > communicate through BGP routers to indicate when they're the quickest, most > efficient route for the data to reach its destination. But BGP assumes that > when a router says it's the best path, it's telling the truth. That > gullibility makes it easy for eavesdroppers to fool routers into sending > them traffic. > > Here's how it works. When a user types a website name into his browser or > clicks "send" to launch an e-mail, a Domain Name System server produces an > IP address for the destination. A router belonging to the user's ISP then > consults a BGP table for the best route. That table is built from > announcements, or "advertisements," issued by ISPs and other networks -- > also known as Autonomous Systems, or ASes -- declaring the range of IP > addresses, or IP prefixes, to which they'll deliver traffic. > > The routing table searches for the destination IP address among those > prefixes. If two ASes deliver to the address, the one with the more specific > prefix "wins" the traffic. For example, one AS may advertise that it > delivers to a group of 90,000 IP addresses, while another delivers to a > subset of 24,000 of those addresses. If the destination IP address falls > within both announcements, BGP will send data to the narrower, more specific > one. > > To intercept data, an eavesdropper would advertise a range of IP addresses > he wished to target that was narrower than the chunk advertised by other > networks. The advertisement would take just minutes to propagate worldwide, > before data headed to those addresses would begin arriving to his network. > > The attack is called an IP hijack and, on its face, isn't new. > > But in the past, known IP hijacks have created outages, which, because they > were so obvious, were quickly noticed and fixed. That's what occurred > earlier this year when Pakistan Telecom > inadvertentlyhijacked > YouTube traffic from around the world. The traffic hit a dead-end > in Pakistan, so it was apparent to everyone trying to visit YouTube that > something was amiss. > > Pilosov's innovation is to forward the intercepted data silently to the > actual destination, so that no outage occurs. > > Ordinarily, this shouldn't work -- the data would boomerang back to the > eavesdropper. But Pilosov and Kapela use a method called AS path prepending > that causes a select number of BGP routers to reject their deceptive > advertisement. They then use these ASes to forward the stolen data to its > rightful recipients. > > "Everyone ... has assumed until now that you have to break something for a > hijack to be useful," Kapela said. "But what we showed here is that you > don't have to break anything. And if nothing breaks, who notices?" > > Stephen Kent, chief scientist for information security at BBN Technologies, > who has been working on solutions to fix the issue, said he demonstrated a > similar BGP interception privately for the Departments of Defense and > Homeland Security a few years ago. > > Kapela said network engineers might notice an interception if they knew how > to read BGP routing tables, but it would take expertise to interpret the > data. > > A handful of academic groups collect BGP > routing information from > cooperating ASes to monitor BGP updates that change traffic's path. But > without context, it can be difficult to distinguish a legitimate change from > a malicious hijacking. There are reasons traffic that ordinarily travels one > path could suddenly switch to another -- say, if companies with separate > ASes merged, or if a natural disaster put one network out of commission and > another AS adopted its traffic. On good days, routing paths can remain > fairly static. But "when the internet has a bad hair day," Kent said, "the > rate of (BGP path) updates goes up by a factor of 200 to 400." > > Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to > allow only authorized peers to draw traffic from their routers, and only for > specific IP prefixes. But filtering is labor intensive, and if just one ISP > declines to participate, it "breaks it for the rest of us," he said. > > "Providers can prevent our attack absolutely 100 percent," Kapela said. > "They simply don't because it takes work, and to do sufficient filtering to > prevent these kinds of attacks on a global scale is cost prohibitive." > > Filtering also requires ISPs to disclose the address space for all their > customers, which is not information they want to hand competitors. > > Filtering isn't the only solution, though. Kent and others are devising > processes to authenticate ownership of IP blocks, and validate the > advertisements that ASes send to routers so they don't just send traffic to > whoever requests it. > > Under the scheme, the five regional internet address registries would issue > signed certificates to ISPs attesting to their address space and AS numbers. > The ASes would then sign an authorization to initiate routes for their > address space, which would be stored with the certificates in a repository > accessible to all ISPs. If an AS advertised a new route for an IP prefix, it > would be easy to verify if it had the right to do so. > > The solution would authenticate only the first hop in a route to prevent > unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an > eavesdropper from hijacking the second or third hop. > > For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would > require BGP routers to digitally sign with a private key any prefix > advertisement they propagated. An ISP would give peer routers certificates > authorizing them to route its traffic; each peer on a route would sign a > route advertisement and forward it to the next authorized hop. > > "That means that nobody could put themselves into the chain, into the path, > unless they had been authorized to do so by the preceding AS router in the > path," Kent said. > > The drawback to this solution is that current routers lack the memory and > processing power to generate and validate signatures. And router vendors > have resisted upgrading them because their clients, ISPs, haven't demanded > it, due to the cost and man hours involved in swapping out routers. > > Douglas Maughan, cybersecurity research program manager for the DHS's > Science and Technology Directorate, has helped fund research at BBN and > elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs > and router vendors to take steps to secure BGP. > > "We haven't seen the attacks, and so a lot of times people don't start > working on things and trying to fix them until they get attacked," Maughan > said. "(But) the YouTube (case) is the perfect example of an attack where > somebody could have done much worse than what they did." > > ISPs, he said, have been holding their breath, "hoping that people don't > discover (this) and exploit it." > > "The only thing that can force them (to fix BGP) is if their customers ... > start to demand security solutions," Maughan said. > > From john at internetassociatesllc.com Wed Aug 27 22:22:36 2008 From: john at internetassociatesllc.com (John Lee) Date: Wed, 27 Aug 2008 22:22:36 -0500 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local>, <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> Patrick, VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen. Rewriting the TTL only hides the number of hop count, trace route will still show the hops the packet has transited. John (ISDN) Lee ________________________________________ From: Patrick W. Gilmore [patrick at ianai.net] Sent: Wednesday, August 27, 2008 11:18 PM To: NANOG list Subject: Re: Revealed: The Internet's well known BGP behavior On Aug 27, 2008, at 11:07 PM, John Lee wrote: > 1. The technique is not new it is well known BGP behavior and not > stealthy to people who route for a living. Using existing technology in novel ways is still novel. Plus it makes the technique more accessible. (Perhaps that is not a good thing?) > 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can > control what packets are going where. No, you cannot. You can only ensure your end points are the end points you think they are. In no way, shape, or form do things like IPsec, SSL, etc. verify or control the intermediate hops. > 3. When you are running some number of trace routes per hour to see > how and where your packets are going you spot the additional hops. The presentation specifically shows hiding the hops by re-writing TTLs. Perhaps you do not understand this attack as well as you thought? > 4. If you do cold potatoe routing and know where you peering points > are and what the acls and peering policies are it is more difficult > to hijack. Would that network operators were so diligent. > And finally you use high speed optical paths or broad band ISDN > (ATM) why route when you can deterministically switch. Because people want to be able to reach the entire planet with a single port and without "deterministically" creating paths to every single end point. Why use ISDN (ATM) when you can do something useful? -- TTFN, patrick From adrian at creative.net.au Wed Aug 27 22:32:12 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 28 Aug 2008 11:32:12 +0800 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> Message-ID: <20080828033212.GE30494@skywalker.creative.net.au> On Wed, Aug 27, 2008, John Lee wrote: > Patrick, > > VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen. > > Rewriting the TTL only hides the number of hop count, trace route will still show the hops the packet has transited. No, traceroute shows the hops which returned "time to live exceeded." This only maps to "the hops the packet has transited" if the TTL is setup and decremented correctly. Adrian From john at internetassociatesllc.com Wed Aug 27 22:47:53 2008 From: john at internetassociatesllc.com (John Lee) Date: Wed, 27 Aug 2008 22:47:53 -0500 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <20080828033212.GE30494@skywalker.creative.net.au> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local>, <20080828033212.GE30494@skywalker.creative.net.au> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> Adrian, The traceroute utility that I used gave me a list of hops that the packet I was interested in transited and a time when it transited the hop. When the TTL was reached it would terminate the listing. When ever I had performance issues on my networks or with my networks links it would indicate if the standard route was being taken or another one. When certain links went down several additional hops would be added to the list. John (ISDN) Lee ________________________________________ From: Adrian Chadd [adrian at creative.net.au] Sent: Wednesday, August 27, 2008 11:32 PM To: John Lee Cc: Patrick W. Gilmore; NANOG list Subject: Re: Revealed: The Internet's well known BGP behavior On Wed, Aug 27, 2008, John Lee wrote: > Patrick, > > VPN's and MPLS control intermediate hops and IPsec and SSL do not allow the info to be seen. > > Rewriting the TTL only hides the number of hop count, trace route will still show the hops the packet has transited. No, traceroute shows the hops which returned "time to live exceeded." This only maps to "the hops the packet has transited" if the TTL is setup and decremented correctly. Adrian From paul at bertain.net Wed Aug 27 23:04:14 2008 From: paul at bertain.net (Paul Bertain) Date: Wed, 27 Aug 2008 21:04:14 -0700 Subject: ATT.net In-Reply-To: <50628.72.88.60.179.1219892309.squirrel@newmail.core.com> References: <50628.72.88.60.179.1219892309.squirrel@newmail.core.com> Message-ID: <9BEB3D00-5DDE-41CA-A3F2-289D31034655@bertain.net> Internap notified us that they were shutting down their peering with ATT (AS7018) at their Dallas facility and was asking them to investigate but there were no listed causes for it. > At approximately 21:34 CDT on August 27th, 2008, we were notified > that the > link with ATT peer (AS 7018) in the DAL PNAP was experiencing loss. We > have since shut down the peering and will asking ATT to investigate > > We will be following-up with ATT immediately to investigate this > issue. > This does not appear to be related to a hardware issue on the Internap > side, so we will open a ticket to have ATT investigate their end > immediately. I haven't seen anything over on the "outages" yet. Paul Aug 27, 2008, at 7:58 PM, tbeecher at localnet.com wrote: > > > Any known issues across AT&T's network? Got a couple calls for some > access issues, I'm seeing roughly 15% loss at a couple of paths at the > AT&T network edge. From j at arpa.com Wed Aug 27 23:08:04 2008 From: j at arpa.com (jamie) Date: Wed, 27 Aug 2008 23:08:04 -0500 Subject: ATT.net In-Reply-To: <9BEB3D00-5DDE-41CA-A3F2-289D31034655@bertain.net> References: <50628.72.88.60.179.1219892309.squirrel@newmail.core.com> <9BEB3D00-5DDE-41CA-A3F2-289D31034655@bertain.net> Message-ID: <6ff30abd0808272108s46c52dd4i121bd612c4a7f16d@mail.gmail.com> Concur; I'm seeing two ds3's (one ptp and one ipfr) down. Down time 21:20 CDT. Meh. On Wed, Aug 27, 2008 at 11:04 PM, Paul Bertain wrote: > Internap notified us that they were shutting down their peering with ATT > (AS7018) at their Dallas facility and was asking them to investigate but > there were no listed causes for it. > > At approximately 21:34 CDT on August 27th, 2008, we were notified that the >> link with ATT peer (AS 7018) in the DAL PNAP was experiencing loss. We >> have since shut down the peering and will asking ATT to investigate >> >> We will be following-up with ATT immediately to investigate this issue. >> This does not appear to be related to a hardware issue on the Internap >> side, so we will open a ticket to have ATT investigate their end >> immediately. >> > > I haven't seen anything over on the "outages" yet. > > Paul > > > Aug 27, 2008, at 7:58 PM, tbeecher at localnet.com wrote: > > >> >> Any known issues across AT&T's network? Got a couple calls for some >> access issues, I'm seeing roughly 15% loss at a couple of paths at the >> AT&T network edge. >> > > From j at arpa.com Wed Aug 27 23:08:36 2008 From: j at arpa.com (jamie) Date: Wed, 27 Aug 2008 23:08:36 -0500 Subject: ATT.net In-Reply-To: <6ff30abd0808272108s46c52dd4i121bd612c4a7f16d@mail.gmail.com> References: <50628.72.88.60.179.1219892309.squirrel@newmail.core.com> <9BEB3D00-5DDE-41CA-A3F2-289D31034655@bertain.net> <6ff30abd0808272108s46c52dd4i121bd612c4a7f16d@mail.gmail.com> Message-ID: <6ff30abd0808272108g46557d21q281760b4558798ff@mail.gmail.com> Oh. Dallas, too , even. On Wed, Aug 27, 2008 at 11:08 PM, jamie wrote: > Concur; I'm seeing two ds3's (one ptp and one ipfr) down. Down time 21:20 > CDT. Meh. > > > On Wed, Aug 27, 2008 at 11:04 PM, Paul Bertain wrote: > >> Internap notified us that they were shutting down their peering with ATT >> (AS7018) at their Dallas facility and was asking them to investigate but >> there were no listed causes for it. >> >> At approximately 21:34 CDT on August 27th, 2008, we were notified that >>> the >>> link with ATT peer (AS 7018) in the DAL PNAP was experiencing loss. We >>> have since shut down the peering and will asking ATT to investigate >>> >>> We will be following-up with ATT immediately to investigate this issue. >>> This does not appear to be related to a hardware issue on the Internap >>> side, so we will open a ticket to have ATT investigate their end >>> immediately. >>> >> >> I haven't seen anything over on the "outages" yet. >> >> Paul >> >> >> Aug 27, 2008, at 7:58 PM, tbeecher at localnet.com wrote: >> >> >>> >>> Any known issues across AT&T's network? Got a couple calls for some >>> access issues, I'm seeing roughly 15% loss at a couple of paths at the >>> AT&T network edge. >>> >> >> > From joe at sumless.net Wed Aug 27 23:08:44 2008 From: joe at sumless.net (Joe Blanchard) Date: Thu, 28 Aug 2008 00:08:44 -0400 Subject: interger to I P address In-Reply-To: <20080828024104.GA26314@vacation.karoshi.com.> Message-ID: <004d01c908c3$c5cb9bf0$1401a8c0@E520> Howdy, Careful, this appears to not be inline with another persons thoughts. Not mine mind you. "Anything concerning an "end network" is not relevant to this list. " lol I am however, very interested in the content/replies thus far. Very entertaining. Ok, sorry, back to the scheduled programs. -Joe > -----Original Message----- > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > Sent: Wednesday, August 27, 2008 10:41 PM > To: kcc > Cc: nanog at nanog.org > Subject: Re: interger to I P address > > On Wed, Aug 27, 2008 at 07:11:41AM -0400, kcc wrote: > > Hi all > > > > ls it possible t convert the interger to ip > > > > Thank you > > sure. how do you want that IP? > hex? octal, decimal, binary? (*) > v4 or v6? > > * other bases by request.... > > --bill From patrick at ianai.net Wed Aug 27 23:10:43 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 28 Aug 2008 00:10:43 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local>, <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> Message-ID: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> On Aug 27, 2008, at 11:47 PM, John Lee wrote: > The traceroute utility that I used gave me a list of hops that the > packet I was interested in transited and a time when it transited > the hop. When the TTL was reached it would terminate the listing. You are very confused how traceroute works. Being confused is fine. Lots of people are confused & ignorant. In fact, everyone is ignorant about more things than they are educated about. However, when people like Adrian, who are clearly more versed in the technology than you are, try to educate you, ignoring his kind help and repeating your confusion to 10s of 1000s of your not-so-close friends is not fine. Please read Adrian's post again, read about traceroute, and try not to post until you have understood them. (To be clear, if you come to the conclusion you are right and Adrian is wrong it means you have _not_ understood them.) > When ever I had performance issues on my networks or with my > networks links it would indicate if the standard route was being > taken or another one. When certain links went down several > additional hops would be added to the list. The fact you do not understand how traceroute works makes it obvious why you misunderstand how to diagnosis something from that lack of understanding. >> VPN's and MPLS control intermediate hops and IPsec and SSL do not >> allow the info to be seen. >> "VPNs" do no such thing. To prove this to yourself, realize that IPsec and SSL are both types of "VPNs". Encrypting the data is very useful. Hell, Anthony & Alex say so themselves. But that wasn't the point of the presentation. (And we'll ignore the fact that the size, speed, and even existence of a data stream - encrypted or not - might be useful information to a miscreant.) Lastly, can you show me a single inter-AS MPLS deployment? When you can, then you can use that as a method to avoid this h4x0r. -- TTFN, patrick From patrick at zill.net Wed Aug 27 23:20:12 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Thu, 28 Aug 2008 00:20:12 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local>, <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> Message-ID: <48B6277C.8040600@zill.net> John Lee wrote: > Adrian, > > The traceroute utility that I used gave me a list of hops that the > packet I was interested in transited and a time when it transited the > hop. When the TTL was reached it would terminate the listing. > But if I can control your traffic I could change everything, couldn't I? I mean, with the ability to inject whatever I wanted, I could spoof traceroute, yes? I could filter for that traffic and return whatever I wanted. I could manufacture a series of packets showing that NYC and London were only 10ms apart in such a case. --Patrick From john at internetassociatesllc.com Wed Aug 27 23:32:03 2008 From: john at internetassociatesllc.com (John Lee) Date: Wed, 27 Aug 2008 23:32:03 -0500 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local>, <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local>, <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942BF6159B03@MEMEXG1.HOST.local> Thanks guys, going back to my Comer one more time. My issue, question was whether the organization doing the hijacking controlled all of the routers in the new modified path or only some of them? John (ISDN) Lee ________________________________________ From: Patrick W. Gilmore [patrick at ianai.net] Sent: Thursday, August 28, 2008 12:10 AM To: NANOG list Subject: Re: Revealed: The Internet's well known BGP behavior On Aug 27, 2008, at 11:47 PM, John Lee wrote: > The traceroute utility that I used gave me a list of hops that the > packet I was interested in transited and a time when it transited > the hop. When the TTL was reached it would terminate the listing. You are very confused how traceroute works. Being confused is fine. Lots of people are confused & ignorant. In fact, everyone is ignorant about more things than they are educated about. However, when people like Adrian, who are clearly more versed in the technology than you are, try to educate you, ignoring his kind help and repeating your confusion to 10s of 1000s of your not-so-close friends is not fine. Please read Adrian's post again, read about traceroute, and try not to post until you have understood them. (To be clear, if you come to the conclusion you are right and Adrian is wrong it means you have _not_ understood them.) > When ever I had performance issues on my networks or with my > networks links it would indicate if the standard route was being > taken or another one. When certain links went down several > additional hops would be added to the list. The fact you do not understand how traceroute works makes it obvious why you misunderstand how to diagnosis something from that lack of understanding. >> VPN's and MPLS control intermediate hops and IPsec and SSL do not >> allow the info to be seen. >> "VPNs" do no such thing. To prove this to yourself, realize that IPsec and SSL are both types of "VPNs". Encrypting the data is very useful. Hell, Anthony & Alex say so themselves. But that wasn't the point of the presentation. (And we'll ignore the fact that the size, speed, and even existence of a data stream - encrypted or not - might be useful information to a miscreant.) Lastly, can you show me a single inter-AS MPLS deployment? When you can, then you can use that as a method to avoid this h4x0r. -- TTFN, patrick From hank at efes.iucc.ac.il Wed Aug 27 23:43:36 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 28 Aug 2008 07:43:36 +0300 Subject: Revealed: The Internet's Biggest Security Hole In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB450A0A59@FHDP1CCMXCV02.us.on e.verizon.com> Message-ID: <5.1.0.14.2.20080828073831.05797040@efes.iucc.ac.il> At 09:40 PM 27-08-08 -0400, marcus.sachs at verizon.com wrote: I beg to differ. What will change is a serious uptick in the number of prefixes (279K) in the routing tables as everyone rushes to deaggregate to /24 size. A year ago we were at 230K, how much you wanna bet we don't just add 40K routes over the next 12 months. -Hank >Nothing will change. You think DNSSEC is hard? Try getting support for >the deployment of S-BGP or soBGP. Without a trust anchor and lots of >community support it will remain largely an academic interest area. > >Marc > >------Original Message------ >From: Gadi Evron >To: Frank >Cc: NANOG list >Sent: Aug 27, 2008 20:54 >Subject: Re: Revealed: The Internet's Biggest Security Hole > >hehe >"new". hehe > >Maybe something will change now' though, it was a great and impressive >presentation, hijacking the defcon network and tweaking TTL to hide it. From hank at efes.iucc.ac.il Wed Aug 27 23:45:57 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 28 Aug 2008 07:45:57 +0300 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159B03@MEMEXG1.HOST.lo cal> References: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> Message-ID: <5.1.0.14.2.20080828074407.00b243f0@efes.iucc.ac.il> At 11:32 PM 27-08-08 -0500, John Lee wrote: >Thanks guys, going back to my Comer one more time. My issue, question was >whether the organization doing the hijacking controlled all of the routers >in the new modified path or only some of them? > >John (ISDN) Lee They didn't have control of any routers other than their own. What they had to find is a single clueless upstream ISP that would allow them to announce prefixes that didn't belong to them. -Hank From jlewis at lewis.org Thu Aug 28 00:18:43 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 28 Aug 2008 01:18:43 -0400 (EDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <5.1.0.14.2.20080828074407.00b243f0@efes.iucc.ac.il> References: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <5.1.0.14.2.20080828074407.00b243f0@efes.iucc.ac.il> Message-ID: On Thu, 28 Aug 2008, Hank Nussbacher wrote: > At 11:32 PM 27-08-08 -0500, John Lee wrote: >> Thanks guys, going back to my Comer one more time. My issue, question was >> whether the organization doing the hijacking controlled all of the routers >> in the new modified path or only some of them? >> >> John (ISDN) Lee > > They didn't have control of any routers other than their own. What they had > to find is a single clueless upstream ISP that would allow them to announce > prefixes that didn't belong to them. Clueless or big and inattentive? AFAIK, Level3 will accept anything from me...as long as I put it in one of the IRRs the day before I plan to announce it. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From patrick at ianai.net Thu Aug 28 00:22:21 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 28 Aug 2008 01:22:21 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942BF6159B03@MEMEXG1.HOST.local> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local>, <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local>, <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159B03@MEMEXG1.HOST.local> Message-ID: On Aug 28, 2008, at 12:32 AM, John Lee wrote: > Thanks guys, going back to my Comer one more time. My issue, > question was whether the organization doing the hijacking controlled > all of the routers in the new modified path or only some of them? That is correct. However, once a packet hits the miscreant's device, the traceroute is defeated. Assuming their device is in the right place, you will not be able to see the difference. Assuming it is in the "wrong" place, you may be able to detect the intrusion. But most people do not run traceroutes all day and watch for it to change. If you run the traceroute after the attack starts, well, how are you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02-$BLAH-$BAR is right? -- TTFN, patrick From yahoo at jimpop.com Thu Aug 28 00:40:23 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 28 Aug 2008 01:40:23 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159B03@MEMEXG1.HOST.local> Message-ID: <7ff145960808272240x8e3130dkdb6140cdde40c663@mail.gmail.com> On Thu, Aug 28, 2008 at 1:22 AM, Patrick W. Gilmore wrote: > Assuming it is in the "wrong" place, you may be able to detect the > intrusion. But most people do not run traceroutes all day and watch for it > to change. If you run the traceroute after the attack starts, well, how are > you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02-$BLAH-$BAR is > right? Uhhh... network monitoring with traceroute and topology tools. There are several off-the-shelf varieties to choose from, and I know of several providers that use them. -Jim P. From patrick at ianai.net Thu Aug 28 00:46:53 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 28 Aug 2008 01:46:53 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <7ff145960808272240x8e3130dkdb6140cdde40c663@mail.gmail.com> References: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159B03@MEMEXG1.HOST.local> <7ff145960808272240x8e3130dkdb6140cdde40c663@mail.gmail.com> Message-ID: <960F6EAB-C660-4B1D-846D-3AB8F330AEB5@ianai.net> On Aug 28, 2008, at 1:40 AM, Jim Popovitch wrote: > On Thu, Aug 28, 2008 at 1:22 AM, Patrick W. Gilmore > wrote: >> Assuming it is in the "wrong" place, you may be able to detect the >> intrusion. But most people do not run traceroutes all day and >> watch for it >> to change. If you run the traceroute after the attack starts, >> well, how are >> you to know that br01-pos07-$FOO-$BAR is wrong and br03-10GE02- >> $BLAH-$BAR is >> right? > > Uhhh... network monitoring with traceroute and topology tools. There > are several off-the-shelf varieties to choose from, and I know of > several providers that use them. I stand by my assertion that most people do not run traceroutes all day and watch for it to change. That some people are diligent does not change the fact the overwhelming majority of people are not. Or the fact that with the right placement of equipment (read "luck") and cooperation of networks involved (read "laziness"), even a traceroute won't show any change besides additional latency. -- TTFN, patrick From fergdawg at netzero.net Thu Aug 28 01:10:33 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 28 Aug 2008 06:10:33 GMT Subject: Revealed: The Internet's well known BGP behavior Message-ID: <20080827.231033.17178.0@webmail08.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Hank Nussbacher wrote: >At 11:32 PM 27-08-08 -0500, John Lee wrote: >>Thanks guys, going back to my Comer one more time. My issue, question was >> whether the organization doing the hijacking controlled all of the >>routers in the new modified path or only some of them? >> >>John (ISDN) Lee > >They didn't have control of any routers other than their own. What they had to find is a single clueless upstream ISP that would allow them to announce prefixes that didn't belong to them. > *bing* Trust is the major exploit here. That has never been "new". - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFItkFQq1pz9mNUZTMRAgqHAJ4ogryvjftxw5CQTWhf0c7VyBBXyQCfUo9w qdK2kEWHY/B1AU/rGNikOlg= =d/L7 -----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 karnaugh at karnaugh.za.net Thu Aug 28 01:26:48 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 28 Aug 2008 08:26:48 +0200 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <5.1.0.14.2.20080828074407.00b243f0@efes.iucc.ac.il> References: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <5.1.0.14.2.20080828074407.00b243f0@efes.iucc.ac.il> Message-ID: <48B64528.20302@karnaugh.za.net> On 2008/08/28 06:45 AM Hank Nussbacher wrote: > They didn't have control of any routers other than their own. What they > had to find is a single clueless upstream ISP that would allow them to > announce prefixes that didn't belong to them. > Leaving aside the ability blackhole prefixes that don't belong to you, they seem to harp on the part of being able to intercept traffic. Well, yes? Personally I don't trust GBLX (sorry) or whoever with my traffic any more than a random hacker who is rerouting the traffic. That's why things like SSL were invented. Yes, with that much control even SSL can technically be broken but if there was ever a pretext of complete trust about the possibilities of snooping on traffic then encryption wouldn't need to exist. Ultimately though, the detailed work that needs to go into pulling something like that off would make it quite hard not to leave a trail somewhere. Also, it's still far easier to just pop a trojan onto a few million machines. Shameless media hyperbole anyway... I think they saw the DNS people getting their 10 minutes of fame and wanted their own :) From eric at spaethco.com Thu Aug 28 01:41:16 2008 From: eric at spaethco.com (Eric Spaeth) Date: Thu, 28 Aug 2008 01:41:16 -0500 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <53A6C7E936ED8544B1A2BC990D254F942BF6159AFF@MEMEXG1.HOST.local> <20080828033212.GE30494@skywalker.creative.net.au> <53A6C7E936ED8544B1A2BC990D254F942BF6159B01@MEMEXG1.HOST.local> <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> <5.1.0.14.2.20080828074407.00b243f0@efes.iucc.ac.il> Message-ID: <48B6488C.20709@spaethco.com> Jon Lewis wrote: >> At 11:32 PM 27-08-08 -0500, John Lee wrote: >> >> They didn't have control of any routers other than their own. What >> they had to find is a single clueless upstream ISP that would allow >> them to announce prefixes that didn't belong to them. > > Clueless or big and inattentive? AFAIK, Level3 will accept anything > from me...as long as I put it in one of the IRRs the day before I plan > to announce it. Working for a company that has been steadily growing through acquisition, we have actually run into this problem a couple times before. I'm not sure if we hit the lottery, but our upstream providers (including LVL3) have definitely intervened when we've moved netblocks from a company that doesn't match our name into our facilities to be advertised under our ASNs. I'm not sure how diligent or widespread the validation checks are, but at least on occasion they do occur. -Eric From ge at linuxbox.org Thu Aug 28 03:58:24 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 28 Aug 2008 03:58:24 -0500 (CDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> Message-ID: On Wed, 27 Aug 2008, Patrick W. Gilmore wrote: > On Aug 27, 2008, at 11:07 PM, John Lee wrote: > >> 1. The technique is not new it is well known BGP behavior and not stealthy >> to people who route for a living. > > Using existing technology in novel ways is still novel. Plus it makes the > technique more accessible. (Perhaps that is not a good thing?) People (especially spammers) have been hijacking networks for a while now, maybe now that we have a presentation to whore around, operators can pressure vendors and bosses. Gadi. > >> 2. When your networks use VPNs, MPLS, IPsec, SSL et al you can control what >> packets are going where. > > No, you cannot. You can only ensure your end points are the end points you > think they are. In no way, shape, or form do things like IPsec, SSL, etc. > verify or control the intermediate hops. > > >> 3. When you are running some number of trace routes per hour to see how and >> where your packets are going you spot the additional hops. > > The presentation specifically shows hiding the hops by re-writing TTLs. > Perhaps you do not understand this attack as well as you thought? > > >> 4. If you do cold potatoe routing and know where you peering points are and >> what the acls and peering policies are it is more difficult to hijack. > > Would that network operators were so diligent. > > >> And finally you use high speed optical paths or broad band ISDN (ATM) why >> route when you can deterministically switch. > > Because people want to be able to reach the entire planet with a single port > and without "deterministically" creating paths to every single end point. > > Why use ISDN (ATM) when you can do something useful? > > -- > TTFN, > patrick > > From b.vontobel at meteonews.ch Thu Aug 28 04:53:59 2008 From: b.vontobel at meteonews.ch (Beat Vontobel) Date: Thu, 28 Aug 2008 11:53:59 +0200 Subject: interger to I P address In-Reply-To: <004d01c908c3$c5cb9bf0$1401a8c0@E520> References: <004d01c908c3$c5cb9bf0$1401a8c0@E520> Message-ID: <02D14C65-6216-4F0E-BDF8-8309A651C450@meteonews.ch> > "Anything concerning an "end network" is not relevant to this list. " > > lol > > I am however, very interested in the content/replies thus far. Very > entertaining. Yes, while certainly off topic, also for me it's probably been one of the most entertaining threads of this kind. So just one more solution, as there's so much unused processing power available on all your PostScript gear: Let your printer do the math! ##### BEGIN of ntoa.ps ##### %! /ntoa { 3 { dup 256 idiv exch 256 mod exch } repeat 256 mod } def /printa { 3 string cvs show 3 { (.) show 3 string cvs show } repeat } def /Helvetica findfont 36 scalefont setfont 36 444 moveto 1089055123 ntoa printa showpage ###### END of ntoa.ps ###### From ops.lists at gmail.com Thu Aug 28 05:25:49 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 28 Aug 2008 15:55:49 +0530 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> Message-ID: Most of the spammer acquired /16s have been 1. pre arin 2. caused by buying up assets of long defunct companies .. assets that just happen to include a /16 nobody knew about Not exactly hijacks this lot .. just like those "barely legal" teen mags. srs On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron wrote: > > People (especially spammers) have been hijacking networks for a while now, > maybe now that we have a presentation to whore around, operators can > pressure vendors and bosses. > From michael.dillon at bt.com Thu Aug 28 06:18:33 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Aug 2008 12:18:33 +0100 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <76AF9F98-BBAF-4BB2-9B22-328E02C2EBC0@ianai.net> Message-ID: > Lastly, can you show me a single inter-AS MPLS deployment? When you > can, then you can use that as a method to avoid this h4x0r. Just some quick googling found this from back in 2006. "Sprint has expanded its global MPLS network capabilities with network-to-network interface (NNI) partnerships and has introduced the industry's first standard end-to-end MPLS VPN SLA as part of its global network." From michael.dillon at bt.com Thu Aug 28 06:22:21 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Aug 2008 12:22:21 +0100 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <960F6EAB-C660-4B1D-846D-3AB8F330AEB5@ianai.net> Message-ID: > I stand by my assertion that most people do not run > traceroutes all day and watch for it to change. > > That some people are diligent does not change the fact the > overwhelming majority of people are not. > > Or the fact that with the right placement of equipment (read > "luck") and cooperation of networks involved (read > "laziness"), even a traceroute won't show any change besides > additional latency. Bingo! Latency is the magic word and that *IS* measured by a lot more people than do traceroutes. Unless the attackers are lucky enough or smart enough to do their dirty work from a server that is reasonably closely colocated to the router that they exploit, you *WILL* see latency changes. It would be wise to change the process for investigating latency increases to include examining routers for this BGP rerouting exploit. --Michael Dillon From patrick at ianai.net Thu Aug 28 07:01:25 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 28 Aug 2008 08:01:25 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> Message-ID: On Aug 28, 2008, at 6:25 AM, Suresh Ramasubramanian wrote: > Most of the spammer acquired /16s have been > > 1. pre arin > > 2. caused by buying up assets of long defunct companies .. assets that > just happen to include a /16 nobody knew about > > Not exactly hijacks this lot .. just like those "barely legal" teen > mags. There have been tons of spam runs I have seen from "hijacked" blocks were simply announcing an unused block or a de-agg of a used block, sending spam for a few minutes / hours / days, and stopping the announcement. This does not require special techniques, just an upstream willing to accept & propagate your announcement. Alex & Anthony's preso is about intercepting legit traffic, not sending illegitimate traffic. -- TTFN, patrick > On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron wrote: >> >> People (especially spammers) have been hijacking networks for a >> while now, >> maybe now that we have a presentation to whore around, operators can >> pressure vendors and bosses. >> > From ge at linuxbox.org Thu Aug 28 07:50:34 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 28 Aug 2008 07:50:34 -0500 (CDT) Subject: reviving the botnets@ mailing list: a new statregy in fighting cyber crime Message-ID: The public botnets@ mailing list, where malicious activity on the Internet can be openly shared, has been revived, and boy is it active. Warning: live samples and malicious URLs are openly shared there. NANOG relevance: These can be operationally used by ISP security operators not of those "in the know" to block new attacks and to identify abusers in their own networks. Reminder: this mailing list was started to take off-topic traffic from NANOG. Mailing list URL: http://www.whitestar.linuxbox.org/mailman/listinfo/botnets Reasons, thinking and explanations: http://gadievron.blogspot.com/2008/08/public-sharing-and-new-statregy-in.html Excerpt: ------ A couple of years ago I started a mailing list where folks not necessarily involved with the vetted, trusted, closed and snobbish circles of cyber crime fighting (some founded by me) could share information and be informed of threats. In this post I explore some of the history behind information sharing online, and explain the concept behind the botnets mailing list. Feel free to skip ahead if you find the history boring. Also, do note the history in this post is mixed with my own opinions. As I am one of the only people who where there in the beginning though and lived through all of it, I feel free to do so (in my own blog post). As I conclude, we may not be able to always share our resources, but it is time to change the tide of the cyber crime war, and strategize. One of the strategies we need to use, or at least try, is public information sharing of "lesser evils" already in the public domain. .. .. To fight a war, you have to be involved and engaged. On the Internet that is very difficult, but the Russians found a way. It is a fact that while we made much progress in our efforts fighting cyber crime, we had nearly no effect what-so-ever on the criminals and the attackers. Non. They maintain their business and we play at writing analysis and whack-a-mole. Using the botnets mailing list, I am burrowing a page from the apparent Russian cyber war doctrine, getting people involved, engaged. Personally aware and a part of what's going on. It can't hurt us, and perhaps now, four years over-due and two years after the previous attempt, we may be ready to give it a go and test the concept. ------- Gadi Evron. -- "You don't need your firewalls! Gadi is Israel's firewall." -- Itzik (Isaac) Cohen, "Computers czar", Senior Deputy to the Accountant General, Israel's Ministry of Finance, at the government's CIO conference, 2005. (after two very funny self-deprication quotes, time to even things up!) My profile and resume: http://www.linkedin.com/in/gadievron From mohacsi at niif.hu Thu Aug 28 08:05:41 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 28 Aug 2008 15:05:41 +0200 (CEST) Subject: interger to I P address In-Reply-To: <20080827111304.GL16377@virtual.bogons.net> References: <20080827111304.GL16377@virtual.bogons.net> Message-ID: <20080828150428.H34042@mignon.ki.iif.hu> On Wed, 27 Aug 2008, Simon Lockhart wrote: > On Wed Aug 27, 2008 at 07:11:41AM -0400, kcc wrote: >> ls it possible t convert the interger to ip > > Yes. > > Simon Yes. But be aware whether you are using IPv6 or IPv4... Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > From esavage at digitalrage.org Thu Aug 28 09:34:25 2008 From: esavage at digitalrage.org (Elijah Savage) Date: Thu, 28 Aug 2008 10:34:25 -0400 (EDT) Subject: Service Outage in Indiana Message-ID: <11224358.30571219934065488.JavaMail.root@mail> Anyone know what is going on there. Sprint Verizon data and voice circuits affected in the Fort Wayne area. From esavage at digitalrage.org Thu Aug 28 09:43:05 2008 From: esavage at digitalrage.org (Elijah Savage) Date: Thu, 28 Aug 2008 10:43:05 -0400 (EDT) Subject: Service Outage in Indiana In-Reply-To: <11224358.30571219934065488.JavaMail.root@mail> Message-ID: <13424912.30601219934585648.JavaMail.root@mail> ----- "Elijah Savage" wrote: > Anyone know what is going on there. > > Sprint Verizon data and voice circuits affected in the Fort Wayne > area. Ok I have some data now. It seems the local LEC has multiple DS3's down in the area. I asked here as a last resort because I have facilities that were down for over an hour with no answers. Sorry for the bother. From tkapela at gmail.com Thu Aug 28 10:16:16 2008 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 28 Aug 2008 10:16:16 -0500 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> Message-ID: <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> I thought I'd toss in a few comments, considering it's my fault that few people are understanding this thing yet. >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron wrote: >>> >>> People (especially spammers) have been hijacking networks for a while I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, AFP, and Forbes. We all know sub-prefix hijacking is not news. What is news? Using as-path loop detection to selectively blackhole the hijacked route - which creates a transport path _back to_ the target. That's all it is, nothing more. All but the WIRED follow-up article missed this point *completely.* They over-represented the 'hijacking' aspects, while only making mention of the 'interception' potential. Lets end this thread with the point I had intended two weeks ago: we've presented a method by which all the theory spewed by academics can be actualized in a real network (the big-I internet) to effect interception of data between (nearly) arbitrary endpoints from (nearly) any edge or stub AS. That, I think, is interesting. -Tk From Benjamin.R.Boyd at windstream.com Thu Aug 28 10:36:05 2008 From: Benjamin.R.Boyd at windstream.com (Boyd, Benjamin R) Date: Thu, 28 Aug 2008 10:36:05 -0500 Subject: Revealed: The Internet's well known BGP behavior Message-ID: <3F045502966C304B963C72E3C442750E01B3B4D0@scarlitnt840.windstream.com> We've encountered the same diligence with LVL3, especially after acquisitions where records haven't been updated yet. Although a little annoying it's quite refreshing. >-----Original Message----- >From: Eric Spaeth [mailto:eric at spaethco.com] >Sent: Thursday, August 28, 2008 1:41 AM >To: Jon Lewis; nanog at merit.edu >Subject: Re: Revealed: The Internet's well known BGP behavior > >Jon Lewis wrote: >>> At 11:32 PM 27-08-08 -0500, John Lee wrote: >>> >>> They didn't have control of any routers other than their own. What >>> they had to find is a single clueless upstream ISP that would allow >>> them to announce prefixes that didn't belong to them. >> >> Clueless or big and inattentive? AFAIK, Level3 will accept anything >> from me...as long as I put it in one of the IRRs the day >before I plan >> to announce it. > >Working for a company that has been steadily growing through >acquisition, we have actually run into this problem a couple times >before. I'm not sure if we hit the lottery, but our upstream >providers >(including LVL3) have definitely intervened when we've moved >netblocks from a company that doesn't match our name into our >facilities to be advertised under our ASNs. I'm not sure how >diligent or widespread the validation checks are, but at least >on occasion they do occur. > >-Eric > > > *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From oleg.bogdanov at morganstanley.com Thu Aug 28 10:56:08 2008 From: oleg.bogdanov at morganstanley.com (Bogdanov, Oleg (IT)) Date: Thu, 28 Aug 2008 11:56:08 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: Message-ID: <7B30DA50D89FFF4699855D0F1EAFB5990BB23D3D@NYWEXMB29.msad.ms.com> First, thank you all for the usually intelligent/enlightening discussion. My first post to this list and apologies in advance if discussion of end point (customer) networks is off-topic: I haven't seen the presentation that some of you have referred to. If someone can provide a link that would be helpful. What is the as-prepend piece of the puzzle? Insert AS numbers of ISPs in the path from hijacker to intended recipient so snooped data doesn't boomerang back to the hijacker (exploit BGP loop detection mechanism)? Theoretically, can one hijack both sender and receiver space to get inline on the whole conversation? And maybe the more relevant question: Can the customer do anything? What would my ISPs tell me if I asked them to take measures (magic ones?) to mitigate my exposure? Thanks, Oleg Bogdanov Morgan Stanley | Technology 1 Pierrepont Plaza, 12th Floor | Brooklyn, NY 11201 oleg.bogdanov at morganstanley.com -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. From smb at cs.columbia.edu Thu Aug 28 10:56:30 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 28 Aug 2008 11:56:30 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> Message-ID: <20080828115630.3feb8f7a@cs.columbia.edu> On Thu, 28 Aug 2008 10:16:16 -0500 "Anton Kapela" wrote: > I thought I'd toss in a few comments, considering it's my fault that > few people are understanding this thing yet. > > >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron > >> wrote: > >>> > >>> People (especially spammers) have been hijacking networks for a > >>> while > > I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, > AFP, and Forbes. > > We all know sub-prefix hijacking is not news. What is news? Using > as-path loop detection to selectively blackhole the hijacked route - > which creates a transport path _back to_ the target. > > That's all it is, nothing more. All but the WIRED follow-up article > missed this point *completely.* They over-represented the 'hijacking' > aspects, while only making mention of the 'interception' potential. > > Lets end this thread with the point I had intended two weeks ago: > we've presented a method by which all the theory spewed by academics > can be actualized in a real network (the big-I internet) to effect > interception of data between (nearly) arbitrary endpoints from > (nearly) any edge or stub AS. That, I think, is interesting. > Indeed, and I thank you for it. As noted, I and others have been warning about the problem for a long time. You've shown that it isn't just an ivory tower exercise; maybe people will now get serious about deploying a solution. To quote Bruce Schneier quoting an NSA maxim, attacks only get better; they never get worse. We now have running code of one way to do this. I think most NANOG readers can see many more ways to do it. A real solution will take years to deploy, but it will never happen if we don't start. And we want to have the solution out there *before* we see serious attacks on BGP. Again, thank you -- it was really nice work. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jlewis at lewis.org Thu Aug 28 12:35:41 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 28 Aug 2008 13:35:41 -0400 (EDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <3F045502966C304B963C72E3C442750E01B3B4D0@scarlitnt840.windstream.com> References: <3F045502966C304B963C72E3C442750E01B3B4D0@scarlitnt840.windstream.com> Message-ID: Do you utilize the IRR, have an as-set, and put all customer AS/CIDR's into the IRR? I've honestly never heard from LVL3 about our advertisements. Other providers have varied from just needing a web form, email, phone call, or those combined with faxed LOAs. The latter gets very annoying...but maybe it is the way it should be. On Thu, 28 Aug 2008, Boyd, Benjamin R wrote: > We've encountered the same diligence with LVL3, especially after > acquisitions where records haven't been updated yet. Although a little > annoying it's quite refreshing. > > >> -----Original Message----- >> From: Eric Spaeth [mailto:eric at spaethco.com] >> Sent: Thursday, August 28, 2008 1:41 AM >> To: Jon Lewis; nanog at merit.edu >> Subject: Re: Revealed: The Internet's well known BGP behavior >> >> Jon Lewis wrote: >>>> At 11:32 PM 27-08-08 -0500, John Lee wrote: >>>> >>>> They didn't have control of any routers other than their own. What >>>> they had to find is a single clueless upstream ISP that would allow >>>> them to announce prefixes that didn't belong to them. >>> >>> Clueless or big and inattentive? AFAIK, Level3 will accept anything >>> from me...as long as I put it in one of the IRRs the day >> before I plan >>> to announce it. >> >> Working for a company that has been steadily growing through >> acquisition, we have actually run into this problem a couple times >> before. I'm not sure if we hit the lottery, but our upstream >> providers >> (including LVL3) have definitely intervened when we've moved >> netblocks from a company that doesn't match our name into our >> facilities to be advertised under our ASNs. I'm not sure how >> diligent or widespread the validation checks are, but at least >> on occasion they do occur. >> >> -Eric >> >> >> > > *************************************************************************************** > > The information contained in this message, including attachments, may contain > privileged or confidential information that is intended to be delivered only to the > person identified above. If you are not the intended recipient, or the person > responsible for delivering this message to the intended recipient, Windstream requests > that you immediately notify the sender and asks that you do not read the message or its > attachments, and that you delete them without copying or sending them to anyone else. > > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From joelja at bogus.com Thu Aug 28 12:41:10 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 28 Aug 2008 10:41:10 -0700 Subject: Revealed: The Internet's Biggest Security Hole In-Reply-To: <5.1.0.14.2.20080828073831.05797040@efes.iucc.ac.il> References: <5.1.0.14.2.20080828073831.05797040@efes.iucc.ac.il> Message-ID: <48B6E336.4090701@bogus.com> Hank Nussbacher wrote: > At 09:40 PM 27-08-08 -0400, marcus.sachs at verizon.com wrote: > > I beg to differ. What will change is a serious uptick in the number of > prefixes (279K) in the routing tables as everyone rushes to deaggregate > to /24 size. A year ago we were at 230K, how much you wanna bet we > don't just add 40K routes over the next 12 months. if you're only seeing 2k new prefixes a week then everything is normal. a change in the slope of the curve would be cause for alarm (say 8k a week) joelja > -Hank > >> Nothing will change. You think DNSSEC is hard? Try getting support >> for the deployment of S-BGP or soBGP. Without a trust anchor and lots >> of community support it will remain largely an academic interest area. >> >> Marc >> >> ------Original Message------ >> From: Gadi Evron >> To: Frank >> Cc: NANOG list >> Sent: Aug 27, 2008 20:54 >> Subject: Re: Revealed: The Internet's Biggest Security Hole >> >> hehe >> "new". hehe >> >> Maybe something will change now' though, it was a great and impressive >> presentation, hijacking the defcon network and tweaking TTL to hide it. > > From jra at baylink.com Thu Aug 28 12:49:18 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 28 Aug 2008 13:49:18 -0400 Subject: Anton Kapela on what the BGP attack *really* means Message-ID: <20080828174918.GH8449@cgi.jachomes.com> [ I'm unthreading this, because Anton didn't think to, and I wouldn't want anyone who canned the other thread to miss it. --jra ] On Thu, Aug 28, 2008 at 11:56:30AM -0400, Steven M. Bellovin wrote: > On Thu, 28 Aug 2008 10:16:16 -0500 > "Anton Kapela" wrote: > > > I thought I'd toss in a few comments, considering it's my fault that > > few people are understanding this thing yet. > > > > >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron > > >> wrote: > > >>> > > >>> People (especially spammers) have been hijacking networks for a > > >>> while > > > > I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, > > AFP, and Forbes. > > > > We all know sub-prefix hijacking is not news. What is news? Using > > as-path loop detection to selectively blackhole the hijacked route - > > which creates a transport path _back to_ the target. > > > > That's all it is, nothing more. All but the WIRED follow-up article > > missed this point *completely.* They over-represented the 'hijacking' > > aspects, while only making mention of the 'interception' potential. > > > > Lets end this thread with the point I had intended two weeks ago: > > we've presented a method by which all the theory spewed by academics > > can be actualized in a real network (the big-I internet) to effect > > interception of data between (nearly) arbitrary endpoints from > > (nearly) any edge or stub AS. That, I think, is interesting. > > Indeed, and I thank you for it. As noted, I and others have been > warning about the problem for a long time. You've shown that it isn't > just an ivory tower exercise; maybe people will now get serious about > deploying a solution. > > To quote Bruce Schneier quoting an NSA maxim, attacks only get better; > they never get worse. We now have running code of one way to do this. > I think most NANOG readers can see many more ways to do it. A real > solution will take years to deploy, but it will never happen if we > don't start. And we want to have the solution out there *before* we > see serious attacks on BGP. > > Again, thank you -- it was really nice work. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb 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. -- (Josef Stalin) From jgreco at ns.sol.net Thu Aug 28 12:58:59 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 28 Aug 2008 12:58:59 -0500 (CDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <20080828115630.3feb8f7a@cs.columbia.edu> from "Steven M. Bellovin" at Aug 28, 2008 11:56:30 AM Message-ID: <200808281758.m7SHwxHI072599@aurora.sol.net> > To quote Bruce Schneier quoting an NSA maxim, attacks only get better; > they never get worse. We now have running code of one way to do this. > I think most NANOG readers can see many more ways to do it. A real > solution will take years to deploy, but it will never happen if we > don't start. And we want to have the solution out there *before* we > see serious attacks on BGP. > > Again, thank you -- it was really nice work. Seems like we *could* get a large part of the way there if people were only checking the information in question. While not the long-term fix of being able to prove authorization to advertise space, simply requiring a LOA at the edge, and requiring IRR further in, and keeping records of what was advertised, would seem to be a worthwhile improvement on the current state of affairs. Total prevention is a very rough goal, so making it more difficult, combined with being able to identify when someone did something bad, really ought to be a worthwhile interim goal, and I've wondered for a long time why this isn't being done. ... 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 ge at linuxbox.org Thu Aug 28 13:30:19 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 28 Aug 2008 13:30:19 -0500 (CDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> Message-ID: Thank you for making your presentation. Gadi. On Thu, 28 Aug 2008, Anton Kapela wrote: > I thought I'd toss in a few comments, considering it's my fault that > few people are understanding this thing yet. > >>> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron wrote: >>>> >>>> People (especially spammers) have been hijacking networks for a while > > I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, > AFP, and Forbes. > > We all know sub-prefix hijacking is not news. What is news? Using > as-path loop detection to selectively blackhole the hijacked route - > which creates a transport path _back to_ the target. > > That's all it is, nothing more. All but the WIRED follow-up article > missed this point *completely.* They over-represented the 'hijacking' > aspects, while only making mention of the 'interception' potential. > > Lets end this thread with the point I had intended two weeks ago: > we've presented a method by which all the theory spewed by academics > can be actualized in a real network (the big-I internet) to effect > interception of data between (nearly) arbitrary endpoints from > (nearly) any edge or stub AS. That, I think, is interesting. > > -Tk > From alex at pilosoft.com Thu Aug 28 15:25:41 2008 From: alex at pilosoft.com (Alex Pilosov) Date: Thu, 28 Aug 2008 16:25:41 -0400 (EDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> Message-ID: On Thu, 28 Aug 2008, Anton Kapela wrote: > I thought I'd toss in a few comments, considering it's my fault that > few people are understanding this thing yet. > > >> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron wrote: > >>> > >>> People (especially spammers) have been hijacking networks for a while > > I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, > AFP, and Forbes. > > We all know sub-prefix hijacking is not news. What is news? Using > as-path loop detection to selectively blackhole the hijacked route - > which creates a transport path _back to_ the target. > > That's all it is, nothing more. All but the WIRED follow-up article > missed this point *completely.* They over-represented the 'hijacking' > aspects, while only making mention of the 'interception' potential. > > Lets end this thread with the point I had intended two weeks ago: we've > presented a method by which all the theory spewed by academics can be > actualized in a real network (the big-I internet) to effect interception > of data between (nearly) arbitrary endpoints from (nearly) any edge or > stub AS. That, I think, is interesting. Yep. While it was common knowledge that it is "easy" to jack space, it was really considered in terms of "denial of service" attack. It was known that you could do traffic monitoring via manipulation of BGP communities and reinjecting traffic "closer" to the target via tunnels - however that technique is not generic. We've demonstrated ability to monitor traffic to arbitrary prefixes. Slides for presentation can be found here: http://eng.5ninesdata.com/~tkapela/iphd-2.ppt I'd also like to draw attention that it didn't draw much attention when Tony has posted immediately after the conference to the nanog-list, which has an extensive reading list - and I highly recommend that before further posting on this, you read through it. http://www.gossamer-threads.com/lists/nanog/users/107423 Added attention to the issue after our public demonstration is good news - more attention to the problem is likely to get people do use best practices in filtering. I'd also like to point out that while presentation went over a lot of people's heads at defcon, it appears that unexpectedly, it did went over people's heads here as well. To clear up some misunderstandings: *) Yes, this is a real problem. *) Yes, it has been known for years. *) There is no currently deployable solution to this problem yet. *) Filtering your customers using IRR is a requirement, however, it is not a solution - in fact, in the demonstration, we registered the /24 prefix we hijacked in IRR. RIRs need to integrate the allocation data with their IRR data. -alex [your former moderator] From randy at psg.com Thu Aug 28 16:15:22 2008 From: randy at psg.com (Randy Bush) Date: Fri, 29 Aug 2008 09:15:22 +1200 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <20080828115630.3feb8f7a@cs.columbia.edu> References: <53A6C7E936ED8544B1A2BC990D254F942BF6159AFE@MEMEXG1.HOST.local> <60A4BF0E-A3DD-4AEA-B8D6-70149FCE1A5F@ianai.net> <2e9d8ae50808280816w140d1b71h90fd404a8bcb873a@mail.gmail.com> <20080828115630.3feb8f7a@cs.columbia.edu> Message-ID: <48B7156A.2040004@psg.com> Steven M. Bellovin wrote: > On Thu, 28 Aug 2008 10:16:16 -0500 > "Anton Kapela" wrote: > >> I thought I'd toss in a few comments, considering it's my fault that >> few people are understanding this thing yet. >> >>>> On Thu, Aug 28, 2008 at 2:28 PM, Gadi Evron >>>> wrote: >>>>> People (especially spammers) have been hijacking networks for a >>>>> while >> I'd like to 'clear the air' here. Clearly, I failed at Defcon, WIRED, >> AFP, and Forbes. >> >> We all know sub-prefix hijacking is not news. What is news? Using >> as-path loop detection to selectively blackhole the hijacked route - >> which creates a transport path _back to_ the target. >> >> That's all it is, nothing more. All but the WIRED follow-up article >> missed this point *completely.* They over-represented the 'hijacking' >> aspects, while only making mention of the 'interception' potential. >> >> Lets end this thread with the point I had intended two weeks ago: >> we've presented a method by which all the theory spewed by academics >> can be actualized in a real network (the big-I internet) to effect >> interception of data between (nearly) arbitrary endpoints from >> (nearly) any edge or stub AS. That, I think, is interesting. >> > Indeed, and I thank you for it. As noted, I and others have been > warning about the problem for a long time. You've shown that it isn't > just an ivory tower exercise; maybe people will now get serious about > deploying a solution. > > To quote Bruce Schneier quoting an NSA maxim, attacks only get better; > they never get worse. We now have running code of one way to do this. > I think most NANOG readers can see many more ways to do it. A real > solution will take years to deploy, but it will never happen if we > don't start. And we want to have the solution out there *before* we > see serious attacks on BGP. > > Again, thank you -- it was really nice work. From deepak at ai.net Thu Aug 28 16:47:30 2008 From: deepak at ai.net (Deepak Jain) Date: Thu, 28 Aug 2008 17:47:30 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: Message-ID: <48B71CF2.9010006@ai.net> > *) Filtering your customers using IRR is a requirement, however, it is not > a solution - in fact, in the demonstration, we registered the /24 prefix > we hijacked in IRR. RIRs need to integrate the allocation data with their > IRR data. > further clarification... [if this is obvious, just skip over the message]. IRR filters helps prevent *accidental* hijacking and *accidental* route spillage. In that, they seem to do their job. I don't know why people think that would help prevent a deliberate hijacking job. I don't think there is enough "trust" in the IP allocation system from the RIRs yet (trust anchors being the word of the week) to even contemplate non-repudiation in advertisements yet. We can go into lots of reasons why the Internet runs this way. I think we can all agree 1) Its amazing it runs as well as it does, and 2) No one has clearly articulated a financial reason for any large organizations to significantly change their interconnection methodologies over the current BCP [that exceeds the costs of doing so]. Until either of those assertions change, the status quo will essentially remain. Alex et al, I apologize if you already covered this in your preso... One way to help mitigate the effects of this [as a user] is to keep all of your conversation end points on the same network -- especially if you run a VPN or similar -- and [rather than scan your traceroutes daily as someone suggested] scan the IRRs daily to make sure no changes have been entered for prefixes you care about. Just some thoughts, Deepak Jain From briand at ca.afilias.info Thu Aug 28 17:25:38 2008 From: briand at ca.afilias.info (Brian Dickson) Date: Thu, 28 Aug 2008 18:25:38 -0400 Subject: Great Suggestion for the DNS problem...? In-Reply-To: <488E87E9.7010209@ca.afilias.info> References: <47EFCC57.7070002@ca.afilias.info> <488E87E9.7010209@ca.afilias.info> Message-ID: <48B725E2.9000403@ca.afilias.info> Alex P wrote: > *) There is no currently deployable solution to this problem yet. > > *) Filtering your customers using IRR is a requirement, however, it is > not > a solution - in fact, in the demonstration, we registered the /24 prefix > we hijacked in IRR. RIRs need to integrate the allocation data with their > IRR data. > > -alex [your former moderator] Kind of true. When doing *prefix* filtering, this kind of hijack is not preventable. However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented. The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR). If the as-path filter only allows generally-feasible as-paths from customers, where the permitted variations are just "N copies of ASfoo" (where "foo" is a member of an as-set), then adding a fake "ASbar" in the as-path will cause the prefix to be rejected. If you follow the diagram from the presentation, information about the *real* path to the victim, from the perspective of the hijacker, requires that the AS's on that path not see the hijacked prefix as announced by the hijackers. This means that if the AS's traversed are: as-hijacker, as-bar, as-victim, then as-bar must *not* see the hijacked victim, for the attack to work. By adding "as-bar" into the as-path of the hijacked prefix, the loop-prevention logic of BGP makes sure as-bar can't see the hijacked prefix. So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails. I hope I haven't managed to confuse folks too much. But, the short answer is: If you use the IRR, the full value is best realized by adding *as-path* filters to the things you build from the IRR data, and applying them to your customers (and peers !!). Oh, and if you already do IRR stuff, it's really quite easy to do. Brian Dickson From briand at ca.afilias.info Thu Aug 28 17:32:42 2008 From: briand at ca.afilias.info (Brian Dickson) Date: Thu, 28 Aug 2008 18:32:42 -0400 Subject: Revealed: The Internet's well known In-Reply-To: <488E87E9.7010209@ca.afilias.info> References: <47EFCC57.7070002@ca.afilias.info> <488E87E9.7010209@ca.afilias.info> Message-ID: <48B7278A.6070005@ca.afilias.info> (Sorry - repost with fixed Subject line. My bad. -briand) Alex P wrote: > *) There is no currently deployable solution to this problem yet. > > *) Filtering your customers using IRR is a requirement, however, it is > not > a solution - in fact, in the demonstration, we registered the /24 prefix > we hijacked in IRR. RIRs need to integrate the allocation data with their > IRR data. > > -alex [your former moderator] Kind of true. When doing *prefix* filtering, this kind of hijack is not preventable. However, if *AS-path* filtering is done based on IRR data, specifically on the as-sets of customers and customers' customers etc., then the attack *can* be prevented. The as-path prepending depends on upstreams and their peers accepting the prefix with a path which differs from the expected path (if the upstreams register their as-sets in the IRR). If the as-path filter only allows generally-feasible as-paths from customers, where the permitted variations are just "N copies of ASfoo" (where "foo" is a member of an as-set), then adding a fake "ASbar" in the as-path will cause the prefix to be rejected. If you follow the diagram from the presentation, information about the *real* path to the victim, from the perspective of the hijacker, requires that the AS's on that path not see the hijacked prefix as announced by the hijackers. This means that if the AS's traversed are: as-hijacker, as-bar, as-victim, then as-bar must *not* see the hijacked victim, for the attack to work. By adding "as-bar" into the as-path of the hijacked prefix, the loop-prevention logic of BGP makes sure as-bar can't see the hijacked prefix. So, if the upstreams of as-hijacker reject all prefixes with an as-path which includes as-bar (because as-bar is not a member of any customer's as-set expansion), the attack fails. I hope I haven't managed to confuse folks too much. But, the short answer is: If you use the IRR, the full value is best realized by adding *as-path* filters to the things you build from the IRR data, and applying them to your customers (and peers !!). Oh, and if you already do IRR stuff, it's really quite easy to do. Brian Dickson From danny at tcb.net Thu Aug 28 18:42:46 2008 From: danny at tcb.net (Danny McPherson) Date: Thu, 28 Aug 2008 17:42:46 -0600 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <48B71CF2.9010006@ai.net> References: <48B71CF2.9010006@ai.net> Message-ID: <5BF5F4A5-2663-4552-8A89-5392D74D138F@tcb.net> On Aug 28, 2008, at 3:47 PM, Deepak Jain wrote: > > We can go into lots of reasons why the Internet runs this way. I > think we can all agree 1) Its amazing it runs as well as it does, > and 2) No one has clearly articulated a financial reason for any > large organizations to significantly change their interconnection > methodologies over the current BCP [that exceeds the costs of doing > so]. > > Until either of those assertions change, the status quo will > essentially remain. Well, there's also been a bit of a chicken and egg problem here - as no formally verifiable authoritative source for who is authorized to originate what IP address space has ever existed, and until that happens, you can't secure the routing system. Fortunately, the RPKI work will address this, and some of the RIRs are working on RPKI implementations now. If there are ways the IRRs can be populated using this information and non-RPKI derived updates can be considered less preferable (whatever that means), then we can get to a better place with the IRRs as a stop gap until a secure routing protocol can actually be deployed. However, without that as a stepping stone, it's an awfully large leap from RPKI directly into a secure inter-domain routing protocol. -danny From glen.kent at gmail.com Thu Aug 28 18:44:44 2008 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 29 Aug 2008 05:14:44 +0530 Subject: IP Fragmentation In-Reply-To: <48AC5223.7060807@Lugoj.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <48AC5223.7060807@Lugoj.com> Message-ID: <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> > > > I'm not sure how to address the above points since there appear to be some > incorrect assumptions at play. It all depends on whether the Don't Fragment > (DF) bit is set in IPv4 and how the source application responds to any > resulting ICMP error responses (if the DF is set and one of the routes > requires fragmentation). OK, so what happens if a transit router does not support IP fragmentation and it receives a packet which is bigger than the outgoing link's MTU. Should it simply drop the packet or proactively send an ICMP Dest Unreachable error (Frag required) to the peer? I understand that routers usually must send this error only when a fragmentation is required and they recieve a packet with DF bit set. However, in this case this router would drop the packet (for it doesnt support fragmentation) and sending an ICMP error back to the host, warning it that its packets will get dropped seems to be a better option. OTOH, what do most of the implementations do if they send a regular IP packet and receive an ICMP dest unreachable - Fragmentation reqd message back? Do they fragment this packet and then send it out, or this message is silently ignored? Glen From fernando at gont.com.ar Thu Aug 28 18:46:56 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 28 Aug 2008 20:46:56 -0300 Subject: IP Fragmentation In-Reply-To: <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.co m> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <48AC5223.7060807@Lugoj.com> <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> Message-ID: <200808282351.m7SNp4WC011133@venus.xmundo.net> At 08:44 p.m. 28/08/2008, Glen Kent wrote: >I understand that routers usually must send this error only when a >fragmentation is required and they recieve a packet with DF bit set. >However, in this case this router would drop the packet (for it doesnt >support fragmentation) and sending an ICMP error back to the host, >warning it that its packets will get dropped seems to be a better >option. > >OTOH, what do most of the implementations do if they send a regular IP >packet and receive an ICMP dest unreachable - Fragmentation reqd >message back? Do they fragment this packet and then send it out, or >this message is silently ignored? You may want to have a look at this IETF I-D: http://www.gont.com.ar/drafts/icmp-attacks/draft-ietf-tcpm-icmp-attacks-03.txt. The PMTUD modification described in the draft ships (at least) in OpenBSD and NetBSD. Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From tony.li at tony.li Thu Aug 28 18:57:23 2008 From: tony.li at tony.li (Tony Li) Date: Thu, 28 Aug 2008 16:57:23 -0700 Subject: IP Fragmentation In-Reply-To: <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com><48AC5223.7060807@Lugoj.com> <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> Message-ID: <8F1036ACA3624834A438CD51E58963BD@ad.redback.com> |OK, so what happens if a transit router does not support IP |fragmentation All IPv4 routers are supposed to support fragmentation per RFC 1812 (Router Requirements), section 4.2.2.7. Tony From glen.kent at gmail.com Thu Aug 28 19:14:28 2008 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 29 Aug 2008 05:44:28 +0530 Subject: IP Fragmentation In-Reply-To: <8F1036ACA3624834A438CD51E58963BD@ad.redback.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <48AC5223.7060807@Lugoj.com> <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> <8F1036ACA3624834A438CD51E58963BD@ad.redback.com> Message-ID: <92c950310808281714l4d9abca4r96dadd3b2dc33b4c@mail.gmail.com> I understand, but the question is what if they dont? Or let me rephrase the question. What do standard implementations do if they send a regular IP packet (no DF bit set) and receive an ICMP dest unreachable - Fragmentation reqd message back? Do they fragment this packet and then send it out again with the MTU reported in the ICMP error message, or is the ICMP error message silently ignored? Glen On 8/29/08, Tony Li wrote: > > > |OK, so what happens if a transit router does not support IP > |fragmentation > > > All IPv4 routers are supposed to support fragmentation per RFC 1812 (Router > Requirements), section 4.2.2.7. > > Tony > > From alex at pilosoft.com Thu Aug 28 21:26:14 2008 From: alex at pilosoft.com (Alex Pilosov) Date: Thu, 28 Aug 2008 22:26:14 -0400 (EDT) Subject: Great Suggestion for the DNS problem...? In-Reply-To: <48B725E2.9000403@ca.afilias.info> Message-ID: On Thu, 28 Aug 2008, Brian Dickson wrote: > However, if *AS-path* filtering is done based on IRR data, specifically > on the as-sets of customers and customers' customers etc., then the > attack *can* be prevented. > > The as-path prepending depends on upstreams and their peers accepting > the prefix with a path which differs from the expected path (if the > upstreams register their as-sets in the IRR). You are thinking about this specific exploit - which may in fact be stopped by as-path-filtering. However, that's not the problem you are solving. Problem is the hijacking. There are many other ways to reinject traffic closer to victim - will require attacker to work a little harder, but not really fix the problem. (Think, GRE tunnels, no-export, no-export-to-specific-peer, etc). > So, if the upstreams of as-hijacker reject all prefixes with an as-path > which includes as-bar (because as-bar is not a member of any customer's > as-set expansion), the attack fails. What's to stop me from adding as-bar into my as-set? To do what you are describing, you will have to enforce "export AS-LEFT" and "import AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if existing tools can do that - or how many existing adjacencies fail that test. From briand at ca.afilias.info Thu Aug 28 22:35:24 2008 From: briand at ca.afilias.info (Brian Dickson) Date: Thu, 28 Aug 2008 23:35:24 -0400 Subject: Great Suggestion for the DNS problem...? In-Reply-To: References: Message-ID: <48B76E7C.8000403@ca.afilias.info> Alex Pilosov wrote: > On Thu, 28 Aug 2008, Brian Dickson wrote: > > >> However, if *AS-path* filtering is done based on IRR data, specifically >> on the as-sets of customers and customers' customers etc., then the >> attack *can* be prevented. >> >> The as-path prepending depends on upstreams and their peers accepting >> the prefix with a path which differs from the expected path (if the >> upstreams register their as-sets in the IRR). >> > You are thinking about this specific exploit - which may in fact be > stopped by as-path-filtering. However, that's not the problem you are > solving. Problem is the hijacking. There are many other ways to reinject > traffic closer to victim - will require attacker to work a little harder, > but not really fix the problem. (Think, GRE tunnels, no-export, > no-export-to-specific-peer, etc). > > > > Very true. Tying allocations and assignments to ASN-of-origin and providing a suitable place to validate such, for building prefix and as-path filters, would do a lot towards further limiting the ability to hijack prefixes - but only to the degree to which providers filter their customers. And that's only on routes - to say nothing of packet filtering (BCP 38)... >> So, if the upstreams of as-hijacker reject all prefixes with an as-path >> which includes as-bar (because as-bar is not a member of any customer's >> as-set expansion), the attack fails. >> > What's to stop me from adding as-bar into my as-set? To do what you are > describing, you will have to enforce "export AS-LEFT" and "import > AS-RIGHT" rules on every pair of AS-PATH adjacencies. And I'm not sure if > existing tools can do that - or how many existing adjacencies fail that > test. > > > True, there is nothing actually stopping you from doing this. However, (and this is both the key, and a big presumption) changes to as-sets are the kind of thing that automatic provisioning tools should alert on, and require confirmation of, before updating prefix-lists and as-path lists based on the new members of the as-set. While prefixes are routinely added, new transit relationships at a BGP level don't happen all *that* often. The idea isn't just to stop the prefix announcement, it is to trap activity that would otherwise permit the prefix hijack, at the time it occurs and before it takes effect. The closer this occurs to the hijacker, the more likely it is that appropriate responses can be directed at the bad guy, and with a greater likelihood of success (e.g. prosecution). The threat alone of such response may act as a suitable deterrent... As for the filter building and enforcement mechanisms: The inbound as-path filters need to permit the permutations of paths that result from expanding as-sets, but that can be accomplished unilaterally on ingress, without enforcement beyond the immediate peering session. The expansion is for each as-set behind an ASN, there should be a corresponding as-set, and so on... each gets expanded and added to the expansion of the permitted paths via that ASN. Lather, rinse, repeat. All filtering is local, although the more places filtering happens, the better. Brian From frnkblk at iname.com Thu Aug 28 22:55:49 2008 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 28 Aug 2008 22:55:49 -0500 Subject: Generic network agreement template Message-ID: I need to supply a network agreement to a friendly customer so that they can obtain an ASN from ARIN. Some of you will mutter that we should have executed one already, but we still shake on things around here. Does anyone have a simple, even one-page template of a network agreement that they can share? Please e-mail me offline. Thanks, Frank From swmike at swm.pp.se Fri Aug 29 01:46:28 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 29 Aug 2008 08:46:28 +0200 (CEST) Subject: Great Suggestion for the DNS problem...? In-Reply-To: <48B725E2.9000403@ca.afilias.info> References: <47EFCC57.7070002@ca.afilias.info> <488E87E9.7010209@ca.afilias.info> <48B725E2.9000403@ca.afilias.info> Message-ID: On Thu, 28 Aug 2008, Brian Dickson wrote: > However, if *AS-path* filtering is done based on IRR data, specifically > on the as-sets of customers and customers' customers etc., then the > attack *can* be prevented. Yes, but I can't do this for everybody else. Doing AS-path and prefix filtering (matching that a certain prefix can only be announced by a certain AS) doesn't scale in IOS for instance. We do prefix filtering for OUR customers, but there is no feasable way for me to do this for everybody else. I think this needs to be fixed, but it involves something new that isn't present today, and I think it needs to involve vendors because they need to produce new code to handle it. -- Mikael Abrahamsson email: swmike at swm.pp.se From iljitsch at muada.com Fri Aug 29 04:18:23 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 29 Aug 2008 11:18:23 +0200 Subject: IP Fragmentation In-Reply-To: <92c950310808281714l4d9abca4r96dadd3b2dc33b4c@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <48AC5223.7060807@Lugoj.com> <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> <8F1036ACA3624834A438CD51E58963BD@ad.redback.com> <92c950310808281714l4d9abca4r96dadd3b2dc33b4c@mail.gmail.com> Message-ID: On 29 aug 2008, at 2:14, Glen Kent wrote: > I understand, but the question is what if they dont? Then the internet breaks. From karnaugh at karnaugh.za.net Fri Aug 29 04:34:50 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 29 Aug 2008 11:34:50 +0200 Subject: HurricaneElectric Message-ID: <48B7C2BA.3060106@karnaugh.za.net> Is anyone from Hurricane Electric/TunnelBroker.net here? From cidr-report at potaroo.net Fri Aug 29 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Aug 2008 22:00:03 +1000 (EST) Subject: BGP Update Report Message-ID: <200808291200.m7TC03vD033648@wattle.apnic.net> BGP Update Report Interval: 28-Jul-08 -to- 28-Aug-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 161731 2.9% 129.3 -- SIFY-AS-IN Sify Limited 2 - AS1803 102448 1.8% 78.9 -- ICMNET-5 - Sprint 3 - AS5691 75708 1.4% 5823.7 -- MITRE-AS-5 - The MITRE Corporation 4 - AS8151 70862 1.3% 31.8 -- Uninet S.A. de C.V. 5 - AS9051 63939 1.1% 404.7 -- IDM Autonomous System 6 - AS4538 47320 0.8% 9.4 -- ERX-CERNET-BKB China Education and Research Network Center 7 - AS10396 39967 0.7% 579.2 -- COQUI-NET - DATACOM CARIBE, INC. 8 - AS17488 37375 0.7% 25.3 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS8866 35099 0.6% 109.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - AS9299 33606 0.6% 26.2 -- IPG-AS-AP Philippine Long Distance Telephone Company 11 - AS6298 33223 0.6% 15.6 -- COX-PHX - Cox Communications Inc. 12 - AS14522 32412 0.6% 158.1 -- Satnet 13 - AS6389 31280 0.6% 7.6 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 14 - AS5056 30874 0.6% 253.1 -- INS-NET-2 - Iowa Network Services 15 - AS3464 30227 0.5% 81.3 -- ASC-NET - Alabama Supercomputer Network 16 - AS28194 29473 0.5% 4912.2 -- 17 - AS209 29222 0.5% 5.9 -- ASN-QWEST - Qwest 18 - AS18231 28359 0.5% 114.8 -- EXATT-AS-AP IOL NETCOM LTD 19 - AS17974 27926 0.5% 36.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS33783 27785 0.5% 199.9 -- EEPAD TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 18957 0.3% 18957.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS29910 8263 0.1% 8263.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 3 - AS47467 14731 0.3% 7365.5 -- GRIFFEL Griffel AB 4 - AS5691 75708 1.4% 5823.7 -- MITRE-AS-5 - The MITRE Corporation 5 - AS28194 29473 0.5% 4912.2 -- 6 - AS40627 8677 0.2% 4338.5 -- RC-COLO1 - RingCentral Inc 7 - AS43299 3980 0.1% 3980.0 -- TELECONTACT-AS Telecontact Ltd. 8 - AS23082 18566 0.3% 3713.2 -- MPHI - Michigan Public Health Institute 9 - AS27245 5896 0.1% 2948.0 -- HEIDRICK-CHICAGO - HEIDRICK 10 - AS39748 2137 0.0% 2137.0 -- VITAS VITAS LLC 11 - AS30929 2110 0.0% 2110.0 -- HUTCB Hidrotechnical Faculty - Technical University 12 - AS4184 4002 0.1% 2001.0 -- STORTEK-WHQ - Storage Technology Corporation 13 - AS23917 1888 0.0% 1888.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS14756 1796 0.0% 1796.0 -- ATMOSPHERE-AS - Atmosphere 15 - AS39794 1782 0.0% 1782.0 -- EL-KOZIENICE-AS Elektrownia Kozienice S.A. 16 - AS30969 18315 0.3% 1665.0 -- TAN-NET TransAfrica Networks 17 - AS11268 1651 0.0% 1651.0 -- WNM-ORG - Walls New Media 18 - AS42795 1599 0.0% 1599.0 -- XEROX-GENERAL-AS Xerox General Services 19 - AS31567 15881 0.3% 1588.1 -- AKSORAN Aksoran LCC 20 - AS28542 1543 0.0% 1543.0 -- Gobierno del Estado de Coahuila TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 75632 1.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 194.126.143.0/24 61225 1.0% AS9051 -- IDM Autonomous System 3 - 221.134.222.0/24 60139 1.0% AS9583 -- SIFY-AS-IN Sify Limited 4 - 83.228.71.0/24 28026 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 5 - 221.128.192.0/18 25757 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 72.50.96.0/20 24225 0.4% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 7 - 12.8.7.0/24 18957 0.3% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 8 - 210.214.151.0/24 14904 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 196.42.0.0/20 14593 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 10 - 89.38.98.0/23 13305 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 11 - 210.210.112.0/24 12032 0.2% AS9583 -- SIFY-AS-IN Sify Limited 12 - 221.135.80.0/24 11995 0.2% AS9583 -- SIFY-AS-IN Sify Limited 13 - 203.63.26.0/24 11584 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 14 - 195.251.5.0/24 11458 0.2% AS5408 -- GR-NET Greek Research & Technology Network, http://www.grnet.gr 15 - 196.27.104.0/21 8984 0.1% AS30969 -- TAN-NET TransAfrica Networks 16 - 83.239.192.0/21 8925 0.1% AS42362 -- ALANIA-AS Sevosetinelectrosvyaz 17 - 205.162.132.0/23 8880 0.1% AS23541 -- Scarlet B.V. 18 - 196.27.108.0/22 8849 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 202.52.245.0/24 8368 0.1% AS4613 -- MOS-NP Mercantile Office Systems 20 - 63.239.134.0/24 8263 0.1% AS29910 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 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 Aug 29 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Aug 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200808291200.m7TC000m033631@wattle.apnic.net> This report has been generated at Fri Aug 29 21:18:25 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 22-08-08 276915 170364 23-08-08 278717 170858 24-08-08 278619 170869 25-08-08 278715 171104 26-08-08 278889 171519 27-08-08 279124 171732 28-08-08 278921 172395 29-08-08 279583 170820 AS Summary 29241 Number of ASes in routing system 12343 Number of ASes announcing only one prefix 5015 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88351232 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'). --- 29Aug08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 279883 172711 107172 38.3% All ASes AS4538 5015 881 4134 82.4% ERX-CERNET-BKB China Education and Research Network Center AS6389 4313 358 3955 91.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2899 666 2233 77.0% ASN-QWEST - Qwest AS4755 1720 250 1470 85.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6298 2008 811 1197 59.6% COX-PHX - Cox Communications Inc. AS17488 1371 305 1066 77.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1046 45 1001 95.7% COVAD - Covad Communications Co. AS8151 1589 605 984 61.9% Uninet S.A. de C.V. AS1785 1650 674 976 59.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4323 1494 560 934 62.5% TWTC - tw telecom holdings, inc. AS22773 968 76 892 92.1% CCINET-2 - Cox Communications Inc. AS19262 944 198 746 79.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1214 502 712 58.6% CABLEONE - CABLE ONE AS2386 1563 917 646 41.3% INS-AS - AT&T Data Communications Services AS9498 674 65 609 90.4% BBIL-AP BHARTI Airtel Ltd. AS6478 1134 560 574 50.6% ATT-INTERNET3 - AT&T WorldNet Services AS18101 696 174 522 75.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4766 900 410 490 54.4% KIXS-AS-KR Korea Telecom AS4808 626 152 474 75.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 589 119 470 79.8% CANET-ASN-4 - Bell Aliant AS22047 564 127 437 77.5% VTR BANDA ANCHA S.A. AS7018 1431 996 435 30.4% ATT-INTERNET4 - AT&T WorldNet Services AS9443 524 89 435 83.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4134 838 407 431 51.4% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 572 154 418 73.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7011 903 491 412 45.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7029 522 112 410 78.5% WINDSTREAM - Windstream Communications Inc AS4668 683 274 409 59.9% LGNET-AS-KR LG CNS AS4780 717 322 395 55.1% SEEDNET Digital United Inc. AS17676 525 148 377 71.8% GIGAINFRA BB TECHNOLOGY Corp. Total 39692 11448 28244 71.2% Top 30 total Possible Bogus Routes 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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 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.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 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.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 91.208.176.0/24 AS35369 LAGIS-AS lagis Internet Serviceprovider GmbH 95.165.192.0/19 AS12479 UNI2-AS Uni2 Autonomous System 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 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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 188.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 188.0.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 AS2018 TENET-1 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.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.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 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 - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 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.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 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.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.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.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 - tw telecom holdings, 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.48.58.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.48.60.0/24 AS4323 TWTC - tw telecom holdings, 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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 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. 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 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 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.127.124.0/23 AS2828 XO-AS15 - XO Communications 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.176.22.0/24 AS20299 Newcom Limited 216.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 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 sam_mailinglists at spacething.org Fri Aug 29 08:52:27 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Fri, 29 Aug 2008 14:52:27 +0100 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <3F045502966C304B963C72E3C442750E01B3B4D0@scarlitnt840.windstream.com> Message-ID: <48B7FF1B.7070909@spacething.org> Jon Lewis wrote: > Do you utilize the IRR, have an as-set, and put all customer AS/CIDR's > into the IRR? I've honestly never heard from LVL3 about our > advertisements. Other providers have varied from just needing a web > form, email, phone call, or those combined with faxed LOAs. The > latter gets very annoying...but maybe it is the way it should be. > Level3 pull information from a number of sources, including RIPE where we register our routes. One of the nice things about their setup is you can query a whois interface to check the filter generation: e.g. (to pick someone else's AS-MACRO at random) whois -h filtergen.level3.net RIPE::AS-DEMON Sam From braaen at zcorum.com Fri Aug 29 10:04:51 2008 From: braaen at zcorum.com (Brian Raaen) Date: Fri, 29 Aug 2008 11:04:51 -0400 Subject: Using 32 bit ASN numbers Message-ID: <200808291104.52068.braaen@zcorum.com> I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer braaen at zcorum.com From anwalam at yahoo.com Fri Aug 29 10:29:21 2008 From: anwalam at yahoo.com (andy lam) Date: Fri, 29 Aug 2008 08:29:21 -0700 (PDT) Subject: Using 32 bit ASN numbers In-Reply-To: <200808291104.52068.braaen@zcorum.com> Message-ID: <616705.76791.qm@web42103.mail.mud.yahoo.com> ? Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN?Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. ? 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. ? ? Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen wrote: From: Brian Raaen Subject: Using 32 bit ASN numbers To: nanog at merit.edu Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer braaen at zcorum.com From James.Pender at PAETEC.com Fri Aug 29 10:44:51 2008 From: James.Pender at PAETEC.com (Pender, James) Date: Fri, 29 Aug 2008 11:44:51 -0400 Subject: Using 32 bit ASN numbers In-Reply-To: <616705.76791.qm@web42103.mail.mud.yahoo.com> Message-ID: <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -----Original Message----- From: andy lam [mailto:anwalam at yahoo.com] Sent: Friday, August 29, 2008 11:29 AM To: nanog at merit.edu; Brian Raaen Subject: Re: Using 32 bit ASN numbers ? Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. ? 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. ? ? Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen wrote: From: Brian Raaen Subject: Using 32 bit ASN numbers To: nanog at merit.edu Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer braaen at zcorum.com From Valdis.Kletnieks at vt.edu Fri Aug 29 12:19:31 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 Aug 2008 13:19:31 -0400 Subject: IP Fragmentation In-Reply-To: Your message of "Fri, 29 Aug 2008 05:44:28 +0530." <92c950310808281714l4d9abca4r96dadd3b2dc33b4c@mail.gmail.com> References: <92c950310808200913s6e8bbab8pbc30492eebfc79bf@mail.gmail.com> <48AC5223.7060807@Lugoj.com> <92c950310808281644h3549166csd5581889c164eba2@mail.gmail.com> <8F1036ACA3624834A438CD51E58963BD@ad.redback.com> <92c950310808281714l4d9abca4r96dadd3b2dc33b4c@mail.gmail.com> Message-ID: <62292.1220030371@turing-police.cc.vt.edu> On Fri, 29 Aug 2008 05:44:28 +0530, Glen Kent said: > I understand, but the question is what if they dont? If it's an alleged router, and it doesn't know how to frag a packet, it's probably so brain-damaged that it can't send a recognizable 'Frag Needed' ICMP back either. At that point, all bets are off... > What do standard implementations do if they send a regular IP packet > (no DF bit set) and receive an ICMP dest unreachable - Fragmentation > reqd message back? Do they fragment this packet and then send it out > again with the MTU reported in the ICMP error message, or is the ICMP > error message silently ignored? A quick perusal of the current Linux 2.6 net/ipv4/icmp.c source says this case ICMP_FRAG_NEEDED: if (ipv4_config.no_pmtu_disc) { LIMIT_NETDEBUG(KERN_INFO "ICMP: " NIPQUAD_FMT ": " "fragmentation needed " "and DF set.\n", NIPQUAD(iph->daddr)); } else { info = ip_rt_frag_needed(net, iph, ntohs(icmph->un.frag.mtu), skb->dev); In other words, if we're configured to do PMTU discovery, we cut back the MTU, and if PMTUD is disabled, we make a note in the kernel log that something odd happened and keep going. Note that it's by definition "odd", because if PMTUD is disabled, we didn't *send* a packet with the DF bit set, so any ICMP error complaining about a DF bit we didn't set is considered spurious. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From christian at broknrobot.com Fri Aug 29 12:45:40 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 29 Aug 2008 13:45:40 -0400 Subject: HurricaneElectric In-Reply-To: <48B7C2BA.3060106@karnaugh.za.net> References: <48B7C2BA.3060106@karnaugh.za.net> Message-ID: you might want to check the obvious first :) http://www.tunnelbroker.net/forums/ ipv6 at he.net On Fri, Aug 29, 2008 at 5:34 AM, Colin Alston wrote: > Is anyone from Hurricane Electric/TunnelBroker.net here? > > From cscora at apnic.net Fri Aug 29 13:08:19 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Aug 2008 04:08:19 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200808291808.m7TI8JQd029330@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 30 Aug, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 267403 Prefixes after maximum aggregation: 129611 Deaggregation factor: 2.06 Unique aggregates announced to Internet: 130029 Total ASes present in the Internet Routing Table: 29086 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25321 Origin ASes announcing only one prefix: 12271 Transit ASes present in the Internet Routing Table: 3765 Transit-only ASes present in the Internet Routing Table: 83 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 584 Unregistered ASNs in the Routing Table: 211 Number of 32-bit ASNs allocated by the RIRs: 59 Prefixes from 32-bit ASNs in the Routing Table: 7 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 758 Number of addresses announced to Internet: 1895287072 Equivalent to 112 /8s, 247 /16s and 201 /24s Percentage of available address space announced: 51.1 Percentage of allocated address space announced: 62.1 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.3 Total number of prefixes smaller than registry allocations: 131240 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 61349 Total APNIC prefixes after maximum aggregation: 22780 APNIC Deaggregation factor: 2.69 Prefixes being announced from the APNIC address blocks: 58289 Unique aggregates announced from the APNIC address blocks: 26196 APNIC Region origin ASes present in the Internet Routing Table: 3351 APNIC Prefixes per ASN: 17.39 APNIC Region origin ASes announcing only one prefix: 885 APNIC Region transit ASes present in the Internet Routing Table: 511 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 374332192 Equivalent to 22 /8s, 79 /16s and 219 /24s Percentage of available APNIC address space announced: 79.7 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: 122481 Total ARIN prefixes after maximum aggregation: 64799 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91576 Unique aggregates announced from the ARIN address blocks: 35030 ARIN Region origin ASes present in the Internet Routing Table: 12412 ARIN Prefixes per ASN: 7.38 ARIN Region origin ASes announcing only one prefix: 4782 ARIN Region transit ASes present in the Internet Routing Table: 1189 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 360803168 Equivalent to 21 /8s, 129 /16s and 107 /24s Percentage of available ARIN address space announced: 74.2 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: 57701 Total RIPE prefixes after maximum aggregation: 34980 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 52817 Unique aggregates announced from the RIPE address blocks: 35529 RIPE Region origin ASes present in the Internet Routing Table: 11793 RIPE Prefixes per ASN: 4.48 RIPE Region origin ASes announcing only one prefix: 6194 RIPE Region transit ASes present in the Internet Routing Table: 1795 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 370029760 Equivalent to 22 /8s, 14 /16s and 52 /24s Percentage of available RIPE address space announced: 84.8 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: 21248 Total LACNIC prefixes after maximum aggregation: 5325 LACNIC Deaggregation factor: 3.99 Prefixes being announced from the LACNIC address blocks: 19481 Unique aggregates announced from the LACNIC address blocks: 10795 LACNIC Region origin ASes present in the Internet Routing Table: 986 LACNIC Prefixes per ASN: 19.76 LACNIC Region origin ASes announcing only one prefix: 324 LACNIC Region transit ASes present in the Internet Routing Table: 167 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 54844416 Equivalent to 3 /8s, 68 /16s and 220 /24s Percentage of available LACNIC address space announced: 54.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: 4039 Total AfriNIC prefixes after maximum aggregation: 1253 AfriNIC Deaggregation factor: 3.22 Prefixes being announced from the AfriNIC address blocks: 4386 Unique aggregates announced from the AfriNIC address blocks: 1910 AfriNIC Region origin ASes present in the Internet Routing Table: 252 AfriNIC Prefixes per ASN: 17.40 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12647424 Equivalent to 0 /8s, 192 /16s and 252 /24s Percentage of available AfriNIC address space announced: 37.7 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 1712 538 180 Videsh Sanchar Nigam Ltd. Aut 17488 1370 89 104 Hathway IP Over Cable Interne 9583 1109 89 492 Sify Limited 4766 871 6407 357 Korea Telecom (KIX) 4134 838 13619 341 CHINANET-BACKBONE 23577 820 35 695 Korea Telecom (ATM-MPLS) 4780 712 353 61 Digital United Inc. 18101 694 167 31 Reliance Infocom Ltd Internet 9498 674 291 53 BHARTI BT INTERNET LTD. 4808 623 1108 136 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 6389 4307 3416 344 bellsouth.net, inc. 209 2883 3873 617 Qwest 6298 2013 323 717 Cox Communicatons 1785 1649 710 156 AppliedTheory Corporation 2386 1559 691 900 AT&T Data Communications Serv 4323 1500 1073 374 Time Warner Telecom 20115 1478 1194 670 Charter Communications 7018 1409 5785 978 AT&T WorldNet Services 11492 1211 151 22 Cable One 6478 1134 239 187 AT&T Worldnet Services 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 414 1776 372 TDC Tele Danmark 3215 396 2756 106 France Telecom Transpac 8452 358 188 11 TEDATA 3301 334 1444 305 TeliaNet Sweden 3320 323 7047 271 Deutsche Telekom AG 8866 317 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 288 270 38 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 8708 267 422 252 Romania Data Systems S.A. 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 1589 2606 230 UniNet S.A. de C.V. 11830 664 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 477 235 67 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 421 85 48 ENTEL CHILE S.A. 10620 411 102 71 TVCABLE BOGOTA 11172 409 118 73 Servicios Alestra S.A de C.V 14117 345 23 9 Telefonica del Sur S.A. 28573 338 440 29 NET Servicos de Comunicao S.A 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 508 65 36 LINKdotNET AS number 20858 402 34 3 EgyNet 3741 266 855 223 The Internet Solution 2018 229 214 135 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 136 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 33776 119 6 3 Starcomms Nigeria Limited 5713 118 539 70 Telkom SA Ltd 29571 107 13 8 Ci Telecom Autonomous system 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 4307 3416 344 bellsouth.net, inc. 209 2883 3873 617 Qwest 6298 2013 323 717 Cox Communicatons 4755 1712 538 180 Videsh Sanchar Nigam Ltd. Aut 1785 1649 710 156 AppliedTheory Corporation 8151 1589 2606 230 UniNet S.A. de C.V. 2386 1559 691 900 AT&T Data Communications Serv 4323 1500 1073 374 Time Warner Telecom 20115 1478 1194 670 Charter Communications 7018 1409 5785 978 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2883 2266 Qwest 4755 1712 1532 Videsh Sanchar Nigam Ltd. Aut 1785 1649 1493 AppliedTheory Corporation 8151 1589 1359 UniNet S.A. de C.V. 6298 2013 1296 Cox Communicatons 17488 1370 1266 Hathway IP Over Cable Interne 11492 1211 1189 Cable One 4323 1500 1126 Time Warner Telecom 18566 1045 1035 Covad Communications 6478 1134 947 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.160.0/19 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 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 63.143.251.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:17 /11:45 /12:146 /13:292 /14:527 /15:1062 /16:10057 /17:4376 /18:7622 /19:16077 /20:18755 /21:18407 /22:23185 /23:24242 /24:139894 /25:834 /26:1022 /27:722 /28:77 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2861 4307 bellsouth.net, inc. 6298 1986 2013 Cox Communicatons 209 1652 2883 Qwest 2386 1237 1559 AT&T Data Communications Serv 11492 1192 1211 Cable One 17488 1178 1370 Hathway IP Over Cable Interne 1785 1118 1649 AppliedTheory Corporation 4755 1049 1712 Videsh Sanchar Nigam Ltd. Aut 6478 1027 1134 AT&T Worldnet Services 18566 1026 1045 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:136 12:2135 13:2 15:22 16:3 17:5 18:13 20:35 24:1082 32:59 38:488 40:92 41:714 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:526 59:510 60:452 61:965 62:1209 63:2047 64:3231 65:2367 66:3453 67:1227 68:782 69:2289 70:868 71:132 72:2024 73:6 74:1127 75:170 76:314 77:769 78:801 79:243 80:977 81:871 82:583 83:374 84:574 85:982 86:401 87:717 88:339 89:1321 90:37 91:1428 92:251 93:808 94:111 96:62 97:65 98:317 99:6 114:92 115:41 116:1000 117:342 118:195 119:480 120:83 121:587 122:821 123:398 124:835 125:1194 128:356 129:202 130:134 131:413 132:70 133:9 134:188 135:34 136:223 137:97 138:141 139:94 140:507 141:103 142:407 143:312 144:411 145:51 146:372 147:157 148:513 149:202 150:127 151:180 152:145 153:136 154:10 155:278 156:174 157:299 158:163 159:299 160:274 161:136 162:256 163:158 164:515 165:490 166:365 167:332 168:628 169:142 170:429 171:33 172:10 173:33 188:1 189:549 190:2114 192:5799 193:4145 194:3251 195:2576 196:1025 198:3734 199:3313 200:5555 201:1527 202:7630 203:8095 204:3946 205:2157 206:2371 207:2758 208:3526 209:3431 210:2600 211:1088 212:1436 213:1613 214:178 215:50 216:4385 217:1207 218:346 219:429 220:1063 221:427 222:313 End of report From karnaugh at karnaugh.za.net Fri Aug 29 13:44:41 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 29 Aug 2008 20:44:41 +0200 Subject: HurricaneElectric In-Reply-To: References: <48B7C2BA.3060106@karnaugh.za.net> Message-ID: <48B84399.5050902@karnaugh.za.net> On 2008/08/29 07:45 PM Christian Koch wrote: > you might want to check the obvious first :) > > http://www.tunnelbroker.net/forums/ > ipv6 at he.net Yes, problem was my prefix was routed wrong.. so trying to get to the site was tedious and would have required turning off IPv6 only to turn it on later and whatever so .. yeah :P Anyway, it's sorted now. Thanks HE guys :) At least I know the support address now. From ge at linuxbox.org Fri Aug 29 15:02:25 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 29 Aug 2008 15:02:25 -0500 (CDT) Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? Message-ID: Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html In it, Brian Krebs discusses the SF Bay Area based Atrivo/Intercage, which has been long named as a bad actor, accused of shuffling abuse reports to different IP addresses and hosting criminals en masse, compared often to RBN in maliciousness. "The American RBN", if you like. 1. I realize this is a problematic issue, but when it is clear a network is so evil (as the story suggests they are), why are we still peering with them? Who currently provides them with transit? Are they aware of this news story? If Lycos' make spam not war, and Blue Security's blue frog were ran out of hosting continually, this has been done before to some extent. This network is not in Russia or China, but in the silicon valley. 2. On a different note, why is anyone still accepting their route announcements? I know some among us re-route RBN traffic to protect users. Do you see this as a valid solution for your networks? What ASNs belong to Atrivo, anyway? Anyone has more details as to the apparent evilness of Atrivo/Intercage, who can verify these reports? As researched as they are, and my personal experience aside, I'd like some more data before coming to conclusions. Hostexploit released a document [PDF] on this very network, just now, which is helpful: http://hostexploit.com/index.php?option=com_content&view=article&id=12&Itemid=15 Gadi. From ariev at vayner.net Fri Aug 29 15:12:57 2008 From: ariev at vayner.net (Arie Vayner) Date: Fri, 29 Aug 2008 23:12:57 +0300 Subject: Using 32 bit ASN numbers In-Reply-To: <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> References: <616705.76791.qm@web42103.mail.mud.yahoo.com> <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> Message-ID: <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> Pender, One small correction... For 7600, 12.2SR, the support would come out in 12.2SRD Arie On Fri, Aug 29, 2008 at 6:44 PM, Pender, James wrote: > > These are the dates I have for Cisco platforms: > > IOS XR 3.4 - September 2007 > IOS 12.0(32)S11 - November 2008 > IOS 12.2SRE - December 2008 > IOS 12.5(1)T - April 2009 > > -----Original Message----- > From: andy lam [mailto:anwalam at yahoo.com] > Sent: Friday, August 29, 2008 11:29 AM > To: nanog at merit.edu; Brian Raaen > Subject: Re: Using 32 bit ASN numbers > > > Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key > Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop > tracking enhancements. > > http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 > BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 > bytes to 4 bytes to scale with expected Internet growth. > > 12.2SR* is supposed to be in late 2008, but has not yet been announced > publicly. > > > Juniper it's in JUNOS 9.1 as farr as I can tell. > > > --- On Fri, 8/29/08, Brian Raaen wrote: > > From: Brian Raaen > Subject: Using 32 bit ASN numbers > To: nanog at merit.edu > Date: Friday, August 29, 2008, 11:04 AM > > I am doing some research for our company regarding 32 bit ASN numbers. I > am > trying to locate information about vendor and service provider support. In > particular I have not been able to find what Cisco IOS image I would need > to > load on our router to support 32 bit ASN's. I also want to know what > experience people have had with service provider support of 32 bit ASN's > > -- > Brian Raaen > Network Engineer > braaen at zcorum.com > > > > > > > From ops.lists at gmail.com Fri Aug 29 15:38:00 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 30 Aug 2008 02:08:00 +0530 Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? In-Reply-To: References: Message-ID: On Sat, Aug 30, 2008 at 1:32 AM, Gadi Evron wrote: > 2. On a different note, why is anyone still accepting their route > announcements? I know some among us re-route RBN traffic to protect users. > Do you see this as a valid solution for your networks? > > What ASNs belong to Atrivo, anyway? The ASNs you ask about - as per the report - are on pages 4..8 of http://hostexploit.com/downloads/Atrivo%20white%20paper%20082808ac.pdf From havenster at gmail.com Fri Aug 29 15:50:11 2008 From: havenster at gmail.com (Haven Hash) Date: Fri, 29 Aug 2008 13:50:11 -0700 Subject: Using 32 bit ASN numbers In-Reply-To: <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> References: <616705.76791.qm@web42103.mail.mud.yahoo.com> <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> Message-ID: <6bc3f4c50808291350j21762ef6h19525fae9eb364e8@mail.gmail.com> Concerning 32 bit AS numbers, are organizations which are granted 32 bit AS numbers given any multicast address space? If so is it possible to figure out what this space is from the ASN ala GLOP (233.ASN.ASN.x)? Thanks, Haven Hash On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner wrote: > Pender, > > One small correction... For 7600, 12.2SR, the support would come out in > 12.2SRD > > Arie > > On Fri, Aug 29, 2008 at 6:44 PM, Pender, James >wrote: > > > > > These are the dates I have for Cisco platforms: > > > > IOS XR 3.4 - September 2007 > > IOS 12.0(32)S11 - November 2008 > > IOS 12.2SRE - December 2008 > > IOS 12.5(1)T - April 2009 > > > > -----Original Message----- > > From: andy lam [mailto:anwalam at yahoo.com] > > Sent: Friday, August 29, 2008 11:29 AM > > To: nanog at merit.edu; Brian Raaen > > Subject: Re: Using 32 bit ASN numbers > > > > > > Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication > Key > > Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop > > tracking enhancements. > > > > > http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 > > BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 > > bytes to 4 bytes to scale with expected Internet growth. > > > > 12.2SR* is supposed to be in late 2008, but has not yet been announced > > publicly. > > > > > > Juniper it's in JUNOS 9.1 as farr as I can tell. > > > > > > --- On Fri, 8/29/08, Brian Raaen wrote: > > > > From: Brian Raaen > > Subject: Using 32 bit ASN numbers > > To: nanog at merit.edu > > Date: Friday, August 29, 2008, 11:04 AM > > > > I am doing some research for our company regarding 32 bit ASN numbers. I > > am > > trying to locate information about vendor and service provider support. > In > > particular I have not been able to find what Cisco IOS image I would need > > to > > load on our router to support 32 bit ASN's. I also want to know what > > experience people have had with service provider support of 32 bit ASN's > > > > -- > > Brian Raaen > > Network Engineer > > braaen at zcorum.com > > > > > > > > > > > > > > > From tme at multicasttech.com Fri Aug 29 15:58:31 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 29 Aug 2008 16:58:31 -0400 Subject: Using 32 bit ASN numbers In-Reply-To: <6bc3f4c50808291350j21762ef6h19525fae9eb364e8@mail.gmail.com> References: <616705.76791.qm@web42103.mail.mud.yahoo.com> <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> <6bc3f4c50808291350j21762ef6h19525fae9eb364e8@mail.gmail.com> Message-ID: On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: > Concerning 32 bit AS numbers, are organizations which are granted 32 > bit AS > numbers given any multicast address space? > > If so is it possible to figure out what this space is from the ASN > ala GLOP > (233.ASN.ASN.x)? > Yes, and yes. The space they are given is the GLOP space ! See http://www.multicasttech.com/faq/#GLOP and http://www.shepfarm.com/multicast/glop.html Regards Marshall > Thanks, > > Haven Hash > > On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner wrote: > >> Pender, >> >> One small correction... For 7600, 12.2SR, the support would come >> out in >> 12.2SRD >> >> Arie >> >> On Fri, Aug 29, 2008 at 6:44 PM, Pender, James >> wrote: >> >>> >>> These are the dates I have for Cisco platforms: >>> >>> IOS XR 3.4 - September 2007 >>> IOS 12.0(32)S11 - November 2008 >>> IOS 12.2SRE - December 2008 >>> IOS 12.5(1)T - April 2009 >>> >>> -----Original Message----- >>> From: andy lam [mailto:anwalam at yahoo.com] >>> Sent: Friday, August 29, 2008 11:29 AM >>> To: nanog at merit.edu; Brian Raaen >>> Subject: Re: Using 32 bit ASN numbers >>> >>> >>> Cisco IOS XR Software Release 3.4.0 adds support for BGP >>> Authentication >> Key >>> Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next >>> Hop >>> tracking enhancements. >>> >>> >> http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 >>> BGP 4-Byte ASN-Increases the range of supported autonomous systems >>> from 2 >>> bytes to 4 bytes to scale with expected Internet growth. >>> >>> 12.2SR* is supposed to be in late 2008, but has not yet been >>> announced >>> publicly. >>> >>> >>> Juniper it's in JUNOS 9.1 as farr as I can tell. >>> >>> >>> --- On Fri, 8/29/08, Brian Raaen wrote: >>> >>> From: Brian Raaen >>> Subject: Using 32 bit ASN numbers >>> To: nanog at merit.edu >>> Date: Friday, August 29, 2008, 11:04 AM >>> >>> I am doing some research for our company regarding 32 bit ASN >>> numbers. I >>> am >>> trying to locate information about vendor and service provider >>> support. >> In >>> particular I have not been able to find what Cisco IOS image I >>> would need >>> to >>> load on our router to support 32 bit ASN's. I also want to know >>> what >>> experience people have had with service provider support of 32 bit >>> ASN's >>> >>> -- >>> Brian Raaen >>> Network Engineer >>> braaen at zcorum.com >>> >>> >>> >>> >>> >>> >>> >> From tme at multicasttech.com Fri Aug 29 16:06:26 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 29 Aug 2008 17:06:26 -0400 Subject: Using 32 bit ASN numbers In-Reply-To: References: <616705.76791.qm@web42103.mail.mud.yahoo.com> <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> <6bc3f4c50808291350j21762ef6h19525fae9eb364e8@mail.gmail.com> Message-ID: On Aug 29, 2008, at 4:58 PM, Marshall Eubanks wrote: > > > On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: > >> Concerning 32 bit AS numbers, are organizations which are granted >> 32 bit AS >> numbers given any multicast address space? >> Oh, and there is a plan in the works to accommodate those with 32 bit ASN. Regards Marshall >> If so is it possible to figure out what this space is from the ASN >> ala GLOP >> (233.ASN.ASN.x)? >> > > Yes, and yes. > > The space they are given is the GLOP space ! > > See > > http://www.multicasttech.com/faq/#GLOP > > and > > http://www.shepfarm.com/multicast/glop.html > > Regards > Marshall > >> Thanks, >> >> Haven Hash >> >> On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner >> wrote: >> >>> Pender, >>> >>> One small correction... For 7600, 12.2SR, the support would come >>> out in >>> 12.2SRD >>> >>> Arie >>> >>> On Fri, Aug 29, 2008 at 6:44 PM, Pender, James >>> wrote: >>> >>>> >>>> These are the dates I have for Cisco platforms: >>>> >>>> IOS XR 3.4 - September 2007 >>>> IOS 12.0(32)S11 - November 2008 >>>> IOS 12.2SRE - December 2008 >>>> IOS 12.5(1)T - April 2009 >>>> >>>> -----Original Message----- >>>> From: andy lam [mailto:anwalam at yahoo.com] >>>> Sent: Friday, August 29, 2008 11:29 AM >>>> To: nanog at merit.edu; Brian Raaen >>>> Subject: Re: Using 32 bit ASN numbers >>>> >>>> >>>> Cisco IOS XR Software Release 3.4.0 adds support for BGP >>>> Authentication >>> Key >>>> Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next >>>> Hop >>>> tracking enhancements. >>>> >>>> >>> http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 >>>> BGP 4-Byte ASN-Increases the range of supported autonomous >>>> systems from 2 >>>> bytes to 4 bytes to scale with expected Internet growth. >>>> >>>> 12.2SR* is supposed to be in late 2008, but has not yet been >>>> announced >>>> publicly. >>>> >>>> >>>> Juniper it's in JUNOS 9.1 as farr as I can tell. >>>> >>>> >>>> --- On Fri, 8/29/08, Brian Raaen wrote: >>>> >>>> From: Brian Raaen >>>> Subject: Using 32 bit ASN numbers >>>> To: nanog at merit.edu >>>> Date: Friday, August 29, 2008, 11:04 AM >>>> >>>> I am doing some research for our company regarding 32 bit ASN >>>> numbers. I >>>> am >>>> trying to locate information about vendor and service provider >>>> support. >>> In >>>> particular I have not been able to find what Cisco IOS image I >>>> would need >>>> to >>>> load on our router to support 32 bit ASN's. I also want to know >>>> what >>>> experience people have had with service provider support of 32 >>>> bit ASN's >>>> >>>> -- >>>> Brian Raaen >>>> Network Engineer >>>> braaen at zcorum.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> > > From surfer at mauigateway.com Fri Aug 29 16:29:21 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Aug 2008 14:29:21 -0700 Subject: BGP Attack - Best Defense ? Message-ID: <20080829142921.AE91480@resin13.mta.everyone.net> My question revolves around the best recovery from an attack of the type we've been discussing. I only figured out the attack methodology yesterday evening Hawaiian Standard Time. Be gentle please... :-) I am signed up for the Prefix Hijack Alert System (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or less?) about a prefix announcement change. I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker. The topologically closer ASs would then start sending the traffic to me properly. Those topologically closest to the attacker would still send to the attack path. I would then try to contact the ASs still using the attack path to get it stopped. (Yell help on NANOG? ;-) Is this the best recovery plan at this time? scott From fw at deneb.enyo.de Fri Aug 29 16:58:32 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 29 Aug 2008 23:58:32 +0200 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: (Alex Pilosov's message of "Thu, 28 Aug 2008 16:25:41 -0400 (EDT)") References: Message-ID: <87zlmvbi0n.fsf@mid.deneb.enyo.de> * Alex Pilosov: > We've demonstrated ability to monitor traffic to arbitrary > prefixes. Slides for presentation can be found here: > http://eng.5ninesdata.com/~tkapela/iphd-2.ppt The interesting question is whether it's acceptable to use this trick for non-malicious day-to-day traffic engineering. From surfer at mauigateway.com Fri Aug 29 16:56:55 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Aug 2008 14:56:55 -0700 Subject: BGP Attack - Best Defense ? Message-ID: <20080829145655.AE9181F@resin13.mta.everyone.net> Please allow me to change this: "I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker." to this: "Announce the same more specific as the attacker." scott --- surfer at mauigateway.com wrote: From: "Scott Weeks" To: Subject: BGP Attack - Best Defense ? Date: Fri, 29 Aug 2008 14:29:21 -0700 My question revolves around the best recovery from an attack of the type we've been discussing. I only figured out the attack methodology yesterday evening Hawaiian Standard Time. Be gentle please... :-) I am signed up for the Prefix Hijack Alert System (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or less?) about a prefix announcement change. I then would deaggregate (as little as possible) to be able to announce the same more specific as the attacker. The topologically closer ASs would then start sending the traffic to me properly. Those topologically closest to the attacker would still send to the attack path. I would then try to contact the ASs still using the attack path to get it stopped. (Yell help on NANOG? ;-) Is this the best recovery plan at this time? scott From owen at delong.com Fri Aug 29 17:08:39 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Aug 2008 15:08:39 -0700 Subject: Using 32 bit ASN numbers In-Reply-To: References: <616705.76791.qm@web42103.mail.mud.yahoo.com> <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> <6bc3f4c50808291350j21762ef6h19525fae9eb364e8@mail.gmail.com> Message-ID: Marshal, Since his question was specifically about I don't see the answer in either of the places you referenced.... The calculator didn't like a 32 bit ASN: AS Number Out of Range AS numbers are represented by 16 bits; 65535 maximum in decimal. Back to the GLOP Calculator Return to Shepfarm Multicast shep at shepfarm.com Owen On Aug 29, 2008, at 1:58 PM, Marshall Eubanks wrote: > > > On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: > >> Concerning 32 bit AS numbers, are organizations which are granted >> 32 bit AS >> numbers given any multicast address space? >> >> If so is it possible to figure out what this space is from the ASN >> ala GLOP >> (233.ASN.ASN.x)? >> > > Yes, and yes. > > The space they are given is the GLOP space ! > > See > > http://www.multicasttech.com/faq/#GLOP > > and > > http://www.shepfarm.com/multicast/glop.html > > Regards > Marshall > >> Thanks, >> >> Haven Hash >> >> On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner >> wrote: >> >>> Pender, >>> >>> One small correction... For 7600, 12.2SR, the support would come >>> out in >>> 12.2SRD >>> >>> Arie >>> >>> On Fri, Aug 29, 2008 at 6:44 PM, Pender, James >>> wrote: >>> >>>> >>>> These are the dates I have for Cisco platforms: >>>> >>>> IOS XR 3.4 - September 2007 >>>> IOS 12.0(32)S11 - November 2008 >>>> IOS 12.2SRE - December 2008 >>>> IOS 12.5(1)T - April 2009 >>>> >>>> -----Original Message----- >>>> From: andy lam [mailto:anwalam at yahoo.com] >>>> Sent: Friday, August 29, 2008 11:29 AM >>>> To: nanog at merit.edu; Brian Raaen >>>> Subject: Re: Using 32 bit ASN numbers >>>> >>>> >>>> Cisco IOS XR Software Release 3.4.0 adds support for BGP >>>> Authentication >>> Key >>>> Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next >>>> Hop >>>> tracking enhancements. >>>> >>>> >>> http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 >>>> BGP 4-Byte ASN-Increases the range of supported autonomous >>>> systems from 2 >>>> bytes to 4 bytes to scale with expected Internet growth. >>>> >>>> 12.2SR* is supposed to be in late 2008, but has not yet been >>>> announced >>>> publicly. >>>> >>>> >>>> Juniper it's in JUNOS 9.1 as farr as I can tell. >>>> >>>> >>>> --- On Fri, 8/29/08, Brian Raaen wrote: >>>> >>>> From: Brian Raaen >>>> Subject: Using 32 bit ASN numbers >>>> To: nanog at merit.edu >>>> Date: Friday, August 29, 2008, 11:04 AM >>>> >>>> I am doing some research for our company regarding 32 bit ASN >>>> numbers. I >>>> am >>>> trying to locate information about vendor and service provider >>>> support. >>> In >>>> particular I have not been able to find what Cisco IOS image I >>>> would need >>>> to >>>> load on our router to support 32 bit ASN's. I also want to know >>>> what >>>> experience people have had with service provider support of 32 >>>> bit ASN's >>>> >>>> -- >>>> Brian Raaen >>>> Network Engineer >>>> braaen at zcorum.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> > From jfesler at gigo.com Fri Aug 29 17:17:28 2008 From: jfesler at gigo.com (Jason Fesler) Date: Fri, 29 Aug 2008 15:17:28 -0700 (PDT) Subject: BGP Attack - Best Defense ? In-Reply-To: <20080829142921.AE91480@resin13.mta.everyone.net> References: <20080829142921.AE91480@resin13.mta.everyone.net> Message-ID: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. Would the alerts go to a mail server behind said BGP prefixes? Also, if you're gonna bother at all.. I'd humbly suggest that 6 hours is too long to wait. Without naming names, consider if this response time is adequate, and if not, look at some of the commercial options. From surfer at mauigateway.com Fri Aug 29 17:50:45 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Aug 2008 15:50:45 -0700 Subject: BGP Attack - Best Defense ? Message-ID: <20080829155045.AE9625D@resin13.mta.everyone.net> ------- jfesler at gigo.com wrote: ------- From: Jason Fesler > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. Would the alerts go to a mail server behind said BGP prefixes? --------------------------------------- They would go to me. They have been coming to me since I heard about this service on NANOG. Thanks folks at Colorado State University! :-) -------------------------------------- Also, if you're gonna bother at all.. I'd humbly suggest that 6 hours is too long to wait. Without naming names, consider if this response time is adequate, and if not, look at some of the commercial options. -------------------------------------- I'm currently on an eyeball network and no one is physically close to me, since I'm in Hawaii (the most isolated land mass in the world). Even though the TTL changes in this attack, the physics don't. The gamers would probably be the first alert folks as they would see the delay regardless of what their traceroutes say... ;-) In this attack the traffic makes it to both end-points. The middle is what changes. Restating my question differently: If the attacker is announcing a /24 of mine, I figure it out some how and I start announcing the same. What happens if the attacker doesn't stop? From scg at gibbard.org Fri Aug 29 17:50:49 2008 From: scg at gibbard.org (Steve Gibbard) Date: Fri, 29 Aug 2008 15:50:49 -0700 (PDT) Subject: BGP Attack - Best Defense ? In-Reply-To: <20080829142921.AE91480@resin13.mta.everyone.net> References: <20080829142921.AE91480@resin13.mta.everyone.net> Message-ID: <20080829153012.E93047@sprockets.gibbard.org> On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve From jlewis at lewis.org Fri Aug 29 17:57:37 2008 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 29 Aug 2008 18:57:37 -0400 (EDT) Subject: BGP Attack - Best Defense ? In-Reply-To: <20080829155045.AE9625D@resin13.mta.everyone.net> References: <20080829155045.AE9625D@resin13.mta.everyone.net> Message-ID: On Fri, 29 Aug 2008, Scott Weeks wrote: > Restating my question differently: If the attacker is announcing a /24 > of mine, I figure it out some how and I start announcing the same. > What happens if the attacker doesn't stop? You may as well announce both the same /24 and /25s if you can...though those probably won't make it far. If they hijack something less specific than a /24, go one bit more specific than the rogue announcement. After that, try contacting the rogue ASN's upstreams. After that? See if you can find a backhoe for hire? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Guy_Shields at Stream.Com Fri Aug 29 17:58:47 2008 From: Guy_Shields at Stream.Com (Guy_Shields at Stream.Com) Date: Fri, 29 Aug 2008 17:58:47 -0500 Subject: BGP Attack - Best Defense ? Message-ID: You need to contact 1st their directly connected provider, 2nd contact your upstream provider and ask that they contact their peers and negate the announcement. 3rd if this is an ARIN provided block contact them as you do pay for your allocation and they will have the contacts to resolve the issue. You cannot normally announce smaller than a /24 ----- Original Message ----- From: "Scott Weeks" [surfer at mauigateway.com] Sent: 08/29/2008 03:50 PM MST To: Subject: Re: BGP Attack - Best Defense ? ------- jfesler at gigo.com wrote: ------- From: Jason Fesler > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. Would the alerts go to a mail server behind said BGP prefixes? --------------------------------------- They would go to me. They have been coming to me since I heard about this service on NANOG. Thanks folks at Colorado State University! :-) -------------------------------------- Also, if you're gonna bother at all.. I'd humbly suggest that 6 hours is too long to wait. Without naming names, consider if this response time is adequate, and if not, look at some of the commercial options. -------------------------------------- I'm currently on an eyeball network and no one is physically close to me, since I'm in Hawaii (the most isolated land mass in the world). Even though the TTL changes in this attack, the physics don't. The gamers would probably be the first alert folks as they would see the delay regardless of what their traceroutes say... ;-) In this attack the traffic makes it to both end-points. The middle is what changes. Restating my question differently: If the attacker is announcing a /24 of mine, I figure it out some how and I start announcing the same. What happens if the attacker doesn't stop? This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From surfer at mauigateway.com Fri Aug 29 18:06:55 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Aug 2008 16:06:55 -0700 Subject: BGP Attack - Best Defense ? Message-ID: <20080829160655.AE961DF@resin13.mta.everyone.net> ----------- scg at gibbard.org wrote: -------------- From: Steve Gibbard On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. ---------------------------------------------------- Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? ------------------------------------------------------ Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? ------------------------------------------------------ I have them do orlonger when I set up the BGP sessions, so I'm good to go. I have a /15 and two /16s fully aggregated, so I can announce anything smaller than that for TE. The worst I have done so far is use /17s to groom ingress traffic, but that was temporary. I now have enough BW to run BGP without turning any knobs ------------------------------------------------------ Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. ------------------------------------------------------ I won't. Learning from many here about netizenship I make sure I am a good boy. ;-) scott ------------------------------------------------------------ > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve -------------------------------------------------------------- From marc at sans.org Fri Aug 29 18:11:36 2008 From: marc at sans.org (Marc Sachs) Date: Fri, 29 Aug 2008 19:11:36 -0400 Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? In-Reply-To: References: Message-ID: <060201c90a2c$9620a390$c261eab0$@org> Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said good-bye to Atrivo/Intercage), it looks like they are no longer their upstream: http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 Marc SANS ISC -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Friday, August 29, 2008 4:02 PM To: nanog at merit.edu Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as _major.html In it, Brian Krebs discusses the SF Bay Area based Atrivo/Intercage, which has been long named as a bad actor, accused of shuffling abuse reports to different IP addresses and hosting criminals en masse, compared often to RBN in maliciousness. "The American RBN", if you like. 1. I realize this is a problematic issue, but when it is clear a network is so evil (as the story suggests they are), why are we still peering with them? Who currently provides them with transit? Are they aware of this news story? If Lycos' make spam not war, and Blue Security's blue frog were ran out of hosting continually, this has been done before to some extent. This network is not in Russia or China, but in the silicon valley. 2. On a different note, why is anyone still accepting their route announcements? I know some among us re-route RBN traffic to protect users. Do you see this as a valid solution for your networks? What ASNs belong to Atrivo, anyway? Anyone has more details as to the apparent evilness of Atrivo/Intercage, who can verify these reports? As researched as they are, and my personal experience aside, I'd like some more data before coming to conclusions. Hostexploit released a document [PDF] on this very network, just now, which is helpful: http://hostexploit.com/index.php?option=com_content&view=article&id=12&Itemi d=15 Gadi. From Guy_Shields at Stream.Com Fri Aug 29 18:11:23 2008 From: Guy_Shields at Stream.Com (Guy_Shields at Stream.Com) Date: Fri, 29 Aug 2008 18:11:23 -0500 Subject: BGP Attack - Best Defense ? Message-ID: Correct, as you would then be contending with the path length portion of the 10 determistic citeria in the bgp protocol. ----- Original Message ----- From: "Scott Weeks" [surfer at mauigateway.com] Sent: 08/29/2008 04:06 PM MST To: Subject: Re: BGP Attack - Best Defense ? ----------- scg at gibbard.org wrote: -------------- From: Steve Gibbard On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. ---------------------------------------------------- Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? ------------------------------------------------------ Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? ------------------------------------------------------ I have them do orlonger when I set up the BGP sessions, so I'm good to go. I have a /15 and two /16s fully aggregated, so I can announce anything smaller than that for TE. The worst I have done so far is use /17s to groom ingress traffic, but that was temporary. I now have enough BW to run BGP without turning any knobs ------------------------------------------------------ Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. ------------------------------------------------------ I won't. Learning from many here about netizenship I make sure I am a good boy. ;-) scott ------------------------------------------------------------ > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve -------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From ge at linuxbox.org Fri Aug 29 18:14:48 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 29 Aug 2008 18:14:48 -0500 (CDT) Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? In-Reply-To: <060201c90a2c$9620a390$c261eab0$@org> References: <060201c90a2c$9620a390$c261eab0$@org> Message-ID: On Fri, 29 Aug 2008, Marc Sachs wrote: > Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said > good-bye to Atrivo/Intercage), it looks like they are no longer their > upstream: > > http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 Current peers: http://cidr-report.org/cgi-bin/as-report?as=AS19151 (just purchased by Host.net) http://cidr-report.org/cgi-bin/as-report?as=AS26769 > Marc > SANS ISC > > > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Friday, August 29, 2008 4:02 PM > To: nanog at merit.edu > Subject: Washington Post: Atrivo/Intercage, why are we peering with the > American RBN? > > Hi all. > > This Washington Post story came out today: > http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as > _major.html > > In it, Brian Krebs discusses the SF Bay Area based Atrivo/Intercage, which > has been long named as a bad actor, accused of shuffling abuse reports to > different IP addresses and hosting criminals en masse, compared often to > RBN in maliciousness. "The American RBN", if you like. > > 1. I realize this is a problematic issue, but when it is clear a network > is so evil (as the story suggests they are), why are we still peering with > them? Who currently provides them with transit? Are they aware of this > news story? > > If Lycos' make spam not war, and Blue Security's blue frog were ran out of > hosting continually, this has been done before to some extent. This > network is not in Russia or China, but in the silicon valley. > > 2. On a different note, why is anyone still accepting their route > announcements? I know some among us re-route RBN traffic to protect users. > Do you see this as a valid solution for your networks? > > What ASNs belong to Atrivo, anyway? > > Anyone has more details as to the apparent evilness of Atrivo/Intercage, > who can verify these reports? As researched as they are, and my personal > experience aside, I'd like some more data before coming to conclusions. > > Hostexploit released a document [PDF] on this very network, just now, > which is helpful: > http://hostexploit.com/index.php?option=com_content&view=article&id=12&Itemi > d=15 > > Gadi. > From surfer at mauigateway.com Fri Aug 29 18:15:43 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Aug 2008 16:15:43 -0700 Subject: BGP Attack - Best Defense ? Message-ID: <20080829161543.AE96062@resin13.mta.everyone.net> ------ Guy_Shields at Stream.Com wrote: --------- You need to contact 1st their directly connected provider, 2nd contact your upstream provider and ask that they contact their peers and negate the announcement. 3rd if this is an ARIN provided block contact them as you do pay for your allocation and they will have the contacts to resolve the issue. You cannot normally announce smaller than a /24 ----------------------------------------------- As someone told me in a private email: ## I would then try to contact the ASs still using the attack ## path to get it stopped. (Yell help on NANOG? ;-) :: What if the relevant ASNs are in a remote part of the world :: that doesn't participate in NANOG, or speak english, or even :: have a 24x7 NOC Which is why I said "Yell help on NANOG? ;-)". Since there're more ASN operators here than on any other *NOG I'm aware of I would have my best hope after exhausting all other avenues of resolution. scott From Guy_Shields at Stream.Com Fri Aug 29 18:15:03 2008 From: Guy_Shields at Stream.Com (Guy_Shields at Stream.Com) Date: Fri, 29 Aug 2008 18:15:03 -0500 Subject: BGP Attack - Best Defense ? Message-ID: Goto www.traceroute.org for a very comprehensive looking glass and routeview servers list. You can then determine how succesful your attempts to quell an attack are. ----- Original Message ----- From: "Scott Weeks" [surfer at mauigateway.com] Sent: 08/29/2008 04:06 PM MST To: Subject: Re: BGP Attack - Best Defense ? ----------- scg at gibbard.org wrote: -------------- From: Steve Gibbard On Fri, 29 Aug 2008, Scott Weeks wrote: > I am signed up for the Prefix Hijack Alert System > (phas.netsec.colostate.edu) and would be alerted in about 6 hours (or > less?) about a prefix announcement change. > > I then would deaggregate (as little as possible) to be able to announce > the same more specific as the attacker. Announcing the same prefix length as the attacker would get you back some portion of your traffic, rather than all of it. You'd really want to announce something more specific than what the attacker is announcing. ---------------------------------------------------- Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? ------------------------------------------------------ Of course, then you'd need to get your upstreams to accept the more specific, which might mean modifying filters. How quickly can you get your upstreams to do that? ------------------------------------------------------ I have them do orlonger when I set up the BGP sessions, so I'm good to go. I have a /15 and two /16s fully aggregated, so I can announce anything smaller than that for TE. The worst I have done so far is use /17s to groom ingress traffic, but that was temporary. I now have enough BW to run BGP without turning any knobs ------------------------------------------------------ Also, please don't be like Covad. If you deaggregate to deal with a highjacking, make your deaggregation temporary, and clean it up when it's not needed anymore. ------------------------------------------------------ I won't. Learning from many here about netizenship I make sure I am a good boy. ;-) scott ------------------------------------------------------------ > I would then try to contact the ASs still using the attack path to get > it stopped. (Yell help on NANOG? ;-) If you try to contact networks that are innocently hearing the announcement, rather than those involved in propagating it, you'll have a lot of networks to contact. A better move would be to contact those originating the announcement (unless you think they're involved in something malicious), and then their upstreams, and if that doesn't work, their upstreams' upstreams. Calling an upstream provider's NOC to ask them to modify a customer's filters generally gets met with lots of skepticism. You'll almost certainly be told that you have to be the customer whose filter it is to ask to have it modified. You'll need to be quite firm, and will probably need to ask to speak to somebody higher up than the front-line tech who answers the phone. The very few times I've had to do this, I've also found it quite useful to deemphasize their receiving of the prefix from a customer, and emphasize that they were announcing it to the rest of the world. "You are announcing our prefix, and you are not authorized to do so," is a useful line. -Steve -------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From tme at multicasttech.com Fri Aug 29 18:21:11 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 29 Aug 2008 19:21:11 -0400 Subject: Using 32 bit ASN numbers In-Reply-To: References: <616705.76791.qm@web42103.mail.mud.yahoo.com> <4C4E171C33ADBF43BFFE42978E1708C90F3F098B@mail1-corp.corp.paetec.com> <20b13c6b0808291312r2d967be2n9946e2a12e35a5d0@mail.gmail.com> <6bc3f4c50808291350j21762ef6h19525fae9eb364e8@mail.gmail.com> Message-ID: On Aug 29, 2008, at 6:08 PM, Owen DeLong wrote: > Marshal, > > Since his question was specifically about I don't see the answer > in either of the places you referenced.... Sorry, I was too eager to respond. The assignees of the 32 bit ASN will have to ask for space from IANA from the former "eGLOP" space, now the Extended AD-HOC space. There will be no automatic pre-assignment of space, see http://www.ietf.org/internet-drafts/draft-ietf-mboned-rfc3171bis-03.txt for details. This has not become an RFC yet, and if people have comments, we welcome them on the MBONED list. Regards Marshall > The calculator didn't > like a 32 bit ASN: > > AS Number Out of Range > AS numbers are represented by 16 bits; 65535 maximum in decimal. > > > No, likely not. Marshall > Back to the GLOP Calculator > Return to Shepfarm Multicast > > shep at shepfarm.com > > > > Owen > > > On Aug 29, 2008, at 1:58 PM, Marshall Eubanks wrote: > >> >> >> On Aug 29, 2008, at 4:50 PM, Haven Hash wrote: >> >>> Concerning 32 bit AS numbers, are organizations which are granted >>> 32 bit AS >>> numbers given any multicast address space? >>> >>> If so is it possible to figure out what this space is from the ASN >>> ala GLOP >>> (233.ASN.ASN.x)? >>> >> >> Yes, and yes. >> >> The space they are given is the GLOP space ! >> >> See >> >> http://www.multicasttech.com/faq/#GLOP >> >> and >> >> http://www.shepfarm.com/multicast/glop.html >> >> Regards >> Marshall >> >>> Thanks, >>> >>> Haven Hash >>> >>> On Fri, Aug 29, 2008 at 1:12 PM, Arie Vayner >>> wrote: >>> >>>> Pender, >>>> >>>> One small correction... For 7600, 12.2SR, the support would come >>>> out in >>>> 12.2SRD >>>> >>>> Arie >>>> >>>> On Fri, Aug 29, 2008 at 6:44 PM, Pender, James >>>> wrote: >>>> >>>>> >>>>> These are the dates I have for Cisco platforms: >>>>> >>>>> IOS XR 3.4 - September 2007 >>>>> IOS 12.0(32)S11 - November 2008 >>>>> IOS 12.2SRE - December 2008 >>>>> IOS 12.5(1)T - April 2009 >>>>> >>>>> -----Original Message----- >>>>> From: andy lam [mailto:anwalam at yahoo.com] >>>>> Sent: Friday, August 29, 2008 11:29 AM >>>>> To: nanog at merit.edu; Brian Raaen >>>>> Subject: Re: Using 32 bit ASN numbers >>>>> >>>>> >>>>> Cisco IOS XR Software Release 3.4.0 adds support for BGP >>>>> Authentication >>>> Key >>>>> Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP >>>>> Next Hop >>>>> tracking enhancements. >>>>> >>>>> >>>> http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 >>>>> BGP 4-Byte ASN-Increases the range of supported autonomous >>>>> systems from 2 >>>>> bytes to 4 bytes to scale with expected Internet growth. >>>>> >>>>> 12.2SR* is supposed to be in late 2008, but has not yet been >>>>> announced >>>>> publicly. >>>>> >>>>> >>>>> Juniper it's in JUNOS 9.1 as farr as I can tell. >>>>> >>>>> >>>>> --- On Fri, 8/29/08, Brian Raaen wrote: >>>>> >>>>> From: Brian Raaen >>>>> Subject: Using 32 bit ASN numbers >>>>> To: nanog at merit.edu >>>>> Date: Friday, August 29, 2008, 11:04 AM >>>>> >>>>> I am doing some research for our company regarding 32 bit ASN >>>>> numbers. I >>>>> am >>>>> trying to locate information about vendor and service provider >>>>> support. >>>> In >>>>> particular I have not been able to find what Cisco IOS image I >>>>> would need >>>>> to >>>>> load on our router to support 32 bit ASN's. I also want to know >>>>> what >>>>> experience people have had with service provider support of 32 >>>>> bit ASN's >>>>> >>>>> -- >>>>> Brian Raaen >>>>> Network Engineer >>>>> braaen at zcorum.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> > From surfer at mauigateway.com Fri Aug 29 18:29:09 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 29 Aug 2008 16:29:09 -0700 Subject: BGP Attack - Best Defense ? Message-ID: <20080829162909.AE96795@resin13.mta.everyone.net> ----- Original Message ----- Let's say the attacker is announcing one or more /24s of mine and announcing a more specific is not possible. I figure it out somehow and begin announcing the same. The attacker doesn't stop his attack. What happens? The part of the internet closest in topology to me sends their traffic to me and the part of the internet closest to the attacker sends traffic to him? ----------------------------------- --- Guy_Shields at Stream.Com wrote:------- Correct, as you would then be contending with the path length portion of the 10 determistic citeria in the bgp protocol. --------------------------------------- And the only one that'd really come into play would be shortest number of AS hops, so topological closeness would be the deciding factor on whether the traffic transits the attacker's network or properly comes directly to me. scott From yahoo at jimpop.com Fri Aug 29 18:53:45 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Fri, 29 Aug 2008 19:53:45 -0400 Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? In-Reply-To: References: <060201c90a2c$9620a390$c261eab0$@org> Message-ID: <7ff145960808291653m3219ce4cvf7efbf15885e6251@mail.gmail.com> On Fri, Aug 29, 2008 at 19:14, Gadi Evron wrote: > On Fri, 29 Aug 2008, Marc Sachs wrote: >> >> Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said >> good-bye to Atrivo/Intercage), it looks like they are no longer their >> upstream: >> >> http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > > Current peers: > http://cidr-report.org/cgi-bin/as-report?as=AS19151 (just purchased by Host.net) > http://cidr-report.org/cgi-bin/as-report?as=AS26769 This popped up on my radar only because of AS19151 and the BGP Attack thread mentioning PHAS. Just last night I got phaser@ notifications about 19151 popping in and out of 22653 (a network I reside deep inside of) for about a 12 hour span. Hmmmm, -Jim P. From fergdawg at netzero.net Fri Aug 29 19:43:38 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sat, 30 Aug 2008 00:43:38 GMT Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercage, w hy are we peering with the American RBN?] Message-ID: <20080829.174338.26085.0@webmail08.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Marc Sachs" wrote: >Unless I'm mis-reading this (or perhaps GBLX read Kreb's story and said >good-bye to Atrivo/Intercage), it looks like they are no longer their >upstream: > >http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > I applaud GLBX's move to disconnect Atrivo/Intercage. What the Armin/McQuaid/Jonkman report [1] documented are activities that many of us in the security community have known for a couple of years. One thing that Krebs _didn't_ mention in his WaPo article are the large number of rogue DNS servers that also reside there. A couple of colleagues, Feike Hacquebord, Chenguai Lu, et al., presented a paper at the Virus Bulletin conference last year [2]. While the paper is almost a year old, that particular situation has gotten progressively worse. My only concern here is that by the publicity this issue continues to receive, these activities will just move else where, like scurrying cockroaches (like what happened with AS40989). One step at a time, I suppose. - - ferg [1] http://www.hostexploit.com/ [2] http://www.virusbtn.com/pdf/conference_slides/2007/HacquebordVB2007.pdf -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIuJelq1pz9mNUZTMRArvXAJ9PHNQygl5Mnrozgu140di34FvuigCcCzFa UWI10pR0jTyDUapX/J3Opa4= =YU/M -----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 deleskie at gmail.com Fri Aug 29 19:47:55 2008 From: deleskie at gmail.com (jim deleskie) Date: Fri, 29 Aug 2008 21:47:55 -0300 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <87zlmvbi0n.fsf@mid.deneb.enyo.de> References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> Message-ID: Announcing a smaller bit of one of you block is fine, more then that most everyone I know does it or has done and is commonly accepted. Breaking up someone else' s block and making that announcement even if its to modify traffic between 2 peered networks is typically not looked as proper. Modify your taffic good. Do it to anyone other traffic = bad. -jim On Fri, Aug 29, 2008 at 6:58 PM, Florian Weimer wrote: > * Alex Pilosov: > >> We've demonstrated ability to monitor traffic to arbitrary >> prefixes. Slides for presentation can be found here: >> http://eng.5ninesdata.com/~tkapela/iphd-2.ppt > > The interesting question is whether it's acceptable to use this trick > for non-malicious day-to-day traffic engineering. > > From ge at linuxbox.org Fri Aug 29 19:52:49 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 29 Aug 2008 19:52:49 -0500 (CDT) Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercage, w hy are we peering with the American RBN?] In-Reply-To: <20080829.174338.26085.0@webmail08.vgs.untd.com> References: <20080829.174338.26085.0@webmail08.vgs.untd.com> Message-ID: On Sat, 30 Aug 2008, Paul Ferguson wrote: > I applaud GLBX's move to disconnect Atrivo/Intercage. > > What the Armin/McQuaid/Jonkman report [1] documented are activities > that many of us in the security community have known for a couple > of years. > > One thing that Krebs _didn't_ mention in his WaPo article are the > large number of rogue DNS servers that also reside there. A couple > of colleagues, Feike Hacquebord, Chenguai Lu, et al., presented a > paper at the Virus Bulletin conference last year [2]. While the > paper is almost a year old, that particular situation has gotten > progressively worse. > > My only concern here is that by the publicity this issue continues > to receive, these activities will just move else where, like > scurrying cockroaches (like what happened with AS40989). > > One step at a time, I suppose. Yep, I am almost intrigued to see where they move. They'd move eventually anyway, the question is if we can then gripe about other countries not being responsive and approach that problem, or have to drive by their building to the office every morning? Gadi From adrian at creative.net.au Fri Aug 29 21:25:49 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 30 Aug 2008 10:25:49 +0800 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> Message-ID: <20080830022549.GA25508@skywalker.creative.net.au> On Fri, Aug 29, 2008, jim deleskie wrote: > Announcing a smaller bit of one of you block is fine, more then that > most everyone I know does it or has done and is commonly accepted. > Breaking up someone else' s block and making that announcement even if > its to modify traffic between 2 peered networks is typically not > looked as proper. Modify your taffic good. Do it to anyone other > traffic = bad. The question shouldn't really be "would people do this to others' traffic"; the question should be "has it already happened and noone noticed." Adrian From deleskie at gmail.com Fri Aug 29 21:41:12 2008 From: deleskie at gmail.com (jim deleskie) Date: Fri, 29 Aug 2008 23:41:12 -0300 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <20080830022549.GA25508@skywalker.creative.net.au> References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> <20080830022549.GA25508@skywalker.creative.net.au> Message-ID: I'm afraid of the answer to that question On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd wrote: > On Fri, Aug 29, 2008, jim deleskie wrote: >> Announcing a smaller bit of one of you block is fine, more then that >> most everyone I know does it or has done and is commonly accepted. >> Breaking up someone else' s block and making that announcement even if >> its to modify traffic between 2 peered networks is typically not >> looked as proper. Modify your taffic good. Do it to anyone other >> traffic = bad. > > The question shouldn't really be "would people do this to others' traffic"; > the question should be "has it already happened and noone noticed." > > > > > > Adrian > > From patrick at ianai.net Fri Aug 29 22:01:12 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 29 Aug 2008 23:01:12 -0400 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> <20080830022549.GA25508@skywalker.creative.net.au> Message-ID: On Aug 29, 2008, at 22:41, "jim deleskie" wrote: > I'm afraid of the answer to that question No you are not, since you already know the answer. -- TTFN, patrick > On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd > wrote: >> On Fri, Aug 29, 2008, jim deleskie wrote: >>> Announcing a smaller bit of one of you block is fine, more then that >>> most everyone I know does it or has done and is commonly accepted. >>> Breaking up someone else' s block and making that announcement >>> even if >>> its to modify traffic between 2 peered networks is typically not >>> looked as proper. Modify your taffic good. Do it to anyone other >>> traffic = bad. >> >> The question shouldn't really be "would people do this to others' >> traffic"; >> the question should be "has it already happened and noone noticed." >> >> >> >> >> >> Adrian >> >> > From nanog at daork.net Fri Aug 29 22:24:34 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 30 Aug 2008 15:24:34 +1200 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <87zlmvbi0n.fsf@mid.deneb.enyo.de> References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> Message-ID: <2F2DB4AB-4648-424A-8E30-13DA34958A03@daork.net> On 30/08/2008, at 9:58 AM, Florian Weimer wrote: > * Alex Pilosov: > >> We've demonstrated ability to monitor traffic to arbitrary >> prefixes. Slides for presentation can be found here: >> http://eng.5ninesdata.com/~tkapela/iphd-2.ppt > > The interesting question is whether it's acceptable to use this trick > for non-malicious day-to-day traffic engineering. The technique of path stuffing ASes who you do not want to receive an announcement is called AS PATH poisoning. It's a fairly well known trick. -- Nathan Ward From maurielelgrande at gmail.com Sat Aug 30 03:21:00 2008 From: maurielelgrande at gmail.com (mauricio elelgrande) Date: Sat, 30 Aug 2008 10:21:00 +0200 Subject: BGP more specific prefixes Message-ID: Sorry for sending this "huge" mail :-) At this moment we have a very simple multihomed ASN with a /20 prefix (x.y.0.0/20) like many other companys in the world. Some days ago, a BGP issue was announced about "IP hijacking". OK, we understand that this is some "new" because the traffic is also sent back to the "real owner" of the block. What kind of security can we have (and all internet providers) about that there is nobody announcing a subset of their prefix or a subset of their customer prefixes (i.e. x.y.0.0/24) disturbing the "normal" traffic flow? Of course, we know about prefix monitoring tools (from RIPE and others) but... it is the best solution? Or simply anyone can announce the /24 prefix that he want "capturing" that /24 prefix (of course if the "normal" prefix is smaller than that (i.e. /16))? In other words... can anybody "capture" the /24 prefix that he want? For example, what hapens if somebody announces a /24 from company "A" meanwhile the "normal" valid prefix of company "A"is a /16 and directs it to null0? That /24 is "shutted down". That is not the "new IP hijacking" issue because the traffic is not sent back to company "A". The question is very simply, It is very very difficult for me to believe that anybody can "shutdown" the /24 network that he wants in the world. I am right? Or may be that simply internet works like this and the providers are very careful about what accepts from their customers and what announces to other providers? I don't know the details of how internet providers work, but I know that when we made our multihoming for our ASN both providers did not setup the BGP session until we have created the "route object" in RIPE that makes a relationship between our ASN and our prefix. Also both providers have made filters in order to accept only our prefix in our BGP session. In other words... There is anybody in internet that can be sure that their traffic (traffic destined to their prefix) is not going to be "stoled"? If yes... how? Keep in mind that announcing the same prefixes than the attacker will not solve totally the problem because it is only a partial solution. If announcing a more specific /24 network is so easy... why does this not happen every day (for example for shutting down competitors sites)? Best regards From raymond at prolocation.net Sat Aug 30 03:32:08 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sat, 30 Aug 2008 10:32:08 +0200 (CEST) Subject: BGP more specific prefixes In-Reply-To: References: Message-ID: Hi! > Some days ago, a BGP issue was announced about "IP hijacking". > OK, we understand that this is some "new" because the traffic is also sent > back to the "real owner" of the block. Traffic will walk the shotest path, so you can never tell its the 'real' owner that will receive this traffic. > What kind of security can we have (and all internet providers) about that > there is nobody announcing a subset of their prefix or a subset of their > customer prefixes (i.e. x.y.0.0/24) disturbing the "normal" traffic flow? > Of course, we know about prefix monitoring tools (from RIPE and others) > but... it is the best solution? > > Or simply anyone can announce the /24 prefix that he want "capturing" that > /24 prefix (of course if the "normal" prefix is smaller than that (i.e. > /16))? > In other words... can anybody "capture" the /24 prefix that he want? If i start announing your /24, and my upstreams dont do proper filtering, i steal your prefix, easy as that. As little this may be, my most direct peerings will accept the routes and off you go. And prefix filtering is within some providers not even per customer, we personally had for example issues with a big carrier, somethhing with a 3 inside their name, who only had a large prefix filter with *ALL* their customers, so if another customer of that same 3 would announce our prefixes, it would be ok for them, and that happened. So we were blackholed, since that other customer had many peerings with '3' on various locations. So even with 'some' filtering in place bad things can and will happen. > The question is very simply, It is very very difficult for me to believe > that anybody can "shutdown" the /24 network that he wants in the world. > I am right? No? Its dead simple in fact. Totally shut down, no, since you most likely have direct peers who have a shorter path. > Or may be that simply internet works like this and the providers are very > careful about what accepts from their customers and what announces to other > providers? Ghe ... you think route leaking and stealing dont happen on a daily base? Go look and see where a major part of your spam is comming from, yes, stolen prefixes. > In other words... There is anybody in internet that can be sure that their > traffic (traffic destined to their prefix) is not going to be "stoled"? > If yes... how? > > Keep in mind that announcing the same prefixes than the attacker will not > solve totally the problem because it is only a partial solution. > > If announcing a more specific /24 network is so easy... why does this not > happen every day (for example for shutting down competitors sites)? It does happen daily, wake up! Bye, Raymond. From srgqwerty at gmail.com Sat Aug 30 04:24:26 2008 From: srgqwerty at gmail.com (Sergio) Date: Sat, 30 Aug 2008 11:24:26 +0200 Subject: BGP more specific prefixes In-Reply-To: References: Message-ID: <200808301124.26707.srgqwerty@gmail.com> Raymond: Thanks a lot for your comments, but... nobody can be sure that their complete prefix is routed OK to him (the "owner" AS). Right? Do you see this as a normal behavior? What do you think that is the best way to protect about this? Do you think that our upstreams can help us? Best regards On Saturday 30 August 2008 10:32:08 Raymond Dijkxhoorn wrote: > Hi! > > > Some days ago, a BGP issue was announced about "IP hijacking". > > OK, we understand that this is some "new" because the traffic is also > > sent back to the "real owner" of the block. > > Traffic will walk the shotest path, so you can never tell its the 'real' > owner that will receive this traffic. > > > What kind of security can we have (and all internet providers) about that > > there is nobody announcing a subset of their prefix or a subset of their > > customer prefixes (i.e. x.y.0.0/24) disturbing the "normal" traffic flow? > > Of course, we know about prefix monitoring tools (from RIPE and others) > > but... it is the best solution? > > > > Or simply anyone can announce the /24 prefix that he want "capturing" > > that /24 prefix (of course if the "normal" prefix is smaller than that > > (i.e. /16))? > > In other words... can anybody "capture" the /24 prefix that he want? > > If i start announing your /24, and my upstreams dont do proper filtering, > i steal your prefix, easy as that. As little this may be, my most direct > peerings will accept the routes and off you go. > > And prefix filtering is within some providers not even per customer, we > personally had for example issues with a big carrier, somethhing with a 3 > inside their name, who only had a large prefix filter with *ALL* their > customers, so if another customer of that same 3 would announce our > prefixes, it would be ok for them, and that happened. So we were > blackholed, since that other customer had many peerings with '3' on > various locations. > > So even with 'some' filtering in place bad things can and will happen. > > > The question is very simply, It is very very difficult for me to believe > > that anybody can "shutdown" the /24 network that he wants in the world. > > I am right? > > No? Its dead simple in fact. Totally shut down, no, since you most likely > have direct peers who have a shorter path. > > > Or may be that simply internet works like this and the providers are very > > careful about what accepts from their customers and what announces to > > other providers? > > Ghe ... you think route leaking and stealing dont happen on a daily base? > Go look and see where a major part of your spam is comming from, yes, > stolen prefixes. > > > In other words... There is anybody in internet that can be sure that > > their traffic (traffic destined to their prefix) is not going to be > > "stoled"? If yes... how? > > > > Keep in mind that announcing the same prefixes than the attacker will not > > solve totally the problem because it is only a partial solution. > > > > If announcing a more specific /24 network is so easy... why does this not > > happen every day (for example for shutting down competitors sites)? > > It does happen daily, wake up! > > Bye, > Raymond. From fw at deneb.enyo.de Sat Aug 30 00:55:40 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 30 Aug 2008 07:55:40 +0200 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: (jim deleskie's message of "Fri, 29 Aug 2008 21:47:55 -0300") References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> Message-ID: <87vdxjvyg3.fsf@mid.deneb.enyo.de> * jim deleskie: > Announcing a smaller bit of one of you block is fine, more then that > most everyone I know does it or has done and is commonly accepted. > Breaking up someone else' s block and making that announcement even if > its to modify traffic between 2 peered networks is typically not > looked as proper. Modify your taffic good. Do it to anyone other > traffic = bad. No, the idea would be to do this to your own prefixes/traffic. +------/AS 2/-----/AS 3/--------+ | | /AS 1/ /AS 4/ | | +----------/AS 5/---------------+ I'm AS 1, and the link to AS 2 has a bad metric from my POV. AS 4 uses local preference (or something else I can't override by prepending my own AS) to route traffic to me through AS 3 and AS 2. Now I prepend AS 4 to my announcement to AS 2, and voil?, the traffic flows through AS 5, as desired. No prefix hijacking has occurred (I would have received the traffic anyway, just over a different path), it's just traffic engineering. (But probably a variant that is generally frowned upon.) From jgreco at ns.sol.net Sat Aug 30 08:26:47 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 30 Aug 2008 08:26:47 -0500 (CDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <2F2DB4AB-4648-424A-8E30-13DA34958A03@daork.net> from "Nathan Ward" at Aug 30, 2008 03:24:34 PM Message-ID: <200808301326.m7UDQlbi035565@aurora.sol.net> > On 30/08/2008, at 9:58 AM, Florian Weimer wrote: > > > * Alex Pilosov: > > > >> We've demonstrated ability to monitor traffic to arbitrary > >> prefixes. Slides for presentation can be found here: > >> http://eng.5ninesdata.com/~tkapela/iphd-2.ppt > > > > The interesting question is whether it's acceptable to use this trick > > for non-malicious day-to-day traffic engineering. > > The technique of path stuffing ASes who you do not want to receive an > announcement is called AS PATH poisoning. It's a fairly well known > trick. Not exactly specifically in reply to your note, but more generally: In the old days, Usenet spammers would sometimes preload the Path: line with names of NNTP transits that they might want to avoid for various reasons (usually the home sites of Usenet spam cancellers). In most ways, avoiding offering an article back to a server because it was already listed in the Path: was merely an optimization, to avoid extra traffic on a futile offer. However, simply removing the exclusion allowed the sending site to attempt the transmission, which would then succeed if the receiving site had not seen the article (etc). For purposes of detection, then, it seems reasonable to consider that there could be some way to leverage BGP to monitor for this sort of thing. There would seem to be at least two very interesting things that you could monitor for, which would be irregularities in the ASPATH, and irregularities in your announced prefixes. Since major networks would need to be involved for significant traffic redirection events, I'm wondering if it would be reasonable to have a looking glass/route server type service that would peer with a bunch of them, based on random 32-bit ASN's assigned from a preallocated range for the purpose, one per network (think: reducing effectiveness of AS PATH stuffing). You could then provide a configurable notification service, or for sites with the technical capabilities, a realtime BGP feed of all events involving their AS or prefixes (again over a randomly assigned 32-bit ASN, and obviously to some off-net IP where they run a monitoring box, so that a prefix hijack is ineffective). Such a service would seem like it would be generally useful for other purposes as well. There's almost certainly some fatal flaw in this idea, or maybe better yet, some obvious improvements that could be made, so for the BGP gurus out there, what are they? ... 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 deleskie at gmail.com Sat Aug 30 09:27:54 2008 From: deleskie at gmail.com (jim deleskie) Date: Sat, 30 Aug 2008 11:27:54 -0300 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> <20080830022549.GA25508@skywalker.creative.net.au> Message-ID: True but I can still believe in a warm and fuzzy internet if I try really hard.... Then my cell phone rings and back to the real world. -jim On Sat, Aug 30, 2008 at 12:01 AM, Patrick W. Gilmore wrote: > On Aug 29, 2008, at 22:41, "jim deleskie" wrote: > >> I'm afraid of the answer to that question > > No you are not, since you already know the answer. > > -- TTFN, > patrick > > >> On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd >> wrote: >>> >>> On Fri, Aug 29, 2008, jim deleskie wrote: >>>> >>>> Announcing a smaller bit of one of you block is fine, more then that >>>> most everyone I know does it or has done and is commonly accepted. >>>> Breaking up someone else' s block and making that announcement even if >>>> its to modify traffic between 2 peered networks is typically not >>>> looked as proper. Modify your taffic good. Do it to anyone other >>>> traffic = bad. >>> >>> The question shouldn't really be "would people do this to others' >>> traffic"; >>> the question should be "has it already happened and noone noticed." >>> >>> >>> >>> >>> >>> Adrian >>> >>> >> > > From deleskie at gmail.com Sat Aug 30 09:35:16 2008 From: deleskie at gmail.com (jim deleskie) Date: Sat, 30 Aug 2008 11:35:16 -0300 Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: <87vdxjvyg3.fsf@mid.deneb.enyo.de> References: <87zlmvbi0n.fsf@mid.deneb.enyo.de> <87vdxjvyg3.fsf@mid.deneb.enyo.de> Message-ID: The biggest issue with using a heavy hammer to effect traffic is that you don't always know why the other side is routing the way they are. Could be simple cost (peer vs transit) or a larger issue like congestion. Either way think before you route. I'm thinking Pandora's box hasn't just been opened but blown apart..... -jim On Sat, Aug 30, 2008 at 2:55 AM, Florian Weimer wrote: > * jim deleskie: > >> Announcing a smaller bit of one of you block is fine, more then that >> most everyone I know does it or has done and is commonly accepted. >> Breaking up someone else' s block and making that announcement even if >> its to modify traffic between 2 peered networks is typically not >> looked as proper. Modify your taffic good. Do it to anyone other >> traffic = bad. > > No, the idea would be to do this to your own prefixes/traffic. > > > +------/AS 2/-----/AS 3/--------+ > | | > /AS 1/ /AS 4/ > | | > +----------/AS 5/---------------+ > > I'm AS 1, and the link to AS 2 has a bad metric from my POV. AS 4 uses > local preference (or something else I can't override by prepending my > own AS) to route traffic to me through AS 3 and AS 2. Now I prepend > AS 4 to my announcement to AS 2, and voil?, the traffic flows through > AS 5, as desired. > > No prefix hijacking has occurred (I would have received the traffic > anyway, just over a different path), it's just traffic engineering. > (But probably a variant that is generally frowned upon.) > From xaerni at pop.ch Sat Aug 30 12:04:02 2008 From: xaerni at pop.ch (Xaver Aerni) Date: Sat, 30 Aug 2008 19:04:02 +0200 Subject: Problems with Routing to AT&T and HP Message-ID: <75C6EBFFC8684279B0901EEEFCC06944@telezueri.ch> Hello, We have updated the AS8404 whith IP Rages 94.100.157/24 and 94.100.158.0/23. The Update of the Ripe Database was maked 1 week ago. Our clients has also have Problems to connect some Servers in USA. Over AT&T and HP (i see is an ATT link too) Is possible that AT&T has some Routers which must be updated manualy... Enclose is a Routing log Greetings X. Aerni linux-o4eb:~ # traceroute www.hp.com traceroute to www.hp.com (15.193.112.23), 30 hops max, 40 byte packets 1 77-59-223-226.static.cablecom.ch (77.59.223.226) 0.557 ms 0.849 ms 0.631 ms 2 77-59-223-225.static.cablecom.ch (77.59.223.225) 1.202 ms 1.173 ms 1.985 ms 3 62-2-54-69.static.cablecom.ch (62.2.54.69) 2.146 ms 0.717 ms 1.823 ms 4 ch-gva01a-ra1-ge-1-1-0.aorta.net (213.46.171.53) 9.111 ms 7.430 ms 5.241 ms 5 fr-par02a-rd1-pos-1-0.aorta.net (213.46.160.25) 27.150 ms 27.541 ms 28.884 ms 6 us-was02a-rd1-pos-1-0.aorta.net (213.46.160.106) 108.778 ms 108.656 ms 108.438 ms 7 us-was02a-ri1-ge-0-0-0-0.aorta.net (213.46.190.190) 110.421 ms 110.551 ms 108.689 ms 8 te-4-1.car3.Washington1.Level3.net (4.79.168.201) 164.303 ms 156.589 ms 148.794 ms 9 ae-1-69.edge1.Washington3.Level3.net (4.68.17.11) 109.955 ms 111.947 ms 109.865 ms 10 att-level3-oc192.Washington1.Level3.net (4.68.127.154) 195.878 ms 188.086 ms 180.087 ms 11 tbr2.wswdc.ip.att.net (12.123.8.102) 153.431 ms 152.593 ms 153.443 ms 12 cr2.wswdc.ip.att.net (12.122.16.109) 151.829 ms 151.673 ms 152.191 ms 13 cr1.attga.ip.att.net (12.122.1.173) 152.351 ms 152.811 ms 151.694 ms 14 cr2.dlstx.ip.att.net (12.122.28.174) 163.353 ms 157.482 ms 152.473 ms 15 cr1.dlstx.ip.att.net (12.122.1.209) 152.950 ms 152.487 ms 152.391 ms 16 cr2.hs1tx.ip.att.net (12.122.28.158) 152.213 ms 152.240 ms 152.922 ms 17 tbr2.hs1tx.ip.att.net (12.122.21.198) 152.295 ms 153.509 ms 153.006 ms 18 gar3.hs1tx.ip.att.net (12.123.134.45) 152.065 ms 151.947 ms 152.131 ms 19 12.116.42.166 (12.116.42.166) 153.071 ms 152.897 ms 153.265 ms 20 cce01gwb06-vl105.houston.hp.com (16.96.40.61) 154.593 ms 153.516 ms 153.215 ms 21 * * * 22 * * * 23 * * * 24 * * * 25 16.224.136.18 (16.224.136.18) 153.506 ms 151.410 ms 152.626 ms 26 16.224.136.58 (16.224.136.58) 153.228 ms 153.170 ms 155.002 ms 27 * * * 28 * * * 29 * * * 30 * * * From rusty at hodge.com Sat Aug 30 13:42:59 2008 From: rusty at hodge.com (Rusty Hodge) Date: Sat, 30 Aug 2008 11:42:59 -0700 Subject: GNi/365main Above.net peering problems? Message-ID: <76091495-11B2-4B98-A4B2-8FC78ABCFA32@hodge.com> Anyone using transit from GNi at 365main seeing problems on routes that normally go over Above.net? For the last 36 hours, we've had problems. GNi isn't saying anything except that "replacement router cards are being delivered". I'm not sure if it's just routing via Above.net but lots of routes going through core-01.ge-1-1.sfo1.gni.com seems to be getting dropped. From zzuser at yahoo.com Sat Aug 30 13:54:50 2008 From: zzuser at yahoo.com (Zed Usser) Date: Sat, 30 Aug 2008 11:54:50 -0700 (PDT) Subject: 10GE CWDM Message-ID: <922203.27764.qm@web65506.mail.ac4.yahoo.com> Hi! I seem to suffer from an acute lack of 10GE CWDM optics options. Is it just me or am I just looking in all the wrong places? You'd think that by now there would be an upgrade market from 1GE to 10GE. DWDM wavelenghts are not always available, but CWDM often are. - Zed From wschultz at bsdboy.com Sat Aug 30 14:17:03 2008 From: wschultz at bsdboy.com (Wil Schultz) Date: Sat, 30 Aug 2008 12:17:03 -0700 Subject: GNi/365main Above.net peering problems? In-Reply-To: <76091495-11B2-4B98-A4B2-8FC78ABCFA32@hodge.com> References: <76091495-11B2-4B98-A4B2-8FC78ABCFA32@hodge.com> Message-ID: <20853DEE-F933-4140-A3B2-71CBC96A7186@bsdboy.com> We found a routing loop on 8/20 caused by some maintenance that either did not get completed, wasn't properly configured, or otherwise had some problems the evening before. At that point I went ahead and shut down BGP peering and asked to be notified when all was well. 8/26 notified that all was well, other customers had been affected, really sorry about that, etc. 8/27 received another emergency maintenance notification 8/29 received another emergency maintenance notification I did not do any investigation so I don't know any more then the above but there clearly is some work being done that has not gone exactly as planned. Meanwhile, peering will remain down until they things get straightened out. I suppose the short answer is, we've seen problems for about 10 days. Hope they get things worked out. -wil On Aug 30, 2008, at 11:42 AM, Rusty Hodge wrote: > Anyone using transit from GNi at 365main seeing problems on routes > that normally go over Above.net? > > For the last 36 hours, we've had problems. GNi isn't saying anything > except that "replacement router cards are being delivered". > > I'm not sure if it's just routing via Above.net but lots of routes > going through core-01.ge-1-1.sfo1.gni.com seems to be getting > dropped. > From isabeldias1 at yahoo.com Sat Aug 30 15:47:53 2008 From: isabeldias1 at yahoo.com (isabel dias) Date: Sat, 30 Aug 2008 13:47:53 -0700 (PDT) Subject: Revealed: The Internet's well known BGP behavior In-Reply-To: Message-ID: <173640.53161.qm@web52606.mail.re2.yahoo.com> everyone seems to have their saying ....from leting you wonder on what is the problem to making assumptions to witty technical explanations and useless question rephrased. For some reading this some are just non-technical individuals posting messages. All can be done ..we all know the BGP selection path algoritm and its extentions ...maybe a costing exercice to some that rather have interface X down for a while or reroute traffic through a different path Is the problem still occuring? Who's being affected? PS: going back to the drawing board is also an interesting approach if this is geting too complex ...:-) --- On Sat, 8/30/08, Patrick W. Gilmore wrote: > From: Patrick W. Gilmore > Subject: Re: Revealed: The Internet's well known BGP behavior > To: "nanog at nanog.org" > Date: Saturday, August 30, 2008, 5:01 AM > On Aug 29, 2008, at 22:41, "jim deleskie" > wrote: > > > I'm afraid of the answer to that question > > No you are not, since you already know the answer. > > -- > TTFN, > patrick > > > > On Fri, Aug 29, 2008 at 11:25 PM, Adrian Chadd > > wrote: > >> On Fri, Aug 29, 2008, jim deleskie wrote: > >>> Announcing a smaller bit of one of you block > is fine, more then that > >>> most everyone I know does it or has done and > is commonly accepted. > >>> Breaking up someone else' s block and > making that announcement > >>> even if > >>> its to modify traffic between 2 peered > networks is typically not > >>> looked as proper. Modify your taffic good. Do > it to anyone other > >>> traffic = bad. > >> > >> The question shouldn't really be "would > people do this to others' > >> traffic"; > >> the question should be "has it already > happened and noone noticed." > >> > >> > >> > >> > >> > >> Adrian > >> > >> > > From rusty at hodge.com Sat Aug 30 15:55:28 2008 From: rusty at hodge.com (Rusty Hodge) Date: Sat, 30 Aug 2008 13:55:28 -0700 Subject: GNi/365main Above.net peering problems? In-Reply-To: <76091495-11B2-4B98-A4B2-8FC78ABCFA32@hodge.com> References: <76091495-11B2-4B98-A4B2-8FC78ABCFA32@hodge.com> Message-ID: Received this update for GNi: > At this time we believe we have found a Cisco day 0 network > vulnerability. > > We have 20+ routers in our core network - 6 of the 20 have the > identical route > processor and IOS version. These 6 have been affected in 3 separate > geographical locations in the past several days. The network issues > range > from simple SNMP failure to loss of BGP or OSPF communications. > These are > creating black holes intermittently across our network. We are > experiencing as > much as 20% of networks not available at this time. > > We have been coordinating with Cisco for the past two days and have > deployed > patches to address the problem. Overall, we have determined that > the fastest, > surest path to restoring 100% network normality is to replace these > 6 routers. > We will continue this process to replace these 6 routers. > > Two of the six affected routers have already been replaced and > clients have > been moved. We are now replacing the remaining 4 affected routers. > We know that this week has been very painful and frustrating for > you. We will > provide a detailed and open RFO Reason For Outage post mortem > document as soon > as we have the replaced the affected routers. > > Also, I will be updating all customers who have opened tickets at > least every > two hours from this time to ensure that all customers have the > latest status > information. If you would prefer a phone call status report, please > note it > on the ticket and I will also give you a call to answer any additional > questions you may have. In addition, you may call the NOC at your > convenience > at (415) 979-9786. > > Thank you for your patience. From nitzan.tzelniker at gmail.com Sat Aug 30 19:23:35 2008 From: nitzan.tzelniker at gmail.com (Nitzan Tzelniker) Date: Sun, 31 Aug 2008 03:23:35 +0300 Subject: 10GE CWDM In-Reply-To: <922203.27764.qm@web65506.mail.ac4.yahoo.com> References: <922203.27764.qm@web65506.mail.ac4.yahoo.com> Message-ID: <6d72a2a10808301723w2c3cfcbeqbf541978a72fa6c5@mail.gmail.com> Hi, Look here http://www.btisystems.com/news/releases/Goldfield_Telecom.php Nitzan On Sat, Aug 30, 2008 at 21:54, Zed Usser wrote: > Hi! > > I seem to suffer from an acute lack of 10GE CWDM optics options. Is it just > me or am I just looking in all the wrong places? > > You'd think that by now there would be an upgrade market from 1GE to 10GE. > DWDM wavelenghts are not always available, but CWDM often are. > > - Zed > > > > > From alex at pilosoft.com Sat Aug 30 20:17:24 2008 From: alex at pilosoft.com (Alex Pilosov) Date: Sat, 30 Aug 2008 21:17:24 -0400 (EDT) Subject: 10GE CWDM In-Reply-To: <6d72a2a10808301723w2c3cfcbeqbf541978a72fa6c5@mail.gmail.com> Message-ID: On Sun, 31 Aug 2008, Nitzan Tzelniker wrote: > Hi, > > Look here > > http://www.btisystems.com/news/releases/Goldfield_Telecom.php These are XFP-based. Thus, not a solution to the problem above. Answer: Nobody's making 10GE CWDM-wavelength lasers. Why? I don't have enough knowledge of optical equipment, but my understanding is that it is because: a) Currently DWDM component suppliers already have a full load of orders and have problems scaling production - as evidenced by long lead times on any DWDM optics. b) They wouldn't be much cheaper to produce than temperature-stabilized DWDM optics. c) The demand is currently for amplifiable DWDM optics. -alex From john at internetassociatesllc.com Sat Aug 30 23:03:56 2008 From: john at internetassociatesllc.com (John Lee) Date: Sat, 30 Aug 2008 23:03:56 -0500 Subject: 10GE CWDM In-Reply-To: <922203.27764.qm@web65506.mail.ac4.yahoo.com> References: <922203.27764.qm@web65506.mail.ac4.yahoo.com> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942EA6F7697F@MEMEXG1.HOST.local> Zed, If you are looking for optical systems my fav pub is Lightwave at http://lw.pennnet.com/. They list DWDM and CWDM systems, lasers, optics, ROADM etc. If you have nanog archives go back at least six months to the thread on DWDM vs CWDM et al that I was one of the contributors to. The last comment you make I do not understand since: 1. DWDM systems have many more lasers / wavelengths that are used and most metro and WAN providers can supply you a ITU wavelength at the normally obscene prices. 2. CWDM systems are usually 4, 8, 16, 24 that are also on ITU wavelengths like DWDM systems but with 50 - 100 nm or more spacing so the lasers and optics do not have to be so precise as the DWDM optics. Currently it is my understanding the 10 Gbps signals are carried on 4 x 2.5 Gbps signals that are compatible with existing CWDM and DWDM equipment. There are 40 Gbps DWDM systems and 10 Gbps lasers on 100 Gbps and greater capacity systems. I agree with Alex's comments that to have 10 Gbps on a CWDM system is to have a CWDM system of at least 40 to 100 Gbps and that is very expensive today. John (ISDN) Lee >From Lightwafve: Optelian adds CWDM XFP transceivers AUGUST 19, 2008 -- Optelian (search for (search for Optelian)) has announced the availability of new LightGAIN 10-Gbit/sec CWDM XFP transceivers, which the company claims create a cost breakthrough in 10-Gbit/sec capacity growth by combining the low price points of CWDM with the inventory cost benefits of using MSA-compliant pluggable transceivers. "These new CWDM XFP transceivers are a cost-saving solution for fiber-constrained customers looking to grow their 10-Gbit/sec services [but] who don't need the full migration path provided by DWDM," explains Dave Dal Farra, senior Optelian product manager. "And in higher growth networks, the low first cost and inventory savings can still be taken advantage of by adding up to 9 DWDM wavelengths into unused CWDM channels, utilizing Optelian's hybrid CWDM/DWDM multiplexers and 10-Gbit/sec tunable DWDM regenerators." The new CWDM XFP transceivers are fully supported and backwards compatible in LightGAIN 6140, 5140, and 3060 systems, plugging into the existing RGN-10GXF 10-Gbit/sec regenerator card. As part of LightGAIN, the flexibility of CWDM pluggable transceivers combines with Optelian's Quick-Turn Custom Passives so that custom 10-Gbit/sec CWDM configurations can be delivered as quickly as two weeks, claim company representatives. Also useful for wavelength conversion, reach extension, and regeneration, the 10-Gbit/sec CWDM XFP transceivers are now available for order. Key specifications include coverage from 1471 nm to 1611 nm, plus SONET and Gigabit Ethernet compliance for data rates with or without G.709 FEC. >From Alex's older e-mail: On Fri, 25 Apr 2008, John Lee wrote: > Subscribe to Lightwave (at no charge) and look at the back issues for networks. Show up at Supercom or OFC or what is replacing them and get the latest on ROADM, full channel tunable lasers and maintenance costs. > > What size of network do you want to grow to before replacing the optical link equipment including ILAs? > > Most any org can cost justify a CWDM / CAN since you can add one fiber pair at a time and one lambda per fiber pair. > > DWDM gear is much more expensive and is aimed at 20 to 40 lambdas per > fiber for service providers while UDWDM and ULHWAN are aimed at trans > oceanic links and are very very expensive. DWDM gear is not expensive. Passive muxes cost little. Active transceivers cost money but not very expensive at all. Check out these two presentations (by yours truly et al): http://www.nanog.org/mtg-0606/pdf/lightning-talks/4-pilosov.pdf http://www.nanog.org/mtg-0610/presenter-pdfs/pilosov.pdf -alex ________________________________________ From: Zed Usser [zzuser at yahoo.com] Sent: Saturday, August 30, 2008 2:54 PM To: nanog at merit.edu Subject: 10GE CWDM Hi! I seem to suffer from an acute lack of 10GE CWDM optics options. Is it just me or am I just looking in all the wrong places? You'd think that by now there would be an upgrade market from 1GE to 10GE. DWDM wavelenghts are not always available, but CWDM often are. - Zed