From skandor at gmail.com Fri Jan 1 09:03:54 2010 From: skandor at gmail.com (A.B. Jr.) Date: Fri, 1 Jan 2010 13:03:54 -0200 Subject: Restrictions on Ethernet L2 circuits? Message-ID: <25f9e2131001010703l5273274avb55b1903f557dacb@mail.gmail.com> Linen, > As far as I'm concerned, enterprises should just connect their various sites to the Internet independently, and use VPN > techniques if and where necessary to provide the illusion of a unified network. In practice, this illusion of a single > large LAN (or rather, multiple organization-wide LANs) is very important to the typical enterprise, because so much > security policy is enforced based on IP addresses. And the typical enterprise wants a central chokepoint that all traffic > must go through, for reasons that might have to do with security, or support costs, or with (illusions of) control. Most security policies are also based on 'local" vs "remote" criteria. Most pieces of software believe that an access to a local IP is faster and safer than accesses to an IP address somewhere else. Emulate means lying to someone, and if you start lying too much you can end up messing everything. I agree that enterprises should use WANs as WANS (i.e., IP routed networks) and don't try to hide distance and security fragility from systems and security appliances. End to end VPN can be used in the very special cases where a special security is needed, by means of strong VPN encryption. It seems nice to have something that looks like a simple Ethernet cable. The problem is that it is *not* a simple cable, and will never be. Make the rest of the LAN believe that it is such a simple cable may raise huge trouble. Most of LAN protocols have a degree of TRUST on LAN traffic. Any security expert will tell you that trust is your enemy. Managing a router is a hassle? Oh, come on! If a net admin is unable to manage a simple sub net configuration and so some simple math with masks and prefixes he would rather find himself another job. Take care, A.B. Jr. From iljitsch at muada.com Fri Jan 1 12:22:09 2010 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 1 Jan 2010 19:22:09 +0100 Subject: 2009 IPv4 Address Use Report Message-ID: <5943D71A-865D-4B31-AC1A-FADA5498DB60@muada.com> [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace2009.php ] 2009 IPv4 Address Use Report As of January first, 2010, the number of unused IPv4 addresses is 722.18 million. On January 1, 2009, this was 925.58 million. So in 2009, 203.4 million addresses were used up. This is the first time since the introduction of CIDR in 1993 that the number of addresses used in a year has topped 200 million. With 3706.65 million usable addresses, 80.5% of the available IPv4 addresses are now in some kind of use, up from 75.3% a year ago. So the depletion of the IPv4 address reserves is continuing in much the same way as in previous years: Date Addresses free Used up 2006-01-01 1468.61 M 2007-01-01 1300.65 M 167.96 M 2008-01-01 1122.85 M 177.80 M (with return of 16.78 M to IANA) 2009-01-01 925.58 M 197.27 M 2010-01-01 722.18 M 203.40 M These figures are derived from from the Internet Assigned Numbers Authority's IANA IPv4 Address Space Registry page and the records published on the FTP servers of the five Regional Internet Registries (RIRs): AfriNIC, which gives out address space in Africa, APNIC (Asia-Pacific region), ARIN (North America), LACNIC (Latin American and the Caribbean) and the RIPE NCC (Europe, the former Soviet Union and the Middle East). The IANA list shows the status of all 256 blocks of 16777216 addresses identified by the first 8-bit number in the IPv4 address. http://www.bgpexpert.com/ianaglobalpool.php is a graphical representation of the IANA global pool (updated weekly). The RIR data indicates how much address space the RIRs have delegated to internet service providers (and sometimes end-users). The changes over the course of 2009 are as follows: Delegated Blocks +/- 2009 Addresses Used Available to/status (in millions) AfriNIC 2 33.55 14.89 18.66 APNIC 34 +4 570.42 540.36 30.06 ARIN 31 520.09 486.58 33.51 LACNIC 6 100.66 79.77 20.89 RIPE NCC 30 +4 503.32 450.11 53.21 RIRs subtotal 103 +8 1728.05 1571.71 156.34 LEGACY 92 1543.50 1413.88 129.62 UNALLOCATED 26 -8 436.21 436.21 Totals 221 3707.76 2985.59 722.17 The RIRs requested an unusually small number of /8s from IANA: only eight. As a result, APNIC is well below the nine months working inventory threshold, so it should be getting no less than six additional /8s soon to get back to 18 months working inventory. Similarly, ARIN should be getting five additional /8s soon. This would bring us to 15 /8s remaining in the IANA global pool, and should allow for regular operation for about the rest of the year. Then in early 2011, the next round of delegations will have to happen, which may or may not hit the magic fifth-to-last /8, after which the remaining four will be given to the other four RIRs and then each RIR will run out of IPv4 space at its own pace. The total number of available addresses is slightly higher than the previously mentioned figure at 3707.76 million because the table above includes 172.16.0.0/12 and 192.168.0.0/16, which are set aside for private use. Networks 0.0.0.0/8 and 127.0.0.0/8 aren't usable because of special uses and 10.0.0.0/8 is also set aside for private use. 224 - 239 are multicast addresses, and 240 - 255 is class E, which is "reserved for future use". The 2985 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: 2010-01-01 2009-01-01 increase Country 1 - US 1495.13 M 1458.21 M 2.3% United States 2 - CN 232.45 M 181.80 M 27.9% China 3 - JP 177.15 M 151.56 M 16.9% Japan 4 - EU 149.48 M 120.29 M 24.3% Multi-country in Europe 5 (6) DE 86.51 M 81.75 M 5.8% Germany 6 (9) KR 77.77 M 66.82 M 16.4% Korea 7 - CA 76.96 M 74.49 M 3.3% Canada 8 - FR 75.54 M 68.04 M 11.0% France 9 (5) GB 74.18 M 86.31 M -14.1% United Kingdom 10 - AU 39.77 M 36.26 M 9.7% Australia 11 - BR 33.95 M 29.75 M 14.1% Brazil 12 - IT 33.50 M 29.64 M 13.0% Italy 13 (14) RU 28.47 M 23.18 M 22.8% Russia 14 (13) TW 27.10 M 24.01 M 12.9% Taiwan 15 (17) NL 22.84 M 21.67 M 5.4% Netherlands The reduction in address use by the UK is because net 51.0.0.0/8 is now registered as country "EU" rather than "GB". In 2008, the United States was the biggest user of new address space with 50 million new addresses put into use. China was second with 46.50 million. In 2009, they swapped places: China used up 50.65 million addresses and the US a mere 36.92 million. The US now holds 50.1% of the IPv4 address space in use, down from 52.4% last year. The total for the top 15 excluding the US is now 38%, up from 35.8%. The rest of the world gets the remaining 12%, up from 11.8%. The size of address blocks given out was increasing until 2005, and then started decreasing. The table below shows the number of delegations for a certain range of block sizes (equal or higher than the first, lower than the second value). 2003 2004 2005 2006 2007 2008 2009 < 1000 745 1022 1309 1507 1830 1896 1747 1000 - 8000 1009 1516 1891 2265 2839 3235 3185 8000 - 64k 1014 1100 1039 1192 1015 1129 1169 64k - 500k 215 404 309 419 395 410 403 500k - 2M 46 61 60 57 62 82 70 > 2M 6 7 18 17 24 18 21 In millions of addresses: 2003 2004 2005 2006 2007 2008 2009 < 1000 0.25 0.35 0.44 0.51 0.63 0.65 0.59 1000 - 8000 3.45 4.49 5.07 5.83 6.93 7.75 7.55 8000 - 64k 14.00 15.99 15.46 18.01 15.67 17.40 18.01 64k - 500k 25.51 42.01 34.23 50.86 50.83 52.58 50.50 500k - 2M 31.98 44.63 41.63 46.69 45.50 57.41 49.28 > 2M 12.58 20.97 68.62 52.43 67.37 54.00 54.12 Numbers of delegations and their average size: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 2006 5457 174.32 31945 2007 6165 186.92 30320 2008 6770 189.79 28035 2009 6595 180.06 27302 (The numbers of addresses given out are lower here because ARIN often attributes the delegation of new addresses to a previous year, this view doesn't correct for that.) From cscora at apnic.net Fri Jan 1 12:29:31 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Jan 2010 04:29:31 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201001011829.o01ITVfd027499@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 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 307533 Prefixes after maximum aggregation: 143181 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 151348 Total ASes present in the Internet Routing Table: 33011 Prefixes per ASN: 9.32 Origin-only ASes present in the Internet Routing Table: 28654 Origin ASes announcing only one prefix: 14007 Transit ASes present in the Internet Routing Table: 4357 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (12026) 22 Prefixes from unregistered ASNs in the Routing Table: 715 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 383 Prefixes from 32-bit ASNs in the Routing Table: 339 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 162 Number of addresses announced to Internet: 2167751936 Equivalent to 129 /8s, 53 /16s and 69 /24s Percentage of available address space announced: 58.5 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.5 Total number of prefixes smaller than registry allocations: 148125 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 74089 Total APNIC prefixes after maximum aggregation: 25790 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 70774 Unique aggregates announced from the APNIC address blocks: 31309 APNIC Region origin ASes present in the Internet Routing Table: 3905 APNIC Prefixes per ASN: 18.12 APNIC Region origin ASes announcing only one prefix: 1068 APNIC Region transit ASes present in the Internet Routing Table: 607 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 486372128 Equivalent to 28 /8s, 253 /16s and 115 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/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, 133/8, 175/8, 180/8, 182/8, 183/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: 129256 Total ARIN prefixes after maximum aggregation: 67488 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 103378 Unique aggregates announced from the ARIN address blocks: 39110 ARIN Region origin ASes present in the Internet Routing Table: 13433 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5203 ARIN Region transit ASes present in the Internet Routing Table: 1329 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 24 Number of ARIN addresses announced to Internet: 734383904 Equivalent to 43 /8s, 197 /16s and 207 /24s Percentage of available ARIN address space announced: 64.4 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 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70759 Total RIPE prefixes after maximum aggregation: 41424 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 64080 Unique aggregates announced from the RIPE address blocks: 42712 RIPE Region origin ASes present in the Internet Routing Table: 13931 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7257 RIPE Region transit ASes present in the Internet Routing Table: 2102 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 409348160 Equivalent to 24 /8s, 102 /16s and 40 /24s Percentage of available RIPE address space announced: 76.2 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26903 Total LACNIC prefixes after maximum aggregation: 6534 LACNIC Deaggregation factor: 4.12 Prefixes being announced from the LACNIC address blocks: 25272 Unique aggregates announced from the LACNIC address blocks: 13806 LACNIC Region origin ASes present in the Internet Routing Table: 1220 LACNIC Prefixes per ASN: 20.71 LACNIC Region origin ASes announcing only one prefix: 386 LACNIC Region transit ASes present in the Internet Routing Table: 201 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 23 Number of LACNIC addresses announced to Internet: 69882624 Equivalent to 4 /8s, 42 /16s and 83 /24s Percentage of available LACNIC address space announced: 69.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 5961 Total AfriNIC prefixes after maximum aggregation: 1605 AfriNIC Deaggregation factor: 3.71 Prefixes being announced from the AfriNIC address blocks: 4352 Unique aggregates announced from the AfriNIC address blocks: 1561 AfriNIC Region origin ASes present in the Internet Routing Table: 336 AfriNIC Prefixes per ASN: 12.95 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 70 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14596352 Equivalent to 0 /8s, 222 /16s and 185 /24s Percentage of available AfriNIC address space announced: 43.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1839 7510 477 Korea Telecom (KIX) 17488 1460 144 142 Hathway IP Over Cable Interne 4755 1279 289 144 TATA Communications formerly 4134 1016 19461 399 CHINANET-BACKBONE 18101 1010 204 37 Reliance Infocom Ltd Internet 9583 1000 75 502 Sify Limited 7545 922 198 96 TPG Internet Pty Ltd 17974 859 273 61 PT TELEKOMUNIKASI INDONESIA 9829 853 677 24 BSNL National Internet Backbo 4808 833 1583 211 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 4166 3891 300 bellsouth.net, inc. 4323 3779 1052 399 Time Warner Telecom 1785 1799 699 133 PaeTec Communications, Inc. 7018 1589 5791 1030 AT&T WorldNet Services 20115 1535 1487 667 Charter Communications 2386 1291 617 928 AT&T Data Communications Serv 3356 1203 10929 423 Level 3 Communications, LLC 11492 1153 222 14 Cable One 22773 1123 2600 66 Cox Communications, Inc. 6478 1094 241 304 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 30890 517 98 207 Evolva Telecom 35805 515 40 5 United Telecom of Georgia 3292 448 1903 393 TDC Tele Danmark 702 419 1837 337 UUNET - Commercial IP service 8551 391 354 40 Bezeq International 8866 374 110 23 Bulgarian Telecommunication C 3320 363 7068 309 Deutsche Telekom AG 3301 351 1412 306 TeliaNet Sweden 3215 349 3160 112 France Telecom Transpac 9198 329 202 13 Kazakhtelecom Data Network Ad 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 1572 2898 233 UniNet S.A. de C.V. 10620 1005 224 131 TVCABLE BOGOTA 28573 829 674 84 NET Servicos de Comunicao S.A 7303 664 351 98 Telecom Argentina Stet-France 22047 545 302 14 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 11172 445 99 70 Servicios Alestra S.A de C.V 14117 437 29 11 Telefonica del Sur S.A. 6503 432 163 178 AVANTEL, S.A. 7738 431 858 29 Telecomunicacoes da Bahia 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 8452 1015 444 8 TEDATA 24863 717 143 53 LINKdotNET AS number 3741 273 857 233 The Internet Solution 2018 178 196 100 Tertiary Education Network 6713 176 166 16 Itissalat Al-MAGHRIB 29571 157 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 114 505 68 Telkom SA Ltd 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 4166 3891 300 bellsouth.net, inc. 4323 3779 1052 399 Time Warner Telecom 4766 1839 7510 477 Korea Telecom (KIX) 1785 1799 699 133 PaeTec Communications, Inc. 7018 1589 5791 1030 AT&T WorldNet Services 8151 1572 2898 233 UniNet S.A. de C.V. 20115 1535 1487 667 Charter Communications 17488 1460 144 142 Hathway IP Over Cable Interne 2386 1291 617 928 AT&T Data Communications Serv 4755 1279 289 144 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3779 3380 Time Warner Telecom 1785 1799 1666 PaeTec Communications, Inc. 4766 1839 1362 Korea Telecom (KIX) 8151 1572 1339 UniNet S.A. de C.V. 17488 1460 1318 Hathway IP Over Cable Interne 11492 1153 1139 Cable One 4755 1279 1135 TATA Communications formerly 22773 1123 1057 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1015 1007 TEDATA 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 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 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:21 /9:10 /10:25 /11:65 /12:181 /13:382 /14:653 /15:1233 /16:10825 /17:5041 /18:8614 /19:17705 /20:21604 /21:21482 /22:27858 /23:28034 /24:160868 /25:926 /26:1173 /27:582 /28:224 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2724 4166 bellsouth.net, inc. 4323 2368 3779 Time Warner Telecom 4766 1479 1839 Korea Telecom (KIX) 1785 1267 1799 PaeTec Communications, Inc. 17488 1228 1460 Hathway IP Over Cable Interne 11492 1073 1153 Cable One 18566 1040 1059 Covad Communications 7018 960 1589 AT&T WorldNet Services 8452 911 1015 TEDATA 10620 910 1005 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:243 12:2011 13:9 15:22 16:3 17:8 20:37 24:1291 32:49 38:637 40:99 41:1848 44:3 46:1 47:30 52:6 55:2 56:2 57:24 58:646 59:619 60:446 61:976 62:977 63:2009 64:3793 65:2368 66:4102 67:1838 68:1041 69:2837 70:688 71:231 72:1883 73:3 74:2075 75:225 76:359 77:873 78:602 79:405 80:965 81:802 82:462 83:441 84:508 85:1008 86:381 87:688 88:423 89:1549 90:64 91:2659 92:425 93:1144 94:1345 95:794 96:195 97:289 98:454 99:23 109:203 110:283 111:547 112:169 113:224 114:301 115:402 116:1109 117:592 118:386 119:810 120:148 121:699 122:1377 123:814 124:1025 125:1305 128:212 129:201 130:134 131:459 132:85 133:16 134:188 135:41 136:228 137:176 138:235 139:81 140:463 141:122 142:375 143:340 144:393 145:53 146:387 147:179 148:556 149:196 150:146 151:172 152:228 153:162 154:2 155:270 156:178 157:330 158:98 159:355 160:306 161:175 162:281 163:188 164:309 165:472 166:489 167:393 168:761 169:159 170:567 171:42 172:1 173:407 174:513 175:21 180:267 183:190 184:3 186:242 187:219 188:1121 189:613 190:3430 192:5718 193:4375 194:3364 195:2775 196:1197 198:3552 199:3395 200:5248 201:1446 202:8058 203:8273 204:3984 205:2173 206:2410 207:3053 208:3948 209:3392 210:2525 211:1170 212:1655 213:1651 214:250 215:56 216:4428 217:1389 218:477 219:422 220:1150 221:455 222:301 End of report From vixie at isc.org Fri Jan 1 15:44:13 2010 From: vixie at isc.org (Paul Vixie) Date: Fri, 01 Jan 2010 21:44:13 +0000 Subject: EDNS (Re: Are the Servers of Spamhaus.rg and blackholes.us down?) In-Reply-To: <4B3CB394.6010604@i6ix.com> (Jason Bertoch's message of "Thu\, 31 Dec 2009 09\:22\:12 -0500") References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> Message-ID: Jason Bertoch writes: >> Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving >> 'XXX.YYY.ZZZ/A' (in 'YYY.ZZZ'?): disabling EDNS > > Do you have a firewall in front of this server that limits DNS packets to > 512 bytes? statistically speaking, yes, most people have that. which is damnfoolery, but well supported by the vendors, who think either that udp/53 datagrams larger than 512 octets are amplification attacks, or that udp packets having no port numbers because they are fragments lacking any udp port information, are evil and dangerous. sadly, noone has yet been fired for buying devices that implement this kind of overspecification. hopefully that will change after the DNS root zone is signed and udp/53 responses start to generally include DNSSEC signatures, pushing most of them way over the 512 octet limit. it's going to be another game of chicken -- will the people who build and/or deploy such crapware lose their jobs, or will ICANN back down from DNSSEC? -- Paul Vixie KI6YSY From cidr-report at potaroo.net Fri Jan 1 16:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Jan 2010 22:00:01 GMT Subject: BGP Update Report Message-ID: <201001012200.o01M01oo094170@wattle.apnic.net> BGP Update Report Interval: 24-Dec-09 -to- 31-Dec-09 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6389 25484 2.4% 6.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 2 - AS17974 16206 1.6% 26.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS7643 16063 1.5% 43.5 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 4 - AS9829 11899 1.1% 19.3 -- BSNL-NIB National Internet Backbone 5 - AS7018 10418 1.0% 6.6 -- ATT-INTERNET4 - AT&T WorldNet Services 6 - AS6822 9078 0.9% 1513.0 -- SUPERONLINE-AS SuperOnline autonomous system 7 - AS4270 8981 0.9% 2993.7 -- Red de Interconexion Universitaria 8 - AS2386 8029 0.8% 6.3 -- INS-AS - AT&T Data Communications Services 9 - AS17488 7370 0.7% 6.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 10 - AS4249 7017 0.7% 40.1 -- LILLY-AS - Eli Lilly and Company 11 - AS6478 6681 0.6% 6.1 -- ATT-INTERNET3 - AT&T WorldNet Services 12 - AS1790 6453 0.6% 53.3 -- Sprint US 13 - AS19262 6254 0.6% 6.0 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 14 - AS4755 6138 0.6% 4.8 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 15 - AS10620 6037 0.6% 6.0 -- TV Cable S.A. 16 - AS8151 5988 0.6% 5.5 -- Uninet S.A. de C.V. 17 - AS17908 5897 0.6% 7.7 -- TCISL Tata Communications 18 - AS5800 5867 0.6% 29.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS5803 5605 0.5% 52.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS32398 5022 0.5% 627.8 -- REALNET-ASN-1 TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS27667 3217 0.3% 3217.0 -- Universidad Autonoma de la Laguna 2 - AS4270 8981 0.9% 2993.7 -- Red de Interconexion Universitaria 3 - AS18610 2535 0.2% 2535.0 -- SEQUO-AS - Sequoia Capital 4 - AS5691 2401 0.2% 2401.0 -- MITRE-AS-5 - The MITRE Corporation 5 - AS48754 2342 0.2% 2342.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 6 - AS6822 9078 0.9% 1513.0 -- SUPERONLINE-AS SuperOnline autonomous system 7 - AS17819 2894 0.3% 1447.0 -- ASN-EQUINIX-AP Equinix Asia Pacific 8 - AS45151 1063 0.1% 1063.0 -- INFOLIENTNET-AS-AP INFOLIENT SDN BHD 9 - AS34787 836 0.1% 836.0 -- LYAKH-AS PF "Volodymyr Lyakh" 10 - AS26516 735 0.1% 735.0 -- TMDAS - TMD FRICTION,INC 11 - AS32398 5022 0.5% 627.8 -- REALNET-ASN-1 12 - AS33368 1807 0.2% 451.8 -- FXSERVER - Visual Trading Systems, LLC 13 - AS39384 422 0.0% 422.0 -- GUILAN-UNIV-AS University of Guilan AS System 14 - AS10445 3205 0.3% 356.1 -- HTG - Huntleigh Telcom 15 - AS25244 338 0.0% 338.0 -- DECODE-AS Decode Autonomous System 16 - AS27759 1025 0.1% 256.2 -- ACCESS HAITI S.A. 17 - AS42608 506 0.1% 253.0 -- YAMALSOFT-AS Yamal-Soft 2003 LLC 18 - AS17713 503 0.1% 251.5 -- NSYSU-TW National Sun Yat-sen University 19 - AS16812 752 0.1% 250.7 -- SPACENET-ENT - Spacenet, Inc. 20 - AS50214 250 0.0% 250.0 -- QWARTA Qwarta Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 170.210.56.0/22 8959 0.8% AS4270 -- Red de Interconexion Universitaria 2 - 202.5.154.0/24 3544 0.3% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 3 - 148.245.181.0/24 3217 0.3% AS27667 -- Universidad Autonoma de la Laguna 4 - 202.177.223.0/24 2886 0.3% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 5 - 64.138.134.0/24 2535 0.2% AS18610 -- SEQUO-AS - Sequoia Capital 6 - 192.12.120.0/24 2401 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 7 - 91.212.23.0/24 2342 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 8 - 143.138.107.0/24 2064 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 9 - 118.96.94.0/23 1861 0.2% AS17974 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - 208.86.25.0/24 1775 0.2% AS33368 -- FXSERVER - Visual Trading Systems, LLC 11 - 212.253.192.0/18 1566 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 12 - 212.253.0.0/17 1564 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 13 - 212.253.13.0/24 1489 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 14 - 212.253.6.0/24 1487 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 15 - 212.253.7.0/24 1487 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 16 - 212.253.20.0/24 1485 0.1% AS6822 -- SUPERONLINE-AS SuperOnline autonomous system 17 - 90.150.0.0/24 1485 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 18 - 118.96.28.0/23 1473 0.1% AS17974 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - 200.13.36.0/24 1304 0.1% AS28477 -- Universidad Autonoma del Esstado de Morelos 20 - 157.92.44.192/26 1274 0.1% AS3449 -- Universidad Nacional de Buenos Aires 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 Jan 1 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Jan 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201001012200.o01M00kW094161@wattle.apnic.net> This report has been generated at Fri Jan 1 21:11:45 2010 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-12-09 313727 193284 26-12-09 313681 193062 27-12-09 313791 193106 28-12-09 313763 193274 29-12-09 313753 193405 30-12-09 313815 193119 31-12-09 312906 193091 01-01-10 312945 193090 AS Summary 33236 Number of ASes in routing system 14160 Number of ASes announcing only one prefix 4373 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92585728 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 01Jan10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 313055 193104 119951 38.3% All ASes AS6389 4166 307 3859 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4373 1951 2422 55.4% TWTC - tw telecom holdings, inc. AS4766 1953 596 1357 69.5% KIXS-AS-KR Korea Telecom AS1785 1799 451 1348 74.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1460 328 1132 77.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1123 71 1052 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1279 299 980 76.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1573 674 899 57.2% Uninet S.A. de C.V. AS10620 1005 168 837 83.3% TV Cable S.A. AS19262 1049 235 814 77.6% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 1010 244 766 75.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS18566 1059 343 716 67.6% COVAD - Covad Communications Co. AS8452 1015 317 698 68.8% TEDATA TEDATA AS6478 1094 466 628 57.4% ATT-INTERNET3 - AT&T WorldNet Services AS4808 833 230 603 72.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 821 220 601 73.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1204 617 587 48.8% LEVEL3 Level 3 Communications AS4804 633 70 563 88.9% MPX-AS Microplex PTY LTD AS7303 663 104 559 84.3% Telecom Argentina S.A. AS7018 1590 1032 558 35.1% ATT-INTERNET4 - AT&T WorldNet Services AS4134 1016 478 538 53.0% CHINANET-BACKBONE No.31,Jin-rong Street AS11492 1153 631 522 45.3% CABLEONE - CABLE ONE, INC. AS7545 938 434 504 53.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 545 50 495 90.8% VTR BANDA ANCHA S.A. AS28573 829 356 473 57.1% NET Servicos de Comunicao S.A. AS4780 608 148 460 75.7% SEEDNET Digital United Inc. AS9443 538 78 460 85.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS9299 663 211 452 68.2% IPG-AS-AP Philippine Long Distance Telephone Company AS5668 786 348 438 55.7% AS-5668 - CenturyTel Internet Holdings, Inc. AS17676 565 141 424 75.0% GIGAINFRA Softbank BB Corp. Total 37343 11598 25745 68.9% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 157.234.0.0/16 AS1239 SPRINTLINK - Sprint 157.234.230.0/24 AS1239 SPRINTLINK - Sprint 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 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.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.74.0/24 AS1239 SPRINTLINK - Sprint 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 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet 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.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS30715 207.174.132.0/23 AS30715 207.174.152.0/22 AS30715 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.73.88.0/21 AS36835 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.224.0/24 AS36835 208.77.225.0/24 AS36835 208.77.226.0/24 AS36835 208.77.227.0/24 AS36835 208.77.228.0/24 AS36835 208.77.229.0/24 AS36835 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.77.230.0/24 AS36835 208.77.231.0/24 AS36835 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.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 bmanning at vacation.karoshi.com Fri Jan 1 16:16:31 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 1 Jan 2010 22:16:31 +0000 Subject: EDNS (Re: Are the Servers of Spamhaus.rg and blackholes.us down?) In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> Message-ID: <20100101221631.GA8657@vacation.karoshi.com.> On Fri, Jan 01, 2010 at 09:44:13PM +0000, Paul Vixie wrote: > Jason Bertoch writes: > > >> Dec 31 10:12:37 linux-1ij2 named[14306]: too many timeouts resolving > >> 'XXX.YYY.ZZZ/A' (in 'YYY.ZZZ'?): disabling EDNS > > > > Do you have a firewall in front of this server that limits DNS packets to > > 512 bytes? > > statistically speaking, yes, most people have that. which is damnfoolery, > but well supported by the vendors, who think either that udp/53 datagrams > larger than 512 octets are amplification attacks, or that udp packets having > no port numbers because they are fragments lacking any udp port information, > are evil and dangerous. sadly, noone has yet been fired for buying devices > that implement this kind of overspecification. hopefully that will change > after the DNS root zone is signed and udp/53 responses start to generally > include DNSSEC signatures, pushing most of them way over the 512 octet limit. > > it's going to be another game of chicken -- will the people who build and/or > deploy such crapware lose their jobs, or will ICANN back down from DNSSEC? > -- > Paul Vixie > KI6YSY well, having been pushing vendors for a while on this, expect at least Checkpoint and Cisco to have corrected solutions fielded soon - and RedHat has fixed their DNSMASQ code since it was pointed out to them that thier defaults were based on flawed assumptions. Not a lost cause - but the inertia of the installed base is huge and it will take more than the last six months of work to make a dent. It would help if the BIND EDNS0 negotiation would not fall back to the 512 byte limit - perhaps you could talk with the ISC developers about that. --bill From Even.Endresen at bkk.no Fri Jan 1 16:16:55 2010 From: Even.Endresen at bkk.no (Endresen Even) Date: Fri, 1 Jan 2010 23:16:55 +0100 Subject: Restrictions on Ethernet L2 circuits? References: <4FCB0CE191CC8A4DBFA2A928D74942E1FE7107@BKKNT90.bkk.no> <20091231.195542.74746906.sthaug@nethelp.no> Message-ID: <4FCB0CE191CC8A4DBFA2A928D74942E102120A5E@BKKNT90.bkk.no> > > Couldn't PBB or even Q-in-Q provide that isolation as well, at least for > > point-to-point services? I must say that I don't personally have much > > experience with those, because we tend to connect our customers to > > EoMPLS-capable routers directly. > QinQ does nothing to reduce the number of MAC addresses required. > PBB can do this, but there is still not a lot of PBB equipment > available. PBB would help a lot, but as far as Cisco equipment is concerned, it is only supported on 7600 with ES40 line cards: http://www.cisco.com/en/US/docs/ios/cether/configuration/guide/ce_mac_evc_pbb_ps6922_TSD_Products_Configuration_Guide_Chapter.html On my wish list is PBB support on access layer switches, like the Cisco ME3400. This would bring the benefits of tunneling out to the very edge of the network. We have an MPLS core with a hierarchial Ethernet layer 2 access network between the core and the customer. Typically there are two or three switches between the the PE node and the customer. Even though we are building the MPLS network further out towards the edge, there will always be a layer 2 access network. It is the switches in the access network that is my concern. We have seen some rather strange problems over the years, like customer nodes that flood MAC address tables with spoofed MAC addresses, and frames that are reflected, causing switches to continually re-learn the same MAC-addresses from different ports. MAC header encapsulation at the very edge of the network would protect the switches in the access layer, and thereby make the service providers more willing to offer more transparent products to their customers. Regards, Even ___________________________________________________ This message and any attachment is intended for the person(s) named above only. It may contain information that is confidential or legally privileged. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank You. This footnote confirms that the email and attachment(s) has been swept by our anti-virus solution for the presence of known computer viruses. From brunner at nic-naa.net Fri Jan 1 16:21:21 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 01 Jan 2010 17:21:21 -0500 Subject: EDNS (Re: Are the Servers of Spamhaus.rg and blackholes.us down?) In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> Message-ID: <4B3E7561.8050307@nic-naa.net> On 1/1/10 4:44 PM, Paul Vixie wrote: ... > it's going to be another game of chicken -- will the people who build and/or > deploy such crapware lose their jobs, or will ICANN back down from DNSSEC? Either (a) a large cohort of entries is added to the root before [pick predicate condition of choice, and signing the root is a common one] "foo", or (b) a number of smaller cohorts of entries are added to the root after [pick predicate condition of choice, and signing the root is a common one] "bar". Security and stability is the last shibboleth in ICANN rhetoric, offered frequently absurdly, e.g., [1], and is one of three fictions [2] which, together with the trademarks issue, constitute the "four overarching issues" which presently prevents the Draft Applicant Guidebook from being final, and therefore, from applications being submitted, and the evaluation system from being exercised under load. Should "ICANN back down from DNSSEC", the rational for not starting the application rat race would be reduced to trademarks [3]. ICANN appears to be avoiding that for all of 2010 and 2011. Should "ICANN [not] back down from DNSSEC", the least refutable (by the non-technical community) rational for delay remains controlling, at some cost to businesses that do not invest in issue advocacy at ICANN, and so do not matter in the slightest even if they "go dark". Eric [1] http://forum.icann.org/lists/draft-eoi-model/msg00000.html [2] The Four Overarching Issues are (1) Intellectual Property and Trademark Protection, (2) Economic Analysis, (3) Security and Stability and (4) Malicious Conduct. [3] OK, there is another biggie out there, the idiots at CRAI proposed that we junk the registry-registrar separation _and_ let every moron cereal and/or soap trademark portfolio manager suff their brands into the IANA root. The separation issue is really big, as it is a stalking horse for 15 U.S.C. ? 1?7. The marks-in-the-root issue should give one pause, not for sizeof(footprint) reasons, but because it is unavoidable that strings in the IANA root will become private property, and because as a string generator, trademarks are an infinite string source. From vixie at isc.org Fri Jan 1 16:34:31 2010 From: vixie at isc.org (Paul Vixie) Date: Fri, 01 Jan 2010 22:34:31 +0000 Subject: EDNS (Re: Are the Servers of Spamhaus.rg and blackholes.us down?) In-Reply-To: Your message of "Fri, 01 Jan 2010 22:16:31 GMT." <20100101221631.GA8657@vacation.karoshi.com.> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <20100101221631.GA8657@vacation.karoshi.com.> Message-ID: <43104.1262385271@nsa.vix.com> > Date: Fri, 1 Jan 2010 22:16:31 +0000 > From: bmanning at vacation.karoshi.com > > It would help if the BIND EDNS0 negotiation would not fall back to > the 512 byte limit - perhaps you could talk with the ISC developers > about that. i don't agree that your proposed change would help with this problem at all. but in any case nanog isn't the place to ask ISC to change BIND, nor is it the place to discuss protocol implementation or interpretation. i suggest bind-users@, bind-workers@, dns-operations@, dnsop@, and/or namedroppers@, depending on what aspect of your above-described concerns you focus on. From mike-nanog at tiedyenetworks.com Fri Jan 1 16:52:33 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 01 Jan 2010 14:52:33 -0800 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E7561.8050307@nic-naa.net> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> Message-ID: <4B3E7CB1.2090608@tiedyenetworks.com> I am looking at the possibility of leasing a ~70 mile run of fiber. I don't have access to any mid point section for regeneration purposes, and so I am wondering what the chances that a 120km rated SFP would be able to light the path and provide stable connectivity. There are a lot of unknowns including # of splices, condition of the cable, or the actual dispersion index or other properties (until we actually get closer to leasing it). Its spare telco fibers in the same cable binder they are using interoffice transport, but there are regen huts along the way so it works for them but may not for us, and 'finding out' is potentially expensive. How would someone experienced go about determining the feasibillity of this concept and what options might there be? Replies online or off would be appreciated. Thanks. From streiner at cluebyfour.org Fri Jan 1 17:19:08 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 1 Jan 2010 18:19:08 -0500 (EST) Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E7CB1.2090608@tiedyenetworks.com> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: On Fri, 1 Jan 2010, Mike wrote: > I am looking at the possibility of leasing a ~70 mile run of fiber. I don't > have access to any mid point section for regeneration purposes, and so I am > wondering what the chances that a 120km rated SFP would be able to light the > path and provide stable connectivity. There are a lot of unknowns including # > of splices, condition of the cable, or the actual dispersion index or other > properties (until we actually get closer to leasing it). Its spare telco > fibers in the same cable binder they are using interoffice transport, but > there are regen huts along the way so it works for them but may not for us, > and 'finding out' is potentially expensive. How would someone experienced go > about determining the feasibillity of this concept and what options might > there be? Replies online or off would be appreciated. The first thing you need to do is test the fiber with an OTDR. If you don't have one, you can probably contract a local cabling company to test it for you. How do you plan to drive transport over the fiber? GE? 10G? >10G? CWDM? DWDM? To drive a signal that far without a regen somewhere in the middle, your best bet might be something in the xWDM space, and then you can provision labmdas for GE, 10G, etc... There are boxes out there (Ciena, Infinera, Cisco ONS, etc) that can do this. How do you plan to handle responses to fiber cuts, signal degradation, someone at $telco unplugging the wrong jumper, etc? jms From ras at e-gerbil.net Fri Jan 1 17:19:30 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 1 Jan 2010 17:19:30 -0600 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E7CB1.2090608@tiedyenetworks.com> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: <20100101231930.GS75640@gerbil.cluepon.net> On Fri, Jan 01, 2010 at 02:52:33PM -0800, Mike wrote: > I am looking at the possibility of leasing a ~70 mile run of fiber. I > don't have access to any mid point section for regeneration purposes, > and so I am wondering what the chances that a 120km rated SFP would be > able to light the path and provide stable connectivity. There are a lot > of unknowns including # of splices, condition of the cable, or the > actual dispersion index or other properties (until we actually get > closer to leasing it). Its spare telco fibers in the same cable binder > they are using interoffice transport, but there are regen huts along the > way so it works for them but may not for us, and 'finding out' is > potentially expensive. How would someone experienced go about > determining the feasibillity of this concept and what options might > there be? Replies online or off would be appreciated. That shouldn't be too difficult, especially at only 1G (though pesonally I can't imagine why you would bother leasing dark fiber for that :P). There are several ways you could do it, including 120km+ rated SFPs (iirc there have been 200km SFPs out for a while too), an external optical amplifier (ideally you'd want to amp in the middle, but with a single channel you should be fine w/pre-amp), and a digital FEC wrapper to extend the receive sensitivity. Remember that the distance spec on optics is mostly a rough guideline, so depending on the fiber conditions and number of splices/panels along the way you could potentially expect to get the entire distance out of a "standard" 100km optic. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From a.harrowell at gmail.com Fri Jan 1 18:23:09 2010 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Sat, 2 Jan 2010 00:23:09 +0000 Subject: dark fiber and sfp distance limitations In-Reply-To: <20100101231930.GS75640@gerbil.cluepon.net> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3E7CB1.2090608@tiedyenetworks.com> <20100101231930.GS75640@gerbil.cluepon.net> Message-ID: <201001020023.18016.a.harrowell@gmail.com> On Friday 01 January 2010 23:19:30 Richard A Steenbergen wrote: > On Fri, Jan 01, 2010 at 02:52:33PM -0800, Mike wrote: > > I am looking at the possibility of leasing a ~70 mile run of fiber. I > > don't have access to any mid point section for regeneration purposes, > > and so I am wondering what the chances that a 120km rated SFP would be > > able to light the path and provide stable connectivity. There are a lot > > of unknowns including # of splices, condition of the cable, or the > > actual dispersion index or other properties (until we actually get > > closer to leasing it). Its spare telco fibers in the same cable binder > > they are using interoffice transport, but there are regen huts along the > > way so it works for them but may not for us, and 'finding out' is > > potentially expensive. How would someone experienced go about > > determining the feasibillity of this concept and what options might > > there be? Replies online or off would be appreciated. > > That shouldn't be too difficult, especially at only 1G (though pesonally > I can't imagine why you would bother leasing dark fiber for that :P). > There are several ways you could do it, including 120km+ rated SFPs > (iirc there have been 200km SFPs out for a while too), an external > optical amplifier (ideally you'd want to amp in the middle, but with a > single channel you should be fine w/pre-amp), and a digital FEC wrapper > to extend the receive sensitivity. Remember that the distance spec on > optics is mostly a rough guideline, so depending on the fiber conditions > and number of splices/panels along the way you could potentially expect > to get the entire distance out of a "standard" 100km optic. There was an excellent thread on this list last year about using "unusual" high power lasers for long range optical networking. http://www.merit.edu/mail.archives/nanog/2008-10/msg00226.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From ml at kenweb.org Fri Jan 1 18:24:00 2010 From: ml at kenweb.org (ML) Date: Fri, 01 Jan 2010 19:24:00 -0500 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E7CB1.2090608@tiedyenetworks.com> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: <4B3E9220.6020307@kenweb.org> On 1/1/2010 5:52 PM, Mike wrote: > I am looking at the possibility of leasing a ~70 mile run of fiber. I > don't have access to any mid point section for regeneration purposes, > and so I am wondering what the chances that a 120km rated SFP would be > able to light the path and provide stable connectivity. There are a lot > of unknowns including # of splices, condition of the cable, or the > actual dispersion index or other properties (until we actually get > closer to leasing it). Its spare telco fibers in the same cable binder > they are using interoffice transport, but there are regen huts along the > way so it works for them but may not for us, and 'finding out' is > potentially expensive. How would someone experienced go about > determining the feasibillity of this concept and what options might > there be? Replies online or off would be appreciated. > > Thanks. > > Pardon my ignorance in this area but is too much to ask for OTDR data before signing contracts? In addition to data on the make of the fiber if you wanted to do xWDM in the future. NDAs shall be signed of course.... From herrin-nanog at dirtside.com Fri Jan 1 19:10:59 2010 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 1 Jan 2010 20:10:59 -0500 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E9220.6020307@kenweb.org> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> Message-ID: <3c3e3fca1001011710l5b1cb5dasb14dc5b1c35fb48@mail.gmail.com> On Fri, Jan 1, 2010 at 7:24 PM, ML wrote: > Pardon my ignorance in this area but is too much to ask for OTDR data before > signing contracts? ?In addition to data on the make of the fiber if you > wanted to do xWDM in the future. Yes, it's too much to ask. They won't splice your path until you sign the contracts and you can't get useful OTDR and loss readings until the fiber is spliced. You can probably put an escape clause in the contract that lets you exit with little or no cost if the readings aren't good enough after the fact. If you're not time-constrained, you can probably request a pre-check for a modest fee after main splicing but before trenching to your endpoints. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nick at foobar.org Fri Jan 1 19:36:07 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 02 Jan 2010 01:36:07 +0000 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E9220.6020307@kenweb.org> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> Message-ID: <4B3EA307.2070200@foobar.org> On 02/01/2010 00:24, ML wrote: > Pardon my ignorance in this area but is too much to ask for OTDR data > before signing contracts? In addition to data on the make of the fiber > if you wanted to do xWDM in the future. fibre grade / quality, absolutely. otdr is difficult, because fibre providers usually splice up a specific path for a specific order. This means that they cannot always provide the otdr without first going to some trouble and expense. So you may find yourself having to specify acceptable attenuation limits in advance, then putting in an order and then getting the otdr + accurate attenuation results after the order has been accepted. Obviously, you assume some risk in terms of hoping that the optics that you buy for the circuit will actually do the job. Nick From swmike at swm.pp.se Sat Jan 2 04:58:14 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 2 Jan 2010 11:58:14 +0100 (CET) Subject: dark fiber and sfp distance limitations In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: On Fri, 1 Jan 2010, Justin M. Streiner wrote: > The first thing you need to do is test the fiber with an OTDR. If you > don't have one, you can probably contract a local cabling company to > test it for you. Why would you want an OTDR report on the fiber, when an attenuation report is probably more accurate? OTDR is good for locating WHERE a problem is, but if you're seeing .2 dB/km attenuation end-to-end, there is little reason to break out the OTDR. Also, for 1G there is little reason to worry about dispersion mentioned in the thread, receive power is basically the only thing to worry about. -- Mikael Abrahamsson email: swmike at swm.pp.se From rene.avi at gmx.net Sat Jan 2 05:35:15 2010 From: rene.avi at gmx.net (Rene Avi) Date: Sat, 02 Jan 2010 12:35:15 +0100 Subject: dark fiber and sfp distance limitations In-Reply-To: <3c3e3fca1001011710l5b1cb5dasb14dc5b1c35fb48@mail.gmail.com> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> <3c3e3fca1001011710l5b1cb5dasb14dc5b1c35fb48@mail.gmail.com> Message-ID: <4B3F2F73.1010402@gmx.net> On 02.01.2010 02:10, William Herrin wrote: > On Fri, Jan 1, 2010 at 7:24 PM, ML wrote: >> Pardon my ignorance in this area but is too much to ask for OTDR data before >> signing contracts? In addition to data on the make of the fiber if you >> wanted to do xWDM in the future. > > Yes, it's too much to ask. They won't splice your path until you sign > the contracts and you can't get useful OTDR and loss readings until > the fiber is spliced. In my experience the fiber splice/patch-teams have quite accurate estimations on the overall attenuation of unprovisioned paths. They know the distance (0.25dB/km for G.652 @ 1550nm), the number of connectors (0.35dB per plug average here) and splices (0.1dB/spice). YMMV though. We add +20% safety, include an escape clause wherever possible and cross our fingers. With regards to suggested EDFA amplification tricks and similar: If the requirement is not > 150km at 1G or 80km at 10G/DWDM then I personally strongly disencourage the use of optical amps. 200km / 41dB 1G SFPs are available with costs way below dual EDFAs plus spare, and the chance for the untrained to get eye damages in the process of implementation is far less. So put some laser googles at around 400 USD/each to the purchase list. If one decides to do so then add a post-amplifier on each *end* of the fiber link to increase the signal before hitting the receiver, and do not pump in star-wars class laser power at the beginning ;) . Cheers, -- Rene Avi next layer Telekommunikationsdienstleistungs- und Beratungs GmbH Mariahilfer Guertel 37/7 | A-1150 Wien | FB 257486g | HG Wien tel: +43 664 31764 00 | fax: +43 517649 | web: www.nextlayer.at my layers: Fiber/Metro | D/CWDM | Cisco | Juniper | I/BGP | MPLS From ras at e-gerbil.net Sat Jan 2 06:22:03 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 2 Jan 2010 06:22:03 -0600 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3F2F73.1010402@gmx.net> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> <3c3e3fca1001011710l5b1cb5dasb14dc5b1c35fb48@mail.gmail.com> <4B3F2F73.1010402@gmx.net> Message-ID: <20100102122203.GW75640@gerbil.cluepon.net> On Sat, Jan 02, 2010 at 12:35:15PM +0100, Rene Avi wrote: > With regards to suggested EDFA amplification tricks and similar: If > the requirement is not > 150km at 1G or 80km at 10G/DWDM then I personally > strongly disencourage the use of optical amps. 200km / 41dB 1G SFPs > are available with costs way below dual EDFAs plus spare, and the > chance for the untrained to get eye damages in the process of > implementation is far less. So put some laser googles at around 400 > USD/each to the purchase list. If one decides to do so then add a > post-amplifier on each *end* of the fiber link to increase the signal > before hitting the receiver, and do not pump in star-wars class laser > power at the beginning ;) . Depends where you buy your EDFAs, I suspect you could probably get them for less than the cost of a single channel of super long reach optics if you tried hard enough. If you needed to add DWDM later on, and/or dispersion compensation for 10G links the EDFAs will be needed anyways, so sometimes it just makes sense to solve the problem once with an amp rather than trying to solve it on a per-channel basis. You're also vastly exagerating the power of what are effectively metro reach amps, you're really in no danger of making an eye hazard unless you start slapping on ultra long-haul 1500+km transport gear with class 3B lasers (i.e. you're in far more danger from someone with a green laser pointer ordered from the Internet :P). Remember that 1550nm is infrared and very effectively filtered by the human eye, so even a +17dBm output EDFA (the max output for most metro systems) is still going to be class 1M and effectively safe as long as you don't stare at it in a microscope. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From iljitsch at muada.com Sat Jan 2 07:08:25 2010 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jan 2010 14:08:25 +0100 Subject: 2009 IPv6 Address Use Report Message-ID: <101C15D9-2D59-49A9-9781-91EC54CCC004@muada.com> [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: http://www.bgpexpert.com/addrspace-ipv6-2009.php ] 2009 IPv6 Address Use Report Since 2005, I've been compiling an IPv4 address use report every year. With the start of the new decade, this is a good moment to start doing the same thing for IPv6. http://www.bgpexpert.com/addrspace-ipv6.php shows the amount of IPv6 space given out by RIR and by year, while http://www.bgpexpert.com/ipv6addressespercountry.php shows the amount of IPv6 address space by country. Both these pages are updated weekly from the delegation data that the RIRs publish on their FTP servers. 2008 saw a huge increase in the amount of IPv6 space given out and then a big drop in 2009 (amounts of IPv6 address space in the equivalent of /32s): 1999 10.88 /32s in 17 blocks 2000 19.75 /32s in 32 blocks 2001 33.13 /32s in 61 blocks 2002 156.75 /32s in 271 blocks 2003 261.38 /32s in 290 blocks 2004 13340.63 /32s in 295 blocks 2005 26985.00 /32s in 245 blocks 2006 9798.00 /32s in 243 blocks 2007 6687.01 /32s in 491 blocks 2008 81012.02 /32s in 886 blocks 2009 1091.03 /32s in 1280 blocks However, this is not the complete picture. The large number for 2008 is the result of two unusual events. The first one is LACNIC's delegation of the 2804::/16 block to the Brazilian national internet registry (NIR). At some point in the future, the delegation records will not show such blocks as "used" in their entirety anymore. Also, ARIN delegated 14 /22 blocks within the range 2608::/13 to the US Department of Defense. With these two artifacts removed, the amount of IPv6 space given out per year looks like this: 1999 11.00 /32s in 17 blocks 2000 20.00 /32s in 32 blocks 2001 33.00 /32s in 61 blocks 2002 157.00 /32s in 271 blocks 2003 261.00 /32s in 290 blocks 2004 13341.00 /32s in 295 blocks 2005 26985.00 /32s in 245 blocks 2006 9798.00 /32s in 243 blocks 2007 6687.00 /32s in 491 blocks 2008 1140.00 /32s in 871 blocks 2009 1091.00 /32s in 1280 blocks So the number of blocks given out keeps increasing, but their size is going down. There are two reasons for this: roughly between 2004 and 2006, RIPE and APNIC gave out some very large blocks to some very large ISPs. They mostly stopped doing that. And provider independent blocks started to be allowed and are getting more and more popular. These are the /32 - /35 allocations. /32 is the minimum block size given out to ISPs, this used to be /35. So this view shows the numbers of small-to-medium sized ISPs obtaining IPv6 address space: 1999 11.00 /32s in 17 blocks 2000 20.00 /32s in 32 blocks 2001 33.00 /32s in 55 blocks 2002 157.00 /32s in 254 blocks 2003 223.00 /32s in 251 blocks 2004 235.00 /32s in 241 blocks 2005 217.00 /32s in 217 blocks 2006 186.00 /32s in 186 blocks 2007 351.00 /32s in 351 blocks 2008 734.00 /32s in 734 blocks 2009 1011.00 /32s in 1013 blocks These are the blocks larger than /32 that go to large ISPs (excluding the BR NIR and DoD blocks): 2003 38.00 /32s in 3 blocks 2004 13106.00 /32s in 9 blocks 2005 26768.00 /32s in 13 blocks 2006 9612.00 /32s in 14 blocks 2007 6336.00 /32s in 8 blocks 2008 406.00 /32s in 7 blocks 2009 80.00 /32s in 4 blocks And these are the blocks smaller than /35, which are now mostly provider independent blocks, but also "critical infrastructure", such as root servers get a /48 block: 2001 0.00 /32s in 6 blocks 2002 0.00 /32s in 17 blocks 2003 0.00 /32s in 36 blocks 2004 0.00 /32s in 45 blocks 2005 0.00 /32s in 15 blocks 2006 0.00 /32s in 43 blocks 2007 0.00 /32s in 132 blocks 2008 0.00 /32s in 130 blocks 2009 0.00 /32s in 263 blocks So after a small dip in 2006, the number of small-to-medium sized ISPs obtaining IPv6 address space shows a steady upward trend, but apparently the very large ISPs either already got their IPv6 address space, are not focussing on IPv6 right now, are starting with a small block (or several small blocks), or a combination of all of these factors. Even with the BR NIR and DoD blocks included, the (equivalent of) 39395.56 /32s given out in 4111 blocks is only 0.026% of the 536870912 possible /32s in the currently defined global unicast space (2000::/3). For comparison, the number of IPv4 blocks given out is 99562. From rene.avi at gmx.net Sat Jan 2 08:22:39 2010 From: rene.avi at gmx.net (Rene Avi) Date: Sat, 02 Jan 2010 15:22:39 +0100 Subject: dark fiber and sfp distance limitations In-Reply-To: <20100102122203.GW75640@gerbil.cluepon.net> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> <3c3e3fca1001011710l5b1cb5dasb14dc5b1c35fb48@mail.gmail.com> <4B3F2F73.1010402@gmx.net> <20100102122203.GW75640@gerbil.cluepon.net> Message-ID: <4B3F56AF.7070505@gmx.net> On 02.01.2010 13:22, Richard A Steenbergen wrote: > On Sat, Jan 02, 2010 at 12:35:15PM +0100, Rene Avi wrote: >> With regards to suggested EDFA amplification tricks and similar: If >> the requirement is not > 150km at 1G or 80km at 10G/DWDM then I personally >> strongly disencourage the use of optical amps. 200km / 41dB 1G SFPs >> are available with costs way below dual EDFAs plus spare, and the >> chance for the untrained to get eye damages in the process of >> implementation is far less. So put some laser googles at around 400 >> USD/each to the purchase list. If one decides to do so then add a >> post-amplifier on each *end* of the fiber link to increase the signal >> before hitting the receiver, and do not pump in star-wars class laser >> power at the beginning ;) . > > Depends where you buy your EDFAs, I suspect you could probably get them > for less than the cost of a single channel of super long reach optics if > you tried hard enough. Respectfully disagree here - been there (googled^H^Hmarket research, talked to both manufactures and resellers for the last year), bought sample and went through lab tests. Still was unable to find trustful/working EDFAs near the cost of a pair of 40dB SFPs. 200km SFPs are even cheaper than 'original' Cisco CWDM-SFPs (standard 80km). We have them on stock for resale (no commercials intended here), so this price indication is near real-time ;) > If you needed to add DWDM later on, and/or > dispersion compensation for 10G links the EDFAs will be needed anyways, > so sometimes it just makes sense to solve the problem once with an amp > rather than trying to solve it on a per-channel basis. It depends on the requirement - of course. When Mike is heading for 10G DWDM demand levels he will probably have to amplify and cromatic-disperse-compensate with 120km G.652 (depending on the transceiver type) in any case. There are plenty of commercial solutions available for such spans, or he can try a building-block approach. My point is to skip EDFAs in a single 1G 120km fiber setup for commercial aspects, let alone technical reasons (complexity, safety), if there is no requirement for more bandwidth. IMHO even with multiple 1G CWDM-style setups, but your mileage may of course vary. > You're also vastly exagerating the power of what are effectively metro > reach amps, you're really in no danger of making an eye hazard unless > you start slapping on ultra long-haul 1500+km transport gear with class > 3B lasers In Mikes scenario this might be as a +10dB pre-amp would do the trick with low power, but a post-amp (+17dB gain with levels around -20..-30dBm to get some additional power budget) is what I would use if EDFAs are a stringent requirement. Most new long-haul transport systems have an automatic power-off feature for optical protection (e.g.the splice teams after a fiber cut/disconnect) now because of this. > (i.e. you're in far more danger from someone with a green > laser pointer ordered from the Internet :P). Agreed, but failed to save the whales - http://www.youtube.com/watch?v=Tuxf2xJ08Cc > Remember that 1550nm is > infrared and very effectively filtered by the human eye, so even a > +17dBm output EDFA (the max output for most metro systems) is still > going to be class 1M and effectively safe as long as you don't stare at > it in a microscope. Or stare in the beam at 500mW/27dBm without noticing because it is infrared, and there is no eyelid closure reflex. I tend not to take chances for my colleagues and me but as common knowledge says it is everyones own decision to look into the laser with the remaining good eye. Cheers, -- Rene Avi next layer Telekommunikationsdienstleistungs- und Beratungs GmbH Mariahilfer Guertel 37/7 | A-1150 Wien | FB 257486g | HG Wien tel: +43 664 31764 00 | fax: +43 517649 | web: www.nextlayer.at my layers: Fiber/Metro | D/CWDM | Cisco | Juniper | I/BGP | MPLS From carlos at race.com Sat Jan 2 10:08:35 2010 From: carlos at race.com (Carlos Alcantar) Date: Sat, 2 Jan 2010 08:08:35 -0800 Subject: dark fiber and sfp distance limitations Message-ID: <859604546CD1FF488BDB6EA94C896AFBAC3851@racexchange.race.local> In my experience in leasing dark fiber strands over long distance the providers usually give the option for regen colo space. And in some cases they wanted to know full specs of the equipment you are going to be using so there is no questions if it will work or not. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos at race.com -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Friday, January 01, 2010 2:53 PM To: nanog at nanog.org Subject: dark fiber and sfp distance limitations I am looking at the possibility of leasing a ~70 mile run of fiber. I don't have access to any mid point section for regeneration purposes, and so I am wondering what the chances that a 120km rated SFP would be able to light the path and provide stable connectivity. There are a lot of unknowns including # of splices, condition of the cable, or the actual dispersion index or other properties (until we actually get closer to leasing it). Its spare telco fibers in the same cable binder they are using interoffice transport, but there are regen huts along the way so it works for them but may not for us, and 'finding out' is potentially expensive. How would someone experienced go about determining the feasibillity of this concept and what options might there be? Replies online or off would be appreciated. Thanks. From mksmith at adhost.com Sat Jan 2 11:07:52 2010 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 02 Jan 2010 09:07:52 -0800 Subject: dark fiber and sfp distance limitations In-Reply-To: Message-ID: On 1/2/10 2:58 AM, "Mikael Abrahamsson" wrote: > On Fri, 1 Jan 2010, Justin M. Streiner wrote: > >> The first thing you need to do is test the fiber with an OTDR. If you >> don't have one, you can probably contract a local cabling company to >> test it for you. > > Why would you want an OTDR report on the fiber, when an attenuation report > is probably more accurate? OTDR is good for locating WHERE a problem is, > but if you're seeing .2 dB/km attenuation end-to-end, there is little > reason to break out the OTDR. If I was of the opinion that the telco in the original message would act upon output data to clean up fibers/jumpers/splices, then the OTDR is the way to go because you can show them exactly where the issues are in the entire length of fiber. If the telco isn't going to make any modifications then an optical power meter would probably be sufficient. Either you can hit the distance in your loss budget or not. Mike From streiner at cluebyfour.org Sat Jan 2 12:37:14 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 2 Jan 2010 13:37:14 -0500 (EST) Subject: dark fiber and sfp distance limitations In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: On Sat, 2 Jan 2010, Mikael Abrahamsson wrote: > On Fri, 1 Jan 2010, Justin M. Streiner wrote: > >> The first thing you need to do is test the fiber with an OTDR. If you >> don't have one, you can probably contract a local cabling company to test >> it for you. > > Why would you want an OTDR report on the fiber, when an attenuation report is > probably more accurate? OTDR is good for locating WHERE a problem is, but if > you're seeing .2 dB/km attenuation end-to-end, there is little reason to > break out the OTDR. Some OTDRs (or, more correctly, fiber test sets that include OTDR capabilities) are multi-function devices that will show you the overall length (assuming the span is not broken somewhere in the middle), of the span, plus attenuation and reflections (spikes) at your desired wavelength in one complete package. I'm a big believer in running my own tests when possible, and not just relying on $provider's word. It also allows me to verify what their engineering reports tell me about the condition of a span. jms From nick at foobar.org Sat Jan 2 12:42:00 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 02 Jan 2010 18:42:00 +0000 Subject: dark fiber and sfp distance limitations In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: <4B3F9378.20000@foobar.org> On 02/01/2010 18:37, Justin M. Streiner wrote: > I'm a big believer in running my own tests when possible, and not just > relying on $provider's word. It also allows me to verify what their > engineering reports tell me about the condition of a span. +1 There's nothing like having hard data to shove in front of the noses of connectivity providers (whether colo / cross-connect or metro dark fibre providers) when unexplained problems suddenly start happening for no apparent reason. "This is what it was like before and this is what it's like now, and this ledge here shows that the problem is on a segment that you manage. Please explain". Nick From dot at dotat.at Sat Jan 2 13:05:40 2010 From: dot at dotat.at (Tony Finch) Date: Sat, 2 Jan 2010 19:05:40 +0000 Subject: RBN and it's spin-offs In-Reply-To: <6cd462c00912302036v3ca7539fwef9e931c04f330c4@mail.gmail.com> References: <47c4bafa707aaa4f8d501f034c2abaf7@mail.dessus.com> <6cd462c00912302012v773dba48x66a01c90b9c6590@mail.gmail.com> <1262232825.14004.45.camel@petrie> <75cb24520912302025k406732dfrc20fcf556801215b@mail.gmail.com> <6cd462c00912302036v3ca7539fwef9e931c04f330c4@mail.gmail.com> Message-ID: On Wed, 30 Dec 2009, Paul Ferguson wrote: > > ...but as of the first of the year, alas, Krebs is no longer working for WaPo: You can continue to follow his work at http://www.krebsonsecurity.com/ Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From surfer at mauigateway.com Sat Jan 2 16:48:38 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 2 Jan 2010 14:48:38 -0800 Subject: Consumer-grade dual-homed connectivity options? Message-ID: <20100102144838.9A591564@resin15.mta.everyone.net> --- paul.w.bennett at gmail.com wrote: From: "Paul Bennett" At home, I currently run two DSL lines. Right now, we just have two separate LANs, one connected to each line, with my wife's devices attached to one, and my devices attached to the other. For a while now, I've been thinking about setting up a load-balancing routing solution to give both of us access to both lines. --------------------------------------------------- Maybe www.xincom.com/products.php will work? scott From sking at kingrst.com Sat Jan 2 17:14:32 2010 From: sking at kingrst.com (Steven King) Date: Sat, 02 Jan 2010 18:14:32 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <20100102144838.9A591564@resin15.mta.everyone.net> References: <20100102144838.9A591564@resin15.mta.everyone.net> Message-ID: <4B3FD358.1070609@kingrst.com> You would need at least one router for this. Personally I would connect both DSL modems into a small Cisco router or multi-layer switch. Use that router as the default gateways for each LAN and have two static routes as the default gateway on the router to specify each DSL line. This would allow for load balancing each connection. Although, you run into the issue of needing PAT on both lines. This wouldn't be complex, but would need to be handled by the router as well. I am not sure about asymmetric paths though. Depending on the device, it may handle this differently, and there is no guarantee that the source of your traffic will be from the same connection all the time to the destination. This would cause connectivity issues. There really is no elegant solution to that without having a full routing table of the Internet and 2 separate providers. Others on this list may have a solution to that issue off the top of their heads, or have done this themselves. On 1/2/10 5:48 PM, Scott Weeks wrote: > > --- paul.w.bennett at gmail.com wrote: > From: "Paul Bennett" > > At home, I currently run two DSL lines. Right now, we just have two > separate LANs, one connected to each line, with my wife's devices attached > to one, and my devices attached to the other. For a while now, I've been > thinking about setting up a load-balancing routing solution to give both > of us access to both lines. > --------------------------------------------------- > > > Maybe www.xincom.com/products.php will work? > > scott > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From swmike at swm.pp.se Sat Jan 2 17:19:04 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 3 Jan 2010 00:19:04 +0100 (CET) Subject: dark fiber and sfp distance limitations In-Reply-To: References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: On Sat, 2 Jan 2010, Justin M. Streiner wrote: > Some OTDRs (or, more correctly, fiber test sets that include OTDR > capabilities) are multi-function devices that will show you the overall > length (assuming the span is not broken somewhere in the middle), of the > span, plus attenuation and reflections (spikes) at your desired wavelength in > one complete package. Well, that I can understand, what I can't understand is why someone would *ONLY* do OTDR. Attenuation testing end-to-end (as opposed to classic OTDR that do the testing from single end) is needed for accurate measurements, and if it shows something strange, then it's warranted to break out the OTDR. If your equipment can do both in one go, fine. > I'm a big believer in running my own tests when possible, and not just > relying on $provider's word. It also allows me to verify what their > engineering reports tell me about the condition of a span. I guess it's all a matter of how much effort you want to put into provisioning. Personally I'm happy enough if the DOM readings (indicating attenuation) on the optics seem reasonable considering the distance of the fiber. If they seem strange, then yes, by all means, break out the testing kit. -- Mikael Abrahamsson email: swmike at swm.pp.se From kevin.hodle at gmail.com Sat Jan 2 17:36:12 2010 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Sat, 2 Jan 2010 17:36:12 -0600 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E7CB1.2090608@tiedyenetworks.com> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> Message-ID: <9639597a1001021536w2dfc6071g1b7144519c3b378c@mail.gmail.com> On Fri, Jan 1, 2010 at 4:52 PM, Mike wrote: > I am looking at the possibility of leasing a ~70 mile run of fiber. I don't > have access to any mid point section for regeneration purposes, and so I am > wondering what the chances that a 120km rated SFP would be able to light the > path and provide stable connectivity. There are a lot of unknowns including > # of splices, condition of the cable, or the actual dispersion index or > other properties (until we actually get closer to leasing it). Its spare > telco fibers in the same cable binder they are using interoffice transport, > but there are regen huts along the way so it works for them but may not for > us, and 'finding out' is potentially expensive. How would someone > experienced go about determining the feasibillity of this concept and what > options might there be? Replies online or off would be appreciated. I second the recommendation that you request OTDR traces from whomever you are leasing the glass from, and further request traces for each strand in *both* directions (a end to z end, z end to a end) at multiple wavelengths, say 1530nm-1640nm at a maximum of 200GHz wavelength spacing to properly identify potential problem locations in the future when you want to build out a 10GE metro DWDM solution (You really do want to know about that old mechanical splice 20km into your run, etc). An OTDR will provide you with granular loss/gain event details for your entire span, while a power meter/light source will only tell you your overall span loss. While your fiber provider may not pony up OTDR results until after you've executed the contract, they should be able to give you a rough estimate of the total loss (in dB for a 1550nm signal) for the span you are looking at leasing, and you can build provisions into your contract that enforce an absolute maximum loss on the span, in which case the provider will be forced to take necessary actions to replace old poorly executed splices with fusion splices, isolate and correct bends, etc. As most have pointed out - EDFA should not be required for a 1GE single channel solution, and probably would not be required for a simple 1GE CWDM setup either. Once you graduate to an active 10GE DWDM solution EDFA's will be more of a necessity (possibly with dispersion compensation, depending on your vendor this may be an entirely separate shelf module or may be build into the amp card). The addition of EDFA's in a multi-channel solution also adds complexity (if you want to build a scalable/cost effective solution). Most EDFA's have a maximum and minimum per-channel input power, and ideally you would want to have each channel near the same power level before hitting the EDFA. Depending on your gear, topological complexity, etc this may require the use of an optical spectrum analyzer to verify individual channel power levels so the correct amount of attenuation can be added to each channel before it hits the EDFA, however for a single point to point span this will probably not be a concern. -- Cheers, Kevin ================================================================ Kevin Hodle | http://www.linkedin.com/in/kevinhodle PGP Key ID | fingerprint 0x803F24BE | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ From ops.lists at gmail.com Sat Jan 2 22:26:03 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 3 Jan 2010 09:56:03 +0530 Subject: Are the Servers of Spamhaus.rg and blackholes.us down? In-Reply-To: <20091231081124.18fa9f53@jpeach-desktop.1425mad.mountsinai.org> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <20091231081124.18fa9f53@jpeach-desktop.1425mad.mountsinai.org> Message-ID: If our friend here is checking for spamhaus.rg he's out of luck. I am sure he'll have better luck checking for spamhaus.ORG instead --srs On Thu, Dec 31, 2009 at 6:41 PM, John Peach wrote: > On Thu, 31 Dec 2009 12:28:41 +0100 (CET) > Raymond Dijkxhoorn wrote: > >> > Are this Blacklistservers since x-mas down. We receive in the last >> > days many errors from this servers... >> > blackholes.us has been non-existent for over a year. Their netblocks > Can't help you with spamhaus... From ops.lists at gmail.com Sat Jan 2 22:38:35 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 3 Jan 2010 10:08:35 +0530 Subject: Article on spammers and their infrastructure In-Reply-To: <4B3CD214.30101@nic-naa.net> References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <4B3CD214.30101@nic-naa.net> Message-ID: While not at all touching the accuracy of knujon's stats with a bargepole, it would be interesting if some process were developed to deaccredit or otherwise kill off the shell registrars .. and the bogus LIRs (which is how the thread started). On Thu, Dec 31, 2009 at 10:02 PM, Eric Brunner-Williams wrote: > > [1] shell registrars exist for another exploit, to maximize race contention > results for the VGRS drop pool, the acquisition of expired names which have > "name" value or residual traffic monitization value. Four companies control > 318 US domiciled ICANN accreditations: eNom (116), Directi/PDR (47), Dotster > (51), and Snapnames (104). Source: http://www.knujon.com/registrars/ -- Suresh Ramasubramanian (ops.lists at gmail.com) From msaqib at gmail.com Sun Jan 3 07:28:09 2010 From: msaqib at gmail.com (Saqib Ilyas) Date: Sun, 3 Jan 2010 18:28:09 +0500 Subject: Regarding SLA violations Message-ID: <262b67201001030528k3a3a630at43b6f43cccaff7de@mail.gmail.com> Hi NANOGers I request a few moments of your time for your invaluable input on the following questions that I am wondering about: 1. a) How often does a service provider network incur SLA violations? b) Which SLA parameter is the most probably violated (bandwidth, delay, packet loss or others)? c) Apart from link failures, what are other likely causes of this violation? 2. If a service provider provisions a 2 Mbps data pipe between two customer sites, how often does the customer traffic go beyond 2 Mbps? Thanks and best regards -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From brunner at nic-naa.net Sun Jan 3 10:54:07 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 03 Jan 2010 11:54:07 -0500 Subject: Article on spammers and their infrastructure In-Reply-To: References: <20091222102709.GD81417@macbook.catpipe.net> <60B0F2124D07B942988329B5B7CA393D020BE875F6@mail2.FireEye.com> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <4B3CD214.30101@nic-naa.net> Message-ID: <4B40CBAF.50306@nic-naa.net> On 1/2/10 11:38 PM, Suresh Ramasubramanian wrote: > ... it would be interesting if some process were developed to > deaccredit or otherwise kill off the shell registrars Suresh, Why? ICANN accreditation provides the registrar with a right to attempt OT&E with registries, the Verisign operated .com registry in particular, and with that, the right to specify a range of addresses from which the .com registy EPP server must accept connections. That is the asset. Every day "mumble.com" is dropped by the .com registry and every day registrars "race" to register "mumble.com". For some reason "mumble.com" has value not present in "mumble.bar", where "bar" takes on some 20 values other than "com", possibly because "mumble" is a generic or hyphenated concatenation of a generic and some other string, possibly also a generic, possibly because strlen("mumble") is less than 5. If every registrar has the right to a fixed number of connections, or "threads", at the .com registry, then the probability of acquisition of "mumble.com" is 1/N, where N is the number of registrars competing to register "mumble.com". Note that this might not be sufficient to motivate investment in a "secondary market", in the abstract, however the verisign registry, and others, identified the "secondary market" as having high value and attempted to obtain non-random distribution of secondary registrations. Therefore, while the value of "threads" was significantly greater than the cost of ICANN accreditation (a subject of note in its own right), it was a rational economic activity to form registrar legal entities, obtain ICANN accreditation, and rent the "threads" to entities which specialized in the "secondary market", that is, in collecting "back orders" on "mumble.com" from entities seeking to become the registrant of "mumble.com", presumably ranked by value (bids at auction), and execution of registrations for "mumble.com" in a race environment. That's auction to 3pm minus some delta, and race at 3pm minus some epsilon to 3pm plus some epsilon. So, a well-ordered sequence sensor and slots on a roulette wheel. Clearly, the more slots on the roulette wheel, the greater the likelihood of winning. So, the root cause for shell registrars is the value of expired names, and the association of acquisition resources with accreditation. Value arises from (a) strings which can be repurposed economically (I claim that should Qualcom forget to renew "q.com" that "q.com" can be repurposed as something other than a domain name for a communications goods and services vendor), and (b) strings which cannot be repurposed economically, but have some fungible value, aka "traffic". Now, shell registrars are a pain in the ass, not for operational reasons, but because every time someone wants to say something stupid and get away with it they say " of registrars". For example, at the ICANN Seoul meeting an unidentified male (in the transcript) who I recall was Dan Halloran, ICANN's Deputy General Counsel, said, while discussing the proposed new gTLD registry agreement (note, it isn't called a contract): "... the central idea is still there that ICANN does retain the right to modify the agreement..." and a minute later "... the point is there's 900 registrars and ... We don't have to go individually and negotiate bilaterally with each registrar." Source, transcript [1]. So the number of shell registrars is offered, by ICANN's DGC, and presumably by ICANN's GC (John Jeffrey) as well, as an absolute bar to contractual distinguishment. Registrars can be "bad" because they fail to pay ICANN (the commonest form of registrar deaccreditation) or because they aren't responsive to email or because they are claimed to be in breech of some specific term in the current accreditation agreement. Other than that, it is ICANN's consistent position of record that registrars cannot be distinguished in contract since the divestiture of Network Solutions (registrar) by Verisign (registry). Now to me (Eric Brunner-Williams, hat=="operator of ICANN accredited registrar #439 and CTO of ICANN accredited registrar #15 and operator of the sponsored gTLD .cat and .museum" registries for their respective ICANN contracted sponsors), the inability to distinguish, in contract, between an application advanced by the RBN and the IRC is ... a pain in the ass. CORE's "business" is socially useful, socially responsible registries, its been our business since Jon Postel and others [2] drew up the IAHC-MOU [3], forming CORE. We'd like to see a contract for .com's clones, where "policy" is completely defined by first $6 offered, and a contract for .cat's kittens, where "policy" is consistent with the language in section 3, subsection 2, of RFC 1591. The IRC contacted CORE (thanks to the ICANN staffer who suggested us to them!) for a .red-{cross,crescent} (Latin and Arabic scripts) but because ICANN won't create contractual constructs now, having done so in the past (the initial 7-10 round was partitioned between what is now called "standard" (biz/info/name/pro) and "sponsored" (aero/coop/museum), and the 2003 round was sponsored), the IRC (and CORE, and all of CORE's other registry partners, from the Provincial Government of Quebec to the Government of the City of Paris) has to wait until ICANN's crafted an evaluation process capable of evaluating every currently imagined scheme the RBN (or any other rational economic actor) puts forward. Oddly enough, this appears to require unbounded time, and naturally enough, someone on NANOG will opine that one or more of, particularly the last item of this list -- {dnssec, ipv6, idns for ccTLDs, new gTLDs (ADH or IDN)} is "a bad thing". As an Indian, I will simply observe that the partition of Indian Countries into "Canada", "US", ... is suboptimal, and the further partition into "native" namespaces under each of the iso3166 associated namespaces is also suboptimal. We could do better, but even if the nsn.us namespace, to pick one well-ignored example, were turned over to me personally, that wouldn't meet all the needs of two of the three tribes I have cultural and/or political association with, which exist "in" both the United States and Canada. That is, I offer the claim that at least one TLD ought to exist, a claim made to Jon prior to the Green and White Papers. I expect the time from request to delegation will be 20 years, assuming the unbounded time requirement becomes bounded in 5 or so years from the present. Shell registrars are not, generally, the source of primary registrations of arbitrarily abusive intent. That problem lies elsewhere and is adequately documented. > .. and the bogus > LIRs (which is how the thread started). This has been a tutorial on why shell registrars are not the source of operational issues that could reasonably be characterized as problems. Problematic use of the DNS exists, but the registrar association is otherwise than to shell registrars. These are different exploits. Eric [1] http://sel.icann.org/meetings/seoul2009/transcript-gtld-registries-constituency-1-27oct09-en.pdf at pages 32 and 33, respectively. [2] ISOC, IANA, IAB, FNC, ITU, INTA, WIPO [3] http://www.gtld-mou.org/ From ms at mironet.ch Sun Jan 3 12:56:07 2010 From: ms at mironet.ch (Mathias Seiler) Date: Sun, 3 Jan 2010 19:56:07 +0100 Subject: Consumer-grade dual-homed connectivity options? References: Message-ID: <3C06E37C-3612-4190-A1FD-0F02B07B593E@mironet.ch> Hi Paul You can do this on a linux box with a pretty much basic kernel. I currently have a similar setup at home with a DSL and a cable line (from different providers). Here's the script I'm actually using: http://ocaholic.ch/download/multinat.txt Some packets are tagged with iptables (SSH as an example) because I want it to prefer the DSL connection. You can do pretty interesting things with it, even per-packet round-robin distribution ? which is a Bad Idea? though. If you want it to fail-over automatically you need to patch the kernel etc. You'll find all information on http://lartc.org/ (especially on http://lartc.org/howto/lartc.rpdb.multiple-links.html) and here: http://www.ssi.bg/~ja/#routes This setup is running for about a year now and it does this quite well. Regards Begin forwarded message: >> >> --- paul.w.bennett at gmail.com wrote: >> From: "Paul Bennett" >> >> At home, I currently run two DSL lines. Right now, we just have two >> separate LANs, one connected to each line, with my wife's devices attached >> to one, and my devices attached to the other. For a while now, I've been >> thinking about setting up a load-balancing routing solution to give both >> of us access to both lines. >> --------------------------------------------------- >> Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler at mironet.ch www.mironet.ch From brunner at nic-naa.net Sun Jan 3 15:11:33 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 03 Jan 2010 16:11:33 -0500 Subject: Does anyone have the Cyber Storm II Exercise Report? Message-ID: <4B410805.709@nic-naa.net> I'm sure someone must, but google as I have I only find "fact sheets" (marcom collateral) and reports to Congress. Thanks in advance! Eric From ops.lists at gmail.com Sun Jan 3 19:37:56 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 4 Jan 2010 07:07:56 +0530 Subject: Article on spammers and their infrastructure In-Reply-To: <4B40CBAF.50306@nic-naa.net> References: <20091222102709.GD81417@macbook.catpipe.net> <6cd462c00912222212v21b6e5fai7611818134a702f5@mail.gmail.com> <75cb24520912222258y7bcf198g479b6c34db23ed05@mail.gmail.com> <20091230143453.GA463@gsp.org> <4B3CD214.30101@nic-naa.net> <4B40CBAF.50306@nic-naa.net> Message-ID: On Sun, Jan 3, 2010 at 10:24 PM, Eric Brunner-Williams wrote: > On 1/2/10 11:38 PM, Suresh Ramasubramanian wrote: >> ... it would be interesting if some process were developed to >> deaccredit or otherwise kill off the shell registrars > > Suresh, Why? My comment was more in the context of this thread's original topic - killing off bogus spam / botnet operations that become registrars (and/or registrar resellers) who buy an outsourced instance of one of the "registrar in a box" services, and are immediately in business. Though, you might want to prevent shell registrars for the same reasons that auctions try to weed out shill bidders. And while it is a rational economic idea for a bidder to game an auction by setting up shills, the auctioneer and the other bidders lose out in the end. > Now, shell registrars are a pain in the ass, not for operational reasons, > but because every time someone wants to say something stupid and get away > with it they say " of registrars". That too of course. Reminds you of Tammanny Hall sometimes? :) > Shell registrars are not, generally, the source of primary registrations of > arbitrarily abusive intent. That problem lies elsewhere and is adequately > documented. Wasn't talking about shell entities setup by various registrars for drop catching and such. Though as I pointed out, those could be weeded out for fairly sensible economic reasons, for the same reasons such practices are discouraged in elections, auctions, rationing systems (like the depression era / WW-II food stamps system) etc. Was talking about totally bogus registrars that are "spammer sets up an LLC, said LLC submits all the paperwork to become a registrar, rents an instance of a DIY registrar service .. and starts doing roaring business with just one customer - the spammer) --srs From Paul.Martin at viatel.com Mon Jan 4 04:01:26 2010 From: Paul.Martin at viatel.com (Martin, Paul) Date: Mon, 4 Jan 2010 10:01:26 -0000 Subject: dark fiber and sfp distance limitations In-Reply-To: <9639597a1001021536w2dfc6071g1b7144519c3b378c@mail.gmail.com> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net><4B3E7CB1.2090608@tiedyenetworks.com> <9639597a1001021536w2dfc6071g1b7144519c3b378c@mail.gmail.com> Message-ID: <6E91D15697439543A9636FCA11BDA1C511235302@eghexch01.viatel.local> If you only want 1gig, then if the SP provides it, won't it be cheaper to simply get a 1gig circuit from them that hands off to you on a GigE port rather than pay for all the various higher spec equipment that you'd otherwise require? Paul. -----Original Message----- From: Kevin Hodle [mailto:kevin.hodle at gmail.com] Sent: 02 January 2010 23:36 To: Mike Cc: nanog at nanog.org Subject: Re: dark fiber and sfp distance limitations On Fri, Jan 1, 2010 at 4:52 PM, Mike wrote: > I am looking at the possibility of leasing a ~70 mile run of fiber. I don't > have access to any mid point section for regeneration purposes, and so I am > wondering what the chances that a 120km rated SFP would be able to light the > path and provide stable connectivity. There are a lot of unknowns including > # of splices, condition of the cable, or the actual dispersion index or > other properties (until we actually get closer to leasing it). Its spare > telco fibers in the same cable binder they are using interoffice transport, > but there are regen huts along the way so it works for them but may not for > us, and 'finding out' is potentially expensive. How would someone > experienced go about determining the feasibillity of this concept and what > options might there be? Replies online or off would be appreciated. I second the recommendation that you request OTDR traces from whomever you are leasing the glass from, and further request traces for each strand in *both* directions (a end to z end, z end to a end) at multiple wavelengths, say 1530nm-1640nm at a maximum of 200GHz wavelength spacing to properly identify potential problem locations in the future when you want to build out a 10GE metro DWDM solution (You really do want to know about that old mechanical splice 20km into your run, etc). An OTDR will provide you with granular loss/gain event details for your entire span, while a power meter/light source will only tell you your overall span loss. While your fiber provider may not pony up OTDR results until after you've executed the contract, they should be able to give you a rough estimate of the total loss (in dB for a 1550nm signal) for the span you are looking at leasing, and you can build provisions into your contract that enforce an absolute maximum loss on the span, in which case the provider will be forced to take necessary actions to replace old poorly executed splices with fusion splices, isolate and correct bends, etc. As most have pointed out - EDFA should not be required for a 1GE single channel solution, and probably would not be required for a simple 1GE CWDM setup either. Once you graduate to an active 10GE DWDM solution EDFA's will be more of a necessity (possibly with dispersion compensation, depending on your vendor this may be an entirely separate shelf module or may be build into the amp card). The addition of EDFA's in a multi-channel solution also adds complexity (if you want to build a scalable/cost effective solution). Most EDFA's have a maximum and minimum per-channel input power, and ideally you would want to have each channel near the same power level before hitting the EDFA. Depending on your gear, topological complexity, etc this may require the use of an optical spectrum analyzer to verify individual channel power levels so the correct amount of attenuation can be added to each channel before it hits the EDFA, however for a single point to point span this will probably not be a concern. -- Cheers, Kevin ================================================================ Kevin Hodle | http://www.linkedin.com/in/kevinhodle PGP Key ID | fingerprint 0x803F24BE | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ For more information about the Viatel Group, please visit www.viatel.com VTL (UK) Limited Registered in England and Wales Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR Company Registration No: 04287100 VAT Registration Number: 781 4991 88 THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. This message has been scanned for viruses and spam by Viatel MailControl - www.viatel.com From jared at puck.nether.net Mon Jan 4 06:03:27 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 4 Jan 2010 07:03:27 -0500 Subject: Does anyone have the Cyber Storm II Exercise Report? In-Reply-To: <4B410805.709@nic-naa.net> References: <4B410805.709@nic-naa.net> Message-ID: On Jan 3, 2010, at 4:11 PM, Eric Brunner-Williams wrote: > I'm sure someone must, but google as I have I only find "fact sheets" (marcom collateral) and reports to Congress. > > Thanks in advance! > Eric These are restricted to those that have signed a Trusted Agent Agreement for participation in the current Cyberstorm event. Ie: if you did CS1, you get access to stuff from CS1. If you did a CS2 TAA, you get access to stuff from CS2. This is to help keep the private data private. If you are interested in participating, you can email me the following info which I will forward to the team that runs the event: Company Name: Contact Name/Info: It's an imperfect system (as are many things) but CS3 is scheduled for fall 2010. The mid-term planning conference is coming up later this month. It's not too late to get involved! - Jared From tsands at rackspace.com Mon Jan 4 06:08:59 2010 From: tsands at rackspace.com (Tom Sands) Date: Mon, 4 Jan 2010 06:08:59 -0600 Subject: InterNAP FCP (again?) In-Reply-To: <98E72206041B1B408D3F92E91E80BF180766C393@slmail101.softlayer.local> References: <1262206718.6137.968.camel@mike-desktop> <98E72206041B1B408D3F92E91E80BF180766C393@slmail101.softlayer.local> Message-ID: <16153_1262606962_o04C9Gob016187_4B41DA5B.8050304@rackspace.com> I feel your pain, as I'm a little frustrated by the stance that Internap is taking on the FCP. We've used them for many years, back when there were numerous competitors to choose from. However, now that they are pretty much the only major player they seem to care less about the results and the customer. Like Ric, you can contact me off-line for details. -------------------------------------------------------------------------------- Tom Sands Chief Network Engineer Rackspace Hosting (210)312-4391 -------------------------------------------------------------------------------- Ric Moseley wrote: > Call me offline. > > Ric. > 214-442-0555 > > -----Original Message----- > From: Michael J McCafferty [mailto:mike at m5computersecurity.com] > Sent: Wednesday, December 30, 2009 2:59 PM > To: nanog > Subject: InterNAP FCP (again?) > > All, > I know this has been discussed to some degree before and I have > searched the archives. However is it seems in my previous posts to this > list about anything, the truly useful replies are the private replies > ones that don't make it to this list. > We are considering the InterNAP Flow Control Platform. Currently > we > have 3 transit providers but are adding one or two more and will also be > adding a connection to the Any2 exchange at One Wilshire. > The price is manageable, the reporting seems quite useful, but I > haven't seen it actually in action on my network. If it works as claimed > for managing commit levels, performance, etc. then I expect we'd be very > happy. The problem is that InterNAP does not want to do any acceptance > testing... all sales are final... and in my research on the web, I see a > few companies that have implemented the FCP and have either removed it > or switched to Avaya CNA (yes, I know it's going away). > Since InterNAP has pulled way from any kind of happiness > guarantee, I'd > very much like to hear from actual users of the FCP, happy and unhappy, > to help me feel better about signing the PO. > Does it do what it says it does for performance and managing > commit > levels? Do you feel it was worth the integration and money? Are you > happy with it? What size and shape is the network you used it on? Do you > have any additional thoughts to share regarding the FCP? > > Thanks! > Mike > Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From v.jones at networkingunlimited.com Mon Jan 4 08:10:05 2010 From: v.jones at networkingunlimited.com (Vincent C Jones) Date: Mon, 04 Jan 2010 09:10:05 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <4B3FD358.1070609@kingrst.com> References: <20100102144838.9A591564@resin15.mta.everyone.net> <4B3FD358.1070609@kingrst.com> Message-ID: <1262614205.5448.17.camel@X61.NetworkingUnlimited.nul> Most of the SOHO router vendors (Netgear, Linksys, etc) have a model targeted at this application. When this class of "dual homed" router first came out several years ago, they were notoriously unreliable, but I would hope they work better by now. A search on the term "ping based routing" should give you insight into the current state of affairs, although it will probably take some work because there is no standard terminology to describe the facility, and most implementations no longer rely on "ping" to do the job of detecting link status. A few limitations to keep in mind: 1 - These routers are targeted at home users, are cheap, and you don't get what you don't pay for. 2 - The job can be done using "real" routers (Cisco, Juniper, etc), but setup requires work and getting a solution that actually works can be tricky. 3 - Be wary of any advice that you get from anyone who has not actually done it on the box in question! There are many ways a solution which should work will fail miserably. For example, when I looked at this problem a few years ago for a client, the SOHO routers tended to lock up and require a power cycle every few days while Cisco IOS routers would not clear the NAT table when a link failed soft and tended to stop testing a link once it failed, requiring manual recovery. Good luck and have fun! -- Vincent C Jones Networking Unlimited, Inc. www.networkingunlimited.com On Sat, 2010-01-02 at 18:14 -0500, Steven King wrote: > You would need at least one router for this. > > Personally I would connect both DSL modems into a small Cisco router or > multi-layer switch. Use that router as the default gateways for each LAN > and have two static routes as the default gateway on the router to > specify each DSL line. This would allow for load balancing each connection. > > Although, you run into the issue of needing PAT on both lines. This > wouldn't be complex, but would need to be handled by the router as well. > > I am not sure about asymmetric paths though. Depending on the device, it > may handle this differently, and there is no guarantee that the source > of your traffic will be from the same connection all the time to the > destination. This would cause connectivity issues. There really is no > elegant solution to that without having a full routing table of the > Internet and 2 separate providers. Others on this list may have a > solution to that issue off the top of their heads, or have done this > themselves. > > > On 1/2/10 5:48 PM, Scott Weeks wrote: > > > > --- paul.w.bennett at gmail.com wrote: > > From: "Paul Bennett" > > > > At home, I currently run two DSL lines. Right now, we just have two > > separate LANs, one connected to each line, with my wife's devices attached > > to one, and my devices attached to the other. For a while now, I've been > > thinking about setting up a load-balancing routing solution to give both > > of us access to both lines. > > --------------------------------------------------- > > > > > > Maybe www.xincom.com/products.php will work? > > > > scott > > > > > From kevin.hodle at gmail.com Mon Jan 4 10:51:47 2010 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Mon, 4 Jan 2010 10:51:47 -0600 Subject: dark fiber and sfp distance limitations In-Reply-To: <6E91D15697439543A9636FCA11BDA1C511235302@eghexch01.viatel.local> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <9639597a1001021536w2dfc6071g1b7144519c3b378c@mail.gmail.com> <6E91D15697439543A9636FCA11BDA1C511235302@eghexch01.viatel.local> Message-ID: <9639597a1001040851u2104f22n25f38a4c3178c09f@mail.gmail.com> On Mon, Jan 4, 2010 at 4:01 AM, Martin, Paul wrote: > > If you only want 1gig, then if the SP provides it, won't it be cheaper > to simply get a 1gig circuit from them that hands off to you on a GigE > port rather than pay for all the various higher spec equipment that > you'd otherwise require? > > Paul. Yes, a carrier provided lit service (wavelength, EoMPLS) would obviously be less expensive than leasing dark for a single 1GE channel (especially for longer spans), but I'm assuming OP has already considered this and is going with a dark fiber option for one of the following reasons: A) Expected rapid growth in transfer volume, wherein a dark fiber solution provides the OP with the flexibility to rapidly upgrade to either a multi-channel xWDM 1GE, single channel 10GE, or xWDM 10GE solution immediately, as opposed to a lit solution where he would be restricted by the provisioning time line of the carrier (dark quickly becomes a more attractive solution than lit services as bandwidth needs increase) B) Specific business requirements (ie security concerns) that preclude the usage of 3rd party's network/transmission gear from carrying traffic deemed 'sensitive', 'confidential', etc. You fill in the blanks. The idea is laughable to many operators, but sometimes a board's ideal model of data security is not exactly in line with business and technical realities (Usually this means money in your pocket). -- Cheers, Kevin ================================================================ :: :: Kevin Hodle | http://www.linkedin.com/in/kevinhodle PGP Key ID | fingerprint 0x803F24BE | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE "Elegance is not a dispensable luxury but a factor that decides between success and failure. " -Edsgar Dijkstra ================================================================ From dts at senie.com Mon Jan 4 11:11:37 2010 From: dts at senie.com (Daniel Senie) Date: Mon, 4 Jan 2010 12:11:37 -0500 Subject: Consumer-grade dual-homed connectivity options? In-Reply-To: <1262614205.5448.17.camel@X61.NetworkingUnlimited.nul> References: <20100102144838.9A591564@resin15.mta.everyone.net> <4B3FD358.1070609@kingrst.com> <1262614205.5448.17.camel@X61.NetworkingUnlimited.nul> Message-ID: The SonicWALL firewall appliances have had decent multi-port NAT functionality for a long time. In the most recent software revision for the latest generation of appliances, they've extended this beyond 2 upstreams. The smaller units in the line also can use various 3G wireless cards and USB dongles to either load balance or do failover. Models range from SOHO-sized to large enterprise. I've used them myself for years, and installed them for clients. They are reliable and straightforward to configure. And yes, for full disclosure, I've been certified on their gear for a long time, and do resell it (also resell several other brands of networking gear). Dan On Jan 4, 2010, at 9:10 AM, Vincent C Jones wrote: > Most of the SOHO router vendors (Netgear, Linksys, etc) have a model > targeted at this application. When this class of "dual homed" router > first came out several years ago, they were notoriously unreliable, but > I would hope they work better by now. A search on the term "ping based > routing" should give you insight into the current state of affairs, > although it will probably take some work because there is no standard > terminology to describe the facility, and most implementations no longer > rely on "ping" to do the job of detecting link status. > > A few limitations to keep in mind: > > 1 - These routers are targeted at home users, are cheap, and you don't > get what you don't pay for. > > 2 - The job can be done using "real" routers (Cisco, Juniper, etc), but > setup requires work and getting a solution that actually works can be > tricky. > > 3 - Be wary of any advice that you get from anyone who has not actually > done it on the box in question! There are many ways a solution which > should work will fail miserably. For example, when I looked at this > problem a few years ago for a client, the SOHO routers tended to lock up > and require a power cycle every few days while Cisco IOS routers would > not clear the NAT table when a link failed soft and tended to stop > testing a link once it failed, requiring manual recovery. > > Good luck and have fun! > -- > Vincent C Jones > Networking Unlimited, Inc. > www.networkingunlimited.com > > > On Sat, 2010-01-02 at 18:14 -0500, Steven King wrote: >> You would need at least one router for this. >> >> Personally I would connect both DSL modems into a small Cisco router or >> multi-layer switch. Use that router as the default gateways for each LAN >> and have two static routes as the default gateway on the router to >> specify each DSL line. This would allow for load balancing each connection. >> >> Although, you run into the issue of needing PAT on both lines. This >> wouldn't be complex, but would need to be handled by the router as well. >> >> I am not sure about asymmetric paths though. Depending on the device, it >> may handle this differently, and there is no guarantee that the source >> of your traffic will be from the same connection all the time to the >> destination. This would cause connectivity issues. There really is no >> elegant solution to that without having a full routing table of the >> Internet and 2 separate providers. Others on this list may have a >> solution to that issue off the top of their heads, or have done this >> themselves. >> >> >> On 1/2/10 5:48 PM, Scott Weeks wrote: >>> >>> --- paul.w.bennett at gmail.com wrote: >>> From: "Paul Bennett" >>> >>> At home, I currently run two DSL lines. Right now, we just have two >>> separate LANs, one connected to each line, with my wife's devices attached >>> to one, and my devices attached to the other. For a while now, I've been >>> thinking about setting up a load-balancing routing solution to give both >>> of us access to both lines. >>> --------------------------------------------------- >>> >>> >>> Maybe www.xincom.com/products.php will work? >>> >>> scott >>> >>> >> From dholmes at mwdh2o.com Mon Jan 4 12:00:26 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 4 Jan 2010 10:00:26 -0800 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0A4B7D8E@usmsxt104.mwd.h2o> I do not know of Comcast's Ethernet services specifically, but a general problem with carrier Ethernet services that are based upon the Metro Ethernet Forum (MEF) is that PIM-snooping is not implemented for multicast traffic. The absence of PIM-snooping results in the carrier's Ethernet service operating like a 1990's style Ethernet hub in which (S,G) multicast packets are incorrectly flooded out all user ports. If multicast traffic is to be used on the carrier Ethernet service, and there is more than one user location, then make sure that the carrier understands the implications of the lack of PIM-snooping support. -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Wednesday, December 23, 2009 1:11 AM To: nanog at nanog.org Subject: Experiences with Comcast Ethernet/Transit service We're looking at using Comcast's (business) transit and private ethernet services at several client locations and I wanted to see what experiences others have had regarding this. Off-list replies are preferred. Thanks, -brandon -- Brandon Galbraith Mobile: 630.400.6992 From davet1 at gmail.com Mon Jan 4 12:32:59 2010 From: davet1 at gmail.com (Dave Temkin) Date: Mon, 04 Jan 2010 10:32:59 -0800 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: <4B31E96D.9050708@head-net.com> References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> <4B31E96D.9050708@head-net.com> Message-ID: <4B42345B.1070804@gmail.com> I purchased a single GigE transport link from them between a off-net building that they lit for us and a lit site. Install went without issue, including pulling in new fiber. Never underestimate the advantages of having pole and conduit rights. My only complaint would be interval - it took nearly 120 days from order to install and much of that was seemingly spent idle. The service itself has been rock solid. Unfortunately they don't span across metros within the same logical network (yet) - this would definitely be a bonus. -Dave Sean Head wrote: > I just started looking into them as well. Mind of I has for similar > info? (maybe just keep the responses on list?) > > -Sean > > On 2009.12.23 01:10:39, Brandon Galbraith wrote: >> We're looking at using Comcast's (business) transit and private ethernet >> services at several client locations and I wanted to see what >> experiences >> others have had regarding this. Off-list replies are preferred. >> >> Thanks, >> -brandon >> > > From bicknell at ufp.org Mon Jan 4 12:38:48 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 Jan 2010 10:38:48 -0800 Subject: More ASN collissions In-Reply-To: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> References: <5D6184FD-CD87-4B5B-B016-504799C5AB70@puck.nether.net> Message-ID: <20100104183848.GA69592@ussenterprise.ufp.org> In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote: > As always, good research by renesys. > > http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml http://blog.isc.org/2010/01/asn-collisions-and-human-error.html -- 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: 826 bytes Desc: not available URL: From tony at lava.net Mon Jan 4 14:13:00 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 4 Jan 2010 10:13:00 -1000 (HST) Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0A4B7D8E@usmsxt104.mwd.h2o> References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> <485ED9BA02629E4BBBA53AC892EDA50E0A4B7D8E@usmsxt104.mwd.h2o> Message-ID: On Mon, 4 Jan 2010, Holmes,David A wrote: > I do not know of Comcast's Ethernet services specifically, but a general > problem with carrier Ethernet services that are based upon the Metro > Ethernet Forum (MEF) is that PIM-snooping is not implemented for > multicast traffic. The absence of PIM-snooping results in the carrier's > Ethernet service operating like a 1990's style Ethernet hub in which > (S,G) multicast packets are incorrectly flooded out all user ports. Not implemented because it's not in the MEF specs or not implemented because of carrier operational practice? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From bhuffake at caida.org Mon Jan 4 14:23:08 2010 From: bhuffake at caida.org (Bradley Huffaker) Date: Mon, 4 Jan 2010 12:23:08 -0800 Subject: geolocation comparison Message-ID: <20100104202308.GT62651@caida.org> CAIDA plans to conduct a comparison of geolcocation tools for determining the location of Internet Protocal (IP) address (and other identifiers) in the summer of 2010. At this time we wish to receive feedback from interested parties on input to the comparison survey, whether they wish to participate and in what capacity. * What is your primary interest in geolocation services? Legal, academic, content localization, disaster preparedness, regulation, ... * Can you provide ground truth geolocation information for your organization? * Do you have suggested metrics, questions, or tests to include in the comparisons? * If you provide a geolocation service, under what conditions would you be willing to participate? * If you use a Geolocation service(s), which do you use and in what way? * Which companies do you consider to be the primary providers of geolocation services at this time? Please send any comments to: geocompare-info at caida.org Details can be found: http://www.caida.org/projects/cybersecurity/geolocation/ -- "Be always at war with your vices, at peace with your neighbors, and let each new year find you a better man." - Benjamin Franklin From nanog at shreddedmail.com Mon Jan 4 15:19:58 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 4 Jan 2010 13:19:58 -0800 Subject: D/DoS mitigation hardware/software needed. Message-ID: Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core. I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives. My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH. Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed. I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases. Thanks, Rick From jeffrey.lyon at blacklotus.net Mon Jan 4 15:25:12 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 4 Jan 2010 16:25:12 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> We have substantial direct experience with both RioRey and IntruGuard. RR is more plug and play while IG is more robust but both are great. Use a robust firewall such as a Netscreen in front of your mitigation tool. Best regards, Jeff On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst wrote: > Looking for D/DoS mitigation solutions. ?I've seen Arbor Networks mentioned > several times but they haven't been responsive to literature requests (hint, > if anybody from Arbor is looking...). ?Our current upstream is 3x GigE from > 3 different providers, each landing on their own BGP endpoint feeding a > route-reflector core. > > I see two possible solutions: > - Netflow/sFlow/***Flow ?feeding a BGP RTBH > - Inline device > > Netflow can lag a bit in detection. ?I'd be concerned that inline devices > add an additional point of failure. ?I'm worried about both failing-open > (e.g. network outage) and false-positives. > > My current system is a home-grown NetFlow parser that spits out syslog to > our NOC to investigate potential attacks and manually enter them into our > RTBH. > > > Any suggestions other than Arbor? ?Any other mechanisms being used? ?My idea > is to quash the immediate problem and work additional mitigation with > upstreams if needed. > > I could probably add some automation to my NetFlow/RTBH setup, but I still > need to worry about false-positives. I'd rather somebody else do the hard > work of finding the various edge-cases. > > Thanks, > Rick > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From raj.singh at demandmedia.com Mon Jan 4 15:45:36 2010 From: raj.singh at demandmedia.com (Raj Singh) Date: Mon, 4 Jan 2010 13:45:36 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <6CDE22DE80A63A4DACF4FE2C916519A53F4F3C157E@BLV11EXVS01.corp.dm.local> Rick, If you pass me your contact info I can forward it to our Arbor Sales guy who can get in touch with you. I been pretty impressed by Arbor so far. Thanks, Raj Singh??? -----Original Message----- From: Rick Ernst [mailto:nanog at shreddedmail.com] Sent: Monday, January 04, 2010 1:20 PM To: NANOG Subject: D/DoS mitigation hardware/software needed. Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned several times but they haven't been responsive to literature requests (hint, if anybody from Arbor is looking...). Our current upstream is 3x GigE from 3 different providers, each landing on their own BGP endpoint feeding a route-reflector core. I see two possible solutions: - Netflow/sFlow/***Flow feeding a BGP RTBH - Inline device Netflow can lag a bit in detection. I'd be concerned that inline devices add an additional point of failure. I'm worried about both failing-open (e.g. network outage) and false-positives. My current system is a home-grown NetFlow parser that spits out syslog to our NOC to investigate potential attacks and manually enter them into our RTBH. Any suggestions other than Arbor? Any other mechanisms being used? My idea is to quash the immediate problem and work additional mitigation with upstreams if needed. I could probably add some automation to my NetFlow/RTBH setup, but I still need to worry about false-positives. I'd rather somebody else do the hard work of finding the various edge-cases. Thanks, Rick From nanog at shreddedmail.com Mon Jan 4 15:59:50 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 4 Jan 2010 13:59:50 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: Several responses already, and Arbor has poked their head up. I'm going to start there and keep the other suggestions at-hand. Thanks, On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst wrote: > > Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned > several times but they haven't been responsive to literature requests (hint, > if anybody from Arbor is looking...). Our current upstream is 3x GigE from > 3 different providers, each landing on their own BGP endpoint feeding a > route-reflector core. > > I see two possible solutions: > - Netflow/sFlow/***Flow feeding a BGP RTBH > - Inline device > > Netflow can lag a bit in detection. I'd be concerned that inline devices > add an additional point of failure. I'm worried about both failing-open > (e.g. network outage) and false-positives. > > My current system is a home-grown NetFlow parser that spits out syslog to > our NOC to investigate potential attacks and manually enter them into our > RTBH. > > > Any suggestions other than Arbor? Any other mechanisms being used? My > idea is to quash the immediate problem and work additional mitigation with > upstreams if needed. > > I could probably add some automation to my NetFlow/RTBH setup, but I still > need to worry about false-positives. I'd rather somebody else do the hard > work of finding the various edge-cases. > > Thanks, > Rick > > From luke.marrott at gmail.com Mon Jan 4 16:02:42 2010 From: luke.marrott at gmail.com (Luke Marrott) Date: Mon, 4 Jan 2010 15:02:42 -0700 Subject: ITU G.992.5 Annex M - ADSL2+M Questions Message-ID: <4a9edb811001041402x383234c8qbb5815d389ebbcf7@mail.gmail.com> I've been looking up information on the Annex M Standard today and am unable to find any ISPs in the US offering this. Can anyone tell me if there are providers in the US using the Annex M standards and increased upstream with it, or if not is there a good reason why its not being done yet? Thanks! :Luke Marrott From dholmes at mwdh2o.com Mon Jan 4 15:56:20 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 4 Jan 2010 13:56:20 -0800 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> <485ED9BA02629E4BBBA53AC892EDA50E0A4B7D8E@usmsxt104.mwd.h2o> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0A4B7E73@usmsxt104.mwd.h2o> PIM-snooping is not in the MEF specs, but should be if multicast is to work properly over a carrier's Ethernet service. Regardless of the specs, RFPs and other user requirements for Ethernet services should include a "must have" clause requiring PIM-snooping functionality. -----Original Message----- From: Antonio Querubin [mailto:tony at lava.net] Sent: Monday, January 04, 2010 12:13 PM To: Holmes,David A Cc: Brandon Galbraith; nanog at nanog.org Subject: RE: Experiences with Comcast Ethernet/Transit service On Mon, 4 Jan 2010, Holmes,David A wrote: > I do not know of Comcast's Ethernet services specifically, but a general > problem with carrier Ethernet services that are based upon the Metro > Ethernet Forum (MEF) is that PIM-snooping is not implemented for > multicast traffic. The absence of PIM-snooping results in the carrier's > Ethernet service operating like a 1990's style Ethernet hub in which > (S,G) multicast packets are incorrectly flooded out all user ports. Not implemented because it's not in the MEF specs or not implemented because of carrier operational practice? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jeffrey.lyon at blacklotus.net Mon Jan 4 16:03:27 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 4 Jan 2010 17:03:27 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <16720fe01001041403n43cb6ecfwdd75948baaf14fea@mail.gmail.com> Ask them if they'd come down to $10 - 20k for a full featured model and they might make two sales, although I doubt it unfortunately. Best regards, Jeff On Mon, Jan 4, 2010 at 4:59 PM, Rick Ernst wrote: > Several responses already, and Arbor has poked their head up. > > I'm going to start there and keep the other suggestions at-hand. > > Thanks, > > > On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst wrote: > >> >> Looking for D/DoS mitigation solutions. ?I've seen Arbor Networks mentioned >> several times but they haven't been responsive to literature requests (hint, >> if anybody from Arbor is looking...). ?Our current upstream is 3x GigE from >> 3 different providers, each landing on their own BGP endpoint feeding a >> route-reflector core. >> >> I see two possible solutions: >> - Netflow/sFlow/***Flow ?feeding a BGP RTBH >> - Inline device >> >> Netflow can lag a bit in detection. ?I'd be concerned that inline devices >> add an additional point of failure. ?I'm worried about both failing-open >> (e.g. network outage) and false-positives. >> >> My current system is a home-grown NetFlow parser that spits out syslog to >> our NOC to investigate potential attacks and manually enter them into our >> RTBH. >> >> >> Any suggestions other than Arbor? ?Any other mechanisms being used? ?My >> idea is to quash the immediate problem and work additional mitigation with >> upstreams if needed. >> >> I could probably add some automation to my NetFlow/RTBH setup, but I still >> need to worry about false-positives. I'd rather somebody else do the hard >> work of finding the various edge-cases. >> >> Thanks, >> Rick >> >> > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From jared at puck.nether.net Mon Jan 4 16:10:51 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 4 Jan 2010 17:10:51 -0500 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0A4B7E73@usmsxt104.mwd.h2o> References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> <485ED9BA02629E4BBBA53AC892EDA50E0A4B7D8E@usmsxt104.mwd.h2o> <485ED9BA02629E4BBBA53AC892EDA50E0A4B7E73@usmsxt104.mwd.h2o> Message-ID: The Deathstar opt-e-man service says they will knee-cap you at 1Mb/s of multicast. - Jared On Jan 4, 2010, at 4:56 PM, Holmes,David A wrote: > PIM-snooping is not in the MEF specs, but should be if multicast is to > work properly over a carrier's Ethernet service. Regardless of the > specs, RFPs and other user requirements for Ethernet services should > include a "must have" clause requiring PIM-snooping functionality. > > -----Original Message----- > From: Antonio Querubin [mailto:tony at lava.net] > Sent: Monday, January 04, 2010 12:13 PM > To: Holmes,David A > Cc: Brandon Galbraith; nanog at nanog.org > Subject: RE: Experiences with Comcast Ethernet/Transit service > > On Mon, 4 Jan 2010, Holmes,David A wrote: > >> I do not know of Comcast's Ethernet services specifically, but a > general >> problem with carrier Ethernet services that are based upon the Metro >> Ethernet Forum (MEF) is that PIM-snooping is not implemented for >> multicast traffic. The absence of PIM-snooping results in the > carrier's >> Ethernet service operating like a 1990's style Ethernet hub in which >> (S,G) multicast packets are incorrectly flooded out all user ports. > > Not implemented because it's not in the MEF specs or not implemented > because of carrier operational practice? > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net From johns at sstar.com Mon Jan 4 16:17:17 2010 From: johns at sstar.com (John Souvestre) Date: Mon, 4 Jan 2010 16:17:17 -0600 Subject: ITU G.992.5 Annex M - ADSL2+M Questions In-Reply-To: <4a9edb811001041402x383234c8qbb5815d389ebbcf7@mail.gmail.com> References: <4a9edb811001041402x383234c8qbb5815d389ebbcf7@mail.gmail.com> Message-ID: <3285E8D2DED6443AB50D590BBD54C2FA@JohnS> Hi Luke. We offer it, along with bonded ADSL. We don't do it often but it is very useful sometimes. Regards, John John Souvestre - New Orleans LA > -----Original Message----- > From: Luke Marrott [mailto:luke.marrott at gmail.com] > Sent: Monday, January 04, 2010 4:03 PM > To: nanog at nanog.org > Subject: ITU G.992.5 Annex M - ADSL2+M Questions > > I've been looking up information on the Annex M Standard today and am unable > to find any ISPs in the US offering this. > > Can anyone tell me if there are providers in the US using the Annex M > standards and increased upstream with it, or if not is there a good reason > why its not being done yet? > > Thanks! > > :Luke Marrott From tom at dyn.com Mon Jan 4 17:38:40 2010 From: tom at dyn.com (Tom Daly) Date: Mon, 4 Jan 2010 18:38:40 -0500 (EST) Subject: [NANOG-announce] REMINDER: CFP for NANOG 48 In-Reply-To: <19114829.335171262648055318.JavaMail.root@mail.corp> Message-ID: <24289800.335191262648320449.JavaMail.root@mail.corp> Hello Fellow NANOG'ers, As you all should know by now, NANOG 48 is coming up in February. The NANOG Program Committee has been busily recruiting, collecting, and reviewing submissions for the program, however, we still need more content. We have lined up many interesting Tracks and Panels, but need more General Session submissions - to learn more about what you're up to in your networks and what is important to you! The NANOG 48 Call for Presentations is still available at http://www.nanog.org/meetings/nanog48/index.php. The PC will be having a call next Tuesday to review submissions, and would like to have more material to review. So what that means: - YOU: Go think of something you think is important to the NANOG Community - YOU: Write up some slides (PDF format prefered) - YOU: Submit them to the PC tool (https://pc.nanog.org) - WE, THE PC: Tell you how awesome your presentation looks - YOU: Present at NANOG 48 and take all the credit for your awesome talk! Yes, it really is that simple. Do it now! Shamelessly, for the NANOG PC, Tom Daly -- Tom Daly CTO, Dynamic Network Services, Inc. http://dyn.com/ _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From nonobvious at gmail.com Mon Jan 4 18:34:39 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 4 Jan 2010 16:34:39 -0800 Subject: DNS question, null MX records In-Reply-To: References: Message-ID: <18a5e7cb1001041634l677c3fbcqb6d202145182d13c@mail.gmail.com> On Tue, Dec 15, 2009 at 7:46 AM, Eric J Esslinger wrote: > So in any case, due to customer privacy concerns we feel we can't do that. If you don't want to handle email for the long-obsolete customer accounts, but just don't want to send that mail to anybody else, it's pretty easy to run a teergrube or other tarpit system to trap any mail addressed to the A-record. These systems basically accept mail v.e.rrrr.yyyyy....s....l.....o...w...l..yyyyy so that spammers can waste their time talking to your tarpit instead of to somebody who cares, and so you can trap their IP addresses and potentially block them or use them to support your other spam-blockers if you want. You don't need a high-performance machine because all the users are spammers and you're *trying* to give them bad service. (Some variants, like LaBrea, are used for connection attempts to non-existent machines - they'll send a syn-ack so the attacker thinks he has a successful 3-way handshake, which slows down scanning attacks.) If you do want to accept mail for the long-obsolete customer accounts, so you can give them a proper human-readable rejection message, you may need to customize. It looks like Exim supports that, though I haven't tried it. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From frnkblk at iname.com Mon Jan 4 20:05:34 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 4 Jan 2010 20:05:34 -0600 Subject: ITU G.992.5 Annex M - ADSL2+M Questions In-Reply-To: <4a9edb811001041402x383234c8qbb5815d389ebbcf7@mail.gmail.com> References: <4a9edb811001041402x383234c8qbb5815d389ebbcf7@mail.gmail.com> Message-ID: We offer it, but practically speaking we haven't gotten much higher than 1.5 Mbps on the upstream. Frank -----Original Message----- From: Luke Marrott [mailto:luke.marrott at gmail.com] Sent: Monday, January 04, 2010 4:03 PM To: nanog at nanog.org Subject: ITU G.992.5 Annex M - ADSL2+M Questions I've been looking up information on the Annex M Standard today and am unable to find any ISPs in the US offering this. Can anyone tell me if there are providers in the US using the Annex M standards and increased upstream with it, or if not is there a good reason why its not being done yet? Thanks! :Luke Marrott From rdobbins at arbor.net Mon Jan 4 20:04:44 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 02:04:44 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> Message-ID: <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > Use a robust firewall such as a Netscreen in front of your mitigation > tool. Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From frnkblk at iname.com Mon Jan 4 20:13:33 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 4 Jan 2010 20:13:33 -0600 Subject: dark fiber and sfp distance limitations In-Reply-To: <4B3E9220.6020307@kenweb.org> References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net> <4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> Message-ID: ....and to add, OTDR at several wavelengths, just in case you want to do xWDM in the future. Frank -----Original Message----- From: ML [mailto:ml at kenweb.org] Sent: Friday, January 01, 2010 6:24 PM To: Mike Cc: nanog at nanog.org Subject: Re: dark fiber and sfp distance limitations On 1/1/2010 5:52 PM, Mike wrote: > I am looking at the possibility of leasing a ~70 mile run of fiber. I > don't have access to any mid point section for regeneration purposes, > and so I am wondering what the chances that a 120km rated SFP would be > able to light the path and provide stable connectivity. There are a lot > of unknowns including # of splices, condition of the cable, or the > actual dispersion index or other properties (until we actually get > closer to leasing it). Its spare telco fibers in the same cable binder > they are using interoffice transport, but there are regen huts along the > way so it works for them but may not for us, and 'finding out' is > potentially expensive. How would someone experienced go about > determining the feasibillity of this concept and what options might > there be? Replies online or off would be appreciated. > > Thanks. > > Pardon my ignorance in this area but is too much to ask for OTDR data before signing contracts? In addition to data on the make of the fiber if you wanted to do xWDM in the future. NDAs shall be signed of course.... From xmin0s at gmail.com Mon Jan 4 20:17:49 2010 From: xmin0s at gmail.com (Tim Eberhard) Date: Mon, 4 Jan 2010 20:17:49 -0600 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> Message-ID: <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> Kinda funny you state that Roland. I know of at least two very large carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS mitigation. State table exhaustion on the netscreen platform is something that is very easy to protect against with some protections and hasn't been a problem for years. If you can fill up a session table on a higher end SRX then I would be very very impressed. I would argue that firewalls place is in fact directly infront of servers and load balancers to protect them. On Mon, Jan 4, 2010 at 8:04 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > > > Use a robust firewall such as a Netscreen in front of your mitigation > > tool. > > Absolutely not - the firewall will fall over due to state-table exhaustion > before the mitigation system will. Firewalls (which have no place in front > of servers in the first place), load-balancers, and any other stateful > devices should be southbound of the mitigation system. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > From deleskie at gmail.com Mon Jan 4 20:18:28 2010 From: deleskie at gmail.com (jim deleskie) Date: Mon, 4 Jan 2010 22:18:28 -0400 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> Message-ID: What Roland said, I've seen people do this, no rules in place, still was able to kill the box (firewall) with a single CPU server. -jim On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > >> Use a robust firewall such as a Netscreen in front of your mitigation >> tool. > > Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. ?Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. > > ----------------------------------------------------------------------- > Roland Dobbins // > > ? ?Injustice is relatively easy to bear; what stings is justice. > > ? ? ? ? ? ? ? ? ? ? ? ?-- H.L. Mencken > > > > > From kowsik at gmail.com Mon Jan 4 20:22:29 2010 From: kowsik at gmail.com (kowsik) Date: Mon, 4 Jan 2010 18:22:29 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <7db9abd31001041822y58d43f38m212a96ae9819e36@mail.gmail.com> If you want to recreate D/DoS from captures (for testing purposes) you might want to check out: http://www.pcapr.net/dos This lets you validate how your mitigation solutions are holding up. K. On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst wrote: > Looking for D/DoS mitigation solutions. ?I've seen Arbor Networks mentioned > several times but they haven't been responsive to literature requests (hint, > if anybody from Arbor is looking...). ?Our current upstream is 3x GigE from > 3 different providers, each landing on their own BGP endpoint feeding a > route-reflector core. > > I see two possible solutions: > - Netflow/sFlow/***Flow ?feeding a BGP RTBH > - Inline device > > Netflow can lag a bit in detection. ?I'd be concerned that inline devices > add an additional point of failure. ?I'm worried about both failing-open > (e.g. network outage) and false-positives. > > My current system is a home-grown NetFlow parser that spits out syslog to > our NOC to investigate potential attacks and manually enter them into our > RTBH. > > > Any suggestions other than Arbor? ?Any other mechanisms being used? ?My idea > is to quash the immediate problem and work additional mitigation with > upstreams if needed. > > I could probably add some automation to my NetFlow/RTBH setup, but I still > need to worry about false-positives. I'd rather somebody else do the hard > work of finding the various edge-cases. > > Thanks, > Rick > From rdobbins at arbor.net Mon Jan 4 20:24:00 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 02:24:00 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> Message-ID: <2B8D5235-0ECE-425C-8A39-91D56C491F76@arbor.net> On Jan 5, 2010, at 9:17 AM, Tim Eberhard wrote: > I would argue that firewalls place is in fact directly infront of servers and load balancers to protect them. The very idea of placing a stateful firewall in front of a Web/DNS/email/etc. server, in which *every single incoming packet is unsolicited, and therefore, leaves no state to be inspected in the first place*, is absurd. There is simply no valid argument for doing so. Hardening the OS/apps/services, combined with stateless ACLs in hardware which can handle mpps, is the way to enforce policy. In fact, the idea is such a poor one that one of the major firewall vendors came out with a 'stateful inspection bypass' feature - the idea being that, you buy their 10gb/sec, $100K-plus stateful firewall, stick it in front of servers, and then . . . disable the stateful inspection, heh. ;> None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From adrian at creative.net.au Mon Jan 4 20:30:33 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 5 Jan 2010 10:30:33 +0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <2B8D5235-0ECE-425C-8A39-91D56C491F76@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <2B8D5235-0ECE-425C-8A39-91D56C491F76@arbor.net> Message-ID: <20100105023033.GA7227@skywalker.creative.net.au> On Tue, Jan 05, 2010, Dobbins, Roland wrote: > None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions. But as you said, they're willing to sell them to you. Then claim that the traffic you're receiving is out of profile. :) (I'm not jaded about this, oh no..) Adrian From jeffrey.lyon at blacklotus.net Mon Jan 4 21:06:06 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 4 Jan 2010 22:06:06 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> Message-ID: <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> We have such a configuration in progress, it works great without any of the issues you're proposing. Jeff On Jan 4, 2010 9:09 PM, "Dobbins, Roland" wrote: On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > Use a robust firewall such as a Netscreen in fro... Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From ops.lists at gmail.com Mon Jan 4 21:13:01 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 Jan 2010 08:43:01 +0530 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> Message-ID: On Tue, Jan 5, 2010 at 8:36 AM, Jeffrey Lyon wrote: > We have such a configuration in progress, it works great without any of the > issues you're proposing. So .. this is interesting. The firewall would have to frontend your mail / web / whatever application .. and if something goes beyond the firewall's rated capacity (100k ++ - maybe nearly 150..175k connections per second for a high end firewall), the firewall falls over. And even before that, there's the risk of whatever application you're protecting getting pounded flat if your firewall passes even a small percentage of this traffic. Do you - 1. Have (say) two firewalls in HA config? 2. Back your firewall with routing based measures, S/RTBH, blackhole communities your upstream offers, etc [the standard nspsec bootcamp stuff] 3. Simply back the firewall with a netflow based device? 4. Estimate that the risk of a DDoS that exceeds your firewall's rated capacity is extremely low? [and yes, 150k ++ connections per second ddos is going to be massive, and relatively rare for most people] --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From rdobbins at arbor.net Mon Jan 4 21:15:42 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 03:15:42 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> Message-ID: <40C1DA82-5902-4F8B-80A0-FC4232CAFB7F@arbor.net> On Jan 5, 2010, at 10:14 AM, Dobbins, Roland wrote: > If it's a stateful firewall, and state-tracking is turned on, it's quite possible to craft sufficient pathological traffic which conforms to the firewall policies and yet which leads to state-table inspection. That should read 'state-table exhaustion', apologies for the typo. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Mon Jan 4 21:14:15 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 03:14:15 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> Message-ID: On Jan 5, 2010, at 10:06 AM, Jeffrey Lyon wrote: > We have such a configuration in progress, it works great without any of the issues you're proposing. Then you aren't testing it to destruction, heh. ;> If it's a stateful firewall, and state-tracking is turned on, it's quite possible to craft sufficient pathological traffic which conforms to the firewall policies and yet which leads to state-table inspection. And the stateful firewall serves no purpose in front of servers, in which *every incoming packet* is unsolicited. Far more sensible to enforce policy in stateless ACLs in ASIC-based router/switch hardware. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From ops.lists at gmail.com Mon Jan 4 21:18:51 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 Jan 2010 08:48:51 +0530 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> Message-ID: Two more options. And for Netflow device - read that to mean Arbor or its competitors. 5 Ditch the stateful firewall and exclusively use a netflow device 6. Outsource to a hosted DDoS mitigation service (Prolexic etc) On Tue, Jan 5, 2010 at 8:43 AM, Suresh Ramasubramanian wrote: > Do you - > > 1. Have (say) two firewalls in HA config? > > 2. Back your firewall with routing based measures, S/RTBH, blackhole > communities your upstream offers, etc [the standard nspsec bootcamp > stuff] > > 3. Simply back the firewall with a netflow based device? > > 4. Estimate that the risk of a DDoS that exceeds your firewall's rated > capacity is extremely low? ?[and yes, 150k ++ connections per second > ddos is going to be massive, and relatively rare for most people] From rdobbins at arbor.net Mon Jan 4 21:31:40 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 03:31:40 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> Message-ID: On Jan 5, 2010, at 10:18 AM, Suresh Ramasubramanian wrote: > 5 Ditch the stateful firewall and exclusively use a netflow device NetFlow analysis is very useful for network visibility, and detection/classification/traceback. There are both open-source and commercial NetFlow collection and analysis systems available (full disclosure: I work for a vendor of both NetFlow analysis and DDoS mitigation solutions); however, they don't provide mitigation, which is where S/RTBH, flow-spec, and/or IDMS come into play. PCI DSS iatrogenically *requires* that a 'Web application firewall' be placed in front of Web servers which process credit card information (PCI DSS completely ignores availability, and contains a number of recommendations which are actually harmful from an opsec standpoint). Running mod_security or its equivalent on the front-end Web servers themselves fulfills this requirement without putting a stateful DDoS chokepoint in front of the servers. It's also a really good idea to front Web servers with a tier of caching-only transparent reverse proxies; Squid is a good choice for this, as well as various commercial offerings. WCCPv2 clustering (supported by Squid and several commercial caching/proxying solutions) allows this tier to be scaled horizontally in order to meet capacity demands. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From morrowc.lists at gmail.com Mon Jan 4 21:35:42 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Jan 2010 22:35:42 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> Message-ID: <75cb24521001041935p7d4bffe2w330560aec65966f2@mail.gmail.com> On Mon, Jan 4, 2010 at 9:18 PM, jim deleskie wrote: > What Roland said, I've seen people do this, no rules in place, still > was able to kill the box (firewall) with a single CPU server. not to pile on, but... +1 to roland here as well. I've seen more than enough folks put in a 'firewall' in front of their 'server' (say a mail server) and then watch that die long before the rest of the system did. Now, if you have equipment capable today of doing a few million session creates/second and you feel comfortable that you can keep track of how attacks grow vs your capacity stays the same and move ahead of the curve well enough, then... by all means do as you want :) There's a cost analysis which Roland sidestepped here as well, state-tracking at the rates required is expensive, as compared to relatively simple acls in hardware with no state on the upstream router. Spend where it matters, and make sure you understand where the failure points are that you place into your network. -chris > -jim > > On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland wrote: >> >> On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: >> >>> Use a robust firewall such as a Netscreen in front of your mitigation >>> tool. >> >> Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. ?Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> ? ?Injustice is relatively easy to bear; what stings is justice. >> >> ? ? ? ? ? ? ? ? ? ? ? ?-- H.L. Mencken >> >> >> >> >> > > From msokolov at ivan.Harhan.ORG Mon Jan 4 21:40:10 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Tue, 5 Jan 2010 03:40:10 GMT Subject: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions) Message-ID: <1001050340.AA11448@ivan.Harhan.ORG> Frank Bulk - iName.com wrote: > We offer it, but practically speaking we haven't gotten much higher than 1.5 > Mbps on the upstream. Sorry that I'm coming into this thread late (I have just subscribed), but since I see people discussing DSL with beefy upstream, I thought I would be brave and ask: do you esteemed high-end network op folks think that there may be anyone in the world who might be interested in bonded SDSL or not? I have spent the past 5 years of my life learning everything there is to know about SDSL. Don't ask me why, I don't really know the answer to that question myself. I won't waste the bandwidth of this elite list with dirty details of just what I've done with SDSL over the past 5 y, but I'll give a link to an open source project that contains the body of SDSL knowledge amassed over those years: http://ifctfvax.Harhan.ORG/OpenSDSL/ To make the long story short, for most of those years I kept trudging on my project, treating it as an ultra-weird hobby that no one else in the world could possibly have any interest in. That persisted until 2009 when my project got noticed by two fairly major North American DSL network operators. (Well, one very major and one semi-major, but I'll spare the names.) Both of those had contacted me via my Open SDSL Connectivity Project expressing interest in SDSL bonding. Both companies were telling me how much interest they had in SDSL bonding, how much it would help their business to be able to offer bonded SDSL services at 3 or 6 Mbps, how many customers they would be able to sign up for these services, etc. But when I asked them to back their verbally-expressed interest with the tiniest amount of money or even no money at all but a letter of intent which I could show to SBA etc, they both went silent. We've been playing a game of cat-and-mouse ever since. As far as I could understand the existing situation is that the SDSL infrastructure already deployed en masse by the major North American DSL network operators already has the capability to serve out bonded SDSL circuits, bonding either in the DSLAM or somewhere upstream of it, using MLPPP, Multilink Frame Relay or whatever else one can think of, but the problem is with CPE. Apparently bonding-capable multiport SDSL CPE devices are quite scarce. Considering everything I've done with SDSL over the past 5 y, I believe I have a right to say with confidence that I am more than capable of designing and building a bonding-capable multiport SDSL CPE device for any existing SDSL flavor with any desired number of ports (2, 4 or whatever). But what I don't know, and what I'm asking this highly esteemed list for advice with, is this question: is there anyone at all in the world who might have a real serious interest in such a thing? If there is someone in the world who would truly appreciate having a bonded SDSL solution, I would be delighted to work on developing such a thing. I would see it as a service to humanity whereby more use would be made out of existing copper infrastructure in the ground instead of having to dig more ditches to bury more fiber or whatever. But if there is no one in the world who would be interested in bonded SDSL (or at least interested enough to invest one dime into development), then why bother... MS From jeffrey.lyon at blacklotus.net Mon Jan 4 22:05:49 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 4 Jan 2010 23:05:49 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> Message-ID: <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> 1. We have multiple nodes conducting DDoS scrubbing, one failing would not be catastrophic. 2. Indeed. 3. Sort of, such devices are downstream for extremely valid reasons I won't get into now. 4. Indeed, were equipped to handle substantially higher than 150kpps. I'm sure Arbor is really neat but I disagree that any DDoS appliance is a standalone solution. I don't expect an employee of the vendor themselves to attest to this though. Best regards, Jeff Best regards, Jeff On Jan 4, 2010 10:14 PM, "Suresh Ramasubramanian" wrote: On Tue, Jan 5, 2010 at 8:36 AM, Jeffrey Lyon wrote: > We have such a c... So .. this is interesting. The firewall would have to frontend your mail / web / whatever application .. and if something goes beyond the firewall's rated capacity (100k ++ - maybe nearly 150..175k connections per second for a high end firewall), the firewall falls over. And even before that, there's the risk of whatever application you're protecting getting pounded flat if your firewall passes even a small percentage of this traffic. Do you - 1. Have (say) two firewalls in HA config? 2. Back your firewall with routing based measures, S/RTBH, blackhole communities your upstream offers, etc [the standard nspsec bootcamp stuff] 3. Simply back the firewall with a netflow based device? 4. Estimate that the risk of a DDoS that exceeds your firewall's rated capacity is extremely low? [and yes, 150k ++ connections per second ddos is going to be massive, and relatively rare for most people] --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From bill at billblackford.com Mon Jan 4 22:09:40 2010 From: bill at billblackford.com (Bill Blackford) Date: Mon, 4 Jan 2010 20:09:40 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001041935p7d4bffe2w330560aec65966f2@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <75cb24521001041935p7d4bffe2w330560aec65966f2@mail.gmail.com> Message-ID: <680a83091001042009j62bcad0dpbe4acaf9f33a5e69@mail.gmail.com> A lot of this has to do with scaling the environment. I've had plenty of asa's and even netscreens fall over from state-table and session limitations. I've also seen a hosts fill up the connection table prior to a firewall being affected. I'm not familiar with the specs and anyone can chime in, but the newer variety of SRX's, I believe implement more in hardware as line-rate routers do. A layered approach is useful as well. If the source can be identified via netflow and null routed before it gets to the firewall and content layer, then all the better. This is much more tricky with DDOS so having robust firewall that can eat traffic is helpful. My 3 cents -b On Mon, Jan 4, 2010 at 7:35 PM, Christopher Morrow wrote: > On Mon, Jan 4, 2010 at 9:18 PM, jim deleskie wrote: > > What Roland said, I've seen people do this, no rules in place, still > > was able to kill the box (firewall) with a single CPU server. > > not to pile on, but... +1 to roland here as well. I've seen more than > enough folks put in a 'firewall' in front of their 'server' (say a > mail server) and then watch that die long before the rest of the > system did. > > Now, if you have equipment capable today of doing a few million > session creates/second and you feel comfortable that you can keep > track of how attacks grow vs your capacity stays the same and move > ahead of the curve well enough, then... by all means do as you want :) > > There's a cost analysis which Roland sidestepped here as well, > state-tracking at the rates required is expensive, as compared to > relatively simple acls in hardware with no state on the upstream > router. > > Spend where it matters, and make sure you understand where the failure > points are that you place into your network. > > -chris > > > -jim > > > > On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland > wrote: > >> > >> On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > >> > >>> Use a robust firewall such as a Netscreen in front of your mitigation > >>> tool. > >> > >> Absolutely not - the firewall will fall over due to state-table > exhaustion before the mitigation system will. Firewalls (which have no > place in front of servers in the first place), load-balancers, and any other > stateful devices should be southbound of the mitigation system. > >> > >> ----------------------------------------------------------------------- > >> Roland Dobbins // > >> > >> Injustice is relatively easy to bear; what stings is justice. > >> > >> -- H.L. Mencken > >> > >> > >> > >> > >> > > > > > > -- Bill Blackford Network Engineer From ops.lists at gmail.com Mon Jan 4 22:13:06 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 Jan 2010 09:43:06 +0530 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> Message-ID: With these safeguards in place - and with flow devices being part of the mix somewhere .. what you propose is quite reasonable. There's still the question of whether an application that receives a lot of new / untrusted traffic - a mail or web server - would benefit from having a stateful firewall in front .. Roland seems to think not. --srs On Tue, Jan 5, 2010 at 9:35 AM, Jeffrey Lyon wrote: > 1. We have multiple nodes conducting DDoS scrubbing, one failing would not > be catastrophic. > > 2.? Indeed. > > 3.? Sort of, such devices are downstream for extremely valid reasons I won't > get into now. > > 4. Indeed, were equipped to handle substantially higher than 150kpps. > > I'm sure Arbor is really neat but I disagree that any DDoS appliance is a > standalone solution. I don't expect an employee of the vendor themselves to > attest to this though. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rdobbins at arbor.net Mon Jan 4 22:20:51 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 04:20:51 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> Message-ID: <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote: > I'm sure Arbor is really neat but I disagree that any DDoS appliance is a standalone solution. I disagree with this proposition, too. S/RTBH and/or flow-spec are great DDoS mitigation tools which don't require any further investment beyond the network infrastructure an operator has already purchased and deployed. These should be the first mitigation tools anyone deploys; in many cases, they're all that's needed. > I don't expect an employee of the vendor themselves to attest to this though. Wrong again. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From morrowc.lists at gmail.com Mon Jan 4 22:41:22 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Jan 2010 23:41:22 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> Message-ID: <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> On Mon, Jan 4, 2010 at 11:20 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote: > >> I'm sure Arbor is really neat but I disagree that any DDoS appliance is a standalone solution. > > I disagree with this proposition, too. > > S/RTBH and/or flow-spec are great DDoS mitigation tools which don't require any further investment beyond the network infrastructure an operator has already purchased and deployed. ?These should be the first mitigation tools anyone deploys; in many cases, they're all that's needed. Is it fair to say that most folks in this thread believe there is not 'one size fits all', and that there are quite a few tools available in the security/networking toolbox? Some of these are outlined in past nanog tutorials: Sorry to pick on barry here, but he's got a few preso's up from past NANOG's that cover this topic pretty well. All of them talk about a set of tools a network operator should be familiar with, with escalating costs (dollars and packet-loss/collateral damage), and some cut/pasteable configlets even. >> I don't expect an employee of the vendor themselves to attest to this though. > > Wrong again. eh, roland's always happy to bash on employers :) but, he's got some solid standing on this set of points. Again, if you know what you're doing then feel free to go off and do it, but at first blush there are LOTS of people putting 'servers' out on the 'public network' behind devices whoafully prepared to deal with 'real world traffic demands', so instead of making the same mistake, perhaps learning from some experience would be in order? The original poster seemed to be asking about appliance based solutions, so your pointed remarks about Roland aside he was actually answering the question. I wonder if Stefan Fouant would offer some of his experience with 'not arbor' vendor solutions to be used when other techniques come up short? (note I think Roland may have been party to some of the presenations I linked in this... I certainly was for one of them at least, in case that matters.) -Chris > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > ? ?Injustice is relatively easy to bear; what stings is justice. > > ? ? ? ? ? ? ? ? ? ? ? ?-- H.L. Mencken > > > > > From rdobbins at arbor.net Mon Jan 4 22:57:50 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 04:57:50 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> Message-ID: <8DDE407B-9817-48B1-81B8-0ED0BBA7195F@arbor.net> On Jan 5, 2010, at 11:41 AM, Christopher Morrow wrote: > (note I think Roland may have been party to some of the presenations I linked in this... Yes, sir, and thanks for posting those links! You and Barry and Tim Battles and Sean Donelan and Danny McPherson and Don Smith and Steve Bellovin and Jared Mauch and John Kristoff and a lot of other folks too numerous to mention here have contributed greatly to advancing the state of the art and generating the body of real-world opsec material out there, which it behooves all network operators to study and take into consideration in their own contexts. I also highly recommend this book by Dave Smith and Gregg Schudel of Cisco - it's the best (and only!) book on real-world opsec out there, available in dead-tree, Kindle, and Adobe Reader formats: [Full disclosure; I'm cited in the book, but received and continue to receive no renumeration of any kind due to same.] Here's another preso on this same topic which may be of interest: ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nanog at shreddedmail.com Mon Jan 4 23:05:53 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 4 Jan 2010 21:05:53 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> Message-ID: Not necessarily an appliance, per se. But a "solution". :) A solution preferably that integrates with NetFlow and RTBH. An in-line solution obviously requires an appliance, or at least special/additional hardware. A software-only solution that sucks in NetFlow data and can speak BGP to inject /32 routes is also good. This is essentially what I have right now. With white-listing as a safety-net, I can chose whether traffic should be blocked automatically or punted for human eyes/brains/fingers to be the intelligence. I'm interested in seeing products (including software) that already have the development (anomaly detection, trends/reports, etc.) work done so I can spend my cycles elsewhere. Additional usefulness (not mentioned earlier) would be some form of API or other hook into the system so non-NetFlow input (e.g. syslog) could generate the /32 routes as well. I'm looking at taking the first whack at immediate mitigation at the border/edge (upstream) via uRPF and RTBH. Additional mitigation would be via manual or automatic RTBH or security/abuse@ involvement with upstreams. Thanks, Rick On Mon, Jan 4, 2010 at 8:41 PM, Christopher Morrow wrote: > The original poster seemed to be asking about appliance based > solutions, so your pointed remarks about Roland aside he was actually > answering the question. I wonder if Stefan Fouant would offer some of > his experience with 'not arbor' vendor solutions to be used when other > techniques come up short? > From ops.lists at gmail.com Mon Jan 4 23:10:28 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 Jan 2010 10:40:28 +0530 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> Message-ID: On Tue, Jan 5, 2010 at 10:35 AM, Rick Ernst wrote: > I'm interested in seeing products (including software) that already have the > development (anomaly detection, trends/reports, etc.) ?work done so I can > spend my cycles elsewhere. This might fit the bill - http://www.zurich.ibm.com/aurora/ Now commercially available as http://www-01.ibm.com/software/tivoli/products/netcool-performance-flow/ Full disclosure - I work for big blue - but not in any division that works on Aurora / Tivoli Netcool. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rdobbins at arbor.net Mon Jan 4 23:08:27 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:08:27 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> Message-ID: <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote: > > A solution preferably that integrates with NetFlow and RTBH. An in-line solution obviously requires an appliance, or at least special/additional hardware. The key is to not be inline all the time, but only inline *when needed*. This removes operational complexity, provides the ability to oversubscribe, and simplifies the routine troubleshooting matrix. > I'm looking at taking the first whack at immediate mitigation at the border/edge (upstream) via uRPF and RTBH. Good plan. > Additional mitigation would be via manual or automatic RTBH or security/abuse@ involvement with upstreams. Automagic is generally bad, as it can be gamed. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nanog at shreddedmail.com Mon Jan 4 23:19:16 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 4 Jan 2010 21:19:16 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> Message-ID: On Mon, Jan 4, 2010 at 9:08 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote: > > > > > A solution preferably that integrates with NetFlow and RTBH. An in-line > solution obviously requires an appliance, or at least special/additional > hardware. > > The key is to not be inline all the time, but only inline *when needed*. > This removes operational complexity, provides the ability to oversubscribe, > and simplifies the routine troubleshooting matrix. > I'd argue just the opposite. If your monitoring/mitigation system changes dependent on the situation (normal vs under attack), you are adding complexity to the system. "What mode is the system in right now? Is this customer having connectivity issues because of a state change in the network? etc." > > > I'm looking at taking the first whack at immediate mitigation at the > border/edge (upstream) via uRPF and RTBH. > > Good plan. > > > Additional mitigation would be via manual or automatic RTBH or > security/abuse@ involvement with upstreams. > > Automagic is generally bad, as it can be gamed. > I know you said "generally", but if I'm seeing 200Kpps from a.b.c.d, I don't care if a.b.c.d is spoofed. I want the traffic blocked from the guts of my network. Note that my original question was in the context of "a D/DoS composed of lots of itty-bitty packets". Other attack mechanisms do not necessarily lend themselves to "chop 'em off at the knees." Rick From ops.lists at gmail.com Mon Jan 4 23:19:20 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 Jan 2010 10:49:20 +0530 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> Message-ID: On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland wrote: > >> Additional mitigation would be ?via manual or automatic RTBH or security/abuse@ involvement with upstreams. > > Automagic is generally bad, as it can be gamed. ... and manual wont scale in ddos -- Suresh Ramasubramanian (ops.lists at gmail.com) From sfouant at shortestpathfirst.net Mon Jan 4 23:27:45 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 5 Jan 2010 00:27:45 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> Message-ID: <005001ca8dc7$d0a6a170$71f3e450$@net> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Monday, January 04, 2010 11:41 PM > > The original poster seemed to be asking about appliance based > solutions, so your pointed remarks about Roland aside he was actually > answering the question. I wonder if Stefan Fouant would offer some of > his experience with 'not arbor' vendor solutions to be used when other > techniques come up short? Interesting thread! And I'm happy to chime in - thanks Chris! I too would have to strongly agree with Roland's comments about not front-ending your mitigation solution with firewalls or load-balancers - these are precisely the types of things which topple over first under a big attack, as such having your mitigation devices behind them makes little sense. If you must use firewalls and/or LBs, put them behind the mitigation device, where the traffic has already been scrubbed and your state tables won't be exhausted. Having said that, if you've got a router capable of doing generic packet filters upstream of your mitigation device, this is certainly a good place to apply stateless filters which can pitch any traffic you are sure you will never need to receive. Flowspec and/or automated blackhole routing works very well for this application when you want to get rid of certain types of cruft, before it hits your mitigation device. Now, on to the OPs original question regarding appliance based solutions, I would say I am actually a firm believer in having multiple vendors in place if you can afford it. Arbor definitely has a corner on the market here, with the most comprehensive solution which entails everything from detection to mitigation and pretty much everything in between. Arbor can also automate the FlowSpec process and/or generate router ACLs for propagation to upstream routers... They do a lot of other stuff as well such as identification of BGP hijacking, DNS analysis, can automate a lot of the RTBH or S/RTBH stuff. Where Arbor generally suffers is with sophisticated attack traffic which requires complex mitigations - these often require a lot of tweaking in order to properly scrub the traffic... knowing your environment and which attack vectors are likely to be exploited is your best bet here, where you can configure mitigation templates in advance for rapid deployment during an attack. I've also worked with the RioRey devices and I have to say that although they don't have all the bells and whistles that some of the other vendors offer, their approach to mitigation is entirely unique and can genuinely mitigate attacks in record-time. Without disclosing too much of their intellectual property, I will say that their algorithms essentially look at the randomness and probability of address space distribution within the attack traffic, and can generally offer a high degree of certainty of scrubbing the majority of the bad traffic - and they do this WITHOUT having to do DPI as many other vendors are currently doing. Bottom line - if you're looking for something with a lot of bells and whistles and the ability to monitor/detect/analyze/etc., you're probably better off going with an Arbor solution. If you have lower OpEx and just want something that you can "set it and forget it", you'd be hard pressed not to look at the RioRey. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From rdobbins at arbor.net Mon Jan 4 23:22:11 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:22:11 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> Message-ID: <9E26318B-F028-4171-BF62-07038169DF05@arbor.net> On Jan 5, 2010, at 12:19 PM, Suresh Ramasubramanian wrote: > ... and manual wont scale in ddos Actually, it can and does. ;> I'm referring to the employment and selection of situationally-appropriate tools, mind. The tools themselves must of necessity perform their work in a largely automated fashion once they're employed, which is what I believe you actually meant. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Mon Jan 4 23:29:05 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:29:05 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> Message-ID: On Jan 5, 2010, at 12:19 PM, Rick Ernst wrote: > I'd argue just the opposite. If your monitoring/mitigation system changes dependent on the situation (normal vs under attack), you are adding complexity to the system. > "What mode is the system in right now? Is this customer having connectivity issues because of a state change in the network? etc." I strongly disagree with this, except for properties which are under sustained attack 24/7. If one has constructed one's detection/classification/traceback/mitigation system properly, one always knows at a glance the state of the system. Otherwise, whenever there's any issue whatsoever with the properties under protection, one must try and prove a negative - i.e., that the mitigation solution isn't causing the problem. Happens every time, heh. > I know you said "generally", but if I'm seeing 200Kpps from a.b.c.d, I don't care if a.b.c.d is spoofed. I want the traffic blocked from the guts of my network. Not if it's legit, you don't, or if the attacker is spoofing, say, the IPs of the root nameservers, or the TLDs, or an e-commerce/supply-chain partner . . . or if the attack is originating behind a broadband mega-proxy, or a mobile CGN. ;> Also, if you've a variety of tools at your disposal, like S/RTBH and/or flow-spec, and then more sophisticated (and expensive) tools like IDMS, the freedom to choose the least intrusive/most situationally-appropriate tool to mitigate a given attack is essential for resource preservation and the ability to oversubscribe the more sophisticated tools. > Note that my original question was in the context of "a D/DoS composed of lots of itty-bitty packets". Other attack mechanisms do not necessarily lend themselves to "chop 'em off at the knees." Absolutely, which is where the situationally-specific selection of tools/modes comes into play. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sfouant at shortestpathfirst.net Mon Jan 4 23:34:34 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 5 Jan 2010 00:34:34 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> Message-ID: <005101ca8dc8$c418dda0$4c4a98e0$@net> > -----Original Message----- > From: Rick Ernst [mailto:nanog at shreddedmail.com] > Sent: Tuesday, January 05, 2010 12:19 AM > > I'd argue just the opposite. If your monitoring/mitigation system > changes > dependent on the situation (normal vs under attack), you are adding > complexity to the system. "What mode is the system in right now? Is > this > customer having connectivity issues because of a state change in the > network? etc." Almost all of the scalable DDoS mitigation architectures deployed in carriers or other large enterprises employ the use of an offramp method. These devices perform a lot better when you can forward just the subset of the traffic through as opposed to all. It just a simple matter of using static routing / RTBH techniques / etc. to automate the offramp. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From ops.lists at gmail.com Mon Jan 4 23:37:31 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 5 Jan 2010 11:07:31 +0530 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <9E26318B-F028-4171-BF62-07038169DF05@arbor.net> References: <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <9E26318B-F028-4171-BF62-07038169DF05@arbor.net> Message-ID: On Tue, Jan 5, 2010 at 10:52 AM, Dobbins, Roland wrote: > > I'm referring to the employment and selection of situationally-appropriate tools, mind. ?The tools themselves must of necessity perform their work in a largely automated fashion once they're employed, which is what I believe you actually meant. > fair enough. -- Suresh Ramasubramanian (ops.lists at gmail.com) From adrian at creative.net.au Mon Jan 4 23:39:04 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 5 Jan 2010 13:39:04 +0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <005101ca8dc8$c418dda0$4c4a98e0$@net> References: <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> Message-ID: <20100105053904.GB7227@skywalker.creative.net.au> On Tue, Jan 05, 2010, Stefan Fouant wrote: > Almost all of the scalable DDoS mitigation architectures deployed in > carriers or other large enterprises employ the use of an offramp method. > These devices perform a lot better when you can forward just the subset of > the traffic through as opposed to all. It just a simple matter of using > static routing / RTBH techniques / etc. to automate the offramp. Has anyone deployed a DDoS distributed enough to inject ETOOMANY routes into the hardware forwarding tables of routers? I mean, I assume that there's checks and balances in place to limit then number of routes being injected into the network so one doesn't overload the tables, but what's the behaviour if/when this limit is reached? Does mitigation cease being as effective? Adrian From nanog at shreddedmail.com Mon Jan 4 23:39:37 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 4 Jan 2010 21:39:37 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <005101ca8dc8$c418dda0$4c4a98e0$@net> References: <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> Message-ID: I think you, Roland, and I are all agreeing on the same argument. The (my) confusion entered with the statement of, "The key is to not be inline all the time, but only inline *when needed*. I inferred a topological or physical path change from that. Redirecting traffic (which is really just an extension of RTBH; a scrubber destination rather than Null0) is an understandable state. Rick On Mon, Jan 4, 2010 at 9:34 PM, Stefan Fouant wrote: > > -----Original Message----- > > From: Rick Ernst [mailto:nanog at shreddedmail.com] > > Sent: Tuesday, January 05, 2010 12:19 AM > > > > I'd argue just the opposite. If your monitoring/mitigation system > > changes > > dependent on the situation (normal vs under attack), you are adding > > complexity to the system. "What mode is the system in right now? Is > > this > > customer having connectivity issues because of a state change in the > > network? etc." > > Almost all of the scalable DDoS mitigation architectures deployed in > carriers or other large enterprises employ the use of an offramp method. > These devices perform a lot better when you can forward just the subset of > the traffic through as opposed to all. It just a simple matter of using > static routing / RTBH techniques / etc. to automate the offramp. > > Stefan Fouant, CISSP, JNCIE-M/T > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > From sfouant at shortestpathfirst.net Mon Jan 4 23:39:46 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 5 Jan 2010 00:39:46 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> Message-ID: <005501ca8dc9$7e43b5b0$7acb2110$@net> > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Tuesday, January 05, 2010 12:19 AM > > On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland > wrote: > > > >> Additional mitigation would be via manual or automatic RTBH or > security/abuse@ involvement with upstreams. > > > > Automagic is generally bad, as it can be gamed. > > ... and manual wont scale in ddos There are pros and cons to each approach. Certain types of things can be automated, in fact I've done this using the Auto-mitigate feature in Arbor coupled with pre-configured mitigation templates for certain types of traffic and it works very well. But generally, as Roland mentioned automagic stuff can be gamed and for the majority of the stuff you are going to want an operator to look at the alert before making the decision to offramp. The trick is to try to automate as much around the process as possible - I've worked in environments where just making little changes to incident handling response methods reduced the time to mitigate an attack from hours to minutes, all the while still requiring an operator to press the "big red button" to offramp and enable the mitigation. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From rdobbins at arbor.net Mon Jan 4 23:43:16 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:43:16 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100105053904.GB7227@skywalker.creative.net.au> References: <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <20100105053904.GB7227@skywalker.creative.net.au> Message-ID: On Jan 5, 2010, at 12:39 PM, Adrian Chadd wrote: > I mean, I assume that there's checks and balances in place to limit > then number of routes being injected into the network so one doesn't > overload the tables, but what's the behaviour if/when this limit is > reached? Does mitigation cease being as effective? For IDMS 'scrubbing' solutions, one merely injects the route of the attack targets into one's iBGP, in order to draw all traffic towards that specific target into the scrubbing center. For S/RTBH and flow-spec, modern edge routers can scale to millions of routes; also note one isn't limited to /32s. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Mon Jan 4 23:47:05 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:47:05 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <005501ca8dc9$7e43b5b0$7acb2110$@net> References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005501ca8dc9$7e43b5b0$7acb2110$@net> Message-ID: On Jan 5, 2010, at 12:39 PM, Stefan Fouant wrote: > The trick is to try to automate as much around the process as possible - I've worked in environments where just making little changes to incident handling response methods reduced the time to mitigate an attack from hours to minutes, all the while still requiring an operator to press the "big red button" to offramp and enable the mitigation. Concur 100% - and when the end-customer is under attack and screaming, this reduction in time to detect/classify/traceback/mitigate makes all the difference. Your very salient comments highlight the paramount importance of preparation as the key enabling phase of the six-phase security incident-handling methodology: 1. Preparation. 2. Detection/identification. 3. Classification. 4. Traceback. 5. Reaction. 6. Post-mortem (feeding lessons learned back into the Preparation phase). ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Mon Jan 4 23:47:27 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:47:27 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> Message-ID: <9A7AA8A1-A0CE-42AE-87AF-DB66B454C364@arbor.net> On Jan 5, 2010, at 12:39 PM, Rick Ernst wrote: > I think you, Roland, and I are all agreeing on the same argument. GMTA. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Mon Jan 4 23:57:16 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 05:57:16 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <8DDE407B-9817-48B1-81B8-0ED0BBA7195F@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <8DDE407B-9817-48B1-81B8-0ED0BBA7195F@arbor.net> Message-ID: On Jan 5, 2010, at 11:57 AM, Dobbins, Roland wrote: > You and Barry and Tim Battles and Sean Donelan and Danny McPherson and Don Smith and Steve Bellovin and Jared Mauch and John Kristoff and a lot of other folks too numerous to mention . . . including Paul Vixie, Darrel Lewis, Ryan McDowell, Paul Quinn, Michael Behringer, Craig Huegen, Craig Labvoitz, Dave Smith, & Gregg Schudel, and many others. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From hank at efes.iucc.ac.il Tue Jan 5 00:02:05 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 5 Jan 2010 08:02:05 +0200 (IST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <005101ca8dc8$c418dda0$4c4a98e0$@net> References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> Message-ID: On Tue, 5 Jan 2010, Stefan Fouant wrote: > Almost all of the scalable DDoS mitigation architectures deployed in > carriers or other large enterprises employ the use of an offramp method. > These devices perform a lot better when you can forward just the subset of > the traffic through as opposed to all. It just a simple matter of using > static routing / RTBH techniques / etc. to automate the offramp. That said, what are all those ISPs doing now that Cisco has stopped developing the Guard? -Hank From sfouant at shortestpathfirst.net Tue Jan 5 00:16:39 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 5 Jan 2010 01:16:39 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> Message-ID: <005c01ca8dce$a59141a0$f0b3c4e0$@net> > -----Original Message----- > From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] > Sent: Tuesday, January 05, 2010 1:02 AM > > On Tue, 5 Jan 2010, Stefan Fouant wrote: > > > Almost all of the scalable DDoS mitigation architectures deployed in > > carriers or other large enterprises employ the use of an offramp > method. > > These devices perform a lot better when you can forward just the > subset of > > the traffic through as opposed to all. It just a simple matter of > using > > static routing / RTBH techniques / etc. to automate the offramp. > > That said, what are all those ISPs doing now that Cisco has stopped > developing the Guard? Well of course, moving to Arbor haha... eased in part by a little Cisco initiative called Clean Pipes 2.0 :) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From darren at bolding.org Tue Jan 5 01:38:38 2010 From: darren at bolding.org (Darren Bolding) Date: Mon, 4 Jan 2010 23:38:38 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> Message-ID: <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> I actually agree with most of this, but want to correct a clearly inadvertent error below, and make a couple of points. PCI DSS does not require a "Web application firewall". It requires that OR an independent audit of all code within PCI scope by a third party. If a WAF is used, it "only" need be deployed in such a manner as to protect devices inside of PCI scope (depending on design, this may or may not include everything that has public exposure). The powers that be specified additional methods by which PCI compliance could be satisfied other than just these two after the wailing of the masses. I don't know off the top of my head if those other methods will be acceptable in 2010. Personally, I believe a DOS detection/prevention system is typically going to be best placed between screening routers/switches and the next L3/L4 aware device- generally you will want it (or them) to be as close to your ingress edge as you can put it- why allow DOS traffic to go further downstresm? So I suspect Roland and I agree on that fwiw. Earlier, Roland mentions load-balancers and firewalls as both being susceptible to state-table overflows. Certainly this is possible and happened in the past, and it argues for a DOS prevention device being in front of them. At least one modern high-end load balancer handles this well and is in front of a large number if not the majority of major sites. It is possible to build equipment that can handle vast numbers of state entries and handle lookups into them in very attractive big O's. It is also possible to build systems that gracefully handle table exhaustion and enter into aggressive reaping modes. This has been empirically proven to me wrt load-balancers. Some device is going to have to handle the state and insert itself into the path- even if that is a lone webserver. I maintain that there is no reason to believe that it is not possible for a firewall to do that as well as a load-balancer. As for whether you should have a stateful firewall in front of a production web server farm, I understand Roland's point. However, I will say that there are many reasons why people put firewalls in front of webservers- to name some: * Defense in depth. You've never had a host that received external traffic ever accidentally have iptables or windows firewall turned off? Even when debugging a production outage or on accident? * Location for IDS/IDP. * Connection cleanup, re-assembling fragments, etc. * SYN flood protection, etc. * Single choke point to block incoming traffic deemed undesirable. * Single log point for inbound connections for analysis and auditing requirements. * Allows outbound traffic enforcement. * Allows conditional inbound traffic from specific approved external hosts- e.g. a partner. * Some firewalls allow programmatic modification of configurations with all the benefits/pain that brings. This is alongside traditional CLI and GUI interfaces. * In some/many cases a zone based firewall configuration can be much easier to work with than a large iptables config. Certainly the management tools are better. * Yeah, auditors like it. I'm not at all adverse to putting transparent proxies in front of your website. CDN vendors aren't either. I will say that I have had several bad experiences with WCCP not working as expected and failing non-gracefully. I am not saying its always a good idea to have a stateful firewall in front of your web servers, I'm saying that there are reasons why you might want to and in my experience it is common. --D On Mon, Jan 4, 2010 at 7:31 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 10:18 AM, Suresh Ramasubramanian wrote: > > > 5 Ditch the stateful firewall and exclusively use a netflow device > > NetFlow analysis is very useful for network visibility, and > detection/classification/traceback. There are both open-source and > commercial NetFlow collection and analysis systems available (full > disclosure: I work for a vendor of both NetFlow analysis and DDoS > mitigation solutions); however, they don't provide mitigation, which is > where S/RTBH, flow-spec, and/or IDMS come into play. > > PCI DSS iatrogenically *requires* that a 'Web application firewall' be > placed in front of Web servers which process credit card information (PCI > DSS completely ignores availability, and contains a number of > recommendations which are actually harmful from an opsec standpoint). > Running mod_security or its equivalent on the front-end Web servers > themselves fulfills this requirement without putting a stateful DDoS > chokepoint in front of the servers. > > It's also a really good idea to front Web servers with a tier of > caching-only transparent reverse proxies; Squid is a good choice for this, > as well as various commercial offerings. WCCPv2 clustering (supported by > Squid and several commercial caching/proxying solutions) allows this tier to > be scaled horizontally in order to meet capacity demands. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > -- -- Darren Bolding -- -- darren at bolding.org -- From rdobbins at arbor.net Tue Jan 5 01:47:46 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 07:47:46 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> Message-ID: <5E8E62F5-5949-4296-A2AB-18F79470AA05@arbor.net> On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote: > * Defense in depth. You've never had a host that received external traffic ever accidentally have iptables or windows firewall turned off? Even when debugging a production outage or on accident? Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps. 'Stateful inspection' where in fact there is no useful state to inspect is pointless. > * Location for IDS/IDP. Non-sequitur, as these things have nothing to do with one another (plus, these devices are useless, anyways, heh). > * Connection cleanup, re-assembling fragments, etc. Far, far, far better and more scalably handled by the hosts themselves and/or load-balancers. > * SYN flood protection, etc. Firewalls simply don't handle this well, marketing claims aside. They crash and burn. > * Single choke point to block incoming traffic deemed undesirable. Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps. > * Single log point for inbound connections for analysis and auditing requirements. Contextless, arbitrary syslog from firewalls and other such devices is largely useless for this purpose. NetFlow combined with server/app/service logs is the answer to this requirement. > * Allows outbound traffic enforcement. Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps. > * Allows conditional inbound traffic from specific approved external hosts- e.g. a partner. Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps. > * Some firewalls allow programmatic modification of configurations with all the benefits/pain that brings. This is alongside traditional CLI and GUI interfaces. Ugly, brittle, siloed, to be avoided at all costs. > * In some/many cases a zone based firewall configuration can be much easier to work with than a large iptables config. Certainly the management tools are better. Again, policy should be enforced via stateless ACLs in router/switch hardware capable of handling mpps. > * Yeah, auditors like it. Education is the answer here. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jan 5 01:54:33 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 07:54:33 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> Message-ID: <7B35D82E-C0B1-450E-A141-3DAD773EA481@arbor.net> On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote: > PCI DSS does not require a "Web application firewall". Since no business is going to allow an external 'code review' (if it's even possible, given that they're likely using COTS products, the source code of which they simply don't have), this defaults to a requirement for the 'Web application firewall'. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From fweimer at bfk.de Tue Jan 5 02:04:42 2010 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 05 Jan 2010 08:04:42 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100105053904.GB7227@skywalker.creative.net.au> (Adrian Chadd's message of "Tue\, 5 Jan 2010 13\:39\:04 +0800") References: <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <20100105053904.GB7227@skywalker.creative.net.au> Message-ID: <82y6kdkmed.fsf@mid.bfk.de> * Adrian Chadd: > Has anyone deployed a DDoS distributed enough to inject ETOOMANY routes into > the hardware forwarding tables of routers? I think this is called "injecting the BGP table into your IGP", and quite a few folks have done it. Nobody claimed that it was an act of sabotage, though. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From darren at bolding.org Tue Jan 5 02:58:03 2010 From: darren at bolding.org (Darren Bolding) Date: Tue, 5 Jan 2010 00:58:03 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <7B35D82E-C0B1-450E-A141-3DAD773EA481@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> <7B35D82E-C0B1-450E-A141-3DAD773EA481@arbor.net> Message-ID: <5a318d411001050058q1a25d08fk12a8cd7b846bae63@mail.gmail.com> I know of several companies, with large websites, that used code reviews as at least one way they met this DSS requirement. So, erm, empirically denied. The PCI DSS does not require code review of the software running in COTS equipment, nor of underlying OS's or applications. It requires a code review of the application code that is inside PCI scope. In general, this means the code you write to run your website is the maximum scope of this requirement. Plenty of companies allow code reviews for security and other purposes, and with good reason. There exist entire practices in IT security firms dedicated to performing code reviews, and they appear to be growing. Also, the PCI security council allows people to use automated code auditing tools (such as fortify), performing a manual "application assessment"- which plenty of firms will let you pay them to do, or even to use an automated web application security scanners. Several vendors of Vulnerability Assessment tools that meet this spec are available. I believe their is strong evidence that the use of web application firewalls to meet this DSS requirement is smaller than you might think. I would not be surprised if it was significantly less than 50%- perhaps 20%. To make the operational content clear- if someone tells you that you need to buy a Web Application Firewall to meet PCI requirements (process credit cards), be aware that is not the only option. I'd recommend you choose the option that is most likely to genuinely improve the security of your infrastructure and business, which may well be a WAF. --D On Mon, Jan 4, 2010 at 11:54 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote: > > > PCI DSS does not require a "Web application firewall". > > < > http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1313797,00.html > > > > Since no business is going to allow an external 'code review' (if it's even > possible, given that they're likely using COTS products, the source code of > which they simply don't have), this defaults to a requirement for the 'Web > application firewall'. > > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > -- -- Darren Bolding -- -- darren at bolding.org -- From steve at ibctech.ca Tue Jan 5 02:58:54 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 05 Jan 2010 03:58:54 -0500 Subject: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions) In-Reply-To: <1001050340.AA11448@ivan.Harhan.ORG> References: <1001050340.AA11448@ivan.Harhan.ORG> Message-ID: <4B42FF4E.1030604@ibctech.ca> Michael Sokolov wrote: > Frank Bulk - iName.com wrote: > >> We offer it, but practically speaking we haven't gotten much higher than 1.5 >> Mbps on the upstream. > > Sorry that I'm coming into this thread late (I have just subscribed), > but since I see people discussing DSL with beefy upstream, I thought I > would be brave and ask: do you esteemed high-end network op folks think > that there may be anyone in the world who might be interested in bonded > SDSL or not? > > I have spent the past 5 years of my life learning everything there is to > know about SDSL. Don't ask me why, I don't really know the answer to > that question myself. I won't waste the bandwidth of this elite list > with dirty details of just what I've done with SDSL over the past 5 y, > but I'll give a link to an open source project that contains the body of > SDSL knowledge amassed over those years: Michael, I'm but a small humble ISP. We have sold SDSL since ~1996. The bonded circuits have been terminated differently over the years, but I still have a fair number of business clients that have SP supplied CPE that is extremely affordable, and that require little to no work on our part. Other than a few stragglers that I keep afloat on SDSL that require fail-over, I've been trying to get rid of the dedicated copper as much as possible, since I 'lease' the copper for the dry circuit(s). We've reached past the break-even point for fibre access within our area, and am at the point where the *very* 'ritzy' resi clients can and will soon be approached. The max length of SDSL that I currently have is 6.7 wired km. Bonded, our longest distance is 5.4 km. Peak throughput over our longest bonded (2 pair) SDSL circuit is 2.25Mb. Given relative average, in the locations that I can provide optics, there is a gain of revenue percentage that I achieve over standard copper SDSL. IOW, when revenue for a bonded SDSL circuit is $285 and I pay $49.40 per circuit for the four wire copper, things begin to look more attractive when I pay *nothing* for the dark fibre, but am able to provide multiple times the bandwidth at the same price to the client ;) fwiw, for bonded SDSL, we have currently: - Symmetric GoWide units deployed (both on the PE and CPE) that inherently manage two-pair which requires but one switch port and no configuration. Aggregates internally. - an 'Elastic' rack that requires a bit more setup on both ends. Terminate into a vlan on a switch to aggregate properly. A 'setup' fee covers this one-time fix. Remember, small ISP, I'm not used to scaling human resources ;) - multiple other stand-alone SDSL modem types (dslam/non-dslam, such as PairGain etc) - Copper Mountain BTW, while on topic, if you know anyone who wants a fully shelved and carded Copper Mountain CE200 dslam w/ dual power supplies, let me know ;) Steve From steve at ibctech.ca Tue Jan 5 03:01:53 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 05 Jan 2010 04:01:53 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100105023033.GA7227@skywalker.creative.net.au> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <2B8D5235-0ECE-425C-8A39-91D56C491F76@arbor.net> <20100105023033.GA7227@skywalker.creative.net.au> Message-ID: <4B430001.4020103@ibctech.ca> Adrian Chadd wrote: > On Tue, Jan 05, 2010, Dobbins, Roland wrote: > >> None of the large, well-known Web properties on the Internet today - at least, the ones which stay up and running, heh - have stateful firewalls in front of them. Including prominent vendors of said stateful firewall solutions. > > But as you said, they're willing to sell them to you. Then claim > that the traffic you're receiving is out of profile. :) > > (I'm not jaded about this, oh no..) ...so, out of curiosity, which one did you buy? ;) Steve From rdobbins at arbor.net Tue Jan 5 03:02:43 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 09:02:43 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5a318d411001050058q1a25d08fk12a8cd7b846bae63@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> <7B35D82E-C0B1-450E-A141-3DAD773EA481@arbor.net> <5a318d411001050058q1a25d08fk12a8cd7b846bae63@mail.gmail.com> Message-ID: On Jan 5, 2010, at 3:58 PM, Darren Bolding wrote: > I believe their is strong evidence that the use of web application firewalls to meet this DSS requirement is smaller than you might think. I would not be surprised if it was significantly less than 50%- perhaps 20%. This directly contradicts my experience working for vendor of such products, FWIW. But I hope this is indeed the case, as it will lead to higher availability for organizations which go this route! ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sthaug at nethelp.no Tue Jan 5 03:09:06 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 05 Jan 2010 10:09:06 +0100 (CET) Subject: Bonded SDSL In-Reply-To: <1001050340.AA11448@ivan.Harhan.ORG> References: <1001050340.AA11448@ivan.Harhan.ORG> Message-ID: <20100105.100906.74738386.sthaug@nethelp.no> > Sorry that I'm coming into this thread late (I have just subscribed), > but since I see people discussing DSL with beefy upstream, I thought I > would be brave and ask: do you esteemed high-end network op folks think > that there may be anyone in the world who might be interested in bonded > SDSL or not? Not only is there interest, it is actually seeing significant use - at least here in Norway. Typical case is bonding 2 or 4 SHDSL links for a total capacity of 4 or 8 Mbps. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From steve at ibctech.ca Tue Jan 5 03:24:58 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 05 Jan 2010 04:24:58 -0500 Subject: Bonded SDSL In-Reply-To: <20100105.100906.74738386.sthaug@nethelp.no> References: <1001050340.AA11448@ivan.Harhan.ORG> <20100105.100906.74738386.sthaug@nethelp.no> Message-ID: <4B43056A.30005@ibctech.ca> sthaug at nethelp.no wrote: >> Sorry that I'm coming into this thread late (I have just subscribed), >> but since I see people discussing DSL with beefy upstream, I thought I >> would be brave and ask: do you esteemed high-end network op folks think >> that there may be anyone in the world who might be interested in bonded >> SDSL or not? > > Not only is there interest, it is actually seeing significant use - at > least here in Norway. Typical case is bonding 2 or 4 SHDSL links for a > total capacity of 4 or 8 Mbps. Out of curiosity, in Norway, who owns the copper? What is your revenue/lease cost ratio? off-list if too far off topic. I'm just curious. I'm about the Toronto Canada area, and I'm just looking at the rough lease cost per km. Be interesting to see if the same figure shows up elsewhere, or, for all I know, perhaps not all countries have a single 'owner' of the copper... Steve From darren at bolding.org Tue Jan 5 04:04:47 2010 From: darren at bolding.org (Darren Bolding) Date: Tue, 5 Jan 2010 02:04:47 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5E8E62F5-5949-4296-A2AB-18F79470AA05@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> <5E8E62F5-5949-4296-A2AB-18F79470AA05@arbor.net> Message-ID: <5a318d411001050204w3b5f55a4q90c4062773c826c1@mail.gmail.com> Comments inline. To reiterate- my entire point is that stateful firewalls are at least sometimes useful in front of large websites. Something of a veer off of the original topic, but not an at all useless exercise IMHO. On Mon, Jan 4, 2010 at 11:47 PM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote: > > > * Defense in depth. You've never had a host that received external > traffic ever accidentally have iptables or windows firewall turned off? > Even when debugging a production outage or on accident? > > Again, policy should be enforced via stateless ACLs in router/switch > hardware capable of handling mpps. 'Stateful inspection' where in fact > there is no useful state to inspect is pointless. > Stateful policies help protect against misbehaving software, operations error, malicious internal activity, external attackers and trojans/viruses/bots making outbound connections to arbitrary ports anywhere on the Internet. Seems to have a point to me. See my previous point about blocking outbound connections. If you allow internal hosts to make connections out to any port on any ip, then perhaps this point is invalid. But lots of people _don't_ allow outbound from any to any/any, and thats a good thing in my book. As for performance, you can get .9mpps stateful firewalls for reasonable prices, and gear exists that can scale up to 15mpps. > * Location for IDS/IDP. > > Non-sequitur, as these things have nothing to do with one another (plus, > these devices are useless, anyways, heh). > > The gear I'm talking about above supports IDP on the same platform. If I am going to deploy an IDP, why wouldn't I choose one that is flow based so it blocks attacks rather than send out panicked RST's in response to attacks, and which has a stateful firewall included (yes, any flow based IDP is essentially a stateful firewall, and I suspect that a well managed IDP with customized rules is similar in functionality to what WAF's do out of the box. In fact one vendors WAF product functionality pre-trained out of the box is snort rules) > > * Connection cleanup, re-assembling fragments, etc. > > Far, far, far better and more scalably handled by the hosts themselves > and/or load-balancers. > Huh, I would have sworn I've seen fragment based attacks on certain linux kernels and Windows systems. I'm sure it won't ever happen again. Load-balancers may be a good place for this, but there are good reasons that you would prefer to have this taken care of as close to ingress as possible. For example, if you want to compare packet flows of a connection on either side of a load-balancer, it is easier to do that if the incoming connections have already been cleaned up. > > > * SYN flood protection, etc. > > Firewalls simply don't handle this well, marketing claims aside. They > crash and burn. I believe that to have been true in the not so recent past, I don't think it is true of more recent equipment. > > * Single choke point to block incoming traffic deemed undesirable. > > Again, policy should be enforced via stateless ACLs in router/switch > hardware capable of handling mpps. > A firewall with easier to use CLI, web UI, management station and API is a much easier way to implement this and offers lots of control for time-of-day based ACL's, etc. etc. I like screening routers, and in a DOS situation I would recommend blocking as close to ingress as possible (preferably outside your own network!) but for typical blocking of nuisance connections, full featured firewalls that can be integrated with a configuration change tracking tool are a better way to go. And what about when the way of identifying undesirable traffic is something other than the source/dest ip/port such as a URI? (more of an argument for an IDP than a simply stateful firewall) > > > * Single log point for inbound connections for analysis and auditing > requirements. > > Contextless, arbitrary syslog from firewalls and other such devices is > largely useless for this purpose. NetFlow combined with server/app/service > logs is the answer to this requirement. > Really? How does netflow show me that a packet was dropped because of rule X? Or permitted because of rule Y? It's great at showing me data about the flow that was extant, but it doesn't tell me the context of the enforcement performed on it. I can assure you that there is a use in looking over denied packet logs. Firewall logs provide _more_ context than netflow. For DOS detection I get that netflow is probably the best tool to use- not arguing that- you made the statement that stateful firewalls are always useless in front of large websites/webservers. I am saying that they are usefull, at least some of the time, and that it is common for them to be deployed in that manner. > > * Allows outbound traffic enforcement. > > Again, policy should be enforced via stateless ACLs in router/switch > hardware capable of handling mpps. So you advocate allowing any packet with ACK set into the internal network? Again, stateful firewalls make this much less of a management headache. > > * Allows conditional inbound traffic from specific approved external > hosts- e.g. a partner. > > Again, policy should be enforced via stateless ACLs in router/switch > hardware capable of handling mpps. > See above :^) > > > * Some firewalls allow programmatic modification of configurations with > all the benefits/pain that brings. This is alongside traditional CLI and > GUI interfaces. > > Ugly, brittle, siloed, to be avoided at all costs. But doing the same thing across hundreds or thousands of web servers via automated systems = good? Personally I like being able to authorize a lower-tech-savvy member of another team to initiate a temporary configuration change via a tool rather than have to wait for the calvary to show up. > > * In some/many cases a zone based firewall configuration can be much > easier to work with than a large iptables config. Certainly the management > tools are better. > > Again, policy should be enforced via stateless ACLs in router/switch > hardware capable of handling mpps. > Huh? > > * Yeah, auditors like it. > > Education is the answer here. > > ;> > If only.... > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > -- -- Darren Bolding -- -- darren at bolding.org -- From darren at bolding.org Tue Jan 5 04:15:43 2010 From: darren at bolding.org (Darren Bolding) Date: Tue, 5 Jan 2010 02:15:43 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> <7B35D82E-C0B1-450E-A141-3DAD773EA481@arbor.net> <5a318d411001050058q1a25d08fk12a8cd7b846bae63@mail.gmail.com> Message-ID: <5a318d411001050215m2e71ae30m78a89b0c96652397@mail.gmail.com> My basis for this is discussions with PCI assessors from multiple firms that perform large numbers of assessments per year. Next time I run into some, I'll ask to see if the usage has increased, its been a few months since I asked this of any of them. --D On Tue, Jan 5, 2010 at 1:02 AM, Dobbins, Roland wrote: > > On Jan 5, 2010, at 3:58 PM, Darren Bolding wrote: > > > I believe their is strong evidence that the use of web application > firewalls to meet this DSS requirement is smaller than you might think. I > would not be surprised if it was significantly less than 50%- perhaps 20%. > > This directly contradicts my experience working for vendor of such > products, FWIW. > > But I hope this is indeed the case, as it will lead to higher availability > for organizations which go this route! > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > -- -- Darren Bolding -- -- darren at bolding.org -- From rdobbins at arbor.net Tue Jan 5 04:13:32 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 10:13:32 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5a318d411001050204w3b5f55a4q90c4062773c826c1@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <5a318d411001042338i354b99d5w3a6e0d38a38adc75@mail.gmail.com> <5E8E62F5-5949-4296-A2AB-18F79470AA05@arbor.net> <5a318d411001050204w3b5f55a4q90c4062773c826c1@mail.gmail.com> Message-ID: <28BEAC4B-1B22-4EAF-B456-FBE1C1C1EF7D@arbor.net> On Jan 5, 2010, at 5:04 PM, Darren Bolding wrote: > To reiterate- my entire point is that stateful firewalls are at least sometimes useful in front of large websites. I understand completely; I simply disagree, stating my reasons for doing so in detail inline. It's my contention that under no circumstances are stateful firewalls *ever* useful in front of *any* Web server, at *any* time, in *any* deployment scenario, either public or private. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sthaug at nethelp.no Tue Jan 5 05:56:10 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 05 Jan 2010 12:56:10 +0100 (CET) Subject: Bonded SDSL In-Reply-To: <4B43056A.30005@ibctech.ca> References: <1001050340.AA11448@ivan.Harhan.ORG> <20100105.100906.74738386.sthaug@nethelp.no> <4B43056A.30005@ibctech.ca> Message-ID: <20100105.125610.74732103.sthaug@nethelp.no> > >> Sorry that I'm coming into this thread late (I have just subscribed), > >> but since I see people discussing DSL with beefy upstream, I thought I > >> would be brave and ask: do you esteemed high-end network op folks think > >> that there may be anyone in the world who might be interested in bonded > >> SDSL or not? > > > > Not only is there interest, it is actually seeing significant use - at > > least here in Norway. Typical case is bonding 2 or 4 SHDSL links for a > > total capacity of 4 or 8 Mbps. > > Out of curiosity, in Norway, who owns the copper? What is your > revenue/lease cost ratio? The copper is owned by the incumbent, Telenor. Leasing copper pairs is 95 NOK (around 17 USD) per pair per year. We have our own DSL equipment in the Telenor COs, which lets us produce (among other things) bonded SHDSL. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jmaimon at ttec.com Tue Jan 5 07:20:45 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 05 Jan 2010 08:20:45 -0500 Subject: DNS queries for . IN A return rcode 2 SERVFAIL from windows DNS recursing resolvers Message-ID: <4B433CAD.9070605@ttec.com> Hey all, This must be old news for everyone else. While looking at a dns monitor on a load balancer that defaulted to . A queries to check liveliness on DNS resolvers, it became quite clear that windows 2000/2003 DNS server appears to return rcode=2 for queries looking for an A record for the root. The resolvers appear to work properly in all other regards. So the monitors were switched to localhost. A (Is this a bad idea?) A little testing later and the results for . A are: Windows NT 4, ancount=0, authority=1, rcode=0 Windows 2000, rcode=2 Windows 2003, rcode=2 bind, ancount=0, authority=1, rcode=0 To my (inexpert) eyes that doesnt seem quite right. I cant seem to find any online information regarding this difference of behavior. Enlightenment appreciated. Joe Here is the output. fpdns -c -s 64.95.32.34 && dig @64.95.32.34 . a 64.95.32.34 Microsoft Windows DNS NT4 ; <<>> DiG 9.6.1-P2 <<>> @64.95.32.34 . a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35180 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN A ;; AUTHORITY SECTION: . 86400 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2010010500 1800 900 604800 86400 ;; Query time: 114 msec ;; SERVER: 64.95.32.34#53(64.95.32.34) ;; WHEN: Tue Jan 5 07:40:33 2010 ;; MSG SIZE rcvd: 92 fpdns -c -s 216.222.144.16 && dig @216.222.144.16 . a 216.222.144.16 ISC BIND 9.2.3rc1 -- 9.6.1-P1 [recursion enabled] id: "9.5.1-P2" ; <<>> DiG 9.6.1-P2 <<>> @216.222.144.16 . a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49220 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN A ;; AUTHORITY SECTION: . 2314 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2010010500 1800 900 604800 86400 ;; Query time: 38 msec ;; SERVER: 216.222.144.16#53(216.222.144.16) ;; WHEN: Tue Jan 5 07:42:08 2010 ;; MSG SIZE rcvd: 92 fpdns -c -s joe.jmaimon.com && dig @joe.jmaimon.com . a 216.222.150.100 ISC BIND 9.2.3rc1 -- 9.6.1-P1 [recursion enabled] id: "9.5.0-P2-W2" ; <<>> DiG 9.6.1-P2 <<>> @joe.jmaimon.com . a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39125 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN A ;; AUTHORITY SECTION: . 10800 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2010010500 1800 900 604800 86400 ;; Query time: 40 msec ;; SERVER: 216.222.150.100#53(216.222.150.100) ;; WHEN: Tue Jan 5 07:57:52 2010 ;; MSG SIZE rcvd: 92 fpdns -c -s 64.95.32.130 && dig @64.95.32.130 . a 64.95.32.130 Microsoft Windows DNS 2000 ; <<>> DiG 9.6.1-P2 <<>> @64.95.32.130 . a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30535 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN A ;; Query time: 35 msec ;; SERVER: 64.95.32.130#53(64.95.32.130) ;; WHEN: Tue Jan 5 07:43:51 2010 ;; MSG SIZE rcvd: 17 fpdns -c -s 72.26.241.205 && dig @72.26.241.205 . a 72.26.241.205 No match found ; <<>> DiG 9.6.1-P1 <<>> @72.26.241.205 . a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12807 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN A ;; Query time: 0 msec ;; SERVER: 72.26.241.205#53(72.26.241.205) ;; WHEN: Tue Jan 5 08:13:06 2010 ;; MSG SIZE rcvd: 17 From rjs at eng.gxn.net Tue Jan 5 08:44:45 2010 From: rjs at eng.gxn.net (Rob Shakir) Date: Tue, 5 Jan 2010 14:44:45 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <005c01ca8dce$a59141a0$f0b3c4e0$@net> References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> Message-ID: <55A91979-A03E-466B-8A4F-4C276E68443B@eng.gxn.net> (Resent, sorry for multiple copies -- I messed up from From: address) On 5 Jan 2010, at 06:16, Stefan Fouant wrote: >> >> That said, what are all those ISPs doing now that Cisco has stopped >> developing the Guard? > > Well of course, moving to Arbor haha... eased in part by a little Cisco > initiative called Clean Pipes 2.0 :) Is this really true? I've seen the white paper, I've been told that the this is the best way forward from the Guard, but I must say that I'm not yet totally convinced. The Guard product was something that can be separated from the Cisco Detection approach, i.e. one can activate the Guard via a means that did not necessarily involve the Detectors being the source of the activation, this doesn't seem to be true for the Arbor alternative (I believe that the TMS requires registering against the rest of the PeakFlow platform). The other thing that we noted relating to the platform is that there's nothing really "new" in the TMS (other than of course, much increased scrubbing rates!) compared to the Guard. There doesn't appear to be any direct comparison to the 'strong' scrubbing mode that the Cisco Guard implemented - whereby the device would proxy a bunch of traffic. If you're an SP who has some existing NetFlow solution, and don't really justify a spend for traffic intelligence within your network (or have something home-grown), is there an alternative scrubber that one might be able to use in a more standalone deployment that can approach the filtering levels of the Arbor kit? I should probably point out that we only really started our conversation with Arbor within the last month or so, so there are perhaps details relating to this that I've missed. I'd be happy to be corrected! Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html From jeffrey.lyon at blacklotus.net Tue Jan 5 08:59:29 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 5 Jan 2010 09:59:29 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <55A91979-A03E-466B-8A4F-4C276E68443B@eng.gxn.net> References: <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> <55A91979-A03E-466B-8A4F-4C276E68443B@eng.gxn.net> Message-ID: <16720fe01001050659v6f7f76bfw870f41b4962d22bf@mail.gmail.com> My somewhat educated opinion on the matter is that appliance developers want to sit on the edge and see all your traffic merely to protect their own interests and market share. NS-5000s have been good to us for bulk filtering and we rely on appliances for more intelligent inspection. Dollar for dollar NS is substantially more robust in my experience. Best regards, Jeff On Jan 5, 2010 9:46 AM, "Rob Shakir" wrote: (Resent, sorry for multiple copies -- I messed up from From: address) On 5 Jan 2010, at 06:16, Stefan Fouant wrote: >> >> That said, what are all those ISPs doing now th... Is this really true? I've seen the white paper, I've been told that the this is the best way forward from the Guard, but I must say that I'm not yet totally convinced. The Guard product was something that can be separated from the Cisco Detection approach, i.e. one can activate the Guard via a means that did not necessarily involve the Detectors being the source of the activation, this doesn't seem to be true for the Arbor alternative (I believe that the TMS requires registering against the rest of the PeakFlow platform). The other thing that we noted relating to the platform is that there's nothing really "new" in the TMS (other than of course, much increased scrubbing rates!) compared to the Guard. There doesn't appear to be any direct comparison to the 'strong' scrubbing mode that the Cisco Guard implemented - whereby the device would proxy a bunch of traffic. If you're an SP who has some existing NetFlow solution, and don't really justify a spend for traffic intelligence within your network (or have something home-grown), is there an alternative scrubber that one might be able to use in a more standalone deployment that can approach the filtering levels of the Arbor kit? I should probably point out that we only really started our conversation with Arbor within the last month or so, so there are perhaps details relating to this that I've missed. I'd be happy to be corrected! Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html From rdobbins at arbor.net Tue Jan 5 09:19:19 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 15:19:19 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001050659v6f7f76bfw870f41b4962d22bf@mail.gmail.com> References: <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> <55A91979-A03E-466B-8A4F-4C276E68443B@eng.gxn.net> <16720fe01001050659v6f7f76bfw870f41b4962d22bf@mail.gmail.com> Message-ID: <5AC6537F-215C-4426-801C-C2E6A25970B8@arbor.net> On Jan 5, 2010, at 9:59 PM, Jeffrey Lyon wrote: > My somewhat educated opinion on the matter is that appliance developers want to sit on the edge and see all your traffic merely to protect their own interests and market share. This isn't generally a smart approach; the value of providing maximum topological coverage and the ability to oversubscribe the system by moving inwards a bit from the edge provides clear advantages, in most circumstances. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From martin at theicelandguy.com Tue Jan 5 09:50:56 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 5 Jan 2010 10:50:56 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst wrote: > Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned > several times but they haven't been responsive to literature requests > (hint, > if anybody from Arbor is looking...). Our current upstream is 3x GigE from > 3 different providers, each landing on their own BGP endpoint feeding a > route-reflector core. > > I see two possible solutions: > - Netflow/sFlow/***Flow feeding a BGP RTBH > - Inline device > > - Outsource to service provider Netflow can lag a bit in detection. I'd be concerned that inline devices > add an additional point of failure. I'm worried about both failing-open > (e.g. network outage) and false-positives. > How often are you getting DDoS'd? The financials of using a managed service provider vs. buy-all-your-own-grrovy-stuff can be fairly compelling especially if the amount of DDoS you experience is almost nil. Re: Arbor. I don't have any recent experience, but they've been around for a long time, have a very experienced team that understands ISP and enterprise and the product is mature. Hard to go wrong if you can justify the costs. YMMV. Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From nanog at shreddedmail.com Tue Jan 5 09:55:03 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Tue, 5 Jan 2010 07:55:03 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: I looked at one of the suggested out-sourced providers. Based on a sample size of 1, the mitigating mechanisms are DNS redirection and BGP/tunneling. While both of these solutions may be useful for an end-user (even large ones), I don't see them fitting in an SP environment. "If something goes wrong, I want my own, local, big-red button." Rick On Tue, Jan 5, 2010 at 7:50 AM, Martin Hannigan wrote: > > > On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst wrote: > >> Looking for D/DoS mitigation solutions. I've seen Arbor Networks >> mentioned >> several times but they haven't been responsive to literature requests >> (hint, >> if anybody from Arbor is looking...). Our current upstream is 3x GigE >> from >> 3 different providers, each landing on their own BGP endpoint feeding a >> route-reflector core. >> >> I see two possible solutions: >> - Netflow/sFlow/***Flow feeding a BGP RTBH >> - Inline device >> >> > > - Outsource to service provider > > > Netflow can lag a bit in detection. I'd be concerned that inline devices >> add an additional point of failure. I'm worried about both failing-open >> (e.g. network outage) and false-positives. >> > > How often are you getting DDoS'd? > > The financials of using a managed service provider vs. > buy-all-your-own-grrovy-stuff can be fairly compelling especially if the > amount of DDoS you experience is almost nil. > > Re: Arbor. I don't have any recent experience, but they've been around for > a long time, have a very experienced team that understands ISP and > enterprise and the product is mature. Hard to go wrong if you can justify > the costs. YMMV. > > Best, > > -M< > > > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants > > From rdobbins at arbor.net Tue Jan 5 09:55:22 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 15:55:22 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <55A91979-A03E-466B-8A4F-4C276E68443B@eng.gxn.net> References: <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> <55A91979-A03E-466B-8A4F-4C276E68443B@eng.gxn.net> Message-ID: On Jan 5, 2010, at 9:44 PM, Rob Shakir wrote: > If you're an SP who has some existing NetFlow solution, and don't really justify a spend for traffic intelligence within your network (or have something home-grown), is there an alternative scrubber that one might be able to use in a more standalone deployment that can approach the filtering levels of the Arbor kit? One thing folks can do is to implement S/RTBH and/or flow-spec at the edges, then take some Intel boxes, throw some high-performance network cards in them, along with Snort-inline, and put them in a scrubbing center, making use of BGP diversion/re-injection to get traffic into them on an as-needed basis. Don't make use of the useless bidirectional/stateful 'IPS' signatures, but do manual filtering on a case-by-case basis, unidirectionally. Below that, put a layer of WCCPv2-clustered Squid proxies to provide additional layer-7 filtering capabilities for Web-based traffic. Below that, re-inject the scrubbed traffic and send it on its way via one's redirection mechanism of choice to the destination servers. Does this 'poor man's IDMS' do everything and scale to the degree of the various commercial systems? No, of course not. But it's a way to get into layer-4-plus dynamic DDoS mitigation in a relatively economical way (at least from a capex perspective); for some folks, this type of solution may prove sufficient to needs, keeping in mind the limitations of this approach and the systems integration/support burden involved, of course. And even if/when it's clear more advanced capabilities are needed, starting out this way, even in a limited PoC, provides valuable operational experience with the diversion/re-injection model which will prove useful in evaluating more advanced commercial systems an an appropriate juncture. > I should probably point out that we only really started our conversation with Arbor within the last month or so, so there are perhaps details relating to this that I've missed. I'd be happy to be corrected! There's actually quite a bit more, but short of answering specific questions in an operational context, this kind of vendor-specific discussion is probably well beyond what vendor employees like me (these strictures don't apply to anyone else, mind) can and should in all propriety participate in on nanog-l; please feel free to reach out 1:1 to the Arbor folks you've already been talking with to discuss further, and I'm happy to help out 1:1, as well. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From mksmith at adhost.com Tue Jan 5 09:56:56 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 5 Jan 2010 07:56:56 -0800 Subject: Request for Information - IPv6 Routing Table Snapshots Message-ID: <17838240D9A5544AAA5FF95F8D520316074E7C7E@ad-exh01.adhost.lan> Hello Everyone: I am requesting the assistance of operators who are receiving full IPv6 routing tables from upstream, transit providers. If you could send me a copy of your full IPv6 table, as plain text or whatever format best suits, I would be sincerely grateful. I am doing some preliminary work on a potential NANOG presentation regarding the differences in IPv6 routing tables presentation from various "large" transit providers, because I've seen some oddities in announcement variations between several of them and want to dig deeper. Sadly, I only have two v6 transit providers, although I've had a third in the past and will again in the near future, so I will have 3 tables to compare. It would be good to have as many sample objects as possible. Please note this isn't a matter of looking at the global routing table from a looking glass - I'm interested to see what each provider is presenting to their customer, and extrapolating internal policies and potential pitfalls in the future as IPv6 is deployed in earnest. I have tables from NTT, TWTC and HE already. If you could add to this I would be grateful. Please feel free to contact me directly with any questions or concerns as well. Kind Regards, Mike Smith -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From joelja at bogus.com Tue Jan 5 10:13:44 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 05 Jan 2010 08:13:44 -0800 Subject: Request for Information - IPv6 Routing Table Snapshots In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7C7E@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316074E7C7E@ad-exh01.adhost.lan> Message-ID: <4B436538.2000508@bogus.com> you might take a look at route-views6.routeviews.org last I looked it had 22 neighbors. you can either telnet to it (it's quagga) or look in the archived ribs here: http://archive.routeviews.org/route-views6/bgpdata/ Michael K. Smith - Adhost wrote: > Hello Everyone: > > I am requesting the assistance of operators who are receiving full IPv6 > routing tables from upstream, transit providers. If you could send me a > copy of your full IPv6 table, as plain text or whatever format best > suits, I would be sincerely grateful. > > I am doing some preliminary work on a potential NANOG presentation > regarding the differences in IPv6 routing tables presentation from > various "large" transit providers, because I've seen some oddities in > announcement variations between several of them and want to dig deeper. > Sadly, I only have two v6 transit providers, although I've had a third > in the past and will again in the near future, so I will have 3 tables > to compare. It would be good to have as many sample objects as > possible. > > Please note this isn't a matter of looking at the global routing table > from a looking glass - I'm interested to see what each provider is > presenting to their customer, and extrapolating internal policies and > potential pitfalls in the future as IPv6 is deployed in earnest. > > I have tables from NTT, TWTC and HE already. If you could add to this I > would be grateful. Please feel free to contact me directly with any > questions or concerns as well. > > Kind Regards, > > Mike Smith > > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > From mksmith at adhost.com Tue Jan 5 10:47:45 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 5 Jan 2010 08:47:45 -0800 Subject: Request for Information - IPv6 Routing Table Snapshots In-Reply-To: <4B436538.2000508@bogus.com> References: <17838240D9A5544AAA5FF95F8D520316074E7C7E@ad-exh01.adhost.lan> <4B436538.2000508@bogus.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316074E7C90@ad-exh01.adhost.lan> > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Tuesday, January 05, 2010 8:14 AM > To: Michael K. Smith - Adhost > Cc: nanog at nanog.org > Subject: Re: Request for Information - IPv6 Routing Table Snapshots > > you might take a look at route-views6.routeviews.org > > last I looked it had 22 neighbors. > > you can either telnet to it (it's quagga) or look in the archived ribs > here: > > http://archive.routeviews.org/route-views6/bgpdata/ > Thanks Joel. 15 active peers, by the way. Perhaps now is a good time to plug connecting to the v6 Route Views server... Regards, Mike From jtk at cymru.com Tue Jan 5 11:13:53 2010 From: jtk at cymru.com (John Kristoff) Date: Tue, 5 Jan 2010 11:13:53 -0600 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> Message-ID: <20100105111353.1570ea74@t61p> On Tue, 5 Jan 2010 04:20:51 +0000 "Dobbins, Roland" wrote: > S/RTBH and/or flow-spec are great DDoS mitigation tools which don't > require any further investment beyond the network infrastructure an > operator has already purchased and deployed. These should be the > first mitigation tools anyone deploys; in many cases, they're all > that's needed. I still wish we would have had something like Bellovin's Pushback implemented as a separate protocol rather than flow-spec over BGP, but having lost that battle we have been playing around with a (free) community, but vetted participant, flow-spec over BGP service if folks are interested in trying it out. Just shoot me note offline. You need an ASN, a flow-spec capable router and must be a verifiable admin/sec contact for said ASN (whatever that means :-). Basic idea is for folks who want to receive one or more sets of flow-spec feeds and/or inject things they want others to filter on (limited to your own routes) you can do so. No need for direct peering and like you say Roland, many networks already have all they need to start doing these sorts of things. Please note, we realize there are a variety of issues in implementing this sort of thing, but if we can find a way to make it trustworthy and workable, that is why we're here. Those not familiar with flow-spec can read up: In a nutshell, distributed router filters via BGP. John From bjohnson at drtel.com Tue Jan 5 14:16:58 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 5 Jan 2010 14:16:58 -0600 Subject: I don't need no stinking firewall! Message-ID: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Security Gurus, et al, I have my own idea of what a firewall is and what it does. I also understand what statefull packet inspection is and what it does. Given this information, and not prejudging any responses, exactly what is a firewall for and when is statefull inspection useful? Please respond on-list as I want to have some useful discourse and discussion in the clear. Flamers and Trolls will be disregarded. :) Thank you. - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From rdobbins at arbor.net Tue Jan 5 14:29:01 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 20:29:01 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> On Jan 6, 2010, at 3:16 AM, Brian Johnson wrote: > Given this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? In the most basic terms, a stateful firewall performs bidirectional classification of communications between nodes, and makes a pass/fail determination on each packet based on a) whether or not a bidirectional communications session is already open between the nodes and b) any policy rules configured on the firewall as to what ports/protocols should be allowed between said nodes. Stateful firewalls make good sense in front of machines which are primarily clients; the stateful inspection part keeps unsolicited packets away from the clients. Stateful firewalls make absolutely no sense in front of servers, given that by definition, every packet coming into the server is unsolicited (some protocols like ftp work a bit differently in that there're multiple bidirectional/omnidirectional communications sessions, but the key is that the initial connection is always unsolicited). Putting firewalls in front of servers is a Really Bad Idea - besides the fact that the stateful inspection premise doesn't apply (see above), rendering the stateful firewall superfluous, even the biggest, baddest firewalls out there can be easily taken down via state-table exhaustion; an attacker can craft enough programmatically-generated, well-formed traffic which conforms to the firewall policies to 'crowd out' legitimate traffic, thus DoSing the server. Addtionally, the firewall can be made to collapse far quicker than the server itself would collapse, as the overhead on the state-tracking is less than what the server itself could handle on its own. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From simon at slimey.org Tue Jan 5 14:39:06 2010 From: simon at slimey.org (Simon Lockhart) Date: Tue, 5 Jan 2010 20:39:06 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <20100105203906.GO23204@virtual.bogons.net> On Tue Jan 05, 2010 at 02:16:58PM -0600, Brian Johnson wrote: > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? Not sure I'd call myself a security guru, but... I'm not a great fan of packet filtering firewalls (as opposed to proxy based or application layer firewalls). Generally, I just use stateless ACLs when I need additional network level security. However, they do have one big disadvantage. Say you've got a server where you want to allow outbound HTTP access to anywhere on the Internet, but only SSH inbound from your home DSL. To do this, you'd build an inbound ACL which looks something like: - Allow from home DSL IP to server port 22 - Allow from anywhere port 80 to server - Deny all other traffic. You need the port 80 rule to allow the return traffic from all those outbound connections. However, an enterprising hacker realises that he can create a TCP connection from port 80 on his own box to port 22 on your server. Now, if you change from stateless to stateful ACLs, you add the intelligence that whenever it sees an connection originating from your server to port 80 on the internet, it automatically adds a rule that allows traffic back from the server you're talking to, but not anywhere else. Therefore, your enterprising hacker can no longer connect in. Of course, the other benefit that a stateful inspection firewall can do is pattern matching on undesirable traffic based on signatures Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From dot at dotat.at Tue Jan 5 14:51:47 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 5 Jan 2010 20:51:47 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: On Tue, 5 Jan 2010, Brian Johnson wrote: > > Given this information, and not prejudging any responses, exactly what > is a firewall for and when is statefull inspection useful? Stateful inspection is useful for breaking things in subtle and hard-to-debug ways. http://fanf.livejournal.com/102206.html http://fanf.livejournal.com/95831.html Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From bruns at 2mbit.com Tue Jan 5 14:58:52 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 05 Jan 2010 13:58:52 -0700 Subject: I don't need no stinking firewall! In-Reply-To: <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <4B43A80C.5010002@2mbit.com> On 1/5/10 1:29 PM, Dobbins, Roland wrote: > Putting firewalls in front of servers is a Really Bad Idea - besides > the fact that the stateful inspection premise doesn't apply (see > above), rendering the stateful firewall superfluous, even the > biggest, baddest firewalls out there can be easily taken down via > state-table exhaustion; an attacker can craft enough > programmatically-generated, well-formed traffic which conforms to the > firewall policies to 'crowd out' legitimate traffic, thus DoSing the > server. Addtionally, the firewall can be made to collapse far > quicker than the server itself would collapse, as the overhead on the > state-tracking is less than what the server itself could handle on > its own. The trick is to not track ports/IPs that do not need it. On my combo firewalls (that handle both NATing and serving websites, dns, etc) for example, I'll do a NOTRACK on the LAN side to prevent connections to the firewall itself from taking up valuable table space. It's all how you configure and tweak the firewall. Recommending people run servers without a firewall is bad advice - do you really want your Win2k3 server exposed, SMB, RPC, and all to the world? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From peter.hicks at poggs.co.uk Tue Jan 5 15:01:27 2010 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Tue, 05 Jan 2010 21:01:27 +0000 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <4B43A8A7.9030904@poggs.co.uk> Tony Finch wrote: > Stateful inspection is useful for breaking things in subtle and > hard-to-debug ways. > > http://fanf.livejournal.com/102206.html > http://fanf.livejournal.com/95831.html Is that really stateful inspection? Isn't the SMTP fixup on a PIX an application-level gateway? I *though* most of the world turns SMTP fixup off because it's naff. Peter From jay at west.net Tue Jan 5 15:04:01 2010 From: jay at west.net (Jay Hennigan) Date: Tue, 05 Jan 2010 13:04:01 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <20100105203906.GO23204@virtual.bogons.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <20100105203906.GO23204@virtual.bogons.net> Message-ID: <4B43A941.1050209@west.net> Simon Lockhart wrote: > Generally, I just use stateless ACLs when I need additional network level > security. However, they do have one big disadvantage. Say you've got a server > where you want to allow outbound HTTP access to anywhere on the Internet, but > only SSH inbound from your home DSL. To do this, you'd build an inbound ACL > which looks something like: > > - Allow from home DSL IP to server port 22 > - Allow from anywhere port 80 to server Change the above to: - Allow from anywhere port 80 to server port > 1023 Or better: - Allow from anywhere port 80 to server port > 1023 established > - Deny all other traffic. > > You need the port 80 rule to allow the return traffic from all those outbound > connections. Those outbound connections will originate from a random high port, so just allow those as destination ports on your inbound rule. > However, an enterprising hacker realises that he can create a TCP connection > from port 80 on his own box to port 22 on your server. Not with the above rules. -- 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 bruns at 2mbit.com Tue Jan 5 15:05:06 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 05 Jan 2010 14:05:06 -0700 Subject: I don't need no stinking firewall! In-Reply-To: <4B43A8A7.9030904@poggs.co.uk> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B43A8A7.9030904@poggs.co.uk> Message-ID: <4B43A982.1040503@2mbit.com> On 1/5/10 2:01 PM, Peter Hicks wrote: > Tony Finch wrote: > >> Stateful inspection is useful for breaking things in subtle and >> hard-to-debug ways. > > >> http://fanf.livejournal.com/102206.html >> http://fanf.livejournal.com/95831.html > > Is that really stateful inspection? Isn't the SMTP fixup on a PIX an > application-level gateway? > > I *though* most of the world turns SMTP fixup off because it's naff. > It is a ALG, and a completely braindead one at that. Nothing like trying to figure out what an error message means when its just... XXX ****************************************************** The PIX's fixup for DNS packets have been causing issues on my end too in one setup. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From simon at slimey.org Tue Jan 5 15:06:30 2010 From: simon at slimey.org (Simon Lockhart) Date: Tue, 5 Jan 2010 21:06:30 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <4B43A80C.5010002@2mbit.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <4B43A80C.5010002@2mbit.com> Message-ID: <20100105210630.GP23204@virtual.bogons.net> On Tue Jan 05, 2010 at 01:58:52PM -0700, Brielle Bruns wrote: > It's all how you configure and tweak the firewall. Recommending people > run servers without a firewall is bad advice - do you really want your > Win2k3 server exposed, SMB, RPC, and all to the world? I have an answer to that problem, but not everyone would agree with it [1]. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * [1] That said, when I've had no choice but to use a Win2k3 web server, I've proxy-passed it behind an Apache server. From blakjak at blakjak.net Tue Jan 5 15:07:24 2010 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 6 Jan 2010 10:07:24 +1300 (NZDT) Subject: I don't need no stinking firewall! In-Reply-To: <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: > Stateful firewalls make absolutely no sense in front of servers, given that by definition, every packet coming into the server is unsolicited (some protocols like ftp work a bit differently in that there're multiple bidirectional/omnidirectional communications sessions, but the key is that the initial connection is always unsolicited). > I'm interested by this assertion; surely Stateful Inspection is meant to facilitate the blocking of out-of-sequence packets, ones which aren't part of valid + recognised existing sessions - whilst of course allowing valid SYN session-starters, etc? So thus, there may still be some value in catching 'injected' packets which don't actually belong in a session... ? > Putting firewalls in front of servers is a Really Bad Idea - besides the fact that the stateful inspection premise doesn't apply (see above), rendering the stateful firewall superfluous, even the biggest, baddest firewalls out there can be easily taken down via state-table exhaustion; an attacker can craft enough programmatically-generated, well-formed traffic which conforms to the firewall policies to 'crowd out' legitimate traffic, thus DoSing the server. Addtionally, the firewall can be made to collapse far quicker than the server itself would collapse, as the overhead on the state-tracking is less than what the server itself could handle on its own. > Some might argue that DoS is preferred to the other degrees of risk that many webservers hold... (trying not to point the finger in any one specific direction.) Mark. From dot at dotat.at Tue Jan 5 15:08:28 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 5 Jan 2010 21:08:28 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <4B43A8A7.9030904@poggs.co.uk> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B43A8A7.9030904@poggs.co.uk> Message-ID: On Tue, 5 Jan 2010, Peter Hicks wrote: > > Is that really stateful inspection? Isn't the SMTP fixup on a PIX an > application-level gateway? Well, the bug I described is caused by it not being stateful enough. > I *though* most of the world turns SMTP fixup off because it's naff. Exactly my point :-) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From jshearer at amedisys.com Tue Jan 5 15:08:59 2010 From: jshearer at amedisys.com (Jason Shearer) Date: Tue, 5 Jan 2010 15:08:59 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <4B43A941.1050209@west.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><201001 05203906.GO23204@virtual.bogons.net><4B43A941.1050209@west.net> Message-ID: Doesn't using the established allow any packet with ACK/RST set and wouldn't you have to allow all high ports? Jason -----Original Message----- From: Jay Hennigan [mailto:jay at west.net] Sent: Tuesday, January 05, 2010 3:04 PM To: nanog at nanog.org Subject: Re: I don't need no stinking firewall! Simon Lockhart wrote: > Generally, I just use stateless ACLs when I need additional network level > security. However, they do have one big disadvantage. Say you've got a server > where you want to allow outbound HTTP access to anywhere on the Internet, but > only SSH inbound from your home DSL. To do this, you'd build an inbound ACL > which looks something like: > > - Allow from home DSL IP to server port 22 > - Allow from anywhere port 80 to server Change the above to: - Allow from anywhere port 80 to server port > 1023 Or better: - Allow from anywhere port 80 to server port > 1023 established > - Deny all other traffic. > > You need the port 80 rule to allow the return traffic from all those outbound > connections. Those outbound connections will originate from a random high port, so just allow those as destination ports on your inbound rule. > However, an enterprising hacker realises that he can create a TCP connection > from port 80 on his own box to port 22 on your server. Not with the above rules. -- 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 *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. *** From bruns at 2mbit.com Tue Jan 5 15:15:17 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 05 Jan 2010 14:15:17 -0700 Subject: I don't need no stinking firewall! In-Reply-To: <20100105210630.GP23204@virtual.bogons.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <4B43A80C.5010002@2mbit.com> <20100105210630.GP23204@virtual.bogons.net> Message-ID: <4B43ABE5.2040403@2mbit.com> On 1/5/10 2:06 PM, Simon Lockhart wrote: > > I have an answer to that problem, but not everyone would agree with it [1]. > One of my biggest beefs with some people is that they'll stand there with their fingers in their ears yelling LA LA LA if you point out to them that not every person in the world can use Linux/UNIX/etc. Some businesses _must_ use Windows to support the applications they use. > [1] That said, when I've had no choice but to use a Win2k3 web > server, I've proxy-passed it behind an Apache server. Except that it requires yet another machine to be sold to a customer who already laid out however many thousands of dollars for a server + licenses + CALs + applications. If we already have the firewall, its _very_ hard for me to justify to the customer another chunk of cash for a second firewall just for the server. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mkarir at merit.edu Tue Jan 5 15:18:43 2010 From: mkarir at merit.edu (mkarir) Date: Tue, 5 Jan 2010 16:18:43 -0500 Subject: Request for Information - IPv6 Routing Table Snapshots Message-ID: <9057552C-4024-46BC-9DC4-2C8E7817709D@merit.edu> You could also try asking the BGP bot which has a couple of views. AIM: bgpbotz Jabber: bgpbotz at jabber.research.merit.edu help examples show ip bgp view show bgp view RS-SWITCH ipv6 -manish > Date: Tue, 05 Jan 2010 08:13:44 -0800 > From: Joel Jaeggli > Subject: Re: Request for Information - IPv6 Routing Table Snapshots > To: "Michael K. Smith - Adhost" > Cc: nanog at nanog.org > Message-ID: <4B436538.2000508 at bogus.com> > Content-Type: text/plain; charset=UTF-8 > > you might take a look at route-views6.routeviews.org > > last I looked it had 22 neighbors. > > you can either telnet to it (it's quagga) or look in the archived > ribs here: > > http://archive.routeviews.org/route-views6/bgpdata/ > > Michael K. Smith - Adhost wrote: >> Hello Everyone: >> >> I am requesting the assistance of operators who are receiving full >> IPv6 >> routing tables from upstream, transit providers. If you could send >> me a >> copy of your full IPv6 table, as plain text or whatever format best >> suits, I would be sincerely grateful. >> >> I am doing some preliminary work on a potential NANOG presentation >> regarding the differences in IPv6 routing tables presentation from >> various "large" transit providers, because I've seen some oddities in >> announcement variations between several of them and want to dig >> deeper. >> Sadly, I only have two v6 transit providers, although I've had a >> third >> in the past and will again in the near future, so I will have 3 >> tables >> to compare. It would be good to have as many sample objects as >> possible. >> >> Please note this isn't a matter of looking at the global routing >> table >> from a looking glass - I'm interested to see what each provider is >> presenting to their customer, and extrapolating internal policies and >> potential pitfalls in the future as IPv6 is deployed in earnest. >> >> I have tables from NTT, TWTC and HE already. If you could add to >> this I >> would be grateful. Please feel free to contact me directly with any >> questions or concerns as well. >> >> Kind Regards, >> >> Mike Smith >> >> -- >> Michael K. Smith - CISSP, GSEC, GISP >> Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com >> w: +1 (206) 404-9500 f: +1 (206) 404-9050 >> PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) >> > From jay at west.net Tue Jan 5 15:18:47 2010 From: jay at west.net (Jay Hennigan) Date: Tue, 05 Jan 2010 13:18:47 -0800 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><201001 05203906.GO23204@virtual.bogons.net><4B43A941.1050209@west.net> Message-ID: <4B43ACB7.6040603@west.net> Jason Shearer wrote: > Doesn't using the established allow any packet with ACK/RST set Yes, as would be expected for legitimate return traffic for a TCP connection initiated from a browser inside the firewall. > and wouldn't you have to allow all high ports? That's what the ">" is for. Cisco syntax "gt" (greater than). The point is that either of these will deny unsolicited new connection attempts from the outside to TCP 22 (and 445, 135, etc.) -- 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 jared at puck.nether.net Tue Jan 5 15:20:56 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 5 Jan 2010 16:20:56 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <4B43A80C.5010002@2mbit.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <4B43A80C.5010002@2mbit.com> Message-ID: <66A75BF6-3C4E-4D42-A952-92E65E625747@puck.nether.net> On Jan 5, 2010, at 3:58 PM, Brielle Bruns wrote: > It's all how you configure and tweak the firewall. Recommending people run servers without a firewall is bad advice - do you really want your Win2k3 server exposed, SMB, RPC, and all to the world? Some people think that exposing any functionality by default such as that is a poor security practice :) My biggest issue is that people think that Firewalls, AV, etc are a catch-all for any network/user/security badness. The real world is more complex than that. Most people make poor security choices and this creates much larger issues. "I thought the firewall would protect me". "I thought my IPS would protect me" "I thought my AV would protect me" Most of these technologies create a truly false sense of security. I'm once again reminded of many people who do technically "silly" things like block TCP/53, packets over 512 bytes, port 587, ssl imap ports, etc. It's frustrating and sad because it's not an effective security strategy and frustrates grumpy old-school users as myself that used odi drivers w/ ka9q to multitask over our CSLIP networks. - Jared From rdobbins at arbor.net Tue Jan 5 15:31:48 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 21:31:48 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <4B43A80C.5010002@2mbit.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <4B43A80C.5010002@2mbit.com> Message-ID: On Jan 6, 2010, at 3:58 AM, Brielle Bruns wrote: > It's all how you configure and tweak the firewall. Recommending people > run servers without a firewall is bad advice - do you really want your > Win2k3 server exposed, SMB, RPC, and all to the world? Nope - I use stateless ACLs in hardware, capable of handling mpps. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jan 5 15:33:00 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jan 2010 21:33:00 +0000 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <2E617922-A112-47B5-B5DF-618028DD72DA@arbor.net> On Jan 6, 2010, at 4:07 AM, Mark Foster wrote: > I'm interested by this assertion; surely Stateful Inspection is meant to > facilitate the blocking of out-of-sequence packets, ones which aren't part > of valid + recognised existing sessions - whilst of course allowing valid > SYN session-starters, etc? > > So thus, there may still be some value in catching 'injected' packets > which don't actually belong in a session... ? Nope - the hosts handle this better on their own. > > Some might argue that DoS is preferred to the other degrees of risk that > many webservers hold... (trying not to point the finger in any one > specific direction.) Except that the firewalls don't mitigate any of the other degrees of risk, either. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sam.silvester at gmail.com Tue Jan 5 15:35:14 2010 From: sam.silvester at gmail.com (Sam Silvester) Date: Wed, 6 Jan 2010 08:05:14 +1030 Subject: Query regarding maintenance menu on Liebert PeX units Message-ID: <5b2427f51001051335x69eb2941r44a7aeb8ebc34931@mail.gmail.com> Hi all, Sorry if this isn't the best place to be posting such a question, but I figured there may well be a few aircon experts around. I've got a few Liebert PeX 3100FA units and we're in the process of commissioning some additional units. The installing contractors are trying to hunt down the maintenance menu PIN as it appears there has been a bit of a breakdown of communications between the installing contractors and the distributer who have decided to keep that detail rather close to their chests - I'm trying to short-circuit the process to keep things moving! Offlist is fine to keep the noise down. Thanks, Sam From frnkblk at iname.com Tue Jan 5 15:37:56 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 5 Jan 2010 15:37:56 -0600 Subject: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions) In-Reply-To: <1001050340.AA11448@ivan.Harhan.ORG> References: <1001050340.AA11448@ivan.Harhan.ORG> Message-ID: It's being done by Actelis, Hatteras, and Zhone. More exactly SHDSL or similar variants. The market is being well-served. Frank -----Original Message----- From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] Sent: Monday, January 04, 2010 9:40 PM To: nanog at nanog.org Subject: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions) Frank Bulk - iName.com wrote: > We offer it, but practically speaking we haven't gotten much higher than 1.5 > Mbps on the upstream. Sorry that I'm coming into this thread late (I have just subscribed), but since I see people discussing DSL with beefy upstream, I thought I would be brave and ask: do you esteemed high-end network op folks think that there may be anyone in the world who might be interested in bonded SDSL or not? I have spent the past 5 years of my life learning everything there is to know about SDSL. Don't ask me why, I don't really know the answer to that question myself. I won't waste the bandwidth of this elite list with dirty details of just what I've done with SDSL over the past 5 y, but I'll give a link to an open source project that contains the body of SDSL knowledge amassed over those years: http://ifctfvax.Harhan.ORG/OpenSDSL/ To make the long story short, for most of those years I kept trudging on my project, treating it as an ultra-weird hobby that no one else in the world could possibly have any interest in. That persisted until 2009 when my project got noticed by two fairly major North American DSL network operators. (Well, one very major and one semi-major, but I'll spare the names.) Both of those had contacted me via my Open SDSL Connectivity Project expressing interest in SDSL bonding. Both companies were telling me how much interest they had in SDSL bonding, how much it would help their business to be able to offer bonded SDSL services at 3 or 6 Mbps, how many customers they would be able to sign up for these services, etc. But when I asked them to back their verbally-expressed interest with the tiniest amount of money or even no money at all but a letter of intent which I could show to SBA etc, they both went silent. We've been playing a game of cat-and-mouse ever since. As far as I could understand the existing situation is that the SDSL infrastructure already deployed en masse by the major North American DSL network operators already has the capability to serve out bonded SDSL circuits, bonding either in the DSLAM or somewhere upstream of it, using MLPPP, Multilink Frame Relay or whatever else one can think of, but the problem is with CPE. Apparently bonding-capable multiport SDSL CPE devices are quite scarce. Considering everything I've done with SDSL over the past 5 y, I believe I have a right to say with confidence that I am more than capable of designing and building a bonding-capable multiport SDSL CPE device for any existing SDSL flavor with any desired number of ports (2, 4 or whatever). But what I don't know, and what I'm asking this highly esteemed list for advice with, is this question: is there anyone at all in the world who might have a real serious interest in such a thing? If there is someone in the world who would truly appreciate having a bonded SDSL solution, I would be delighted to work on developing such a thing. I would see it as a service to humanity whereby more use would be made out of existing copper infrastructure in the ground instead of having to dig more ditches to bury more fiber or whatever. But if there is no one in the world who would be interested in bonded SDSL (or at least interested enough to invest one dime into development), then why bother... MS From herrin-nanog at dirtside.com Tue Jan 5 15:44:31 2010 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 5 Jan 2010 16:44:31 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <3c3e3fca1001051325i176d09f9w2ec8ffdc0964a1a@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <3c3e3fca1001051325i176d09f9w2ec8ffdc0964a1a@mail.gmail.com> Message-ID: <3c3e3fca1001051344l21ac321u36b190c939415fb1@mail.gmail.com> On Tue, Jan 5, 2010 at 3:16 PM, Brian Johnson wrote: > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? A firewall is anything that examines IP packets in-line for the purpose of discarding undesirable packets before they can be interpreted by the transport layer protocol (e.g. TCP) on the endpoint computer. A firewall is usually a computer filling in the same slot as a router in a network topology capable of discarding packets before they can reach the endpoint computer at all. In some cases though, a firewall may be a separate piece of software on the same computer sending or receiving the packet. The purpose of the firewall is to permit the protected equipment to operate with a less thorough (hence less expensive) attention to the network security process. Can't really afford to have a dedicated network security guru for every dozen desktops playing big brother with what software the users are using so you focus your attention on the border instead. Stateful inspection is useful when you want the firewall to discard any packets which are not part of a communications session that the firewall understands and has approved. By contrast, packet filtering will only discard those packets explicitly deemed bad. At a practical level, the above distinction can be a noop. Internal machines are usually incapable of acting on packets the packet filter will unintentionally pass, such as IP fragments without the first fragment. Stateful address-overloaded NAT offers additional protection over stateful inspection alone in that the firewall naturally "fails closed." That is, a malfunctioning firewall will drop acceptable packets rather than allow bad ones. This is "defense in depth." An error in the filtering process still leaves the firewall with no idea which internal machine to transmit the errantly cleared packet to; that information was only available as part of the session state. By contrast, stateful, packet filtering and non-overloaded NAT firewalls are always able to send the packet to an internal machine once it passes the filtering rules. This last is part of what makes the little "DSL routers" such useful weapons in the network security professional's arsenal. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From henry at AegisInfoSys.com Tue Jan 5 15:55:22 2010 From: henry at AegisInfoSys.com (Henry Yen) Date: Tue, 5 Jan 2010 16:55:22 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <4B43ACB7.6040603@west.net>; from Jay Hennigan on Tue, Jan 05, 2010 at 13:18:47PM -0800 References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><201001 <4B43ACB7.6040603@west.net> Message-ID: <20100105165522.A31930@AegisInfoSys.com> On Tue, Jan 05, 2010 at 13:18:47PM -0800, Jay Hennigan wrote: > Jason Shearer wrote: > > Doesn't using the established allow any packet with ACK/RST set > > Yes, as would be expected for legitimate return traffic for a TCP > connection initiated from a browser inside the firewall. > > > and wouldn't you have to allow all high ports? > > That's what the ">" is for. Cisco syntax "gt" (greater than). One could also use reflexive access lists, which are much better than static lists, although that takes you back to stateful. It is possible to combine them both to achieve a mostly stateless setup while still having better overall security. > The point is that either of these will deny unsolicited new connection > attempts from the outside to TCP 22 (and 445, 135, etc.) -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York (800) 234-4700 From fred at cisco.com Tue Jan 5 16:08:57 2010 From: fred at cisco.com (Fred Baker) Date: Tue, 5 Jan 2010 14:08:57 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: The primary value of a firewall is two-fold: - It enables a network administrator to define his "edge", the interior of which he is responsible for. - It enables a network administrator to isolate his network from externally-originated traffic per his whims and viewpoints. IMHO, it is not a security solution per se; it is comparable perhaps to human skin - keeping certain stuff out to limit the need to use other tools that one uses internally. That said, the tools one uses to create true security are a combination of network-based detection/ analysis equipment like honeypots, router configurations, and sensors, and host-based security technologies. In the final analysis, the hosted application is responsible for its own security (if some attacker threads the needle, it had better be able to handle the attack), and uses host and network facilities as defense-in-depth (the less it has to worry about that the more effective overall security is). On Jan 5, 2010, at 12:16 PM, Brian Johnson wrote: > Security Gurus, et al, > > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? > > Please respond on-list as I want to have some useful discourse and > discussion in the clear. Flamers and Trolls will be disregarded. :) > > Thank you. > > - Brian > > > CONFIDENTIALITY NOTICE: This email message, including any > attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are > not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the > original message. Thank you. > http://www.ipinc.net/IPv4.GIF From msokolov at ivan.Harhan.ORG Tue Jan 5 16:34:55 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Tue, 5 Jan 2010 22:34:55 GMT Subject: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions) Message-ID: <1001052234.AA13652@ivan.Harhan.ORG> Frank Bulk - iName.com wrote: > It's being done by Actelis, Hatteras, and Zhone. More exactly SHDSL or ^^^^^^^^^^^^^^^^^^^^^ > similar variants. The market is being well-served. ^^^^^^^^^^^^^^^^^ The highlighted sentence is precisely the difference between what they are doing and what I am doing. The SHDSL folks seem to live in some kind of fantasy world where they think that all major network operators are going to throw out all their SDSL/2B1Q infrastructure and install SHDSL DSLAMs across the country instead. My SDSL work on the other hand is oriented toward working with the existing SDSL/2B1Q infrastructure massily deployed across USA by networks like Covad and what used to be DSL.net (now part of MegaPath). My Open SDSL Connectivity Project has successfully reverse-engineered the proprietary SDSL/2B1Q flavors used by the DSLAM brands deployed by the two networks named above, and I want to build bonded SDSL CPE for those flavors/networks. And yes, I have already had discussions with some people at both of the named companies. It wasn't even necessary for me to initiate contact with them as both of them have sought my open source project out and contacted me on their own about this very idea of SDSL bonding. However, despite lots of excited talk, both dialogues have ended with a mutter. Apparently there is some kind of wall of arrogance that prevents those folks from even considering getting their CPE from a mosquito like me, even though I can deliver it for one-tenth to one-hundredth of what the big vendors would want for the same thing if they would even consider building such - those big vendors have plenty of their own arrogance! Therefore, my next angle of approach is to see if there are any ISPs who go through Covad or through MegaPath's ex-DSL.net component as their Layer 2 transport (I know that at least in Covad's case there is a huge number of ISPs large and small who do that) and who want bonded SDSL badly enough to punch through that wall of arrogance. If you are an ISP who rents Layer 2 transport from Covad and I were to supply you the CPE, I think you should be able to serve bonded SDSL to your customers without having to beg Covad to descend from the heavens and give that service its blessing. Just order 2 (or 3 or 4 or however many loops you want to bond) ATM transport pipes from Covad terminating at your customer's address on one end and at your DS3/ATM interconnection point on the other end. Have your Cisco/Redback/whatever router run PPPoA on each of those ATM pipes and do MLPPP bonding between them. All that would be needed then is the CPE, and that's what the Open SDSL Connectivity Project is for... MS From sean at donelan.com Tue Jan 5 16:36:01 2010 From: sean at donelan.com (Sean Donelan) Date: Tue, 5 Jan 2010 17:36:01 -0500 (EST) Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: On Tue, 5 Jan 2010, Fred Baker wrote: > The primary value of a firewall is two-fold: > > - It enables a network administrator to define his "edge", the interior of > which he is responsible for. > - It enables a network administrator to isolate his network from > externally-originated traffic per his whims and viewpoints. Actually, a firewall is so the "security administrator" can intervene between the network administrator and the system administrator to impose controls on both because they didn't prevent something themselves. It sounds like of beginning of a joke, a network administrator, system administrator and security administrator walk into a bar ... A statefull firewall is most useful for *outbound* traffic, inbound traffic controls usually break things that depend on maintaining state. Of course, if you want outbound traffic from your web server, its no longer just a web server. Its some mongrel type of client/server. Likewise a IDS/IPS/AV/Anti-X box is no longer just a stateful firewall, its some kind of mongrel security device. Simple ACLs can keep stuff out, or keep stuff in. Stateful things are only needed when you want to keep track of things you sent outbound, so you can let (hopefull) the same thing back inbound. > IMHO, it is not a security solution per se; it is comparable perhaps to human > skin - keeping certain stuff out to limit the need to use other tools that > one uses internally. That said, the tools one uses to create true security > are a combination of network-based detection/analysis equipment like > honeypots, router configurations, and sensors, and host-based security > technologies. In the final analysis, the hosted application is responsible > for its own security (if some attacker threads the needle, it had better be > able to handle the attack), and uses host and network facilities as > defense-in-depth (the less it has to worry about that the more effective > overall security is). Your "simple", "verifiable", "etc" security devices then become something even more complex than the systems they are supposedly are protecting. With that additional complexity comes additional risks that the security device itself has flaws. Adding NAT/PAT/state/DNS proxy creates its own problems and many protocol hacks, often requiring even more complexity to "fix" what you broke. I blame Bellovin & Cheswick for firewalls :-) There are some subtle points in their early papers I'm still learning. Yes, statefull firewalls can be usefull. But too often security professionals suffer from the I have a hammer syndrome. They break everything with a single tool, even stuff that may be better without it. Security should worry about all the letters in C-I-A. From kenny.sallee at gmail.com Tue Jan 5 16:45:54 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 5 Jan 2010 14:45:54 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <4a80ecce1001051445k3cdee7b0n6215273e19e865ed@mail.gmail.com> On Tue, Jan 5, 2010 at 12:16 PM, Brian Johnson wrote: > Security Gurus, et al, > > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? > > Please respond on-list as I want to have some useful discourse and > discussion in the clear. Flamers and Trolls will be disregarded. :) > > Thank you. > > - Brian > > > To me - a firewall is just another layer of security to help protect company/personal assets. Firewalls, AV, IPS, OS patches, physical security, educated users etc. etc...all play a part in protecting what you own and what you data you have from 'bad guys'. Where to place firewalls depends on what you are protecting. If regular humans (ie consumers) stateful packet firewalls are smart (although NAT does provide a level of security - and I know there will be arguments against that). If business assets - it depends on scale and traffic. If you have a small to medium business with a T1 - a smart network engineer can us ACL's to protect your assets but stateful firewalls are fairly cheap so why not use them? If you are running gigabits worth of traffic then a stateful firewall is a bad thing but layered protection is still important. DDOS defenses of some form is part of that layered protection (scale to handle DDOS, work w/ upstream providers etc..) . So I guess my answer is - it just depends on the business, traffic patterns, $$, and skill sets of the engineers or consultants you hire. But I do agree - firewalling or protection of assets is a necessity no matter what your size or scale from a practical and most likely regulatory perspective. So now I get to rant - becuase I think that 'security guru's' are one-tracked minded. Often times - in larger organizations the executives are the largest FUD mongers. This lead to hiring a 'Security Guru'. The 'Security Guru' convinces said executives that the sky is falling. Executives fear for their jobs and company assets and the next thing you know - all innovation and flexibility is removed from the employee's in the name of security. It's a really bad thing. Are most users bungholes that require strict security policies - yes. Are they all? No. It's your job to make sure the company is protected enough to continue innovation and making money. You have a tough job I'll give you that - and I wouldn't want it - but you chose your path in life not me! So make it work without stifling the users you are trying to protect! Kenny From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 5 16:49:30 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 6 Jan 2010 09:19:30 +1030 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <20100106091930.2e61194b@opy.nosense.org> On Tue, 5 Jan 2010 14:16:58 -0600 "Brian Johnson" wrote: > Security Gurus, et al, > > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? > First thing to work out is your threat model. Once you've worked out what you're trying to protect, who you're trying to protect it from, and what techniques they're likely use to break that protection, you can then work out if a firewall is the right tool, then work out how many to have and where (network perimeter only, network perimeter + hosts, network perimeter + hosts + in application protection (e.g. authentication like in ssh - remember, it's people that are your real threat, not machines and their IP addresses - those are just the tools people use). The trap is to think technology like firewalls are only thing you need to worry about. Unfortunately they won't stop the building cleaners from lifting things out of the bins under desks. > Please respond on-list as I want to have some useful discourse and > discussion in the clear. Flamers and Trolls will be disregarded. :) > > Thank you. > > - Brian > > > CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original message. Thank you. > From jabley at hopcount.ca Tue Jan 5 17:13:50 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 5 Jan 2010 15:13:50 -0800 Subject: Request for Information - IPv6 Routing Table Snapshots In-Reply-To: <17838240D9A5544AAA5FF95F8D520316074E7C7E@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316074E7C7E@ad-exh01.adhost.lan> Message-ID: <8036A753-BD74-4095-8829-E46B762C7ACF@hopcount.ca> On 2010-01-05, at 07:56, Michael K. Smith - Adhost wrote: > I am doing some preliminary work on a potential NANOG presentation > regarding the differences in IPv6 routing tables presentation from > various "large" transit providers, because I've seen some oddities in > announcement variations between several of them and want to dig deeper. See also . Joe From carlos at race.com Tue Jan 5 17:29:31 2010 From: carlos at race.com (Carlos Alcantar) Date: Tue, 5 Jan 2010 15:29:31 -0800 Subject: Level3 voice rep Message-ID: <859604546CD1FF488BDB6EA94C896AFBAC3928@racexchange.race.local> Does anyone have a level3 tdm voice rep ? that they don't mind sharing thanks in advance. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos at race.com From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 5 17:38:43 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 6 Jan 2010 10:08:43 +1030 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <20100106100843.13e37bd4@opy.nosense.org> On Tue, 5 Jan 2010 20:51:47 +0000 Tony Finch wrote: > On Tue, 5 Jan 2010, Brian Johnson wrote: > > > > Given this information, and not prejudging any responses, exactly what > > is a firewall for and when is statefull inspection useful? > > Stateful inspection is useful for breaking things in subtle and > hard-to-debug ways. > http://fanf.livejournal.com/102206.html > http://fanf.livejournal.com/95831.html > Your second article (with the pointer to "end-to-end arguments in systems design") reminded me of this thread that came up on the Linux networking development mailing list recently. TCP was flaking out, but if the same traffic was tunnelled over the same connection, all was good. Strange TCP behavior over HSDPA http://www.spinics.net/lists/netdev/msg116809.html > Tony. > -- > f.anthony.n.finch http://dotat.at/ > GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. > MODERATE OR GOOD. > From oberman at es.net Tue Jan 5 18:55:41 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 05 Jan 2010 16:55:41 -0800 Subject: I don't need no stinking firewall! In-Reply-To: Your message of "Tue, 05 Jan 2010 16:20:56 EST." <66A75BF6-3C4E-4D42-A952-92E65E625747@puck.nether.net> Message-ID: <20100106005541.5E3F61CC0B@ptavv.es.net> > From: Jared Mauch > Date: Tue, 5 Jan 2010 16:20:56 -0500 > > On Jan 5, 2010, at 3:58 PM, Brielle Bruns wrote: > > > It's all how you configure and tweak the firewall. Recommending people run servers without a firewall is bad advice - do you really want your Win2k3 server exposed, SMB, RPC, and all to the world? > > Some people think that exposing any functionality by default such as that is a poor security practice :) > > My biggest issue is that people think that Firewalls, AV, etc are a catch-all for any network/user/security badness. The real world is more complex than that. > > Most people make poor security choices and this creates much larger issues. > > "I thought the firewall would protect me". > "I thought my IPS would protect me" > "I thought my AV would protect me" > > Most of these technologies create a truly false sense of security. > > I'm once again reminded of many people who do technically "silly" > things like block TCP/53, packets over 512 bytes, port 587, ssl imap > ports, etc. > > It's frustrating and sad because it's not an effective security > strategy and frustrates grumpy old-school users as myself that used > odi drivers w/ ka9q to multitask over our CSLIP networks. I suspect at least part of this will soon get fixed due to DNSSEC. Blocking tcp/53 and packets over 512 bytes will cause user complaints and, after enough education, the problem will get fixed. I had a problem with a large US government site due to tcp/53 blocking and had no luck getting it fixed. The "Security Officer" informed me that tcp/53 was only ever needed for zone transfer and any other use was clear evidence of abuse. RFCs meant nothing to him. (I don't know if he knew what an RFC was.) Now that gov domains are mandated to be signed, seems like he learned that tcp/53 could be used for normal operations. "You can get more with a kind word and a two-by-four than you can with just a kind word." J. Michael Straczynski from Ceremonies of Light and Dark Babylon 5 -- 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 From mysidia at gmail.com Tue Jan 5 19:56:05 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 5 Jan 2010 19:56:05 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <6eb799ab1001051756k49e2ecc5w8e389b7464283fdd@mail.gmail.com> On Tue, Jan 5, 2010 at 2:16 PM, Brian Johnson wrote: > I have my own idea of what a firewall is and what it does. I also A firewall is a term for a class of device (or software program). Ask different people and you should get different answers, depending on who you ask. Windows firewall... bpf.. ipfw.. iptables... broadband router.. It's not one specific thing, but the description of a role...... The essential characteristic of a firewall is: "a control point", and usually a "central control point" at that. A computer network virtual equivalent of real-world "sally ports" and the access control vestibules you will find at airports, with metal detectors, security guards, etc. You probably won't find security booths at each row of seats on airplanes themselves -- but that's the equivalent of a "host firewall" (a much less useful more expensive control point to maintain, if you have many servers, all subject to attack through the shared network, you definitely want some checkpoints and common firewalls, in addition to host firewalls) A control point is a place that provides the core security functions: * Identification/Classification -- determining the nature of traffic crossing the control point into or out from the protected area * Access Control -- implementing a policy against such classified traffic, to determine who/what/when bits may cross into or out from the protected area, or between different protected areas * Auditing -- logging, making a record of what happened, when, in what direction, evidence collection It is just as much about preventing your compromised server from making improper outbound connections, such as 'port 25' connections to send spam (for a server that is not a mail server), or 'port 22' connections to your other servers in different subnets (e.g. attempts to use a successfully compromised server's trusted IP to leapfrog to other servers in different LAN subnets) Some firewalls do not perform auditing functions, or log to /dev/null, anyways: this is just a log retention time of 0 seconds. If the firewall does not produce logs, then how can you validate the firewall blocks the right things and allows other things? Access control policy might be pre-defined by the manufacturer, or set by an administrator. It might not deny anything, unless asked; it's still a firewall. The ability to quickly set a block with flexible parameters is one of the most significant benefits of having firewalls in place. The depth of "Identification" may vary, depending on the type of check point; searching the packet's luggage thoroughly (DPI) versus just passing it through the metal detector ( protocol type / port number based filters). > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? Stateful inspection is useful for discarding traffic that is not meaningful in the context of a valid connection. In the absence of a stateful firewall, the destination host has to receive the traffic, and make a decision (hopefully) to drop it. If the host has an exploitable condition in its TCP/IP implementation, a stateful firewall may be able to assist, by refusing packets that are invalid, or do not make any sense in the context of any already established connection. So the host never sees them, it never kernel panics, or blue screens, due to the exploit attempt (which would have happened without the firewall). Some stateful firewalls may re-assemble certain fragments, offer protections against teardrop attacks, common SYN floods, simple floods, and the like. So a Firewall can be a good backup safety net against the exploitation of unpatched vulnerabilities. In addition, by restricting management access, a central firewall protects against password guessing attacks, or even, an outsider who (somehow) stole the server password. You might say your system admins are perfect, and always apply all vendor patches, with no mistakes ever, always keep all ports closed except the absolutely required ones, so none of your servers should ever be vulnerable to 15-year-old TCP stack, application issues, or remote exploit of software you didn't know was installed. But reminder: without a safety net, only one mistake is required, for an attacker to (eventually) become a successful intruder. As for patching.. this is only useful, if the vendor knows about the vulnerability, admits the problem, and makes a patch available, before your adversary can take advantage of it. New (as of yet unknown) vulnerabilities may exist in hosts, and thorough validation by the firewall device looking for any funny business can be beneficial, in almost all situations. As long as you size, configure your firewalls appropriately, and protect against problems like state table exhaustion. Size does not equal just bits per second of traffic, but worst-case peak packets per second cleartext+encrypted, worst-case peak connections per second, etc. Probably if you have 100 mail or web servers, you do not want just 2 or 3 firewalls handling all that all by themselves, depending on how much traffic they get, and the need/price of downtime.. -- -J From rsk at gsp.org Tue Jan 5 20:20:31 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 5 Jan 2010 21:20:31 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <20100106022030.GA26925@gsp.org> A firewall is another layer in a defense-in-depth strategy, but tends to only be truly effective if the first rule in it is deny all from any to any which of course does not happen much of the time in the real world, with predictable results. Moreover, stateful packet inspection is not the end-all be-all: there's a lot to be said for application-level proxying, and for quasi-realtime traffic analysis. I think of my firewalls as tools which reduce the overwhelming flood of malicious and garbage traffic to a trickle -- which does not necessarily reduce the attack surface or the threats to it, but may at least allow me a better chance of seeing the threats and doing something useful about them. ---Rsk From robert at timetraveller.org Tue Jan 5 15:24:58 2010 From: robert at timetraveller.org (Robert Brockway) Date: Tue, 5 Jan 2010 16:24:58 -0500 (EST) Subject: I don't need no stinking firewall! In-Reply-To: <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: On Tue, 5 Jan 2010, Dobbins, Roland wrote: > In the most basic terms, a stateful firewall performs bidirectional > classification of communications between nodes, and makes a pass/fail > determination on each packet based on a) whether or not a bidirectional > communications session is already open between the nodes and b) any > policy rules configured on the firewall as to what ports/protocols > should be allowed between said nodes. > > Stateful firewalls make good sense in front of machines which are > primarily clients; the stateful inspection part keeps unsolicited > packets away from the clients. > > Stateful firewalls make absolutely no sense in front of servers, given > that by definition, every packet coming into the server is unsolicited > (some protocols like ftp work a bit differently in that there're > multiple bidirectional/omnidirectional communications sessions, but the > key is that the initial connection is always unsolicited). > > Putting firewalls in front of servers is a Really Bad Idea - besides the Hi Roland. I disagree strongly with this position. > fact that the stateful inspection premise doesn't apply (see above), The problem is that your premise is wrong. Stateful firewalls (hereafter just called firewalls) offer several advantages. This list is not necessarily exhaustive. (1) Security in depth. In an ideal world every packet arriving at a server would be for a port that is intended to be open and listening. Unfortunately ports can be opened unintentionally on servers in several ways: sysadmin error, package management systems pulling in an extra package which starts a service, etc. By having a firewall in front of the server we gain security in depth against errors like this. (2) Centralised management of access controls. Many services should only be open to a certain set of source addresses. While this could be managed on each server we may find that some applications don't support this well, and management of access controls is then spread across any number of management interfaces. Using a firewall for network access control reduces the management overhead and chances of error. Even if network access control is managed on the server, doing it on the firewall offers additional security in depth. (3) Outbound access controls. In many cases we want to stop certain types of outbound traffic. This may contain an intrusion and prevent attacks against other hosts owned by the organisation or other organisations. Trying to do outbound access control on the server won't help as if the server is compromised the attacker can likely get around it. (4) Rate limiting. The ability to rate limit incoming and outgoing data can prevent certain sorts of DoSes. (5) Signature based blocking. Modern firewalls can be tied to intrusion prevention systems which will 'raise the shields' in the face of certain attacks. Many exploits require repeated probing and this provides a way to stop the attack before it is successful. > rendering the stateful firewall superfluous, even the biggest, baddest > firewalls out there can be easily taken down via state-table exhaustion; Do you have any evidence to support this assertion? You've just asserted that all firewalls have a specific vulnerability. It isn't even possible to know the complete set of architectures (hardware & software) used for firewalls so I don't see how you can assert they all have this vulnerability. In any case, my experience tells me that a DDoS will be successful due to exhaustion of available network capacity before it exhausts the state table on the firewall. > an attacker can craft enough programmatically-generated, well-formed > traffic which conforms to the firewall policies to 'crowd out' > legitimate traffic, thus DoSing the server. Addtionally, the firewall > can be made to collapse far quicker than the server itself would > collapse, as the overhead on the state-tracking is less than what the > server itself could handle on its own. Again, I don't believe such a global claim can be made given the wide variety of architectures used for firewalls. Cheers, Rob -- I tried to change the world but they had a no-return policy http://www.practicalsysadmin.com From jmamodio at gmail.com Tue Jan 5 22:04:42 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 5 Jan 2010 22:04:42 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <202705b1001052004n77448a05w1a4995b959a4f08c@mail.gmail.com> - A firewall is a partition structure that normally consists of two side walls with a fire retardant material between them. - A firewall does not prevent a fire. - A firewall does not extinguish a fire. - A firewall only delays the propagation of a fire event to the other side. - The characteristics and properties of each side are independent and not necessary equal. - A firewall eventually gets on fire. - Fire retardant performance is dependent on type of fire and subject to change without notice. - A firewall does not prevent against monkeys with matchboxes. - In the event of a fire locate the nearest exit. - Use the exit and wait in a safe place for the arrival of trained personnel to extinguish the fire. - Clean up the mess and get rid of the monkey. - Apply to computer networks as necessary. Cheers Jorge From rdobbins at arbor.net Tue Jan 5 22:23:28 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 04:23:28 +0000 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> On Jan 6, 2010, at 4:24 AM, Robert Brockway wrote: > Hi Roland. I disagree strongly with this position. You can disagree all you want, but it's still borne out by real-world operational experience. ;> > The problem is that your premise is wrong. Just what about my premise is wrong? Nothing in your message repudiates - or even addresses - a single thing I've said. ;> > Stateful firewalls (hereafter just called firewalls) offer several advantages. Not in front of servers, they don't. Clients, yes. Servers, no. > This list is not necessarily exhaustive. No, it doesn't include all - or even any - of the reasons firewalls are inappropriate for placement in front of servers, not by a long shot. ;> > (1) Security in depth. In an ideal world every packet arriving at a > server would be for a port that is intended to be open and listening. > Unfortunately ports can be opened unintentionally on servers in several > ways: sysadmin error, package management systems pulling in an extra > package which starts a service, etc. By having a firewall in front of the > server we gain security in depth against errors like this. Stateless ACLs in router/switch hardware capable of handling mpps takes care of this. > (2) Centralised management of access controls. Many services should only > be open to a certain set of source addresses. While this could be managed > on each server we may find that some applications don't support this well, > and management of access controls is then spread across any number of > management interfaces. Using a firewall for network access control reduces > the management overhead and chances of error. Even if network access > control is managed on the server, doing it on the firewall offers > additional security in depth. Stateless ACLs in router/switch hardware capable of handling mpps takes care of this. > > (3) Outbound access controls. In many cases we want to stop certain types > of outbound traffic. This may contain an intrusion and prevent attacks > against other hosts owned by the organisation or other organisations. > Trying to do outbound access control on the server won't help as if the > server is compromised the attacker can likely get around it. Stateless ACLs in router/switch hardware capable of handling mpps takes care of this. > (4) Rate limiting. The ability to rate limit incoming and outgoing data > can prevent certain sorts of DoSes. Rate-limiting during a DDoS - i.e., an attack against state and *capacity* - is absolutely the *worst* thing one can possibly do, in almost all circumstances. Yet another security myth which is easily disproved via hands-on operational experience. > (5) Signature based blocking. Signatures are obsolete before they're ever created; 15 years of firewalls and so-called IDS/'IPS', and the resultant hundreds of millions of botted hosts, pretty much put paid to this canard. > Modern firewalls can be tied to intrusion > prevention systems which will 'raise the shields' in the face of > certain attacks. These systems are worse than useless, they're actively harmful; they form DDoS chokepoints themselves, drastically increase the attack surface, and can also be gamed. > Many exploits require repeated probing and this provides a way to stop the attack before it is successful. In the same way that powering off the server ensures perfect confidentiality and integrity of its data, applications, and services. ;> > Do you have any evidence to support this assertion? Yes - many years of watching the biggest, baddest firewalls choke and die under trivial DDoS. Including the better part of a decade working for the largest firewall vendor in the world. > You've just asserted that all firewalls have a specific vulnerability. No, I've asserted that all stateful firewalls created in the history of the world to date, commercial or open-source, are based upon a specific *fundamental architectural premise* which precludes their placement in front of servers. This isn't the same as saying they've a *vulnerability*. I'm saying they're unsuited to be placed in front of servers. > I don't see how you can assert they all have this > vulnerability. Again, I'm not asserting they've a vulnerability. I'm asserting that it doesn't make much sense to pound nails with a monkey-wrench. ;> > In any case, my experience tells me that a DDoS will be successful due to > exhaustion of available network capacity before it exhausts the state > table on the firewall. My experiences defending against DDoS attacks from the 1990s to the present nanosecond indicate otherwise. ;> > Again, I don't believe such a global claim can be made given the wide variety of architectures used for firewalls. Again, *all* stateful firewalls produced to date share a fundamental architectural premise which renders them unsuitable for placement in front of servers. In fact, one major firewall vendor recently implemented a 'stateful inspection bypass' feature as a direct result of this issue; apparently, one is supposed to purchase their $100KUSD 10gb/sec stateful firewall, wedge it into one's network (forcing artificial and undesirable traffic symmetry in order to do so) . . . and then *disable* the stateful inspection one supposedly purchased it to perform in the first place, heh. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From gbonser at seven.com Tue Jan 5 22:43:55 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 5 Jan 2010 20:43:55 -0800 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> > -----Original Message----- > From: nanog-bounces at nanog.org [mailto:nanog-bounces at nanog.org] On > Behalf Of Robert Brockway > Sent: Tuesday, January 05, 2010 1:25 PM > To: NANOG list > > On Tue, 5 Jan 2010, Dobbins, Roland wrote: > > > Putting firewalls in front of servers is a Really Bad Idea - besides > the > > Hi Roland. I disagree strongly with this position. > > > fact that the stateful inspection premise doesn't apply (see above), > > The problem is that your premise is wrong. Stateful firewalls > (hereafter > just called firewalls) offer several advantages. This list is not > necessarily exhaustive. > > (1) Security in depth. In an ideal world every packet arriving at a > server would be for a port that is intended to be open and listening. > Unfortunately ports can be opened unintentionally on servers in several > ways: sysadmin error, package management systems pulling in an extra > package which starts a service, etc. By having a firewall in front of > the > server we gain security in depth against errors like this. Most large operations don't have individual servers accepting incoming traffic. They generally have a farm of servers behind a load balancer. The load balancer itself provides this layer of security. You configure a service on a specific address/port/protocol on the load balancer and bind that to a group of servers on the other side of the balancer. It doesn't matter what you have open on the server, the server is not directly accessible from the Internet. If you don't have the service configured on the load balancer, traffic simply gets dropped on the floor at the front door. Most load balancers these days are even configurable to handle (or not) specifically formatted requests so you can craft ACLs based on the actual requests if you need to. In other words, for all practical purposes these days, the load balancer IS a stateful firewalling proxy. Having another one in front of the load balancer that is simply configured to pass your production traffic to the load balancer is a waste of money and resources in addition to a potential bottleneck. This is particularly true if you are a client/server operation where you are handling traffic on custom ports using custom protocols that a firewall isn't going to know how to inspect anyway. > (2) Centralised management of access controls. Many services should > only be open to a certain set of source addresses. While this could be > managed on each server we may find that some applications don't support this > well, > and management of access controls is then spread across any number of > management interfaces. Using a firewall for network access control > reduces > the management overhead and chances of error. Even if network access > control is managed on the server, doing it on the firewall offers > additional security in depth. > In the case where a service is open to only a certain set of source addresses such as when providing a specific service to a business partner, the ACL can just as easily be configured on the routers at the ingress to your network. Any traffic that you KNOW you are going to drop should be dropped as soon as possible so you don't waste resources forwarding the traffic to the firewall. Ingress ACLs are the best place for that, in my opinion. A modern layer2/3 switch can drop traffic in hardware without a lot of resource consumption. > (3) Outbound access controls. In many cases we want to stop certain > types > of outbound traffic. This may contain an intrusion and prevent attacks > against other hosts owned by the organisation or other organisations. > Trying to do outbound access control on the server won't help as if the > server is compromised the attacker can likely get around it. Yes. Outbound access control IS a valid location for a firewall but that is a separate path from your production service traffic, or at least it probably should be. A modern load balancer is capable of source NATing the traffic so the connections to your server appear to come from the load balancer itself and they can insert a header in the transaction that includes the original connecting IP address of the client so the server still has access to that information if it needs it. When the server needs to initiate an outbound connection, it has a default gateway to a path that eventually leads to a firewall on the way out. > (4) Rate limiting. The ability to rate limit incoming and outgoing > data > can prevent certain sorts of DoSes. This can be done on both the load balancer or the routers depending on the kind of traffic you want to limit. > (5) Signature based blocking. Modern firewalls can be tied to > intrusion > prevention systems which will 'raise the shields' in the face of > certain attacks. Many exploits require repeated probing and this > provides > a way to stop the attack before it is successful. Modern load balancers are capable of this. You can program it for a particular query string, for example, and if you see it, you can ignore it, redirect it, log it, whatever. The line is also blurring in many routers these days between what is a firewall function and what is a router function. IOS, for example, has a large array of firewalling features available. Many of the problems associated with firewalls in your production path aren't going to show themselves if you have less than say a million or two users. When you get to tens of millions of users with literally billions of transactions, things get a little different. I have run a lot of firewalls out of resources over the years ... Netscreens, PIX/ASA, even special purpose units hand-built using OS kernel firewalling. And that is not even in the face of a DoS, that is with normal production traffic. In practically every case the response is the same ... start disabling features on the firewall for the inbound production traffic flow because you are going to allow that anyway. Put any "blocks" on the provider edge ingress ports and drop the traffic before it even gets to the firewall or load balancer. At that point the majority of the traffic through the firewall becomes "allow any eq " for the address/port/protocol of your service VIPs so if you are allowing "any", why are you paying for an extra colo heater? The load balancers these days have methods just as effective as firewalls for dealing with things like syn attacks, they can rate limit requests, they can buffer them, they can drop them, routers can limit icmp. There are a lot of tools in the drawer. Yes, you have to take some of the things that were done in one spot and do them in different locations now, but the results are an amazing increase in service capacity per dollar spent on infrastructure. From nenolod at systeminplace.net Tue Jan 5 22:44:07 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 05 Jan 2010 22:44:07 -0600 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <1262753047.6710.17.camel@petrie> On Tue, 2010-01-05 at 16:24 -0500, Robert Brockway wrote: > On Tue, 5 Jan 2010, Dobbins, Roland wrote: > > > In the most basic terms, a stateful firewall performs bidirectional > > classification of communications between nodes, and makes a pass/fail > > determination on each packet based on a) whether or not a bidirectional > > communications session is already open between the nodes and b) any > > policy rules configured on the firewall as to what ports/protocols > > should be allowed between said nodes. > > > > Stateful firewalls make good sense in front of machines which are > > primarily clients; the stateful inspection part keeps unsolicited > > packets away from the clients. > > > > Stateful firewalls make absolutely no sense in front of servers, given > > that by definition, every packet coming into the server is unsolicited > > (some protocols like ftp work a bit differently in that there're > > multiple bidirectional/omnidirectional communications sessions, but the > > key is that the initial connection is always unsolicited). > > > > Putting firewalls in front of servers is a Really Bad Idea - besides the > > Hi Roland. I disagree strongly with this position. As someone who worked for a startup several years ago working on solving precisely the problem of having a reliable firewall/IDS solution infront of the server, I'm going to have to disagree with your disagreement. > > > fact that the stateful inspection premise doesn't apply (see above), > > The problem is that your premise is wrong. Stateful firewalls (hereafter > just called firewalls) offer several advantages. This list is not > necessarily exhaustive. > > (1) Security in depth. In an ideal world every packet arriving at a > server would be for a port that is intended to be open and listening. > Unfortunately ports can be opened unintentionally on servers in several > ways: sysadmin error, package management systems pulling in an extra > package which starts a service, etc. By having a firewall in front of the > server we gain security in depth against errors like this. > ACLs in the router hardware handle this. Your average datacentre switch, even a small one can handle stateless ACL checks in hardware. Also ACLs don't protect you from the bad guys, especially if you're incompetent. What my team found was that it was infact -impossible- to sanely do DPI infront of a server and also survive a DDoS attack. DDoS attacks are a big problem these days, in case you didn't notice. > (2) Centralised management of access controls. Many services should only > be open to a certain set of source addresses. While this could be managed > on each server we may find that some applications don't support this well, > and management of access controls is then spread across any number of > management interfaces. Using a firewall for network access control reduces > the management overhead and chances of error. Even if network access > control is managed on the server, doing it on the firewall offers > additional security in depth. ACLs in the router hardware handles this. Doing it on a firewall provides no additional security, and may infact decrease network performance and throughput. Additionally, predictive firewalls can be gamed. > > (3) Outbound access controls. In many cases we want to stop certain types > of outbound traffic. This may contain an intrusion and prevent attacks > against other hosts owned by the organisation or other organisations. > Trying to do outbound access control on the server won't help as if the > server is compromised the attacker can likely get around it. ACLs in the router hardware as well as blackholed /32s in the route table of the router handle this. Doing it on a firewall provides no additional security and *will* decrease network performance and throughput. Routers are built for large route tables and make use of RADIX tries and other optimizations that hardware server-oriented firewalls do not typically have. > > (4) Rate limiting. The ability to rate limit incoming and outgoing data > can prevent certain sorts of DoSes. I am not sure what makes you believe that. The ability to rate limit incoming data at the server level would definitely not prevent a DoS. The ability to rate limit outgoing data would cause a DoS of anything other than DoS traffic that is hosted on the server. The basic rule here is "you can't filter more than your port speed", and if your port is getting hit with 1.3gbit of DDoS and your port is only 1gbit, you're still offline. > > (5) Signature based blocking. LOL. Signature based blocking is the biggest scam since the 1980s when IDS technology was first invented. It doesn't work. It is snake oil. The only type of 'signature' that would work would be a list of all known botnet IPs, and you're never going to get that. > Modern firewalls can be tied to intrusion > prevention systems which will 'raise the shields' in the face of > certain attacks. Many exploits require repeated probing and this provides > a way to stop the attack before it is successful. As mentioned above, predictive firewalls can be gamed and cheated to make themselves DoS the downstream network. Keep in mind DoS does not mean the same as "packet flooding", DoS means "denial of service", so if it chokes, service is denied. > > > rendering the stateful firewall superfluous, even the biggest, baddest > > firewalls out there can be easily taken down via state-table exhaustion; > > Do you have any evidence to support this assertion? You've just asserted > that all firewalls have a specific vulnerability. It isn't even possible > to know the complete set of architectures (hardware & software) used for > firewalls so I don't see how you can assert they all have this > vulnerability. It's a known problem with firewalls in general. You have to keep in mind that all firewalls mechanically do the same thing -- they proxy packets from one port to another port depending on various rules. > > In any case, my experience tells me that a DDoS will be successful due to > exhaustion of available network capacity before it exhausts the state > table on the firewall. Adding the firewall infront of a server can reduce network throughput to that server by up to 80% depending on what checks it is doing, and how fast it can do the checks. There are no hardware firewalls that can *really* do DPI at 10GE linerate that I know of, for example. William From jof at thejof.com Tue Jan 5 22:52:49 2010 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 05 Jan 2010 20:52:49 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> Message-ID: <1262752784-sup-6499@sfo.thejof.com> Excerpts from Dobbins, Roland's message of Tue Jan 05 20:23:28 -0800 2010: Roland, On many of the points you've made, I totally agree. Well-managed hardware routers that have support for ACLs in hardware are a great firewall for things that have a relatively small set of rules (e.g. "any:any -> server:80", "server:80 -> any:any"), and come with the added bonus of being able to both firewall and route traffic at whatever speed it forwards at. However, the "well managed" part seems to be a sticking point for most organizations I've seen. No doubt, shops that use this effectively have some sort of homebrew or commercial firewall management platform that let's you place policy in one place and make sure that it's pushed out properly. > Rate-limiting during a DDoS - i.e., an attack against state and *capacity* - is > absolutely the *worst* thing one can possibly do, in almost all circumstances. Why so? Because of something this does to the device doing the rate limiting (I assume an upstream router of some sort), or because it renders the attack successful? > No, I've asserted that all stateful firewalls created in the history of the > world to date, commercial or open-source, are based upon a specific > *fundamental architectural premise* which precludes their placement in front of > servers. I'm not so sure I follow you here. How does a "fundamental architectural premise" (I assume you mean keeping track of application-layer session state) *preclude* it from being placed in front of a server? Sure, it's a poor use of raw silicon and electrical power, but why does that rule out in advance placing it in front of a server? In theory though, someone could construct a massive state-tracking machine that can still keep track of stateful traffic, Mpps and above. Cheers, jonathan From rdobbins at arbor.net Tue Jan 5 22:53:17 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 04:53:17 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> Message-ID: <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> On Jan 6, 2010, at 11:43 AM, George Bonser wrote: > Yes, you have to take some of the things that were done in one spot and do > them in different locations now, but the results are an amazing increase > in service capacity per dollar spent on infrastructure. I strongly agree with the majority of your comments, with the caveat that I've seen many, many load-balancers fall over due to state-exhaustion, too; load-balancers need northbound protection from DDoS (S/RTBH, flow-spec, IDMS, et. al.), as well. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From gbonser at seven.com Tue Jan 5 23:03:51 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 5 Jan 2010 21:03:51 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Tuesday, January 05, 2010 8:53 PM > To: NANOG list > Subject: Re: I don't need no stinking firewall! > > > On Jan 6, 2010, at 11:43 AM, George Bonser wrote: > > > Yes, you have to take some of the things that were done in one spot > and do > > them in different locations now, but the results are an amazing > increase > > in service capacity per dollar spent on infrastructure. > > I strongly agree with the majority of your comments, with the caveat > that I've seen many, many load-balancers fall over due to state- > exhaustion, too; load-balancers need northbound protection from DDoS > (S/RTBH, flow-spec, IDMS, et. al.), as well. > Yes, I have seen load balancers fall over, too. I have some interesting stories of how those problems have been solved. Sometimes it relies on using a feature of one vendor to leverage a feature of another vendor. But I generally agree with you. There is a lot that can be done ahead of the load balancers. From ryan at hack.net Tue Jan 5 23:14:05 2010 From: ryan at hack.net (Ryan Brooks) Date: Tue, 05 Jan 2010 23:14:05 -0600 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <4B441C1D.7070704@hack.net> On 1/5/10 3:24 PM, Robert Brockway wrote: > On Tue, 5 Jan 2010, Dobbins, Roland wrote: > > The problem is that your premise is wrong. Stateful firewalls > (hereafter just called firewalls) offer several advantages. This list > is not necessarily exhaustive. > Great advantages list, but where's the disadvantages list? Here's mine: 1..n) Stateful firewalls go down. It's the very nature of what they do. If you haven't had this problem, then your application is small. Everyone needs to listen to Roland's mantra: "stateless ACLs in hardware than can handle Mpps". It's more than just a hint. From rdobbins at arbor.net Tue Jan 5 23:41:40 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 05:41:40 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <1262752784-sup-6499@sfo.thejof.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> Message-ID: On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote: > However, the "well managed" part seems to be a sticking point for most organizations I've seen. No doubt, shops that use this effectively have some sort of homebrew or commercial firewall management platform that let's you place policy in one place and make sure that it's pushed out > properly. Concur 100% - all the commercial systems which have purported to do this to date have been unusable, miserable failures. Folks tend to use homegrown systems, starting with something as basic as RCS. Tom Ptacek over at Matasano is working on a firewall/ACL rules management system which, given his track record of innovation, one hopes may buck this trend. > Why so? Because of something this does to the device doing the rate limiting (I assume an upstream router of some sort), or because it renders the attack successful? The latter. DDoS attacks are attacks against capacity and/or state. Start reducing capacity, and you end up making it even easier for the attacker's programatically-generated attack traffic to 'crowd out' the legitimate user traffic. It's self-defeating. ;> > I'm not so sure I follow you here. How does a "fundamental architectural > premise" (I assume you mean keeping track of application-layer session > state) *preclude* it from being placed in front of a server? Sure, > it's a poor use of raw silicon and electrical power, but why does that > rule out in advance placing it in front of a server? Because, by definition, all incoming packets to the server are unsolicited. Therefore, it's a waste of money, and also forms a DDoS chokepoint due to the non-infinite state-table which forms the basis for said stateful firewalling. It will fall over and die under any kind of serious attack. > In theory though, someone could construct a massive state-tracking machine that can still keep track of stateful traffic, Mpps and above. See above; in front of the server, there's no state to track in the first place, heh. Fish, meet bicycle. ;> Additionally, it becomes an impractical physics problem (physical dimensions, logic density, power consumption, heat dissipation, et. al.) to construct a device which could even plausibly attempt this due to the extreme capacity/resource asymmetry which favors the attacker (i.e., botnets with thousands, tens of thousands, hundreds of thousands, and even millions of compromised hosts). ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From herrin-nanog at dirtside.com Wed Jan 6 01:45:17 2010 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 6 Jan 2010 02:45:17 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <20100106022030.GA26925@gsp.org> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <20100106022030.GA26925@gsp.org> Message-ID: <3c3e3fca1001052345m152af5acl2ce4379a20072f24@mail.gmail.com> On Tue, Jan 5, 2010 at 9:20 PM, Rich Kulawiec wrote: > A firewall is another layer in a defense-in-depth strategy, but tends > to only be truly effective if the first rule in it is > > ? ? ? ?deny all from any to any Not surprisingly, good network security starts with and incorporates the protected users as its most important element. Start with "deny all" and not only won't they work with you, the more creative among them will teach the others how to work around you. I've seen it over and over again and the faulty design always starts with a deny-all mentality. Can you imagine a deny-all mentality in physical security? I'm sorry sir, you can't leave your house until you justify your need to walk down the street. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Wed Jan 6 01:45:43 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 5 Jan 2010 23:45:43 -0800 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F716C@RWC-EX1.corp.seven.com> > See above; in front of the server, there's no state to track in the > first place, heh. > > Fish, meet bicycle. I think that is the part that some people aren't getting. You have a network just sitting there. A syn packet arrives for port 80 to an http server. You ARE going to allow it because that is what a web server does. Now if you have a firewall in front of the load balancer you have a three-way handshake that goes on with the firewall. Then another one between the firewall and the load balancer. And then possibly yet another one between the balancer and the server if you aren't using persistent connections in that part of the network. So now you get a DoS request that is as simple as "GET /index.html" or worse, some huge file, which you are also going to allow anyway because there is no way to tell a legitimate request from a flood of requests from a bot net or someone posted your link on Slashdot or whatever. So now your web server is flooded with "legitimate" requests that pass all of your policy but you are being overwhelmed by the sheer volume of them and they are originating from thousands of IP addresses from all around the world. They are all getting through your firewall. So now it is just a matter of which is the weakest link in the chain. If you have enough servers and bandwidth, the firewall is often that weakest link. From mysidia at gmail.com Wed Jan 6 01:47:24 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 6 Jan 2010 01:47:24 -0600 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> Message-ID: <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> On Tue, Jan 5, 2010 at 11:41 PM, Dobbins, Roland wrote: > On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote: > DDoS attacks are attacks against capacity and/or state. ?Start reducing DDoS, by its very nature is a type of attack that dances around common security measures like conventional firewalls, by its very nature. The possibility of someone dropping a nuke on your facility, shouldn't stop you from locking your doors at night. If necessary, use another arrangement to detect that threat, and protect firewall+servers from it. Having no 'firewall' type safeguard at all (stateless or otherwise) would appear pretty risky. > Because, by definition, all incoming packets to the server are unsolicited. For UDP servers sure.. not for TCP.. the initial SYN is unsolicited, for inbound TCP connections. Once the server acknowledges the connection by invoking accept(), the rest of it the packets are solicited, the packets are either part of an active connection, or unwanted. There are other types of noise, 'stealth port scans', port 25, 445, 139, 22 probes, DNS cache poisoning attempts, and sequence prediction, TCP connection hijacking attempts, TCP Reset attempts, LAND attacks, that firewalls protect against (through port randomization), etc. >[...]and also forms a DDoS chokepoint due to the non-infinite state-table which >forms the basis for said stateful firewalling. The number of states which can be required is not infinite, it's really only a question of how efficient your equipment can be, if you can find suitable choices for your stateful gear. Even if your firewall has a whole 1 gigabit connection, find some stateful firewall, that can efficiently track a maximum of at least 22,321,500 X2 states. (For 100 megabits, a much smaller table will do) Set the connection timeout to an idle time of 15 seconds, so a connection expires if a packet is not received in 15 seconds. The line rate of Gigabit Ethernet is < 1/((0.096+0.064+0.512)*10^-6) => 1488096 pps in each direction. So, even if every single packet is the SYN for a valid new connection, you will not exceed the maximum size of the table based on that rate. In the worst case, you receive 22321440 packets over 15 seconds. On the 16th second, 1488096 connections expire and 1488096 connections are added, since every packet was a new connection. Now relax your timeout reqs according to your preferences _real world_ estimates of maximum connection rate.... "Overflowing the state table" then becomes only a possible outcome that has some acceptable level of probability, assuming that your other protections have already failed... -- -J From nenolod at systeminplace.net Wed Jan 6 02:03:20 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 06 Jan 2010 02:03:20 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> Message-ID: <1262765000.6710.26.camel@petrie> On Wed, 2010-01-06 at 01:47 -0600, James Hess wrote: > On Tue, Jan 5, 2010 at 11:41 PM, Dobbins, Roland wrote: > > On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote: > > DDoS attacks are attacks against capacity and/or state. Start reducing > > DDoS, by its very nature is a type of attack that dances around > common security measures like conventional firewalls, by its very > nature. > > The possibility of someone dropping a nuke on your facility, > shouldn't stop you from locking your doors at night. > If necessary, use another arrangement to detect that threat, and > protect firewall+servers from it. > DDoS mitigation gear tends to choke up in my experience. It's a really touchy subject. > Having no 'firewall' type safeguard at all (stateless or otherwise) > would appear pretty risky. Not really, because firewalls don't do anything useful. Stateless ACL policies do something useful, and usually that is handled in the router in a modern network. The other features of a firewall range from not so useful to actively harmful. > > > Because, by definition, all incoming packets to the server are unsolicited. > > For UDP servers sure.. not for TCP.. the initial SYN is unsolicited, > for inbound TCP connections. Once the server acknowledges the > connection by invoking accept(), the rest of it the packets are > solicited, the packets are either part of an active connection, or > unwanted. Wrong. You seem to assume that TCP stacks are well-behaved, or that botnets aren't just synthesizing junk. I've seen unsolicited ACK floods before. They are quite real. So, in fact, all incoming packets should be considered unsolicited until proven otherwise. It should be mentioned that DDoS mitigation gear in use on that network let those packets through without even alerting us about it. William From rdobbins at arbor.net Wed Jan 6 02:12:46 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 08:12:46 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> Message-ID: <39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> On Jan 6, 2010, at 2:47 PM, James Hess wrote: > "Overflowing the state table" then becomes only a possible > outcome that has some acceptable level of probability, assuming > that your other protections have already failed... Wrong. The attacker just programmatically generates semantically-valid traffic which is indistinguishablle from real traffic, and crowds out the real traffic. All those fancy timers and counters and what-not don't matter. I've seen it done over and over again. Why some folks seem to think this is theoretical or that I somehow haven't thought of something they think will prove to be a magic solution is really beyond me, heh. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nathan at atlasnetworks.us Wed Jan 6 02:17:54 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 6 Jan 2010 00:17:54 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment Message-ID: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> Greetings, LONG VERSION: I have recently inherited the management of an undocumented network (failed FTTH provider) which utilizes World Wide Packets' LightningEdge 427 (16 port GBIC switch) and 311v (24/4 port Ethernet/GBIC switch) switches. We've swapped out a 427 so that we can rebuild it, push it back into the network, and repeat, until everything is under our control. Trouble is, the lack of documentation extends to passwords, the nature of which preclude any hope of getting in to the switch without resetting to defaults. Fortunately, I can do this without issue, since it is not in active service. I reset a spare 311v to defaults, but cannot log in to it with any of the logical default passwords. I can only assume the same will be true of the 427. Sadly, it seems World Wide Packets is now owned by a new company, who will not provide simple documentation without a full support contract. I got them to grudgingly provide the documentation for the customer premise devices (LightningEdge 47's), but my pleas for the switch documentation (and the management software that I believe WWP provided for free) has fallen on deaf ears. I don't have the budget to blow on a support contract just to get one default password (Who would?). SHORT VERSION: Does anyone know the default passwords for World Wide Packets 427 and 311v switches? I will most definitely owe anyone with an answer a beer or four next time they visit Seattle. By the way, the default username/password for the LightningEdge 47 and other WWP CPEs is su/pureethernet. Hopefully that will save someone else some pain. :-) Best Regards, Nathan Eisenberg From rdobbins at arbor.net Wed Jan 6 02:17:28 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 08:17:28 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <1262765000.6710.26.camel@petrie> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> <1262765000.6710.26.camel@petrie> Message-ID: <6F4BDE00-7659-4616-BAC2-F3224541DF9D@arbor.net> On Jan 6, 2010, at 3:03 PM, William Pitcock wrote: > So, in fact, all incoming packets should > be considered unsolicited until proven otherwise. Concur - it works this way, as well. At one extreme, completely pathological, at the other extreme, perfectly normal - just faux. ;> > It should be mentioned that DDoS mitigation gear in use on that network let those packets through without even alerting us about it. This is where baselining and anomaly-detection can come into play, along with an understanding of valid/invalid states, if the system is designed correctly, heh. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Wed Jan 6 02:26:25 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 08:26:25 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> Message-ID: On Jan 6, 2010, at 3:17 PM, Nathan Eisenberg wrote: > Does anyone know the default passwords for World Wide Packets 427 and 311v switches? One should think the fact that there are default passwords at all should be a cause for alarm, in and of itself. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sthaug at nethelp.no Wed Jan 6 02:44:43 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 06 Jan 2010 09:44:43 +0100 (CET) Subject: Bonded SDSL In-Reply-To: <1001052234.AA13652@ivan.Harhan.ORG> References: <1001052234.AA13652@ivan.Harhan.ORG> Message-ID: <20100106.094443.74702276.sthaug@nethelp.no> > > It's being done by Actelis, Hatteras, and Zhone. More exactly SHDSL or > > similar variants. The market is being well-served. > ^^^^^^^^^^^^^^^^^ > > The highlighted sentence is precisely the difference between what they > are doing and what I am doing. The SHDSL folks seem to live in some > kind of fantasy world where they think that all major network operators > are going to throw out all their SDSL/2B1Q infrastructure and install > SHDSL DSLAMs across the country instead. I certainly can't speak for all major network operators. However, the operator I work for did just that - threw out all the old SDSL/2B1Q equipment. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nathan at atlasnetworks.us Wed Jan 6 02:44:41 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 6 Jan 2010 00:44:41 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> Message-ID: <11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> > One should think the fact that there are default passwords at all > should be a cause for alarm, in and of itself. I must not have been very clear. I'm resetting these switches to factory defaults using the hardware reset button, and attempting to log in using whatever the factory default passwords are. No cause for alarm - the devices as deployed DO NOT have the default passwords on them (probably... without having the factory default passwords for the devices, it's hard to say...) Anyways, does that make sense? From nathan at atlasnetworks.us Wed Jan 6 02:59:47 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 6 Jan 2010 00:59:47 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> Message-ID: <11B064048F34FD4094CBA16FC04BE219864BC3D9@ex01> After weeks on banging my head on this, I figure it out within an hour of posting it to NANOG. You guys are good luck! For future reference/Google, the factory default password for (at least the LightningEdge 427 - not sure about the 311v yet) these switches is: su/wwp. Obviously, you should change this prior to deployment! Best Regards, Nathan Eisenberg From rdobbins at arbor.net Wed Jan 6 02:57:07 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 08:57:07 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> Message-ID: On Jan 6, 2010, at 3:44 PM, Nathan Eisenberg wrote: > I must not have been very clear. I'm resetting these switches to factory defaults using the hardware reset button, and attempting to log in using whatever the factory default passwords are. Right - what I'm saying is the fact that there are default passwords at all is horribly insecure, and that the vendor in question should be prodded to change this dangerous practice. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From bbillon-ml at splio.fr Wed Jan 6 03:03:49 2010 From: bbillon-ml at splio.fr (Benjamin BILLON) Date: Wed, 06 Jan 2010 10:03:49 +0100 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> Message-ID: <4B4451F5.5060703@splio.fr> Did you try to get in touch with Ciena people? I'm sure they will be comprehensive about how you get their products (not being exactly a customer). You could maybe even get an access to products' documentation without providing S/N: https://portal.ciena.com/AccountRequest/index.aspx?mode=MgsZFb3Brzo= I didn't try myself, but I guess getting the full documentation is worth it. Ben Nathan Eisenberg a ?crit : > Greetings, > > LONG VERSION: > > I have recently inherited the management of an undocumented network (failed FTTH provider) which utilizes World Wide Packets' LightningEdge 427 (16 port GBIC switch) and 311v (24/4 port Ethernet/GBIC switch) switches. We've swapped out a 427 so that we can rebuild it, push it back into the network, and repeat, until everything is under our control. > > Trouble is, the lack of documentation extends to passwords, the nature of which preclude any hope of getting in to the switch without resetting to defaults. Fortunately, I can do this without issue, since it is not in active service. > > I reset a spare 311v to defaults, but cannot log in to it with any of the logical default passwords. I can only assume the same will be true of the 427. > > Sadly, it seems World Wide Packets is now owned by a new company, who will not provide simple documentation without a full support contract. I got them to grudgingly provide the documentation for the customer premise devices (LightningEdge 47's), but my pleas for the switch documentation (and the management software that I believe WWP provided for free) has fallen on deaf ears. I don't have the budget to blow on a support contract just to get one default password (Who would?). > > SHORT VERSION: > > Does anyone know the default passwords for World Wide Packets 427 and 311v switches? > > > I will most definitely owe anyone with an answer a beer or four next time they visit Seattle. By the way, the default username/password for the LightningEdge 47 and other WWP CPEs is su/pureethernet. Hopefully that will save someone else some pain. :-) > > Best Regards, > Nathan Eisenberg > From mpalmer at hezmatt.org Wed Jan 6 03:18:37 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 6 Jan 2010 20:18:37 +1100 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> Message-ID: <20100106091837.GF25450@hezmatt.org> On Wed, Jan 06, 2010 at 08:26:25AM +0000, Dobbins, Roland wrote: > > Does anyone know the default passwords for World Wide Packets 427 and 311v switches? > > One should think the fact that there are default passwords at all should be a cause for alarm, in and of itself. As much as they're a definite security risk, I can't imagine what other option there is. The closest I can come to a solution is to set a random password and flash it using a front-panel LED using morse. - Matt From gbonser at seven.com Wed Jan 6 03:24:51 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 6 Jan 2010 01:24:51 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01><11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F716D@RWC-EX1.corp.seven.com> > Right - what I'm saying is the fact that there are default passwords at > all is horribly insecure, and that the vendor in question should be > prodded to change this dangerous practice. How is that a risk in any way? Considering that one must have physical access to reset the unit to factory default, having physical access pretty much trumps any other security measure. From rdobbins at arbor.net Wed Jan 6 03:23:01 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 09:23:01 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <20100106091837.GF25450@hezmatt.org> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> Message-ID: On Jan 6, 2010, at 4:18 PM, Matthew Palmer wrote: > The closest I can come to a solution is to set a random password and flash it using a front-panel LED using morse. heh No password at all, operator prompted at the console during startup unless/until he sets one. No IP address, et. al. until a password is set. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Wed Jan 6 03:26:33 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 09:26:33 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F716D@RWC-EX1.corp.seven.com> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01><11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> <5A6D953473350C4B9995546AFE9939EE081F716D@RWC-EX1.corp.seven.com> Message-ID: On Jan 6, 2010, at 4:24 PM, George Bonser wrote: > having physical access pretty much trumps any other security measure. The fact that there's a factory default means that lots of folks won't change it when they configure the unit with an IP address; they follow this with failing to implement iACLs, and it's pw3nt1me! ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From gbonser at seven.com Wed Jan 6 03:43:15 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 6 Jan 2010 01:43:15 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01><11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01><5A6D953473350C4B9995546AFE9939EE081F716D@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F716E@RWC-EX1.corp.seven.com> > -----Original Message----- > > > having physical access pretty much trumps any other security measure. > > The fact that there's a factory default means that lots of folks won't > change it when they configure the unit with an IP address; they follow > this with failing to implement iACLs, and it's pw3nt1me! I suppose it is a philosophical thing with me. I don't believe in protecting people from their own stupidity. If you try to enforce that, you end up with organizations making up their own "default" passwords which can be little better than manufacturer defaults. From nathan at atlasnetworks.us Wed Jan 6 03:49:47 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 6 Jan 2010 01:49:47 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01> Message-ID: <11B064048F34FD4094CBA16FC04BE219864BC3DA@ex01> > Right - what I'm saying is the fact that there are default passwords at > all is horribly insecure, and that the vendor in question should be > prodded to change this dangerous practice. I don't see how there's a security problem with equipment coming from the factory with factory default passwords. In my opinion, a breach caused by a reset of equipment to default configuration/passwords would suggest far more basic security issues, which are not at all mitigated by eliminating the existence of default passwords. I generally try to mitigate the issues further down the stack. I doubt factory default passwords are going anywhere, but even if they did go away, I would still strictly control access to my management interfaces, as well as the reset holes on my equipment, and so I would argue that I would be no more or less secure than I am now. But maybe I'm missing something? Best Regards, Nathan Eisenberg From xaerni at pop.ch Wed Jan 6 04:38:03 2010 From: xaerni at pop.ch (Xaver Aerni) Date: Wed, 6 Jan 2010 11:38:03 +0100 Subject: Blocking only Facebook Apps Message-ID: <45DD2FCA82AA470E875C29FCD9CEC987@telezueri.ch> Hello, We have differents company here, they would only block the Apps from Facebook. Facebook self could be open. It give a methode to block only the Apps by firewall. If we haven't a methode we must block facebook in difference bigger companies... Greetings Xaver Xariffusion Informatik & Telecom Z?richstrasse 10a 8340 Hinwil Switerzland Tel. +41 43 843 7878 +1 707 361 6839 From Steven.Glogger at swisscom.com Wed Jan 6 04:53:04 2010 From: Steven.Glogger at swisscom.com (Steven.Glogger at swisscom.com) Date: Wed, 6 Jan 2010 11:53:04 +0100 Subject: Blocking only Facebook Apps In-Reply-To: <45DD2FCA82AA470E875C29FCD9CEC987@telezueri.ch> References: <45DD2FCA82AA470E875C29FCD9CEC987@telezueri.ch> Message-ID: <1FC8A0BAFBBD9749BB1F06010D23C8A5038A379448@sg000035.corproot.net> hm.. have you tried to analyze how facebook implements those apps and just filters them out by some URL filters or so? -steven > -----Original Message----- > From: Xaver Aerni [mailto:xaerni at pop.ch] > Sent: Wednesday, January 06, 2010 11:38 AM > To: nanog at nanog.org > Subject: Blocking only Facebook Apps > > Hello, > We have differents company here, they would only block the Apps from Facebook. > Facebook self could be open. It give a methode to block only the Apps by firewall. If > we haven't a methode we must block facebook in difference bigger companies... > Greetings > Xaver > > Xariffusion Informatik & Telecom > Z?richstrasse 10a > 8340 Hinwil > Switerzland > Tel. +41 43 843 7878 > +1 707 361 6839 From joe at routespot.com Wed Jan 6 05:01:51 2010 From: joe at routespot.com (Joe Tyson) Date: Wed, 6 Jan 2010 06:01:51 -0500 Subject: Blocking only Facebook Apps In-Reply-To: <45DD2FCA82AA470E875C29FCD9CEC987@telezueri.ch> References: <45DD2FCA82AA470E875C29FCD9CEC987@telezueri.ch> Message-ID: <7b88df5e1001060301u5c05ea8blfdeefb6a0ac8986e@mail.gmail.com> Well, if you can filter by some URL pattern, then block apps.facebook.com. All the applications are served from that domain. On Wed, Jan 6, 2010 at 5:38 AM, Xaver Aerni wrote: > Hello, > We have differents company here, they would only block the Apps from > Facebook. Facebook self could be open. It give a methode to block only the > Apps by firewall. If we haven't a methode we must block facebook in > difference bigger companies... > Greetings > Xaver > > Xariffusion Informatik & Telecom > Z?richstrasse 10a > 8340 Hinwil > Switerzland > Tel. +41 43 843 7878 > +1 707 361 6839 > From ww at styx.org Wed Jan 6 04:38:11 2010 From: ww at styx.org (William Waites) Date: Wed, 6 Jan 2010 11:38:11 +0100 Subject: I don't need no stinking firewall! In-Reply-To: <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: Le 10-01-05 ? 21:29, Dobbins, Roland a ?crit : > Stateful firewalls make absolutely no sense in front of servers, > given that by definition, every packet coming into the server is > unsolicited (some protocols like ftp work a bit differently in that > there're multiple bidirectional/omnidirectional communications > sessions, but the key is that the initial connection is always > unsolicited). Most hosts are in some measure servers and clients. Sometimes a "server" might want to make an outbound connection for a legitimate reason (say a DNS lookup or zone transfer). Sometimes it might be tricked into doing so for nefarious reasons (like the old reverse telnet trick of binding a shell to an outbound tcp connection). A properly configured firewall will prevent latter. -w From john at vanoppen.com Fri Jan 1 19:24:31 2010 From: john at vanoppen.com (John van Oppen) Date: Fri, 1 Jan 2010 17:24:31 -0800 Subject: dark fiber and sfp distance limitations References: <000001ca8a07$cc3749a0$8262d15b@Asus> <4B3CB394.6010604@i6ix.com> <4B3E7561.8050307@nic-naa.net><4B3E7CB1.2090608@tiedyenetworks.com> <4B3E9220.6020307@kenweb.org> <3c3e3fca1001011710l5b1cb5dasb14dc5b1c35fb48@mail.gmail.com> Message-ID: The best OTDR data I have ever gotten prior to signing an agreement for strands is the readings from another pair on the same route. That being said most dark fiber agreements have some sort of minimum performance specifications in them. John van Oppen Spectrum Networks LLC Direct: 206.973.8302 Main: 206.973.8300 Website: http://spectrumnetworks.us -----Original Message----- From: William Herrin [mailto:herrin-nanog at dirtside.com] Sent: Friday, January 01, 2010 5:11 PM To: ML Cc: nanog at nanog.org Subject: Re: dark fiber and sfp distance limitations On Fri, Jan 1, 2010 at 7:24 PM, ML wrote: > Pardon my ignorance in this area but is too much to ask for OTDR data before > signing contracts? ?In addition to data on the make of the fiber if you > wanted to do xWDM in the future. Yes, it's too much to ask. They won't splice your path until you sign the contracts and you can't get useful OTDR and loss readings until the fiber is spliced. You can probably put an escape clause in the contract that lets you exit with little or no cost if the readings aren't good enough after the fact. If you're not time-constrained, you can probably request a pre-check for a modest fee after main splicing but before trenching to your endpoints. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rdobbins at arbor.net Wed Jan 6 06:43:46 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 12:43:46 +0000 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: <15B16716-61B6-4476-9E13-0974473E342E@arbor.net> On Jan 6, 2010, at 5:38 PM, William Waites wrote: > A properly configured firewall will prevent latter. So will stateless ACLs, running in hardware capable of handling mpps. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From ju at netzwerklabor.at Wed Jan 6 07:25:03 2010 From: ju at netzwerklabor.at (juttazalud) Date: Wed, 6 Jan 2010 14:25:03 +0100 Subject: I don't need no stinking firewall! In-Reply-To: <15B16716-61B6-4476-9E13-0974473E342E@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <15B16716-61B6-4476-9E13-0974473E342E@arbor.net> Message-ID: <19510639383.20100106142503@netzwerklabor.at> am Mittwoch, 06. J?nner 2010 um 13:43 schrieb Roland Dobbins: > On Jan 6, 2010, at 5:38 PM, William Waites wrote: >> A properly configured firewall will prevent latter. > So will stateless ACLs, running in hardware capable of handling mpps. How do you define "firewall"? I remember something like "a security concept, comprising a device or set of devices designed to prevent unauthorized access to a computer system or network". ACLs would then just be part of the firewall concept. cheers, jutta From rdobbins at arbor.net Wed Jan 6 07:31:10 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 13:31:10 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <19510639383.20100106142503@netzwerklabor.at> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <15B16716-61B6-4476-9E13-0974473E342E@arbor.net> <19510639383.20100106142503@netzwerklabor.at> Message-ID: <73F65AD6-C3B0-4EC7-8C37-A62C664E37F8@arbor.net> On Jan 6, 2010, at 8:25 PM, juttazalud wrote: > How do you define "firewall"? This threat was about stateful firewalls in particular. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From jared at puck.nether.net Wed Jan 6 07:36:59 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Jan 2010 08:36:59 -0500 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> Message-ID: On Jan 5, 2010, at 4:24 PM, Robert Brockway wrote: > Do you have any evidence to support this assertion? You've just asserted that all firewalls have a specific vulnerability. It isn't even possible to know the complete set of architectures (hardware & software) used for firewalls so I don't see how you can assert they all have this vulnerability. Just about every ddos i've ever been involved in mitigation results in some device labeled "firewall" blowing it's brains and crippling the company further than if they had utilized a more distributed model. When combined with various other layers of mitigation that are either integrated or inline with another device we've spent lots of time troubleshooting which exact device was causing the most trouble. I can't cite specific cases unless my customers say I can, but it's somewhat amusing to watch some C* of a company realize they've wasted money on a device/service that actually made the problem worse in the face of an attack. There are those that might say the protection devices were not properly used, configured, etc... and if that's the case, it reflects the sad state of the lack of maturity of the industry/tech. (Or that it's obsolete). - Jared From jared at puck.nether.net Wed Jan 6 07:42:37 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Jan 2010 08:42:37 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> <39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> Message-ID: On Jan 6, 2010, at 3:12 AM, Dobbins, Roland wrote: > Wrong. The attacker just programmatically generates semantically-valid traffic which is indistinguishablle from real traffic, and crowds out the real traffic. > > All those fancy timers and counters and what-not don't matter. > > I've seen it done over and over again. Why some folks seem to think this is theoretical or that I somehow haven't thought of something they think will prove to be a magic solution is really beyond me, heh. The reality is they just have not been attacked yet, and hence have no experience in what to do about the problem... - Jared From rdobbins at arbor.net Wed Jan 6 07:51:34 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 6 Jan 2010 13:51:34 +0000 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> <39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> Message-ID: <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> On Jan 6, 2010, at 8:42 PM, Jared Mauch wrote: > The reality is they just have not been attacked yet, and hence have no experience in what to do about the problem... And they've been bombarded with misinformation for years by 'security' vendors, wildly unrealistic certification training courses, and the 'compliance' mafia; you're right, of course. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From dot at dotat.at Wed Jan 6 08:39:19 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 6 Jan 2010 14:39:19 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <20100106005541.5E3F61CC0B@ptavv.es.net> References: <20100106005541.5E3F61CC0B@ptavv.es.net> Message-ID: On Tue, 5 Jan 2010, Kevin Oberman wrote: > > I suspect at least part of this will soon get fixed due to DNSSEC. > Blocking tcp/53 and packets over 512 bytes will cause user complaints > and, after enough education, the problem will get fixed. Yes. Remember the root zone is due to be signed within the next six months, and many nameservers (BIND in particular) request DNSSEC data by default. You WILL have to deal with large DNS replies SOON - the first ones from the root servers will appear this month. http://www.root-dnssec.org/ Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 6 08:46:43 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 7 Jan 2010 01:16:43 +1030 Subject: I don't need no stinking firewall! In-Reply-To: <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> Message-ID: <20100107011643.429721cc@opy.nosense.org> On Wed, 6 Jan 2010 04:53:17 +0000 "Dobbins, Roland" wrote: > > On Jan 6, 2010, at 11:43 AM, George Bonser wrote: > > > Yes, you have to take some of the things that were done in one spot and do > > them in different locations now, but the results are an amazing increase > > in service capacity per dollar spent on infrastructure. > > I strongly agree with the majority of your comments, with the caveat that I've seen many, many load-balancers fall over due to state-exhaustion, too; load-balancers need northbound protection from DDoS (S/RTBH, flow-spec, IDMS, et. al.), as well. > And that is the crux of the matter. Any time you maintain state in the network (e.g. stateful firewalls), you're vulnerable to traffic based attacks that can exhaust that state. The Internet is scalable because the (soft) state that it maintains, namely route tables, isn't dependent on or influenced by the traffic that is forwarded through it. Hosts have to maintain state about their connections - there is no choice. However, the more you're able to push state tracking to the hosts, you end up with less consequences of state targeted attacks, and more scalable architectures. From bjohnson at drtel.com Wed Jan 6 08:51:37 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 6 Jan 2010 08:51:37 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> Message-ID: <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> I will not argue the more complete statement about the architectural premise that statefull firewalls are being produced under. That would be fruitless and I would concede to Roland and his statements on that. It appears that the real argument is whether statefull inspection is useful, and whether the firewall causes other issues to the network design. If this is so, then I would say that it depends on the network and it's design as to whether a statefull firewall is useful. One could put ACLs in routers and switches, but when you break it down and turn off statefull inspection, that is what a firewall is. As always, you should always consider your network design before implementing any network appliance that will/may affect traffic. I don't think that discarding ideas like signature based analysis and DPI are wise. Depending on the network, the staff running the network, the users using the network, external exposure and many other metrics, I don't think that anyone should be making broad statements on equipment decisions. I'm glad that I can go to lists like NANOG with this type of question and not get the clue bat across the head. Like Roland, I've been doing this for over a decade as well, and I have seen some pretty strange things, even a statefull firewall in front of servers with IPS actually work. This thread is a tribute to different ideas and beliefs as well as experience on this topic. Please keep up the conversation and down the condescension and rhetoric. Thank you. - Brian > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Wednesday, January 06, 2010 7:52 AM > To: NANOG list > Subject: Re: I don't need no stinking firewall! > > > On Jan 6, 2010, at 8:42 PM, Jared Mauch wrote: > > > The reality is they just have not been attacked yet, and hence have > no experience in what to do about the problem... > > And they've been bombarded with misinformation for years by 'security' > vendors, wildly unrealistic certification training courses, and the > 'compliance' mafia; you're right, of course. > > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From hank at efes.iucc.ac.il Wed Jan 6 09:00:14 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 06 Jan 2010 17:00:14 +0200 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <0E2AE8B3-037A-4293-B456-ACE600A6C7DB@as5413.net> References: <005c01ca8dce$a59141a0$f0b3c4e0$@net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> Message-ID: <5.1.0.14.2.20100106165830.055f5bf8@efes.iucc.ac.il> At 13:19 05/01/2010 +0000, Rob Shakir wrote: >If you're an SP who has some existing NetFlow solution, and don't really >justify a spend for traffic intelligence within your network (or have >something home-grown), is there an alternative scrubber that one might be >able to use in a more standalone deployment that can approach the >filtering levels of the Arbor kit? > >I should probably point out that we only really started our conversation >with Arbor within the last month or so, so there are perhaps details >relating to this that I've missed. I'd be happy to be corrected! In that case, how do you run your current service: http://www.vialtus.com/en/Solutions/Hosting-and-Datacentre-Services/Security-Solutions/Distributed-Denial-of-Service-Protection.aspx -Hank >Kind regards, >Rob > >-- >Rob Shakir >Network Development Engineer GX Networks/Vialtus Solutions >ddi: +44208 587 6077 mob: +44797 155 4098 >pgp: 0xc07e6deb nic-hdl: RJS-RIPE > >This email is subject to: http://www.vialtus.com/disclaimer.html From jgreco at ns.sol.net Wed Jan 6 09:00:19 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 6 Jan 2010 09:00:19 -0600 (CST) Subject: I don't need no stinking firewall! In-Reply-To: <1262753047.6710.17.camel@petrie> from "William Pitcock" at Jan 05, 2010 10:44:07 PM Message-ID: <201001061500.o06F0JPX070224@aurora.sol.net> > > (4) Rate limiting. The ability to rate limit incoming and outgoing data > > can prevent certain sorts of DoSes. > > I am not sure what makes you believe that. The ability to rate limit > incoming data at the server level would definitely not prevent a DoS. > > The ability to rate limit outgoing data would cause a DoS of anything > other than DoS traffic that is hosted on the server. It may be good practice to rate limit outgoing ICMP PING replies from your server to the real world. Kind of like being a good neighbor in the event of certain types of attacks on other parties. This can be extended into more specific types of outgoing rate limits. For example, an ISP DNS recurser that normally serves 1Mbps of traffic in aggregate but lives on a 1Gbps ethernet might use a per-destination outgoing limit to restrict the amount of damage that could be inflicted on a remote DNS server (without affecting other destinations); things like FreeBSD ipfw/dummynet and Linux (mumble) have these sorts of capabilities. I can see some usefulness in rate limiting as a form of sanity enforcement. Your average switch cannot do the more complex forms in silicon. ... 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 graeme at graemef.net Wed Jan 6 09:05:42 2010 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 06 Jan 2010 15:05:42 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5.1.0.14.2.20100106165830.055f5bf8@efes.iucc.ac.il> References: <005c01ca8dce$a59141a0$f0b3c4e0$@net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> <5.1.0.14.2.20100106165830.055f5bf8@efes.iucc.ac.il> Message-ID: <1262790342.27779.1.camel@localhost> On Wed, 2010-01-06 at 17:00 +0200, Hank Nussbacher wrote: > In that case, how do you run your current service: > http://www.vialtus.com/en/Solutions/Hosting-and-Datacentre-Services/Security-Solutions/Distributed-Denial-of-Service-Protection.aspx It says how, right on that page. Not Arbor. Graeme (ex PIPEX employee who had first hand experience of just how good the aforementioned Cisco Guard kit was in production) From scott.mackenzie at bikouware.com Wed Jan 6 09:15:51 2010 From: scott.mackenzie at bikouware.com (Scott E. MacKenzie) Date: Wed, 6 Jan 2010 23:15:51 +0800 Subject: Data Centre - Advice? (Shenzhen, China) Message-ID: <000e01ca8ee3$2495d500$6dc17f00$@bikouware.com> Wow, missed this one reply. Sorry Benjamin. 1) Define "tier one". Let's go with this definition: http://en.wikipedia.org/wiki/Tier_1_network I hope the definition helps? ________________________________________________________ NTT got some IDC in China (Beijing, Guangzhou, Hong Kong, Shanghai, Suzhou), but not in Shenzhen. I noticed that the NTT sites are look owned by third parties. Can anyone confirm this? Chinanetcenter would be there: http://www.chinanetcenter.com/wangsu/english/co/Shenzhen_Banxuegang_IDC.htm Remember Hong Kong is well served in Datacenters and upstream providers, and well, just next to Shenzhen. Thank you, for the feedback. We will be looking at chinanetcenter next week and I will let you know my thoughts. Hong Kong is not going to work as our clients are in China and the network delay (latency) to HK is excruciatingly painful. It is like sending a packet around the globe from Shenzhen to HK. I don't know why, but I have my suspicions. Anywhere inside the PRC the network is blazing fast from point to point. _________________________________________________________ 2) Define "technology foot print" =) Couldn't respecting RFC be a foot print already? No joke, please give more details about your "technology". Servers, switches, routers, firewalls, load balancers, etc... When serving your clients inside the PRC from outside the PRC, does anyone have any feedback, thoughts, comments, or suggestions surrounding placement of gear - as in inside or outside the PRC. Thus far it looks not good from HK or Taiwan. Our concern is delivering the best possible experience to our clients using the services we offer. (SaaS, MashApps, Etc.) We need low latency, moderate bandwidth, and 100% uptime - or very close to it... Scott Best, Benjamin Le 10/12/2009 05:57, Scott E. MacKenzie a ?crit : > Hi, > > > > Does anyone have any great websites to share or advice where I can > locate all the tier one Internet Data Centre (IDC) providers in > Shenzhen China? > > > > My second question would be on any advice that anyone can offer about > the problems that can be faced operating your technology foot print > inside the PRC, if there are any? > > > > Warm Regards, > > > > > > Scott > > ------------------------------ From hiersd at gmail.com Wed Jan 6 10:49:43 2010 From: hiersd at gmail.com (David Hiers) Date: Wed, 6 Jan 2010 08:49:43 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> Message-ID: <2873f3701001060849o68f0ff91n47e21e9ca54a235f@mail.gmail.com> Poking the dragon a bit, aren't you? Fun. If you really look at it, there is no quantitative difference between statefull and non-statefull. A non-stateful firewall can prevent a TCP session from entering the SYN_RECEIVED state by blocking the SYN packet, so it strongly impacts session state without really trying. A statefull firewall will venture a bit deeper into the state diagram with a few more rules, but this is mostly a quantitative difference when viewed at a behavioral level (disregarding the internal implementation, of course). Coders and marketeers will burn me in effigy over this, but there's already a lot of people in that line... In the most general terms, a firewall attempts to permit desired traffic flows and block undesirable traffic flows. Statefull ones attempt to do so using knowledge of the protocols' state machines. The work performed by a statefull firewall must be done, either by the ultimate endpoints (your servers, etc) or by a central enforcement point (a firewall). In other words, desirable traffic (like spice) must flow, and undesirable traffic must not impede the former. The rationale for the existence of firewalls is that you can enforce the rules of the protocols more cheaply if you move some of the enforcement into a specialized device (a statefull firewall). If you care to engineer every end node such that they can enforce the protocols' state machines in every case at every possible traffic level, you have no need for firewalls at all. At the current triple-point of threat, product, and protocol, separation of function is currently a useful method, nothing more. David On Tue, Jan 5, 2010 at 12:16 PM, Brian Johnson wrote: > Security Gurus, et al, > > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? > > Please respond on-list as I want to have some useful discourse and > discussion in the clear. Flamers and Trolls will be disregarded. :) > > Thank you. > > ?- Brian > > > ?CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original message. Thank you. > > From rjs at eng.gxn.net Wed Jan 6 11:04:09 2010 From: rjs at eng.gxn.net (Rob Shakir) Date: Wed, 6 Jan 2010 17:04:09 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <5.1.0.14.2.20100106165830.055f5bf8@efes.iucc.ac.il> References: <005c01ca8dce$a59141a0$f0b3c4e0$@net> <16720fe01001041905wab47d73xd5a6696ad4061ce7@mail.gmail.com> <16720fe01001041906x3832752jed167ab7e633ba4c@mail.gmail.com> <16720fe01001042000g514d5ac1o9677b2667f2af9b8@mail.gmail.com> <16720fe01001042005i23f0360en6bd5740f6b90beec@mail.gmail.com> <9BC57588-4D57-41DA-BC9D-9A96FFC14ABC@arbor.net> <75cb24521001042041n14eaa11djb5454f46b752f0cb@mail.gmail.com> <3E9BB882-E810-40B5-8C2A-F34D84CE3674@arbor.net> <005101ca8dc8$c418dda0$4c4a98e0$@net> <005c01ca8dce$a59141a0$f0b3c4e0$@net> <5.1.0.14.2.20100106165830.055f5bf8@efes.iucc.ac.il> Message-ID: <85B9DA1C-98E0-4ACA-BAF6-1D84425E9833@eng.gxn.net> On 6 Jan 2010, at 15:00, Hank Nussbacher wrote: > At 13:19 05/01/2010 +0000, Rob Shakir wrote: > >> If you're an SP who has some existing NetFlow solution, and don't really justify a spend for traffic intelligence within your network (or have something home-grown), is there an alternative scrubber that one might be able to use in a more standalone deployment that can approach the filtering levels of the Arbor kit? >> >> I should probably point out that we only really started our conversation with Arbor within the last month or so, so there are perhaps details relating to this that I've missed. I'd be happy to be corrected! > > In that case, how do you run your current service: > http://www.vialtus.com/en/Solutions/Hosting-and-Datacentre-Services/Security-Solutions/Distributed-Denial-of-Service-Protection.aspx Our existing mitigation devices are Riverhead boxes and some in-house tools, hence my interest in what other people are doing relating to the Cisco/Arbor Clean Pipes document. I find the Riverhead boxes really good to work with, it's a shame that they're no longer under active development though! Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http://www.vialtus.com/disclaimer.html From brandon at shrader.net Wed Jan 6 11:18:55 2010 From: brandon at shrader.net (Brandon M. Lapointe) Date: Wed, 6 Jan 2010 11:18:55 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <2873f3701001060849o68f0ff91n47e21e9ca54a235f@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <2873f3701001060849o68f0ff91n47e21e9ca54a235f@mail.gmail.com> Message-ID: <62B051F561B10F4897A7120430E590EE820D55@SEC-EXCHANGE.shrader.net> -----Original Message----- From: David Hiers [mailto:hiersd at gmail.com] Sent: Wednesday, January 06, 2010 10:50 AM To: Brian Johnson Cc: nanog at nanog.org Subject: Re: I don't need no stinking firewall! >Poking the dragon a bit, aren't you? Fun. >If you really look at it, there is no quantitative difference between >statefull and non-statefull. A non-stateful firewall can prevent a >TCP session from entering the SYN_RECEIVED state by blocking the SYN >packet, so it strongly impacts session state without really trying. A >statefull firewall will venture a bit deeper into the state diagram >with a few more rules, but this is mostly a quantitative difference >when viewed at a behavioral level -snip- >David +1 As mentioned before, the line has substantially blurred with what current devices (routers/load balancers) can do in hardware. Brandon L. On Tue, Jan 5, 2010 at 12:16 PM, Brian Johnson wrote: > Security Gurus, et al, > > I have my own idea of what a firewall is and what it does. I also > understand what statefull packet inspection is and what it does. Given > this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? > > Please respond on-list as I want to have some useful discourse and > discussion in the clear. Flamers and Trolls will be disregarded. :) > > Thank you. > > ?- Brian > > > ?CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original message. Thank you. > > From chort at smtps.net Wed Jan 6 11:38:01 2010 From: chort at smtps.net (Brian Keefer) Date: Wed, 6 Jan 2010 09:38:01 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> Message-ID: On Jan 6, 2010, at 6:51 AM, Brian Johnson wrote: > Like Roland, I've been doing > this for over a decade as well, and I have seen some pretty strange > things, even a statefull firewall in front of servers with IPS actually > work. > What do you mean by "work"? If you mean "all three pieces ran for years without being seriously attacked", then that's really not the same thing as "continued to perform assigned duties effectively in the face of a determined DDoS". I'd venture to say the vast majority of network operators, including myself, have never faced a DoS worse than a miscreant kid with a cable modem. The few customers I've talked to who have been DDoS'd have all said the firewall died first. It's pretty simple. Of the devices on your network that have to keep state, a firewall has to maintain far more of them, since it's the aggregate of many down-stream hosts. The resources to maintain state are finite. At some point, those finite resources will be exceeded, and that will happen to a device holding the aggregate before any other device succumbs to the same problem. If the firewall goes down, that DoS's everything behind it. Is that really better than having only a portion of the down-stream hosts unavailable? IMO firewalls have been a crutch for far too long. They're an excuse for not having tight host-based security and (more importantly) good patch-management. There really isn't a network perimeter any more any way. If any of your hosts gets infected, they're going to attempt to infect their neighbors. Worms have been doing this since they were invented and a network firewall offers very little protection against it. Put another way: Is it clear that spending money on fancy network firewalls and IPS is more effective at mitigating risk than investing the same money in patch-management and host-hardening? I don't think so. I'd also like to add a +1 to the statement "firewalls break things in subtle and hard-to-debug ways". The longest support calls are always those trying to figure out how the customer's firewall is breaking things, and then how to prove this to their $management so they'll approve disabling the offending "feature". Speaking of which, there are about 700MB of PCAPs that I'm supposed to be looking at right now... -- bk From hiersd at gmail.com Wed Jan 6 11:43:36 2010 From: hiersd at gmail.com (David Hiers) Date: Wed, 6 Jan 2010 09:43:36 -0800 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net> <1262752784-sup-6499@sfo.thejof.com> <6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com> <39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> Message-ID: <2873f3701001060943t5027683ctf867d80594eb8d4b@mail.gmail.com> As long as you raise the level of CAIN (Confidentiality, Availability, Integrity, Non-Repudiation) that your mission requires and funding permits, you can do it anywhere you like, with whatever you like, and call it whatever you like. David On Wed, Jan 6, 2010 at 9:38 AM, Brian Keefer wrote: > > On Jan 6, 2010, at 6:51 AM, Brian Johnson wrote: > >> ?Like Roland, I've been doing >> this for over a decade as well, and I have seen some pretty strange >> things, even a statefull firewall in front of servers with IPS actually >> work. >> > > > What do you mean by "work"? ?If you mean "all three pieces ran for years without being seriously attacked", then that's really not the same thing as "continued to perform assigned duties effectively in the face of a determined DDoS". > > I'd venture to say the vast majority of network operators, including myself, have never faced a DoS worse than a miscreant kid with a cable modem. ?The few customers I've talked to who have been DDoS'd have all said the firewall died first. > > It's pretty simple. ?Of the devices on your network that have to keep state, a firewall has to maintain far more of them, since it's the aggregate of many down-stream hosts. ?The resources to maintain state are finite. ?At some point, those finite resources will be exceeded, and that will happen to a device holding the aggregate before any other device succumbs to the same problem. > > If the firewall goes down, that DoS's everything behind it. ?Is that really better than having only a portion of the down-stream hosts unavailable? > > IMO firewalls have been a crutch for far too long. ?They're an excuse for not having tight host-based security and (more importantly) good patch-management. ?There really isn't a network perimeter any more any way. ?If any of your hosts gets infected, they're going to attempt to infect their neighbors. ?Worms have been doing this since they were invented and a network firewall offers very little protection against it. > > Put another way: ?Is it clear that spending money on fancy network firewalls and IPS is more effective at mitigating risk than investing the same money in patch-management and host-hardening? ?I don't think so. > > I'd also like to add a +1 to the statement "firewalls break things in subtle and hard-to-debug ways". ?The longest support calls are always those trying to figure out how the customer's firewall is breaking things, and then how to prove this to their $management so they'll approve disabling the offending "feature". ?Speaking of which, there are about 700MB of PCAPs that I'm supposed to be looking at right now... > > -- > bk > > > > > From jimb at jsbc.cc Wed Jan 6 13:12:29 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 06 Jan 2010 11:12:29 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> Message-ID: <4B44E09D.8010004@jsbc.cc> On 1/6/2010 01:23, Dobbins, Roland wrote: > On Jan 6, 2010, at 4:18 PM, Matthew Palmer wrote: > > >> The closest I can come to a solution is to set a random password and flash it using a front-panel LED using morse. >> > heh > > No password at all, operator prompted at the console during startup unless/until he sets one. No IP address, et. al. until a password is set. > Yeah. And for devices with no console, only network interfaces, a default IP address, no default password, and no default route (just in case they plug it into a real LAN instead of a laptop. :p ). From bjohnson at drtel.com Wed Jan 6 13:29:39 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 6 Jan 2010 13:29:39 -0600 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> Message-ID: <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> - Brian > -----Original Message----- > From: Brian Keefer [mailto:chort at smtps.net] > Sent: Wednesday, January 06, 2010 11:38 AM > To: Brian Johnson > Cc: NANOG list > Subject: Re: I don't need no stinking firewall! > > > On Jan 6, 2010, at 6:51 AM, Brian Johnson wrote: > > > Like Roland, I've been doing > > this for over a decade as well, and I have seen some pretty strange > > things, even a statefull firewall in front of servers with IPS > actually > > work. > > > > > What do you mean by "work"? If you mean "all three pieces ran for > years without being seriously attacked", then that's really not the > same thing as "continued to perform assigned duties effectively in the > face of a determined DDoS". By work I mean that it held-up under DDoS attack. The size of a DDoS attack is the question. If I have enough resources a person can DDoS an entire network, irrelevant of its equipment, that will make the network un-usable and unreachable. Statefull firewall or not. They simply need to fill up the inbound connection with traffic so that nothing else gets through. If your point is given unlimited inbound bandwidth that a stateful firewall will fail (not work correctly), I can say that about any piece of equipment. And even if it does fail, does it matter if your connection is full of useless traffic? DDoS attacks are not designed to compromise or gather data about networks. DDoS is the sledge hammer of the dubious to cause disruption. It doesn't matter what you put in there (Statefull Firewall, IDS, IPS, Router ACLS, et al...), if the connection is flooded, the network will be unreachable. Does it matter if the equipment can't handle it if no good traffic, that would need to be statefully inspected, is traversing the connection? - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From chort at smtps.net Wed Jan 6 15:12:24 2010 From: chort at smtps.net (Brian Keefer) Date: Wed, 6 Jan 2010 13:12:24 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> Message-ID: <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> On Jan 6, 2010, at 11:29 AM, Brian Johnson wrote: > If your point is given unlimited inbound bandwidth that a stateful > firewall will fail (not work correctly), I can say that about any piece > of equipment. And even if it does fail, does it matter if your > connection is full of useless traffic? > It's a lot easier to fill up a state table than to fill up a pipe, which I believe was Roland's point. It's quite possible to flood the state table on a device with a fraction of the pipe's capacity, in which case a stateful device will fall over where a stateless device would not have. This type of attack will definitely degrade the service it's aimed at, and probably degrade other services sharing the same pipe, but won't _necessarily_ kill them as is the case when a stateful gateway falls over. Typical scenario is $badguys DDoS one of your webservers. If the gateway is stateless, your webservers grind to a crawl, but your DNS, e-mail, VOIP, etc probably still function to a degree. Contrast that with site-wide outage if your gateway was stateful and crashed/rebooted/refused to pass traffic due to having the state table filled. You're not going to be able to stop $sophisticated_badguy from enumerating your services no matter how fancy your gear is. Could you detect a distributed portscan that looks at 5000 proto/IP/port combos per day, across your IP space, each probe coming from a different IP? I really doubt it. If you have services listening, someone is going to find them. IMO you're better off making sure only the services you intend to provide are listening, and that those services are hardened appropriately for public exposure. This topic has probably run it's course; everyone has different opinions and takes away different lessons from their experience. I think it's valuable to challenge the common assumptions (everyone knows you need a stateful firewall!) now and then to make sure they actually make sense. -- bk From Valdis.Kletnieks at vt.edu Wed Jan 6 15:46:07 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 06 Jan 2010 16:46:07 -0500 Subject: I don't need no stinking firewall! In-Reply-To: Your message of "Tue, 05 Jan 2010 23:14:05 CST." <4B441C1D.7070704@hack.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <4B441C1D.7070704@hack.net> Message-ID: <24355.1262814367@localhost> On Tue, 05 Jan 2010 23:14:05 CST, Ryan Brooks said: > Everyone needs to listen to Roland's mantra: "stateless ACLs in hardware > than can handle Mpps". It's more than just a hint. I suspect that more than a few need to be reminded that "stateless ACLs in switch hardware" is just another name for "switch that also does stateless firewall". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bjohnson at drtel.com Wed Jan 6 15:56:28 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 6 Jan 2010 15:56:28 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> Message-ID: <29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> > -----Original Message----- > From: Brian Keefer [mailto:chort at smtps.net] > Sent: Wednesday, January 06, 2010 3:12 PM > To: Brian Johnson > Cc: NANOG list > Subject: Re: I don't need no stinking firewall! > > It's quite possible to flood the state table on a device with a > fraction of the pipe's capacity, in which case a stateful device will > fall over where a stateless device would not have. This type of attack > will definitely degrade the service it's aimed at, and probably degrade > other services sharing the same pipe, but won't _necessarily_ kill them > as is the case when a stateful gateway falls over. This would depend on the nature of the DDoS (how it was crafted). I would agree that a DDoS designed to fill a state table would do this. However, a DDoS can also be designed with large packets to fill up the capacity of the connection. In this case it would depend on the amount of bandwidth available. If total bandwidth / packet size > state table size (rough formula), then your assertion is valid. But if not, then it may be flawed. This goes back to the idea that the network design/goals/intent is an unknown quantity in every statement made on this matter. > > Typical scenario is $badguys DDoS one of your webservers. If the > gateway is stateless, your webservers grind to a crawl, but your DNS, > e-mail, VOIP, etc probably still function to a degree. Contrast that > with site-wide outage if your gateway was stateful and > crashed/rebooted/refused to pass traffic due to having the state table > filled. I'll give this to you, but this still depends on the previous point. I know that under minimum packet sizes and using a pipe with > 200 Mbps capacity, I have seen a statefull firewall handle a large DDoS just fine. The problem was that the packets that needed to get in to the host couldn't, because the bandwidth was fully utilized. I also know that if the state table on said device were to be filled, the box wouldn't crash or reboot. It would just queue or drop the packets until a state slot became available. The scope of the state table was so large though that it would take a lot more traffic than the operation would ever purchase to fill it up. Remember YMMV. :) > > You're not going to be able to stop $sophisticated_badguy from > enumerating your services no matter how fancy your gear is. Could you > detect a distributed portscan that looks at 5000 proto/IP/port combos > per day, across your IP space, each probe coming from a different IP? I > really doubt it. If you have services listening, someone is going to > find them. So the port scan would tell them about services I want there to be access to. I'm OK with that to a large extent. In practice if I do detect a port scan (usually from a single IP address), this would lead me to take prerequisite steps to block a future attack. > > IMO you're better off making sure only the services you intend to > provide are listening, and that those services are hardened > appropriately for public exposure. OK. This is obvious to anyone with experience in these things. But I also believe in a layered approach. It never hurts to add more layers to prevent human error or even internal breaches as the different systems are under the control of different equipment (servers, routers, switches, security devices). It's like two supports holding up something without knowing if the other one is doing its job. Both need to pull the full weight in case the other fails. > > This topic has probably run it's course; everyone has different > opinions and takes away different lessons from their experience. I > think it's valuable to challenge the common assumptions (everyone knows > you need a stateful firewall!) now and then to make sure they actually > make sense. I agree. I just don't want anyone to go throw out their statefull firewalls because you, I or somebody else maybe would do it differently. Or because we have a different type of network or size of network or even goals of our network. So here's the brunt of it... Understand what statefull firewalls are and what they do, every network is different and YMMV. Now, let's go get a beer. :) - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From smb at cs.columbia.edu Wed Jan 6 16:13:58 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 6 Jan 2010 17:13:58 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F716E@RWC-EX1.corp.seven.com> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01><11B064048F34FD4094CBA16FC04BE219864BC3D6@ex01><5A6D953473350C4B9995546AFE9939EE081F716D@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE081F716E@RWC-EX1.corp.seven.com> Message-ID: <87FD3FF8-51E0-43A5-B25C-CD58C3153159@cs.columbia.edu> On Jan 6, 2010, at 4:43 AM, George Bonser wrote: >> -----Original Message----- >> >>> having physical access pretty much trumps any other security > measure. >> >> The fact that there's a factory default means that lots of folks won't >> change it when they configure the unit with an IP address; they follow >> this with failing to implement iACLs, and it's pw3nt1me! > > > I suppose it is a philosophical thing with me. I don't believe in > protecting people from their own stupidity. If you try to enforce that, > you end up with organizations making up their own "default" passwords > which can be little better than manufacturer defaults. > > They're much better, since once guess doesn't suffice for all devices; see http://ids.ftw.fm/Home/publications/RouterScan-RAID09-Poster.pdf?attredirects=0 for some indication of just how bad the problem can be. And we all suffer from p0wned devices, because they get turned into bots. Roland is 100% right. --Steve Bellovin, http://www.cs.columbia.edu/~smb From bjohnson at drtel.com Wed Jan 6 16:18:27 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 6 Jan 2010 16:18:27 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <24355.1262814367@localhost> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><4B441C1D.7070704@hack.net> <24355.1262814367@localhost> Message-ID: <29A54911243620478FF59F00EBB12F4701B27F5F@ex01.drtel.lan> > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Wednesday, January 06, 2010 3:46 PM > To: nanog at nanog.org > Subject: Re: I don't need no stinking firewall! > > On Tue, 05 Jan 2010 23:14:05 CST, Ryan Brooks said: > > > Everyone needs to listen to Roland's mantra: "stateless ACLs in > hardware > > than can handle Mpps". It's more than just a hint. > > I suspect that more than a few need to be reminded that "stateless ACLs > in > switch hardware" is just another name for "switch that also does > stateless > firewall". I don't think so: "stateless ACLs in switch hardware" != " switch that also does stateless firewall" IMHO... "stateless ACLs in [switch|router] hardware" = ACLs applied to interfaces that filter packets based on source or destination IP addresses and ports, or protocols. Correct me if I'm wrong Roland. - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From jis at MIT.EDU Wed Jan 6 17:24:26 2010 From: jis at MIT.EDU (Jeffrey I. Schiller) Date: Wed, 06 Jan 2010 18:24:26 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <20100106091837.GF25450@hezmatt.org> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> Message-ID: <4B451BAA.4020109@mit.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An option I saw years ago (I forgot on whose equipment) was a default password which was a function of the equipment's serial number. So you had to have the algorithm and you needed the serial number which was not related to the MAC. So if you didn't have physical access, you were not in a good position to learn the password. I suspect this was a support nightmare for the vendor and I bet they went to a more standard (read: the same) factory password. At the end of the day, minimizing support costs for the vendor (not to mention likely annoyance for the customer) trumps providing "default" security for the folks who won't change the default password. -Jeff Matthew Palmer wrote: > On Wed, Jan 06, 2010 at 08:26:25AM +0000, Dobbins, Roland wrote: >>> Does anyone know the default passwords for World Wide Packets 427 and 311v switches? >> One should think the fact that there are default passwords at all should be a cause for alarm, in and of itself. > > As much as they're a definite security risk, I can't imagine what other > option there is. The closest I can come to a solution is to set a random > password and flash it using a front-panel LED using morse. > > - Matt > - -- ======================================================================== Jeffrey I. Schiller MIT Network Manager/Security Architect PCI Compliance Officer Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis at mit.edu http://jis.qyv.name ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLRRuk8CBzV/QUlSsRAuEEAJ4vFWYnMqK3AP1q9y46HzIIMeasoQCfSAkb CobOYgNelNkZL2ePmd6jwpM= =zBKR -----END PGP SIGNATURE----- From gb10hkzo-nanog at yahoo.co.uk Wed Jan 6 17:42:50 2010 From: gb10hkzo-nanog at yahoo.co.uk (gb10hkzo-nanog at yahoo.co.uk) Date: Wed, 6 Jan 2010 23:42:50 +0000 (GMT) Subject: I don't need no stinking firewall! Message-ID: <940660.73153.qm@web24710.mail.ird.yahoo.com> Don't think anyone has mentioned this yet, so I will.... All this debate over the pros and cons of firewalls brings the words "Jericho Forum" to mind.....and their "principles for de-perimeterization (perimeter erosion)" http://www.opengroup.org/jericho/ Just my 2 worth ! From nhale at softlayer.com Wed Jan 6 18:13:28 2010 From: nhale at softlayer.com (Nick Hale) Date: Wed, 6 Jan 2010 18:13:28 -0600 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <4B451BAA.4020109@mit.edu> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> Message-ID: <98E72206041B1B408D3F92E91E80BF1807AE1D15@slmail101.softlayer.local> I think the vendor you're thinking of was Cabletron (now Enterasys). I had to call them and give them the Serial Number for them to provide me with the default password to the system after a hard reset (this was for an ELS100-24TXG 'switch'). -NH -----Original Message----- From: Jeffrey I. Schiller [mailto:jis at MIT.EDU] Sent: Wednesday, January 06, 2010 17:24 To: Matthew Palmer Cc: nanog at nanog.org Subject: Re: Default Passwords for World Wide Packets/Lightning Edge Equipment -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An option I saw years ago (I forgot on whose equipment) was a default password which was a function of the equipment's serial number. So you had to have the algorithm and you needed the serial number which was not related to the MAC. So if you didn't have physical access, you were not in a good position to learn the password. I suspect this was a support nightmare for the vendor and I bet they went to a more standard (read: the same) factory password. At the end of the day, minimizing support costs for the vendor (not to mention likely annoyance for the customer) trumps providing "default" security for the folks who won't change the default password. -Jeff Matthew Palmer wrote: > On Wed, Jan 06, 2010 at 08:26:25AM +0000, Dobbins, Roland wrote: >>> Does anyone know the default passwords for World Wide Packets 427 and 311v switches? >> One should think the fact that there are default passwords at all should be a cause for alarm, in and of itself. > > As much as they're a definite security risk, I can't imagine what other > option there is. The closest I can come to a solution is to set a random > password and flash it using a front-panel LED using morse. > > - Matt > - -- ======================================================================== Jeffrey I. Schiller MIT Network Manager/Security Architect PCI Compliance Officer Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis at mit.edu http://jis.qyv.name ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLRRuk8CBzV/QUlSsRAuEEAJ4vFWYnMqK3AP1q9y46HzIIMeasoQCfSAkb CobOYgNelNkZL2ePmd6jwpM= =zBKR -----END PGP SIGNATURE----- From kenny.sallee at gmail.com Wed Jan 6 18:36:07 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Wed, 6 Jan 2010 16:36:07 -0800 Subject: ASR1002 Message-ID: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> Anyone have recommendations on solid IOS XE code for ASR 1002 that's just doing: - BGP - VRF's - Many sub-interfaces and ACL's It shipped with 02.04.02.122-33.XND2.bin Thanks, Kenny From mark.jacksontechnology at gmail.com Wed Jan 6 18:42:11 2010 From: mark.jacksontechnology at gmail.com (Mark Jackson) Date: Wed, 6 Jan 2010 16:42:11 -0800 Subject: ASR1002 In-Reply-To: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> Message-ID: <-474984356341572919@unknownmsgid> 2.10 has been solid on all my clients thus far and supports your below mentioned requirements. Mark Jackson, CCIE #4736 Sent from my iPhone. Please excuse spelling errors On Jan 6, 2010, at 4:36 PM, Kenny Sallee wrote: > Anyone have recommendations on solid IOS XE code for ASR 1002 that's > just > doing: > > - BGP > - VRF's > - Many sub-interfaces and ACL's > > It shipped with 02.04.02.122-33.XND2.bin > > Thanks, > Kenny From jared at puck.nether.net Wed Jan 6 18:45:50 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Jan 2010 19:45:50 -0500 Subject: ASR1002 In-Reply-To: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> Message-ID: <9813C702-36BA-4B50-ACFB-FD18D27B78B4@puck.nether.net> I would run at least the 2.5 software (XNE). You don't mention if you have RP1 or RP2, if you're doing sw redundancy or hw redundancy or both, etc.. This will also have an impact. I've seen some 'odd' issues with BGP on the ASR1k, so you really do want to track the latest code. It's also recommended to keep a close eye on your memory utilization and if/when any cores show up on the harddisk(s). - Jared On Jan 6, 2010, at 7:36 PM, Kenny Sallee wrote: > Anyone have recommendations on solid IOS XE code for ASR 1002 that's just > doing: > > - BGP > - VRF's > - Many sub-interfaces and ACL's > > It shipped with 02.04.02.122-33.XND2.bin > > Thanks, > Kenny From smb at cs.columbia.edu Wed Jan 6 19:26:07 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 6 Jan 2010 20:26:07 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <4B451BAA.4020109@mit.edu> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> Message-ID: <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> On Jan 6, 2010, at 6:24 PM, Jeffrey I. Schiller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > An option I saw years ago (I forgot on whose equipment) was a default > password which was a function of the equipment's serial number. So you > had to have the algorithm and you needed the serial number which was not > related to the MAC. So if you didn't have physical access, you were not > in a good position to learn the password. > > I suspect this was a support nightmare for the vendor and I bet they > went to a more standard (read: the same) factory password. > > At the end of the day, minimizing support costs for the vendor (not to > mention likely annoyance for the customer) trumps providing "default" > security for the folks who won't change the default password. The MyFi apparently does this. According to http://www.nytimes.com/2009/05/07/technology/personaltech/07pogue.html "The network password is printed right there on the bottom of the MiFi itself." --Steve Bellovin, http://www.cs.columbia.edu/~smb From jesler at sourcefire.com Wed Jan 6 19:41:14 2010 From: jesler at sourcefire.com (Joel Esler) Date: Wed, 6 Jan 2010 20:41:14 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> Message-ID: <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> On Wed, Jan 6, 2010 at 8:26 PM, Steven Bellovin wrote: > On Jan 6, 2010, at 6:24 PM, Jeffrey I. Schiller wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > An option I saw years ago (I forgot on whose equipment) was a default > > password which was a function of the equipment's serial number. So you > > had to have the algorithm and you needed the serial number which was not > > related to the MAC. So if you didn't have physical access, you were not > > in a good position to learn the password. > > > > I suspect this was a support nightmare for the vendor and I bet they > > went to a more standard (read: the same) factory password. > > > > At the end of the day, minimizing support costs for the vendor (not to > > mention likely annoyance for the customer) trumps providing "default" > > security for the folks who won't change the default password. > > The MyFi apparently does this. According to > http://www.nytimes.com/2009/05/07/technology/personaltech/07pogue.html"The network password is printed right there on the bottom of the MiFi > itself." > > At least it's not "0000". But yes, my Mifi *had* the password on the bottom. -- Joel Esler From blakjak at blakjak.net Wed Jan 6 19:50:41 2010 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 7 Jan 2010 14:50:41 +1300 (NZDT) Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> Message-ID: >>> At the end of the day, minimizing support costs for the vendor (not to >>> mention likely annoyance for the customer) trumps providing "default" >>> security for the folks who won't change the default password. >> >> The MyFi apparently does this. According to >> http://www.nytimes.com/2009/05/07/technology/personaltech/07pogue.html"The network password is printed right there on the bottom of the MiFi >> itself." >> >> > At least it's not "0000". > > But yes, my Mifi *had* the password on the bottom. > In a lot of cases, physical access = you're screwed anyway. What's the difference if the password is printed on the box? If you can't physically protect your kit, that's something else, but aside from things like WAP's which are routinely in 'the open' surely you protect your equipment inside secure racks/cabinets/datacentres such that the physical labelling is inaccessible to those who aren't authorised... ? From mpalmer at hezmatt.org Wed Jan 6 19:54:22 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 7 Jan 2010 12:54:22 +1100 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> Message-ID: <20100107015422.GK25450@hezmatt.org> On Wed, Jan 06, 2010 at 08:41:14PM -0500, Joel Esler wrote: > On Wed, Jan 6, 2010 at 8:26 PM, Steven Bellovin wrote: > > On Jan 6, 2010, at 6:24 PM, Jeffrey I. Schiller wrote: > > > An option I saw years ago (I forgot on whose equipment) was a default > > > password which was a function of the equipment's serial number. So you > > > had to have the algorithm and you needed the serial number which was not > > > related to the MAC. So if you didn't have physical access, you were not > > > in a good position to learn the password. > > > > > > I suspect this was a support nightmare for the vendor and I bet they > > > went to a more standard (read: the same) factory password. > > > > > > At the end of the day, minimizing support costs for the vendor (not to > > > mention likely annoyance for the customer) trumps providing "default" > > > security for the folks who won't change the default password. > > > > The MyFi apparently does this. According to > > http://www.nytimes.com/2009/05/07/technology/personaltech/07pogue.html"The network password is printed right there on the bottom of the MiFi > > itself." > > At least it's not "0000". > > But yes, my Mifi *had* the password on the bottom. As long as the passwords are reasonably secure (ie not generated to a simple pattern that can be easily brute forced) and they can be changed, I'd consider that to be pretty reasonable security. As has been mentioned in this thread already, if someone's got physical access to your equipment you're dead in the water, security wise, so having the device-specific "factory" default password on the equipment is far more secure than having a single factory default password, whilst being *far* more user friendly than a hash-the-serial-number approach -- or even a "prompt for a password before I'll do anything" (which, I agree, is the most secure, but is still not very usable). For the record, all of my personal networking gear has the admin credentials (and whatever else I need to get into them, like IP addresses, etc) written on it. I don't trust myself to remember those over the years, and assuming that anything else is going to be working when I *need* to get into them seems awfully optimistic. - Matt From mcdonald.richards at gmail.com Wed Jan 6 21:08:57 2010 From: mcdonald.richards at gmail.com (McDonald Richards) Date: Thu, 7 Jan 2010 14:08:57 +1100 Subject: ASR1002 In-Reply-To: <9813C702-36BA-4B50-ACFB-FD18D27B78B4@puck.nether.net> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <9813C702-36BA-4B50-ACFB-FD18D27B78B4@puck.nether.net> Message-ID: <8bde567b1001061908i6b334d90mbf28d3b0ec74fc05@mail.gmail.com> I'd recommend 2.4.x (XNDx) unless you REALLY need the BGP PIC features in 2.5. 2.4 was the first release to support L2VPNs and should be mature enough in it's general support of MPLS/VRFs. 2.5 is still VERY new and was only released publicly in December. 2.4.2 still has a few bugs but for the features you've listed above, should be stable enough. After running it since it's release (2.3.2 previously) I've not seen a software crash on any of our ASR1Ks. I run a mix of RP1 and RP2 devices and since this an ASR1002 you'll be after the RP1 code. McDonald On Thu, Jan 7, 2010 at 11:45 AM, Jared Mauch wrote: > I would run at least the 2.5 software (XNE). > > You don't mention if you have RP1 or RP2, if you're doing sw redundancy or > hw redundancy or both, etc.. This will also have an impact. > > I've seen some 'odd' issues with BGP on the ASR1k, so you really do want to > track the latest code. It's also recommended to keep a close eye on your > memory utilization and if/when any cores show up on the harddisk(s). > > - Jared > > On Jan 6, 2010, at 7:36 PM, Kenny Sallee wrote: > > > Anyone have recommendations on solid IOS XE code for ASR 1002 that's just > > doing: > > > > - BGP > > - VRF's > > - Many sub-interfaces and ACL's > > > > It shipped with 02.04.02.122-33.XND2.bin > > > > Thanks, > > Kenny > > > From joe at nethead.com Wed Jan 6 21:12:58 2010 From: joe at nethead.com (Joe Hamelin) Date: Wed, 6 Jan 2010 19:12:58 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <20100107015422.GK25450@hezmatt.org> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> <20100107015422.GK25450@hezmatt.org> Message-ID: <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> I've been in training with the WWP folks for the last two days (VERY GOOD TRAINING, BTW!) and they got quite a chuckle out of this thread. They say if a customer is willing to pay they can change the initialization method. But I'm guessing that anyone willing to pay would be the type to actually secure the box once it's turned-up. If you got some serious layer 2 stuff to do, these boxes have a really interesting architecture and some trick features (unix type shell, for one.) -Joe -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From rdobbins at arbor.net Wed Jan 6 21:19:55 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 7 Jan 2010 03:19:55 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> <20100107015422.GK25450@hezmatt.org> <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> Message-ID: On Jan 7, 2010, at 10:12 AM, Joe Hamelin wrote: > they got quite a chuckle out of this thread. Which goes to show that they just really don't get it when it comes to security. Maybe they should look here at all the entries for 'default credentials': ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Wed Jan 6 21:22:30 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 7 Jan 2010 03:22:30 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> <20100107015422.GK25450@hezmatt.org> <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> Message-ID: <698A9D5B-0CBC-4BE5-AF86-0A373A3697BA@arbor.net> On Jan 7, 2010, at 10:19 AM, Dobbins, Roland wrote: > Which goes to show that they just really don't get it when it comes to security. Maybe they should look here at all the entries for 'default credentials': Actually, should be 'default password'. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From mysidia at gmail.com Wed Jan 6 22:01:39 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 6 Jan 2010 22:01:39 -0600 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <4B44E09D.8010004@jsbc.cc> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B44E09D.8010004@jsbc.cc> Message-ID: <6eb799ab1001062001g14a29c55wc9cb427a7446d21@mail.gmail.com> On Wed, Jan 6, 2010 at 1:12 PM, Jim Burwell wrote: [snip] > Yeah. ?And for devices with no console, only network interfaces, a > default IP address, no default password, and no default route (just in > case they plug it into a real LAN instead of a laptop. ?:p ?). Ah... don't worry about default routes.. Proxy ARP will "fix it".. when combined with a suitable router that does it by default, and help make sure the default-pw'ed device can still be reached by the bad guys. As murphy would have it, default device IP happens to correspond to a valid LAN IP address formerly used by a server, that the neglected perimeter firewall still forwards port 80 traffic to... You know.. an extra port isn't so expensive these days. equipment vendors could just make one of the network ports be labelled "Manage", ship the units with management access disabled, except on that port. Don't allow normal traffic forwarding to/from that port by default. On first login, require a password change to be made before all other changes, such as enabling full management are even allowed, including turning the manage port into a normal port (if it's even necessary). Device should shutdown the manage port, until reboot, via "management port security".. when the first frame is received, memorize the MAC address, as long as carrier is still detected. If later a second MAC address is detected as the source on any frame, or any multicast frame at all is received, other than an ARP for switch's default IP. Light up an orange LED for "security violation" or a "user error" light. :) -- -J From gbonser at seven.com Wed Jan 6 22:06:51 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 6 Jan 2010 20:06:51 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <698A9D5B-0CBC-4BE5-AF86-0A373A3697BA@arbor.net> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01><20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu><59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu><314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com><20100107015422.GK25450@hezmatt.org><79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> <698A9D5B-0CBC-4BE5-AF86-0A373A3697BA@arbor.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7186@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Dobbins, Roland > Sent: Wednesday, January 06, 2010 7:23 PM > To: NANOG list > Subject: Re: Default Passwords for World Wide Packets/Lightning Edge > Equipment > > > On Jan 7, 2010, at 10:19 AM, Dobbins, Roland wrote: > > > Which goes to show that they just really don't get it when it comes > to security. Maybe they should look here at all the entries for > 'default credentials': > > Actually, should be 'default password'. > One of the problems I have seen is an organization where someone uses something stupid just to get something up and running (say a password of "password" or "foo" or something) with every intention of coming back to fix it later but forgets to. That is what I meant yesterday about an organizational "default" password that can be just as bad as the manufacturers default. At least with some manufacturers you can log in from the console with the factory "default" password but can't log in over the network unless you have set one. From bblackford at gmail.com Wed Jan 6 22:31:32 2010 From: bblackford at gmail.com (Bill Blackford) Date: Wed, 6 Jan 2010 20:31:32 -0800 Subject: ASR1002 In-Reply-To: <8bde567b1001061908i6b334d90mbf28d3b0ec74fc05@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <9813C702-36BA-4B50-ACFB-FD18D27B78B4@puck.nether.net> <8bde567b1001061908i6b334d90mbf28d3b0ec74fc05@mail.gmail.com> Message-ID: <680a83091001062031k24c21d8eu61089bc8c17c6048@mail.gmail.com> I'm finding this to be a fascinating thread as I am currently in the process of evaluating some M7i's vs. some ASR1002's. Seems the Jun's have settled into a less reflexive release schedule then the ASRs currently. At some point I'm sure the ASR's release schedule will settle into a trend more like that of the SXI on the 6.5k or the SRx on the 7.6k. I too, will need BGP Netflow Traffic profiling/NBAR uRPF micro packet bursts etc., and hoping to keep it in all in hardware. This may be better suited for the Cisco-nsp list, but I am interested, as I'm sure is the OP, in more opinions of stable releases/trains. Maybe a question better suited for the cisco-nsp list. thanks all -b On Wed, Jan 6, 2010 at 7:08 PM, McDonald Richards < mcdonald.richards at gmail.com> wrote: > I'd recommend 2.4.x (XNDx) unless you REALLY need the BGP PIC features in > 2.5. 2.4 was the first release to support L2VPNs and should be mature > enough > in it's general support of MPLS/VRFs. 2.5 is still VERY new and was only > released publicly in December. > > 2.4.2 still has a few bugs but for the features you've listed above, should > be stable enough. After running it since it's release (2.3.2 previously) > I've not seen a software crash on any of our ASR1Ks. I run a mix of RP1 and > RP2 devices and since this an ASR1002 you'll be after the RP1 code. > > McDonald > > > On Thu, Jan 7, 2010 at 11:45 AM, Jared Mauch > wrote: > > > I would run at least the 2.5 software (XNE). > > > > You don't mention if you have RP1 or RP2, if you're doing sw redundancy > or > > hw redundancy or both, etc.. This will also have an impact. > > > > I've seen some 'odd' issues with BGP on the ASR1k, so you really do want > to > > track the latest code. It's also recommended to keep a close eye on your > > memory utilization and if/when any cores show up on the harddisk(s). > > > > - Jared > > > > On Jan 6, 2010, at 7:36 PM, Kenny Sallee wrote: > > > > > Anyone have recommendations on solid IOS XE code for ASR 1002 that's > just > > > doing: > > > > > > - BGP > > > - VRF's > > > - Many sub-interfaces and ACL's > > > > > > It shipped with 02.04.02.122-33.XND2.bin > > > > > > Thanks, > > > Kenny > > > > > > > -- Bill Blackford Network Engineer From joe at nethead.com Wed Jan 6 22:38:49 2010 From: joe at nethead.com (Joe Hamelin) Date: Wed, 6 Jan 2010 20:38:49 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> <20100107015422.GK25450@hezmatt.org> <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> Message-ID: <79db6ae1001062038r10c155ddp86f775bcda41da75@mail.gmail.com> On Wed, Jan 6, 2010 at 7:19 PM, Dobbins, Roland wrote: > Which goes to show that they just really don't get it when it comes to security. ?Maybe they should look here at all the entries for 'default credentials': Roland, this isn't the home wi-fi market we're talking about. Anyone that's going to buy one of these puppies is going to have a clue about putting their password in. BTW: You have to be on the console or the management port on them to use the default password (ok, you could get on the right VLAN too.) Problem solved, except for those cases where the operator is a total idiot. Trust me, the shop I'm working for isn't that way, not with the size of the roll-out we're doing (25k+ switches.) I liked what you said about firewalls vs. servers but, to be honest, in this thread you're really beating a dead horse. -Joe -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jgreco at ns.sol.net Wed Jan 6 22:45:32 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 6 Jan 2010 22:45:32 -0600 (CST) Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <79db6ae1001062038r10c155ddp86f775bcda41da75@mail.gmail.com> from "Joe Hamelin" at Jan 06, 2010 08:38:49 PM Message-ID: <201001070445.o074jW0c012649@aurora.sol.net> > On Wed, Jan 6, 2010 at 7:19 PM, Dobbins, Roland wrote: > > Which goes to show that they just really don't get it when it comes to security. ?Maybe they should look here at all the entries for 'default credentials': > > Roland, this isn't the home wi-fi market we're talking about. Anyone > that's going to buy one of these puppies is going to have a clue about > putting their password in. You apparently missed the recent thread on NANOG where this guy was asking for some help with "Default Passwords for World Wide Packets/Lightning Edge Equipment" ... apparently not everyone has the "clue" you expect them to. ... 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 kenny.sallee at gmail.com Wed Jan 6 23:31:14 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Wed, 6 Jan 2010 21:31:14 -0800 Subject: ASR1002 In-Reply-To: <8bde567b1001061908i6b334d90mbf28d3b0ec74fc05@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <9813C702-36BA-4B50-ACFB-FD18D27B78B4@puck.nether.net> <8bde567b1001061908i6b334d90mbf28d3b0ec74fc05@mail.gmail.com> Message-ID: <4a80ecce1001062131u61f9e6deyefd074a59afefa6e@mail.gmail.com> >From my research - I'd have to agree. There is VRF aware NAT that I may need in 2.5 - however I shouldn't need it right away. Perhaps give 2.5 a chance to mature a little. Thanks for the feedback. Kenny On Wed, Jan 6, 2010 at 7:08 PM, McDonald Richards < mcdonald.richards at gmail.com> wrote: > I'd recommend 2.4.x (XNDx) unless you REALLY need the BGP PIC features in > 2.5. 2.4 was the first release to support L2VPNs and should be mature > enough > in it's general support of MPLS/VRFs. 2.5 is still VERY new and was only > released publicly in December. > > 2.4.2 still has a few bugs but for the features you've listed above, should > be stable enough. After running it since it's release (2.3.2 previously) > I've not seen a software crash on any of our ASR1Ks. I run a mix of RP1 and > RP2 devices and since this an ASR1002 you'll be after the RP1 code. > > McDonald > > > On Thu, Jan 7, 2010 at 11:45 AM, Jared Mauch > wrote: > > > I would run at least the 2.5 software (XNE). > > > > You don't mention if you have RP1 or RP2, if you're doing sw redundancy > or > > hw redundancy or both, etc.. This will also have an impact. > > > > I've seen some 'odd' issues with BGP on the ASR1k, so you really do want > to > > track the latest code. It's also recommended to keep a close eye on your > > memory utilization and if/when any cores show up on the harddisk(s). > > > > - Jared > > > > On Jan 6, 2010, at 7:36 PM, Kenny Sallee wrote: > > > > > Anyone have recommendations on solid IOS XE code for ASR 1002 that's > just > > > doing: > > > > > > - BGP > > > - VRF's > > > - Many sub-interfaces and ACL's > > > > > > It shipped with 02.04.02.122-33.XND2.bin > > > > > > Thanks, > > > Kenny > > > > > > > From mpalmer at hezmatt.org Wed Jan 6 23:32:54 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 7 Jan 2010 16:32:54 +1100 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <201001070445.o074jW0c012649@aurora.sol.net> References: <79db6ae1001062038r10c155ddp86f775bcda41da75@mail.gmail.com> <201001070445.o074jW0c012649@aurora.sol.net> Message-ID: <20100107053254.GM25450@hezmatt.org> On Wed, Jan 06, 2010 at 10:45:32PM -0600, Joe Greco wrote: > > On Wed, Jan 6, 2010 at 7:19 PM, Dobbins, Roland wrote: > > > Which goes to show that they just really don't get it when it comes to security. ?Maybe they should look here at all the entries for 'default credentials': > > > > Roland, this isn't the home wi-fi market we're talking about. Anyone > > that's going to buy one of these puppies is going to have a clue about > > putting their password in. > > You apparently missed the recent thread on NANOG where this guy was asking > for some help with "Default Passwords for World Wide Packets/Lightning Edge > Equipment" ... apparently not everyone has the "clue" you expect them to. To be fair, he was just asking about factory resetting the device because the current password was unknown, then reconfiguring the device (I'm willing to be generous and assume that the reconfiguration included setting a new, secure password). - Matt From jgreco at ns.sol.net Wed Jan 6 23:56:01 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 6 Jan 2010 23:56:01 -0600 (CST) Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <20100107053254.GM25450@hezmatt.org> from "Matthew Palmer" at Jan 07, 2010 04:32:54 PM Message-ID: <201001070556.o075u1PJ017019@aurora.sol.net> > On Wed, Jan 06, 2010 at 10:45:32PM -0600, Joe Greco wrote: > > > On Wed, Jan 6, 2010 at 7:19 PM, Dobbins, Roland wrote: > > > > Which goes to show that they just really don't get it when it comes to security. ?Maybe they should look here at all the entries for 'default credentials': > > > > > > Roland, this isn't the home wi-fi market we're talking about. Anyone > > > that's going to buy one of these puppies is going to have a clue about > > > putting their password in. > > > > You apparently missed the recent thread on NANOG where this guy was asking > > for some help with "Default Passwords for World Wide Packets/Lightning Edge > > Equipment" ... apparently not everyone has the "clue" you expect them to. > > To be fair, he was just asking about factory resetting the device because > the current password was unknown, then reconfiguring the device (I'm willing > to be generous and assume that the reconfiguration included setting a new, > secure password). But that's my point. Someone who is presumably reasonably clueful had a problem determining what a predefined default password for a given device is. If it's difficult to determine THAT, what sort of chance does an engineer/admin have when he doesn't even possess the manual for the device, and it requires some more clever and sophisticated serial- number based method? The fact that someone has purchased some extremely expensive device does not guarantee that the next guy who has to run it will magically be able to figure it all out. ... 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 bjorn at mork.no Thu Jan 7 03:03:56 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 07 Jan 2010 10:03:56 +0100 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <4B451BAA.4020109@mit.edu> (Jeffrey I. Schiller's message of "Wed, 06 Jan 2010 18:24:26 -0500") References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> Message-ID: <87zl4qp9qb.fsf@nemi.mork.no> "Jeffrey I. Schiller" writes: > An option I saw years ago (I forgot on whose equipment) was a default > password which was a function of the equipment's serial number. So you > had to have the algorithm and you needed the serial number which was not > related to the MAC. So if you didn't have physical access, you were not > in a good position to learn the password. > > I suspect this was a support nightmare for the vendor and I bet they > went to a more standard (read: the same) factory password. Another class of devices, but the Compaq OOM management cards for servers ("RILOE") used to do this. Really nice when the serial number is placed on a sticker on a PCI card... You would usually have to shut down the server and pull out the card to read the sticker. Unless it had fallen off. Did I mention that the cards had a number of stickers with similar numbers on them with no indication which was the real serial number? Well, I'm not going to claim this was the reason why there is no Compaq anymore, but it must have cost them *a lot* in support and frustrated users. For what passible gain? It was still a default password, just a tiny bit more obscure. Bj?rn From nathan at atlasnetworks.us Thu Jan 7 03:37:59 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 7 Jan 2010 01:37:59 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <20100107053254.GM25450@hezmatt.org> References: <79db6ae1001062038r10c155ddp86f775bcda41da75@mail.gmail.com> <201001070445.o074jW0c012649@aurora.sol.net> <20100107053254.GM25450@hezmatt.org> Message-ID: <11B064048F34FD4094CBA16FC04BE219864BC6F2@ex01> Matthew Palmer [mpalmer at hezmatt.org] > To be fair, he was just asking about factory resetting the device > because > the current password was unknown, then reconfiguring the device (I'm > willing > to be generous and assume that the reconfiguration included setting a > new, > secure password). Thank you - You're correct. The administration and security of these devices is hardly magic - but one has to be able to access them in order to secure them. The devices haven't even left my hotel room for the production site, and you would already be SOL if you didn't have access to the either the (management interface AND the Very Long Password) or the (reset button AND the management interface AND (the default password)). Dobbins, Roland [rdobbins at arbor.net] > Which goes to show that they just really don't get it when it comes to > security. So are you specifically opposed to globally default passwords, or are you opposed to being able to reset a device to factory defaults and somehow get into the device? Because while I still maintain there's no real security issue with the former (if there is, there's a bigger issue), all that I'm really gung ho for is the ability to get into a piece of equipment I need to operate, even if I don't have credentials to it. Nothing grinds my gears more than equipment that has to be thrown out because there is no recovery mechanism. I frankly don't much care if the default password on my WWP LE427 is 'wwp' or 'wwp[serial-number-which-is-printed-on-the-back]' - as long as I can get it so I can get in and change it, I'm happy. Steven Bellovin [smb at cs.columbia.edu] > And we all suffer from p0wned devices, because they > get turned into bots. Roland is 100% right. Eh... I think this is confusing cause and effect. We all suffer, but the fact that a device is compromised because of a default password is, at the root of the chain, the result of a faulty Operator. Why was the password left at default? Why was it possible to access the management interface to utilize the default password? I would argue that the solution is to replace or modify the defective operator, rather than replacing, eliminating, or modifying the tool they misused. Joe Hamelin [joe at nethead.com] > I've been in training with the WWP folks for the last two days (VERY > GOOD TRAINING, BTW!) and they got quite a chuckle out of this thread. Are they still around, or are they Ciena employees? My understanding was that they were completely acquired. > If you got some serious layer 2 stuff to do, these boxes have a really > interesting architecture and some trick features (unix type shell, for > one.) Yep, they're rock solid devices. Every deployment I've seen of them as worked very well. Ciena certainly got a good deal out of buying them! I'm actually not sure how much of the WWP gear is still manufactured. Thank you all again for helping me sort out what the factory default WWP passwords are so that I can now have a secure and documented deployment out here! I've received a couple offers of technical assistance from WWP veterans that I may well take up moving forward. Best Regards, Nathan Eisenberg From mike-nanog at tiedyenetworks.com Thu Jan 7 04:04:08 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 07 Jan 2010 02:04:08 -0800 Subject: qwest outage no notice Message-ID: <4B45B198.5040309@tiedyenetworks.com> We just had a qwest outage of about 2 mins at 1:41am pst. When I called to report it I was told it was a 200+ emergency software upgrade due to a security concern, and that we will get a notice later after the fact. Normally we get notices in advance, even for software upgrades due to security or other important issues, so I am curious if other qwest customers had the same experience and wether this is how it's going to be from here on in? The affected platform was juniper and I'd love to know the specfic case being addressed here. Mike- From auser at mind.net Thu Jan 7 04:14:11 2010 From: auser at mind.net (Steve Ryan) Date: Thu, 07 Jan 2010 02:14:11 -0800 Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: <4B45B3F3.1070403@mind.net> Any other specifics? Got a trouble ticket ID? I'm located in the NW (Talent, Oregon, just over CA border..) and we have a few customers on Qwest T1's and the like. We also have a customer who gets MPLS directly from Q. We've yet to hear of any outages for our customers - but I suppose the night is still young... Any other information you got might be helpful.. Regards, Steve On 1/7/2010 2:04 AM, Mike wrote: > We just had a qwest outage of about 2 mins at 1:41am pst. When I > called to report it I was told it was a 200+ emergency software > upgrade due to a security concern, and that we will get a notice later > after the fact. Normally we get notices in advance, even for software > upgrades due to security or other important issues, so I am curious if > other qwest customers had the same experience and wether this is how > it's going to be from here on in? The affected platform was juniper > and I'd love to know the specfic case being addressed here. > > Mike- > From sthaug at nethelp.no Thu Jan 7 06:06:31 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 07 Jan 2010 13:06:31 +0100 (CET) Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: <20100107.130631.74702085.sthaug@nethelp.no> > We just had a qwest outage of about 2 mins at 1:41am pst. When I called > to report it I was told it was a 200+ emergency software upgrade due to > a security concern, and that we will get a notice later after the fact. > Normally we get notices in advance, even for software upgrades due to > security or other important issues, so I am curious if other qwest > customers had the same experience and wether this is how it's going to > be from here on in? The affected platform was juniper and I'd love to > know the specfic case being addressed here. We received 7 Juniper Security Advisories today. My guess is that this is the reason for the Qwest outage you've seen. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From sean at donelan.com Thu Jan 7 08:33:00 2010 From: sean at donelan.com (Sean Donelan) Date: Thu, 7 Jan 2010 09:33:00 -0500 (EST) Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <698A9D5B-0CBC-4BE5-AF86-0A373A3697BA@arbor.net> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> <20100107015422.GK25450@hezmatt.org> <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> <698A9D5B-0CBC-4BE5-AF86-0A373A3697BA@arbor.net> Message-ID: On Thu, 7 Jan 2010, Dobbins, Roland wrote: >> Which goes to show that they just really don't get it when it comes to security. Maybe they should look here at all the entries for 'default credentials': > > Actually, should be 'default password'. Default credentials may be a more generic description of the problem (although "default password" is a better search term). A problem with default credentials is history has demonstrated even an expert (i.e. the vendors own technical support) aren't always certain they've found and changed every default credential possible on complex devices. Its not just the usual console access, but also snmp protocals public/private, http protocols admin, ldap cn=admin, postscript none, decnet mop, and so on. Even if you think you know every possible protocol, some vendors have had the habit of adding new protocols in updates with its own set of defaults for new remote access protocols. Multiple protocols, using multiple authorization sources, with defaults. Its not a suprise why old-timers get annoyed with vendor gear with default remote access methods enabled before the user configured the access credentials for the access method. Eventually you'll get bit by some device, some protocol, that has something enabled without your knowledge. If you require your vendors not to ship stuff with remote access enabled by default, its not a substitute for your own due dilgence, but in practice it helps reduce unexpected incidents. From jshearer at amedisys.com Thu Jan 7 08:42:18 2010 From: jshearer at amedisys.com (Jason Shearer) Date: Thu, 7 Jan 2010 08:42:18 -0600 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01><20100106091837.GF25450@hezmatt.org> <4B451B AA.4020109@mit.edu><59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu><3 14cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com><20100107015422. GK25450@hezmatt.org><79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail .com><698A9D5B-0CBC-4BE5-AF 86-0A373A3697BA@arbor.net> Message-ID: I kind of liked the way the Symantec Vraptor (piece of junk) firewalls used to do it. Factory reset from the front panel, set addressing and it generates new passwords displayed on the LCD. Jason *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. *** From jshearer at amedisys.com Thu Jan 7 08:46:47 2010 From: jshearer at amedisys.com (Jason Shearer) Date: Thu, 7 Jan 2010 08:46:47 -0600 Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: Notices were left at the discretion of Qwest account teams. There was no mass notification. Jason -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Thursday, January 07, 2010 4:04 AM To: NANOG list Subject: qwest outage no notice We just had a qwest outage of about 2 mins at 1:41am pst. When I called to report it I was told it was a 200+ emergency software upgrade due to a security concern, and that we will get a notice later after the fact. Normally we get notices in advance, even for software upgrades due to security or other important issues, so I am curious if other qwest customers had the same experience and wether this is how it's going to be from here on in? The affected platform was juniper and I'd love to know the specfic case being addressed here. Mike- *** NOTICE--The attached communication contains privileged and confidential information. If you are not the intended recipient, DO NOT read, copy, or disseminate this communication. Non-intended recipients are hereby placed on notice that any unauthorized disclosure, duplication, distribution, or taking of any action in reliance on the contents of these materials is expressly prohibited. If you have received this communication in error, please delete this information in its entirety and contact the Amedisys Privacy Hotline at 1-866-518-6684. Also, please immediately notify the sender via e-mail that you have received this communication in error. *** From jrossi at ptnsecurity.com Thu Jan 7 09:02:22 2010 From: jrossi at ptnsecurity.com (Jeremy Rossi) Date: Thu, 7 Jan 2010 10:02:22 -0500 Subject: qwest outage no notice In-Reply-To: <4B45B3F3.1070403@mind.net> References: <4B45B198.5040309@tiedyenetworks.com> <4B45B3F3.1070403@mind.net> Message-ID: <2511F631-C834-4C4D-8D09-B1230FD5CF28@ptnsecurity.com> Give the nature of the issue from juniper I am guessing that a large number of companies were doing upgrades over the last few days as fast as they could. http://j.mp/8XaReK has the details I know of now. On Jan 7, 2010, at 5:14 AM, Steve Ryan wrote: > Any other specifics? Got a trouble ticket ID? > > I'm located in the NW (Talent, Oregon, just over CA border..) and we have a few customers on Qwest T1's and the like. We also have a customer who gets MPLS directly from Q. > > We've yet to hear of any outages for our customers - but I suppose the night is still young... > > Any other information you got might be helpful.. > > Regards, > > Steve > > On 1/7/2010 2:04 AM, Mike wrote: >> We just had a qwest outage of about 2 mins at 1:41am pst. When I called to report it I was told it was a 200+ emergency software upgrade due to a security concern, and that we will get a notice later after the fact. Normally we get notices in advance, even for software upgrades due to security or other important issues, so I am curious if other qwest customers had the same experience and wether this is how it's going to be from here on in? The affected platform was juniper and I'd love to know the specfic case being addressed here. >> >> Mike- >> > From cmadams at hiwaay.net Thu Jan 7 09:04:54 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 7 Jan 2010 09:04:54 -0600 Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: <20100107150454.GA1549798@hiwaay.net> Once upon a time, Mike said: > We just had a qwest outage of about 2 mins at 1:41am pst. When I called > to report it I was told it was a 200+ emergency software upgrade due to > a security concern, and that we will get a notice later after the fact. > Normally we get notices in advance, even for software upgrades due to > security or other important issues, so I am curious if other qwest > customers had the same experience and wether this is how it's going to > be from here on in? The affected platform was juniper and I'd love to > know the specfic case being addressed here. I got 3 notices about the outage related to our 1 Qwest OC-3. As for the Juniper security issues, see juniper-nsp archives. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From if at xip.at Thu Jan 7 09:05:50 2010 From: if at xip.at (Ingo Flaschberger) Date: Thu, 7 Jan 2010 16:05:50 +0100 (CET) Subject: rj21/centronics cable mounting Message-ID: Hi, I'm searching "something", to secure mount/connect a rj21 cable to a device. I have a angled plug like this: http://commons.wikimedia.org/wiki/File:RJ21-female-connector.jpg It can only be screwed to the device at the top side, and is "loose" at the down side. I have seen a type of "knop" at the down side and also that a "hook-and-loop fastener" is used over the whole plug. (http://www.retrevo.com/r/23018bh245/18/ADSL+RJ21+Pinouts/) Any ideas where to get this or any other ideas how to get a good connection? (retro-fit). I know, "straight" rj21 plugs would also solve the problem. Kind regards, ingo flaschberger geschaeftsleitung ____________________________________ crossip communications gmbh A-1020 Wien, Sebastian Kneipp Gasse 1 Tel: +43-1-7261522-0 Fax: +43-1-726 15 22-111 www.crossip.net _______________________________________________________________________________ crossip communications gmbh From ssaner at hubris.net Thu Jan 7 09:17:47 2010 From: ssaner at hubris.net (Steven Saner) Date: Thu, 7 Jan 2010 09:17:47 -0600 Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 7, 2010, at 4:04 AM, Mike wrote: > We just had a qwest outage of about 2 mins at 1:41am pst. When I > called to report it I was told it was a 200+ emergency software > upgrade due to a security concern, and that we will get a notice > later after the fact. Normally we get notices in advance, even for > software upgrades due to security or other important issues, so I am > curious if other qwest customers had the same experience and wether > this is how it's going to be from here on in? The affected platform > was juniper and I'd love to know the specfic case being addressed > here. > > Mike- We experienced the outage, but so far have not received any notifications. Steve - -- - --------------------------------------------------------------- Steven Saner Director of Network Operations Hubris Communications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAktF+xsACgkQvgCxUpg3pZPDrwCgo9IPUGExaOlsmAkoctnpzzkR SpYAniXz5P8Y/2YiCZMjD/t3Bx4/SmC0 =sqgK -----END PGP SIGNATURE----- From joesox at gmail.com Thu Jan 7 09:25:28 2010 From: joesox at gmail.com (JoeSox) Date: Thu, 7 Jan 2010 07:25:28 -0800 Subject: qwest outage no notice In-Reply-To: <20100107.130631.74702085.sthaug@nethelp.no> References: <4B45B198.5040309@tiedyenetworks.com> <20100107.130631.74702085.sthaug@nethelp.no> Message-ID: <785694cd1001070725o46f26cd0r467f2cea22d21fe5@mail.gmail.com> On Thu, Jan 7, 2010 at 4:06 AM, wrote: >> We just had a qwest outage of about 2 mins at 1:41am pst. When I called >> to report it I was told it was a 200+ emergency software upgrade due to >> a security concern, and that we will get a notice later after the fact. >> Normally we get notices in advance, even for software upgrades due to >> security or other important issues, so I am curious if other qwest >> customers had the same experience and wether this is how it's going to >> be from here on in? The affected platform was juniper and I'd love to >> know the specfic case being addressed here. > > We received 7 Juniper Security Advisories today. My guess is that this > is the reason for the Qwest outage you've seen. My QWest account manager called three different people at my business 7hrs before the maintenance. Also mentioned the Juniper Security Advisories. -- Later, Joe From herrin-nanog at dirtside.com Thu Jan 7 09:27:55 2010 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 7 Jan 2010 10:27:55 -0500 Subject: rj21/centronics cable mounting In-Reply-To: <3c3e3fca1001070727n52a1f01x3fa56e8fdd649028@mail.gmail.com> References: <3c3e3fca1001070727n52a1f01x3fa56e8fdd649028@mail.gmail.com> Message-ID: <3c3e3fca1001070727u75fde899rcec951c86a835d31@mail.gmail.com> On Thu, Jan 7, 2010 at 10:05 AM, Ingo Flaschberger wrote: > I'm searching "something", to secure mount/connect a rj21 cable to a device. > I have a angled plug like this: > http://commons.wikimedia.org/wiki/File:RJ21-female-connector.jpg > > It can only be screwed to the device at the top side, and is "loose" at the > down side. > > I have seen a type of "knop" at the down side and also that a "hook-and-loop > fastener" is used over the whole plug. > (http://www.retrevo.com/r/23018bh245/18/ADSL+RJ21+Pinouts/) > > Any ideas where to get this or any other ideas how to get a good connection? > (retro-fit). You mean like this: http://www.cisco.com/en/US/i/000001-100000/55001-60000/55501-56000/55735.jpg http://www.patentstorm.us/patents/6080010/description.html http://www.freepatentsonline.com/6080010.pdf I don't know where to get one after-market, no, but you could conceivably buy some old gear and extract them. http://cgi.ebay.com/a_W0QQitemZ380184008457QQcmdZViewItemQQptZCOMP_EN_Hubs http://cgi.ebay.com/z_W0QQitemZ280444580224QQcmdZViewItemQQptZLH_DefaultDomain_0 -Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From MatlockK at exempla.org Thu Jan 7 09:28:42 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Thu, 7 Jan 2010 08:28:42 -0700 Subject: qwest outage no notice In-Reply-To: <785694cd1001070725o46f26cd0r467f2cea22d21fe5@mail.gmail.com> References: <4B45B198.5040309@tiedyenetworks.com><20100107.130631.74702085.sthaug@nethelp.no> <785694cd1001070725o46f26cd0r467f2cea22d21fe5@mail.gmail.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3DAB@LMC-MAIL2.exempla.org> We also got email notifications about 'emergency maintenance' on our Qwest circuits, from their notice: Reason For Maintenance: EMERGENCY MAINTENANCE TO IMPLEMENT A SOFTWARE PATCH FOR NETWORK RELIABILITY Sure sounds like it's all related to the Juniper advisory to me. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: JoeSox [mailto:joesox at gmail.com] Sent: Thursday, January 07, 2010 8:25 AM To: nanog at nanog.org Subject: Re: qwest outage no notice My QWest account manager called three different people at my business 7hrs before the maintenance. Also mentioned the Juniper Security Advisories. -- Later, Joe From if at xip.at Thu Jan 7 09:34:21 2010 From: if at xip.at (Ingo Flaschberger) Date: Thu, 7 Jan 2010 16:34:21 +0100 (CET) Subject: rj21/centronics cable mounting In-Reply-To: <3c3e3fca1001070727n52a1f01x3fa56e8fdd649028@mail.gmail.com> References: <3c3e3fca1001070727n52a1f01x3fa56e8fdd649028@mail.gmail.com> Message-ID: Dear William, >> I'm searching "something", to secure mount/connect a rj21 cable to a device. >> I have a angled plug like this: >> http://commons.wikimedia.org/wiki/File:RJ21-female-connector.jpg > http://www.cisco.com/en/US/i/000001-100000/55001-60000/55501-56000/55735.jpg > > http://www.patentstorm.us/patents/6080010/description.html > http://www.freepatentsonline.com/6080010.pdf exactly > I don't know where to get one after-market, no, but you could > conceivably buy some old gear and extract them. found - keyword "was" bracket: http://www.connectworld.net/cgi-bin/dataw/CN50-VEL Thanks & kind regards, Ingo Flaschberger From robert at tellurian.com Thu Jan 7 09:29:42 2010 From: robert at tellurian.com (Robert Boyle) Date: Thu, 07 Jan 2010 10:29:42 -0500 Subject: rj21/centronics cable mounting In-Reply-To: References: Message-ID: <1262878664_924067@mail1.tellurian.net> At 10:05 AM 1/7/2010, you wrote: >I'm searching "something", to secure mount/connect a rj21 cable to a device. >I have a angled plug like this: >http://commons.wikimedia.org/wiki/File:RJ21-female-connector.jpg > >It can only be screwed to the device at the top side, and is "loose" >at the down side. Usually there is a small plastic or metal hook on the other side of the panel connector (opposite the screw side) which will allow you to use a small zip tie to secure the unscrewed side of the connector. -Robert "Well done is better than well said." - Benjamin Franklin From jgreco at ns.sol.net Thu Jan 7 09:49:01 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 7 Jan 2010 09:49:01 -0600 (CST) Subject: rj21/centronics cable mounting In-Reply-To: from "Ingo Flaschberger" at Jan 07, 2010 04:34:21 PM Message-ID: <201001071549.o07Fn13q078680@aurora.sol.net> > Dear William, > > >> I'm searching "something", to secure mount/connect a rj21 cable to a device. > >> I have a angled plug like this: > >> http://commons.wikimedia.org/wiki/File:RJ21-female-connector.jpg > > > http://www.cisco.com/en/US/i/000001-100000/55001-60000/55501-56000/55735.jpg > > > > http://www.patentstorm.us/patents/6080010/description.html > > http://www.freepatentsonline.com/6080010.pdf > > exactly > > > I don't know where to get one after-market, no, but you could > > conceivably buy some old gear and extract them. > > found - keyword "was" bracket: > http://www.connectworld.net/cgi-bin/dataw/CN50-VEL Caution, caution... when using those, velcro *first*, tightly, and then attempt to wiggle/remove the connector. It's only good when you can't *actually* move the connector (much). Only then should you tighten the screw (if you're so inclined/holes allow/etc). Personally, while I like velcro, I was not always impressed with the reliability of those sorts of brackets. You can get better reliability by taking a tie wrap base (maybe T&B TC102 or something like that) and screwing it to the side of the socket the wire exits the plug from. Then you screw the plug in with its one screw, and take a zip tie on the other end, and you're very, very securely fastened without any hope of inadvertent loosening. This has the advantage of being visually verifiable, rather than the "try wiggling it" method that's mandatory with the velcro. ... 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 jbates at brightok.net Thu Jan 7 10:25:12 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 07 Jan 2010 10:25:12 -0600 Subject: qwest outage no notice In-Reply-To: <20100107.130631.74702085.sthaug@nethelp.no> References: <4B45B198.5040309@tiedyenetworks.com> <20100107.130631.74702085.sthaug@nethelp.no> Message-ID: <4B460AE8.60404@brightok.net> sthaug at nethelp.no wrote: > > We received 7 Juniper Security Advisories today. My guess is that this > is the reason for the Qwest outage you've seen. > Yeah, they refused to notify due to security concerns from what they told me last night. Notification was performed after maintenance was complete. Jack From smb at cs.columbia.edu Thu Jan 7 10:51:09 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 7 Jan 2010 11:51:09 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <79db6ae1001062038r10c155ddp86f775bcda41da75@mail.gmail.com> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <59790A5B-F03B-472F-99A6-BD289A0FCC5A@cs.columbia.edu> <314cf0831001061741n6d41ab72j36ddb9b59680c0ad@mail.gmail.com> <20100107015422.GK25450@hezmatt.org> <79db6ae1001061912h5593dd21lad8b80e593c9d2fd@mail.gmail.com> <79db6ae1001062038r10c155ddp86f775bcda41da75@mail.gmail.com> Message-ID: On Jan 6, 2010, at 11:38 PM, Joe Hamelin wrote: > On Wed, Jan 6, 2010 at 7:19 PM, Dobbins, Roland wrote: >> Which goes to show that they just really don't get it when it comes to security. Maybe they should look here at all the entries for 'default credentials': > > Roland, this isn't the home wi-fi market we're talking about. Anyone > that's going to buy one of these puppies is going to have a clue about > putting their password in. Again, look at http://ids.ftw.fm/Home/publications/RouterScan-RAID09-Poster.pdf?attredirects=0 -- while consumer devices were much worse, there was a noticeable problem on enterprise devices and a significant problem with VoIP devices, and I suspect that those latter are largely enterprise-based. --Steve Bellovin, http://www.cs.columbia.edu/~smb From mike-nanog at tiedyenetworks.com Thu Jan 7 11:04:13 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 07 Jan 2010 09:04:13 -0800 Subject: qwest outage no notice In-Reply-To: <4B460AE8.60404@brightok.net> References: <4B45B198.5040309@tiedyenetworks.com> <20100107.130631.74702085.sthaug@nethelp.no> <4B460AE8.60404@brightok.net> Message-ID: <4B46140D.8010502@tiedyenetworks.com> > Yeah, they refused to notify due to security concerns from what they > told me last night. Notification was performed after maintenance was > complete. Ok, so the next question is, what harm would a simple advance notice of 'emergency maintenance' caused, vs the very real hassle and inconvenience that DS3-down in the middle of the night caused for operations staff? I personally was yanked out of bed by my network monitoring systems and had to spend at least 5 minutes looking at logs and perf monitors and so forth so I had enough information before making the call to qwest support, thinking we took a hit on our fiber. Some others reported getting 7 or more hours of advance notice - this would have been enough for me, even tho of course I don't like it - and I suspect it could have saved many many others from a similar fate of responding to the event so late. Just saying "we need to do this", does not give the bad guys any ammo with which to attack, and would go a long ways twords preventing needless heroics such as middle of the night investigations by senior staff. The follow up email we subsequently received was fine and we appreciated learning it really was a necessary upgrade and seems justified now with that knowledge, I would simply have appreciated not having to engage my emergency processes for something that was planned. Mike- From mylists at battleop.com Thu Jan 7 11:12:00 2010 From: mylists at battleop.com (Richey) Date: Thu, 7 Jan 2010 12:12:00 -0500 Subject: qwest outage no notice In-Reply-To: <4B46140D.8010502@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> <20100107.130631.74702085.sthaug@nethelp.no> <4B460AE8.60404@brightok.net> <4B46140D.8010502@tiedyenetworks.com> Message-ID: <02f701ca8fbc$86d77050$948650f0$@battleop.com> That should read... Yeah, they refused to notify due to [marketing] concerns from what they Richey -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Thursday, January 07, 2010 12:04 PM Cc: nanog at nanog.org Subject: Re: qwest outage no notice > Yeah, they refused to notify due to security concerns from what they > told me last night. Notification was performed after maintenance was > complete. Ok, so the next question is, what harm would a simple advance notice of 'emergency maintenance' caused, vs the very real hassle and inconvenience that DS3-down in the middle of the night caused for operations staff? I personally was yanked out of bed by my network monitoring systems and had to spend at least 5 minutes looking at logs and perf monitors and so forth so I had enough information before making the call to qwest support, thinking we took a hit on our fiber. Some others reported getting 7 or more hours of advance notice - this would have been enough for me, even tho of course I don't like it - and I suspect it could have saved many many others from a similar fate of responding to the event so late. Just saying "we need to do this", does not give the bad guys any ammo with which to attack, and would go a long ways twords preventing needless heroics such as middle of the night investigations by senior staff. The follow up email we subsequently received was fine and we appreciated learning it really was a necessary upgrade and seems justified now with that knowledge, I would simply have appreciated not having to engage my emergency processes for something that was planned. Mike- From bjohnson at drtel.com Thu Jan 7 11:30:30 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 7 Jan 2010 11:30:30 -0600 Subject: he.net down/slow? Message-ID: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> Has anyone noticed that accessing http://www.he.net or http://ipv6.he.net is either slow or inaccessible? Please let me know if you have a different experience currently. Thanks - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From chd at arizona.edu Thu Jan 7 11:31:58 2010 From: chd at arizona.edu (Chris De Young) Date: Thu, 07 Jan 2010 10:31:58 -0700 Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: <4B461A8E.7020605@arizona.edu> Mike wrote: > We just had a qwest outage of about 2 mins at 1:41am pst. When I called > to report it I was told it was a 200+ emergency software upgrade due to > a security concern, and that we will get a notice later after the fact. Hmm - I got notice in advance. I'll have to go search for the email, but it was sometime before Christmas, since I had it on my calendar. -C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bclark at spectraaccess.com Thu Jan 7 11:43:16 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 07 Jan 2010 12:43:16 -0500 Subject: qwest outage no notice In-Reply-To: <4B461A8E.7020605@arizona.edu> References: <4B45B198.5040309@tiedyenetworks.com> <4B461A8E.7020605@arizona.edu> Message-ID: <1262886196.6153.5.camel@acer> This is one reason why companies should use twitter...great for those impromptu emergency messages. Our electrical utility company uses twitter and I have to admit that it's nice to know what is going on ahead of time even if it is a short message! On Thu, 2010-01-07 at 10:31 -0700, Chris De Young wrote: > Mike wrote: > > We just had a qwest outage of about 2 mins at 1:41am pst. When I called > > to report it I was told it was a 200+ emergency software upgrade due to > > a security concern, and that we will get a notice later after the fact. > > Hmm - I got notice in advance. I'll have to go search for the email, but it > was sometime before Christmas, since I had it on my calendar. > > -C > From tb at tburke.us Thu Jan 7 11:43:10 2010 From: tb at tburke.us (Tim Burke) Date: Thu, 7 Jan 2010 17:43:10 +0000 Subject: he.net down/slow? Message-ID: <22C39FC2-3AE3-495E-827C-F90A9ECAD9C9@tburke.us> Can't access http://he.net from my location here in Chicago... traceroute to he.net (216.218.186.2), 30 hops max, 40 byte packets 1 10.65.44.1 (10.65.44.1) 2.504 ms 1.039 ms 0.653 ms 2 * * * 3 te-2-3-ur04.romeoville.il.chicago.comcast.net (68.86.119.205) 13.648 ms 13.693 ms 13.477 ms 4 be-70-ar01.area4.il.chicago.comcast.net (68.87.230.121) 16.598 ms 16.109 ms 15.896 ms 5 pos-1-12-0-0-cr01.chicago.il.ibone.comcast.net (68.86.90.53) 16.631 ms 16.550 ms 16.598 ms 6 162.97.117.41 (162.97.117.41) 21.319 ms 21.136 ms 20.932 ms 7 Hurrican-Electric-LLC.TenGigabitEthernet1-4.ar2.SJC2.gblx.net (64.214.174.246 ) 74.953 ms 72.685 ms 77.759 ms 8 10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109) 78.804 ms 76.097 ms 79.715 ms 9 * * * 10 * * * 11 * * * 12 * * * On Jan 7, 2010, at 11:32, "Brian Johnson" wrote: > Has anyone noticed that accessing http://www.he.net or > http://ipv6.he.net is either slow or inaccessible? > > Please let me know if you have a different experience currently. > > Thanks > > - Brian > > CONFIDENTIALITY NOTICE: This email message, including any > attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are > not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the > original message. Thank you. > From pstewart at nexicomgroup.net Thu Jan 7 11:49:02 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 7 Jan 2010 12:49:02 -0500 Subject: he.net down/slow? In-Reply-To: <22C39FC2-3AE3-495E-827C-F90A9ECAD9C9@tburke.us> References: <22C39FC2-3AE3-495E-827C-F90A9ECAD9C9@tburke.us> Message-ID: No issues from Toronto area on an HE connection... -----Original Message----- From: Tim Burke [mailto:tb at tburke.us] Sent: Thursday, January 07, 2010 12:43 PM To: nanog at nanog.org Subject: Re: he.net down/slow? Can't access http://he.net from my location here in Chicago... traceroute to he.net (216.218.186.2), 30 hops max, 40 byte packets 1 10.65.44.1 (10.65.44.1) 2.504 ms 1.039 ms 0.653 ms 2 * * * 3 te-2-3-ur04.romeoville.il.chicago.comcast.net (68.86.119.205) 13.648 ms 13.693 ms 13.477 ms 4 be-70-ar01.area4.il.chicago.comcast.net (68.87.230.121) 16.598 ms 16.109 ms 15.896 ms 5 pos-1-12-0-0-cr01.chicago.il.ibone.comcast.net (68.86.90.53) 16.631 ms 16.550 ms 16.598 ms 6 162.97.117.41 (162.97.117.41) 21.319 ms 21.136 ms 20.932 ms 7 Hurrican-Electric-LLC.TenGigabitEthernet1-4.ar2.SJC2.gblx.net (64.214.174.246 ) 74.953 ms 72.685 ms 77.759 ms 8 10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109) 78.804 ms 76.097 ms 79.715 ms 9 * * * 10 * * * 11 * * * 12 * * * On Jan 7, 2010, at 11:32, "Brian Johnson" wrote: > Has anyone noticed that accessing http://www.he.net or > http://ipv6.he.net is either slow or inaccessible? > > Please let me know if you have a different experience currently. > > Thanks > > - Brian > > CONFIDENTIALITY NOTICE: This email message, including any > attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are > not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the > original message. Thank you. > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From Bryan at bryanfields.net Thu Jan 7 11:52:40 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 07 Jan 2010 12:52:40 -0500 Subject: rj21/centronics cable mounting In-Reply-To: References: Message-ID: <4B461F68.8030905@bryanfields.net> Ingo Flaschberger wrote: > Any ideas where to get this or any other ideas how to get a good > connection? (retro-fit). Easy way to solve this is to lace it in place with some no. 9 wax twine. I do this on most of these connectors, it's more secure then the cheesy velcro loops. http://en.wikipedia.org/wiki/Cable_lacing -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From bdfleming at kanren.net Thu Jan 7 12:13:28 2010 From: bdfleming at kanren.net (Brad Fleming) Date: Thu, 7 Jan 2010 12:13:28 -0600 Subject: he.net down/slow? In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> Message-ID: no issues in Kansas City (area) via Internet2 at 12:10pm Central. On Jan 7, 2010, at 11:30 AM, Brian Johnson wrote: > Has anyone noticed that accessing http://www.he.net or > http://ipv6.he.net is either slow or inaccessible? > > Please let me know if you have a different experience currently. > > Thanks > > - Brian > > CONFIDENTIALITY NOTICE: This email message, including any > attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are > not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the > original message. Thank you. > > From nenolod at systeminplace.net Thu Jan 7 12:18:59 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 07 Jan 2010 12:18:59 -0600 Subject: he.net down/slow? In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> Message-ID: <1262888339.6710.28.camel@petrie> On Thu, 2010-01-07 at 11:30 -0600, Brian Johnson wrote: > Has anyone noticed that accessing http://www.he.net or > http://ipv6.he.net is either slow or inaccessible? > > Please let me know if you have a different experience currently. It is up here. > CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the > intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, > copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original message. Thank you. ...why would you have that on a mailing list post? William From jed at jedsmith.org Thu Jan 7 12:48:34 2010 From: jed at jedsmith.org (Jed Smith) Date: Thu, 7 Jan 2010 13:48:34 -0500 Subject: he.net down/slow? In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> Message-ID: <2111EB37-F804-461B-8132-91209BF5EAAE@jedsmith.org> On Jan 7, 2010, at 12:30 PM, Brian Johnson wrote: > Has anyone noticed that accessing http://www.he.net or > http://ipv6.he.net is either slow or inaccessible? Both are up here from both locations I'm bothered to try (business Comcast, Net Access Corp MMU). JS From jcdill.lists at gmail.com Thu Jan 7 12:56:05 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 07 Jan 2010 10:56:05 -0800 Subject: 4.1 earthquake in SF Bay region (was Re: he.net down/slow?) In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> Message-ID: <4B462E45.5040707@gmail.com> Brian Johnson wrote: > Has anyone noticed that accessing http://www.he.net or > http://ipv6.he.net is either slow or inaccessible? > We had a 4.1 earthquake here in the SF Bay area at about 10:09 PST. http://earthquake.usgs.gov/earthquakes/recenteqsus/Quakes/nc71336726.php I believe he.net's primary data center is located in the east bay, relatively near to the epicenter of this quake. This was a small quake, but perhaps a plug got jostled loose during the shaking. Or perhaps the quake is entirely unrelated to your issue. jc From sethm at rollernet.us Thu Jan 7 13:00:22 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 07 Jan 2010 11:00:22 -0800 Subject: 4.1 earthquake in SF Bay region (was Re: he.net down/slow?) In-Reply-To: <4B462E45.5040707@gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <4B462E45.5040707@gmail.com> Message-ID: <4B462F46.8040901@rollernet.us> JC Dill wrote: > Brian Johnson wrote: >> Has anyone noticed that accessing http://www.he.net or >> http://ipv6.he.net is either slow or inaccessible? >> > > We had a 4.1 earthquake here in the SF Bay area at about 10:09 PST. > http://earthquake.usgs.gov/earthquakes/recenteqsus/Quakes/nc71336726.php > > I believe he.net's primary data center is located in the east bay, > relatively near to the epicenter of this quake. > This was a small quake, but perhaps a plug got jostled loose during the > shaking. Or perhaps the quake is entirely unrelated to your issue. > Not down for me (Reno). I also have an IPv6 tunnel to fremont2 that never went down. ~Seth From mike.lyon at gmail.com Thu Jan 7 13:01:17 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 7 Jan 2010 11:01:17 -0800 Subject: 4.1 earthquake in SF Bay region (was Re: he.net down/slow?) In-Reply-To: <4B462E45.5040707@gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <4B462E45.5040707@gmail.com> Message-ID: <1b5c1c151001071101m38bc3a23y73cf6c7928cb8aed@mail.gmail.com> I think the he.net problems occurred before the quake... -Mike On Thu, Jan 7, 2010 at 10:56 AM, JC Dill wrote: > Brian Johnson wrote: > >> Has anyone noticed that accessing http://www.he.net or >> http://ipv6.he.net is either slow or inaccessible? >> >> > > We had a 4.1 earthquake here in the SF Bay area at about 10:09 PST. > http://earthquake.usgs.gov/earthquakes/recenteqsus/Quakes/nc71336726.php > > I believe he.net's primary data center is located in the east bay, > relatively near to the epicenter of this quake. > This was a small quake, but perhaps a plug got jostled loose during the > shaking. Or perhaps the quake is entirely unrelated to your issue. > > jc > > > > From fm-lists at st-kilda.org Thu Jan 7 13:02:50 2010 From: fm-lists at st-kilda.org (Fearghas McKay) Date: Thu, 7 Jan 2010 19:02:50 +0000 Subject: he.net down/slow? In-Reply-To: <1262888339.6710.28.camel@petrie> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> Message-ID: <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> On 7 Jan 2010, at 18:18, William Pitcock wrote: > ...why would you have that on a mailing list post? because the mail server that adds it is too dumb to differentiate between list and direct mail? f From golson at markettools.com Thu Jan 7 13:08:02 2010 From: golson at markettools.com (Greg Olson) Date: Thu, 7 Jan 2010 11:08:02 -0800 Subject: qwest outage no notice In-Reply-To: <4B461A8E.7020605@arizona.edu> References: <4B45B198.5040309@tiedyenetworks.com> <4B461A8E.7020605@arizona.edu> Message-ID: <18937AE4095FB043B9540D6497B15581056728A564@wdccpmail02.markettools.com> Probably related to this: http://www.theregister.co.uk/2010/01/07/juniper_critical_router_bug/ -----Original Message----- From: Chris De Young [mailto:chd at arizona.edu] Sent: Thursday, January 07, 2010 9:32 AM To: Mike Cc: NANOG list Subject: Re: qwest outage no notice Mike wrote: > We just had a qwest outage of about 2 mins at 1:41am pst. When I > called to report it I was told it was a 200+ emergency software > upgrade due to a security concern, and that we will get a notice later after the fact. Hmm - I got notice in advance. I'll have to go search for the email, but it was sometime before Christmas, since I had it on my calendar. -C From matthew at eeph.com Thu Jan 7 13:18:21 2010 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 07 Jan 2010 11:18:21 -0800 Subject: 4.1 earthquake in SF Bay region (was Re: he.net down/slow?) In-Reply-To: <1b5c1c151001071101m38bc3a23y73cf6c7928cb8aed@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <4B462E45.5040707@gmail.com> <1b5c1c151001071101m38bc3a23y73cf6c7928cb8aed@mail.gmail.com> Message-ID: <4B46337D.6050903@eeph.com> Mike Lyon wrote: > I think the he.net problems occurred before the quake... > > -Mike > They did. I was looking at what it looked like from here when the building started swaying. Matthew Kaufman From jna at retina.net Thu Jan 7 13:32:37 2010 From: jna at retina.net (John Adams) Date: Thu, 7 Jan 2010 11:32:37 -0800 Subject: 4.1 earthquake in SF Bay region (was Re: he.net down/slow?) In-Reply-To: <4B46337D.6050903@eeph.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <4B462E45.5040707@gmail.com> <1b5c1c151001071101m38bc3a23y73cf6c7928cb8aed@mail.gmail.com> <4B46337D.6050903@eeph.com> Message-ID: <84DE56BC-4407-4093-BEB0-98A7B0F215C1@retina.net> I'm in downtown SF and felt nothing. -j On Jan 7, 2010, at 11:18 AM, Matthew Kaufman wrote: > Mike Lyon wrote: >> I think the he.net problems occurred before the quake... >> -Mike > They did. I was looking at what it looked like from here when the > building started swaying. > > Matthew Kaufman > --- John Adams (@netik) Retina Communications jna at retina.net http://www.retina.net/tech this email is: [ ] bloggable [ x ] ask first [ ] confidential From bjohnson at drtel.com Thu Jan 7 13:51:41 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 7 Jan 2010 13:51:41 -0600 Subject: he.net down/slow? In-Reply-To: <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan><1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> Message-ID: <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> > > On 7 Jan 2010, at 18:18, William Pitcock wrote: > > > ...why would you have that on a mailing list post? > > because the mail server that adds it is too dumb to differentiate > between list and direct mail? > > f Bingo! ;) - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From fergdawgster at gmail.com Thu Jan 7 14:12:55 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 7 Jan 2010 12:12:55 -0800 Subject: 4.1 earthquake in SF Bay region (was Re: he.net down/slow?) In-Reply-To: <84DE56BC-4407-4093-BEB0-98A7B0F215C1@retina.net> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <4B462E45.5040707@gmail.com> <1b5c1c151001071101m38bc3a23y73cf6c7928cb8aed@mail.gmail.com> <4B46337D.6050903@eeph.com> <84DE56BC-4407-4093-BEB0-98A7B0F215C1@retina.net> Message-ID: <6cd462c01001071212o2566b861q2e67317347805eb0@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 7, 2010 at 11:32 AM, John Adams wrote: > I'm in downtown SF and felt nothing. > I live & work virtually on top of the epicenter of the quake this morning - -- it was pretty mild, but still caused some dish rattling, building swaying, etc., but connectivity around the Bay Area seems to have not been affected by it as far as I can tell. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFLRkA+q1pz9mNUZTMRAshCAJ9bjARpt9Hma5OFbmVDKpXlzvgDlgCgogJX GH+iE81XQ3AvdZqG0bJX6ys= =FJXF -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From dylan.ebner at crlmed.com Thu Jan 7 14:49:20 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 7 Jan 2010 20:49:20 +0000 Subject: qwest outage no notice In-Reply-To: <4B460AE8.60404@brightok.net> References: <4B45B198.5040309@tiedyenetworks.com> <20100107.130631.74702085.sthaug@nethelp.no> <4B460AE8.60404@brightok.net> Message-ID: <017265BF3B9640499754DD48777C3D206717C0CC32@MBX9.EXCHPROD.USA.NET> Same thing for us in Minnesota. Brief outage and emergency outage notification came after the outage. The outage window was for 6:00-12:00GMT, and the outage came at 6:15GMT. We didn't get the notice until 10:30GMT. Qwest had a major outage over the Xmas weekend in MN. I wonder if this is related. They told me it was a bad switch, but that sounded funny. Dylan Ebner -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, January 07, 2010 10:25 AM To: sthaug at nethelp.no Cc: nanog at nanog.org Subject: Re: qwest outage no notice sthaug at nethelp.no wrote: > > We received 7 Juniper Security Advisories today. My guess is that this > is the reason for the Qwest outage you've seen. > Yeah, they refused to notify due to security concerns from what they told me last night. Notification was performed after maintenance was complete. Jack From Valdis.Kletnieks at vt.edu Thu Jan 7 17:13:16 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 07 Jan 2010 18:13:16 -0500 Subject: he.net down/slow? In-Reply-To: Your message of "Thu, 07 Jan 2010 13:51:41 CST." <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> Message-ID: <19839.1262905996@localhost> On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: > > On 7 Jan 2010, at 18:18, William Pitcock wrote: > > > ...why would you have that on a mailing list post? > > because the mail server that adds it is too dumb to differentiate > > between list and direct mail? > Bingo! ;) That sort of gratuitous "add it to everything because our software is too stupid to sort it out" is *this* close to what the legal eagles call "overwarning". Just sayin'. (Basically, your site and everybody else's site sticks it on everything, all the recipients just ignore it the same way we almost always ignore Received: headers because they're on every message and very rarely have any useful content - with the end result that if you stick it on a message that *matters*, it will still get ignored....) Oh, and is your company ready to indemnify my employer for the costs of "destroy all copies of the original message" sufficiently thoroughly to prevent recovery by a competent forensics expert? This may include, but not be limited to, the main mail store for 70,000 people, backup tapes, and other mail systems where the data may have been logically deleted but as yet not overwritten. Just sayin'. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From surfer at mauigateway.com Thu Jan 7 18:50:22 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 7 Jan 2010 16:50:22 -0800 Subject: qwest outage no notice Message-ID: <20100107165022.A742946@resin18.mta.everyone.net> --- mike-nanog at tiedyenetworks.com wrote: From: Mike Ok, so the next question is, what harm would a simple advance notice of 'emergency maintenance' caused, vs the very real hassle and inconvenience that DS3-down in the middle of the night caused for operations staff? I personally was yanked out of bed by my network ---------------------------------------------- Try no notice at all and 4 GigEs of upstream bandwidth down at 1:30am. :-( scott From jfbeam at gmail.com Thu Jan 7 23:58:26 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 08 Jan 2010 00:58:26 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <4B451BAA.4020109@mit.edu> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> Message-ID: On Wed, 06 Jan 2010 18:24:26 -0500, Jeffrey I. Schiller wrote: > An option I saw years ago (I forgot on whose equipment) was a default > password which was a function of the equipment's serial number. So you > had to have the algorithm and you needed the serial number which was not > related to the MAC. So if you didn't have physical access, you were not > in a good position to learn the password. Gadzoox used to do that... the management modules for their hubs had factory set random passwords. It's provided on a sticker with the card, so you can put it where you want -- just don't lose it, because that's only place it exists (without breaking out a JTAG debugger.) Yes, their later gear has standard default passwords. --Ricky From jfbeam at gmail.com Thu Jan 7 23:58:29 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 08 Jan 2010 00:58:29 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <98E72206041B1B408D3F92E91E80BF1807AE1D15@slmail101.softlayer.local> References: <11B064048F34FD4094CBA16FC04BE219864BC3D5@ex01> <20100106091837.GF25450@hezmatt.org> <4B451BAA.4020109@mit.edu> <98E72206041B1B408D3F92E91E80BF1807AE1D15@slmail101.softlayer.local> Message-ID: On Wed, 06 Jan 2010 19:13:28 -0500, Nick Hale wrote: > I think the vendor you're thinking of was Cabletron (now Enterasys). I > had to call them and give them the Serial Number for them to provide me > with the default password to the system after a hard reset (this was for > an ELS100-24TXG 'switch'). And their CPE gear had a 5 minute password reset window after power on. We hated the customers who'd figured that out. While we're on the subject, a lot of leibert gear has a dip switch/jumper block to turn passwords off entirely. (of course, that requires physical access and a power cycle.) --Ricky From jay at west.net Fri Jan 8 00:55:25 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 07 Jan 2010 22:55:25 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <20100107142514.GA23323@mail.zucchetti.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <20100105203906.GO23204@virtual.bogons.net> <4B43A941.1050209@west.net> <20100107142514.GA23323@mail.zucchetti.com> Message-ID: <4B46D6DD.6060901@west.net> Nenad Andric wrote: > On Tue Jan 05, 2010 at 01:04:01PM -0800, Jay Hennigan wrote: >> Or better: >> - Allow from anywhere port 80 to server port > 1023 established > > Adding "established" brings us back to stateful firewall! Not really. It only looks to see if the ACK or RST bits are set. This is different from a stateful firewall which memorizes each outbound packet and checks the return for a match source/destination/sequence. -- 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 jgreco at ns.sol.net Fri Jan 8 01:22:41 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 8 Jan 2010 01:22:41 -0600 (CST) Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: from "Ricky Beam" at Jan 08, 2010 12:58:29 AM Message-ID: <201001080722.o087Mfb1010074@aurora.sol.net> > While we're on the subject, a lot of leibert gear has a dip switch/jumper > block to turn passwords off entirely. (of course, that requires physical > access and a power cycle.) So do a lot of HP/Compaq servers with integrated lights out management. Don't think you even need to power cycle (whether you're brave enough to go poking around the deep innards of an energized server is another matter). I know the DIP switch on older DL385's is a micro DIP switch and it's inconveniently located in the middle of the server behind some stuff. The good part is that you can clear out unknown passwords as long as you have access to the chassis innards. The bad part is that I've seen these left in password bypass mode (though the BIOS thoughtfully warns you of the status if you do that). ... 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 brent at servuhome.net Fri Jan 8 01:40:57 2010 From: brent at servuhome.net (Brent Jones) Date: Thu, 7 Jan 2010 23:40:57 -0800 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> Message-ID: On Wed, Dec 23, 2009 at 1:10 AM, Brandon Galbraith wrote: > We're looking at using Comcast's (business) transit and private ethernet > services at several client locations and I wanted to see what experiences > others have had regarding this. Off-list replies are preferred. > > Thanks, > -brandon > > -- > Brandon Galbraith > Mobile: 630.400.6992 > This was a timely question, as we've have a GigE fiber line with them for 6 months now. Largely, the link performs at ~999Mbit 99% of the time :) However, we've had two issues with connectivity that seem to originate from their network. The link will show up, but both sides of our fiber will show 0 frames received, and lots of transmit errors. It takes a call into the Comcast NOC each time for them to resolve it, but they've been silent on what may actually be going on. These interruptions last anywhere from 30 minutes, to the last one almost 7 hours (luckily over a weekend). Benefits to this, being Metro Ethernet, they do support tagged VLAN's, so cost to entry is low in terms of equipment and setup/support. Our link goes between downtown Portland, OR, to across the river to East Vancouver and Mill Plain. -- Brent Jones brent at servuhome.net From arievayner at gmail.com Fri Jan 8 02:21:34 2010 From: arievayner at gmail.com (Arie Vayner) Date: Fri, 8 Jan 2010 10:21:34 +0200 Subject: I don't need no stinking firewall! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> Message-ID: <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> What is nice about load balancers is that if you design your solution correctly, you can scale them in a very nice way. Things like direct server return, where only the requests hit the load balancer, but the replies (which are usually larger) just route back directly to the client can free up resources on the load balancer to handle more complex policies. This also reduces the imposed symmetry for routing that firewalls bring to the table. Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. Arie On Wed, Jan 6, 2010 at 7:03 AM, George Bonser wrote: > > > > -----Original Message----- > > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > > Sent: Tuesday, January 05, 2010 8:53 PM > > To: NANOG list > > Subject: Re: I don't need no stinking firewall! > > > > > > On Jan 6, 2010, at 11:43 AM, George Bonser wrote: > > > > > Yes, you have to take some of the things that were done in one spot > > and do > > > them in different locations now, but the results are an amazing > > increase > > > in service capacity per dollar spent on infrastructure. > > > > I strongly agree with the majority of your comments, with the caveat > > that I've seen many, many load-balancers fall over due to state- > > exhaustion, too; load-balancers need northbound protection from DDoS > > (S/RTBH, flow-spec, IDMS, et. al.), as well. > > > > Yes, I have seen load balancers fall over, too. I have some interesting > stories of how those problems have been solved. Sometimes it relies on > using a feature of one vendor to leverage a feature of another vendor. > But I generally agree with you. There is a lot that can be done ahead > of the load balancers. > > > > From rdobbins at arbor.net Fri Jan 8 02:28:12 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 8 Jan 2010 08:28:12 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> Message-ID: <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: > Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. GSLB or whatever we want to call it is extremely useful from a general availability standpoint; however, the attackers can always scale up and really distribute their already-DDoS even further (they learned about routeservers and DNS tinkering years ago). Architecture, visibility, and control are key, as are vendor/customer/peer/upstream/opsec community relationships. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From bill at kruchas.com Fri Jan 8 07:22:00 2010 From: bill at kruchas.com (bill from home) Date: Fri, 08 Jan 2010 08:22:00 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> Message-ID: <4B473178.7010100@kruchas.com> All, This thread certainly has been educational, and has changed my perception of what an appropriate outward facing architecture should be. But seldom do I have the luxury of designing this from scratch, and also the networks I administer are "small business's". My question is at what size connection does a state table become vulnerable, are we talking 1mb dsl's with a soho firewall? Or as I suspect we are talking about a larger scale? I know there are variables, I am just looking for a "rule of thumb". I would not want to recommend a change if it is not warranted. But when fatter and fatter pipes become available at what point would a change be warranted. Thanks Bill Kruchas Dobbins, Roland wrote: > On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: > > >> Further on, if you want to really protect against a real DDoS you would most likely would have to look at a really distributed solution, where the different geographical load balancing solutions come into play. >> > > GSLB or whatever we want to call it is extremely useful from a general availability standpoint; however, the attackers can always scale up and really distribute their already-DDoS even further (they learned about routeservers and DNS tinkering years ago). > > Architecture, visibility, and control are key, as are vendor/customer/peer/upstream/opsec community relationships. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > From darkmoon at vt.edu Fri Jan 8 07:24:51 2010 From: darkmoon at vt.edu (Dave Martin) Date: Fri, 8 Jan 2010 08:24:51 -0500 Subject: he.net down/slow? In-Reply-To: <19839.1262905996@localhost> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> Message-ID: <20100108132451.GA19815@vt.edu> On Thu, Jan 07, 2010 at 06:13:16PM -0500, Valdis.Kletnieks at vt.edu wrote: > On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: > > > On 7 Jan 2010, at 18:18, William Pitcock wrote: > > > > ...why would you have that on a mailing list post? > > > because the mail server that adds it is too dumb to differentiate > > > between list and direct mail? > > > Bingo! ;) > > That sort of gratuitous "add it to everything because our software is too > stupid to sort it out" is *this* close to what the legal eagles call > "overwarning". Just sayin'. > > (Basically, your site and everybody else's site sticks it on everything, > all the recipients just ignore it the same way we almost always ignore > Received: headers because they're on every message and very rarely have > any useful content - with the end result that if you stick it on a message > that *matters*, it will still get ignored....) > > Oh, and is your company ready to indemnify my employer for the costs of > "destroy all copies of the original message" sufficiently thoroughly to > prevent recovery by a competent forensics expert? This may include, but > not be limited to, the main mail store for 70,000 people, backup tapes, > and other mail systems where the data may have been logically deleted but > as yet not overwritten. Just sayin'. ;) Valdis: 150,000. Not 70,000. Spread across four machines and eleven partitions and 5 flash partions. Not mentioning the pool of a/v scanners, the quarantine servers, the auth server, the five webmail machines, or the OMR. :-> -- Dave ----- Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed! From rdobbins at arbor.net Fri Jan 8 07:25:28 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 8 Jan 2010 13:25:28 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <4B473178.7010100@kruchas.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> Message-ID: <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> On Jan 8, 2010, at 8:22 PM, bill from home wrote: > Or as I suspect we are talking about a larger scale? Even an attacker with relatively moderate resources can succeed simply by creating enough well-formed, programatically-generated traffic to 'crowd out' legitimate traffic. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From bill at kruchas.com Fri Jan 8 08:02:12 2010 From: bill at kruchas.com (bill from home) Date: Fri, 08 Jan 2010 09:02:12 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> Message-ID: <4B473AE4.7000102@kruchas.com> Roland, I understand, but at the site we are protecting, at what point is the bottleneck the connection speed, and at what point is the state table the bottle neck. It saves me the following uncomfortable conversation. ME> Mr customer, remember that firewall you bought a couple of years ago for $$$$. Customer> Yes... ME> We might better throw it out. And then you can pay me to harden your hosts. Or I could just re cable, and leave it turned on, they would never know (just kidding). And maybe there is no way to tell, but I feel I need to ask the question. Thanks Bill Kruchas Dobbins, Roland wrote: > On Jan 8, 2010, at 8:22 PM, bill from home wrote: > > >> Or as I suspect we are talking about a larger scale? >> > > Even an attacker with relatively moderate resources can succeed simply by creating enough well-formed, programatically-generated traffic to 'crowd out' legitimate traffic. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > From rdobbins at arbor.net Fri Jan 8 08:17:00 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 8 Jan 2010 14:17:00 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <4B473AE4.7000102@kruchas.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> Message-ID: <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> On Jan 8, 2010, at 9:02 PM, bill from home wrote: > And maybe there is no way to tell, but I feel I need to ask the question. Situationally-dependent; the only way to really tell, not just theorize, is to test the firewall to destruction during a maintenance window (or one like it, in the lab). ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From bblackford at gmail.com Fri Jan 8 08:52:07 2010 From: bblackford at gmail.com (Bill Blackford) Date: Fri, 8 Jan 2010 06:52:07 -0800 Subject: Experiences with Comcast Ethernet/Transit service In-Reply-To: References: <366100670912230110y16340050x5e423cb0fed8727d@mail.gmail.com> Message-ID: <680a83091001080652i4d7ec8av7910382a816a702@mail.gmail.com> I've found them to be quite sufficient here in the PDX metro area. They support all L2 tunnels, in particular, QnQ which I require. We have diverse paths, multiple strands and multi-colored. We are a bit of a special case as we are serviced by a group that is intended for government and education which gives us pricing breaks. The commercial shots I have out to meet-me POPs are priced diffrently. Their CPE devices are migrating to Cisco ME3400, etc. devices. Their tiered pricing is based on link speed which I'm not necessarily pleased with but they're starting to become more flexible. They aren't currently honoring our P-tags so our locations that may be oversubscribed have difficulty with priority queueing. Their new core in our area is a single C 7.6k. I would rather they moved from their older F Big Iron to a J MX or C GSR, but I'm sure the group that services us is faced with limited resources (ref pricing breaks earlier). The customer portal provides custom/customer views on their Orion instance which I find even more useful than my own Cacti graphs at times. The engineering staff is very accesible (again our group is unique). I'd like to see them put gear in more colos and hotels. Their uptime and reliability from my perspective has been right on target. -b On Thu, Jan 7, 2010 at 11:40 PM, Brent Jones wrote: > On Wed, Dec 23, 2009 at 1:10 AM, Brandon Galbraith > wrote: > > We're looking at using Comcast's (business) transit and private ethernet > > services at several client locations and I wanted to see what experiences > > others have had regarding this. Off-list replies are preferred. > > > > Thanks, > > -brandon > > > > -- > > Brandon Galbraith > > Mobile: 630.400.6992 > > > > This was a timely question, as we've have a GigE fiber line with them > for 6 months now. > Largely, the link performs at ~999Mbit 99% of the time :) > However, we've had two issues with connectivity that seem to originate > from their network. The link will show up, but both sides of our fiber > will show 0 frames received, and lots of transmit errors. It takes a > call into the Comcast NOC each time for them to resolve it, but > they've been silent on what may actually be going on. These > interruptions last anywhere from 30 minutes, to the last one almost 7 > hours (luckily over a weekend). > > Benefits to this, being Metro Ethernet, they do support tagged VLAN's, > so cost to entry is low in terms of equipment and setup/support. > > Our link goes between downtown Portland, OR, to across the river to > East Vancouver and Mill Plain. > > -- > Brent Jones > brent at servuhome.net > > -- Bill Blackford Network Engineer From Joel.Snyder at Opus1.COM Fri Jan 8 09:21:52 2010 From: Joel.Snyder at Opus1.COM (Joel Snyder) Date: Fri, 08 Jan 2010 08:21:52 -0700 Subject: I don't need no stinking firewall! In-Reply-To: References: Message-ID: <4B474D90.40909@opus1.com> > On Thu Jan 07, 2010 at 01:04:01PM -0800, Jay Hennigan wrote: > >>> Or better: >>> - Allow from anywhere port 80 to server port > 1023 established >> Adding "established" brings us back to stateful firewall! > > Not really. It only looks to see if the ACK or RST bits are set. This > is different from a stateful firewall which memorizes each outbound > packet and checks the return for a match source/destination/sequence. Actually, most firewalls don't check TCP sequence numbers. You are totally correct in that stateless packet filters with "established" are only looking for TCP bits, but the main difference that stateful firewalls add is watching the TCP state machine. Sequence number watching is a bonus, something you can enable on some firewalls, but most of the common ones don't do it by default. 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 Valdis.Kletnieks at vt.edu Fri Jan 8 09:50:22 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 08 Jan 2010 10:50:22 -0500 Subject: I don't need no stinking firewall! In-Reply-To: Your message of "Fri, 08 Jan 2010 08:22:00 EST." <4B473178.7010100@kruchas.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> Message-ID: <6756.1262965822@localhost> On Fri, 08 Jan 2010 08:22:00 EST, bill from home said: > My question is at what size connection does a state table become > vulnerable, are we talking 1mb dsl's with a soho firewall? Security - you're doing it wrong. ;) The question you *should* be asking yourself is "at what size connection am I enough of a network presence that I might attract attention from somebody who might want to attack me?" And that depends more on the *type* of presence than the size of the pipe. If you're a small electrical-components design firm that nobody's heard of, the size of your state table is probably moot. One of your users just drew the attention of some random 4chan /b/tard, the size of the state table is again probably moot. ;) But to answer your question - it's so absurdly easy for a competent(*) attacker to saturate any edge connection smaller than a gigabit or so, that 'state table exhaustion' is only *really* an issue if you have a 10G or bigger pipe. (*) There is of course the case of an incompetent attacker who only has a botnet of a few hundred machines, attacking a small pipe. At that point, it's probably a crap shoot - if your firewall falls over, you've been DDoS'ed. But if it doesn't fall over, you'll probably *still* be DDoS'ed because the machines you're protecting fall over... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mlarson at verisign.com Fri Jan 8 09:52:12 2010 From: mlarson at verisign.com (Matt Larson) Date: Fri, 8 Jan 2010 10:52:12 -0500 Subject: Upcoming DNS behavior changes to .com/.net/.edu name servers Message-ID: <20100108155212.GE52195@dul1mcmlarson-l1-2.local> (Apologies in advance that some of you will see multiple copies of this message on various lists.) On March 1, 2010, VeriSign will be making two changes that affect the behavior of the authoritative name servers for the .com, .net and .edu zones ([a-m].gtld-servers.net). The changes are a prerequisite for deploying DNSSEC in these three zones beginning in 2010. Because of the widespread use of .com and .net, and because resolution of some domains might be affected, we'd like to notify the community in advance about these changes. The two changes are: 1. New referral behavior When queried for an existing A or AAAA record serving as glue (an address record at or below NS records at a delegation point), the authoritative name servers for .com and .net respond with the glue record in the answer section. However, the answer is not marked authoritative, i.e., the AA bit is not set. While this behavior conforms to the DNS standards, recent authoritative servers do not respond this way. Instead, when queried for a name at or below a delegation point, recent authoritative servers respond with a referral to the delegated zone. This behavior is also supported by the DNS standards. The [a-m].gtld-servers.net servers are changing to the latter referral behavior: queries for glue records will result in referrals rather than non-authoritative answers. Note that this change will affect the resolution of certain domains under .com and .net that depend upon one another. For example, the following configuration of mutually interdependent "example.com" and "example.net" zones would work today: example.com. NS ns1.example.net. example.com. NS ns2.example.net. example.net. NS ns1.example.com. example.net. NS ns2.example.com. These two domains are configured in a "cycle": all of example.com's servers are in the example.net domain, and all of example.net's servers are in the example.com domain. Such a cyclic configuration resolves today because [a-m].gtld-servers.net are authoritative for both the .com and .net zones, and because these servers return queries for glue as non-authoritative answers as described above. To illustrate exactly why this configuration works today, consider the steps an iterative resolver (the portion of a recursive name server that sends queries) would follow to resolve any data at "www.example.com": * The iterative resolver queries a .com authoritative name server for "www.example.com" and receives a referral to "example.com" listing only name servers in "example.net". * Even though the referral includes A records for "ns1.example.net" and "ns2.example.net" in the additional section of the DNS message, modern iterative resolvers ignore these records as a defense against cache poisoning. * Having discarded the A records for "ns1.example.net" and "ns2.example.net", the iterative resolver now has the names but no addresses for any "example.com" name servers. It must temporarily suspend the query for "www.example.com" to look up the address of one of the "example.com" name servers. Let's assume it chooses to resolve "ns1.example.net". * The iterative resolver eventually queries a .net authoritative name server for the A records for "ns1.example.net". With the current referral behavior of [a-m].gtld-servers.net, the .net server returns a non-authoritative answer for the A record for "ns1.example.net". The iterative resolver uses this address to contact this "example.com" name server and resolve "www.example.com". As of March 1, 2010, when the referral behavior changes, the .net server will not return the A record for "ns1.example.net"; instead, it will return a referral to "example.net". But recall that all of the "example.net" name servers are in the "example.com" domain. The only reason the iterative resolver is attempting to resolve "ns1.example.net" now is to resolve the initial query, "www.example.com", also obviously in the "example.com" domain. Thus with each domain depending on the other, resolution can no longer succeed. VeriSign has created two lists of .com and .net domains that may be affected by this change: #1: Domains participating in cycles Domains on this list are mutually interdependent as described above. For example, given the scenario described above, both "example.com" and "example.net" would be on list #1. #2: Domains that depend exclusively on domains in cycles Domains on this list are not actively part of a cycle as those in list #1. Instead, all of the domains in list #2 use exclusively name servers from domains that are part of a cycle. In other words, a domain in list #2 has all its name servers from one or more domains in list #1. Continuing the example above, if the domain "foo.com" had name servers "ns1.example.com" and "ns2.example.com", then "foo.com" would appear in list #2. Both lists follow at the end of this message. Note that the lists were created on Monday, January 4, 2010, and the content of the .com/.net registry changes all the time. Therefore, it's possible that some domains in the lists are no longer in cycles nor depend on domains in cycles. If a domain appears in one of the two lists, to ensure successful resolution after March 1, 2010, at least one of its name servers must be changed to either break the cycle (for domains in list #1) or remove the domain's dependency on a cycle (for domains in list #2). 2. Glue no longer promoted to authoritative status In the .com/.net registry system, a domain can be placed on an administrative hold status. A domain on hold is not published: the NS records delegating the domain are removed from the .com or .net zone. For example, registrars sometimes place a domain on hold if it is about to expire but the registrant has not responded to requests to renew it, or if it is being used for malicious activity. Currently, when a domain is placed on hold, its NS records are removed from the zone but not any of the A and AAAA records of name servers in that domain. For example, consider if the domain "example.com" existed in the registry along with the name server "ns.example.com". (An important note: whether or not the "example.com" zone itself actually uses "ns.example.com" as one of its authoritative name servers is irrelevant to the behavior described here. The important point is that "ns.example.com" is in the "example.com" domain, i.e., below it in the DNS name space.) If the "example.com" domain were placed on hold today, the NS records delegating it would be removed from the .com zone. The A and AAAA records for "ns.example.com" remain in the zone. In fact, since these records are no longer below a delegation point, they are promoted to become authoritative data. As of March 1, 2010, when a domain goes on hold, the NS records delegating the domain will be removed from the zone, and the A and AAAA records for name servers below the domain will no longer be promoted to authoritative status. These A and AAAA records will not actually be removed: although they will not be returned when queried for directly, they will appear in the additional section of referrals that reference them. In the example above, if "example.com" went on hold, its NS records would be removed from the zone. But if the "example.net" domain uses "ns.example.com" as a name server, a referral response to "example.net" will include the A and AAAA records for "ns.example.com" in the additional section. A principal motivation for this change is DNSSEC. When DNSSEC is deployed in the .com and .net zones, A and AAAA records promoted to authoritative data would have to be signed, resulting in increased complexity for the overall registry system. This change in business logic (where the removal of a domain on hold also affects name servers below that domain) is consistent with the behavior of other top-level domain registries. If you have questions about these changes, you may follow up here, contact me directly, or send email to VeriSign's registry customer service group at info at verisign-grs.com. Matt Larson -- (Two lists of domains follow.) #1: Domains participating in cycles (139 domains) 150dollarsites.com 150dollarsites.net 3xidc.com 3xidc.net ableincorporated.com ableincorporated.net abnhost.net abshostingdns.com absolutebackground.net aigc.net aigraphics.com alvaldi.net badgerwebhosting.net beleko.com beleko.net bilgitasarim.com bilgitasarim.net buyukbese.net cast4all.com charlestonstudios.com charlestonstudios.net chqdns.com ciberlinux.com ciberlinux.net circlesquared.com clanhq.net crystalbox.net cybercon.com cybercon.net datesistem.com democritus.net dns-logic.com dns-logic.net doblebuffer.net doitwithdomains.com doitwithdomains.net esolution.net eversible.com eversible.net evlilikfuari.net expansionimmo.com eyepublish.com eyepublish.net f-fective.com foremosttech.net ftphosting.net globalli.com globalli.net groksoft.com groksoft.net guvenlihost.com guvenlihost.net hiphip.com hpmarketing.com hpmarketing.net imoxion.com imoxion.net inetgraphix.com innetrex.net iranwebsolutions.com irisindia.net itxasondo.com ivanglez.com ivanglez.net krystalbox.com krystalbox.net lemoncat.com lemoncat.net lighthousesc.com lighthousestrategies.net lokrio.com lokrio.net lpgcngfuari.com madmedya.com madmedya.net markamtanitim.com markljones.com maxosystem.com maxosystem.net mhplus.net middlehost.com mmchost.net myiris.com mykoup.com mykoup.net neptunogp.com neptunogp.net netspan.com ntcell.com ntcell.net nutkenz.net ogocan.net pocketdns.net politicalunrest.net pubbliservice.net qaop.com qaop.net recoverynetworks.com recoverynetworks.net reliam.com ristech.net sabrienix.com sabrienix.net seamlesstech.net sedat.net servermar.com servermar.net sinzi.com sinzi.net smooth-network.com soportesinformaticos.com soportesinformaticos.net sungman.com sungman.net suplima.net taisweb.com taisweb.net tanint.com telemolise.com terramg.com terramg.net tgscom.com tgscom.net therebel.net tobigfive.com trexservers.com uk2serve.com uk2serve.net v-base.net vault5.com vitzo.com w3kweb.com watchxonline.com webexc.com wheelockweb.com wheelockweb.net wtso.net ztorm.com ztorm.net #2: Domains that depend exclusively on domains in cycles (2690 domains) 010101000100110001000011.com 1-800-back-links.com 1800cake.com 1800cakes.com 1800sellbuyrealestate.com 1streviewinc.com 21cbs.net 21cim.net 21cit.net 23r.com 2crowsjoy.com 3day-email.com 3day-email1.com 3day-email10.com 3day-email11.com 3day-email12.com 3day-email13.com 3day-email14.com 3day-email15.com 3day-email2.com 3day-email3.com 3day-email4.com 3day-email5.com 3day-email6.com 3day-email7.com 3day-email8.com 3day-email9.com 3day-emails.com 3day-emails1.com 3day-emails10.com 3day-emails11.com 3day-emails12.com 3day-emails13.com 3day-emails14.com 3day-emails15.com 3day-emails2.com 3day-emails3.com 3day-emails4.com 3day-emails5.com 3day-emails6.com 3day-emails7.com 3day-emails8.com 3day-emails9.com 3day-optout5.com 3rmexico.com 4-most.com 4dengine.com 4leaseorrent.com 4myvote.net 4reset.com 4saleleaseorrent.com 4saleleaserent.com 4salerentlease.com 4salerentorlease.com 4slor.com 50thanniversaryforgrammies.com 50thanniversaryforgrammy.com 50thanniversaryforgrammys.com 50yearsatthegrammies.com 50yearsatthegrammys.com 50yearsforgrammy.com 50yearsforthegrammies.com 7034990011.com 99309.net a345business.com aabank.net aabankvote.net abenet.net abndemo.com abnsite.net aboutspelapoker.com aboutwebbingo.com academyaward.com academyawards.com acarcelik.com accommodationtimes.com aceforprofessionals.com actiiilicensing.com actiondoors.com activhoodia.com actualholdem.com ad2.com ad2us.net adamsgloballogistics.com adbscreening.com adbtech.net adelghorbani.com adriandtoys.com adritoys.com adtous.net adult-mobile.com advanceboiler.com advancedhealthcenter.net advancedlogics.net advancethermotec.com advantechsecurity.net affintus.com africantours.com afsininsaat.com ag-ruraland.net ag-ruralland.net aggressivecraps.com agltc.net agruraland.net agruralland.net agshandrails.com ahdeveney.com ahiretyolcusu.com ahmedhakeem.com aicpnext.com aicpshow.com aihosting.com air-ticket.com airauctions.com airbazar.com airreservation.com akatra.net akazemiart.com akhim6.com aktuelmedya.com akyildizplastik.com al-natsheh.net al7ob-gaza.com alaaddintoy.com alavitabar.com albertocontador.com alexanderrv.net alexanderslandscaping.net alicenav.com alivesupplements.com allactiontrade.net allenfamilia.com allergiemittel.com allfords.net allkeno.com allsaladapoker.com alocen.com alphacf.com alphash.com altecheco.com altinozofis.net altunozmetal.net altunozofis.net alvinbitkisel.com alwayscarehealth.com ambasoft.com ambrosianostra.com amen.net amensolutions.com american-stamp.com americandatabank.net americandreambenefit.net americankarateofaustin.com americansurvivalcompany.com amexrep.com ampedout.com ampnow.com amsterdamshopmap.com amsterdamtoenennu.com anapiccola.com anavatankagithane.com ancashloans.com andreaduro.com andrewshaw.net angerbanger.com angiecorporation.com angledebeaute.com angledebeautes.com anglucksspiel.com anhomeloan.com aninsureauto.com aninsurehealth.com ankarapinarhaliyikama.com anleihen-finder.com anniversarytravelregistry.com anonlinecredit.com anotherbaccarat.com anotherblackjack.com anothercasinos.com anotherkasino.com antalyaholidayworld.com antalyalifehospital.com antalyamuhtarlar.com antalyaseramik.com antalyatravelworld.com antikpazar.com apoher.com appraisalforum.net appstorewrapup.com aradhana.net archadeck-email1.com archadeck-email2.com archadeck-email3.com archadeck-email4.com archadeck-email5.com archadeck-optout1.com archadeck-optout2.com are-you-ill.com arenatarim.com aresgrup.com areyouill.com arghavanshekari.com armabanyo.com armornet.net arniflora.com arnifloragel.com arsenalpb.com artandco.com artandcompany.com asadoguarani.com asaplimousine.net aselcom.net aserpinto.com ashburnhomes.net asheville-downtown.com asheville-elderlaw.com asheville-realestate.com ashevillecom.com ashevilledowntownwireless.com ashevilleelderlaw.com ashevillelivecamera.com ashevilletraffic.com ashevilletrafficreport.com ashevillewireless.com ashstevensisfocused.com asianaffairholidays.com associatedchemicals.net astorstreet.com astrodirect.com athletestyle.com athostech.net athostechnologies.net athostechnology.net athosteck.net atidgapyear.net atidisrael.net atlanticassociates.net atlanticrepublic.com atxholdempoker.com auctionairticket.com auctionairtickets.com auctioncruises.com auctiontours.com auctionvacation.com auctionvacations.com auhlaw.net austinburt.com auto-mega.net autodonation.net autodonationcharities.net automega.net automotive-awi.com autorijschooltremendo.com autumntravel.net avatasarim.com avpdizayn.net awajiya.net aydesing.net aynenzi.com aynetdesign.net ayyildiz-team.com azstonecare.com babiesarewelcome.com babiesrwelcome.com babymayer.com baischandskinner.net bajarwii.com baktashsarang.com balchmachine.com banakontor.com bandofcare.net bandofcaring.net banquepc.com banqueplus.com baptistworldalliance.com barefootbella.net baretraps.net barnesassoc.net basicremortgage.com batesvillecdj.com batzer-family.com baymaf.com bb63vets.com bbread.net bbrp.net bbtcam.com bbtcamera.com bc-centralplus.com bclip-sales.com bcsawfilers.com beauteservice.com bebemobile.com believers-networks.com believersnetworks.com bellemeade.net beraenerji.com bergerdean.com berlinsys.com bernardocafe.com besslertracksideauto.com best-hoodia.com bestmedicalinsure.com bestofcards.com bestpokerseite.com betterdesigngroup.com bid4spots.com bidforspots.com bidfourspot.com bids4spot.com bids4spots.com bidsforspot.com bidsforspots.com bidsfourspot.com bidsfourspots.com big62.com bigcitydelicatessen.com bigcitywines.com bigdawgz.com bigislandfractionals.com bigloandebt.com bigmop.com bigmophomes.com bigwebcazino.com bilisimevreni.com bilisimfrm.net bilisimhost.com billspan.com biltmoreforestcruise.com biltmoreforestlive.com biltmoreforesttravel.com birdsongbooks.net birolcan.com bison-fute.net bisonfute.net bitkiselurunpazari.com bizems.com blackgrammy.com blackstarbags.com blacktigerkarate.com blackwagon.com blipvideo.net blows-hard.com blue-marble.net bluegrassllc.net bluehensprings.com bluehwy.com blueridgebuilders.net blueridgeheritagearts.com blueridgeheritageinc.com blueriverprinting.com boatownersclubofamerica.net bobmobley.net boericke.com bolubagislar.com boluildernegi.com bonesoy.com bootiemall.com bootymall.com bordercrossersforchrist.com botthouse.com bounceaboutltd.com boyte.net brakeysolutions.com brasseagleparts.com braunengineering.net breadandbagel.com breezebrazil.net bremcoinc.com brewerinsuranceinformationservice.com brightonmobile.com brownsite.net broy3.com broylive.com budgetrgv.com buildersdrawings.com burlesonearleykeel.com bushmasterparts.com businessincorporators.net butler-farm.com butlerandcooke.com buybwatours.com buycurrency.com bwatours.com bwatourscentral.com bwatoursonline.com bwayouthconference.com cagintarim.com cajunqueenscuisine.net califloragel.com callawayfurniture.net camsconstruction.com can-turkco.net canadiancalculatorwarehouse.com candasmanzano.com canistrum.net canlar.net caphomes.net cardonation.net caregivingconnection.net careprep.com carersrelief-dgs.com carlssonpalmer.com carltonchauffeurs.com carmelcorsairs.com carmelproprinter.com cartiersuicide.com casaespina.com cassrogers.com cat-breeding.com catherinemoy.net cayugabay.net cbllensusa.com cdbe.net cdcc.net cdslp.net ce.net celebritypaintball.com cellulite.net celticguitarstrap.com celviano.com centralcoffee.net centralcoffeeroasters.net centralpets.net centraltxparrotheads.com chandlee.com chaseonbase.com chennaiplots.net chickcorea.net cholamandalam.com christiangrammy.com christiantours.com christinagowns.net chromefile.com chromeriver.com cinemaguarani.com citiplex.net cityhighfootball.com citypartners.net cizgi-mobilya.com cjbrankov.com clanhqhosting.net clasenti.com classentipiano.com classentipianos.com classenty.com classienti.com clearreflectioncoaching.com clemcal.com clevertrevor.net clickalo.com client-awi1.com client-awi10.com client-awi2.com client-awi3.com client-awi4.com client-awi5.com client-awi6.com client-awi7.com client-awi8.com client-awi9.com clients-awi.com clifty.net clothesforyoga.com cobanalibaba.com cobblestoneshoerepair.net cohrp.com coldfresh.com collage-video.net collagevideo.net collegecitylimit.net collegecitylimits.net collegecitylimitz.net collegetownonline.net colorgloledlighting.com comeuphigh.net commercialprocess.com commoncasinojeux.com communicate-eei.com completia.com concentricco.net concentricsourcing.net contessabags.com continuumdebthelp.com cookingwithsanyo.com coolbingohall.com cooldogz.com coolgiochicasino.com coolpokerrooms.com coolpokerseite.com coolspelapoker.com copadeorobar.com copadorobar.com copydocamerica.com corionis.net cornerstoneadv.com cornerstonefunds.com coronillas.com corplimo.net corporate-insiders.net corporateinsiders.net corporatepros.com corruptshun.com county-crim.com county-researcher.com countycrim.com countyresearcher.com covadiria.com cox-hobbies.com coxhobbies.com cpmsystems.com creativmedia.net creditheaderdata.com creditheaders.com crime-snoop.com crimesnoop.com criminalcheck.net cruisereservation.com csikr.com ctxphc.com cukurovatarim.com currentashevilletraffic.com curvykarma.com custardandmustard.com customaryroulette.com customautotrim.net customsportsgear.net cybcon.com cyber-h.net cybergrammy.com cybersingles.net cymbals.com cymbalshop.com da-office.com dagyelialabalik.com dailycraps.com dailyinsurehealth.com dailyparidepoker.com dailysurvey.net dailysurveys.net daleeelak.com dalejarretttoyota.net dallas-summit.com dallassummit.com danieljvoccia.com dannystoltz.com danvoccia.com data-awi1.com data-awi10.com data-awi11.com data-awi12.com data-awi13.com data-awi14.com data-awi15.com data-awi16.com data-awi17.com data-awi18.com data-awi19.com data-awi2.com data-awi20.com data-awi3.com data-awi4.com data-awi5.com data-awi6.com data-awi7.com data-awi8.com data-awi9.com datapilot.com datatransfercenter.com davidandthea.net daydreamswylie.com dbprinting.net dealum.net deanmayer.com debralenes.com declareyourself.com dedicatedtowomenobgyn.net deepcontemplations.com definitefinance.com delaware.net delawarebestbuy.com delawareministorage.com delawaremodernpediatrics.net delawaresbestbuy.com delawrae.net delcorpamerica.net deleware.net delmarvaalf.net delmarvatraining.com deltatelecominc.net demecinc.net demokratakademi.com denizwebtasarim.net denofdeliverability.com dermdoc.net derps.net designsbyelana.com desireins.com deskmagazine.net destination-israel.net destinationisrael.net desynced.com desynergy.com desynergy.net deverkoopschool.com dhsforms.net diabetessymptom.net diaconcrete.com dietdrugs.net digital-pianos.com digitalvisitorhosting.com dim-plus.com discountcaribbeanvacations.com discoveryreprographics.com distinguishedlimoservice.net diveredtogo.com diversiontv.com diyar21.net djaugustin14.com djcremefresh.com djjayskee.com dllabs.net dmodata-feedback.com dodgynet.net dollshop.net dolphinland.net donatecar.net donationcar.net donotcallsoftware.net donovanpalmer.com dontpiratemovies.com dorseygolf.com doveautodetailing.com doverrentall.com dowcpass.com dowmicrobialcontrolnews.com downtownashevillewireless.com dreamweaver.net drewpatterson.com drieredtogo.com drieveredtogo.com drinkest.com driveed2go.com driverddtogo.com driverdtogo.com drivered2go.com drivereddtogo.com driveredotgo.com driveredtgo.com driveredtgoo.com driveredtog.com driveredtoggo.com driveredtogoo.com driveredtoog.com driveredttogo.com drivereedtogo.com drivereetogo.com driveretdogo.com driveretogo.com driverredtogo.com driversdtogo.com driversed2go.com drivredtogo.com drivreedtogo.com drkaemmerer.com drumsticks.com drveredtogo.com drysinkdesign.com duanemorrisloses.com dunkindonuts-awemail.com duranmehmet.net duvallosteen.com duygucafe.net dwaccess.com dxl.net dynamic6.net e-proxy.net e-tangent.com e-zmark.net eachgiochicasino.com eaglesnesthomes.net eaglest.com earth-source.net easternshoremaryland.com easylawn.com easylifecosmetics.com ebolterinn.com ebookcenter.net ebookpr.net ebookpress.net ebookworld.net ebrugundesfanclup.net ecamp2009.net ecamp4u.net ecamp4you.net ecampalumni.net ecampasia.net ecampeurope.net ecampforyou.net ecampisrael.net ecampnc.net ecampstaff.net ecampsworld.net ecaribbeanvacationpackages.com ecirrigation.com ecoclosings.com ecpmd.com edatasearch.com education-email1.com education-email10.com education-email2.com education-email3.com education-email4.com education-email5.com education-email6.com education-email7.com education-email8.com education-email9.com educationalschooltours.net edutrainme.com eeats.net eertown.net eerzone.net efagold.com efnetwiki.com ehlikuran.com ek-tech.com ekaputra.com ekegs.com elainelajoie.com elcuartocreciente.com electronic-rd.com elektronikhayat.net elicat.com elicate.com elitemejorcasino.com elitepokergratis.com elitepokerligne.com elitepoquer.com elliebarbeerealty.com elpatomexicanfood.com email-awi.com email-awi1.com email-awi10.com email-awi11.com email-awi12.com email-awi13.com email-awi14.com email-awi15.com email-awi16.com email-awi17.com email-awi18.com email-awi19.com email-awi2.com email-awi20.com email-awi3.com email-awi4.com email-awi5.com email-awi6.com email-awi7.com email-awi8.com email-awi9.com email-logic.net email4travelagents.com emailoverture.com emails-awi.com emails-csi.com emaksan.com emirdagforum.net emmafakes.com empcapital.com empirecarehealth.com employeefirstnetwork.net employmentscreeningfranchise.com empyreancapitals.com emuneo.com energysmartcorp.com englishlaundry.com enkolik.net enm6.net ensenadaonline.com entertainmentlawinitiative.com entirebaccarat.com envirotemp.net epic-culture.com epicculture.com epiconsulting.com epntec.com epolicingmail.com erkagrup.com eroticlondon.net erria.com ertanotomotiv.com esocialsciences.com espsmc.com estrosoy.com etatilim.com eunipiro.com europeantours.com europeol.net eutotec.com everyroulette.com everyslots.com evgent.com examfx.net excelsiorveritas.com execlimousine.net executiveeconomy.com executiveeconomyclass.com exerflex.net existentgamble.com expansiontank.net extracarinsure.com extrahomeloans.com extrajeudepoker.com eyeline.net ezfund.net ezmigliorecasino.com ezol.net ezon.net ezspielpoker.com f-webshop.net faaida.com facility-op.com facility-ops.com faircraps.com fairgiochicasino.com falcontarget.com familiesfocus.com family-travel.com fanidunya.net fantasticcraps.com fantasticroulette.com farkindanalik.com fart-f.com fartminusf.com fasthealthfood.net fastholdem.com favorablebet.com featurecarehealth.com fectogroup.net fenwickislandlighthouse.net fflekker.com fflekkeramateur.com fflekkeranders.com fflekkergay.com fflekkerthuis.com fgrammy.com fibroalive.com filoinsaat.com findgolfholidays.com finedj.com finestbet.com finikeportakal.com finikeportakali.com firstreviewinc.com firststate.net firststatefun.com firsttymemom.com fisherav.com fisherspopcorn.net fit4college.com fix37.net flashreferral.com flicketz.com floralartgifts.com florasone.com floridamortgageassociation.net floridamortgagebrokers.net flysingaporeair.com flysingaporeairlines.com fm-gallery.com foremostanesthesia.com foremosttelecom.com foremosttelecommunications.com forestmanorinn.com forevercareplans.com forktrain.com forktraining.com formsigorta.com forsalein.com forsaleleaseorrent.com forsaleleaserent.com forsalerentlease.com forsalerentorlease.com forslor.com forumefsane.com foundationmares.net foxteknoloji.net foxyholes.com fpai.net fraudulentclicks.net freddyadu.com freecarmedia.com freegames4nokia.com freelifecenter.com fried-epstein.com frisson-media.com fuckhartmannexhibits.com fullbaccarat.com fullcasinovirtuel.com fullerhotrods.com fullymanagedservers.net funartists.com funcaribbeanvacations.com funcruisevacations.com funmexicanvacations.com funtechind.com fvvc.com g3med.com galaxy88.net galleryminerva.com gallerysixsf.com gamedonkey.net gameingbros.com gameplaymobile.com games-4-lg.com games-4-mobile.com games-4-mobiles.com games-4-motorola.com games-4-nec.com games-4-nokia.com games-4-siemens.com games-4-sony-ericsson.com games4ericsson.com games4lg.com games4motorola.com games4nec.com games4nokia.com games4panasonic.com games4sagem.com games4samsung.com games4sharp.com games4siemens.com games4sonyericsson.com gapyearatid.net gapyearisrael.net gardenpotter.com garlicin.com gateplex.net gatewayambulance.net gatewaymiataclub.net gbfoodforthought.net gbphc.com gbv.net geciktiricipjur.com geldareport.com gencircles.net genesisexecutive.net genkimya.com genuinepokerspel.com geoinfosharedev.com getbonds.com getreducedebt.com gfbilbao.com ggrammy.com giangreco.com giantcarehealth.com gidavesaglikdergisi.com giltweasel.com ginkgold.com girlsofmotocross.com givecars.net giveson.com givingtreegift.com givingtreejewelry.com glasir.net globaljeuxpoker.com globallogics.net gloriagifford.com gmelink.net go-ici.com go2faith.com goallstarlimo.net gocaribbeanvacationpackages.com godguide.net godvomit.com godwinsigns.com gogreencarbon.net gogreeninisrael.net gokhanozkaya.com goldenwombat.com golf-trainingaids.com golfinglive.com gomexicovacationpackages.com gonetworking.net goodfeet-emails1.com goodfeet-emails10.com goodfeet-emails2.com goodfeet-emails3.com goodfeet-emails4.com goodfeet-emails5.com goodfeet-emails6.com goodfeet-emails7.com goodfeet-emails8.com goodfeet-emails9.com goodmorningkansas.net goodmorningnetwork.net goodmorningwichita.net googlesyndication-ads.com gorawvegan.com gospelapoker.com gospielbank.com gotocollegenow.com gotoisraelfree.net gotyouranswer.com goudbehandelingen.com govisitcaribbeanislands.com gps-global.net gpsconsultants.net gpsglobalinc.net graammy.com grammiawards.com grammies-50thanniversary.com grammies-50thcelebration.com grammies-50years.com grammies50thanniversary.com grammies50thcelebration.com grammies50thyearanniversary.com grammies50thyearcelebration.com grammiesat50.com grammiesat50years.com grammiescelebrate50.com grammiescelebrates50years.com grammiescelebrating50years.com grammiestocelebrate50.com grammiestocelebrate50thanniversary.com grammiestocelebrate50years.com grammiestocelebrate50yrs.com grammiesturn50.com grammmy.com grammy-50thanniversary.com grammy-50thcelebration.com grammy-50years.com grammy-award-info.com grammy-awardinfo.com grammy50thanniversary.com grammy50thyearanniversary.com grammy50thyearcelebration.com grammyarchive.com grammyartofmusic.com grammyasia.com grammyat50.com grammyat50years.com grammyatl.com grammyawardwinner.com grammybs.com grammycelebrates50.com grammycelebrates50th.com grammycelebrates50thanniversary.com grammycelebrates50years.com grammychi.com grammychicago.com grammydc.com grammye.com grammyebook.com grammyexpo.com grammyexposition.com grammyfl.com grammyfla.com grammyfoundation.com grammyis.com grammyjam.com grammylac.com grammylaw.com grammymphs.com grammynashville.com grammynyc.com grammyphilly.com grammyphl.com grammyrecords.com grammys-50thanniversary.com grammys-50thcelebration.com grammys-50years.com grammys-creations.com grammys50thanniversary.com grammys50thcelebration.com grammys50thyearanniversary.com grammys50thyearcelebration.com grammysat50.com grammysat50years.com grammyscelebrate50.com grammyscelebrates50years.com grammyscelebrating50years.com grammysf.com grammysgifts.com grammysgroupies.com grammysphotos.com grammystocelebrate50.com grammystocelebrate50thanniversary.com grammystocelebrate50years.com grammystocelebrate50yrs.com grammysturn50.com grammyswebsite.com grammytocelebrate50.com grammytocelebrate50years.com grammytocelebrate50yrs.com grammyturns50.com grammytx.com grammyuniversitynetwork.com grammywdc.com grammyy.com greatvastforest.com greenvillelive.com gripsprogram.com groovemaker.net groovingtogether.net groundforceonelimo.net groundforceonetransportation.net growtastic.com grqammy.com grrammy.com grsammy.com grzammy.com grzmmy.com guaraniprod.com guaraniproductions.com guidedhemptour.com gunsatcost.net guntasyapi.com gurant.com gurbuzlerkuruyemis.com guvenhaber.net gymnastics-unlimited.com gypsysoulsailing.com hairthin.com halcombskennel.com halkinadresi.net haloparts.com handcarvedguitarstraps.com handfruit.net handpickedtrucks.net handpickedwesterntrucks.net harajukumobile.com harbimi.net harcoproperties.com hardinminor.com hdcameraman.com hdproducers.com hdroyaltyfree.com healthcareforms.net hearts-n-minds.com hejran.com helepolis.com helpfulgamble.com helpstudio.net henrygenry.com henrystogden.com hereinayear.com heritageautomotivesales.com hesterwernert.com hexol.net heywhatifitworks.com hicks-oil.com hirecheck.net hirechecks.net hitechinternships.net hockinghills.net holidayroad.com hollandmedical.net hollowayhouse.net hollywoodmodelmanagement.com hollywoodselecttalent.com holyland4u.net holylandtours.com homebizclubs.com homerobotics.net homerobots.net honeymoontripregistry.com hootersmusicschool.com hospederiadelvalle.com hospitalinc.net hospitallink.net hostkoyu.net hostracks.net hot-note.net hotel-harrington.com hotjeudecasino.com hotllamamedia.com hotllamaplayer.com hotspringstalk.com hufnagelcycles.com hugepaydayloan.com humanitarianaidtravel.com hunterautopartinc.com hurleyandassoc.com huxleybertram.com hzamora.com ibrahim-ay.com icallleads.net idahotbivpc.net idealmalimusavirlik.com idyllicspades.com ieatrox.com ificandream.com ifilmvideo.com iicit.com iisysz.com ik-inc.com ikmultimedia.net ilgiornaledelmolise.com illuseffects.com imcue.net imfaking.net immediatedeals.com immo-egypte.com immunizationtracking.net imnetwork.com imusicforum.com in-momentum.com incartech.net inclinc.com incorporatingservices.net incorporations.com incserv.net incserve.net indianapolisrunning.com indianlegislator.com indistream.net indyinthemove.com inebolupostasi.com infectedloser.com infiniti-me.com infiniticanada.com infinitiglobalcms-me.com infinitiglobalcms.com info-aw1.com info-awi1.com info-awi10.com info-awi11.com info-awi12.com info-awi13.com info-awi14.com info-awi15.com info-awi16.com info-awi17.com info-awi18.com info-awi19.com info-awi2.com info-awi20.com info-awi3.com info-awi4.com info-awi5.com info-awi6.com info-awi7.com info-awi8.com info-awi9.com inint.net inndestination.net innovasys.net instant-replays.net instantsdeals.com instaprospects.net instituto-ides.com insulationtools.net internationalsupplies.com intheholecs.net intimidatorparts.com investdelawarerealestate.com invisiblism.com invitecreditcheck.com iowabattleship.com ipcoltd.com iphonedialup.com iraqibrothers.net irc-atheism.com irc3.com irisbusiness.com irischat.com irisindia.com irisinfo.com irispersonal.com irisreport.com irisreports.com irisupdate.com iriswatch.com islamokyanusu.com islde.com islde.net isowl.com israel-free.net israelatid.net israelawards.net israelcamp.net israelcamps.net israelfree.net israelgreencorps.net israelnature.net israelnext.net israelservicecore.net israelservicecorp.net israelservicecorps.net israelsummercamp.net israelsummercamps.net israelsummerschool.net israelsummerschools.net israeluniversity.net israelvolunteercenter.net israelvolunteercentre.net istanbulgundem.net itavisen.com itemtomo.com itisjuegoscasino.com itmedicalinsure.com iwanttolearnto.net iwebplus.com iworknaked.net izmirsaglikrehberi.com jaloe.net jaltidore.com jamaicacruise.net jameseustace.com jawbreakerlures.com jawsevents.com jaygreenephoto.com jaykerrlaw.com jbgarc.com jbgphoto.com jbs-law.com jc-enterprises.net jcaudiogetafe.com jcc4u.net jccisrael.net jccjewishtravel.net jdginc.com jeremyroll.com jewellerybyminoo.com jewelrybyminoo.com jewishadventure.net jewishadventures.net jewishteentravel.net jfarm5.com jic2compact.com jimdgray.com jimdgrayassoc.com jlwpartners.com jobsol.net johnbergman.net johnhhurley.com jojoxo.com journeysofpaul.com jpjdevelopment.com jstechservices.com jubileerose.com juebosbros.com juegones.net juegostorrents.net justcardgame.com jvrstore.com k-marine.com k2resources.com k9rentals.com kahnscatering.com kahnsfinewine.com kahnsfinewines.com kahnskatering.com kalis-boutique.com kalisboutique.com kansasfarming.net kansasgaragesales.net kansasranching.net kansasspacefrontier.net kansasvisitor.net kansell.net kapow.com karacula.com karavanorganizasyon.com karetarim.com kasikcilar.com kasimaydin.com kaud.net kayahediyelik.com kaynakkirpik.com kbcpark.com kccomputek.com kclinux.net keithdmilby.com kemerlifehospital.com kemerliler.net kemeryasam.com kentconstructionco.net kentmayhew.com kernowanimals.com kerriganart.com keybridgeconsulting.net kibbutz4u.net kibutz4u.net kidcostumes.com kidsol.net kissedbags.com kisseduk.com kitchencabinets.net kiydesign.com klementagency.com klimapiano.com knappekoppie.com knightmania.com knightslimousine.net knightsofcaketown.com kohls-email1.com kohls-email10.com kohls-email2.com kohls-email3.com kohls-email4.com kohls-email5.com kohls-email6.com kohls-email7.com kohls-email8.com kohls-email9.com kohls-emails1.com kohls-emails10.com kohls-emails2.com kohls-emails3.com kohls-emails4.com kohls-emails5.com kohls-emails6.com kohls-emails7.com kohls-emails8.com kohls-emails9.com koytar.com krgv.com kristal-hotel.com krister.net kurukahveciahmet.com kuverainvestments.com kwcentraldelaware.com labetc.net laboratorioceranium.com labyrinthsinnc.com lacycles.com ladsnet.net lake-lure.com lakegastonconnect.com lakegastonnews.com landplusd.com larramotor.com larsenlegal.com larugbyacademy.com laserate.com latestruleta.com latingrammy.com latingrammyaward.com latingrammys.com latinrecordingacademy.com latte-mail.com laurenslimousine.net leadbingozone.com leadcredithistory.com leadexcite.net leadpokergratis.com leadsimpact.net leadsoncommand.net ledpoollight.com legacyllc.net legalcopilot.com legresources.com lendingtree-csi.com lesbian-photos.net letscampamerica.com letscampindiana.com leviguitarstraps.com liberalhaber.net libertoministorage.com licenseplatesplus.com licks-ass.com lightlivepoker.com linuxbiblesoftware.com linxup.net liquorstore-online.com listenfeelrespond.com listentodetails.net littletonobserveronline.net llcserv.net llcserve.net localcarsinsures.com localcraps.com lodgesattablerock.com logics.net lookatad.net lookatcredit.com loreleihunt.com lotromap.net louisesoloway.com lovescotch.com lowes-email1.com lowes-email10.com lowes-email11.com lowes-email13.com lowes-email14.com lowes-email15.com lowes-email16.com lowes-email17.com lowes-email18.com lowes-email19.com lowes-email2.com lowes-email20.com lowes-email21.com lowes-email22.com lowes-email23.com lowes-email24.com lowes-email25.com lowes-email3.com lowes-email4.com lowes-email5.com lowes-email6.com lowes-email7.com lowes-email8.com lowes-email9.com lowes-emails1.com lowes-emails2.com lowes-emails3.com lowes-emails4.com lowes-emails5.com ltrain12.com lucidproteomics.com lumbroso.com lunanetwork.com lyonbusinessbrokers.net m-placement.com mad-eye.com mahemare2000.com mahmutcan.net mahue.com mail-logic.net mailsubmission.com mainhealthplans.com mainpokergratis.com mainportals.net maintexaspoker.com makecashtraveling.com mannfred.com manusignota.net marconimicrocentro.com marifor.com marinelube.net marketingurdata.com marketworld.net marlindarrah.com marshas.net martincritchell-architects.com masha-ana.com masrf.net mastersinisrael.net matchlesscazino.com matteogastel.com maxcreditrating.com maximconstruction.net maxjeuxpoker.com maxkasinospel.com maxquickloans.com mccormick-group.com meadowgreenfarm.net meatdepressed.com mecawen.com medeqonline.com medicalassociations.net medicsoft.net medisuhastanesi.com megagiocarepoker.com mehmetislek.net meineke-emails1.com meineke-emails10.com meineke-emails11.com meineke-emails12.com meineke-emails13.com meineke-emails14.com meineke-emails15.com meineke-emails16.com meineke-emails17.com meineke-emails18.com meineke-emails19.com meineke-emails2.com meineke-emails20.com meineke-emails3.com meineke-emails4.com meineke-emails5.com meineke-emails6.com meineke-emails7.com meineke-emails8.com meineke-emails9.com mercadodelmueble.com merchandizer.com mergewithus.com mesothelioma-asbestos-lung-cancer-attorney.net mesothelioma-asbestos-lung-cancer-attorneys.net mesothelioma-asbestos-lung-cancer-lawsuits.net mesothelioma-claims-attorneys.net mesothelioma-law-attorneys.net mesothelioma-lawsuit-attorney.net mesothelioma-lawsuit-claims.net mesothelioma-lawyer-claims.net metrocharters.net metromatrix.net mhtleads.net miamidrivingschools.com michaeldavidhairsalon.net michaeldavidsalon.net mickeyssurplus.com midas-email1.com midas-email10.com midas-email11.com midas-email12.com midas-email13.com midas-email14.com midas-email15.com midas-email2.com midas-email3.com midas-email4.com midas-email5.com midas-email6.com midas-email7.com midas-email8.com midas-email9.com midas-emails1.com midas-emails10.com midas-emails11.com midas-emails12.com midas-emails13.com midas-emails14.com midas-emails15.com midas-emails2.com midas-emails3.com midas-emails4.com midas-emails5.com midas-emails6.com midas-emails7.com midas-emails8.com midas-emails9.com midcindia.com midwesthvacparts.com midwestlumination.net militarytapes.com millerscreek.net miltape.com miltapes.com milwaukeerigging.com minarecim.net missarkansasteenusa.com missgrace.com missgracecake.com missgracecakes.com missgracelemoncake.com missgracelemoncakes.com misshawaiiteenusa.com missionary.com missionreach.com missmaineteenusa.com missmontanateenusa.com missmontanausa.com missnevadateenusa.com missnevadausa.com missnewmexicoteenusa.com missnewmexicousa.com misspennsylvaniateen.com missteenuniverse.com missteenusa.com missuniverse.com missusa.com mixingspices.com mixmachine.net mizzouspirit.net mlmhelp.net mlsamericas.com mnlimo.net mobile-games4adults.com mobileforensics.com mobilehealthtechnologies.net mobilepms.com modelaircraft.com modelaircrafts.com modelairplane.com modelairplanes.com modernauthor.com mogeen.com molisevideo.com monarchgc.com moncheworld.com monchey.com mondo-digital.com monicajanea.com monkeyboy.com monsoonwife.com montaguefineart.com moonbayweb.net mooresvillerentalllc.com moredebtloans.com moredriveinsure.com mortgagesflorida.net mortgagesunlimited.net mosmuffin.com motoinformer.com motorite.net mountaineertown.net mountaineerzone.net movieblockbusters.com mpli.net mrsbeasley.com mrsbeasleys.com mrstinky.net mtcarmelcaravan.com muhendisbey.net multiplayfloor.com musicareonline.com musicares.com mwaheb-riyadiye.net my-site.com myagis.net myatso.com mycasinojuegos.com mydatapilot.com mydigitalfriends.com myetrainer.com myexpertlawyer.com myfriendstephanie.net mygrammy.com myimmunization.net myirisplus.com myiristv.com mykortspelpoker.com myleadbreeze.net myltccounselor.net mynewsmile.net myprivatelimo.net myrelocation.net mysitecafe.com mysticwitch.com mysticwitch.net mytekleads.net mzekiaktas.com n00bins.com n4th4nr1ch.com nancycarolwillis.net nansnames.com nationalcarehealth.com naturalife.com naturalniche.net naturemail.net natureswaycanada.com naughty-mobile.com nccng.net ncmountainland.com ncmtnwireless.com ncs-mfg.com nctraveler.com neatcasinoonline.com necessarygambling.com needanairticket.com needaurl.com needausedcar.com needsometoys.com needtogolf.com nekhethair.net netchecks.net netcreep.com netfastloan.com netscad.net netwebbingo.com network-offers.com nevadasuccess.com newarkexectran.net newconsumergoods.com newestdebtloans.com newissue.com newmeridia.com newvincerecasino.com nextodiusa.com ngi-fractional.com nicelydoneco.com nicelydonecompany.com nicevilleproperties.net nicevilleproperty.net nicevillerealestate.net nickogden.net nikon-email.com ninelzohrabi.com nisfilehosting.com nissan-thegtr.com nissancanada.com nissanneighbours.com njjustice.net nmcrym.com nmmconline.com nolimitholdemtexespoker.com northplex.net novelgambling.com novis-navitas.com novisnavi.com novisnavitas.com novusnavi.com nowlifeinsure.com nowpokergratuito.com npowermobile.net numericast.net nurshriners.com nwaypromos.com nygrammy.com nyupolyisrael.net oberammergau.com oberhandgallery.com offers-awi.com ofvisualinterest.com okayonlinecredit.com okfastloans.com okula-hayir.com okupaylas.net oldway.net omneyeh.com omni-employment-screening.com omniemploymentscreening.com omnihostingdns.com omzetbevordering.com onbasewithchase.com oncreditscore.com oneal7.com onebodybooks.com onegamble.com onespanolcasino.com oneworldfinancial-stl.net ongiocare.com ongiocarepoker.com onlydriveinsure.com onlyquickloan.com onpker.com onrefinancing.com ontargettraining.com onyargici.net oondi.com opleidingverkoop.com optionautoinsure.com orangecoastyachts.com oranimcanada.net oranimtravel.net orchardfruits.com orderbiotone.com orientalphotousa.com orjinalgutto.com oscar.com oscars.com otherautoinsure.com othercasinogioco.com otoklimacim.com ottysanchez.com ourregion.net outlooktraining.net oyunlaroynayalim.com ozcankafe.com ozdemirtelefon.com ozgursiirt.net p-ewing.com packsquareassoc.com packsquareassociates.com pahapaikka.com paintballparts.com paintballteams.net paintballtechs.net paintcheck.net pakenhamtom.com palmsbistrobar.com palmstreetinv.com palver.net pandewing.com paradisefishinglodge.net pariodesign.com pariomarketing.com pariopartners.com parkrowbooks.com parrotheadadventurecruises.com partnerdns.net partyindiana.com partyroundupsupport.com passion-play.com pathwaysnc.net pats-creations.com patstaub.com payperclickmaestro.com pcxeon.com pcxeonconsolas.com pcxeonmercadillo.com pcxeontaller.com peaceandbeans.com peermetrx.com pegasuslimo.net penis-buyut.com penisbuyutmetr.com penisibuyut.com pepogest.com perfectholidaymeal.com perfectholidaymeals.com perfecthomebusiness.net perfectjeuxpoker.com performertrack.com permanentbingo.com permission-awi.com personalinjurycopilot.com personneltesting.net peruhack.net perukaliente.com pescoenergy.net petpublish.com petriumpetshop.com petrochemtransport.com petsol.net peygamberim.net phip.com physicianassociations.net physiciancredentialing.net physicianlicensing.net pier23cafe.com piercepece.com pinokyotr.com pirateheadadventures.com pirateheadcruises.com pirateheadsailing.com pivotalvc.com pixandtunes.com pjur-superhero.com plexit.net plusbonmarche.com plushsurvival.com pms-online.net pmsonline.net pnewing.com pnmg.net pocketpms.com poconowhitewater.net polytarps.net ponunaxentuagenda.com ponyexpressuk.com poopycow.com popularcazino.com pornosbig.com portalemula.com portalinet.com posadavaloria.com powellandpartnerscreative.com poyrazgida.net pppoker.net pre-paid-gifts.com premier-collections.net prepaid-gifts.com prestigetravelnc.com pridehospitality.net primadophilus.com primefocus-inc.com primekasinoslot.com primepokerseite.com princesscouture.com priveskincare.net producersandengineers.com productsthatwork.net professionallearningtree.com profitpointadvisors.com promo-awi1.com promo-awi10.com promo-awi11.com promo-awi12.com promo-awi13.com promo-awi14.com promo-awi16.com promo-awi17.com promo-awi18.com promo-awi19.com promo-awi2.com promo-awi20.com promo-awi3.com promo-awi4.com promo-awi5.com promo-awi6.com promo-awi7.com promo-awi8.com promo-awi9.com promotions-awi.com promptcraps.com properhomeloans.com properslots.com provaxac.net pshs1988.com pshsclassof88.com psoriaflora.com pspersonnel.com ptkcom.com ptmglobal.com pubbliservice.com purewhitepoollight.com purplebook.com pvmc.net q1limousine.com qloab.com quality1limo.com quarterlytrialsreview.com qubixcart.com quickhouseinsure.com quickspelapoker.com radioaudiodelta.com radiolunanetwork.com raisehealthinsure.com rakeshmohan.com ramseycoastguard.com randrcommercialrealty.com rangeisp.net rappcova.net rayan-group.com razor-line.com rbl-monitor.com realestateasheville.com realestateweekly.com realestatewnc.com realityfakes.com recordingartistscoalition.com redhatterlady.com redhotartspot.com redlinelogistics.com reformation-lutheran.net reformationtour.com reformationtravel.com reggaebiz.net reggaesunsplashja.net relaxtheback.com relaxthebackfranchise.com relaytechnology.net relocity.net reloplex.net reloselect.net reloshop.net relosight.net relosite.net remaxavenues.net remcogeerdink.com remembrancebeads.com remindum.net renegeerdink.com rentholidayvilla.com replaymessagecentre.com research2gether.com reseauexpansion.com resetdietplan.com resetshake.com residencialcervantes.com residenciavillamayor.com restaurantzina.com retainingwallsolutions.net rethinkingschools.net retiring-in-panama.com retiring-to-panama.com reuniontravelregistry.com rhcoc.com rhinoprospects.net rich-smith.net richardapizzuti.com rightjeuxdecasino.com ristechinc.net ritualsalon.net riverplex.net rmslink.net robeband.com robinsonandcook.com roflronjon.net roland-pianos.com rongxulong.com rttracking.com rubthelamp.com rukosinc.com rulercazino.com ruralghetto.net rxhr.net sababatime.net saddleridge.com safeguard-biosystems.net safeguardbiosystems.net sahvet.com saigontoday.net sailestrella.com sailmadeline.com saintmd.com sales-awi1.com sales-awi10.com sales-awi11.com sales-awi12.com sales-awi13.com sales-awi14.com sales-awi15.com sales-awi16.com sales-awi17.com sales-awi18.com sales-awi19.com sales-awi2.com sales-awi20.com sales-awi3.com sales-awi4.com sales-awi5.com sales-awi6.com sales-awi7.com sales-awi8.com sales-awi9.com salonaydin.net salsashoe.com samplesgirl.com samsapp.net samscottschiavo.com sandsunfun.net sanyobatteries.com sanyobattery.com sanyobiomedical.com sanyocanada.com sanyocellculture.com sanyocommercialsolutions.com sanyoctv.com sanyoeducation.com sanyoenergy.com sanyofoodsolutions.com sanyohdproseries.com sanyohvac.com sanyologistics.com sanyomassagechairs.com sanyopanfocus.com sanyoprojectors.com sanyosemi.com sanyosemiconductor.com sanyousa.com sanyovideopilot.com sarahshaoul.com sarayhan.net saripapatya.net saucy-mobile.com saxorama.com schoolcrimereports.com schoolnite.net schpiel.com scjinc.net script-u-free.com sea-cruise.com seacoastmotors.net seamlesstech.com seeds-awi1.com seeds-awi2.com selectinsurelife.com selvinwraith.com semflex.com seminary.net senatordeluca.com seotestimonials.com seriouscredits.com seriousslots.com servamp.com serveramp.com serveramplifier.com serverbutler.net servetalk.net servicedataonline.com seweepreserve.net sex-drives.net sexshopfantazi.com sfsend.com sgiocaapoker.com shainakins.com shalomoranim.net sheboygan.net shiftthewayyoumove.com shiningperformancearts.com shopjustpink.com short-rib.com shotgla55.com shoutees.com showusyourx.com sia380.com sighra.com siirbahcesi.com sikovanberkel.com silkrosepetals.net simonized.net simpleinsurelife.com simplemedia.net singaporeairlinesholidays.com singaporeairlinesvacations.com singaporeairpass.com singularcity.com sioba.com sirtlanlarvadisi.net sirtlanvadisi.net sistersinthewind.com sivil.net siyasigundem.com skylinechennai.net slamrated.com smart-gadgets.net smartfile.com smartfilemail.com smartgadgets.net smarthouses.net smartlumen.com smokeymountainbottledwater.com smyrnadelaware.net smyrnapolice.com snapcost.com snow-bound.com snowvice.com soffmtr.com softmovil.net softpave.com solheim-tickets.com sos-europe.net soscredits.net soseurope.net soundsmusic.com southamericaway.net southernthing.com southpacifictours.com southwestrelocation.net soxgen.com soygrower.net soygrowers.net spartanburglive.com spartanburgsc.com spasupplydepot.com spasupplyunlimited.com specialroulette.com speedeeweevers.com sperryville.net spillrated.com spnwonline.com spokengrammy.com spookyfishtank.com spoonsandspice.net sportmentv.com sportsfly.com sportsmediaguide.net springbreakeilat.net springbreakisrael.net springbreaktelaviv.net spruitstuk.com sqtravelpartners.com sqvacations.com srspackaging.com staffnet.net staffnetworks.net staffsunirugby.net stallcrawl.com stellar-dazzler.com stellardazzler.com stellarphotonics.com sterisonic.com stevepolifka.com stickandstay.net stingstopgel.com stl-carpenterbenefits.net stl-carpenters.net stlhomepage.net stlouishomepage.net stlouisjobs.net stlouispage.net stlpage.net stltec.net stltechnology.net stopbabiesandpuppies.com store-logic.net stpaulsucc.com stratosinternational.com stratosintl.com strattonscafe.net striishii.com stritamustangs.com studio411.com sucks-balls.com sufidreams.com summercampinisrael.net summercampsinisrael.net suncatcherz.com sundayhappyhour.com sungminship.com sunrisemount.net sunsetsailor.com supercollege.net superdriveinsure.com superiorcustomhomes.com superiorhomedirect.com superiorhomesdirect.com superipeople.com superwebpoker.com surfacechemistrynews.com surfpc.net surfsidetransportation.net susannilsson.com sushicatering.net sussextechtraining.net sussing.com susteen.com suzybailey.com suzyhazel.com swheatbarley.net swheatgrass.net swiftlimousine.net syn-tec.net ta11-telia.com taksimcinaralti.com talyabitkisel.com talyag.com tangent-international.com taperoff.net tarpandcoversuperstore.com tasarimyarat.com tatshingchemicals.com tattoomafia.net taxesprof.com tbwachiatdev.com tbwachiatqa.com tbwachiatstaging.com tcbcourier.com tdtffc.com teachers2israel.net teachingholocaust.net teamsafe-t.com teamsafet.com teensol.net teknomarketin.net tenantscreeningfranchise.com tennesseeaging.net terrorbox.com teselli.net test-technology.com teydeseo.com tgsarchs.com the-corporate-insider.com thearubaopen.com theashevillemall.com thebeatlessource.com theblakelys.net thecasinojeux.com thecoverworld.com thecrapsauthority.com thefamousgroup.com thegrandmanor.net thegunsource.net thehotelcommonwealth.com thehouseofinfiniti.com thehubguide.com theindianlegislator.com thejenniferbrand.com thelloydmorganrevivals.com thelodgesattablerock.com themiglioricasino.com themilbys.com thenewberrys.com thenewnissangtr.com thenissangt-r.com theonlinegiochi.com thepaconnection.net thepokor.com thepurplebook.net thequigleys.net theredneckinvestor.com theregsite.com theresetplan.com theroadshows.com theshoppingcompany.net thetrailsedge.com thevanderbiltgroup.net thewallstreetredneck.com theweddingboutique.net thinkoutdoor.com thinkwithoutboundaries.com thisilyn.com thisistexasholdem.com thomascarlsson.com threeon.com thrillclick.com thrillpage.com thudrumblegallery.com tifac.com timby.com tiochs.net tippmanparts.com tirweb.com tlc-ambulance.net tmaclive.com tmpf.net tnc-ltd.com tobigfive.net togetherclothing.com togethergallery.com tokgozoto.com tomdeanco.com toothology.net top-dek.com top-picks.net top10inns.net topcreditinfo.com topcyclingshoes.com toppmarketing.com toppoke.com toppokergratis.com toproulettespel.com tosa-wi.com total-mortgageinc.com totalcats.com totalcraps.com totallyokay.com tour-asia.com tour-china.com tours4schools.net toursforschools.net toursfourschools.net toysol.net tpbookstore.com tqnye.com trackcocaine.com traficosoft.com trailersdirectonline.net traklix.com transecoenergy.com trashtalkfcm.com travel4teens.net travelbase.net traveldealseveryday.com traveldiscountemail.com traveldiscountemails.com travelnc.com traveltheworld.com traviscalhoundds.com treiba.com trexserver.net trialsreviewonline.com trifloragel.com trina.net triumphcarehealth.com trompeter.com troop443.net trueservicedata.com ttaee.net ttslimo.net tufotoenoro.com tunersandmodels.com turizmbulvari.com turizmbulvari365.com turkerticaret.com turmwirt.com turnerceramictile.com tuspornostv.com twilight3d.com txvision.com tyhs.net typicalcreditcard.com uccserv.net uccserve.net uforix.com ukarticle.com ukpiano.com ulk.net ultima-cs.net ultratektel.com unionwholesale.net uniquelimousinetransportation.net universalkasino.com unleashyourequity.com untestesisat.com upango.com upangohealth.com upright-piano.com uptowntheatre.net usahotoffers.com usedcarvalue.net ushotoffers.com uskamimarlik.com uskasera.com uspatentexchange.net uspokergratis.com usualhealthcare.com usualloanscash.com usualpokerbetting.com usualwagers.com utr.net uwars.net uwco.net vacationtravelregistry.com validcarinsure.com validcashloans.com validcreditcheck.com valuablebets.com valvinalliance.com vancebrawley.com vanderbiltconsulting.net vault5.net vcentre.net vehicledonation.net vehicledonationcharity.net venatrack.com vendorscreening.net verkoopcoaching.com vgrammy.com viabusiness.net viadrugstore.net viaexchange.com viaflower.net viaflowers.net viamoneytransfer.net viamortgage.net viarealestate.net viashopping.net vibescity.net videodiscord.com videojourney.com videonya.com videostockshots.com videotikla.com vidigreet.com vigalanty.com vigalantyinternational.com vineandtable.com vintageguns.net vipcazino.com vipmoneyloan.com vipreinsurance.com virgingrammys.com virtualcampuses.net vision-centre.net visit-sc.com visitaz.com visitbibleland.com visitca.com visitco.com visitfla.com visitga.com visithi.com visitholyland.com visitmn.com visitms.com visitnm.com visitnv.com visitny.com visitorreview.com visitsc.com visitsites.com visittn.com visittx.com visitut.com visitva.com vitaminsfordiabetes.net vitzi.com vivagreen.com vividlocations.com vmgnc.com volleyballplano.com voyagedvd.com vservercenter.net vvvkin.net walkerhousewi.com walkonblogger.com wallstreetredneck.com wantam.com wantem.com wantgiocaapoker.com wanthomeinsurance.com wantum.com wapxml.net watchclevelandshowonline.net watchdbzonline.com watchhdporn.net watchsavers.com watereehomeowners.net weareborg.net webcardz.com webdreamland.com webervations.net webjacket.net websiterange.com webtamir.net webtasarimhizmeti.com webvoice.com weightchannel.net wereallfans.com westernblowpipe.net westerninspections.com westgatebridge.com what-is.net whatireallyneed.com whatshouldiget.com whatsthedownload.com whatsthedownloadblog.com whatsyourstatus.net wheeliesport.net wheelockhomeschool.net wheelocks.net whistle-blower-alert.com whistle-blower-hotline.com whistlebloweralert.com whitewaterrecording.com whitwellessays.com wholecraps.com wholesale-criminal-data.com wholesalecriminaldata.com whuffiemeter.com whuffierank.com wichitabusiness.net wickedcode.com wikizero.com wilcox-tour-host.com wilcox-travel.com wilcoxcam.com wilcoxcamera.com wilcoxescortedtour.com wilcoxescortedtours.com wilcoxhostedtour.com wilcoxhostedtours.com wilcoxicecream.com wilcoxincentives.com wilcoxmeetings.com wilcoxmeetingservice.com wilcoxmeetingservices.com wilcoxtourhost.com wilcoxtraveldeals.com wilcoxtravelmail.com wilcoxtravelmall.com wilcoxvacations.com wildquail.net williamdunlap.com windowsbiblesoftware.com winedows.com wirelessasheville.com wittschenck.com wittybingo.com wmpd.net wnccrafts.com women2israel.net womenol.net wordburp.com worldmetanews.net worldofhomeloans.com worldportals.net worldrating.net worldwidecolleges.net worldwidecraps.com worthkasinos.com wowcasinogioco.com wpdparts.com wrightpetroleum.com wskfarch.com wvutown.net wvuzone.net wyliespasupply.com xaliber.com xixnet.net xm303.com xn--bykbee-3yab80g.net xn--grtnerei-baum-bfb.com xtremeprospects.net xxx-mobile.com yaaaar.com yabedo.com yala3arb.com yalanas.com yalla3arb.com yaloe.net yankihaber.com yapraklarinsaat.com yasarartglass.com yasarartglasscenter.com yazlikkoyu52.com yconcept.net yenisystem.net yilmazhali.net yilmazkaracula.com yinedebiz.net yongazetesi.com youfoundmark.com yourbusinessmatters.net yourcapitalrealtor.net yourdelaware.net yourholdem.com yourpokerenlinea.com yourpoquer.com yourscarinsure.com yoursdebitcard.com yoursonlineloans.com youthol.net yurtdisilisansegitimi.com zamoragroup.com zayifliyalim.com zcalling.net zdaa385.com zenterrafloor.com zildjian.com zildjian385.com zildjianbangedontour.com zildjianplayedontour.com zildjianshop.com zildjianstore.com zildjianwornontour.com zirvekoxp.com zoek-win.com zprospects.net zuckerconsulting.com zzzzzzzzzzzzzzzzzzzzzzzzzzzzz.com From jgreco at ns.sol.net Fri Jan 8 10:48:03 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 8 Jan 2010 10:48:03 -0600 (CST) Subject: I don't need no stinking firewall! In-Reply-To: <4B473178.7010100@kruchas.com> from "bill from home" at Jan 08, 2010 08:22:00 AM Message-ID: <201001081648.o08Gm3WR069536@aurora.sol.net> > All, > This thread certainly has been educational, and has changed my > perception of what an appropriate outward facing architecture should be. > But seldom do I have the luxury of designing this from scratch, and also > the networks I administer are "small business's". > My question is at what size connection does a state table become > vulnerable, are we talking 1mb dsl's with a soho firewall? > Or as I suspect we are talking about a larger scale? > I know there are variables, I am just looking for a "rule of thumb". > I would not want to recommend a change if it is not warranted. > But when fatter and fatter pipes become available at what point would a > change be warranted. For small pipes, a simple DoS is trivial enough to jam up the works without worrying about the state table size. However, that doesn't mean it isn't smart to get a handle on it. The biggest question may be pipe size: this variable controls the total possible PPS that can be tossed at the firewall. If you consider a technology such as 10base-T Ethernet, that's 10 megabits per second. When you add up the IFG, MAC preamble, dest/src, MAC type, payload, and CRC, the smallest Ethernet frame is 84 bytes. 10M/(84*8) = 14880 frames per second. Now let's say you want to block a SYN flood from hitting your server (nobody need tell me that there are obvious problems with this; this is an educational exercise). If your firewall is configured to expire state table entries for partially opened connections after 15 seconds, the speed of ethernet combined with the 15 seconds means you need a table that's 225,000 entries large. But wait. If they're blowing 14880 frames per second at you, that Ethernet's quite full. You're already getting DoS'ed by capacity. Further, what happens when the attack moves to simply fully opening connections? Your state table is tiny for that... I know this is NANOG, and it's network-centric. However, fundamentally, a stateful firewall fuzzes the boundary between network and server. It is taking on some duties that have typically been the responsibility of the server. So I'm going to go off on a tangent and say that it may be useful to consider the state of the art in server technology. A good UNIX implementation (OpenBSD, FreeBSD, maybe Linux ;-) ) will be hardened and further-hardenable against these sorts of attacks. The server *already* has to do things such as tracking SYN's, except that they no longer have to - they can issue cookies back and then simply forget about it. If the cookie is returned in the ACK, then a connection is established. A proper implementation of this means that a server using SYN cookies has an infinitely large SYN queue; packets on the network itself are actually the queue. The technique works and scales at 1Mbps as well as it does at 10Gbps. Putting a stateful firewall in front of that would be dumb; the server is completely capable of coping with the superfluous SYN's in a much more competent manner than the firewall. I won't go into this in more detail. You can look to see what the IRC networks are doing to protect themselves. They're commonly beat up and have learned most of the best defense tricks around. A stateless firewall that can implement filtering policies in silicon is absolutely a fantastic thing to have, especially when faced with a DoS for which you can write rules. Put your servers behind one heck of a good stateless firewall, and run a well-tuned OS. You'll be a lot more DoS-resistant. ... 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 jbates at brightok.net Fri Jan 8 12:28:19 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 08 Jan 2010 12:28:19 -0600 Subject: qwest outage no notice In-Reply-To: <20100107165022.A742946@resin18.mta.everyone.net> References: <20100107165022.A742946@resin18.mta.everyone.net> Message-ID: <4B477943.90606@brightok.net> Scott Weeks wrote: > > Try no notice at all and 4 GigEs of upstream bandwidth down at 1:30am. :-( Honestly, I feel for them. They probably left it up to the account reps, which means the smaller circuits probably got notified and the HUGE wholesale accounts were not. Oh, well. That's why we have redundancy. ;) Jack From cscora at apnic.net Fri Jan 8 12:43:43 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Jan 2010 04:43:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201001081843.o08Ihhao021615@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 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 307662 Prefixes after maximum aggregation: 143300 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 151565 Total ASes present in the Internet Routing Table: 33037 Prefixes per ASN: 9.31 Origin-only ASes present in the Internet Routing Table: 28698 Origin ASes announcing only one prefix: 14013 Transit ASes present in the Internet Routing Table: 4339 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN ( 9503) 20 Prefixes from unregistered ASNs in the Routing Table: 731 Unregistered ASNs in the Routing Table: 133 Number of 32-bit ASNs allocated by the RIRs: 385 Prefixes from 32-bit ASNs in the Routing Table: 335 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 186 Number of addresses announced to Internet: 2169545344 Equivalent to 129 /8s, 80 /16s and 162 /24s Percentage of available address space announced: 58.5 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.7 Total number of prefixes smaller than registry allocations: 148143 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 73972 Total APNIC prefixes after maximum aggregation: 25793 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 70662 Unique aggregates announced from the APNIC address blocks: 31402 APNIC Region origin ASes present in the Internet Routing Table: 3913 APNIC Prefixes per ASN: 18.06 APNIC Region origin ASes announcing only one prefix: 1071 APNIC Region transit ASes present in the Internet Routing Table: 612 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 22 Number of APNIC addresses announced to Internet: 486803488 Equivalent to 29 /8s, 4 /16s and 8 /24s Percentage of available APNIC address space announced: 80.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/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, 133/8, 175/8, 180/8, 182/8, 183/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: 129255 Total ARIN prefixes after maximum aggregation: 67559 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103380 Unique aggregates announced from the ARIN address blocks: 39158 ARIN Region origin ASes present in the Internet Routing Table: 13428 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5201 ARIN Region transit ASes present in the Internet Routing Table: 1323 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 735019296 Equivalent to 43 /8s, 207 /16s and 129 /24s Percentage of available ARIN address space announced: 64.4 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 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 70912 Total RIPE prefixes after maximum aggregation: 41459 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 64240 Unique aggregates announced from the RIPE address blocks: 42763 RIPE Region origin ASes present in the Internet Routing Table: 13948 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7257 RIPE Region transit ASes present in the Internet Routing Table: 2088 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 20 Number of RIPE addresses announced to Internet: 409561344 Equivalent to 24 /8s, 105 /16s and 105 /24s Percentage of available RIPE address space announced: 76.3 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 26966 Total LACNIC prefixes after maximum aggregation: 6530 LACNIC Deaggregation factor: 4.13 Prefixes being announced from the LACNIC address blocks: 25329 Unique aggregates announced from the LACNIC address blocks: 13780 LACNIC Region origin ASes present in the Internet Routing Table: 1225 LACNIC Prefixes per ASN: 20.68 LACNIC Region origin ASes announcing only one prefix: 391 LACNIC Region transit ASes present in the Internet Routing Table: 204 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 69899712 Equivalent to 4 /8s, 42 /16s and 149 /24s Percentage of available LACNIC address space announced: 69.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 5994 Total AfriNIC prefixes after maximum aggregation: 1610 AfriNIC Deaggregation factor: 3.72 Prefixes being announced from the AfriNIC address blocks: 4375 Unique aggregates announced from the AfriNIC address blocks: 1592 AfriNIC Region origin ASes present in the Internet Routing Table: 337 AfriNIC Prefixes per ASN: 12.98 AfriNIC Region origin ASes announcing only one prefix: 93 AfriNIC Region transit ASes present in the Internet Routing Table: 69 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC addresses announced to Internet: 14742016 Equivalent to 0 /8s, 224 /16s and 242 /24s Percentage of available AfriNIC address space announced: 43.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1831 7509 473 Korea Telecom (KIX) 17488 1464 144 140 Hathway IP Over Cable Interne 4755 1281 289 144 TATA Communications formerly 18101 1033 220 38 Reliance Infocom Ltd Internet 4134 1018 19477 400 CHINANET-BACKBONE 9583 998 74 503 Sify Limited 7545 920 198 98 TPG Internet Pty Ltd 17974 844 271 55 PT TELEKOMUNIKASI INDONESIA 4808 836 1583 213 CNCGROUP IP network: China169 9829 835 679 22 BSNL National Internet Backbo 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 4165 3891 301 bellsouth.net, inc. 4323 3783 1068 400 Time Warner Telecom 1785 1796 699 134 PaeTec Communications, Inc. 7018 1589 5791 1028 AT&T WorldNet Services 20115 1537 1487 666 Charter Communications 2386 1294 617 930 AT&T Data Communications Serv 3356 1200 10929 423 Level 3 Communications, LLC 11492 1154 222 14 Cable One 22773 1124 2600 66 Cox Communications, Inc. 6478 1092 241 298 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 30890 516 98 206 Evolva Telecom 35805 466 40 5 United Telecom of Georgia 3292 448 1903 393 TDC Tele Danmark 9198 426 202 13 Kazakhtelecom Data Network Ad 702 419 1837 337 UUNET - Commercial IP service 8551 396 353 37 Bezeq International 8866 374 110 23 Bulgarian Telecommunication C 3320 361 7068 307 Deutsche Telekom AG 3301 352 1412 307 TeliaNet Sweden 3215 350 3168 107 France Telecom Transpac 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 1576 2899 232 UniNet S.A. de C.V. 10620 1004 224 130 TVCABLE BOGOTA 28573 832 674 85 NET Servicos de Comunicao S.A 7303 668 352 98 Telecom Argentina Stet-France 22047 546 302 14 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 6503 446 163 185 AVANTEL, S.A. 11172 444 99 69 Servicios Alestra S.A de C.V 14117 436 29 11 Telefonica del Sur S.A. 3816 431 193 69 Empresa Nacional de Telecomun 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 8452 1017 444 8 TEDATA 24863 719 143 53 LINKdotNET AS number 3741 273 857 233 The Internet Solution 2018 178 196 100 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 161 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 121 8 18 Internet Egypt Network 5713 114 505 68 Telkom SA Ltd 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 4165 3891 301 bellsouth.net, inc. 4323 3783 1068 400 Time Warner Telecom 4766 1831 7509 473 Korea Telecom (KIX) 1785 1796 699 134 PaeTec Communications, Inc. 7018 1589 5791 1028 AT&T WorldNet Services 8151 1576 2899 232 UniNet S.A. de C.V. 20115 1537 1487 666 Charter Communications 17488 1464 144 140 Hathway IP Over Cable Interne 2386 1294 617 930 AT&T Data Communications Serv 4755 1281 289 144 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3783 3383 Time Warner Telecom 1785 1796 1662 PaeTec Communications, Inc. 4766 1831 1358 Korea Telecom (KIX) 8151 1576 1344 UniNet S.A. de C.V. 17488 1464 1324 Hathway IP Over Cable Interne 11492 1154 1140 Cable One 4755 1281 1137 TATA Communications formerly 22773 1124 1058 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1017 1009 TEDATA 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 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.78.60.0/22 6762 Telecom Italia international 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 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:21 /9:10 /10:25 /11:65 /12:181 /13:382 /14:654 /15:1233 /16:10850 /17:5053 /18:8622 /19:17725 /20:21661 /21:21549 /22:27892 /23:28054 /24:160791 /25:915 /26:1147 /27:584 /28:221 /29:11 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2723 4165 bellsouth.net, inc. 4323 2369 3783 Time Warner Telecom 4766 1476 1831 Korea Telecom (KIX) 1785 1263 1796 PaeTec Communications, Inc. 17488 1230 1464 Hathway IP Over Cable Interne 11492 1074 1154 Cable One 18566 1040 1059 Covad Communications 7018 960 1589 AT&T WorldNet Services 8452 913 1017 TEDATA 18101 913 1033 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:242 12:2007 13:9 15:22 16:3 17:8 20:38 24:1301 32:49 38:635 40:99 41:1881 44:3 46:1 47:29 52:6 55:2 56:2 57:23 58:640 59:596 60:446 61:968 62:956 63:2005 64:3774 65:2358 66:4100 67:1841 68:1047 69:2832 70:688 71:231 72:1878 73:3 74:2075 75:225 76:359 77:871 78:604 79:406 80:961 81:803 82:469 83:440 84:521 85:1015 86:376 87:692 88:433 89:1561 90:65 91:2674 92:434 93:1151 94:1293 95:799 96:194 97:290 98:488 99:23 109:206 110:263 111:413 112:168 113:216 114:304 115:404 116:1126 117:596 118:380 119:812 120:141 121:684 122:1385 123:830 124:1029 125:1305 128:198 129:203 130:134 131:461 132:84 133:16 134:193 135:41 136:228 137:175 138:236 139:81 140:462 141:121 142:377 143:349 144:393 145:51 146:390 147:175 148:565 149:196 150:151 151:172 152:225 153:162 154:2 155:270 156:178 157:329 158:98 159:355 160:304 161:175 162:271 163:189 164:309 165:472 166:493 167:387 168:758 169:158 170:568 171:42 172:1 173:425 174:519 175:20 180:273 183:200 184:3 186:258 187:211 188:1138 189:615 190:3423 192:5722 193:4390 194:3352 195:2786 196:1192 198:3550 199:3390 200:5256 201:1450 202:8076 203:8300 204:3981 205:2167 206:2401 207:3042 208:3924 209:3394 210:2518 211:1170 212:1657 213:1650 214:248 215:58 216:4425 217:1390 218:481 219:416 220:1137 221:461 222:303 End of report From owen at delong.com Fri Jan 8 13:22:04 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jan 2010 11:22:04 -0800 Subject: New SPAM DOS Message-ID: At least this is new for me... I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: > Dear user of the scvrs.org mailing service! > > We are informing you that because of the security upgrade of the mailing > service your mailbox (x) settings were changed. In order to > apply the new set of settings click on the following link: > > http://scvrs.org/owa/service_directory/settings.php?email=x&from= > scvrs.org&fromname=wa2ibm > > Best regards, scvrs.org Technical Support. An now I'm having to clean up various blacklistings thinking that my server is a spamvertised web site. Anyone seen this before? Any good techniques for combatting it? Owen From sronan at fattoc.com Fri Jan 8 13:34:05 2010 From: sronan at fattoc.com (Shane Ronan) Date: Fri, 8 Jan 2010 14:34:05 -0500 Subject: New SPAM DOS In-Reply-To: References: Message-ID: I recently started receiving these as well for my domain. Would appreciate anyone's input on what the deal is. On Jan 8, 2010, at 2:22 PM, Owen DeLong wrote: > At least this is new for me... > > I host scvrs.org on one of my servers, and, it does not have any outlook or owa > services. For some reason, someone decided to try and send this message > out to various internet recipients: > >> Dear user of the scvrs.org mailing service! >> >> We are informing you that because of the security upgrade of the mailing >> service your mailbox (x) settings were changed. In order to >> apply the new set of settings click on the following link: >> >> http://scvrs.org/owa/service_directory/settings.php?email=x&from= >> scvrs.org&fromname=wa2ibm >> >> Best regards, scvrs.org Technical Support. > > An now I'm having to clean up various blacklistings thinking that my server is > a spamvertised web site. > > Anyone seen this before? Any good techniques for combatting it? > > Owen > From sthaug at nethelp.no Fri Jan 8 13:39:54 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 08 Jan 2010 20:39:54 +0100 (CET) Subject: New SPAM DOS In-Reply-To: References: Message-ID: <20100108.203954.85380276.sthaug@nethelp.no> > I host scvrs.org on one of my servers, and, it does not have any outlook or owa > services. For some reason, someone decided to try and send this message > out to various internet recipients: ... > Anyone seen this before? Any good techniques for combatting it? If you look more closely at the messages I believe you'll find that they are multipart/alternative, and that the second part gives a slightly modified version of the owa URL. For instance, for my own nethelp.no domain the first part of message says http://nethelp.no/owa/... but the second part specifies URLs like http://nethelp.no.ujjikx.co.im/owa/... http://nethelp.no.ujjiks.net.im/owa/... http://nethelp.no.ikuu8w.com/owa/... http://nethelp.no.ikuu8e.net/owa/... This is a very old trick, seen lots of times in connection with phishing sites, for instance. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bpfankuch at cpgreeley.com Fri Jan 8 13:41:07 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Fri, 8 Jan 2010 12:41:07 -0700 Subject: New SPAM DOS In-Reply-To: References: Message-ID: <01759D50DC387C45A018FE1817CE27D757899A9DEA@CPExchange1.cpgreeley.com> I too have been receiving these to my spamtrap domain... again any ideas to combat this would be helpful. -----Original Message----- From: Shane Ronan [mailto:sronan at fattoc.com] Sent: Friday, January 08, 2010 12:34 PM To: Owen DeLong Cc: Nanog list Subject: Re: New SPAM DOS I recently started receiving these as well for my domain. Would appreciate anyone's input on what the deal is. On Jan 8, 2010, at 2:22 PM, Owen DeLong wrote: > At least this is new for me... > > I host scvrs.org on one of my servers, and, it does not have any > outlook or owa services. For some reason, someone decided to try and > send this message out to various internet recipients: > >> Dear user of the scvrs.org mailing service! >> >> We are informing you that because of the security upgrade of the >> mailing service your mailbox (x) settings were changed. In order to >> apply the new set of settings click on the following link: >> >> http://scvrs.org/owa/service_directory/settings.php?email=x&from= >> scvrs.org&fromname=wa2ibm >> >> Best regards, scvrs.org Technical Support. > > An now I'm having to clean up various blacklistings thinking that my > server is a spamvertised web site. > > Anyone seen this before? Any good techniques for combatting it? > > Owen > From aaron at wholesaleinternet.net Fri Jan 8 13:42:00 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 8 Jan 2010 13:42:00 -0600 Subject: New SPAM DOS In-Reply-To: References: Message-ID: <10f501ca909a$a50bae90$ef230bb0$@net> Yep. I've been receiving them from several of my domains for a couple weeks. I've been sending the normal complaints to the provider of the IP space in the header but other than that I have no good ideas about combating it. Aaron -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, January 08, 2010 1:22 PM To: Nanog list Subject: New SPAM DOS At least this is new for me... I host scvrs.org on one of my servers, and, it does not have any outlook or owa services. For some reason, someone decided to try and send this message out to various internet recipients: > Dear user of the scvrs.org mailing service! > > We are informing you that because of the security upgrade of the mailing > service your mailbox (x) settings were changed. In order to > apply the new set of settings click on the following link: > > http://scvrs.org/owa/service_directory/settings.php?email=x&from= > scvrs.org&fromname=wa2ibm > > Best regards, scvrs.org Technical Support. An now I'm having to clean up various blacklistings thinking that my server is a spamvertised web site. Anyone seen this before? Any good techniques for combatting it? Owen No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.725 / Virus Database: 270.14.123/2592 - Release Date: 01/08/10 01:35:00 From john-nanog at johnpeach.com Fri Jan 8 13:47:28 2010 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 8 Jan 2010 14:47:28 -0500 Subject: New SPAM DOS In-Reply-To: <01759D50DC387C45A018FE1817CE27D757899A9DEA@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D757899A9DEA@CPExchange1.cpgreeley.com> Message-ID: <20100108144728.5074bde4@jpeach-desktop.anbg.mssm.edu> It's a phishing scam: http://isc.sans.org/diary.html?storyid=7918&rss On Fri, 8 Jan 2010 12:41:07 -0700 Blake Pfankuch wrote: > I too have been receiving these to my spamtrap domain... again any > ideas to combat this would be helpful. > > -----Original Message----- > From: Shane Ronan [mailto:sronan at fattoc.com] > Sent: Friday, January 08, 2010 12:34 PM > To: Owen DeLong > Cc: Nanog list > Subject: Re: New SPAM DOS > > I recently started receiving these as well for my domain. > > Would appreciate anyone's input on what the deal is. > > On Jan 8, 2010, at 2:22 PM, Owen DeLong wrote: > > > At least this is new for me... > > > > I host scvrs.org on one of my servers, and, it does not have any > > outlook or owa services. For some reason, someone decided to try > > and send this message out to various internet recipients: > > > >> Dear user of the scvrs.org mailing service! > >> > >> We are informing you that because of the security upgrade of the > >> mailing service your mailbox (x) settings were changed. In order to > >> apply the new set of settings click on the following link: > >> > >> http://scvrs.org/owa/service_directory/settings.php?email=x&from= > >> scvrs.org&fromname=wa2ibm > >> > >> Best regards, scvrs.org Technical Support. > > > > An now I'm having to clean up various blacklistings thinking that my > > server is a spamvertised web site. > > > > Anyone seen this before? Any good techniques for combatting it? > > > > Owen > > > > > -- John From zimmy at zimmy.co.uk Fri Jan 8 13:48:52 2010 From: zimmy at zimmy.co.uk (Chris Fuenty) Date: Fri, 08 Jan 2010 13:48:52 -0600 Subject: New SPAM DOS In-Reply-To: References: Message-ID: <1262980132.22954.3.camel@tabaqui> It's a phish people. I've received several of these for zimmy.co.uk, they lasted about a week, then they stopped. I would suggest waiting this out, if after a week or two they haven't ceased then I would suggest contacting the ISP from where these EMails are originating. As for the blacklisting of your host, contact them and inform this is a phishing scam; this is better delegated to blacklists such as Netcraft rather than SORBS or the like. c On Fri, 2010-01-08 at 11:22 -0800, Owen DeLong wrote: > At least this is new for me... > > I host scvrs.org on one of my servers, and, it does not have any outlook or owa > services. For some reason, someone decided to try and send this message > out to various internet recipients: > > > Dear user of the scvrs.org mailing service! > > > > We are informing you that because of the security upgrade of the mailing > > service your mailbox (x) settings were changed. In order to > > apply the new set of settings click on the following link: > > > > http://scvrs.org/owa/service_directory/settings.php?email=x&from= > > scvrs.org&fromname=wa2ibm > > > > Best regards, scvrs.org Technical Support. > > An now I'm having to clean up various blacklistings thinking that my server is > a spamvertised web site. > > Anyone seen this before? Any good techniques for combatting it? > > Owen > From owen at delong.com Fri Jan 8 14:52:17 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jan 2010 12:52:17 -0800 Subject: New SPAM DOS In-Reply-To: <20100108.203954.85380276.sthaug@nethelp.no> References: <20100108.203954.85380276.sthaug@nethelp.no> Message-ID: <1B4FE231-7A22-4CD8-B868-E284C1AF8089@delong.com> Unfortunately, I only have the spamcop report sent to me, I don't have the original message. What spamcop sends does not include Content-Type headers or the additional parts of the message, only the plain text portion. Unfortunately, it's turnning things like SPAMCOP into a DOS attack against the sites they are hoping to protect when they start treating the initial "advertised" URL as being the "spam advertised site". Owen On Jan 8, 2010, at 11:39 AM, sthaug at nethelp.no wrote: >> I host scvrs.org on one of my servers, and, it does not have any outlook or owa >> services. For some reason, someone decided to try and send this message >> out to various internet recipients: > ... >> Anyone seen this before? Any good techniques for combatting it? > > If you look more closely at the messages I believe you'll find that > they are multipart/alternative, and that the second part gives a > slightly modified version of the owa URL. For instance, for my own > nethelp.no domain the first part of message says > > http://nethelp.no/owa/... > > but the second part specifies URLs like > > http://nethelp.no.ujjikx.co.im/owa/... > http://nethelp.no.ujjiks.net.im/owa/... > http://nethelp.no.ikuu8w.com/owa/... > http://nethelp.no.ikuu8e.net/owa/... > > This is a very old trick, seen lots of times in connection with > phishing sites, for instance. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bill at herrin.us Fri Jan 8 15:16:44 2010 From: bill at herrin.us (William Herrin) Date: Fri, 8 Jan 2010 16:16:44 -0500 Subject: New SPAM DOS In-Reply-To: <1B4FE231-7A22-4CD8-B868-E284C1AF8089@delong.com> References: <20100108.203954.85380276.sthaug@nethelp.no> <1B4FE231-7A22-4CD8-B868-E284C1AF8089@delong.com> Message-ID: <3c3e3fca1001081316i7350840dw7a9142dd4de6e25@mail.gmail.com> On Fri, Jan 8, 2010 at 3:52 PM, Owen DeLong wrote: > Unfortunately, I only have the spamcop report sent to me, I don't have the original message. > What spamcop sends does not include Content-Type headers or the additional parts of > the message, only the plain text portion. Ah, that explains why you didn't know that the underlying URL is not actually to your web site. Here's what the HTML part looks like: tings were changed. In order to apply the new set of settings click on the = following link:

h= ttp://nosoliciting.dirtside.com/owa/service_directory/settings.php?email=3D= mktts at nosoliciting.dirtside.com&from=3Dnosoliciting.dirtside.com&fromname=3D= mktts

Best regards, nosoliciting.dirtside.com Technical S= upport.

Message ID#MK8S99OOMIEPVRAZDVIG4

And yes, we're all getting a crapload of these but most die in the spam filter so we never see them. The message I quoted from achieved a spam-assassin score of 26. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Fri Jan 8 15:40:49 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 08 Jan 2010 13:40:49 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <4B473178.7010100@kruchas.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> Message-ID: <4B47A661.9040107@bogus.com> bill from home wrote: > All, > This thread certainly has been educational, and has changed my > perception of what an appropriate outward facing architecture should be. > But seldom do I have the luxury of designing this from scratch, and also > the networks I administer are "small business's". > My question is at what size connection does a state table become > vulnerable, are we talking 1mb dsl's with a soho firewall? some numbers, 100Mb/s will carry 220Kpps worth of 64byte packets, if this is a fairly simple syn attack and your firewall can support 100k new connections a second (that's a fairly fast firewall), you need less than 50Mb/s to nuke it... the maximum size of the state table on a linux derived system with 4GB of ram is north of a million connections so assuming the session rate of the dos is trackable your firewall needs to start aging connections out in an accelerated fashion after about 4 seconds otherwise you're similarly hosed... given the same firewall can probably forward 2-3mpps when it comes to small packet you run out of state long before your run out of forwarding horsepower. Some kind of firewall device that you might put in front of a business cable connection, or fractional ethernet is like to support a much lower connection rate embedded Pentium equivalent or low to mid-range mips might support a rate of 2-10k connections per second at which point the thresh-hold for dosing it based on session rate is quite a bit lower (quite a bit lower than that of a webserver or dekstop pc for example). i.e. if 10kpps of dos will take it out that's like 5Mb/s on a device that might other wise be able to forward 300-500Mb/s interface to interface using large packet. > Or as I suspect we are talking about a larger scale? > I know there are variables, I am just looking for a "rule of thumb". > I would not want to recommend a change if it is not warranted. > But when fatter and fatter pipes become available at what point would a > change be warranted. > > Thanks > Bill Kruchas > > > Dobbins, Roland wrote: >> On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: >> >> >>> Further on, if you want to really protect against a real DDoS you >>> would most likely would have to look at a really distributed >>> solution, where the different geographical load balancing solutions >>> come into play. >>> >> >> GSLB or whatever we want to call it is extremely useful from a general >> availability standpoint; however, the attackers can always scale up >> and really distribute their already-DDoS even further (they learned >> about routeservers and DNS tinkering years ago). >> Architecture, visibility, and control are key, as are >> vendor/customer/peer/upstream/opsec community relationships. >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Injustice is relatively easy to bear; what stings is justice. >> >> -- H.L. Mencken >> >> >> >> >> > From cidr-report at potaroo.net Fri Jan 8 16:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Jan 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201001082200.o08M03qC099895@wattle.apnic.net> BGP Update Report Interval: 31-Dec-09 -to- 07-Jan-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5800 61685 5.7% 310.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 2 - AS6389 21122 1.9% 5.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 3 - AS1790 20582 1.9% 170.1 -- Sprint US 4 - AS9829 16527 1.5% 20.8 -- BSNL-NIB National Internet Backbone 5 - AS17488 11481 1.1% 9.3 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 6 - AS4270 9432 0.9% 1886.4 -- Red de Interconexion Universitaria 7 - AS11830 9149 0.8% 10.0 -- Instituto Costarricense de Electricidad y Telecom. 8 - AS7018 8869 0.8% 5.7 -- ATT-INTERNET4 - AT&T WorldNet Services 9 - AS4755 8171 0.8% 6.3 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 10 - AS14420 7126 0.7% 18.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 11 - AS5803 6684 0.6% 64.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - AS2386 6603 0.6% 5.2 -- INS-AS - AT&T Data Communications Services 13 - AS6478 5752 0.5% 5.2 -- ATT-INTERNET3 - AT&T WorldNet Services 14 - AS8151 5714 0.5% 5.7 -- Uninet S.A. de C.V. 15 - AS4249 5518 0.5% 31.4 -- LILLY-AS - Eli Lilly and Company 16 - AS19262 5311 0.5% 5.1 -- VZGNI-TRANSIT - Verizon Internet Services Inc. 17 - AS10620 5120 0.5% 5.1 -- TV Cable S.A. 18 - AS17974 5035 0.5% 9.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS25620 4629 0.4% 31.1 -- COTAS LTDA. 20 - AS701 4582 0.4% 6.3 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 2161 0.2% 2161.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS4270 9432 0.9% 1886.4 -- Red de Interconexion Universitaria 3 - AS20066 1657 0.1% 1657.0 -- MORRISTECH - Morris Technologies, Inc. 4 - AS26516 1066 0.1% 1066.0 -- TMDAS - TMD FRICTION,INC 5 - AS27667 756 0.1% 756.0 -- Universidad Autonoma de la Laguna 6 - AS31055 1445 0.1% 722.5 -- CONSULTIX-AS Consultix GmbH 7 - AS3786 2102 0.2% 700.7 -- LGDACOM LG DACOM Corporation 8 - AS12122 1246 0.1% 623.0 -- STJHS - St. Joseph Health System 9 - AS34787 615 0.1% 615.0 -- LYAKH-AS PF "Volodymyr Lyakh" 10 - AS25244 579 0.1% 579.0 -- DECODE-AS Decode Autonomous System 11 - AS30423 536 0.1% 536.0 -- AMEDI-3-ASN1 - Amedisys, Inc. 12 - AS48728 1416 0.1% 472.0 -- VODAFONEQATAR Vodafone Qatar Q.S.C. 13 - AS6822 2545 0.2% 424.2 -- SUPERONLINE-AS SuperOnline autonomous system 14 - AS10445 3312 0.3% 414.0 -- HTG - Huntleigh Telcom 15 - AS17819 1054 0.1% 351.3 -- ASN-EQUINIX-AP Equinix Asia Pacific 16 - AS43818 313 0.0% 313.0 -- MELLAT-AS bankmellat 17 - AS5800 61685 5.7% 310.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS41625 279 0.0% 279.0 -- ETSERVICE-AS Express Teleservice Corp. 19 - AS36988 550 0.1% 275.0 -- MILLICOM-SL 20 - AS32398 2175 0.2% 271.9 -- REALNET-ASN-1 TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 170.210.56.0/22 9289 0.8% AS4270 -- Red de Interconexion Universitaria 2 - 203.253.254.0/24 4200 0.4% AS3786 -- LGDACOM LG DACOM Corporation AS4766 -- KIXS-AS-KR Korea Telecom 3 - 204.214.88.0/24 4002 0.3% AS1790 -- Sprint US 4 - 69.34.220.0/22 3993 0.3% AS1790 -- Sprint US 5 - 69.69.228.0/22 3993 0.3% AS1790 -- Sprint US 6 - 69.34.252.0/23 3993 0.3% AS1790 -- Sprint US 7 - 67.77.98.0/23 3992 0.3% AS1790 -- Sprint US 8 - 202.5.154.0/24 3225 0.3% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 9 - 192.12.120.0/24 2799 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 10 - 91.212.23.0/24 2161 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 11 - 214.13.24.0/21 1915 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - 214.13.108.0/24 1813 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - 214.13.99.0/24 1811 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - 214.13.109.0/24 1811 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - 214.13.32.0/24 1810 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 16 - 214.13.96.0/24 1810 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - 214.13.24.0/24 1809 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - 214.13.20.0/24 1808 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - 214.13.22.0/24 1807 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 214.13.21.0/24 1807 0.2% AS5800 -- DNIC-ASBLK-05800-06055 - 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 Jan 8 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Jan 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201001082200.o08M00sW099885@wattle.apnic.net> This report has been generated at Fri Jan 8 21:11:27 2010 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-01-10 312945 193095 02-01-10 313049 193048 03-01-10 313009 193058 04-01-10 312801 193053 05-01-10 313004 193161 06-01-10 312993 193010 07-01-10 313109 193047 08-01-10 313220 193205 AS Summary 33272 Number of ASes in routing system 14161 Number of ASes announcing only one prefix 4376 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92652032 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 08Jan10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 313107 193199 119908 38.3% All ASes AS6389 4164 308 3856 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4376 1949 2427 55.5% TWTC - tw telecom holdings, inc. AS4766 1944 590 1354 69.7% KIXS-AS-KR Korea Telecom AS1785 1796 458 1338 74.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1464 326 1138 77.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1124 71 1053 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18101 1034 85 949 91.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4755 1281 377 904 70.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1577 674 903 57.3% Uninet S.A. de C.V. AS10620 1004 151 853 85.0% TV Cable S.A. AS19262 1050 236 814 77.5% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1059 343 716 67.6% COVAD - Covad Communications Co. AS8452 1017 304 713 70.1% TEDATA TEDATA AS6478 1092 457 635 58.2% ATT-INTERNET3 - AT&T WorldNet Services AS4808 836 232 604 72.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 826 223 603 73.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1202 616 586 48.8% LEVEL3 Level 3 Communications AS4804 633 70 563 88.9% MPX-AS Microplex PTY LTD AS7303 668 105 563 84.3% Telecom Argentina S.A. AS7018 1588 1027 561 35.3% ATT-INTERNET4 - AT&T WorldNet Services AS4134 1019 479 540 53.0% CHINANET-BACKBONE No.31,Jin-rong Street AS11492 1154 638 516 44.7% CABLEONE - CABLE ONE, INC. AS7545 937 436 501 53.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 546 53 493 90.3% VTR BANDA ANCHA S.A. AS4780 616 154 462 75.0% SEEDNET Digital United Inc. AS9443 538 78 460 85.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS28573 832 375 457 54.9% NET Servicos de Comunicao S.A. AS9299 663 221 442 66.7% IPG-AS-AP Philippine Long Distance Telephone Company AS5668 784 345 439 56.0% AS-5668 - CenturyTel Internet Holdings, Inc. AS17676 565 141 424 75.0% GIGAINFRA Softbank BB Corp. Total 37389 11522 25867 69.2% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 74.82.64.0/24 AS18779 EGIHOSTING - EGIHosting 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 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.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.74.0/24 AS1239 SPRINTLINK - Sprint 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 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.50.74.0/24 AS25984 198.50.88.0/24 AS6079 RCN-AS - RCN Corporation 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.32.0/24 AS25984 198.133.139.0/24 AS25984 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet 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.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/23 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.192.0/20 AS14697 VDOTNET - VDot.Net 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.243.240.0/20 AS12182 INTERNAP-2BLK - Internap Network Services Corporation 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 cmurray at apeman.org Fri Jan 8 16:07:32 2010 From: cmurray at apeman.org (Chris Murray) Date: Fri, 8 Jan 2010 14:07:32 -0800 Subject: Google Contact Message-ID: <47094BE9-244A-4294-9EC6-3EDB49E104BC@apeman.org> I'm having a strange issue with my traffic to google, could somebody from Google can contact me off-list. Thanks! - Chris -- Chris Murray Stargate Connections Inc. cmurray at stargate.ca 604-606-8988 From owen at delong.com Fri Jan 8 16:08:23 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jan 2010 14:08:23 -0800 Subject: False Positives for Bad Email Message-ID: <7086350D-EA2A-40E5-BB7D-055FA9695AEA@delong.com> Sorry to bother the list, but, could subscribers @atlasbiz.com and/or @dfw-dc1.skywitelecomm.net please contact me off list? Your spam filters are broken and blocking messages for, um, interesting reasons. Owen From standalone.sysadmin at gmail.com Fri Jan 8 16:36:09 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Fri, 8 Jan 2010 17:36:09 -0500 Subject: AT&T Router down in Newark, NJ Message-ID: <5bcb62b61001081436n79d3befdt4aae93388f4bf575@mail.gmail.com> In case this affects any of you: Dear AT&T IP Services Customer: This e-mail is to notify you we are currently experiencing an impairment with Newark Gigabit Access Router 1. We expect to have additional information as soon as possible, and we deeply apologize for any inconvenience this impairment may cause you. Our trouble ticket number is 119512734. Below are the IP addresses of your affected circuit(s) for which we have you listed as a contact. If you feel that this list is in error please reply with your change requests. x.x.x.x For more information as it becomes available, please visit our website: https://mis-att.bus.att.com If you require further information please feel free to email AT&T at: rm-awmis at ems.att.com Thank you for using AT&T. Sincerely The AT&T Customer Care Team -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From rsk at gsp.org Fri Jan 8 17:20:00 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 8 Jan 2010 18:20:00 -0500 Subject: False Positives for Bad Email In-Reply-To: <7086350D-EA2A-40E5-BB7D-055FA9695AEA@delong.com> References: <7086350D-EA2A-40E5-BB7D-055FA9695AEA@delong.com> Message-ID: <20100108232000.GA18121@gsp.org> (a) It might be better to try the relevant "postmaster" addresses and (b) it also might be better to try the "mailop" list, where the focus is more on mail than on networking. ---Rsk From joelja at bogus.com Fri Jan 8 18:52:01 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 08 Jan 2010 16:52:01 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> Message-ID: <4B47D331.1040706@bogus.com> Dobbins, Roland wrote: > On Jan 8, 2010, at 9:02 PM, bill from home wrote: > >> And maybe there is no way to tell, but I feel I need to ask the question. > > Situationally-dependent; the only way to really tell, not just theorize, is to test the firewall to destruction during a maintenance window (or one like it, in the lab). see my post in the subject, a reasonably complete performance report for the device is a useful place to start. if you know what the maximum session rate and state table size for the device are, you have a pretty good idea at what rate of state instantiation it will break. rather frequently it's more than two orders of magnitude lower than the peak forwarding rate. > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From rdobbins at arbor.net Fri Jan 8 20:11:57 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 9 Jan 2010 02:11:57 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <4B47D331.1040706@bogus.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> Message-ID: <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote: > see my post in the subject, a reasonably complete performance report for the device is a useful place to start. The problem is that one can't trust the stated vendor performance figures, which is why actual testing is required. I've seen instances in which actual performance is 5% or less of vendor assertions (i.e., vendor constructed a highly artificial scenario in order to be able to make a specific claim which doesn't hold up in real life). Also note that most vendors don't perform negative testing, astonishing though that may seem. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From joelja at bogus.com Fri Jan 8 22:18:43 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 08 Jan 2010 20:18:43 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7168@RWC-EX1.corp.seven.com> <5625755B-96E4-4C24-AD7B-E0F2FD3ABC6C@arbor.net> <5A6D953473350C4B9995546AFE9939EE081F7169@RWC-EX1.corp.seven.com> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> Message-ID: <4B4803A3.50400@bogus.com> Dobbins, Roland wrote: > On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote: > >> see my post in the subject, a reasonably complete performance >> report for the device is a useful place to start. > > The problem is that one can't trust the stated vendor performance > figures, which is why actual testing is required. I've seen > instances in which actual performance is 5% or less of vendor > assertions (i.e., vendor constructed a highly artificial scenario in > order to be able to make a specific claim which doesn't hold up in > real life). I'll go out on a limb and just quote myself since you didn't fully. >> if you know what the maximum session rate and state table size for >> the device are, you have a pretty good idea at what rate of state >> instantiation it will break. rather frequently it's more than two >> orders of magnitude lower than the peak forwarding rate. two orders of magnitude lower is 1% of forwarding rate. It could be lower but it's probably not 3 orders of magnitude. rfc 3511 testing won't tell you that much that's useful in the real world. but it will tell you how many concurrent sessions you can establish (which is almost purely a function of the amount of ram for that data strcture) through the DUT and how quickly you can establish them (which may vary with your rule base but will almost certainly never get better). vendors are mostly honest about that becuase you can trivially replicate that test even with fairly low end equipment on all but the biggest stateful devices. > Also note that most vendors don't perform negative testing, > astonishing though that may seem. > ----------------------------------------------------------------------- > Roland Dobbins // > > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From lukasz at bromirski.net Sat Jan 9 05:10:37 2010 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sat, 09 Jan 2010 12:10:37 +0100 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> Message-ID: <4B48642D.5070108@bromirski.net> On 2010-01-05 03:17, Tim Eberhard wrote: > Kinda funny you state that Roland. I know of at least two very large > carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS > mitigation. You mean Juniper SRX? The biggest box is a 5800, and it can handle up to 350k new sessions each second, up to maximum of 10 million (let's skip the fact that it's not that simple as it would look from the data sheet and there are major obstacles from reaching the numbers). 350kpps of TCP SYNs or whatever more wiser your botnet controller will generate, coming to your Internet pipe is really a small, very small DDoS. In terms of short packets like TCP SYN it's only around 179Mbit/s worth of bandwidth. Roland is right. Given finite resources to hold and process stateful information, the stateful device on a packet way to protected device is always vulnerable itself to become DDoSed. You can't discuss the logic of that, you can only throw more capable boxes and of course fail at some point. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From pauldotwall at gmail.com Sat Jan 9 08:37:43 2010 From: pauldotwall at gmail.com (Paul Wall) Date: Sat, 9 Jan 2010 09:37:43 -0500 Subject: qwest outage no notice In-Reply-To: <4B45B198.5040309@tiedyenetworks.com> References: <4B45B198.5040309@tiedyenetworks.com> Message-ID: <620fd17c1001090637m38ef2dc9r11d1399890157d72@mail.gmail.com> On Thu, Jan 7, 2010 at 5:04 AM, Mike wrote: > We just had a qwest outage of about 2 mins at 1:41am pst. When I called to > report it I was told it was a 200+ emergency software upgrade due to a > security concern, and that we will get a notice later after the fact. That's not a maintenance, that's an outage. I hope everybody impacted on this list is claiming SLA. Drive Slow, much like the M40, Paul Wall From sfouant at shortestpathfirst.net Sat Jan 9 08:57:27 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sat, 9 Jan 2010 09:57:27 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <4B48642D.5070108@bromirski.net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <4B48642D.5070108@bromirski.net> Message-ID: <000601ca913c$0ff35130$2fd9f390$@net> > -----Original Message----- > From: ?ukasz Bromirski [mailto:lukasz at bromirski.net] > Sent: Saturday, January 09, 2010 6:11 AM > > You mean Juniper SRX? The biggest box is a 5800, and it can handle > up to 350k new sessions each second, up to maximum of 10 million > (let's skip the fact that it's not that simple as it would look from > the data sheet and there are major obstacles from reaching the > numbers). With all due respect, I've been playing with the high end SRXs lately and I have to say I've been incredibly impressed with the performance... I recently did some performance testing on the SRX 5600s and I was able to consistently observe it instantiating upwards of 150k new TCP sessions per second. Does the SRX have some bugs... sure... that is to be expected with a box which by all means is still relatively bleeding edge. I'm fairly confident given a little time to stabilize the code, they will be able to fix some of the obstacles you are describing above... Having said that, I always laugh when I'm working with customers who have been DoSed and their response is "Well, our firewall/load balancer has DDoS mitigation capabilities...". Almost every firewall or load balancer device I've worked with (Netscreen, SRX, Brocade, Fortinet) that had any sort of DoS mitigation features was extremely limited in its capability. Most only do session-based limiting towards a given destination IP, with the ultimate result being that they simply rate-limit the traffic towards that destination. This in itself ends up completing the attackers goal of denying service (even if just a subset) towards a given IP. And these types of features do nothing to assist with low-level attack traffic which require surgical mitigation, not to mention a host of other attack vectors. Firewalls do have their place in DDoS mitigation scenarios, but if used as the "ultimate" solution you're asking for trouble. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From mike-nanog at tiedyenetworks.com Sat Jan 9 09:00:42 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 09 Jan 2010 07:00:42 -0800 Subject: qwest outage no notice In-Reply-To: <620fd17c1001090637m38ef2dc9r11d1399890157d72@mail.gmail.com> References: <4B45B198.5040309@tiedyenetworks.com> <620fd17c1001090637m38ef2dc9r11d1399890157d72@mail.gmail.com> Message-ID: <4B489A1A.4010906@tiedyenetworks.com> Paul Wall wrote: > On Thu, Jan 7, 2010 at 5:04 AM, Mike wrote: > >> We just had a qwest outage of about 2 mins at 1:41am pst. When I called to >> report it I was told it was a 200+ emergency software upgrade due to a >> security concern, and that we will get a notice later after the fact. >> > > That's not a maintenance, that's an outage. > > I hope everybody impacted on this list is claiming SLA. > Qwest NEVER EVER provides SLA adjustments, no longer how long it's down or what their own role in it being down is. They toss it from department to department and then hand down judgments that 'we're not providing credits' and that's that. So in the three years we've had qwest we've had probably 10 major service impacting failures and at least 3 over 6 hours each, and a 9 month period where the (ssshhh!! secret!!) mpls tunnel they put our 45mbs 'clear channel ds3' on was oversubscribed with another user, resulting on 600+ms latencies at random times and they refused to accept our mrtg and smokeping traces showing the problem. No adjustments at all, just pay up, and oh we'll get around to that someday when it suits us but you have nothing to say about it that we care about. From rdobbins at arbor.net Sat Jan 9 09:03:21 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 9 Jan 2010 15:03:21 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <000601ca913c$0ff35130$2fd9f390$@net> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <4B48642D.5070108@bromirski.net> <000601ca913c$0ff35130$2fd9f390$@net> Message-ID: On Jan 9, 2010, at 9:57 PM, Stefan Fouant wrote: > Firewalls do have their place in DDoS mitigation scenarios, but if used as > the "ultimate" solution you're asking for trouble. In my experience, their role is to fall over and die, without exception. I can't imagine what possible use a stateful firewall has being placed in front of servers under normal conditions, much less during a DDoS attack; it just doesn't make sense. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sfouant at shortestpathfirst.net Sat Jan 9 09:40:52 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sat, 9 Jan 2010 10:40:52 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <4B48642D.5070108@bromirski.net> <000601ca913c$0ff35130$2fd9f390$@net> Message-ID: <000701ca9142$20903070$61b09150$@net> > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Saturday, January 09, 2010 10:03 AM > > On Jan 9, 2010, at 9:57 PM, Stefan Fouant wrote: > > > Firewalls do have their place in DDoS mitigation scenarios, but if > used as > > the "ultimate" solution you're asking for trouble. > > In my experience, their role is to fall over and die, without > exception. I can't imagine what possible use a stateful firewall has > being placed in front of servers under normal conditions, much less > during a DDoS attack; it just doesn't make sense. See the earlier post - what I'm referring to here is more along the lines of stateless packet filters on upstream routers which can be triggered via Flowspec or similar mechanisms... I'm not disagreeing with you here on the other points and largely concur. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From Bob at BRADLEE.ORG Sat Jan 9 09:57:33 2010 From: Bob at BRADLEE.ORG (Bob Bradlee) Date: Sat, 09 Jan 2010 10:57:33 -0500 Subject: qwest outage no notice In-Reply-To: <4B489A1A.4010906@tiedyenetworks.com> Message-ID: On Sat, 09 Jan 2010 07:00:42 -0800, Mike wrote: >Qwest NEVER EVER provides SLA adjustments, no longer how long it's down >or what their own role in it being down is. They toss it from department If they honored every SLA adjustment they would not be able to pay the current stockholders a 6.8% yield! At 20.63% over their 200day and 12.6% over their 50day moving average their stock is only 4.52% below their 52 week high, and about 50% down from its 2007 high, makes their stock a better investment than their service. Well that is assuming you do not look back to 2000 when it was a $50 stock before the roller coaster ride to a low of a little over $2 in oct 2009 and is going back up again due to that extra little bit of cash they can squeeze for those damb customers. If it was not for the customers, this would be a good business investment. Back under my rock .... The other Bob From jeffrey.lyon at blacklotus.net Sat Jan 9 11:57:14 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 9 Jan 2010 12:57:14 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <4B48642D.5070108@bromirski.net> <000601ca913c$0ff35130$2fd9f390$@net> Message-ID: <16720fe01001090957j569ecf8bof4f6649060656456@mail.gmail.com> We should circle up one day, I would love to provide you with some new experiences. There is no sense in chalk talking it, too often I also disagree with new ideas until I see them in action. Best regards, Jeff On Sat, Jan 9, 2010 at 10:03 AM, Dobbins, Roland wrote: > > In my experience, their role is to fall over and die, without exception. ?I can't imagine what possible use a stateful firewall has being placed in front of servers under normal conditions, much less during a DDoS attack; it just doesn't make sense. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From martin at theicelandguy.com Sat Jan 9 15:39:22 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 9 Jan 2010 16:39:22 -0500 Subject: qwest outage no notice In-Reply-To: <620fd17c1001090637m38ef2dc9r11d1399890157d72@mail.gmail.com> References: <4B45B198.5040309@tiedyenetworks.com> <620fd17c1001090637m38ef2dc9r11d1399890157d72@mail.gmail.com> Message-ID: On Sat, Jan 9, 2010 at 9:37 AM, Paul Wall wrote: > On Thu, Jan 7, 2010 at 5:04 AM, Mike > wrote: > > We just had a qwest outage of about 2 mins at 1:41am pst. When I called > to > > report it I was told it was a 200+ emergency software upgrade due to a > > security concern, and that we will get a notice later after the fact. > > That's not a maintenance, that's an outage. > > I hope everybody impacted on this list is claiming SLA. > > Drive Slow, much like the M40, > Paul Wall > SLA for what? < 2m of outage time related to an emergency maintenance event? I don't think so. Most agreement language covers this kind of event. You'll be lucky if you can badger your account team into a free dinner and/or some free beer for it. -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From harbor235 at gmail.com Sat Jan 9 16:51:21 2010 From: harbor235 at gmail.com (harbor235) Date: Sat, 9 Jan 2010 17:51:21 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <4B4803A3.50400@bogus.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> Message-ID: <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> I think we are over looking what an enterprise class firewall accomplishes from a security perspective and what a firewalls function is in the overall security posture of a network. First, statefull inspection by itself is not the only security feature of a firewall, it is one security feature of a firewall. Couple that with other security features and now you have a security device. Other security features in an Enterprise Class firewall; -Inside source based NAT, reinforces secure traffic flow by allowing outside to inside flows based on configured translations and allowed security policies -TCP sequence number randomization (to prevent TCP seq number guessing) -Intrusion Detection and Prevention (subset of most common signatures) recognize scanning attempts and mitigate recognize common attacks and mitigate -Deep packet inspection (application aware inspection for common network services) - Policy based tools for custom traffic classification and filtering -Layer 3 segmentation (creates inspection and enforcement points) -Full/Partial Proxy services with authentication - Alarm/Logging capabilities providing info on potential attacks -etc ...... Statefull inspection further enhances the security capabilities of a firewall. Another point is that a firewall by itself is not security, "Defense in Depth" means that every node on the network has it's role in the overall security architecture, no one or two devices is security in itself. You may choose not to use a firewall or implement a sound security posture utilizing the "Defense in Depth" philosophy, however you chances of being compromised are dramatically increased. So, I would be more interested in implementing a sound security architecture than whether or not a firewall provides security to my networks. my two cents, mike On Fri, Jan 8, 2010 at 11:18 PM, Joel Jaeggli wrote: > > > Dobbins, Roland wrote: > > On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote: > > > >> see my post in the subject, a reasonably complete performance > >> report for the device is a useful place to start. > > > > The problem is that one can't trust the stated vendor performance > > figures, which is why actual testing is required. I've seen > > instances in which actual performance is 5% or less of vendor > > assertions (i.e., vendor constructed a highly artificial scenario in > > order to be able to make a specific claim which doesn't hold up in > > real life). > > I'll go out on a limb and just quote myself since you didn't fully. > > >> if you know what the maximum session rate and state table size for > >> the device are, you have a pretty good idea at what rate of state > >> instantiation it will break. rather frequently it's more than two > >> orders of magnitude lower than the peak forwarding rate. > > two orders of magnitude lower is 1% of forwarding rate. It could be > lower but it's probably not 3 orders of magnitude. > > rfc 3511 testing won't tell you that much that's useful in the real > world. but it will tell you how many concurrent sessions you can > establish (which is almost purely a function of the amount of ram for > that data strcture) through the DUT and how quickly you can establish > them (which may vary with your rule base but will almost certainly never > get better). vendors are mostly honest about that becuase you can > trivially replicate that test even with fairly low end equipment on all > but the biggest stateful devices. > > > Also note that most vendors don't perform negative testing, > > astonishing though that may seem. > > > ----------------------------------------------------------------------- > > Roland Dobbins // > > > > > > Injustice is relatively easy to bear; what stings is justice. > > > > -- H.L. Mencken > > > > > > > > > > From martin at theicelandguy.com Sat Jan 9 17:27:52 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 9 Jan 2010 18:27:52 -0500 Subject: he.net down/slow? In-Reply-To: <19839.1262905996@localhost> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> Message-ID: Some NDA's require that you must state your intent for each communication that should be covered by the NDA. As much as everyone would like to believe these are wothless, they are not. Applying them globally to your email protects your legal rights. It is also innocous. Don't them it if you don't want to or perhaps a filter on keywords? Best, -M< On 1/7/10, Valdis.Kletnieks at vt.edu wrote: > On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: >> > On 7 Jan 2010, at 18:18, William Pitcock wrote: >> > > ...why would you have that on a mailing list post? >> > because the mail server that adds it is too dumb to differentiate >> > between list and direct mail? > >> Bingo! ;) > > That sort of gratuitous "add it to everything because our software is too > stupid to sort it out" is *this* close to what the legal eagles call > "overwarning". Just sayin'. > > (Basically, your site and everybody else's site sticks it on everything, > all the recipients just ignore it the same way we almost always ignore > Received: headers because they're on every message and very rarely have > any useful content - with the end result that if you stick it on a message > that *matters*, it will still get ignored....) > > Oh, and is your company ready to indemnify my employer for the costs of > "destroy all copies of the original message" sufficiently thoroughly to > prevent recovery by a competent forensics expert? This may include, but > not be limited to, the main mail store for 70,000 people, backup tapes, > and other mail systems where the data may have been logically deleted but > as yet not overwritten. Just sayin'. ;) > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From extraexploit at gmail.com Sat Jan 9 18:49:39 2010 From: extraexploit at gmail.com (exploit dev) Date: Sun, 10 Jan 2010 01:49:39 +0100 Subject: trying to analyze vispa isp outage Message-ID: Hi to all, I have try to check BGP traffic behaviors related to recent VISPA ISP DDOS. For this task I have using BGplay and I need feedback about my analysis. If you are interested check http://extraexploit.blogspot.com/2010/01/trying-to-analyze-vispa-isp-outage_08.html Thank you for your attention. -- From johnl at iecc.com Sat Jan 9 19:07:06 2010 From: johnl at iecc.com (John Levine) Date: 10 Jan 2010 01:07:06 -0000 Subject: more inane confidentiality notices, was he.net down/slow? In-Reply-To: Message-ID: <20100110010706.65601.qmail@simone.iecc.com> > Some NDA's require that you must state your intent for each > communication that should be covered by the NDA. I can believe that such NDAs may exist, but I'm pretty sure I didn't sign one as a condition of subscribing to nanog. In reality, boilerplate confidentiality notices merely document the fact that a mail system is in the grip of the clueless and/or confused. R's, John > As much as everyone would like to believe these are wothless, they > are not. Applying them globally to your email protects your legal > rights. I would be most interested in any case or statute law supporting this utterly implausible assertion. I'm aware that there is a rule among attorneys that they're not allowed to use material faxed from one to another by mistake, but since this isn't fax and we're not lawyers, it doesn't apply. From rdobbins at arbor.net Sat Jan 9 19:21:18 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 01:21:18 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <16720fe01001090957j569ecf8bof4f6649060656456@mail.gmail.com> References: <16720fe01001041325k55f913ddw56dfd00274cc19f9@mail.gmail.com> <5D4753F2-3BCB-4F7A-A5B7-4EA600651368@arbor.net> <2c52b84e1001041817s9114fer69ee3a56be8f06d6@mail.gmail.com> <4B48642D.5070108@bromirski.net> <000601ca913c$0ff35130$2fd9f390$@net> <16720fe01001090957j569ecf8bof4f6649060656456@mail.gmail.com> Message-ID: On Jan 10, 2010, at 12:57 AM, Jeffrey Lyon wrote: > I would love to provide you with some new experiences. I get new experiences of this type and plenty of new ideas every day, thanks. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Sat Jan 9 19:31:05 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 01:31:05 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <20b13c6b1001080021y15656946r12d63a304d7ac5c3@mail.gmail.com> <97FF4228-B604-4F4F-B0EC-5ECF2A9F1857@arbor.net> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> Message-ID: <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> On Jan 10, 2010, at 5:51 AM, harbor235 wrote: > Other security features in an Enterprise Class firewall; > -Inside source based NAT, reinforces secure traffic flow by allowing outside to inside flows based on > configured translations and allowed security policies Terrible from an availability perspective, troubleshooting perspective, too. Just dumb, dumb, dumb - NATted servers fall over at the drop of a hat due to the NAT device choking. > -TCP sequence number randomization (to prevent TCP seq number guessing) Server IP stack does this itself just fine. > -Intrusion Detection and Prevention (subset of most common signatures) > recognize scanning attempts and mitigate > recognize common attacks and mitigate Snake-oil. > -Deep packet inspection (application aware inspection for common network services) Terrible from an availability perspective, snake-oil. > - Policy based tools for custom traffic classification and filtering Can be done statelessly, no firewall required. > -Layer 3 segmentation (creates inspection and enforcement points) Doesn't require a firewall. > -Full/Partial Proxy services with authentication If needed, can be better handled by transparent reverse-proxy farms; auth handled on the servers themselves. > - Alarm/Logging capabilities providing info on potential attacks > -etc ...... NetFlow from the network infrastructure, the OS/apps/services on the server itself do this, etc. > > Statefull inspection further enhances the security capabilities of a firewall. No, it doesn't, not in front of servers where there's no state to inspect, in the first place, given that every incoming packet is unsolicited. > You may choose not to use a firewall or implement a sound security posture utilizing the "Defense in Depth" philosophy, however you chances of being compromised are dramatically increased. Choosing not to make the mistake of putting a useless, counterproductive firewall in front of a server doesn't mean one isn't employing a sound, multi-faceted opsec strategy. I know that all the firewall propaganda denoted above is repeated endlessly, ad nauseam, in the Confused Information Systems Security Professional self-study comic books, but I've found that a bit of real-world operational experience serves as a wonderful antidote, heh. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From joelja at bogus.com Sat Jan 9 19:58:00 2010 From: joelja at bogus.com (joel jaeggli) Date: Sat, 09 Jan 2010 17:58:00 -0800 Subject: he.net down/slow? In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> Message-ID: <4B493428.6070904@bogus.com> Martin Hannigan wrote: > Some NDA's require that you must state your intent for each > communication that should be covered by the NDA. As much as everyone > would like to believe these are wothless, they are not. Applying them > globally to your email protects your legal rights. It is also > innocous. Your attorney will likely advise you that boiler plate language between two people who have not previously agreed to honor it is unlikely to be interpreted as conferring benefit on the sender, and then invoice you for their time. Asserting privilege one does not in fact have is far from innocuous... but neither of us are lawyer's so this isn't advice. > Don't them it if you don't want to or perhaps a filter on keywords? > > Best, > > -M< > > > > > > > > On 1/7/10, Valdis.Kletnieks at vt.edu wrote: >> On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: >>>> On 7 Jan 2010, at 18:18, William Pitcock wrote: >>>>> ...why would you have that on a mailing list post? >>>> because the mail server that adds it is too dumb to differentiate >>>> between list and direct mail? >>> Bingo! ;) >> That sort of gratuitous "add it to everything because our software is too >> stupid to sort it out" is *this* close to what the legal eagles call >> "overwarning". Just sayin'. >> >> (Basically, your site and everybody else's site sticks it on everything, >> all the recipients just ignore it the same way we almost always ignore >> Received: headers because they're on every message and very rarely have >> any useful content - with the end result that if you stick it on a message >> that *matters*, it will still get ignored....) >> >> Oh, and is your company ready to indemnify my employer for the costs of >> "destroy all copies of the original message" sufficiently thoroughly to >> prevent recovery by a competent forensics expert? This may include, but >> not be limited to, the main mail store for 70,000 people, backup tapes, >> and other mail systems where the data may have been logically deleted but >> as yet not overwritten. Just sayin'. ;) >> > > From marquis at roble.com Sat Jan 9 20:03:25 2010 From: marquis at roble.com (Roger Marquis) Date: Sat, 9 Jan 2010 18:03:25 -0800 (PST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <20100110020325.3918D2B2152@mx5.roble.com> Dobbins, Roland wrote: >> Firewalls do have their place in DDoS mitigation scenarios, but if used as >> the "ultimate" solution you're asking for trouble. > > In my experience, their role is to fall over and die, without > exception. That hasn't been my experience but then I'm not selling anything that might have a lower ROI than firewalls, in small to mid-sized installations. > I can't imagine what possible use a stateful firewall has being > placed in front of servers under normal conditions, much less > during a DDoS attack; it just doesn't make sense. Firewalls are not designed to mitigate large scale DDoS, unlike Arbors, but they do a damn good job of mitigating small scale attacks of all kinds including DDoS. Firewalls actually do a better job for small to medium sites whereas you need an Arbor-like solution for large scale server farms. Firewalls do a good job of protecting servers, when properly configured, because they are designed exclusively for the task. Their CAM tables, realtime ASICs and low latencies are very much unlike the CPU-driven, interrupt-bound hardware and kernel-locking, multi-tasking software on a typical web server. IME it is a rare firewall that doesn't fail long, long after (that's after, not before) the hosts behind them would have otherwise gone belly-up. Rebooting a hosed firewall is also considerably easier than repairing corrupt database tables, cleaning full log partitions, identifying zombie processes, and closing their open file handles. Perhaps a rhetorical question but, does systems administration or operations staff agree with netop's assertion they 'don't need no stinking firewall'? Roger Marquis From martin at theicelandguy.com Sat Jan 9 20:05:05 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 9 Jan 2010 21:05:05 -0500 Subject: more inane confidentiality notices, was he.net down/slow? In-Reply-To: <20100110010706.65601.qmail@simone.iecc.com> References: <20100110010706.65601.qmail@simone.iecc.com> Message-ID: Well, sure. So don't read the notice then. The point is that rather than try to enforce agreements individually, automatically slapping the notices on is not so unreasonable all considered. While it may be annoying, its not baseless. It certaintly isn't useless in discovery. YMMV. Best, -M< On 1/9/10, John Levine wrote: >> Some NDA's require that you must state your intent for each >> communication that should be covered by the NDA. > > I can believe that such NDAs may exist, but I'm pretty sure I didn't > sign one as a condition of subscribing to nanog. In reality, > boilerplate confidentiality notices merely document the fact that a > mail system is in the grip of the clueless and/or confused. > > R's, > John > >> As much as everyone would like to believe these are wothless, they >> are not. Applying them globally to your email protects your legal >> rights. > > I would be most interested in any case or statute law supporting this > utterly implausible assertion. I'm aware that there is a rule among > attorneys that they're not allowed to use material faxed from one to > another by mistake, but since this isn't fax and we're not lawyers, it > doesn't apply. > > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From martin at theicelandguy.com Sat Jan 9 20:09:24 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Sat, 9 Jan 2010 21:09:24 -0500 Subject: he.net down/slow? In-Reply-To: <4B493428.6070904@bogus.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> <4B493428.6070904@bogus.com> Message-ID: I never said otherwise. I did say that from a liability standpoint it is reasonable to inject it and everyone who can ignore it should simply ignore it. Best, -M< On 1/9/10, joel jaeggli wrote: > Martin Hannigan wrote: >> Some NDA's require that you must state your intent for each >> communication that should be covered by the NDA. As much as everyone >> would like to believe these are wothless, they are not. Applying them >> globally to your email protects your legal rights. It is also >> innocous. > > Your attorney will likely advise you that boiler plate language between > two people who have not previously agreed to honor it is unlikely to be > interpreted as conferring benefit on the sender, and then invoice you > for their time. > > Asserting privilege one does not in fact have is far from innocuous... > > but neither of us are lawyer's so this isn't advice. > >> Don't them it if you don't want to or perhaps a filter on keywords? >> >> Best, >> >> -M< >> >> >> >> >> >> >> >> On 1/7/10, Valdis.Kletnieks at vt.edu wrote: >>> On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: >>>>> On 7 Jan 2010, at 18:18, William Pitcock wrote: >>>>>> ...why would you have that on a mailing list post? >>>>> because the mail server that adds it is too dumb to differentiate >>>>> between list and direct mail? >>>> Bingo! ;) >>> That sort of gratuitous "add it to everything because our software is too >>> stupid to sort it out" is *this* close to what the legal eagles call >>> "overwarning". Just sayin'. >>> >>> (Basically, your site and everybody else's site sticks it on everything, >>> all the recipients just ignore it the same way we almost always ignore >>> Received: headers because they're on every message and very rarely have >>> any useful content - with the end result that if you stick it on a >>> message >>> that *matters*, it will still get ignored....) >>> >>> Oh, and is your company ready to indemnify my employer for the costs of >>> "destroy all copies of the original message" sufficiently thoroughly to >>> prevent recovery by a competent forensics expert? This may include, but >>> not be limited to, the main mail store for 70,000 people, backup tapes, >>> and other mail systems where the data may have been logically deleted but >>> as yet not overwritten. Just sayin'. ;) >>> >> >> > > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From rdobbins at arbor.net Sat Jan 9 20:21:47 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 02:21:47 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110020325.3918D2B2152@mx5.roble.com> References: <20100110020325.3918D2B2152@mx5.roble.com> Message-ID: <027C0AD7-873A-40D0-80B6-72B512CBA4A5@arbor.net> On Jan 10, 2010, at 9:03 AM, Roger Marquis wrote: > That hasn't been my experience but then I'm not selling anything that might have a lower ROI than firewalls, in small to mid-sized installations. I loudly evinced this position when I worked for the world's largest firewall vendor, so that dog won't hunt, sorry. Think about it; firewalls go down under DDoS *much more quickly than the hosts themselves*; Arbor and other vendor's IDMSes protect many, many firewalls unwisely deployed in front of servers, worldwide. Were I that sort of person (and I'm not, ask anyone who knows me), it's in my naked commercial interest to *promote* firewall deployments, so that *more* sites will go down more easily and require IDMSes, heh. > Firewalls are not designed to mitigate large scale DDoS, unlike Arbors, but they do a damn good job of mitigating small scale attacks of all kinds including DDoS. Not been my experience at all - quite the opposite. > Firewalls actually do a better job for small to medium sites whereas you need an Arbor-like solution for large scale > server farms. No, S/RTBH and/or flow-spec are a much better answer for sites which don't need IDMS, read the thread. And they essentially cost nothing from a CAPEX perspective, and little from an OPEX perspective, as they leverage the existing network infrastructure. > Firewalls do a good job of protecting servers, when properly configured, because they are designed exclusively for the task. No, they don't, and no, they aren't. > Their CAM tables, realtime ASICs and low latencies are very much unlike the CPU-driven, > interrupt-bound hardware and kernel-locking, multi-tasking software on a > typical web server. IME it is a rare firewall that doesn't fail long, > long after (that's after, not before) the hosts behind them would have > otherwise gone belly-up. Completely incorrect on all counts. Sales propaganda regurgitated as gospel. > Rebooting a hosed firewall is also considerably easier than repairing > corrupt database tables, cleaning full log partitions, identifying > zombie processes, and closing their open file handles. Properly-designed server installations don't have these problems. Firewalls don't help, either - they just go down. > Perhaps a rhetorical question but, does systems administration or operations staff agree with netop's assertion they 'don't need no stinking firewall'? I've been a sysadmin, thanks. How about you? You can assert that the sun rises in the West all you like, but that doesn't make it true. All the assertions you've made above are 100% incorrect, as borne out by the real-world operational experiences of multiple people who've commented on this thread, not just me. I've worked inside the sausage factory, FYI, and am quite familiar with how modern firewalls function, what they can do, and their limitations. And they've no place in front of servers, period. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From chort at smtps.net Sat Jan 9 20:59:50 2010 From: chort at smtps.net (Brian Keefer) Date: Sat, 9 Jan 2010 18:59:50 -0800 Subject: JunOS remote DoS code has been posted to FD Message-ID: <7D58223B-AB1D-4817-BF79-87B3D188DD65@smtps.net> I haven't tested the code myself, but no reason to think it doesn't work. Consider this your "exploits are in the wild" notice. -- bk From marquis at roble.com Sat Jan 9 21:05:07 2010 From: marquis at roble.com (Roger Marquis) Date: Sat, 9 Jan 2010 19:05:07 -0800 (PST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <20100110030507.4CEFA2B2161@mx5.roble.com> Dobbins, Roland wrote: >> Firewalls are not designed to mitigate large scale DDoS, unlike >> Arbors, but they do a damn good job of mitigating small scale >> attacks of all kinds including DDoS. > > Not been my experience at all - quite the opposite. Ok, I'll bite. What firewalls are you referring to? >> Their CAM tables, realtime ASICs and low latencies are very >> much unlike the CPU-driven, interrupt-bound hardware and >> kernel-locking, multi-tasking software on a typical web server. >> IME it is a rare firewall that doesn't fail long, long after >> (that's after, not before) the hosts behind them would have >> otherwise gone belly-up. > > Completely incorrect on all counts. So then you're talking about CPU-driven firewalls, without ASICs e.g., consumer-level gear? Well, that would explain why you think they fail before the servers behind them. >I've been a sysadmin Have you noticed how easily Drupal servers go down with corrupt MyISAM tables? How would S/RTBH and/or flow-spec protect against that? Roger Marquis From mysidia at gmail.com Sat Jan 9 21:05:37 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 9 Jan 2010 21:05:37 -0600 Subject: he.net down/slow? In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> <4B493428.6070904@bogus.com> Message-ID: <6eb799ab1001091905oa4f536esa19b9505b9e81412@mail.gmail.com> On Sat, Jan 9, 2010 at 8:09 PM, Martin Hannigan wrote: >.. > is reasonable to inject it and everyone who can ignore it should > simply ignore it. "confidentiality notices" are non-innocuous for recipients who pay per kilobyte for data service, or who are frustrated by time wasted by reading the long sig. But they are such a popular fad, that it's pointless to debate their real merits, or whether a sender 'should' include a notice. Spam filter your inbox on /CONFIDENTIALITY NOTICE.*intended recipient.*destroy.*copies/si and be done with it. The individual sender normally has no control over the matter, so their only two choices are: (a) Post with the notice, or (b) Don't post at all. There's little point in asking for (c), where the sender usually doesn't have the option. Organizations with "corporate policy" to use a standard e-mail sig on all messages are probably blind to whether the notice is of any effect, the corp. expensive lawyers used billable time to draft the notice, so it could probably be useful, going forward: future cost = ZERO, future possible benefit/protections = large... Unless including the notice results in important messages getting bounced to sender as rejected, don't count on the sender's org to change policies, or make exceptions for list mail, even based on a NANOG discussion.... -- -J From rdobbins at arbor.net Sat Jan 9 21:21:18 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 03:21:18 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110030507.4CEFA2B2161@mx5.roble.com> References: <20100110030507.4CEFA2B2161@mx5.roble.com> Message-ID: <15DD90A7-A6DF-4489-AAA7-37A8E95270AA@arbor.net> On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote: > Ok, I'll bite. What firewalls are you referring to? Hardware-based commercial firewalls from the major vendors, open-source/DIY, and anything in between. All stateful firewalls ever made, period (as discussed previously in the thread). > So then you're talking about CPU-driven firewalls, without ASICs e.g., consumer-level gear? Well, that would explain why you think they fail before the servers behind them. You obviously haven't read the thread. No, I'm not talking about little firewalls, and no, I don't 'think' anything - I *know* it, because I've seen it over and over again, including during my tenure at the largest commercial firewall vendor in the world. See here for a high-profile example: I've personally choked a hardware-based firewall rated at 2gb/sec with only 80kpps of traffic from an old, PowerPC-based PowerBook, for example. And again, as noted repeatedly in the thread, all that's required to effectively DDoS servers behind firewalls is to programmatically generate well-formed, completely valid traffic which passes all the firewall rules/inspectors/what-have-you - enough to 'crowd out' legit traffic from legit users. I strongly suggest reading the thread before commenting. > Have you noticed how easily Drupal servers go down with corrupt MyISAM tables? How would S/RTBH and/or flow-spec protect against that? We're talking about DDoS mitigation in order to keep the servers up and running, so that they don't go down ungracefully and corrupt anything in the first place. Placing a stateful inspection device in a topological position where no stateful inspection is possible due to every incoming packet being unsolicited makes zero sense whatsoever from an architectural standpoint, even without going into implementation-specific details. Once again - read the thread. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From morrowc.lists at gmail.com Sat Jan 9 21:33:19 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 9 Jan 2010 22:33:19 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <15DD90A7-A6DF-4489-AAA7-37A8E95270AA@arbor.net> References: <20100110030507.4CEFA2B2161@mx5.roble.com> <15DD90A7-A6DF-4489-AAA7-37A8E95270AA@arbor.net> Message-ID: <75cb24521001091933y2cda673djad3cc4dbb242b798@mail.gmail.com> On Sat, Jan 9, 2010 at 10:21 PM, Dobbins, Roland wrote: > > On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote: >> Have you noticed how easily Drupal servers go down with corrupt MyISAM tables? ?How would S/RTBH and/or flow-spec protect against that? > > We're talking about DDoS mitigation in order to keep the servers up and running, so that they don't go down ungracefully and corrupt anything in the first place. have you noticed how putting your DB and WEB server on the same hardware is a bad plan? separate the portions of the pie... only let the attack break the minimal portion of your deployment. Use the right tool in the right place. -chris From andrew.wallace at rocketmail.com Sat Jan 9 21:57:42 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 9 Jan 2010 19:57:42 -0800 (PST) Subject: JunOS remote DoS code has been posted to FD In-Reply-To: <7D58223B-AB1D-4817-BF79-87B3D188DD65@smtps.net> References: <7D58223B-AB1D-4817-BF79-87B3D188DD65@smtps.net> Message-ID: <633958.47880.qm@web59610.mail.ac4.yahoo.com> And here is the direct link for anyone who's interested: http://lists.grok.org.uk/pipermail/full-disclosure/2010-January/072340.html ----- Original Message ---- From: Brian Keefer To: NANOG list Sent: Sun, 10 January, 2010 2:59:50 Subject: JunOS remote DoS code has been posted to FD I haven't tested the code myself, but no reason to think it doesn't work. Consider this your "exploits are in the wild" notice. -- bk From rdobbins at arbor.net Sat Jan 9 21:56:51 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 03:56:51 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001091933y2cda673djad3cc4dbb242b798@mail.gmail.com> References: <20100110030507.4CEFA2B2161@mx5.roble.com> <15DD90A7-A6DF-4489-AAA7-37A8E95270AA@arbor.net> <75cb24521001091933y2cda673djad3cc4dbb242b798@mail.gmail.com> Message-ID: On Jan 10, 2010, at 10:33 AM, Christopher Morrow wrote: > separate the portions of the pie... only let the attack break the minimal portion of your deployment. Use the right tool in the right place. An excellent point. A Web front-end server should be that - merely the front-end. Situationally-appropriate functional separation is a key architectural principle. Combine that with the measures outlined in , coupled with a functionally-separated, bulkheaded DNS infrastructure pictured in , and one will end up with a much more robust, scalable, and defensible system. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From virendra.rode at gmail.com Sat Jan 9 22:17:40 2010 From: virendra.rode at gmail.com (virendra rode) Date: Sat, 09 Jan 2010 20:17:40 -0800 Subject: qwest outage no notice In-Reply-To: References: <4B45B198.5040309@tiedyenetworks.com> <620fd17c1001090637m38ef2dc9r11d1399890157d72@mail.gmail.com> Message-ID: <4B4954E4.2000609@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Martin Hannigan wrote: > On Sat, Jan 9, 2010 at 9:37 AM, Paul Wall wrote: > >> On Thu, Jan 7, 2010 at 5:04 AM, Mike >> wrote: >>> We just had a qwest outage of about 2 mins at 1:41am pst. When I called >> to >>> report it I was told it was a 200+ emergency software upgrade due to a >>> security concern, and that we will get a notice later after the fact. >> That's not a maintenance, that's an outage. >> >> I hope everybody impacted on this list is claiming SLA. >> >> Drive Slow, much like the M40, >> Paul Wall >> > > > > SLA for what? < 2m of outage time related to an emergency maintenance event? > I don't think so. Most agreement language covers this kind of event. - --------------------- I think it comes down to disclosure policy. I cannot imagine qwest was the only provider who was hit by this emergency patch upgrade. I don't think general public is really keen in knowing the exact details of the vulnerabilities as much as getting some sort of heads up about emergency maintenance window which IMHO should have been issued. Given that I'm a staunch believer in openness when it comes down to outages related to critical infrastructure :-) regards, /virendra > > You'll be lucky if you can badger your account team into a free dinner > and/or some free beer for it. > > > -M< > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLSVTkpbZvCIJx1bcRAvX2AJsEmwKOBOs9Ynl8VaHTnS0SLP+SlACgykj3 nEmbjBDWmFj6XUI3k7Kv7fw= =yGz+ -----END PGP SIGNATURE----- From johnl at iecc.com Sat Jan 9 23:50:16 2010 From: johnl at iecc.com (John R. Levine) Date: 10 Jan 2010 00:50:16 -0500 Subject: more inane confidentiality notices, was he.net down/slow? In-Reply-To: References: <20100110010706.65601.qmail@simone.iecc.com> Message-ID: > The point is that rather than try to enforce agreements individually, > automatically slapping the notices on is not so unreasonable all > considered. > > While it may be annoying, its not baseless. It certaintly isn't > useless in discovery. Once again, I would be most interested in any statute or case law to support this claim. I've been involved in a lot of discovery in a lot of cases over the years, and I cannot remember a single instance where a boilerplate confidentiality notice was even noted, much less enforced. As I said: > In reality, boilerplate confidentiality notices merely document the fact > that a mail system is in the grip of the clueless and/or confused. R's, John From bill at herrin.us Sun Jan 10 00:12:44 2010 From: bill at herrin.us (William Herrin) Date: Sun, 10 Jan 2010 01:12:44 -0500 Subject: he.net down/slow? In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> Message-ID: <3c3e3fca1001092212p6385fa47wa60e53cf7b3d9308@mail.gmail.com> On Sat, Jan 9, 2010 at 6:27 PM, Martin Hannigan wrote: > Some NDA's require that you must state your intent for each > communication that should be covered by the NDA. ?As much as everyone > would like to believe these are wothless, they are not. Applying them > globally to your email ?protects your legal rights. It is also > innocous. Martin, Actually that's not a great idea. A notice that the recipient is expected to handle information with unusual attention to confidentiality is required by law to stand out so that there isn't any ambiguity about the duties demanded of the recipient. Trade secret cases have been lost because a sender relied on the email boilerplate, the recipient produced intentionally public emails with the same boilerplate, and the recipient asserted that he had no reason to believe the particular message was any more sensitive than the sender's routine public messages. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From harbor235 at gmail.com Sun Jan 10 00:22:29 2010 From: harbor235 at gmail.com (harbor235) Date: Sat, 9 Jan 2010 22:22:29 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> Message-ID: <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> > > Other security features in an Enterprise Class firewall; > > -Inside source based NAT, reinforces secure traffic flow by allowing > outside to inside flows based on > > configured translations and allowed security policies > > Terrible from an availability perspective, troubleshooting perspective, > too. Just dumb, dumb, dumb - NATed servers fall over at the drop of a hat > due to the NAT device choking. > >>>How is that possible with inside source NATing? You must mean a misconfigured >>> outside source NATing > > > -TCP sequence number randomization (to prevent TCP seq number > guessing) > > Server IP stack does this itself just fine. > >>> What server randomizes TCP sequence numbers? servers randomize initial >>> sequence numbers!, regardless, the FW will accept and randomize again making >>> sure the endpoints get the correct TCP seq numbers, again more secure > > -Intrusion Detection and Prevention (subset of most common signatures) > > recognize scanning attempts and mitigate > > recognize common attacks and mitigate > > Snake-oil. > >>> Preventing attacks on internal networks or servers, snake oil, LOL >>> FWs typically offer a subset of potential IDS signatures, dedicated appliances >>> or systems offer a higher level of prevention > > > -Deep packet inspection (application aware inspection for common > network services) > > Terrible from an availability perspective, snake-oil. > >>> Inspecting application header and data, it will identify/prevent some application >>>attacks? how does that reduce availability? > > > - Policy based tools for custom traffic classification and filtering > > Can be done statelessly, no firewall required. > >>> True, never said this was done statefully, what device are you using to perform >>>this function? >>>no firewall required, but part of distributed defense in depth strategy and can be >>>done by a firewall , again a secure architecture is the goal not just a firewall > > > -Layer 3 segmentation (creates inspection and enforcement points) > > Doesn't require a firewall. > >>> No, but segmentation and multiple security enforcements points are essential for >>> a secure architecture, > > > -Full/Partial Proxy services with authentication > > If needed, can be better handled by transparent reverse-proxy farms; auth > handled on the servers themselves. > >>>The servers are doing everything in your model, must be quite some servers, are >>>we talking firewalls in general of are we talking datacenter, all companies do not >>>have access to reverse-proxy farms > > > - Alarm/Logging capabilities providing info on potential attacks > > -etc ...... > > NetFlow from the network infrastructure, the OS/apps/services on the server > itself do this, etc. > >>> not the same thing , you will need to analyze the data, Netflow does not perform >>> data analysis, you will need to develop/buy something else for that > > > > > Statefull inspection further enhances the security capabilities of a > firewall. > > No, it doesn't, not in front of servers where there's no state to inspect, > in the first place, given that every incoming packet is unsolicited. > >>> every packet is not unsolicited, webserver to database request ? DB synch >>>between datacenters, administration, remote services, etc ,,, there is no state for >>>the services you are serving, true, but what about the rest of the network services >>>potentially available and their exploits? > > > You may choose not to use a firewall or implement a sound security > posture utilizing the "Defense in Depth" philosophy, however you chances of > being compromised are dramatically increased. > > Choosing not to make the mistake of putting a useless, counterproductive > firewall in front of a server doesn't mean one isn't employing a sound, > multi-faceted opsec strategy. > >>> didn't say it did, I stated several times that a secure architecture should be the >>>goal not just adding a FW, did you fail to read or respond to that part? > > I know that all the firewall propaganda denoted above is repeated > endlessly, ad nauseam, in the Confused Information Systems Security > Professional self-study comic books, but I've found that a bit of real-world > operational experience serves as a wonderful antidote, heh. > >>> Again, a firewall has it's place just like any other device in the network, defense in >>> depth is a prudent philosophy to reduce the chances of compromise, it does not >>>eliminate it nor does any architecture you can think of, period > > mike > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > From marquis at roble.com Sun Jan 10 00:27:27 2010 From: marquis at roble.com (Roger Marquis) Date: Sat, 9 Jan 2010 22:27:27 -0800 (PST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100109185802.Y41960@eboyr.pbz> References: <20100109185802.Y41960@eboyr.pbz> Message-ID: <20100110062727.0821E2B2163@mx5.roble.com> Dobbins, Roland wrote: >See here for a high-profile example: > Reads like a sales pitch to me. No apples to apples comparisons, nothing like an ANOVA of PPS, payload sizes, and other vectors across different types of border defenses. Your presentation makes a good case for Arbor-type defenses, against a certain type of attack, but it doesn't make the case you're referring to. What would convince me is an IXIA on a subnet with ten hosts running a db-bound LAMP stack. Plot the failure points under different loads. Then add an ASA or Netscreen and see what fails under the same loads. That would be an objective measure, unlike what has been offered as evidence in this thread so far. >Placing a stateful inspection device in a topological position where no >stateful inspection is possible due to every incoming packet being >unsolicited makes zero sense whatsoever from an architectural standpoint, >even without going into implementation-specific details. Which is basically claiming that the general purpose web server, running multiple applications, is more capable of inspecting every incoming packet than hardware specifically designed for the task and doing only the task it was designed for. Christopher Morrow wrote: >have you noticed how putting your DB and WEB server on the same hardware >is a bad plan? While often true this is entirely tangental to the thread. Roger Marquis From gbonser at seven.com Sun Jan 10 00:29:33 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 9 Jan 2010 22:29:33 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110020325.3918D2B2152@mx5.roble.com> References: <20100110020325.3918D2B2152@mx5.roble.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F71E1@RWC-EX1.corp.seven.com> > > Firewalls are not designed to mitigate large scale DDoS, Generally speaking, if it didn't being the firewall to its knees, it wasn't a DoS. It was just sort of an annoying attempt at a DoS. I think that more or less the definition of a DoS is one that exploits the resource limitations of the firewall to deny service to everything behind it. The ultimate DoS, though, is simply filling the pipe with traffic from "legitimate" data transfer requests. Nothing you are going to do is going to mitigate that because to stop it you have to DoS yourself. Imagine thousands of requests per second from all around the internet for a legitimate URL. How do you use a firewall to separate the wheat from the chaff? So let's say you have some client software that you want people to download. Suddenly you are getting more download requests than you can handle. Nobody is flooding you with syn or icmp packets. They are sending a single packet (a legitimate URL) that results in you sending thousands of packets to real IP addresses that are simply copying the traffic to what amounts to /dev/null. Now when your download server gets slow, things get worse because connections begin to take longer to clear. The kernel on the web server is able to handle the tcp/ip setup fairly quickly but getting the file actually shipped out takes time. As connections build up on the firewall, it finally reaches a point where it is out of RAM in storing all those NAT translations and connection state. Now you start noticing that services not under attack are starting to slow down because the firewall has to sort through an increasingly large connection table when doing stateful inspection of traffic going to other services. All the while, there really isn't anything the firewall can do to mitigate the traffic because it is all correct and "legitimate". Basically you are being Slashdotted or experiencing the Drudge Effect but in this case you are being botnetted. If you have the server capacity to keep up, now your outbound pipe to the Internet is filling up, you are dropping packets, TCP/IP connections begin to back off, connections back up even more and at some point the firewall just gives up by failing over to the secondary, which then promptly fails back to the primary and you bounce back and forth in that state for a while and then finally it just gets hung someplace and the whole thing is stuck. And during the entire incident there was no "illegal traffic" that your firewall could have done a thing to block. Oh, and rate limiting connections isn't going to fix things either unless you can do it on a per URL basis. Maybe the rate of requests for /really-big-file.tgz that clogs your system is way different than the rate of requests for /somewhat-smaller-file.tgz or /index.html From rdobbins at arbor.net Sun Jan 10 00:32:18 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 06:32:18 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> Message-ID: On Jan 10, 2010, at 1:22 PM, harbor235 wrote: > Again, a firewall has it's place just like any other device in the network, defense in >>> depth is a prudent philosophy to reduce the chances of compromise, it does not >>>eliminate it nor does any architecture you can think of, period What a ridiculous statement - of course it does. *The place of the stateful firewall is in front of clients, not servers*. I'm not going to continue the unequal contest of pitting real-world operational experience against Confused Information Systems Security Professional brainwashing. One can spout all the buzzwords and catchphrases one wishes, but at the end of the day, it's all dead wrong - and anyone naive enough to fall for it is setting himself up for a world of hurt. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From goemon at anime.net Sun Jan 10 00:44:15 2010 From: goemon at anime.net (goemon at anime.net) Date: Sat, 9 Jan 2010 22:44:15 -0800 (PST) Subject: he.net down/slow? In-Reply-To: <6eb799ab1001091905oa4f536esa19b9505b9e81412@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> <4B493428.6070904@bogus.com> <6eb799ab1001091905oa4f536esa19b9505b9e81412@mail.gmail.com> Message-ID: On Sat, 9 Jan 2010, James Hess wrote: > Spam filter your inbox on /CONFIDENTIALITY NOTICE.*intended > recipient.*destroy.*copies/si and be done with it. The > individual sender normally has no control over the matter, so their > only two choices are: (a) Post with the notice, or (b) Don't post at > all. senders who don't have control over the matter shouldn't be using such accounts to subscribe to public mailing lists like nanog. -Dan From rdobbins at arbor.net Sun Jan 10 00:45:50 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 06:45:50 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110062727.0821E2B2163@mx5.roble.com> References: <20100109185802.Y41960@eboyr.pbz> <20100110062727.0821E2B2163@mx5.roble.com> Message-ID: On Jan 10, 2010, at 1:27 PM, Roger Marquis wrote: > Reads like a sales pitch to me. My employer's products don't compete with firewalls, they *protect* them; if anything, it's in my pecuniary interest to *encourage* firewall deployments, so said firewalls will fall down and need protection, heh. Teaching people how to design their server farms, harden their network infrastructure, and deploy S/RTBH and flow-spec isn't selling anything. Only someone with ulterior motives would claim otherwise. This isn't 'selling' anything, either: So, this line of attack falls flat, and merely comes across as unjustified, uninformed, foolish and petty. > Your presentation makes a good case for Arbor-type defenses, against a certain type of attack, but it doesn't > make the case you're referring to. S/RTBH and flow-spec aren't 'Arbor-type defenses', and I had a long track record of making the case for all of these things for many years before I ever worked for Arbor. > > What would convince me is an IXIA on a subnet with ten hosts running a > db-bound LAMP stack. Plot the failure points under different loads. > Then add an ASA or Netscreen and see what fails under the same loads. Then hop to it. I did this kind of testing when I worked for the largest manufacturer of firewalls in the world, so I've no need to repeat it. > Which is basically claiming that the general purpose web server, running > multiple applications, is more capable of inspecting every incoming packet > than hardware specifically designed for the task and doing only the task > it was designed for. Properly tuned, yes. Here's the thing; you're simply mistaken, and you hurl insults instead of listening to the multiple people on this thread who have vastly more large-scale Internet experience than you do and who concur with these prescriptions. That's your prerogative; and it's my prerogative to grow tired repeating the same points which have already been made earlier in this and other threads, when they fall on biased, deaf ears. If you choose not to read and understand and learn from the broader experiences of others, that's up to you. I'm done. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Sun Jan 10 01:18:50 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 07:18:50 +0000 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> Message-ID: On Jan 10, 2010, at 1:32 PM, Dobbins, Roland wrote: > One can spout all the buzzwords and catchphrases one wishes, but at the end of the day, it's all dead wrong - and anyone naive enough to fall for it is setting himself up for a world of hurt. mike , You deserve a better response than this; I'm sorry for snapping, it just gets a bit wearying going over the same points over and over again. My apologies. Every point you raised has been discussed in detail previously on the two threads encompassing this topic (and previously on cisco-nsp, as well). If you go read through the threads, you'll find the answers to the questions you've asked. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From mysidia at gmail.com Sun Jan 10 02:48:54 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 10 Jan 2010 02:48:54 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <201001081648.o08Gm3WR069536@aurora.sol.net> References: <4B473178.7010100@kruchas.com> <201001081648.o08Gm3WR069536@aurora.sol.net> Message-ID: <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> On Fri, Jan 8, 2010 at 10:48 AM, Joe Greco wrote: > Putting a stateful firewall in front of that would be dumb; the server > is completely capable of coping with the superfluous SYN's in a much > more competent manner than the firewall. The trouble with blanket statements about "all stateful firewalls" and "all servers" is there are lots of different firewall and server platforms. Stateful firewalls can implement SYN cookies, and at least a couple do. Firewalls do not need to build a state entry for partial TCP sessions, there are a few different things that can be done, such as the firewall answering on behalf of the server (using SYN cookies) and negotiating connection with the server after the final ACK. As a result, spoofed TCP packets don't consume state. Multiple IPs they can _receive_ traffic to required, next? Spoofed UDP is a much bigger problem, because there is no connection establishment. And it's probably not sane to put certain public-facing UDP services such as large public DNS service IPs (e.g. 8.8.8.8) behind most forms of stateful filter. But that's not the average case, by any means, most servers are not DNS servers. Servers consume state just like firewalls do.... E.g. A public FTP server that opens a process for each connection, goes down in a connection flood, when kernel process slots are used up, long before the firewall. Servers running a robust OS completely and correctly configured to perfectly protect themsleves (resource limits, etc), no Windows OSes, with unwanted open ports, is a wholly unwarranted assumption for real-world server environments. In the best cases it does hold up (to a great extent). In other cases, it's an operational fantasy; it would be nice if that could be relied upon.... --- -J From rdobbins at arbor.net Sun Jan 10 04:45:47 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 10:45:47 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> References: <4B473178.7010100@kruchas.com> <201001081648.o08Gm3WR069536@aurora.sol.net> <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> Message-ID: <3807FC2F-85DF-4B7D-83B7-0A229239469A@arbor.net> On Jan 10, 2010, at 3:48 PM, James Hess wrote: > Firewalls do not need to build a state entry for > partial TCP sessions, there are a few different things that can be > done, such as the firewall answering on behalf of the server (using > SYN cookies) and negotiating connection with the server after the > final ACK. The firewall capacity for doing this can be easily overwhelmed; and again, well-formed traffic can simply 'crowd out' good traffic. The other drawbacks of the stateful firewall further outweigh even this negligible benefit. Fronting one's Web server farms/load-balancers with a tier of transparent reverse-proxy caches is a better way to scale TCP connection capacity, as well as the myriad other benefits offered (described earlier in this thread). ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From raymond at prolocation.net Sun Jan 10 06:32:51 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 10 Jan 2010 13:32:51 +0100 (CET) Subject: trying to analyze vispa isp outage In-Reply-To: References: Message-ID: Hi! > I have try to check BGP traffic behaviors related to recent VISPA ISP DDOS. > For this task I have using BGplay and I need feedback about my analysis. If > you are interested check > http://extraexploit.blogspot.com/2010/01/trying-to-analyze-vispa-isp-outage_08.html > > Thank you for your attention. Thats not too strange, UK ISP, small uplink line(s?), line full, router unable to send BGP updates. Gone! They dont have any direct peerings just a transit. I mean, any student in europe could map them off the card. With a gigabit @ home. I'll check with James (Vispa) if he has more info for you but the above applies i am afraid. Bye, Raymond. From jgreco at ns.sol.net Sun Jan 10 08:40:51 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jan 2010 08:40:51 -0600 (CST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110020325.3918D2B2152@mx5.roble.com> from "Roger Marquis" at Jan 09, 2010 06:03:25 PM Message-ID: <201001101440.o0AEepqD060436@aurora.sol.net> > Firewalls do a good job of protecting servers, when properly configured, > because they are designed exclusively for the task. Their CAM tables, > realtime ASICs and low latencies are very much unlike the CPU-driven, > interrupt-bound hardware and kernel-locking, multi-tasking software on a > typical web server. IME it is a rare firewall that doesn't fail long, > long after (that's after, not before) the hosts behind them would have > otherwise gone belly-up. Then you need to get rid of that '90's antique web server and get something modern. When you say "interrupt-bound hardware," all you are doing is showing that you're not familiar with modern servers and quality operating systems that are designed to mitigate things like DDoS attacks. "Stateful filtering" is to firewalls what "interrupt-based packet processing" is to web servers. Both are recipes for disaster. ... 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 jgreco at ns.sol.net Sun Jan 10 08:44:47 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jan 2010 08:44:47 -0600 (CST) Subject: he.net down/slow? In-Reply-To: <6eb799ab1001091905oa4f536esa19b9505b9e81412@mail.gmail.com> from "James Hess" at Jan 09, 2010 09:05:37 PM Message-ID: <201001101444.o0AEilnM060547@aurora.sol.net> > Spam filter your inbox on /CONFIDENTIALITY NOTICE.*intended > recipient.*destroy.*copies/si and be done with it. The > individual sender normally has no control over the matter, so their > only two choices are: (a) Post with the notice, or (b) Don't post at > all. Wow, are you implying that such readers are too stupid to do (c) get a Hotmail account for posting to mailing lists? ... 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 jgreco at ns.sol.net Sun Jan 10 08:54:09 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jan 2010 08:54:09 -0600 (CST) Subject: he.net down/slow? In-Reply-To: <3c3e3fca1001092212p6385fa47wa60e53cf7b3d9308@mail.gmail.com> from "William Herrin" at Jan 10, 2010 01:12:44 AM Message-ID: <201001101454.o0AEsAIi060816@aurora.sol.net> > Actually that's not a great idea. A notice that the recipient is > expected to handle information with unusual attention to > confidentiality is required by law to stand out so that there isn't > any ambiguity about the duties demanded of the recipient. Trade secret > cases have been lost because a sender relied on the email boilerplate, > the recipient produced intentionally public emails with the same > boilerplate, and the recipient asserted that he had no reason to > believe the particular message was any more sensitive than the > sender's routine public messages. The use of the words "intended recipient" are also extremely problematic; by definition, if it is addressed to me, I can be construed as being the "intended recipient." If I then turn around and forward it to you, you are now also an "intended recipient." Nice, eh. ... 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 marquis at roble.com Sun Jan 10 10:19:27 2010 From: marquis at roble.com (Roger Marquis) Date: Sun, 10 Jan 2010 08:19:27 -0800 (PST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <201001101440.o0AEepqD060436@aurora.sol.net> References: <201001101440.o0AEepqD060436@aurora.sol.net> Message-ID: <20100110161927.F281F2B2164@mx5.roble.com> > Then you need to get rid of that '90's antique web server and get > something modern. When you say "interrupt-bound hardware," all you > are doing is showing that you're not familiar with modern servers > and quality operating systems that are designed to mitigate things > like DDoS attacks. "Modern" servers? IP is processed in the kernel on web servers, regardless of OS. Have you configured a kernel lately? Noticed there are ~3,000 lines in the Linux config file alone? _Lots_ of device drivers in there, which are interrupt driven and have to be timeshared. No servers I know do realtime processing (RT kernels don't) or process IP in ASICs. What configurations of Linux / BSD / Solaris / etc does web / email / ntp / sip / iptables / ipfw / ... and doesn't have issues with kernel locking? Test it on your own servers by mounting a damaged DVD on the root directory, and dd'ing it to /dev/null. Notice how the ATA/SATA/SCSI driver impacts the latency of everything on the system. How would you replicate that on a firmware and ASIC drive appliance? Roger Marquis From marquis at roble.com Sun Jan 10 10:55:13 2010 From: marquis at roble.com (Roger Marquis) Date: Sun, 10 Jan 2010 08:55:13 -0800 (PST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110080202.L32677@eboyr.pbz> References: <201001101440.o0AEepqD060436@aurora.sol.net> <20100110080202.L32677@eboyr.pbz> Message-ID: <20100110165513.B733A2B2152@mx5.roble.com> Dobbins, Roland wrote: >My employer's products don't compete with firewalls, they *protect* them; >if anything, it's in my pecuniary interest to *encourage* firewall >deployments, so said firewalls will fall down and need protection, heh. Nobody's disputing that Roland, or the fact that different specialized appliances will protect against different perimeter attacks. The only thing you've said that is being disputed is the the claim that a firewall under a DDoS type of attack will fail before a server under the same type of attack. I question this claim for several reasons. * because it doesn't correlate with my 22 years of experience in systems administration and 14 years in netops (including Yahoo netsecops where I did use IXIAs to compile stats on FreeBSD and Linux packet filtering), * it doesn't correlate with experience in large networks with multiple geographically disperse data centers where we did use Arbor, Cisco and Juniper equipment, * it doesn't correlate with server and firewall hardware and software designs, and last but not least, * because you have shown no objective evidence to support the claim. > I did this kind of testing when I worked for the largest > manufacturer of firewalls in the world Where then, can we find the results of your testing? > Here's the thing; you're simply mistaken, and you hurl insults > instead of listening to the multiple people on this > thread who have vastly more large-scale Internet experience than > you do and who concur with these prescriptions. Nobody has "hurled insults" in this thread other than yourself Roland. Shame on you for such disreputable tactics. To make the case you need more than repeated dismissal of requests for evidence and repeated unsupported claims of "vast experience" with failing servers and firewalls. We just need some actual statistics. Roger Marquis From jgreco at ns.sol.net Sun Jan 10 11:09:48 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jan 2010 11:09:48 -0600 (CST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110161927.F281F2B2164@mx5.roble.com> from "Roger Marquis" at Jan 10, 2010 08:19:27 AM Message-ID: <201001101709.o0AH9nT2064919@aurora.sol.net> > > Then you need to get rid of that '90's antique web server and get > > something modern. When you say "interrupt-bound hardware," all you > > are doing is showing that you're not familiar with modern servers > > and quality operating systems that are designed to mitigate things > > like DDoS attacks. > > "Modern" servers? IP is processed in the kernel on web servers, > regardless of OS. Have you configured a kernel lately? Yes, pretty much every time I install a server. > Noticed there > are ~3,000 lines in the Linux config file alone? Well, that explains a lot. % wc -l /sys/i386/conf/WEBX4 324 /sys/i386/conf/WEBX4 I probably haven't noticed that there are ~3,000 lines in the Linux config file alone because I use a different OS; ~3,000 lines of config would just be another example of why I generally consider Linux to be a little broken. I can see why admins would be hesitant to challenge such a thing. > _Lots_ of device > drivers in there, which are interrupt driven and have to be timeshared. > No servers I know do realtime processing (RT kernels don't) or process IP > in ASICs. Roger, meet FreeBSD. FreeBSD, meet Roger. FreeBSD, would you please show Roger how IP is handled without excessive interrupts? % systat -vm (snipped from larger display) Interrupts 2208 total stray irq7 mux irq9 em5 irq5 85 ata0 irq14 mux irq11 fdc0 irq6 atkbd0 irq sio0 irq4 1995 clk irq0 128 rtc irq8 % netstat 1 input (Total) output packets errs bytes packets errs bytes colls 58991 0 54547321 58975 0 54523849 0 59492 0 58297208 59475 0 58388027 0 65828 0 62105928 65856 0 62081922 0 60257 0 56781863 60219 0 56809674 0 62547 0 61254034 62583 0 61231514 0 58188 9 55536734 58103 0 55560822 0 73870 0 70245952 73959 0 70223249 0 61436 0 58766122 61429 0 58786292 0 61390 0 59050710 61336 0 59029298 0 61447 0 58701312 61502 0 58725356 0 63934 0 60801413 63932 0 60777621 0 60187 0 56724030 60189 0 56751946 0 60247 0 55544082 60036 0 55522162 0 66472 0 63061572 66635 0 63033232 0 66415 0 62876955 66438 0 62854488 0 66612 0 63270235 66355 0 63335538 0 66020 0 60478426 66293 0 60454874 0 67696 0 63512069 67692 0 63534500 0 66342 0 60462142 66353 0 60439239 0 That's 60Kpps being handled with 2K interrupts per second. It'll be 2K interrupts per second at 0pps or 200Kpps or whatever. % ipfw l | wc -l 620 It's doing nontrivial amounts of firewalling while doing this. % top last pid: 83148; load averages: 0.31, 0.28, 0.23 up 459+08:00:24 12:00:33 51 processes: 3 running, 42 sleeping, 6 stopped CPU states: 14.8% user, 0.0% nice, 19.1% system, 13.3% interrupt, 52.7% idle % cat /var/run/dmesg.boot [...] CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2994.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff [...] Ewww, but it *is* a 2004-vintage Pentium Prescott CPU on a legacy PCI mobo, so it is actually a little disadvantaged compared to modern hardware. > What configurations of Linux / BSD / Solaris / etc does web / email / ntp > / sip / iptables / ipfw / ... and doesn't have issues with kernel > locking? That's like saying "what cars cannot be crashed into a wall." A much better question is "what combination of driver and vehicle can I get that significantly reduces the chances of my being involved in a crash." Driver is important because even the best vehicle can be driven into a wall; vehicle is important because even the best driver is severely limited by a decrepit old car. It's when you get a great driver in a great vehicle that you get the good results. > Test it on your own servers by mounting a damaged DVD on the > root directory, and dd'ing it to /dev/null. Notice how the ATA/SATA/SCSI > driver impacts the latency of everything on the system. As soon as a remote attacker is able to insert a damaged DVD into one of my servers (maybe via specially crafted IP options in a TCP packet?), you will witness my posterior emit a large number of blocks of ceramic material (used in masonry construction). Until then, I am unfazed by this because it isn't particularly relevant to the discussion. I can cause excessive latency simply by switching off gear too. I *strongly* suggest you go and look over http://info.iet.unipi.it/~luigi/polling/ /and note its date/ before you compose any reply; device polling has been around for a *long* time and its usefulness as a DDoS mitigator in the server arena is hard to refute. ... 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 mhernand1 at comcast.net Sun Jan 10 11:15:11 2010 From: mhernand1 at comcast.net (Manolo Hernandez) Date: Sun, 10 Jan 2010 17:15:11 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110165513.B733A2B2152@mx5.roble.com> References: <201001101440.o0AEepqD060436@aurora.sol.net><20100110080202.L32677@eboyr.pbz><20100110165513.B733A2B2152@mx5.roble.com> Message-ID: <799286984-1263143696-cardhu_decombobulator_blackberry.rim.net-235854868-@bda215.bisx.prod.on.blackberry> From someone who mostly lerks but has been in network engineering operations biz for 17 years, the only OS that seems to always keel over under a ddos and need a firewall is windows. Linux in its current incarnation can handle a substantially larger attack before needing mitigation by firewall type device. So in the end I believe its the environment dictates the use of products unless you have aformentioned windows os which for me has always necessitated a firewall. Manolo Sent from my BlackBerry -----Original Message----- From: Roger Marquis Date: Sun, 10 Jan 2010 08:55:13 To: Subject: Re: D/DoS mitigation hardware/software needed. Dobbins, Roland wrote: >My employer's products don't compete with firewalls, they *protect* them; >if anything, it's in my pecuniary interest to *encourage* firewall >deployments, so said firewalls will fall down and need protection, heh. Nobody's disputing that Roland, or the fact that different specialized appliances will protect against different perimeter attacks. The only thing you've said that is being disputed is the the claim that a firewall under a DDoS type of attack will fail before a server under the same type of attack. I question this claim for several reasons. * because it doesn't correlate with my 22 years of experience in systems administration and 14 years in netops (including Yahoo netsecops where I did use IXIAs to compile stats on FreeBSD and Linux packet filtering), * it doesn't correlate with experience in large networks with multiple geographically disperse data centers where we did use Arbor, Cisco and Juniper equipment, * it doesn't correlate with server and firewall hardware and software designs, and last but not least, * because you have shown no objective evidence to support the claim. > I did this kind of testing when I worked for the largest > manufacturer of firewalls in the world Where then, can we find the results of your testing? > Here's the thing; you're simply mistaken, and you hurl insults > instead of listening to the multiple people on this > thread who have vastly more large-scale Internet experience than > you do and who concur with these prescriptions. Nobody has "hurled insults" in this thread other than yourself Roland. Shame on you for such disreputable tactics. To make the case you need more than repeated dismissal of requests for evidence and repeated unsupported claims of "vast experience" with failing servers and firewalls. We just need some actual statistics. Roger Marquis From Valdis.Kletnieks at vt.edu Sun Jan 10 11:25:59 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 10 Jan 2010 12:25:59 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: Your message of "Sun, 10 Jan 2010 08:19:27 PST." <20100110161927.F281F2B2164@mx5.roble.com> References: <201001101440.o0AEepqD060436@aurora.sol.net> <20100110161927.F281F2B2164@mx5.roble.com> Message-ID: <1176.1263144359@localhost> On Sun, 10 Jan 2010 08:19:27 PST, Roger Marquis said: > > Then you need to get rid of that '90's antique web server and get > > something modern. When you say "interrupt-bound hardware," all you > > are doing is showing that you're not familiar with modern servers > > and quality operating systems that are designed to mitigate things > > like DDoS attacks. > > "Modern" servers? IP is processed in the kernel on web servers, > regardless of OS. Have you configured a kernel lately? Noticed there > are ~3,000 lines in the Linux config file alone? _Lots_ of device > drivers in there, which are interrupt driven and have to be timeshared. Yes, but all the fast network adapters are able to do a lot of stuff like interrupt coalescing so you don't need to take an interrupt on every packet. And "have you configured a kernel lately" is another red herring - yes, there are indeed be 4,533 lines in the current Fedora .config. But that's because that config turns on everything under the sun. I just checked, and my current kernel config has only 960 '=y' lines, and another 220 '=m' lines - and a large portion of those could easily be turned off. I have a minimal config file that comes in under 730 non-comment lines. > No servers I know do realtime processing (RT kernels don't) or process IP > in ASICs. That's because in general, processing the IP in an ASIC simply Does Not Work as well as you might hope. Alan Cox did a nice discussion of some of the issues here: http://lkml.indiana.edu/hypermail/linux/kernel/0307.1/2116.html One should read his last paragraph carefully, and note that what he wrote back in 2003 is still true today: http://www.internet2.edu/lsr/history.html > What configurations of Linux / BSD / Solaris / etc does web / email / ntp > / sip / iptables / ipfw / ... and doesn't have issues with kernel > locking? So let me get this straight - you perceive a problem with locking inside the kernel, where if you're lucky the lock is in an already-hot cache line and your biggest worry is cache line ping-ponging, and if you're unlucky you actually have to go out the southbridge and hit main memory, at main memory access speeds. And to fix this, you're going to move one of the things contending for the lock off the CPU, so now every time the lock is contended, it has to go out through the PCI bridge to an external card? How the heck is that supposed to help? You're suggesting the same "go talk to another card" solution that the router vendors learned is the *last* thing you want to do - calling out to the supervisor card rather than handling it onboard the line card is guaranteed performance death. > Test it on your own servers by mounting a damaged DVD on the > root directory, and dd'ing it to /dev/null. Notice how the ATA/SATA/SCSI > driver impacts the latency of everything on the system. How would you > replicate that on a firmware and ASIC drive appliance? There's two little things you went astray on here: 1) I've in fact had to do this while doing data recovery. It doesn't do squat to the latency of anything that doesn't have to go through the same controller as the DVD. Everything else works just fine. Heck, it isn't even enough to cause audio playback skips (and those are noticeable even at the millisecond level). 2) Your latency hit is because the controller is *busy* while trying to re-read and error-correct a bad block. So yeah - trying to do I/O through a controller that's taking a several-second time-out dealing with bad media will cause a latency hit *for that I/O*. What's your point? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sun Jan 10 11:26:33 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 10 Jan 2010 12:26:33 -0500 Subject: he.net down/slow? In-Reply-To: Your message of "Sun, 10 Jan 2010 08:54:09 CST." <201001101454.o0AEsAIi060816@aurora.sol.net> References: <201001101454.o0AEsAIi060816@aurora.sol.net> Message-ID: <1195.1263144393@localhost> On Sun, 10 Jan 2010 08:54:09 CST, Joe Greco said: > The use of the words "intended recipient" are also extremely problematic; > by definition, if it is addressed to me, I can be construed as being the > "intended recipient." If I then turn around and forward it to you, you > are now also an "intended recipient." Nice, eh. They're trying to make their mistaken use of "reply all" our problem rather than theirs. Or selecting the wrong 'J. Smith' from their contacts list. Or any number of other dumb-ass moves we've all seen. Unfortunately, there's no good a priori way for the recipient to know that the sender has committed a major faux pax, except by actually reading the content. Of particular interest - what happens if they've botched their intended recipient, and as a result the mail bounced into my Postmaster mailbox? At that point, I'm pretty obviously *not* the intended recipient, and the sending individual better be ready to pay for the service they've actually requested in their boilerplate. I mean, I'd hate to incur costs complying with their wishes and then have to sue them to recover said costs... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Sun Jan 10 11:47:24 2010 From: bill at herrin.us (William Herrin) Date: Sun, 10 Jan 2010 12:47:24 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> References: <4B473178.7010100@kruchas.com> <201001081648.o08Gm3WR069536@aurora.sol.net> <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> Message-ID: <3c3e3fca1001100947i43482aacq1d70d78dbfbbf531@mail.gmail.com> On Sun, Jan 10, 2010 at 3:48 AM, James Hess wrote: >?there are a few different ?things that can be > done, ?such as ?the firewall answering on behalf of the server (using > SYN cookies) and negotiating connection with the server after the > final ACK. James, That's called a proxy or sometimes an application-layer gateway. The problem with proxies, aside from the extra computing overhead, is that they radically change the failure semantics of a TCP connection. The sender believes itself connected and has transferred the first window worth of data (which may be all the data he needs to transmit) while the firewall is still trying to connect to the recipient. Often the proxy isn't clever enough to send an RST in stead of a FIN so the remote application thinks it has a successful finish. Even if it does send an RST, most application developers aren't well enough versed in sockets programming to block on the shutdown and check the success status, and even if they do they may report a different error than the basic "failed to connect." Proxies can be a useful tool but they should be used with caution and only when you're absolutely sure that the difference in TCP failure semantics is not important to the protocol you're proxying. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sun Jan 10 11:54:24 2010 From: bill at herrin.us (William Herrin) Date: Sun, 10 Jan 2010 12:54:24 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <3c3e3fca1001100947i43482aacq1d70d78dbfbbf531@mail.gmail.com> References: <4B473178.7010100@kruchas.com> <201001081648.o08Gm3WR069536@aurora.sol.net> <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> <3c3e3fca1001100947i43482aacq1d70d78dbfbbf531@mail.gmail.com> Message-ID: <3c3e3fca1001100954g3c4216e3y3391035cc449ff59@mail.gmail.com> On Sun, Jan 10, 2010 at 12:47 PM, William Herrin wrote: > Even if it does > send an RST, most application developers aren't well enough versed in > sockets programming to block on the shutdown and check the success > status, Sorry, I got that wrong. shutdown() will succeed without waiting for a FIN or RST from the remote end. So will close(). Instead, after the shutdown() you then have to block on read() waiting for a either 0 bytes read or an error. 0 bytes = FIN, error = RST. Unfortunately, few sockets programmers realize that they have to do this to catch that final possible error. They send what the expect to send and if they don't expect to receive anything back, they shutdown and close the socket without waiting. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcdill.lists at gmail.com Sun Jan 10 12:14:52 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 10 Jan 2010 10:14:52 -0800 Subject: he.net down/slow? In-Reply-To: <201001101444.o0AEilnM060547@aurora.sol.net> References: <201001101444.o0AEilnM060547@aurora.sol.net> Message-ID: <4B4A191C.3090905@gmail.com> Joe Greco wrote: >> Spam filter your inbox on /CONFIDENTIALITY NOTICE.*intended >> recipient.*destroy.*copies/si and be done with it. The >> individual sender normally has no control over the matter, so their >> only two choices are: (a) Post with the notice, or (b) Don't post at >> all. >> > > Wow, are you implying that such readers are too stupid to do (c) get a > Hotmail account for posting to mailing lists? Some of these confidentiality/security paranoid companies have firewalls that prevent employees from accessing off-company communication services[1], to prevent employees from using those services to leak confidential information. However, if you work at one of those companies, and don't have the skills or means to bypass the firewall, perhaps you should avoid posting to nanog from work for anything other than to receive help from your fellow netops during emergencies. jc [1] Blocking webmail websites, blocking IM and email ports to off-company IPs, etc. From jgreco at ns.sol.net Sun Jan 10 13:56:13 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jan 2010 13:56:13 -0600 (CST) Subject: I don't need no stinking firewall! In-Reply-To: <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> from "James Hess" at Jan 10, 2010 02:48:54 AM Message-ID: <201001101956.o0AJuELY073059@aurora.sol.net> > On Fri, Jan 8, 2010 at 10:48 AM, Joe Greco wrote: > > Putting a stateful firewall in front of that would be dumb; the server > > is completely capable of coping with the superfluous SYN's in a much > > more competent manner than the firewall. > > The trouble with blanket statements about "all stateful firewalls" and > "all servers" is there are lots of different firewall and server > platforms. Yes, yes there are, but only an idiot buys a Ford Pinto to haul pallets of freight. When you get serious about hauling lots of freight, you buy something appropriate, and there are suddenly a lot fewer combinations. > Stateful firewalls can implement SYN cookies, and at least > a couple do. Firewalls do not need to build a state entry for > partial TCP sessions, there are a few different things that can be > done, such as the firewall answering on behalf of the server (using > SYN cookies) and negotiating connection with the server after the > final ACK. And how much of that is done in silicon? Because if it's not in silicon, then it's being done by a CPU, and if it's being done by a CPU, why not just let the server do it? Commodity server hardware is cheap compared to specialized silicon offerings... > As a result, spoofed TCP packets don't consume state. Multiple IPs > they can _receive_ traffic to required, next? > > Spoofed UDP is a much bigger problem, because there is no connection > establishment. And it's probably not sane to put certain > public-facing UDP services such as large public DNS service IPs > (e.g. 8.8.8.8) behind most forms of stateful filter. > > But that's not the average case, by any means, most servers are not > DNS servers. > Servers consume state just like firewalls do.... > > E.g. A public FTP server that opens a process for each connection, > goes down in a connection flood, when kernel process slots are used > up, long before the firewall. Again, Ford Pinto... you can always design a system that will fail. That's like shooting fish in a barrel. If you're worried about kernel process slots, you *choose* an appropriate service. Like a threaded ftp server. > Servers running a robust OS completely and correctly configured to > perfectly protect themsleves (resource limits, etc), no Windows > OSes, with unwanted open ports, is a wholly unwarranted assumption > for real-world server environments. And so is a high-performance non-crashable stateful firewall that's so talented that it can keep a poorly configured server operational under all circumstances. Wheee. > In the best cases it does hold up (to a great extent). > In other cases, it's an operational fantasy; it would be nice if that > could be relied upon.... Some of us are still failing to understand why it is that it's better to buy an extremely expensive stateful firewall device which is likely to collapse under load because the salesman lied; it seems like it'd be easier to go and scale capacity with some cheap stateless firewalls to do packet filtering in silicon, backended by some additional servers and some good admins who have a clue about what they're doing. ... 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 jgreco at ns.sol.net Sun Jan 10 14:01:21 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jan 2010 14:01:21 -0600 (CST) Subject: he.net down/slow? In-Reply-To: <1195.1263144393@localhost> from "Valdis.Kletnieks@vt.edu" at Jan 10, 2010 12:26:33 PM Message-ID: <201001102001.o0AK1LpW073251@aurora.sol.net> > On Sun, 10 Jan 2010 08:54:09 CST, Joe Greco said: > > The use of the words "intended recipient" are also extremely problematic; > > by definition, if it is addressed to me, I can be construed as being the > > "intended recipient." If I then turn around and forward it to you, you > > are now also an "intended recipient." Nice, eh. > > They're trying to make their mistaken use of "reply all" our problem rather > than theirs. Or selecting the wrong 'J. Smith' from their contacts list. > Or any number of other dumb-ass moves we've all seen. Unfortunately, there's > no good a priori way for the recipient to know that the sender has committed > a major faux pax, except by actually reading the content. People send me all kinds of stuff I've absolutely no interest in all the time. I have no idea how I'd tell the difference between "sender was too lazy/dumb to figure out I would have no interest but sent it anyways" and "sender mistakenly sent it to me." > Of particular interest - what happens if they've botched their intended > recipient, and as a result the mail bounced into my Postmaster mailbox? > At that point, I'm pretty obviously *not* the intended recipient, and the > sending individual better be ready to pay for the service they've actually > requested in their boilerplate. I mean, I'd hate to incur costs complying > with their wishes and then have to sue them to recover said costs... Yes, that's a problem too. Perhaps this simply needs to happen. ... 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 mysidia at gmail.com Sun Jan 10 15:55:39 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 10 Jan 2010 15:55:39 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <3c3e3fca1001100947i43482aacq1d70d78dbfbbf531@mail.gmail.com> References: <4B473178.7010100@kruchas.com> <201001081648.o08Gm3WR069536@aurora.sol.net> <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> <3c3e3fca1001100947i43482aacq1d70d78dbfbbf531@mail.gmail.com> Message-ID: <6eb799ab1001101355n41a54dd4hef14b7ec2ece67aa@mail.gmail.com> On Sun, Jan 10, 2010 at 11:47 AM, William Herrin wrote: > On Sun, Jan 10, 2010 at 3:48 AM, James Hess wrote: >>?there are a few different ?things that can be >> done, ?such as ?the firewall answering on behalf of the server (using >> SYN cookies) and negotiating connection with the server after the >> final ACK. > That's called a proxy or sometimes an application-layer gateway. The I'm not really referring to ALGs, but to Layer 3 proxies, that are application-agnostic -- simply manipulate the connection setup, and then step 'out of the way' performing only mechanical translation of SEQ numbers / port numbers. However, appliction layer gateways are still stateful firewalls. Content switches and load balancers that track connections and allow access control are also stateful firewalls. They are widely used, for many different kinds of applications. > they radically change the failure semantics of a TCP connection. The > sender believes itself connected and has transferred the first window > worth of data (which may be all the data he needs to transmit) while And if the initial window size is 0? > send an RST, most application developers aren't well enough versed in > sockets programming to block on the shutdown and check the success > status, and even if they do they may report a different error than the > basic "failed to connect." I agree that could be an issue. The proxy might do the wrong thing, the application might do the wrong thing. > Proxies can be a useful tool but they should be used with caution and I agree they should be used with caution. I don't agree with "You never need a proxy in front of a server, it's only there to fail". -- -J From rdobbins at arbor.net Sun Jan 10 15:56:38 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 21:56:38 +0000 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <20100110165513.B733A2B2152@mx5.roble.com> References: <201001101440.o0AEepqD060436@aurora.sol.net> <20100110080202.L32677@eboyr.pbz> <20100110165513.B733A2B2152@mx5.roble.com> Message-ID: <168539BC-F0B1-4330-9E82-D3B4357E0D58@arbor.net> On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote: > The only thing you've said that is being disputed is the the claim that a firewall > under a DDoS type of attack will fail before a server under the same type > of attack. It's so obvious that well-crafted programmatically-generated attack traffic, if nothing else, will crowd out the good traffic that I'm just dumbfounded anyone thinks 'proof' of this is needed. Same thing for the fact that horizontally-scaled Web farm (with or without reverse caching proxies) will of necessity handle a great deal more TCP state than the biggest, firewall made to date. > * because it doesn't correlate with my 22 years of experience in systems > administration and 14 years in netops (including Yahoo netsecops where I > did use IXIAs to compile stats on FreeBSD and Linux packet filtering), It doesn't correlate with my 25 years in the industry, a good portion of the last 15 years spent handling DDoS after DDoS after DDoS, during which the biggest, baddest firewalls choked and died over and over again, through multiple generations of said firewalls. Again, I was able to take down a hardware-based (for whatever value of 'hardware-based' is possible) firewall rated at 2gb/sec with 80kpps of traffic. > * it doesn't correlate with experience in large networks with multiple geographically disperse data centers where we did use Arbor, Cisco and Juniper equipment, It correlates with my experience in large networks with geographically-dispersed IDCs with heterogeneous gear. > * it doesn't correlate with server and firewall hardware and software designs, and last but not least, Which is a non-sequitur. > * because you have shown no objective evidence to support the claim. I've my own broad subjective experience, and that of several other people who've commented on this thread have similar experiences. Since you haven't yet acquired this subjective experience, you can cause it to happen in a controlled test environment, should you so choose. > Where then, can we find the results of your testing? The testing I did when I worked for the vendor in question is proprietary, as you can well surmise. You're free to do your own testing and confirm these assertions for yourself. > Nobody has "hurled insults" in this thread other than yourself Roland. You accused me of acting in my own pecuniary interest, of trying to 'sell' things, *for no reason at all*. > We just need some actual statistics. If you actually care about the truth of the matter, you're free to generate your own. If you read the RoK/USA DDoS preso to which I linked, you see the attack throughput and bandwidth metrics/host, and you also see where I noted multiple 'Web Application Firewalls', load-balancers, and so-called 'IPS' falling over as a result of those attacks. That gives you a range right there, along with some attack traffic characteristics, including average packet size. It makes no sense to put a stateful inspection device in front of servers, where *every single packet* is unsolicited, and therefore no state tracking is even possible in the first place. Stateless filters in hardware capable of mpps do a much better job, without the risk of falling over due to state-table exhaustion. Folks who've been unlucky enough to be subjected to significant DDoS attacks have run into this issue again and again and again. Perhaps you've simply been lucky; but one can't count on one's luck holding forever. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Sun Jan 10 15:58:39 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Jan 2010 21:58:39 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <6eb799ab1001101355n41a54dd4hef14b7ec2ece67aa@mail.gmail.com> References: <4B473178.7010100@kruchas.com> <201001081648.o08Gm3WR069536@aurora.sol.net> <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com> <3c3e3fca1001100947i43482aacq1d70d78dbfbbf531@mail.gmail.com> <6eb799ab1001101355n41a54dd4hef14b7ec2ece67aa@mail.gmail.com> Message-ID: On Jan 11, 2010, at 4:55 AM, James Hess wrote: > I don't agree with "You never need a proxy in front of a server, it's only there to fail". Again, reverse proxy *caches* are extremely useful in front of Web farms. Pure proxying makes no sense. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From oberman at es.net Sun Jan 10 17:13:12 2010 From: oberman at es.net (Kevin Oberman) Date: Sun, 10 Jan 2010 15:13:12 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: Your message of "Sun, 10 Jan 2010 21:56:38 GMT." <168539BC-F0B1-4330-9E82-D3B4357E0D58@arbor.net> Message-ID: <20100110231312.644291CC09@ptavv.es.net> > From: "Dobbins, Roland" > Date: Sun, 10 Jan 2010 21:56:38 +0000 > > On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote: > > > The only thing you've said that is being disputed is the the claim > > that a firewall under a DDoS type of attack will fail before a > > server under the same type > of attack. > > It's so obvious that well-crafted programmatically-generated attack > traffic, if nothing else, will crowd out the good traffic that I'm > just dumbfounded anyone thinks 'proof' of this is needed. Same thing > for the fact that horizontally-scaled Web farm (with or without > reverse caching proxies) will of necessity handle a great deal more > TCP state than the biggest, firewall made to date. > > > * because it doesn't correlate with my 22 years of experience in systems > > administration and 14 years in netops (including Yahoo netsecops where I > > did use IXIAs to compile stats on FreeBSD and Linux packet filtering), > > It doesn't correlate with my 25 years in the industry, a good portion > of the last 15 years spent handling DDoS after DDoS after DDoS, during > which the biggest, baddest firewalls choked and died over and over > again, through multiple generations of said firewalls. > > Again, I was able to take down a hardware-based (for whatever value of > 'hardware-based' is possible) firewall rated at 2gb/sec with 80kpps of > traffic. > > > * it doesn't correlate with experience in large networks with > > multiple geographically disperse data centers where we did use Arbor, > > Cisco and Juniper equipment, > > It correlates with my experience in large networks with > geographically-dispersed IDCs with heterogeneous gear. > > > * it doesn't correlate with server and firewall hardware and > > software designs, and last but not least, > > Which is a non-sequitur. > > > * because you have shown no objective evidence to support the claim. > > I've my own broad subjective experience, and that of several other > people who've commented on this thread have similar experiences. > Since you haven't yet acquired this subjective experience, you can > cause it to happen in a controlled test environment, should you so > choose. > > > Where then, can we find the results of your testing? > > The testing I did when I worked for the vendor in question is > proprietary, as you can well surmise. You're free to do your own > testing and confirm these assertions for yourself. > > > Nobody has "hurled insults" in this thread other than yourself Roland. > > You accused me of acting in my own pecuniary interest, of trying to > 'sell' things, *for no reason at all*. > > > We just need some actual statistics. > > If you actually care about the truth of the matter, you're free to > generate your own. If you read the RoK/USA DDoS preso to which I > linked, you see the attack throughput and bandwidth metrics/host, and > you also see where I noted multiple 'Web Application Firewalls', > load-balancers, and so-called 'IPS' falling over as a result of those > attacks. That gives you a range right there, along with some attack > traffic characteristics, including average packet size. > > It makes no sense to put a stateful inspection device in front of > servers, where *every single packet* is unsolicited, and therefore no > state tracking is even possible in the first place. Stateless filters > in hardware capable of mpps do a much better job, without the risk of > falling over due to state-table exhaustion. > > Folks who've been unlucky enough to be subjected to significant DDoS > attacks have run into this issue again and again and again. Perhaps > you've simply been lucky; but one can't count on one's luck holding > forever. There is a culture that has developed a dogma that firewalls are THE solution. Be it DDOS or most any other security threat. Like many dogmas, it is ingrained into so many people that denial is essentially heresy. People simply "know" that a firewall is essential, so any contrary argument is obviously bogus or confused and must be denied. I used to work at the place that probably invented the stateful firewall and the folks who invented it became the priests of the firewall dogma and went forth and preached its value. Note that this predates DDOS by many years and that they did have some valid arguments. But the result was an army of security "experts" who scowled and marked the audit as "FAILED" if you did not front EVERYTHING with a firewall. I know of one case where an organization bought a firewall and programmed it to pass everything, just to fix an automatic failure of a security audit. Oddly, the auditor did not even look at who the firewall was configured. Simple presence of the box made him happy. I'm afraid that you are fighting a dogma that will only slowly be beaten into recognizing reality, but I appreciate your fighting the good fight. -- 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 From mksmith at adhost.com Sun Jan 10 19:03:11 2010 From: mksmith at adhost.com (Michael K. Smith) Date: Sun, 10 Jan 2010 17:03:11 -0800 Subject: I don't need no stinking firewall! In-Reply-To: Message-ID: On 1/9/10 10:32 PM, "Dobbins, Roland" wrote: > > On Jan 10, 2010, at 1:22 PM, harbor235 wrote: > >> Again, a firewall has it's place just like any other device in the network, >> defense in >>> depth is a prudent philosophy to reduce the chances of >> compromise, it does not >>>eliminate it nor does any architecture you can >> think of, period > > What a ridiculous statement - of course it does. > > *The place of the stateful firewall is in front of clients, not servers*. > > I'm not going to continue the unequal contest of pitting real-world > operational experience against Confused Information Systems Security > Professional brainwashing. One can spout all the buzzwords and catchphrases > one wishes, but at the end of the day, it's all dead wrong - and anyone naive > enough to fall for it is setting himself up for a world of hurt. > I certainly understand and agree with your position, in most cases, but there are some instances when a firewall serves an excellent purpose. As an example, we manage hundreds of heterogeneous servers where customers also have administrative access to the devices. As such, we can never be sure they haven't changed something that can negatively impact the security of the server or servers. However, since the firewall is a magic box ? they don't want anything to do with it. This means that I can keep a server fairly secure from extraneous cruft and have a demarcation point into and out of the customer's environment that I control. I understand this does nothing for SQL injection, XSS, and other application-layer mischief, but it does wonders for keeping all the other stuff blocked, even when an customer "admin" says "why do I need Windows Firewall?" I wish I had a perfect world where I had a homogenous server environment that I controlled all the way through the stack with only one Management Layer to deal with. But, I'm glad I don't because these customers pay my salary. Regards, Mike From gbonser at seven.com Sun Jan 10 19:40:01 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 10 Jan 2010 17:40:01 -0800 Subject: I don't need no stinking firewall! In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> > I certainly understand and agree with your position, in most cases, but > there are some instances when a firewall serves an excellent purpose. > As an > example, we manage hundreds of heterogeneous servers where customers > also > have administrative access to the devices. As such, we can never be > sure > they haven't changed something that can negatively impact the security > of > the server or servers. Firewalls do have a purpose and I don't think anyone disputes that. I certainly have firewalls in my network. What I believe the argument here is about is which kinds of traffic does one use a firewall for and which kinds of traffic are best left to other devices to handle access control/management. And I don't believe anyone is necessarily advocating exposing individual servers directly to the internet either. There are other devices that can handle isolation of the servers and protect them against such things as syn floods. From randy at psg.com Sun Jan 10 19:48:17 2010 From: randy at psg.com (Randy Bush) Date: Mon, 11 Jan 2010 10:48:17 +0900 Subject: I don't need no stinking firewall! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> Message-ID: > And I don't believe anyone is necessarily advocating exposing > individual servers directly to the internet either. some of us do that takes all kinds :) randy From chort at smtps.net Sun Jan 10 20:44:37 2010 From: chort at smtps.net (Brian Keefer) Date: Sun, 10 Jan 2010 18:44:37 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> Message-ID: <91389021-8B52-49BA-880E-577570287716@smtps.net> On Jan 10, 2010, at 5:40 PM, George Bonser wrote: > And I don't believe anyone is necessarily advocating exposing individual > servers directly to the internet either. Actually, some of us are. > There are other devices that > can handle isolation of the servers and protect them against such things > as syn floods. What is the point of that when the servers can do it themselves? -- bk From jul_bsd at yahoo.fr Sun Jan 10 23:26:39 2010 From: jul_bsd at yahoo.fr (jul) Date: Mon, 11 Jan 2010 06:26:39 +0100 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: Message-ID: <4B4AB68F.1050501@yahoo.fr> Martin Hannigan wrote on 05/01/10 16:50: >> I see two possible solutions: >> - Netflow/sFlow/***Flow feeding a BGP RTBH >> - Inline device >> >> > > - Outsource to service provider I want to add some stuff on this as I didn't see them with a quick check on the thread. Local solution always have a limit as bandwith will be exhausted before goin into your solution/network. Outsourced services have higher cost than Arbor but can handled more. Known leader of the clean-pipe solution is Prolexic http://www.prolexic.com/ Akamai and Verisign also tries to go on this market http://www.akamai.com/security (through CDN) http://www.verisign.com/internet-defense-network/index.html Best regards, Julien From gbonser at seven.com Sun Jan 10 23:56:14 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 10 Jan 2010 21:56:14 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <91389021-8B52-49BA-880E-577570287716@smtps.net> References: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> <91389021-8B52-49BA-880E-577570287716@smtps.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F71E6@RWC-EX1.corp.seven.com> > > And I don't believe anyone is necessarily advocating exposing > individual > > servers directly to the internet either. > > Actually, some of us are. That can be difficult to do when you have maybe 300 or 400 servers that handle one service. Let's say you have a site called www.foobar.com and you have several hundred servers on the front end that handle that domain. You aren't going to put several hundred A records in DNS; at least I hope you aren't. One would probably have a load balancer of some sort in front of those machines. That is the device that would be fielding any DoS. > > There are other devices that > > can handle isolation of the servers and protect them against such > things > > as syn floods. > > What is the point of that when the servers can do it themselves? I have a feeling you are talking about relatively small amounts of traffic. From rdobbins at arbor.net Mon Jan 11 00:15:35 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 11 Jan 2010 06:15:35 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F71E6@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com> <91389021-8B52-49BA-880E-577570287716@smtps.net> <5A6D953473350C4B9995546AFE9939EE081F71E6@RWC-EX1.corp.seven.com> Message-ID: On Jan 11, 2010, at 12:56 PM, George Bonser wrote: > One would probably have a load balancer of some sort in front of those machines. That is the device that would be fielding any DoS. Yes, and as you've noted previously, it should be protected via stateless ACLs in hardware capable of handling mpps, S/RTBH, flow-spec, IDMS, whatever. And of course the load-balancer should also be fronted by a reverse-proxy cache farm, if the servers in question are Web servers. > I have a feeling you are talking about relatively small amounts of traffic. I believe that these comments were more along the lines of 'servers can better handle this that stateful firewalls', not ruling out the use of load-balancers, reverse-proxy caches, etc. as appropriate. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From morrowc.lists at gmail.com Mon Jan 11 01:05:17 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 Jan 2010 02:05:17 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <4B4AB68F.1050501@yahoo.fr> References: <4B4AB68F.1050501@yahoo.fr> Message-ID: <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> On Mon, Jan 11, 2010 at 12:26 AM, jul wrote: > Martin Hannigan wrote on 05/01/10 16:50: >>> I see two possible solutions: >>> - Netflow/sFlow/***Flow ?feeding a BGP RTBH >>> - Inline device >>> >>> >> >> ? ? ?- Outsource to service provider > > I want to add some stuff on this as I didn't see them with a quick check > on the thread. > Local solution always have a limit as bandwith will be exhausted before > goin into your solution/network. > > Outsourced services have higher cost than Arbor but can handled more. Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over 2yrs. Arbor, I think, for a TMS + collectors was +100k. There are decent outsourced solutions, that move the problem out of your network, scrub traffic as requested, give you the ability to send traffic there on-demand (without calling the provider) and actually do work. All at a cost that's more than reasonable if your business depends upon the Internets. -chris From gbonser at seven.com Mon Jan 11 01:35:30 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 10 Jan 2010 23:35:30 -0800 Subject: I don't need no stinking firewall! In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F71E4@RWC-EX1.corp.seven.com><91389021-8B52-49BA-880E-577570287716@smtps.net><5A6D953473350C4B9995546AFE9939EE081F71E6@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F71E7@RWC-EX1.corp.seven.com> > I believe that these comments were more along the lines of 'servers can > better handle this that stateful firewalls', not ruling out the use of > load-balancers, reverse-proxy caches, etc. as appropriate. > > ----------------------------------------------------------------------- > Roland Dobbins // I read it as the poster linking a service to a server. That would imply to me a small amount of traffic. The notion that a service is somehow related to a server is valid for rates of traffic that a single server can handle but things change once you scale beyond that level. A service provided to the internet does not map to a server except in small scale operation. From hank at efes.iucc.ac.il Mon Jan 11 03:40:13 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 11 Jan 2010 11:40:13 +0200 (IST) Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <4B4AB68F.1050501@yahoo.fr> References: <4B4AB68F.1050501@yahoo.fr> Message-ID: On Mon, 11 Jan 2010, jul wrote: > Known leader of the clean-pipe solution is Prolexic > http://www.prolexic.com/ > > Akamai and Verisign also tries to go on this market > http://www.akamai.com/security (through CDN) > http://www.verisign.com/internet-defense-network/index.html Indeed, these 3 also ended up on my shortlist after much research. Each has areas they are weaker in than their competitors but they are all worthy. -Hank From sfouant at shortestpathfirst.net Mon Jan 11 07:45:45 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 11 Jan 2010 08:45:45 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <4B4AB68F.1050501@yahoo.fr> Message-ID: <004a01ca92c4$60fc8e50$22f5aaf0$@net> > -----Original Message----- > From: Hank Nussbacher [mailto:hank at efes.iucc.ac.il] > Sent: Monday, January 11, 2010 4:40 AM > To: jul > Cc: NANOG > Subject: Re: D/DoS mitigation hardware/software needed. > > On Mon, 11 Jan 2010, jul wrote: > > > Known leader of the clean-pipe solution is Prolexic > > http://www.prolexic.com/ > > > > Akamai and Verisign also tries to go on this market > > http://www.akamai.com/security (through CDN) > > http://www.verisign.com/internet-defense-network/index.html > > Indeed, these 3 also ended up on my shortlist after much research. > Each > has areas they are weaker in than their competitors but they are all > worthy. If you're connected to Level 3 in any capacity, they have a reseller agreement with Prolexic and can offer REALLY aggressive pricing. I really liked their offering. If anyone is interested, I did pretty exhaustive research into the Service Provider marketplace last summer (before Verisign came out with their VIDN). I've got some slides which outline the costs, mitigation capacity, etc. of many different providers. The provider option isn't always the cheapest when compared to DIY factored in over a 3-5 year lifespan. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From sfouant at shortestpathfirst.net Mon Jan 11 08:33:08 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 11 Jan 2010 09:33:08 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> Message-ID: <004e01ca92ca$ffc5c280$ff514780$@net> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Monday, January 11, 2010 2:05 AM > > On Mon, Jan 11, 2010 at 12:26 AM, jul wrote: > > Martin Hannigan wrote on 05/01/10 16:50: > > > > Outsourced services have higher cost than Arbor but can handled more. > > Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over > 2yrs. Arbor, I think, for a TMS + collectors was +100k. Don't forget to factor in OpEx. This can often tilt the scales in favor of one vs. the other. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From mjkelly at gmail.com Mon Jan 11 08:35:31 2010 From: mjkelly at gmail.com (Matt Kelly) Date: Mon, 11 Jan 2010 09:35:31 -0500 Subject: AT&T request... Message-ID: <463DF9D4-044A-464C-859C-8C33A53D537F@gmail.com> Can someone from AT&T please contact me off list regarding a problem with a segment of our network being blocked? Thanks. --Matt From nanog at shreddedmail.com Mon Jan 11 09:38:37 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 11 Jan 2010 07:38:37 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <004e01ca92ca$ffc5c280$ff514780$@net> References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> <004e01ca92ca$ffc5c280$ff514780$@net> Message-ID: I thought I had mentioned outsourcing earlier, but I don't see it in the thread... The two mechanisms I've seen for outsources D/DoS are DNS manipulation, or essentially remote BGP peering with an tunnel back to the local presence. Even if we are purely hosting, DNS manipulation doesn't do anything for attacks against an IP. For remote BGP peering/tunneling, you are are adding additional complexity and moving control outside your network. As a service-provider/data-center, it seems like outsourcing would be either ineffective and/or removes the "big red button" in case of trouble. Am I missing something, overly paranoid, or are there other mechanisms for outsourced protection? Rick On Mon, Jan 11, 2010 at 6:33 AM, Stefan Fouant < sfouant at shortestpathfirst.net> wrote: > > -----Original Message----- > > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > > Sent: Monday, January 11, 2010 2:05 AM > > > > On Mon, Jan 11, 2010 at 12:26 AM, jul wrote: > > > Martin Hannigan wrote on 05/01/10 16:50: > > > > > > Outsourced services have higher cost than Arbor but can handled more. > > > > Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over > > 2yrs. Arbor, I think, for a TMS + collectors was +100k. > > Don't forget to factor in OpEx. This can often tilt the scales in favor of > one vs. the other. > > Stefan Fouant, CISSP, JNCIE-M/T > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > > From math at sizone.org Mon Jan 11 09:48:00 2010 From: math at sizone.org (Ken Chase) Date: Mon, 11 Jan 2010 10:48:00 -0500 Subject: SORBS on autopilot? Message-ID: <20100111154759.GK6617@sizone.org> Anyone got some pointers on how to get off SORBS' Dynamic IP lists? We've followed their RFC proposed static reverse DNS assignment naming and all elements of their FAQ. We are not spammers. The /24 in question isnt listed on any RBLs except SORBS DUL. We've submitted requests in various different formats, but get a robot reply and -ENOJOY. We've even had our upstream that is listed at the RIR as managing the supernet of our BGP announced prefixes submit requests to delist for the /24, but we are only ever replied to by a robot that lists 67.196.137.0/24 as dynamic except .163 (somehow manually excluded from their db, I think when they werent adrift in years past). Our upstream's techs are also at a loss now and suggested I seek arcane clue amongst the sages here. Pointers appreciated. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From lesmith at ecsis.net Mon Jan 11 10:01:11 2010 From: lesmith at ecsis.net (Larry Smith) Date: Mon, 11 Jan 2010 10:01:11 -0600 Subject: SORBS on autopilot? In-Reply-To: <20100111154759.GK6617@sizone.org> References: <20100111154759.GK6617@sizone.org> Message-ID: <201001111001.11155.lesmith@ecsis.net> On Mon January 11 2010 09:48, Ken Chase wrote: > Anyone got some pointers on how to get off SORBS' Dynamic IP lists? > > We've followed their RFC proposed static reverse DNS assignment naming and > all elements of their FAQ. > > We are not spammers. The /24 in question isnt listed on any RBLs except > SORBS DUL. > > We've submitted requests in various different formats, but get a robot > reply and -ENOJOY. > > We've even had our upstream that is listed at the RIR as managing the > supernet of our BGP announced prefixes submit requests to delist for the > /24, but we are only ever replied to by a robot that lists 67.196.137.0/24 > as dynamic except .163 (somehow manually excluded from their db, I think > when they werent adrift in years past). Our upstream's techs are also at a > loss now and suggested I seek arcane clue amongst the sages here. > > Pointers appreciated. > > /kc Hmmm, probably something to do with your "reverse" naming convention: host 67.196.137.1 1.137.196.67.in-addr.arpa domain name pointer H1.C137.B196.A67.tor.colo.heavycomputing.ca. host 67.196.137.163 163.137.196.67.in-addr.arpa domain name pointer sizone.org. host 67.196.137.16 16.137.196.67.in-addr.arpa domain name pointer H16.C137.B196.A67.tor.colo.heavycomputing.ca. host 67.196.137.162 162.137.196.67.in-addr.arpa domain name pointer H162.C137.B196.A67.tor.colo.heavycomputing.ca. IP 67.196.137.163 appears to actually have a "name" and everything else has Hnnn.C137.B196.A67.tor.colo.heavycomputing.ca (where nnn is the fourth octet IP). -- Larry Smith lesmith at ecsis.net From jlewis at lewis.org Mon Jan 11 10:11:41 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 Jan 2010 11:11:41 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <20100111154759.GK6617@sizone.org> References: <20100111154759.GK6617@sizone.org> Message-ID: On Mon, 11 Jan 2010, Ken Chase wrote: > Anyone got some pointers on how to get off SORBS' Dynamic IP lists? > > We've followed their RFC proposed static reverse DNS assignment naming > and all elements of their FAQ. Have you tried all 3 of the routes listed at http://www.au.sorbs.net/faq/dul.shtml ? Something they don't tell you on the web page is that they ignore TTL and cache your DNS for a relatively long time. If you tried for automated removal and your rDNS wasn't SORBS-compliant, automated removal isn't going to work for some number of days (I forget how many) even after you have made your rDNS SORBS-compliant. 67.196.137.160 H160.C137.B196.A67.tor.colo.heavycomputing.ca. 67.196.137.161 H161.C137.B196.A67.tor.colo.heavycomputing.ca. 67.196.137.162 H162.C137.B196.A67.tor.colo.heavycomputing.ca. 67.196.137.163 sizone.org. 67.196.137.164 H164.C137.B196.A67.tor.colo.heavycomputing.ca. 67.196.137.165 H165.C137.B196.A67.tor.colo.heavycomputing.ca. 67.196.137.166 H166.C137.B196.A67.tor.colo.heavycomputing.ca. With rDNS like that...good luck. Go read http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt change your rDNS, wait a few days, and maybe you'll have a chance. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sfouant at shortestpathfirst.net Mon Jan 11 10:14:08 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 11 Jan 2010 11:14:08 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> <004e01ca92ca$ffc5c280$ff514780$@net> Message-ID: <000501ca92d9$1b575ff0$52061fd0$@net> > -----Original Message----- > From: Rick Ernst [mailto:nanog at shreddedmail.com] > Sent: Monday, January 11, 2010 10:39 AM > To: NANOG > Subject: Re: D/DoS mitigation hardware/software needed. > > As a service-provider/data-center, it seems like outsourcing would be > either > ineffective and/or removes the "big red button" in case of trouble. > > Am I missing something, overly paranoid, or are there other mechanisms > for > outsourced protection? In fact, quite the opposite. Those providers who do offer DDoS mitigation services usually allow the customer to trigger the redirect in a manner similar to RTBHs by substituting the blackhole community for some type of mitigation community. This causes the Provider's edge router (or Route Server) to advertise the affected route within the Service Provider's network with a next-hop of the scrubbers. There are some providers who do auto-mitigation on behalf of the customer, but IMO this approach is asking for trouble. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From telmnstr at 757.org Mon Jan 11 10:15:26 2010 From: telmnstr at 757.org (telmnstr at 757.org) Date: Mon, 11 Jan 2010 11:15:26 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <20100111154759.GK6617@sizone.org> References: <20100111154759.GK6617@sizone.org> Message-ID: > Anyone got some pointers on how to get off SORBS' Dynamic IP lists? Our solution was to find new IP space. It was hopeless. From patrick at ianai.net Mon Jan 11 10:18:23 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Jan 2010 11:18:23 -0500 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> Message-ID: <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> On Jan 11, 2010, at 11:15 AM, telmnstr at 757.org wrote: >> Anyone got some pointers on how to get off SORBS' Dynamic IP lists? > > Our solution was to find new IP space. It was hopeless. Did SORBS really cause you that much pain? I ask because the other possible solution is enough people do not find new space that people using SORBS stop using SORBS. -- TTFN, patrick From math at sizone.org Mon Jan 11 10:24:42 2010 From: math at sizone.org (Ken Chase) Date: Mon, 11 Jan 2010 11:24:42 -0500 Subject: SORBS on autopilot? In-Reply-To: <201001111001.11155.lesmith@ecsis.net> References: <20100111154759.GK6617@sizone.org> <20100111154759.GK6617@sizone.org> <201001111001.11155.lesmith@ecsis.net> Message-ID: <20100111162442.GM6617@sizone.org> On Mon, Jan 11, 2010 at 10:01:11AM -0600, Larry Smith's said: >host 67.196.137.1 >1.137.196.67.in-addr.arpa domain name pointer >H1.C137.B196.A67.tor.colo.heavycomputing.ca. Yeah I didnt make the .colo. up, it's in their proposed-RFC document in section 6.3. They even go so far as to use the word MUST w.r.t. 'colo' in YELLCAPS: http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt >host 67.196.137.163 >163.137.196.67.in-addr.arpa domain name pointer sizone.org. This one was manually delisted a while ago. I have other hosts in there that have proper custom-reverses such as .188 (which is the customer of mine which wants off, but we cant get off.) He's had his custom name in there for months. Doenst seem to help. >Have you tried all 3 of the routes listed at >http://www.au.sorbs.net/faq/dul.shtml ? Yes. >Something they don't tell you on the web page is that they ignore TTL and >cache your DNS for a relatively long time. If you tried for automated >removal and your rDNS wasn't SORBS-compliant, automated removal isn't >going to work for some number of days (I forget how many) even after you >have made your rDNS SORBS-compliant. It's been 5 days since I changed from a generic naming scheme (which was the above minus the word colo) to adding in the 'colo'. Maybe the .tor. extra subdomain is hurting somehow - the feedback loop between executing and testing results is painfully long, and hard to tie down cause and effect. I see our listing is also dated as an Aug 29th test, Im not sure how to get them to re-test the block despite the 're-test' guidelines on their pages. >67.196.137.165 H165.C137.B196.A67.tor.colo.heavycomputing.ca. >67.196.137.166 H166.C137.B196.A67.tor.colo.heavycomputing.ca. > >With rDNS like that...good luck. Go read > >http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Exactly. Section 6.3, though with the .tor., perhaps Im not allowed to indicate with a STATIC NAME where the colocation is, and perhaps I have to remove the H/C/B/A as well. Guess ill try and just wait another 4-8 days before guessing that's not working. >change your rDNS, wait a few days, and maybe you'll have a chance. Have, maybe not enough days though. Hard to tell, which is my whole complaint. But getting this working would also help spammers, I suppose is their refrain. Ill try to be extremely literal about the non-RFC and see where that gets me. Thanks. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From telmnstr at 757.org Mon Jan 11 10:54:30 2010 From: telmnstr at 757.org (telmnstr at 757.org) Date: Mon, 11 Jan 2010 11:54:30 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> Message-ID: > Did SORBS really cause you that much pain? Yes. We purchased colo space for some systems that didn't need high class of service (mostly development systems.) The IP space in a former lifetime was a dialup pool for analog modems. We of course changed the reverse DNS entries, and did the normal request with SORBS. Nothign really happened. I started looking into it, and finding stories of people doing the mandatory $90 donation to get express attention, and still not getting attention (so they were reversing the paypal payments and such.) After reading all this crap, I pushed our provider, they couldn't get response from sorbs, so we ended up relaying some of the traffic through our ISP and other traffic through our mail servers that are in a better data center. We had ZERO problem with Spamhaus. They were cool. Fast. Worked. The problem of course is that customers that don't know any better use mail servers that are setup for SORBS. Trying to explain it to non-tech folks is futile. The people that run SORBS are obviously bored with the project, and it should die. > I ask because the other possible solution is enough people do not find new space that people using SORBS stop using SORBS. That's tough because the people that generally are using mail servers that use SORBS don't know better. They have to ask their providers, etc. From gordslater at ieee.org Mon Jan 11 11:05:39 2010 From: gordslater at ieee.org (gordon b slater) Date: Mon, 11 Jan 2010 17:05:39 +0000 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> Message-ID: <1263229539.26974.12.camel@ub-g-d2> On Mon, 2010-01-11 at 11:15 -0500, telmnstr at 757.org wrote: > > Anyone got some pointers on how to get off SORBS' Dynamic IP lists? > > Our solution was to find new IP space. It was hopeless. > > "me too"; for 2 of my old (smaller sized) customers in the last 4 or 5 month. Nothing seemed to work and the immediate financial losses rapidly hit over 10k Euros in both cases, so switching was by far the easier option. I was amazed, but it definitely worked, I'll grant them that. Both were "normal" and non-spammy setups, correctly configured and well run by experienced netops. They just figured it was faster/safer (financially) to move, all things considered. Caused a panic at the time but until it happens again, 100% success :) Gord -- error: wit pool entropy approaching zero. system halted. again. From chort at smtps.net Mon Jan 11 11:26:11 2010 From: chort at smtps.net (Brian Keefer) Date: Mon, 11 Jan 2010 09:26:11 -0800 Subject: SORBS on autopilot? In-Reply-To: <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> Message-ID: On Jan 11, 2010, at 8:18 AM, Patrick W. Gilmore wrote: > people using SORBS stop using SORBS. > > -- > TTFN, > patrick Usually that's the easiest path. All it takes is asking the site using SORBS to do a few Google searches. There are much better options out there than SORBS. Why anyone thinks it's a good idea to cause that much collateral damage is beyond me. -- bk From auser at mind.net Mon Jan 11 11:40:14 2010 From: auser at mind.net (Steve Ryan) Date: Mon, 11 Jan 2010 09:40:14 -0800 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> Message-ID: <4B4B627E.8050300@mind.net> On 1/11/2010 8:54 AM, telmnstr at 757.org wrote: >> Did SORBS really cause you that much pain? > SORBS causes people pain every day. I worked at an ISP that used > SORBS and it was nothing short of a nightmare. Donations to ge things > removed, nobody would help you, everything was 'automated' and if > somehow something pissed off the 'automation process' you were subject > to things just staying broken. SORBS is a joke, always been a joke, and always will be a joke. I'm quite saddened by the fact an entity actually provided financial support to keep it going. The internet community would have been better served had they just went away. From morrowc.lists at gmail.com Mon Jan 11 11:48:51 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 Jan 2010 12:48:51 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <004e01ca92ca$ffc5c280$ff514780$@net> References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> <004e01ca92ca$ffc5c280$ff514780$@net> Message-ID: <75cb24521001110948ib9ecca5ua46e6a726a1f2ce5@mail.gmail.com> On Mon, Jan 11, 2010 at 9:33 AM, Stefan Fouant wrote: >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Monday, January 11, 2010 2:05 AM >> >> On Mon, Jan 11, 2010 at 12:26 AM, jul wrote: >> > Martin Hannigan wrote on 05/01/10 16:50: >> > >> > Outsourced services have higher cost than Arbor but can handled more. >> >> Do they? VerizonBusiness's solution was $3250US/month so ~$90USk over >> 2yrs. Arbor, I think, for a TMS + collectors was +100k. > > Don't forget to factor in OpEx. ?This can often tilt the scales in favor of > one vs. the other. sure, but just capex alone the 'make vzb do this' option wins. (I think at least, I'm not a math guy though...) From sfouant at shortestpathfirst.net Mon Jan 11 12:12:55 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 11 Jan 2010 13:12:55 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <75cb24521001110948ib9ecca5ua46e6a726a1f2ce5@mail.gmail.com> References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> <004e01ca92ca$ffc5c280$ff514780$@net> <75cb24521001110948ib9ecca5ua46e6a726a1f2ce5@mail.gmail.com> Message-ID: <001501ca92e9$b3594dd0$1a0be970$@net> Precisely - I was saying that in order to add more point to your argument. I wasn't disagreeing with you :) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D > -----Original Message----- > From: christopher.morrow at gmail.com > [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Monday, January 11, 2010 12:49 PM > To: Stefan Fouant > Cc: jul; NANOG > Subject: Re: D/DoS mitigation hardware/software needed. > > On Mon, Jan 11, 2010 at 9:33 AM, Stefan Fouant > wrote: > >> -----Original Message----- > >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > >> Sent: Monday, January 11, 2010 2:05 AM > >> > >> On Mon, Jan 11, 2010 at 12:26 AM, jul wrote: > >> > Martin Hannigan wrote on 05/01/10 16:50: > >> > > >> > Outsourced services have higher cost than Arbor but can handled > more. > >> > >> Do they? VerizonBusiness's solution was $3250US/month so ~$90USk > over > >> 2yrs. Arbor, I think, for a TMS + collectors was +100k. > > > > Don't forget to factor in OpEx. ?This can often tilt the scales in > favor of > > one vs. the other. > > sure, but just capex alone the 'make vzb do this' option wins. (I > think at least, I'm not a math guy though...) From morrowc.lists at gmail.com Mon Jan 11 12:39:08 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 Jan 2010 13:39:08 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <001501ca92e9$b3594dd0$1a0be970$@net> References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> <004e01ca92ca$ffc5c280$ff514780$@net> <75cb24521001110948ib9ecca5ua46e6a726a1f2ce5@mail.gmail.com> <001501ca92e9$b3594dd0$1a0be970$@net> Message-ID: <75cb24521001111039p5b52ff55g15e2dabab1a7c8fc@mail.gmail.com> On Mon, Jan 11, 2010 at 1:12 PM, Stefan Fouant wrote: > Precisely - I was saying that in order to add more point to your argument. > I wasn't disagreeing with you :) i need more coffee :( thanks! -Chris From bill at herrin.us Mon Jan 11 12:48:46 2010 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jan 2010 13:48:46 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B4B627E.8050300@mind.net> References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> <4B4B627E.8050300@mind.net> Message-ID: <3c3e3fca1001111048w50c0ae21kb8dd66ff41772bc3@mail.gmail.com> On Mon, Jan 11, 2010 at 12:40 PM, Steve Ryan wrote: > SORBS is a joke, always been a joke, and always will be a joke. ?I'm quite > saddened by the fact an entity actually provided financial support to keep > it going. ?The internet community would have been better served had they > just went away. SORBS appeared because someone was upset when the widely reviled ORBS decamped. If SORBS went away there'd just be MORBS. All the same, it's disappointing to see the SORBS DUL fall into disrepair. Although not the focus of sorbs' operator, the DUL *was* one of the more useful lists they published. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at shreddedmail.com Mon Jan 11 13:16:50 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Mon, 11 Jan 2010 11:16:50 -0800 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <000501ca92d9$1b575ff0$52061fd0$@net> References: <4B4AB68F.1050501@yahoo.fr> <75cb24521001102305t1de9ff43r9ba6540af4357e93@mail.gmail.com> <004e01ca92ca$ffc5c280$ff514780$@net> <000501ca92d9$1b575ff0$52061fd0$@net> Message-ID: Right. Some providers allow you to BGP community trigger RTBH. There was a separate mention of D/DoS-mitigation-providers using DNS and BGP tunneling. Rick On Mon, Jan 11, 2010 at 8:14 AM, Stefan Fouant < sfouant at shortestpathfirst.net> wrote: > > -----Original Message----- > > From: Rick Ernst [mailto:nanog at shreddedmail.com] > > Sent: Monday, January 11, 2010 10:39 AM > > To: NANOG > > Subject: Re: D/DoS mitigation hardware/software needed. > > > > As a service-provider/data-center, it seems like outsourcing would be > > either > > ineffective and/or removes the "big red button" in case of trouble. > > > > Am I missing something, overly paranoid, or are there other mechanisms > > for > > outsourced protection? > > In fact, quite the opposite. Those providers who do offer DDoS mitigation > services usually allow the customer to trigger the redirect in a manner > similar to RTBHs by substituting the blackhole community for some type of > mitigation community. This causes the Provider's edge router (or Route > Server) to advertise the affected route within the Service Provider's > network with a next-hop of the scrubbers. > > There are some providers who do auto-mitigation on behalf of the customer, > but IMO this approach is asking for trouble. > > Stefan Fouant, CISSP, JNCIE-M/T > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > From hartwick at hartwick.com Mon Jan 11 13:47:29 2010 From: hartwick at hartwick.com (Michael J. Hartwick) Date: Mon, 11 Jan 2010 14:47:29 -0500 Subject: he.net down/slow? In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> Message-ID: <013701ca92f6$e8d6c5c0$ba845140$@com> I have never understood how posting the "warning" at the bottom of the email after you have already given up the "protected" information could possibly be considered enforceable. I thought most NDA's required willing acceptance by both parties before it could be considered valid, a message at the bottom of the email that I have not agreed to should not be considered a valid contract. That is kind of like putting the software license agreement inside the box and the only way to get to the agreement is to open the shrink wrap, but opening the shrink wrap is your acceptance of the agreement. If you put the "warning" at the top of the email before what you are trying to protect I *might* be more likely to believe it could be enforced. Michael ---------------------------------------------------------------------- Michael J. Hartwick, VE3SLQ hartwick at hartwick.com Hartwick Communications Consulting (519) 396-7719 Kincardine, ON, CA http://www.hartwick.com ---------------------------------------------------------------------- > -----Original Message----- > From: Martin Hannigan [mailto:martin at theicelandguy.com] > Sent: Saturday, January 09, 2010 18:28 > To: Valdis.Kletnieks at vt.edu; Brian Johnson; nanog at nanog.org > Subject: Re: he.net down/slow? > > Some NDA's require that you must state your intent for each > communication that should be covered by the NDA. As much as everyone > would like to believe these are wothless, they are not. Applying them > globally to your email protects your legal rights. It is also > innocous. > > Don't them it if you don't want to or perhaps a filter on keywords? > > Best, > > -M< > > > > > > > > On 1/7/10, Valdis.Kletnieks at vt.edu wrote: > > On Thu, 07 Jan 2010 13:51:41 CST, Brian Johnson said: > >> > On 7 Jan 2010, at 18:18, William Pitcock wrote: > >> > > ...why would you have that on a mailing list post? > >> > because the mail server that adds it is too dumb to differentiate > >> > between list and direct mail? > > > >> Bingo! ;) > > > > That sort of gratuitous "add it to everything because our software is > too > > stupid to sort it out" is *this* close to what the legal eagles call > > "overwarning". Just sayin'. > > > > (Basically, your site and everybody else's site sticks it on > everything, > > all the recipients just ignore it the same way we almost always > ignore > > Received: headers because they're on every message and very rarely > have > > any useful content - with the end result that if you stick it on a > message > > that *matters*, it will still get ignored....) > > > > Oh, and is your company ready to indemnify my employer for the costs > of > > "destroy all copies of the original message" sufficiently thoroughly > to > > prevent recovery by a competent forensics expert? This may include, > but > > not be limited to, the main mail store for 70,000 people, backup > tapes, > > and other mail systems where the data may have been logically deleted > but > > as yet not overwritten. Just sayin'. ;) > > > > > -- > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and > Occupants From henry at AegisInfoSys.com Mon Jan 11 14:52:05 2010 From: henry at AegisInfoSys.com (Henry Yen) Date: Mon, 11 Jan 2010 15:52:05 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <4B46D6DD.6060901@west.net>; from Jay Hennigan on Thu, Jan 07, 2010 at 22:55:25PM -0800 References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <20100105203906.GO23204@virtual.bogons.net> <4B43A941.1050209@west.net> <20100107142514.GA23323@mail.zucchetti.com> <4B46D6DD.6060901@west.net> Message-ID: <20100111155205.M31930@AegisInfoSys.com> On Thu, Jan 07, 2010 at 22:55:25PM -0800, Jay Hennigan wrote: > Nenad Andric wrote: > > On Tue Jan 05, 2010 at 01:04:01PM -0800, Jay Hennigan wrote: > > >> Or better: > >> - Allow from anywhere port 80 to server port > 1023 established > > > > Adding "established" brings us back to stateful firewall! > > Not really. It only looks to see if the ACK or RST bits are set. This > is different from a stateful firewall which memorizes each outbound > packet and checks the return for a match source/destination/sequence. That's (cisco) reflexive access lists. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From jul_bsd at yahoo.fr Mon Jan 11 15:58:07 2010 From: jul_bsd at yahoo.fr (jul) Date: Mon, 11 Jan 2010 22:58:07 +0100 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <004a01ca92c4$60fc8e50$22f5aaf0$@net> References: <4B4AB68F.1050501@yahoo.fr> <004a01ca92c4$60fc8e50$22f5aaf0$@net> Message-ID: <4B4B9EEF.6030308@yahoo.fr> Stefan Fouant wrote on 11/01/10 14:45: > If anyone is interested, I did pretty exhaustive research into the Service > Provider marketplace last summer (before Verisign came out with their VIDN). > I've got some slides which outline the costs, mitigation capacity, etc. of > many different providers. The provider option isn't always the cheapest > when compared to DIY factored in over a 3-5 year lifespan. If you can share, I think everyone would be interested. I am :) From sfouant at shortestpathfirst.net Mon Jan 11 17:31:49 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 11 Jan 2010 18:31:49 -0500 Subject: D/DoS mitigation hardware/software needed. In-Reply-To: <4B4B9EEF.6030308@yahoo.fr> References: <4B4AB68F.1050501@yahoo.fr> <004a01ca92c4$60fc8e50$22f5aaf0$@net> <4B4B9EEF.6030308@yahoo.fr> Message-ID: <002201ca9316$4000fa90$c002efb0$@net> Ummm... there is some proprietary information I would have to remove first. Will NANOG accept a message to the forum with an attachment? If not I can put it up on my site. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D > -----Original Message----- > From: jul [mailto:jul_bsd at yahoo.fr] > Sent: Monday, January 11, 2010 4:58 PM > To: Stefan Fouant > Cc: 'Hank Nussbacher'; 'NANOG' > Subject: Re: D/DoS mitigation hardware/software needed. > > Stefan Fouant wrote on 11/01/10 14:45: > > If anyone is interested, I did pretty exhaustive research into the > Service > > Provider marketplace last summer (before Verisign came out with their > VIDN). > > I've got some slides which outline the costs, mitigation capacity, > etc. of > > many different providers. The provider option isn't always the > cheapest > > when compared to DIY factored in over a 3-5 year lifespan. > > If you can share, I think everyone would be interested. > I am :) From jcdill.lists at gmail.com Mon Jan 11 18:01:22 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 11 Jan 2010 16:01:22 -0800 Subject: he.net down/slow? In-Reply-To: <013701ca92f6$e8d6c5c0$ba845140$@com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> <013701ca92f6$e8d6c5c0$ba845140$@com> Message-ID: <4B4BBBD2.5010809@gmail.com> Michael J. Hartwick wrote: > I have never understood how posting the "warning" at the bottom of the email > after you have already given up the "protected" information could possibly > be considered enforceable. It might be useful to look at what some people in the legal business say about these disclaimers: http://arborlaw.biz/blog/2007/07/19/legal-issues-in-email-disclaimers/ From bill at herrin.us Mon Jan 11 18:36:14 2010 From: bill at herrin.us (William Herrin) Date: Mon, 11 Jan 2010 19:36:14 -0500 Subject: he.net down/slow? In-Reply-To: <4B4BBBD2.5010809@gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27F9B@ex01.drtel.lan> <1262888339.6710.28.camel@petrie> <7FEAD060-0114-4C81-8C7F-139DDCA839E6@st-kilda.org> <29A54911243620478FF59F00EBB12F4701B27FB3@ex01.drtel.lan> <19839.1262905996@localhost> <013701ca92f6$e8d6c5c0$ba845140$@com> <4B4BBBD2.5010809@gmail.com> Message-ID: <3c3e3fca1001111636y70c16b50q3a0cb0445e3b243f@mail.gmail.com> On Mon, Jan 11, 2010 at 7:01 PM, JC Dill wrote: > Michael J. Hartwick wrote: >> >> I have never understood how posting the "warning" at the bottom of the >> email >> after you have already given up the "protected" information could possibly >> be considered enforceable. > > It might be useful to look at what some people in the legal business say > about these disclaimers: > > http://arborlaw.biz/blog/2007/07/19/legal-issues-in-email-disclaimers/ Here's what these lawyers have to say: http://www.ndasforfree.com/TSProgram03BasicProtection.html "Don?t go overboard and mark everything in sight confidential. If virtually everything, including public information, is marked ?confidential,? a court may conclude that nothing was really confidential. It is better not to mark anything than to mark everything." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From giulianocm at uol.com.br Mon Jan 11 19:03:25 2010 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Mon, 11 Jan 2010 23:03:25 -0200 Subject: Question about how to define network equipments Message-ID: <4B4BCA5D.9030103@uol.com.br> People, I have seen a discussion about DDoS Mitigation in this list. Someone reference Juniper SRX equipments like good equipments to prevent DDoS attacks. Like Juniper SRX, other players like fortinet has some hardware based ( FORTIGATE) Appliances to provide great throughput, ddos mitigation, UTM Features, etc. Ex. Recent Fortigate 1240B My question about this products is related to a combination of performance parameters that I really does not understand. Lets use Juniper SRX as an example: Juniper SRX has (from Juniper's web site): Firewall performance (max) 1.5 Gbps Maximum concurrent sessions 64 K (512 MB DRAM) / 128 K (1 GB DRAM) New sessions/second (sustained, TCP, 3-way) 9,000 Lets suppose that we have a client with 100 Mbps total full duplex throughput in a SRX-240 interfaces. If this client has 6000 users ... how is possible to combine: 1.5 Gbps (100 Mbps) x 128K sessions x 9000 new sessions/second Supposing 5000 users x 100 sessions per user ... the box will not support it , right ? How is the correct way to calculate with accuracy this ? Every player looks like to have a way to calculate it. Every player said something about sessions. What is the correct parameter about sessions ? How many sessions per second a normal user (FTP, E-mail, HTTP, SSL, SSH, Telnet) can generate ? Why the number 9000 new sessions/second is important ? How can I sum to all of this 3 parameters ... the DDoS mitigation ? How much performance I will consume, under a DDoS attack ? It is possible to measure it ? Thanks a lot, Giuliano From sliplever at gmail.com Mon Jan 11 19:12:14 2010 From: sliplever at gmail.com (Dan Snyder) Date: Mon, 11 Jan 2010 20:12:14 -0500 Subject: Question about how to define network equipments In-Reply-To: <4B4BCA5D.9030103@uol.com.br> References: <4B4BCA5D.9030103@uol.com.br> Message-ID: <1c2d53bb1001111712u73529a48i731602ea83bb3bec@mail.gmail.com> I know you can measure the actual performance if you use Ixia hardware. We have used Ixia to find the limitations of hardware before putting it in production. On Mon, Jan 11, 2010 at 8:03 PM, GIULIANO (UOL) wrote: > People, > > I have seen a discussion about DDoS Mitigation in this list. > > Someone reference Juniper SRX equipments like good equipments to prevent > DDoS attacks. > > Like Juniper SRX, other players like fortinet has some hardware based ( > FORTIGATE) Appliances to provide great throughput, ddos mitigation, UTM > Features, etc. Ex. Recent Fortigate 1240B > > My question about this products is related to a combination of > performance parameters that I really does not understand. > > Lets use Juniper SRX as an example: > > Juniper SRX has (from Juniper's web site): > > Firewall performance (max) > 1.5 Gbps > > Maximum concurrent sessions > 64 K (512 MB DRAM) / 128 K (1 GB DRAM) > > New sessions/second (sustained, TCP, 3-way) > 9,000 > > Lets suppose that we have a client with 100 Mbps total full duplex > throughput in a SRX-240 interfaces. > > If this client has 6000 users ... how is possible to combine: > > 1.5 Gbps (100 Mbps) x 128K sessions x 9000 new sessions/second > > Supposing 5000 users x 100 sessions per user ... the box will not > support it , right ? > > How is the correct way to calculate with accuracy this ? > > Every player looks like to have a way to calculate it. Every player said > something about sessions. > > What is the correct parameter about sessions ? > > How many sessions per second a normal user (FTP, E-mail, HTTP, SSL, SSH, > Telnet) can generate ? > > Why the number 9000 new sessions/second is important ? > > How can I sum to all of this 3 parameters ... the DDoS mitigation ? > > How much performance I will consume, under a DDoS attack ? > > It is possible to measure it ? > > Thanks a lot, > > Giuliano > > From cra at WPI.EDU Mon Jan 11 20:17:25 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 11 Jan 2010 21:17:25 -0500 Subject: d000::/8 from AS28716 Message-ID: <20100112021725.GQ2591@angus.ind.WPI.EDU> Anyone know why this ISP from Italy is advertising d000::/8 to the IPv6 Internet? > show route d000::/8 inet6.0: 2446 destinations, 5143 routes (2445 active, 0 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both d000::/8 *[BGP/170] 01:08:26, MED 760, localpref 200 AS path: 30071 6762 28716 I > to 2001:4830:e1:10::1 via ge-0/0/0.593 aut-num: AS28716 as-name: EPLANET-AS export: to AS49772 announce ANY descr: ePLANET SPA descr: Internet Service Provider descr: Via G.Vida 19 20127 Milano - ITALY - admin-c: GU29-RIPE tech-c: MF8125-RIPE mnt-by: EPLANET-MNT mnt-routes: EPLANET-MNT changed: hostmaster at ripe.net 20080208 source: RIPE From swm at emanon.com Mon Jan 11 20:24:16 2010 From: swm at emanon.com (Scott Morris) Date: Mon, 11 Jan 2010 21:24:16 -0500 Subject: d000::/8 from AS28716 In-Reply-To: <20100112021725.GQ2591@angus.ind.WPI.EDU> References: <20100112021725.GQ2591@angus.ind.WPI.EDU> Message-ID: <4B4BDD50.90603@emanon.com> To be honest, when I figured a big BUNCH of d000 was going to hit the Internet, I did not expect it to come from Italy. ;) Chuck Anderson wrote: Anyone know why this ISP from Italy is advertising d000::/8 to the IPv6 Internet? show route d000::/8 inet6.0: 2446 destinations, 5143 routes (2445 active, 0 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both d000::/8 *[BGP/170] 01:08:26, MED 760, localpref 200 AS path: 30071 6762 28716 I > to 2001:4830:e1:10::1 via ge-0/0/0.593 aut-num: AS28716 as-name: EPLANET-AS export: to AS49772 announce ANY descr: ePLANET SPA descr: Internet Service Provider descr: Via G.Vida 19 20127 Milano - ITALY - admin-c: GU29-RIPE tech-c: MF8125-RIPE mnt-by: EPLANET-MNT mnt-routes: EPLANET-MNT changed: [1]hostmaster at ripe.net 20080208 source: RIPE References 1. mailto:hostmaster at ripe.net From mark.jacksontechnology at gmail.com Mon Jan 11 20:25:56 2010 From: mark.jacksontechnology at gmail.com (Mark Jackson) Date: Mon, 11 Jan 2010 18:25:56 -0800 Subject: d000::/8 from AS28716 In-Reply-To: <20100112021725.GQ2591@angus.ind.WPI.EDU> References: <20100112021725.GQ2591@angus.ind.WPI.EDU> Message-ID: <-8325558465033721992@unknownmsgid> I'd say that is a bogus route/AS announcement. I see nothing in the address assignment for that. But I see traffic started originating around 12/15/2009. Mark Jackson, CCIE #4736 Sent from my iPhone. Please excuse spelling errors On Jan 11, 2010, at 6:17 PM, Chuck Anderson wrote: > Anyone know why this ISP from Italy is advertising d000::/8 to the > IPv6 Internet? > >> show route d000::/8 > > inet6.0: 2446 destinations, 5143 routes (2445 active, 0 holddown, 1 > hidden) > Restart Complete > + = Active Route, - = Last Active, * = Both > > d000::/8 *[BGP/170] 01:08:26, MED 760, localpref 200 > AS path: 30071 6762 28716 I >> to 2001:4830:e1:10::1 via ge-0/0/0.593 > > > aut-num: AS28716 > as-name: EPLANET-AS > export: to AS49772 announce ANY > descr: ePLANET SPA > descr: Internet Service Provider > descr: Via G.Vida 19 20127 Milano - ITALY - > admin-c: GU29-RIPE > tech-c: MF8125-RIPE > mnt-by: EPLANET-MNT > mnt-routes: EPLANET-MNT > changed: hostmaster at ripe.net 20080208 > source: RIPE > > From steve at ibctech.ca Mon Jan 11 21:17:02 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 11 Jan 2010 22:17:02 -0500 Subject: d000::/8 from AS28716 In-Reply-To: <-8325558465033721992@unknownmsgid> References: <20100112021725.GQ2591@angus.ind.WPI.EDU> <-8325558465033721992@unknownmsgid> Message-ID: <4B4BE9AE.6080801@ibctech.ca> Mark Jackson wrote: > I'd say that is a bogus route/AS announcement. > I see nothing in the address assignment for that. But I see traffic > started originating around 12/15/2009. I envision that work will be done in this regard shortly. God willing, our RIRs will be handing out prefixes to everyone from blocks that are specifically designed for 'that purpose'. It's interesting to know that since we are so virgin v6, that the RIRs should have no problem shelving up address space into an easy-to-document format. Although the RIRs can't dictate routing policy, routing/ops people can dictate what the RIR policy states. Then, Team Cymru will have an easy time laying base with an 'allowed' as opposed to a 'denied' list of addresses. Steve From andree+nanog at toonk.nl Mon Jan 11 22:21:48 2010 From: andree+nanog at toonk.nl (Andree Toonk) Date: Tue, 12 Jan 2010 05:21:48 +0100 Subject: d000::/8 from AS28716 In-Reply-To: <-8325558465033721992@unknownmsgid> References: <20100112021725.GQ2591@angus.ind.WPI.EDU> <-8325558465033721992@unknownmsgid> Message-ID: <20100112042148.GA20811@toonk.nl> .-- My secret spy satellite informs me that at Mon, 11 Jan 2010, Mark Jackson wrote: > I'd say that is a bogus route/AS announcement. > I see nothing in the address assignment for that. But I see traffic > started originating around 12/15/2009. Actually d000::/8 has been around for 2 months already (2009-11-13 08:24:46). Also see: http://www.bgpmon.net/showbogons.php?inet=6 Cheers Andree From p.caci at seabone.net Tue Jan 12 01:33:01 2010 From: p.caci at seabone.net (Pierfrancesco Caci) Date: Tue, 12 Jan 2010 08:33:01 +0100 Subject: d000::/8 from AS28716 In-Reply-To: <20100112021725.GQ2591@angus.ind.WPI.EDU> (Chuck Anderson's message of "Mon, 11 Jan 2010 21:17:25 -0500") References: <20100112021725.GQ2591@angus.ind.WPI.EDU> Message-ID: <87k4vnzsk2.fsf@clarabella.noc.seabone.net> :-> "Chuck" == Chuck Anderson writes: > d000::/8 *[BGP/170] 01:08:26, MED 760, localpref 200 > AS path: 30071 6762 28716 I >> to 2001:4830:e1:10::1 via ge-0/0/0.593 I fail to see how this could have gone through this: ipv6 prefix-list AS28716-V6-IN: 1 entries seq 5 permit 2001:1BD0::/32 unless "Every IPv6 prefix list, including prefix lists that do not have any permit and deny condition statements, has an implicit deny any any statement as its last match condition" is not true for this particular IOS release, or the router just went nuts. Maybe next time drop me a line when it's happening, I don't see the route from the customer now. Pf -- ------------------------------------------------------------------------------- Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC p.caci at seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/ From mysidia at gmail.com Tue Jan 12 08:03:11 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 12 Jan 2010 08:03:11 -0600 Subject: d000::/8 from AS28716 In-Reply-To: <87k4vnzsk2.fsf@clarabella.noc.seabone.net> References: <20100112021725.GQ2591@angus.ind.WPI.EDU> <87k4vnzsk2.fsf@clarabella.noc.seabone.net> Message-ID: <6eb799ab1001120603u45c60f3dqfd9d4a208a50ad9f@mail.gmail.com> On Tue, Jan 12, 2010 at 1:33 AM, Pierfrancesco Caci wrote: .. > Maybe next time drop me a line when it's happening, I don't see the > route from the customer now. Can still be seen on routeviews... a ghost route, perhaps? route-views6.routeviews.org> show bgp d000:: BGP routing table entry for d000::/8 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 33437 29748 3257 6762 28716 2001:4810::1 from 2001:4810::1 (66.117.34.140) Origin IGP, localpref 100, valid, external, best Community: 3257:3300 3257:3301 3257:5033 Last update: Tue Jan 12 13:10:31 2010 -- -J From p.caci at seabone.net Tue Jan 12 09:09:34 2010 From: p.caci at seabone.net (Pierfrancesco Caci) Date: Tue, 12 Jan 2010 16:09:34 +0100 Subject: d000::/8 from AS28716 In-Reply-To: <6eb799ab1001120603u45c60f3dqfd9d4a208a50ad9f@mail.gmail.com> (James Hess's message of "Tue, 12 Jan 2010 08:03:11 -0600") References: <20100112021725.GQ2591@angus.ind.WPI.EDU> <87k4vnzsk2.fsf@clarabella.noc.seabone.net> <6eb799ab1001120603u45c60f3dqfd9d4a208a50ad9f@mail.gmail.com> Message-ID: <876377tl5d.fsf@clarabella.noc.seabone.net> :-> "James" == James Hess writes: > On Tue, Jan 12, 2010 at 1:33 AM, Pierfrancesco Caci wrote: > .. >> Maybe next time drop me a line when it's happening, I don't see the >> route from the customer now. > Can still be seen on routeviews... a ghost route, perhaps? Yes. -- ------------------------------------------------------------------------------- Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC p.caci at seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/ From vixie at isc.org Tue Jan 12 09:21:02 2010 From: vixie at isc.org (Paul Vixie) Date: Tue, 12 Jan 2010 15:21:02 +0000 Subject: DNS queries for . IN A return rcode 2 SERVFAIL from windows DNS recursing resolvers In-Reply-To: <4B433CAD.9070605@ttec.com> (Joe Maimon's message of "Tue\, 05 Jan 2010 08\:20\:45 -0500") References: <4B433CAD.9070605@ttec.com> Message-ID: Joe Maimon writes: > Hey all, > > This must be old news for everyone else. While looking at a dns monitor > on a load balancer that defaulted to . A queries to check liveliness on > DNS resolvers, it became quite clear that windows 2000/2003 DNS server > appears to return rcode=2 for queries looking for an A record for the > root. The resolvers appear to work properly in all other regards. well, there is no A RR for the root domain. RCODE=2 is still an error, you should receive RCODE=0 ANCOUNT=0 for an unused RR type. but many resolvers get confused when the root domain is the QNAME, so let's assume that you're using one of those. > So the monitors were switched to localhost. A > > (Is this a bad idea?) probably. there is no "localhost" in the root zone. this name is a TCP/IP stack convention, not a standard. for health monitoring purposes you should probably choose one of your own local names, since there's almost certainly no local intelligence in your resolver about them. that means to look up one of your own names the resolver probably has to iterate downward from the root zone to the top level and all the way down to your authority nameservers. (the problem here is, you may be testing more than you intend, and a failure in your own authority server or in the delegation path to it would look the same as an IP path failure or a resolver problem.) > A little testing later and the results for . A are: > > Windows NT 4, ancount=0, authority=1, rcode=0 > Windows 2000, rcode=2 > Windows 2003, rcode=2 > bind, ancount=0, authority=1, rcode=0 > > To my (inexpert) eyes that doesnt seem quite right. probably resolver bugs, either in those TCP/IP stacks or in the "recursive nameserver" they are using. (is the same recursive nameserver used in all four tests?) > I cant seem to find any online information regarding this difference of > behavior. > > Enlightenment appreciated. i suggest re-asking this over on dns-operations at lists.dns-oarc.net, since it a bit deep in the DNS bits for a general purpose list like NANOG. -- Paul Vixie KI6YSY From drew.weaver at thenap.com Tue Jan 12 09:36:55 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 12 Jan 2010 10:36:55 -0500 Subject: Senderbase contact Message-ID: Any Senderbase contacts on list? I am having problems getting some questions answered through normal channels. thanks, -Drew From jed at jedsmith.org Tue Jan 12 10:51:47 2010 From: jed at jedsmith.org (Jed Smith) Date: Tue, 12 Jan 2010 11:51:47 -0500 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> Message-ID: <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: > http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt At the risk of hijacking the thread, is this draft considered to be of importance outside of SORBS' domain at all? When handling a /24 that ended up on the DUL -- I feel this thread's pain -- I made the case that this draft expired years ago by the book and never got any further. The DUL companies like SORBS, Trend Micro, et. al. all point to this document as justification for their practices, however; wouldn't that be considered violating it, given the preamble on page 1? The vibe I got from a number of administrators I talked to about it was "why would a standards document assume an IPv4/IPv6 unicast address is a residential customer with a modem, forcing those with allocations to prove that they are not residentially allocated rather than the other way around?" If it remains the magic document to get SORBS to pay attention to you, and nothing more, that would be ideal. JS From jlewis at lewis.org Tue Jan 12 11:33:19 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 12 Jan 2010 12:33:19 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> Message-ID: On Tue, 12 Jan 2010, Jed Smith wrote: >> http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt > > At the risk of hijacking the thread, is this draft considered to be of > importance outside of SORBS' domain at all? When handling a /24 that > ended up on the DUL -- I feel this thread's pain -- I made the case that > this draft expired years ago by the book and never got any further. The > DUL companies like SORBS, Trend Micro, et. al. all point to this > document as justification for their practices, however; wouldn't that be > considered violating it, given the preamble on page 1? Sure, it's expired and never made it to RFC status. But are the "DUL"'s really pointing at it as justification for their policies, or simply pointing to it as a handy place to find a set of reasonably sensible suggested practices for DNS naming schemes. If there's another similar document, I'm not aware of it. I don't know that following the schemes the draft proposes is required for keeping IPs off any "DUL", but I sure wish people would at least read it and consider some of the ideas presented...namely that their DNS naming scheme should clearly indicate an IP's purpose, at least if they want that IP to be useful for sending email. For example, take the following IPs and their PTRs 70.42.226.181 sm-70-42-226-181.quepasa.com 78.228.245.8 mad26-1-78-228-245-8.fbx.proxad.net 83.185.129.102 m83-185-129-102.cust.tele2.se 118.137.228.242 fm-ip-118.137.228.242.fast.net.id 189.84.86.106 189-84-86-106.marinter.com.br All of them have recently tried sending mail. How many are mail servers? As the vast majority of spam now comes from bot-infected end user systems, it's increasinly important to be able to easily differentiate mail servers from !mail servers. rDNS is a cheap and easy (or at least it can be if the provider chooses) way to do it. Those who choose to ignore the ideas presented in draft-msullivan-dnsop-generic-naming-schemes-00.txt do so at their own peril. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sandofree at gmail.com Tue Jan 12 11:33:46 2010 From: sandofree at gmail.com (Ye Wang) Date: Tue, 12 Jan 2010 12:33:46 -0500 Subject: Is FRR protection good enough? Message-ID: <502a66881001120933h59ee47ccu26a3b9e13b7af139@mail.gmail.com> Hi, I am doing some research on the backup routing issue. I know Fast ReRoute bypass routing such as MPLS FRR is used by many networks. You may have experienced with this thing pretty well, and can teach me a little bit. My question is: current FRR scheme seems only guarantee network reachability under link/node failure, but not bandwidth (say, if my primary link is carrying 1Gbps, but my bypass path has a capacity of only 100Mbps, then the bandwidth for the traffic under failure is limited). Do you think the reachability level of protection is good enough? Has anyone here encountered any issues with FRR (say, bypass routing could not save your network service during unexpected accident, e.g., concurrent failures of multiple devices)? Is there any example case (or any news and reports regarding this question) I can study? Another thing I want to understand is: if I want to protect a lot of links/nodes (in addition to a few major ones), is the configuration job easy of difficult? My knowledge so far tells me that it is not easy at all. I don't know what is going on in practice. If you can share your experience with me, it will be great. Many Thanks, sando From Valdis.Kletnieks at vt.edu Tue Jan 12 11:37:12 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Jan 2010 12:37:12 -0500 Subject: SORBS on autopilot? In-Reply-To: Your message of "Tue, 12 Jan 2010 11:51:47 EST." <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> Message-ID: <25604.1263317832@localhost> On Tue, 12 Jan 2010 11:51:47 EST, Jed Smith said: > The vibe I got from a number of administrators I talked to about it was "why > would a standards document assume an IPv4/IPv6 unicast address is a residential > customer with a modem, forcing those with allocations to prove that they are > not residentially allocated rather than the other way around?" What percent of allocated globally routed IP addresses are residential endpoints, and what percent are in data centers? What's the better base assumption if your goal is "I don't want to talk to address ranges that are full of botted boxes"? There's a *reason* why "default deny" is a well-known security policy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From schampeo at hesketh.com Tue Jan 12 11:42:58 2010 From: schampeo at hesketh.com (Steven Champeon) Date: Tue, 12 Jan 2010 12:42:58 -0500 Subject: SORBS on autopilot? In-Reply-To: <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> Message-ID: <20100112174258.GB9961@hesketh.com> on Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: > The vibe I got from a number of administrators I talked to about it > was "why would a standards document assume an IPv4/IPv6 unicast > address is a residential customer with a modem, forcing those with > allocations to prove that they are not residentially allocated rather > than the other way around?" Well, of course. Any idiot can tell just by looking at any PTR that the IP to which it corresponds is obviously an IPv4 unicast address! I think they teach that in elementary school now. I know I got high marks on how to identify mail sources hidden behind NATs, ISP-outsourced university residential network blocks, and snowshoe spammers using burner domains with hostnames "borrowed" from real hosts in other domains. But there was this one kid in my class who simply couldn't see when a host with a IP-derived, hexadecimal generic name was obviously a broadcast address. Poor guy. Even when it emitted spam he had trouble seeing that it wasn't actually possible, because clearly the PTR is always correct. OTOH, those of us who were out sick when they dealt out the magic PTR meaning decoder rings need a little more help. If I had my way, all PTRs would be clear, unambiguous strings of tokens that indicated their use, their assignment type, the technology or technologies in use, and so on. In reality, we have names like these to contend with (naturally, this example's IP whois simply indicates it's part of a /16): 183.87.5.131.static-dynamic.nivyah.com [183.87.5.131] And if you're trying to classify such naming conventions, as I do with my Enemieslist project, or if you're trying to build and/or maintain a DUL, as Michelle does, well, that sucks. It's far better when the naming is clear, eg u1524.spam-source.sprintnet.ru [81.22.1.89] n081022008237.avoid-mail-from-theese-hosts.sprintnet.ru [81.22.8.237] or, more informatively: host-79-141-236-93.dynamic.pptp.planeta.starnet.ru [79.141.236.93] host-94-102-86-87.static.pppoe.planeta.starnet.ru [94.102.86.87] or, because there's always a joker (both names have since been updated): alameda.net.has.not.owned.this.ip.for.more.then.four.years [209.0.51.16] this.ptr.is.named.in.honor.of.arin.nac.net [66.246.175.3] (heh) just to pick a few. At the very least, customer-assigned blocks ought to have a SWIP and a comment showing whether they're dynamic or static, residential or business class, and so forth. A surprising example, given the paucity of such examples in the .pl TLD, is dialog.net.pl, which does exactly that: inetnum: 87.105.24.0 - 87.105.24.255 netname: DIALOGNET descr: Static Broadband Services descr: Telefonia Dialog S.A. - Dialog Telecom country: PL inetnum: 62.87.215.0 - 62.87.215.255 netname: DIALOGNET descr: Dynamic Broadband Services descr: Telefonia Dialog S.A. - Dialog Telecom country: PL So, if the Poles (well, some Poles) can do it, why can't we simply end the endless back and forth over why SORBS is evil, and start adopting sane and clear naming conventions for PTRs? Given how easy it is to modify a $GENERATE statement, I should think you've spent far more energy on arguing about why you're being wronged than it would have taken to fix your problem. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From Valdis.Kletnieks at vt.edu Tue Jan 12 11:45:55 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Jan 2010 12:45:55 -0500 Subject: Is FRR protection good enough? In-Reply-To: Your message of "Tue, 12 Jan 2010 12:33:46 EST." <502a66881001120933h59ee47ccu26a3b9e13b7af139@mail.gmail.com> References: <502a66881001120933h59ee47ccu26a3b9e13b7af139@mail.gmail.com> Message-ID: <25958.1263318355@localhost> On Tue, 12 Jan 2010 12:33:46 EST, Ye Wang said: > My question is: current FRR scheme seems only guarantee network reachability > under link/node failure, but not bandwidth (say, if my primary link is > carrying 1Gbps, but my bypass path has a capacity of only 100Mbps, then the > bandwidth for the traffic under failure is limited). Do you think the > reachability level of protection is good enough? That's a total "it depends" question. We've had several instances where backhoe fade or hardware issues have killed our primary off-site link and taken 80% of our bandwidth with it, and we just put up a "The Internet Will Be Slow For A Bit" notice and keep going, as most of our traffic is basically bulk data transfer and we're OK as long as all the bits eventually arrive. For other organizations, the resulting slowdown may be totally unacceptable - if you're doing a lot of video streaming or VoIP, it would be fatal. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jed at jedsmith.org Tue Jan 12 12:31:06 2010 From: jed at jedsmith.org (Jed Smith) Date: Tue, 12 Jan 2010 13:31:06 -0500 Subject: SORBS on autopilot? In-Reply-To: <20100112174258.GB9961@hesketh.com> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> Message-ID: Steven, take it easy please. Given the first few replies I received, allow me to clarify, now that I've successfully hijacked the thread and apparently angered the anti-spam crowd: I am quite aware of the problem and do not disagree that there needs to be a way to identify what IP endpoints are residential CPE. I simply have some problems with /this/ current incarnation of a best practice, and I was querying whether it had applicability outside of the SORBS/Trend Micro world. Honestly, I feel that PTRs are the least reliable way to make such a decision. Depending on the chain of delegation, a server operator may not have access to modify his PTR record and might not be able to change it. Several operators have annoyingly odd delegation patterns. PTRs are just bad news for any kind of useful decision on, other than "PTR-matches-A". Given the amount of IRC abuse PTRs have seen, the consequential abuse of IPv4 allocation to support exotic PTRs, and the resulting limitation of PTR alteration that many providers practice I just don't like PTRs overall for anything meaningful. I also disagree with space being assumed dynamic unless it is declared static -- helpfully, I have been reminded that consumer CPE equipment is a large number of IPv4 endpoints, but I still think space should be assumed static unless declared dynamic. The burden really should be upon the providers of dynamic services to inform us that their allocations are a dynamic pool; good luck with this, however. Getting a standards-track solution that is reliable, cost-effective for home Internet providers to get on board with, and that has very little wiggle-room for discretion (this current incarnation has quite a bit) is necessary for me to be on board with such classification techniques. That said, I am not the guru that others on this list are and I am unprepared to present an alternative; I am simply pointing out that I'd like to see an alternative. Let me reiterate: I'm not disputing the challenges that network operators face with network abuse, I am simply disagreeing with this draft, its authorship, the sour taste you get from reading it because it's so far past expiration, and its motives in current practice. It's akin to me disagreeing with daylight savings time because it tries to fix energy consumption from lighting. JS From chort at smtps.net Tue Jan 12 12:48:31 2010 From: chort at smtps.net (Brian Keefer) Date: Tue, 12 Jan 2010 10:48:31 -0800 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> Message-ID: On Jan 12, 2010, at 10:31 AM, Jed Smith wrote: > > Given the first few replies I received, allow me to clarify, now that I've > ... apparently angered the anti-spam crowd: > I wouldn't say that necessarily accurate. I could be considered part of the "anti-spam crowd", seeing as that's my line of work. I think DULs are a really dumb way to block spam. Making a binary decision off of information that's wrong as often as it's right it's a great way to create collateral damage and just generally cause more headaches for everyone. Sure, you could take PTR content into account as _part_ of your decision on how to treat incoming e-mail (or connections, for that matter), but it should never be the _whole_ decision. Keeping track of observed behavior is much more indicative of whether an IP is going to send you spam than just assuming all IPs are dynamic until proven otherwise (through some laborious 12-step process, possibly including bribes^H^H^H^H^H^Hdonations). There are several enterprise-class, best-of-breed vendors using the former technique rather than the latter. I think you'll find it's low-end, unsophisticated outfits who use the latter method. Yes PTRs should be more accurate and informative, but very often the people standing up mail servers aren't the people who have control over the DNS and barely even understand how it works. Many organizations who have access to directly edit their forward zones don't have that kind of access to their reverse zones and find updating that information to be somewhat of an arcane process. DNS should really be taught in schools. -- bk From darkmoon at vt.edu Tue Jan 12 12:48:59 2010 From: darkmoon at vt.edu (Dave Martin) Date: Tue, 12 Jan 2010 13:48:59 -0500 Subject: SORBS on autopilot? In-Reply-To: <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> Message-ID: <20100112184859.GB12541@vt.edu> On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: > On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: > The vibe I got from a number of administrators I talked to about it was "why > would a standards document assume an IPv4/IPv6 unicast address is a residential > customer with a modem, forcing those with allocations to prove that they are > not residentially allocated rather than the other way around?" Because a default allow policy doesn't work in today's environment. Blocking generic and residential addresses is the single most effective thing we've ever done to reduce spam. Most legit senders don't want to look like a compromised box in someone's bedroom anyway. -- Dave ----- Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed! From jcdill.lists at gmail.com Tue Jan 12 12:56:01 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 12 Jan 2010 10:56:01 -0800 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> Message-ID: <4B4CC5C1.4010806@gmail.com> Jed Smith wrote: > Depending on the chain of delegation, a server operator may not have access to > modify his PTR record and might not be able to change it. It's a common belief among network operators that if a "server operator" doesn't have access/ability to modify the PTR record for a server, it's a good sign that the server shouldn't be used to send email, but instead should send email thru an email server provided by their upstream access provider. The people who manage those servers, who can't or won't fix the PTR *or* send email thru an email server provided by their access provider, think it is critically important that the rest of the internet receive their missives. They are mistaken. Their missives come from "a bad neighborhood" (IPs with PTR formats that are strongly associated with botnets) where the odds of any email being desired by the recipient are extremely low. If they want their email to avoid being treated as spam then they need to move to a better neighborhood (fix the PTR) or send from a server located in a better neighborhood (a server with a correct PTR for a mail server). Endlessly whining "I wanna, I wanna, I can't, You should, I wanna" over and over isn't going to change anything. Other networks aren't going to change how they filter based on PTR for someone who can't properly assign the PTR for their mail server. jc From jed at jedsmith.org Tue Jan 12 12:59:09 2010 From: jed at jedsmith.org (Jed Smith) Date: Tue, 12 Jan 2010 13:59:09 -0500 Subject: SORBS on autopilot? In-Reply-To: <20100112184859.GB12541@vt.edu> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> Message-ID: On Jan 12, 2010, at 1:48 PM, Dave Martin wrote: > On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >> The vibe I got from a number of administrators I talked to about it was "why >> would a standards document assume an IPv4/IPv6 unicast address is a residential >> customer with a modem, forcing those with allocations to prove that they are >> not residentially allocated rather than the other way around?" > > Because a default allow policy doesn't work in today's environment. Blocking based on PTR alone is dangerous, is what I'm saying. I know default deny is important, but the decision can only be minorly influenced by PTR, not entirely made on it. There needs to be a better way, but there isn't. JS From mike at mtcc.com Tue Jan 12 13:11:13 2010 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Jan 2010 11:11:13 -0800 Subject: SORBS on autopilot? In-Reply-To: <20100112184859.GB12541@vt.edu> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> Message-ID: <4B4CC951.80309@mtcc.com> On 01/12/2010 10:48 AM, Dave Martin wrote: > On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >> The vibe I got from a number of administrators I talked to about it was "why >> would a standards document assume an IPv4/IPv6 unicast address is a residential >> customer with a modem, forcing those with allocations to prove that they are >> not residentially allocated rather than the other way around?" > > Because a default allow policy doesn't work in today's environment. > > Blocking generic and residential addresses is the single most effective > thing we've ever done to reduce spam. Really? You mean that if you stopped doing this you'd have trillions, or quadrillions of spams per day instead now? I'm skeptical. Mike From chort at smtps.net Tue Jan 12 13:27:32 2010 From: chort at smtps.net (Brian Keefer) Date: Tue, 12 Jan 2010 11:27:32 -0800 Subject: SORBS on autopilot? In-Reply-To: <20100112184859.GB12541@vt.edu> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> Message-ID: <9B0BB0D9-8586-4B98-923B-04FE646808C5@smtps.net> On Jan 12, 2010, at 10:48 AM, Dave Martin wrote: > On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >> The vibe I got from a number of administrators I talked to about it was "why >> would a standards document assume an IPv4/IPv6 unicast address is a residential >> customer with a modem, forcing those with allocations to prove that they are >> not residentially allocated rather than the other way around?" > > Because a default allow policy doesn't work in today's environment. There are lots of other ways to deny that don't cause massive collateral damage. Allowing IPs with "suspicious" PTRs to attempt a connection doesn't mean their mail is delivered, or even that their connection will succeed. There are better ways to deny. > Blocking generic and residential addresses is the single most effective > thing we've ever done to reduce spam. Not surprising, but at what cost of false positives? Maybe your organization is different, but the ones I talk to are much more worried about missing a single e-mail than blocking an extra 1,000. > Most legit senders don't want to look like a compromised box in > someone's bedroom anyway. There are literally thousands of companies who don't grasp the difference, or have little ability to influence their appearance. I listen to the guy in the next cube over say "setup your RDNS" probably half a dozen times a day. He's lucky if they even understand what he said most of the time. Most people just do not grok DNS--even when they're given simple templates to fill out, cut, and paste they still manage to screw it up, or simply ignore it. The membership of this list probably has one of the highest concentrations of DNS-clue in the world, but it's not representative of most organizations with an e-mail server. -- bk From patrick at ianai.net Tue Jan 12 13:34:18 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Jan 2010 14:34:18 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B4CC951.80309@mtcc.com> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <4B4CC951.80309@mtcc.com> Message-ID: <1DFA025F-1E21-4B22-AF4C-B4575682556C@ianai.net> On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote: > On 01/12/2010 10:48 AM, Dave Martin wrote: >> On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >>> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >>> The vibe I got from a number of administrators I talked to about it was "why >>> would a standards document assume an IPv4/IPv6 unicast address is a residential >>> customer with a modem, forcing those with allocations to prove that they are >>> not residentially allocated rather than the other way around?" >> >> Because a default allow policy doesn't work in today's environment. >> >> Blocking generic and residential addresses is the single most effective >> thing we've ever done to reduce spam. > > Really? You mean that if you stopped doing this you'd have trillions, > or quadrillions of spams per day instead now? I'm skeptical. 1) Is this really the place to talk about SORBS? 2) Your reply to Dave's post is not useful. It's not even useful if you consider it pure hyperbole for effect. There are many ways to reduce spam, the "single most effective" does not stop even 50%. 3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption. -- TTFN, patrick P.S. Just to be clear, I don't like SORBS. I don't use it either. And I prefer the "make them stop", to the point that I would simply not e-mail someone if I were listed and they used SORBS. (But I'm not listed, so it's easy for me to say.) From mike at mtcc.com Tue Jan 12 13:48:04 2010 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Jan 2010 11:48:04 -0800 Subject: SORBS on autopilot? In-Reply-To: <1DFA025F-1E21-4B22-AF4C-B4575682556C@ianai.net> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <4B4CC951.80309@mtcc.com> <1DFA025F-1E21-4B22-AF4C-B4575682556C@ianai.net> Message-ID: <4B4CD1F4.1000005@mtcc.com> On 01/12/2010 11:34 AM, Patrick W. Gilmore wrote: > On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote: >> On 01/12/2010 10:48 AM, Dave Martin wrote: >>> On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: >>>> On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: >>>> The vibe I got from a number of administrators I talked to about it was "why >>>> would a standards document assume an IPv4/IPv6 unicast address is a residential >>>> customer with a modem, forcing those with allocations to prove that they are >>>> not residentially allocated rather than the other way around?" >>> >>> Because a default allow policy doesn't work in today's environment. >>> >>> Blocking generic and residential addresses is the single most effective >>> thing we've ever done to reduce spam. >> >> Really? You mean that if you stopped doing this you'd have trillions, >> or quadrillions of spams per day instead now? I'm skeptical. > > 1) Is this really the place to talk about SORBS? I'm not the one who brought up SORBS. My post didn't even have anything to do with SORBS. > 2) Your reply to Dave's post is not useful. It's not even useful if you consider it pure hyperbole for effect. There are many ways to reduce spam, the "single most effective" does not stop even 50%. > > 3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption. Who said anything about SORBS? Not me. Sorry. My post had to do with whether rDNS is doing much of anything in this day and age. I'm dubious. Spammers don't seem to have any impediment because on it. Mike From jed at jedsmith.org Tue Jan 12 13:59:55 2010 From: jed at jedsmith.org (Jed Smith) Date: Tue, 12 Jan 2010 14:59:55 -0500 Subject: Identifying residential CPE IP addresses? (was: SORBS on autopilot?) In-Reply-To: <1DFA025F-1E21-4B22-AF4C-B4575682556C@ianai.net> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <4B4CC951.80309@mtcc.com> <1DFA025F-1E21-4B22-AF4C-B4575682556C@ianai.net> Message-ID: <6F43E6D0-A9BD-45C0-80F8-9A2A6F11B2E5@jedsmith.org> On Jan 12, 2010, at 2:34 PM, Patrick W. Gilmore wrote: > On Jan 12, 2010, at 2:11 PM, Michael Thomas wrote: > > 3) Should people really argue over what other people do with their own machines? You don't like SORBS, don't use it. Someone you need to talk to likes SORBS, make them stop, or conform. Might as well argue over a website using HTTPS when you don't like encryption. I don't think the discussion is about SORBS, I think it's about this standards draft that SORBS points to. Here, I'll lay out what I'm saying simply (and retitle the thread so the SORBS issue will go away): 1. Your mailserver receives a connection from a previously-unknown relay. Although this discussion is meta to mail, it's the most prime example. 2. Very quickly, your mailserver must make a spot decision on whether the connecting IP address is a residential modem or a racked server. This information might be important in an administrator's decision, via his rules, to accept or reject any message that relay offers. (To reiterate: the problem is determination of sender, not an attempt to determine if the incoming mail is legitimate. This is beyond that.) 3. Currently, the solution is to consult the PTR, which this draft -- which coincidentally is written by the administrator of SORBS -- recommends. 4. For other reasons laid out in this thread, PTR is not the best choice. Additionally, administrators of mailservers who have no idea what a PTR is -- although their entry fee to the Internet mail system is debatable it will not be discussed here -- are now punished by blocklists like SORBS and Trend Micro with the simple crime of not knowing to PTR their mail server with something that screams "static allocation, not CPE". I note, with a heavy hand, that there are no widely-disseminated standards governing the reverse DNS of an Internet host other than this draft, but administrators make decisions on it anyway. 5. What else does your mailserver use? What could it use? Are there any desirable candidates for a standards-track behavior for determining the "class" of an IP (i.e., iPhone, home CPE, colo'd server, grid node, and so on). Should there be? My original goal here was educational -- I'd like to hear if anybody has given this question serious pause aside from putting silly restrictions on what can go in a PTR, and basing a heavy decision on said PTR. Are there any applications for such a test, outside of mail? I've apparently hit a nerve, and I'm sorry for that. JS From schampeo at hesketh.com Tue Jan 12 14:25:12 2010 From: schampeo at hesketh.com (Steven Champeon) Date: Tue, 12 Jan 2010 15:25:12 -0500 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> Message-ID: <20100112202512.GA23214@hesketh.com> on Tue, Jan 12, 2010 at 01:31:06PM -0500, Jed Smith wrote: > Steven, take it easy please. > > Given the first few replies I received, allow me to clarify, now that I've > successfully hijacked the thread and apparently angered the anti-spam crowd: Oh, I'm not angry, if anything I'm disappointed by the massive ongoing failure on the part of some of the folks responsible for PTR naming to deal with the FACT that people are ALREADY using PTRs to discriminate against probably infected spam-sending hosts. And the willingness of so many to argue against the adoption of sane naming conventions. And the amount of time that gets spent by people offering up their opinion on whether PTRs have any value at all (they do) and suggesting that maybe we should just eat all the abuse, forever, without making any efforts to stop it at our perimeters. But I've come to expect it from nanog. It happens that the doc that M. Sullivan wrote contains certain recommendations. It's not the only draft to do so. It doesn't matter to me what people do, as long as they're consistent (unlike, say, vsnl.net.in), as long as they don't mix dynamic and static naming (like RIMA-TDE), as long as it's not idiotic (like volia.net) and as long as they do /something/. But I've already tracked almost 50K naming conventions over the past six years or so; *I* don't *need* you to be sane or to agree with me or M. on specific tokens you should use, or to even agree that PTRs make a reliable indicator of legitimacy for SMTP emitters. That boat has sailed, that dog's been hunting for *years*, it's not an issue. Major AS appliance and AV vendors are already using these practices, period. > Honestly, I feel that PTRs are the least reliable way to make such a > decision. Well, be that as it may, other people don't share that opinion. And they're running mail servers, or writing software that runs antispam appliances, or they're sharing datasets on how to block mail from generics on lists like spam-l. It's ALREADY HAPPENING and has been for several years. To be more specific - I've looked at several hundred thousand IPs with PTRs, and analyzed and classified their naming conventions, to the tune of ~48K patterns in ~26K domains, over the last six years. PTRs are a very useful tool for SMTP, and a very useful tool for finding bots. Period. Yes, many PTRs are too generic to say with certainty "this IP is a dynamic/residential host", but many are not (approximately 13K out of that 48K are dynamics, 12K are statics, and others are generic - 13K or so - and still others are weird mixes like NATs and resnets). Why? Because other netops have discovered that providing a degree of transparency is reducing their abuse load, because it allows everyone else to reject from their dynamics. Helping Spamhaus PBL, SORBS, and everyone else classifying /your networks/ make the right decision is important, whatever your opinion of whether trusting PTRs is "smart". > Depending on the chain of delegation, a server operator may not have > access to modify his PTR record and might not be able to change it. And that's the rest of the network's problem how? > Several operators have annoyingly odd delegation patterns. So? > PTRs are just bad news for any kind of useful decision on, other than > "PTR-matches-A". Given the amount of IRC abuse PTRs have seen, the > consequential abuse of IPv4 allocation to support exotic PTRs, and the > resulting limitation of PTR alteration that many providers practice I > just don't like PTRs overall for anything meaningful. So, because a few blocks have silly.irc.scrip.kiddy.rdns the rest is not to be trusted? I've got 48K patterns against your occasional IRC script kiddy abuse that say otherwise. If a host wants to claim in SMTP that it's 18715194033.user.veloxzone.com.br [187.15.194.33] and I know that IP is residential, I have no reason to doubt it. Even if (as in this case) the PTR doesn't reverse-resolve. Even more so, I'd say. And even more if (as in this case) that host tried to send me nine spams (six to forged/bogus addresses based on mine) in the past three minutes. > I also disagree with space being assumed dynamic unless it is declared > static -- helpfully, I have been reminded that consumer CPE equipment > is a large number of IPv4 endpoints, but I still think space should be > assumed static unless declared dynamic. The burden really should be > upon the providers of dynamic services to inform us that their > allocations are a dynamic pool; good luck with this, however. I agree with you completely. Fortunately, genericity (rather than "static" versus "dynamic") matters even more. Yes, we classify patterns as applying to static hosts if that's what we can determine. But we score static generics as well, and treat them as suspect. And so do a lot of other folks, either using our data or otherwise. You're in a different position than most of the end user ISPs here; as a provider of web hosting and colo, you're going to have to deal more with scumbag snowshoe spammers and their ilk, and appear to be doing a decent job of it, based on my logs. /ll/maillog.24.gz:Dec 19 11:53:11 tabasco sendmail[32510]: nBJGqsYW032510: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li143-113.members.linode.com [109.74.196.113] /ll/maillog.24.gz:Dec 19 17:28:44 tabasco sendmail[1554]: nBJMSQqv001554: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li143-113.members.linode.com [109.74.196.113] /ll/maillog.24.gz:Dec 19 20:21:02 tabasco sendmail[16525]: nBK1KiD6016525: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li143-113.members.linode.com [109.74.196.113] /ll/maillog.25.gz:Dec 18 10:19:13 tabasco sendmail[8583]: nBIFItLC008583: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li130-51.members.linode.com [69.164.215.51] /ll/maillog.25.gz:Dec 18 10:30:17 tabasco sendmail[8996]: nBIFU0qr008996: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li130-51.members.linode.com [69.164.215.51] /ll/maillog.25.gz:Dec 18 12:03:00 tabasco sendmail[14154]: nBIH2gO3014154: from=, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=MTA, relay=li76-167.members.linode.com [74.207.234.167] Fortunately, we block all mail from hosts matching that pattern: li[0-9]+\-[0-9]+\.members\.linode\.com because in our opinion, generic / webhost rDNS is far more likely to emit spam than legit mail /for our users/. Others may score on such a pattern, others still may accept it and flag it for the spam folder, approaches vary. > Let me reiterate: I'm not disputing the challenges that network > operators face with network abuse, I am simply disagreeing with this > draft, its authorship, the sour taste you get from reading it because > it's so far past expiration, and its motives in current practice. It's > akin to me disagreeing with daylight savings time because it tries to > fix energy consumption from lighting. Fair enough. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From ben at bjencks.net Tue Jan 12 14:27:52 2010 From: ben at bjencks.net (Ben Jencks) Date: Tue, 12 Jan 2010 15:27:52 -0500 Subject: BGP testbed tools Message-ID: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> This is obviously a rookie question, but I haven't found anything by searching. I'm looking to set up a small testbed to simulate our internal network topology, and I want to have a realistic BGP table from the fake "upstream" routers. Ideally what I'd like to do is dump the BGP table from our production routers, strip the immediate neighbor AS, and load the table into Quagga or OpenBGPD to advertise. I'm running into two problems: how do you dump BGP tables in a machine-parseable format from IOS, and how do you make the route server advertise the routes as they were in the original table, including the full AS-path, communities, etc? If Quagga/OpenBGPD aren't the right tools, I'm happy to use something else. This seems like it would be a pretty standard thing to do, but none of the tools I've found seem aimed at this sort of testbed. Thanks! -Ben Jencks From Joel.Snyder at Opus1.COM Tue Jan 12 14:27:59 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Tue, 12 Jan 2010 13:27:59 -0700 Subject: SORBS on autopilot? In-Reply-To: References: Message-ID: <4B4CDB4F.8080706@opus1.com> Just a couple of corrections to two of the posts in this thread: >I simply have some problems > with /this/ current incarnation of a best practice, and I was querying whether > it had applicability outside of the SORBS/Trend Micro world. I think you are mixing/confusing SORBS and MAPS. MAPS was bought by Trend and is run as a service based on subscription fees. SORBS is whatever it is. If you don't like SORBS, that's great, but don't tar Trend with that brush. >2) Your reply to Dave's post is not useful. It's not even useful if >you consider it pure hyperbole for effect. There are many ways to >reduce spam, the "single most effective" does not stop even 50%. Actually, that's not true. I don't want to get into an argument about "single most effective," but I can guarantee that using a good reputation service will block more than 50% of the incoming spam to your network. The leading ones normally hit the 80% range. In fact, many of the popular anti-spam appliances are completely miserable at the content filter end which is applied post-reputation service; without reputation filtering, they wouldn't be worth using. (My information is based on monthly testing of anti-spam appliances we have conducted for the past 5 years. For example, this month we are looking at 43 different appliances and 25 reputation sevices) 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 Valdis.Kletnieks at vt.edu Tue Jan 12 14:36:38 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Jan 2010 15:36:38 -0500 Subject: SORBS on autopilot? In-Reply-To: Your message of "Tue, 12 Jan 2010 11:27:32 PST." <9B0BB0D9-8586-4B98-923B-04FE646808C5@smtps.net> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <9B0BB0D9-8586-4B98-923B-04FE646808C5@smtps.net> Message-ID: <6430.1263328598@localhost> On Tue, 12 Jan 2010 11:27:32 PST, Brian Keefer said: > On Jan 12, 2010, at 10:48 AM, Dave Martin wrote: > listen to the guy in the next cube over say "setup your RDNS" probably > half a dozen times a day. It's funny that you say that in reply to Dave's note - I usually wear headphones in the office so I don't have to listen to Dave in the next cube saying "fix your RDNS" over and over to clueless admins.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at ianai.net Tue Jan 12 14:38:51 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Jan 2010 15:38:51 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B4CDB4F.8080706@opus1.com> References: <4B4CDB4F.8080706@opus1.com> Message-ID: <80E1881A-FC6F-434F-9B79-209C9D19A519@ianai.net> On Jan 12, 2010, at 3:27 PM, Joel M Snyder wrote: >> 2) Your reply to Dave's post is not useful. It's not even useful if >> you consider it pure hyperbole for effect. There are many ways to >> reduce spam, the "single most effective" does not stop even 50%. > > Actually, that's not true. I don't want to get into an argument about "single most effective," but I can guarantee that using a good reputation service will block more than 50% of the incoming spam to your network. The leading ones normally hit the 80% range. A good reputation service is not using a single criteria. But you didn't want to get into an argument, and I agree it's not worth arguing over. The point was, trying to imply that not using DUL would result in "quadrillions" more spam is not useful. And I stand behind that. -- TTFN, patrick From gschwim at gmail.com Tue Jan 12 14:54:24 2010 From: gschwim at gmail.com (Greg Schwimer) Date: Tue, 12 Jan 2010 13:54:24 -0700 Subject: Baidu Contact Message-ID: <702ea15b1001121254x11b348d5g57d5dfb7d9dc6bec@mail.gmail.com> I'm looking for a technical contact at Baidu.com. Please contact me off list if you can help. Thanks! Greg Schwimer From schampeo at hesketh.com Tue Jan 12 14:59:01 2010 From: schampeo at hesketh.com (Steven Champeon) Date: Tue, 12 Jan 2010 15:59:01 -0500 Subject: Identifying residential CPE IP addresses? (was: SORBS on autopilot?) In-Reply-To: <6F43E6D0-A9BD-45C0-80F8-9A2A6F11B2E5@jedsmith.org> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <4B4CC951.80309@mtcc.com> <1DFA025F-1E21-4B22-AF4C-B4575682556C@ianai.net> <6F43E6D0-A9BD-45C0-80F8-9A2A6F11B2E5@jedsmith.org> Message-ID: <20100112205901.GC23214@hesketh.com> on Tue, Jan 12, 2010 at 02:59:55PM -0500, Jed Smith wrote: > 4. For other reasons laid out in this thread, PTR is not the best choice. > Additionally, administrators of mailservers who have no idea what a PTR > is -- although their entry fee to the Internet mail system is debatable > it will not be discussed here -- are now punished by blocklists like > SORBS and Trend Micro with the simple crime of not knowing to PTR their > mail server with something that screams "static allocation, not CPE". Mild correction: it's FAR BETTER to use something that screams I AM A MAIL SERVER WITH A LEGITIMATE PURPOSE AND A COMPETENT ADMIN rather than just using yet another generic static naming convention. :-) Because using generic static naming is falling victim to the rather baseless assumption that all statics should be allowed to send mail, which is just ridiculous. We've got a /27 (we're a web app dev shop) and only one of those IPs is a mail source, one is a NAT, one is a VPN box, several others run Web servers and other services, and so could possibly emit mail but likely only to us, and we can always whitelist if need be. I assume that the case is similar in other organizations; their static IPs far outnumber their canonical mail servers. Of course, I asked for appropriate custom PTRs for all of them, but still - the point stands, especially for those who think that generic static PTRs are sufficient for a modern mail infrastructure. I don't care who your ISP is, I care who you supposedly are, because if I see that your mail server (or other hosts on your network) are infected, compromised, or otherwise sources of abuse directed at my network, I want to deal with /you/, not with your upstream's abuse desk triage. > I note, with a heavy hand, that there are no widely-disseminated > standards governing the reverse DNS of an Internet host other than this > draft, but administrators make decisions on it anyway. On that and on a wide variety of other criteria, yes. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From rsk at gsp.org Tue Jan 12 15:09:27 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 12 Jan 2010 16:09:27 -0500 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> Message-ID: <20100112210927.GA6931@gsp.org> On Tue, Jan 12, 2010 at 10:48:31AM -0800, Brian Keefer wrote: > I wouldn't say that necessarily accurate. I could be considered > part of the "anti-spam crowd", seeing as that's my line of work. > I think DULs are a really dumb way to block spam. Making a binary > decision off of information that's wrong as often as it's right it's > a great way to create collateral damage and just generally cause more > headaches for everyone. I've done a little bit of work in the anti-spam area as well (starting around 1983) and I can tell you that your viewpoint about DULs is roughly half a decade out of date. With the rise of 100M+ zombies, it has long since become a best practice to block outright anything that looks like, smells like, feels like it's not a real live mail server. (And many things that are.) One of the best ways to do that is to reject all mail from anything without a PTR, and a lot of things *with* PTRs matching certain well-known/well-understood patterns. Hence the work of various DULs, the EnemiesList project, and others. They have long since proven their marked superiority to other methods in terms of accuracy, resource cost, maintainability, scalability, resistance to countermeasures, and other applicable metrics. They're some of the very best tools we have, and anyone with even a little bit of clue is using them for all they're worth. Default-permit mail system policies which don't implement these are years behind best current practices. PTR allocation policies which pretend that this doesn't work or shouldn't work or won't work are years behind best current practices. As an aside, there is no such thing as "collateral damage" in this context, because there is no such thing as "damage". This point was discussed extensively on the IRTF-ASRG mailing list nearly two years ago in the discussion over Chris Lewis's RFC on DNSBL operational procedures, and I believe I presented a clinching set of arguments there as to why that's the case -- certainly enough to get that language removed from the draft. You might want to read that list's archives to see why that phrase has absolutely no place in any anti-spam discussion. I suggest that further discussion of this move to spam-l, where it's probably much more appropriate than NANOG. ---Rsk From darkmoon at vt.edu Tue Jan 12 15:14:17 2010 From: darkmoon at vt.edu (Dave Martin) Date: Tue, 12 Jan 2010 16:14:17 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B4CC951.80309@mtcc.com> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <4B4CC951.80309@mtcc.com> Message-ID: <20100112211417.GC12541@vt.edu> On Tue, Jan 12, 2010 at 11:11:13AM -0800, Michael Thomas wrote: > On 01/12/2010 10:48 AM, Dave Martin wrote: > >On Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote: > >>On Jan 11, 2010, at 11:11 AM, Jon Lewis wrote: > >>The vibe I got from a number of administrators I talked to about it was "why > >>would a standards document assume an IPv4/IPv6 unicast address is a residential > >>customer with a modem, forcing those with allocations to prove that they are > >>not residentially allocated rather than the other way around?" > > > >Because a default allow policy doesn't work in today's environment. > > > >Blocking generic and residential addresses is the single most effective > >thing we've ever done to reduce spam. > > Really? You mean that if you stopped doing this you'd have trillions, > or quadrillions of spams per day instead now? I'm skeptical. We did stop. We used to maintain our own list. Dealing with it, and the support issues it caused ate up a lot of time. It stopped about half of the mess that was offered to us. Right now we're quarantining and blocking via other means a lot more than we used to. And no, it doesn't mean we get trillions or quadrillions of spams a day now. No single method we use stops even 60%. (and probably not even that.) Now we can point the users at our vendor, and use the time for other things. We do get more spam, but we're probably coming out ahead in cost/return sense. I'll note that we blocked generic names, as well as obvious end user names. I'd love a more standard nameing policy. -- Dave ----- Nobody believed that I could build a space station here. So I built it anyway. It sank into the vortex. So I built another one. It sank into the vortex. The third station burned down, fell over then sank into the vortex. The fourth station just vanished. And the fifth station, THAT stayed! From bruce.curtis at ndsu.edu Tue Jan 12 17:13:30 2010 From: bruce.curtis at ndsu.edu (Bruce Curtis) Date: Tue, 12 Jan 2010 17:13:30 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> <29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> Message-ID: <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu> On Jan 6, 2010, at 3:56 PM, Brian Johnson wrote: >> -----Original Message----- >> From: Brian Keefer [mailto:chort at smtps.net] >> Sent: Wednesday, January 06, 2010 3:12 PM >> To: Brian Johnson >> Cc: NANOG list >> Subject: Re: I don't need no stinking firewall! > > >> >> IMO you're better off making sure only the services you intend to >> provide are listening, and that those services are hardened >> appropriately for public exposure. > > OK. This is obvious to anyone with experience in these things. But I > also believe in a layered approach. It never hurts to add more layers to > prevent human error or even internal breaches as the different systems > are under the control of different equipment (servers, routers, > switches, security devices). It's like two supports holding up something > without knowing if the other one is doing its job. Both need to pull the > full weight in case the other fails. I disagree. "Never" is pretty absolute. If that were true there would be no limit to the number of layers. Realistically I have experienced the harm from having firewalls in the network path. I have witnessed too many video sessions that either couldn't be started or had the sessions dropped prematurely because of firewalls. When the worms were infecting machines a couple of years ago our network was robust and stable and I identified and blocked infected machines quickly. Other universities shut down their residence halls or large portions of their network because their firewalls rolled over and died otherwise from all of the scanning from inside their network. I have talked to universities who consider the firewall the canary of the network world, its the first box in the network to cease functioning when there is a problem. Others have already mentioned the troubleshooting nightmares that firewalls generate, I would consider that a harm also. --- Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University From lukasz at bromirski.net Tue Jan 12 17:13:38 2010 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Wed, 13 Jan 2010 00:13:38 +0100 Subject: BGP testbed tools In-Reply-To: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> References: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> Message-ID: <4B4D0222.6080307@bromirski.net> On 2010-01-12 21:27, Ben Jencks wrote: > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. Use libbgpdump from ris.ripe.net to get raw data from http://data.ris.ripe.net/ (you're looking for newest bview file), and dump them using bgpdump to something easily to parse. Then using bgpsimple (from googlecode) simulate a peer with specific number of prefixes advertised - up to the limit of the contents of the file. You can spoof next-hop, AS, etc. As for the attribute manipulation, fire up a couple of VMWare/VirtualBox/vimage instances with quagga/openbgpd to accept the prefixes from bgpsimple and mangle them in some manner. Here you go. -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end. | http://lukasz.bromirski.net From jlewis at packetnexus.com Tue Jan 12 19:31:34 2010 From: jlewis at packetnexus.com (Jason Lewis) Date: Tue, 12 Jan 2010 20:31:34 -0500 Subject: BGP testbed tools In-Reply-To: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> References: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> Message-ID: <554140e81001121731n65335dd5h1f5c6cd6baa3b7a@mail.gmail.com> This might do what you need: MDFMT - MRT dump file manipulation toolkit http://caia.swin.edu.au/urp/bgp/tools.html On Tue, Jan 12, 2010 at 3:27 PM, Ben Jencks wrote: > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. > > Thanks! > > -Ben Jencks > > From nonobvious at gmail.com Tue Jan 12 19:50:37 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Tue, 12 Jan 2010 17:50:37 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <201001080722.o087Mfb1010074@aurora.sol.net> References: <201001080722.o087Mfb1010074@aurora.sol.net> Message-ID: <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> A password recovery method I've found very frustrating is to use the serial number or similar value that's on a label on the bottom of the equipment. It's just fine for desktop hardware - but for rack-mounted gear, it's not uncommon to find out that you need this information *after* somebody's racked and stacked the hardware, and therefore you either need to unscrew it (if it was screwed into the rack) or drag it out (if it wasn't screwed in for some reason like missing wing-brackets or 23-inch telco racks or random junk piled on top of it, etc.), and possibly uncable it as well, depending on how much slack is in the cabling, and you almost certainly want to power it down first, and you need to have enough flashlights and reading glasses to deal with reading the bottom of the equipment lying down on the floor of the data center. Yes, you *should* be able to find the serial number by looking in the accurate complete up-to-date spreadsheet of equipment inventory records, or at least the previous-user-printed Dymo-label on the front of the box. But if you had that quality of records, you probably wouldn't need to be running password recovery anyway. (Disclaimer: I'm currently working in a development lab, not operations, so ideally this doesn't reflect the state of our production data centers :-) Most of the time it doesn't reflect our lab either, but occasionally it does, and of course loaner equipment often arrives in random condition. From Valdis.Kletnieks at vt.edu Tue Jan 12 22:03:46 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Jan 2010 23:03:46 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: Your message of "Tue, 12 Jan 2010 17:50:37 PST." <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> Message-ID: <13915.1263355426@localhost> On Tue, 12 Jan 2010 17:50:37 PST, Bill Stewart said: > A password recovery method I've found very frustrating is to use the > serial number or similar value that's on a label on the bottom of the > equipment. Related pet peeve: Inventory and asset control people that stick a sticker on hardware and then expect to be able to scan the barcode at a later date. Works fine if the barcode sticker actually ends up facing the front or the back of the rack. But occasionally, the sticker ends up stuck on an empty space on the printed circuit board of a upgrade blade that's plugged into a chassis... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From math at sizone.org Tue Jan 12 23:24:16 2010 From: math at sizone.org (Ken Chase) Date: Wed, 13 Jan 2010 00:24:16 -0500 Subject: more news from Google Message-ID: <20100113052416.GB12526@sizone.org> I must say I'll have to take a step back from my previous position/postings having read this article. I just can't figure out their /ANGLE/. :) http://googleblog.blogspot.com/2010/01/new-approach-to-china.html Well played, google? /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From ip at ioshints.info Wed Jan 13 00:51:38 2010 From: ip at ioshints.info (Ivan Pepelnjak) Date: Wed, 13 Jan 2010 07:51:38 +0100 Subject: BGP testbed tools In-Reply-To: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> References: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> Message-ID: <001301ca941c$db6c8d80$9245a880$@info> This is how you can do it with Quagga: http://wiki.nil.com/Use_Quagga_to_generate_BGP_routes You could write a Perl (or whatever your favorite scripting language is) script to get Quagga/IOS configuration from live BGP data, but it would be non-trivial and the resulting configuration would be enormous. I know there was a similar discussion months ago on the NANOG mailing list; browse the archives. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -----Original Message----- > From: Ben Jencks [mailto:ben at bjencks.net] > Sent: Tuesday, January 12, 2010 9:28 PM > To: nanog at nanog.org > Subject: BGP testbed tools > > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. > > Thanks! > > -Ben Jencks > From sfouant at shortestpathfirst.net Wed Jan 13 01:05:01 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 13 Jan 2010 02:05:01 -0500 Subject: more news from Google In-Reply-To: <20100113052416.GB12526@sizone.org> References: <20100113052416.GB12526@sizone.org> Message-ID: <00af01ca941e$ba3c6390$2eb52ab0$@net> I for one would be really happy to see them follow through with this. I was very disappointed when they agreed to censor search results, although I can understand why they did so from a business standpoint... it seemed to go against the google mantra of "do no evil"... I'm skeptical if they'll go through with it... Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D > -----Original Message----- > From: Ken Chase [mailto:math at sizone.org] > Sent: Wednesday, January 13, 2010 12:24 AM > To: nanog at nanog.org > Subject: more news from Google > > I must say I'll have to take a step back from my previous > position/postings > having read this article. > > I just can't figure out their /ANGLE/. :) > > http://googleblog.blogspot.com/2010/01/new-approach-to-china.html > > Well played, google? > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS > @151 Front St. W. From sfouant at shortestpathfirst.net Wed Jan 13 01:14:38 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 13 Jan 2010 02:14:38 -0500 Subject: BGP testbed tools In-Reply-To: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> References: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> Message-ID: <00b001ca9420$11f69f00$35e3dd00$@net> > -----Original Message----- > From: Ben Jencks [mailto:ben at bjencks.net] > Sent: Tuesday, January 12, 2010 3:28 PM > To: nanog at nanog.org > Subject: BGP testbed tools > > This is obviously a rookie question, but I haven't found anything by > searching. I'm looking to set up a small testbed to simulate our > internal network topology, and I want to have a realistic BGP table > from the fake "upstream" routers. Ideally what I'd like to do is dump > the BGP table from our production routers, strip the immediate > neighbor AS, and load the table into Quagga or OpenBGPD to advertise. > I'm running into two problems: how do you dump BGP tables in a > machine-parseable format from IOS, and how do you make the route > server advertise the routes as they were in the original table, > including the full AS-path, communities, etc? If Quagga/OpenBGPD > aren't the right tools, I'm happy to use something else. > > This seems like it would be a pretty standard thing to do, but none of > the tools I've found seem aimed at this sort of testbed. Cisco has a tool called RouteM which they use for lots of BGP scalability testing. I used it a lot back in my testing days at UU. Basically you just saved the contents of "show ip route" and you could replay that using the tool. Man I wish I saved that tool somewhere, it was incredibly valuable. You might be able find someone out there that still has this tool. And please get me an extra copy if you do manage to find it ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From bbillon-ml at splio.fr Wed Jan 13 01:18:36 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Wed, 13 Jan 2010 08:18:36 +0100 Subject: more news from Google In-Reply-To: <20100113052416.GB12526@sizone.org> References: <20100113052416.GB12526@sizone.org> Message-ID: <4B4D73CC.9070203@splio.fr> Seems logical, after all. Considering the (bad) performances of Google search engine in China compared to Chinese competitors, and considering the fact that wouldn't change a bit in the future, closing offices wouldn't be a bad thing. That doesn't mean closing R&D centers. Ben Le 13/01/2010 06:24, Ken Chase a ?crit : > I must say I'll have to take a step back from my previous position/postings > having read this article. > > I just can't figure out their /ANGLE/. :) > > http://googleblog.blogspot.com/2010/01/new-approach-to-china.html > > Well played, google? > > /kc > From gordslater at ieee.org Wed Jan 13 01:56:17 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 13 Jan 2010 07:56:17 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> Message-ID: <1263369377.32002.27.camel@ub-g-d2> Dymo-style solutions are somewhat lacking when it comes to some complex boxes. Equipment configs, mods, firmware versions, etc can all be fitted onto a nice big sheet that can be slipped back into the rack without much problem in most cases A nifty solution I often claim to have invented in the last century is to spray-adhesive an A4 (or equivalent US size) plastic pocket/"punched pocket" on the TOP face of the equipment before you slide it in, such that a single piece of A4 just protrudes from the front of the rack when you use a self-adhesive tab on it's TOP edge. (the TOP 's above are emphasized, ignore them at your peril; in the first case the plastic will be destroyed the first time the equipment is de-racked and in the second the tab will pull off easily. Problems can be prevented by placing two tabs on the paper, one on each side, exactly over each other.) The trick, to ensure subsequent re-insertion (which is much harder than it seems if you don't) is to also firmly stick a tab to the UPPER INSIDE of the plastic wallet opening. To re-insert, gently lift the plastic tab up. All of this takes up under a millimeter and (unless the equipment designer was drunk) doesn't affect ventilation. On rolling ships, however, the papers require a bit of insulation tape across adjacent case-fronts after each use. /end_stationary_geek_mode pics off-list on request if that doesn't make sense. Gord On Tue, 2010-01-12 at 17:50 -0800, Bill Stewart wrote: > A password recovery method I've found very frustrating is to use the > serial number or similar value that's on a label on the bottom of the > equipment. It's just fine for desktop hardware - but for rack-mounted > gear, it's not uncommon to find out that you need this information > *after* somebody's racked and stacked the hardware, and therefore you > either need to unscrew it (if it was screwed into the rack) From martin at hotze.com Wed Jan 13 02:07:28 2010 From: martin at hotze.com (Martin Hotze) Date: Wed, 13 Jan 2010 09:07:28 +0100 Subject: SORBS on autopilot? In-Reply-To: References: Message-ID: <275E689A52D3FD4E922743D02EAEA8FA2C2B63@server1.hotze.local> Oh well, there's an approach where one splits users into "residential" and "business", meaning that "residential" is only downloading, surfing, ... without need of providing any services "back" to the 'net. At least with IPv6 one has to rethink this position as there finally is end-to-end communication and everybody with a limited upload bandwidth can multicast his content to half of the world (crossing fingers). inetnum: 82.150.208.0 - 82.150.208.255 netname: AT-HOTZE-NET descr: hotze.com GmbH descr: DSL wholesale country: AT Our position is that we sell internet access at the IP level, a pure IP pipe - nothing less and nothing more. The customer can have his own PTR-record with a name matching his domain, he can set up a server or not. All IPs are static (no need to hassle with DHCP pools, matching IP to time&date to user for law enforcment). Every customer is served the same according to his service plan. And we don't make any decisions wether the customer is "residential" or "business" - simple as that. I won't feel happy with an ISP who wants to make this decision for me. greetings, martin AS8596 / hotze.com GmbH / Austria > -----Original Message----- > Date: Tue, 12 Jan 2010 12:42:58 -0500 > From: Steven Champeon > Subject: Re: SORBS on autopilot? > To: nanog at nanog.org (...) > just to pick a few. At the very least, customer-assigned blocks ought to > have a SWIP and a comment showing whether they're dynamic or static, > residential or business class, and so forth. A surprising example, given > the paucity of such examples in the .pl TLD, is dialog.net.pl, which does > exactly that: > > inetnum: 87.105.24.0 - 87.105.24.255 > netname: DIALOGNET > descr: Static Broadband Services > descr: Telefonia Dialog S.A. - Dialog Telecom > country: PL > > inetnum: 62.87.215.0 - 62.87.215.255 > netname: DIALOGNET > descr: Dynamic Broadband Services > descr: Telefonia Dialog S.A. - Dialog Telecom > country: PL > > So, if the Poles (well, some Poles) can do it, why can't we simply end > the endless back and forth over why SORBS is evil, and start adopting > sane and clear naming conventions for PTRs? Given how easy it is to > modify a $GENERATE statement, I should think you've spent far more > energy on arguing about why you're being wronged than it would have > taken to fix your problem. From dennis-lists at thenose.net Wed Jan 13 06:23:06 2010 From: dennis-lists at thenose.net (Dennis Dayman) Date: Wed, 13 Jan 2010 07:23:06 -0500 Subject: Senderbase contact In-Reply-To: References: Message-ID: I will forward your email to the admin them of senderbase. -Dennis On Jan 12, 2010, at 10:36 AM, Drew Weaver wrote: > Any Senderbase contacts on list? I am having problems getting some questions answered through normal channels. > > thanks, > -Drew > From mark at streamservice.nl Wed Jan 13 07:35:00 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 13 Jan 2010 14:35:00 +0100 Subject: SORBS contact Message-ID: <001f01ca9455$343e2760$9cba7620$@nl> Hello, I did try to reach someone at SORBS using their contact forms on the website. Somehow no action was taken and I also didn't get a response. Could someone from SORBS contact me? I need an issue to be resolved. With kind regards, Mark Scholten SinnerG BV From rsk at gsp.org Wed Jan 13 08:30:08 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 13 Jan 2010 09:30:08 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B4CC951.80309@mtcc.com> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112184859.GB12541@vt.edu> <4B4CC951.80309@mtcc.com> Message-ID: <20100113143008.GA9408@gsp.org> On Tue, Jan 12, 2010 at 11:11:13AM -0800, Michael Thomas wrote: >> Blocking generic and residential addresses is the single most effective >> thing we've ever done to reduce spam. > > Really? You mean that if you stopped doing this you'd have trillions, > or quadrillions of spams per day instead now? I'm skeptical. The original statement is accurate, and becomes nearly an absolute if qualified with the addition of "...from zombies". This is common knowledge among everyone with sufficient $clue in the field, and has been for most of the past decade. Remaining research/discussion/debate is now focused on how best to enumerate such space, either by PTR or by allocation. Given that the zombie population continues to monotonically increase with no sign that the trend will reverse, and given that precious few owner/operators of such space have taken appropriate, timely and effective actions to staunch the flow of outbound abuse from the zombies within their operations, it seems reasonable that this tactic will remain extremely useful into the forseeable future. Once again, I direct those interested to the spam-l list (and its archives) where copious discussion on these points may be found, and is much more on-topic than here on NANOG. ---Rsk From bjohnson at drtel.com Wed Jan 13 09:07:52 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 13 Jan 2010 09:07:52 -0600 Subject: I don't need no stinking firewall! In-Reply-To: <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan><828F4485-EB8C-4D52-A2F9-89A0C06235B6@arbor.net><0E7725B7-603B-4C6E-80B5-4CF6D3EEE802@arbor.net><1262752784-sup-6499@sfo.thejof.com><6eb799ab1001052347s6faddue4e9f6c1a5fea6d5@mail.gmail.com><39147642-D10A-4352-BDCC-9291D4BCEAAC@arbor.net><39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net><29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan><29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan><24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net><29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu> Message-ID: <29A54911243620478FF59F00EBB12F4701BFF4A0@ex01.drtel.lan> > -----Original Message----- > From: Bruce Curtis [mailto:bruce.curtis at ndsu.edu] > Sent: Tuesday, January 12, 2010 5:14 PM > To: NANOG list > Subject: Re: I don't need no stinking firewall! > >> > >> IMO you're better off making sure only the services you intend to > >> provide are listening, and that those services are hardened > >> appropriately for public exposure. > > > > OK. This is obvious to anyone with experience in these things. But I > > also believe in a layered approach. It never hurts to add more layers > to > > prevent human error or even internal breaches as the different > systems > > are under the control of different equipment (servers, routers, > > switches, security devices). It's like two supports holding up > something > > without knowing if the other one is doing its job. Both need to pull > the > > full weight in case the other fails. > > > I disagree. "Never" is pretty absolute. If that were true there > would be no limit to the number of layers. I'm with you, but you get my sentiment without being too literal. :) > > Realistically I have experienced the harm from having firewalls in > the network path. I've experienced harm from routers in the network path. If you use the tool correctly and with full knowledge of its limitations, then you will be able to avoid "harm" and add functionality/security/value... whatever the goal is. > > I have witnessed too many video sessions that either couldn't be > started or had the sessions dropped prematurely because of firewalls. So putting a firewall that can't handle your traffic in your network path sounds like a bad idea FOR YOU. :) > > When the worms were infecting machines a couple of years ago our > network was robust and stable and I identified and blocked infected > machines quickly. Other universities shut down their residence halls > or large portions of their network because their firewalls rolled over > and died otherwise from all of the scanning from inside their network. I remember hearing about this type of thing. I'm sorry for this learning lesson, but that doesn't mean that firewalls are "bad" or that stateful inspection is "bad". It means that it was a bad choice for your environment. > I have talked to universities who consider the firewall the canary of > the network world, its the first box in the network to cease > functioning when there is a problem. I think this type of assertion is just folly. I would say that some universities (full of all those really smart people ;) should be able to discern that a monkey wrench was being used to do the job of a hammer, or vice versa. The problem was not the tool, but the person who used the wrong tool for the job at hand. > > Others have already mentioned the troubleshooting nightmares that > firewalls generate, I would consider that a harm also. > I've had one of those "troubleshooting nightmares" before. It was due to MY IGNORANCE of what I was doing. The firewall is not causing the nightmare. Ignorance is. My last statement on this thread is that if you use a tool in the wrong way, you will either break the tool, or the item you are using it on. If you don't know how to use a tool, learn before you try. If you try first, you will learn later (Here comes that nightmare) how the tool does/doesn't work. Specific examples of failure are not failures of the device, but failures of the implementer(s) to correctly use the tool with the obvious exception of vendors not being truthful about the tools capabilities. Please no more examples of specific failures of firewalls. We all know that they were designed by Satan himself to destroy our networks and bring about the Antichrist. ;) - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From tdurack at gmail.com Wed Jan 13 09:24:41 2010 From: tdurack at gmail.com (Tim Durack) Date: Wed, 13 Jan 2010 10:24:41 -0500 Subject: I don't need no stinking firewall! In-Reply-To: <29A54911243620478FF59F00EBB12F4701BFF4A0@ex01.drtel.lan> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> <29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu> <29A54911243620478FF59F00EBB12F4701BFF4A0@ex01.drtel.lan> Message-ID: <9e246b4d1001130724h6a28a6aeo47584fc6f3d28e3b@mail.gmail.com> Lots of interesting technical information in this thread. Mixed with a healthy dose of religion/politics :-) I suspect that most people are going to keep doing what they are doing. In our environment, at the transport level, we have moved from stateful towards stateless, as it has proved to be operationally simpler and more resilient. At the same time some of our application people have seen the need to put their servers behind stateful "Layer 7" firewalls (I say why stop at Layer 7?) Here is a thought experiment: Replace all the routers on the Internet with stateful firewalls. What happens? Replace all the stateful firewalls on the Internet with stateless packet filters. What is the result? -- Tim:> Sent from Brooklyn, NY, United States From vern at ee.lbl.gov Wed Jan 13 09:42:33 2010 From: vern at ee.lbl.gov (vern at ee.lbl.gov) Date: Wed, 13 Jan 2010 07:42:33 -0800 Subject: ICSI Netalyzr launch #2 Message-ID: <201001131542.o0DFgXra021480@pork.ICSI.Berkeley.EDU> Folks, you may recall that last June we released a beta version of Netalyzr, a Java applet you can run by surfing to netalyzr.icsi.berkeley.edu (or to netalyzr.com). It measures a bunch of the properties of an end user's network access, particularly looking for transparent modifications (e.g., hidden proxies or blocking), connectivity restrictions, DNS modifications, and some security issues (e.g., whether the DNS resolver is vulnerable to the Kaminsky attack). You can see a sample report at: http://netalyzr.icsi.berkeley.edu/restore/id=example-session That launch was fairly successful (~50K users). Since then we've been working on a bunch of improvements, and today we've gone out of beta with an updated version, so you may be hearing about reports your customers have gotten from it. Also, as Netalyzr forms the foundation for a large-scale measurement study of the Internet's edge, to the degree that you pass along the word so that more people run it, that would be highly helpful with us gathering comprehensive data for the project. Thanks, Vern Vern Paxson Associate Professor EECS Department 737 Soda Hall - MC 1776 University of California Berkeley, CA, USA 94720-1776 +1 510 643-4209 vern at eecs.berkeley.edu From richcasto at gmail.com Wed Jan 13 09:44:54 2010 From: richcasto at gmail.com (Rich Casto) Date: Wed, 13 Jan 2010 10:44:54 -0500 Subject: cable provider problems yesterday around 1pm EST? Message-ID: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> Is anyone aware of any routing problems with any cable providers yesterday around 1pm EST? Thanks! -- Rich From patrick at ianai.net Wed Jan 13 10:12:11 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Jan 2010 11:12:11 -0500 Subject: more news from Google In-Reply-To: <4B4D73CC.9070203@splio.fr> References: <20100113052416.GB12526@sizone.org> <4B4D73CC.9070203@splio.fr> Message-ID: <19A9F5BD-6369-40FA-879B-083D0306CFFB@ianai.net> On Jan 13, 2010, at 2:18 AM, Benjamin Billon wrote: > Seems logical, after all. > > Considering the (bad) performances of Google search engine in China compared to Chinese competitors, and considering the fact that wouldn't change a bit in the future, closing offices wouldn't be a bad thing. > That doesn't mean closing R&D centers. Baidu has ~63%, Google has ~31%. Q4 2009 was Google's best Q in China ever. While I admit that 31% is not the market share Google usually enjoys, it certainly is not horrible. Most companies would love to have 1/3 of a market as big and growing as China. Oh, and I prefer Google over Baidu when I'm in China (which is frequently). Their results are better, and I can get some in English. :) -- TTFN, patrick > Le 13/01/2010 06:24, Ken Chase a ?crit : >> I must say I'll have to take a step back from my previous position/postings >> having read this article. >> >> I just can't figure out their /ANGLE/. :) >> >> http://googleblog.blogspot.com/2010/01/new-approach-to-china.html >> >> Well played, google? >> >> /kc >> > From patrick at ianai.net Wed Jan 13 10:14:12 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Jan 2010 11:14:12 -0500 Subject: more news from Google In-Reply-To: <00af01ca941e$ba3c6390$2eb52ab0$@net> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> Message-ID: <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> On Jan 13, 2010, at 2:05 AM, Stefan Fouant wrote: > I for one would be really happy to see them follow through with this. I was > very disappointed when they agreed to censor search results, although I can > understand why they did so from a business standpoint... it seemed to go > against the google mantra of "do no evil"... > > I'm skeptical if they'll go through with it... According to their spokesperson, they have already stopped censoring. That sounds a bit iffy to me. It's one thing to say "we want to stop censoring, and will pull out if you don't let us", and "we are breaking the law, nah, nah, nah". You don't like the law, don't do biz in that country. But blatantly breaking a law is bad joo-joo. -- TTFN, patrick >> -----Original Message----- >> From: Ken Chase [mailto:math at sizone.org] >> Sent: Wednesday, January 13, 2010 12:24 AM >> To: nanog at nanog.org >> Subject: more news from Google >> >> I must say I'll have to take a step back from my previous >> position/postings >> having read this article. >> >> I just can't figure out their /ANGLE/. :) >> >> http://googleblog.blogspot.com/2010/01/new-approach-to-china.html >> >> Well played, google? >> >> /kc >> -- >> Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA >> Heavy Computing - Clued bandwidth, colocation and managed linux VPS >> @151 Front St. W. > > From fw at deneb.enyo.de Wed Jan 13 10:21:12 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 13 Jan 2010 17:21:12 +0100 Subject: more news from Google In-Reply-To: <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> (Patrick W. Gilmore's message of "Wed, 13 Jan 2010 11:14:12 -0500") References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> Message-ID: <87zl4i6knb.fsf@mid.deneb.enyo.de> * Patrick W. Gilmore: > You don't like the law, don't do biz in that country. But blatantly > breaking a law is bad joo-joo. I think we all consider their approach to copyright law refreshing and useful, so there are certainly laws worth breaking. 8-) From smeuse at mara.org Wed Jan 13 10:23:23 2010 From: smeuse at mara.org (Steve Meuse) Date: Wed, 13 Jan 2010 11:23:23 -0500 Subject: cable provider problems yesterday around 1pm EST? In-Reply-To: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> References: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> Message-ID: <20100113162323.GB29245@mara.org> Rich Casto expunged (richcasto at gmail.com): > Is anyone aware of any routing problems with any cable providers yesterday > around 1pm EST? Thanks! I dare you to be more vague.... -Steve From mpetach at netflight.com Wed Jan 13 10:27:34 2010 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 13 Jan 2010 08:27:34 -0800 Subject: cable provider problems yesterday around 1pm EST? In-Reply-To: <20100113162323.GB29245@mara.org> References: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> <20100113162323.GB29245@mara.org> Message-ID: <63ac96a51001130827g3c4d0ef9v1ed6d6caeb02178d@mail.gmail.com> On Wed, Jan 13, 2010 at 8:23 AM, Steve Meuse wrote: > Rich Casto expunged (richcasto at gmail.com): > >> Is anyone aware of any routing problems with any cable providers yesterday >> around 1pm EST? ?Thanks! > > I dare you to be more vague.... > > -Steve Has anyone had any problems this past week. Y'know...'problems'...? Matt From setient at gmail.com Wed Jan 13 10:29:13 2010 From: setient at gmail.com (Ronald Cotoni) Date: Wed, 13 Jan 2010 11:29:13 -0500 Subject: cable provider problems yesterday around 1pm EST? In-Reply-To: <20100113162323.GB29245@mara.org> References: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> <20100113162323.GB29245@mara.org> Message-ID: <2f1d68351001130829p6b497ce4sedf4d85e9cca6cd2@mail.gmail.com> Were there any problems on the internet at 1 PM EST yesterday :) But honestly which provider and in what area? On Wed, Jan 13, 2010 at 11:23 AM, Steve Meuse wrote: > Rich Casto expunged (richcasto at gmail.com): > >> Is anyone aware of any routing problems with any cable providers yesterday >> around 1pm EST? ?Thanks! > > I dare you to be more vague.... > > -Steve > > > From ben at bjencks.net Wed Jan 13 10:35:29 2010 From: ben at bjencks.net (Ben Jencks) Date: Wed, 13 Jan 2010 11:35:29 -0500 Subject: BGP testbed tools In-Reply-To: <4B4D0222.6080307@bromirski.net> References: <64f649f41001121227x70045ac6tdd86af0c1bb7a66@mail.gmail.com> <4B4D0222.6080307@bromirski.net> Message-ID: <64f649f41001130835j7416d22dlee09ed2e6e73004a@mail.gmail.com> 2010/1/12 ?ukasz Bromirski : > On 2010-01-12 21:27, Ben Jencks wrote: >> This is obviously a rookie question, but I haven't found anything by >> searching. I'm looking to set up a small testbed to simulate our >> internal network topology, and I want to have a realistic BGP table >> from the fake "upstream" routers. Ideally what I'd like to do is dump >> the BGP table from our production routers, strip the immediate >> neighbor AS, and load the table into Quagga or OpenBGPD to advertise. >> I'm running into two problems: how do you dump BGP tables in a >> machine-parseable format from IOS, and how do you make the route >> server advertise the routes as they were in the original table, >> including the full AS-path, communities, etc? If Quagga/OpenBGPD >> aren't the right tools, I'm happy to use something else. > > Use libbgpdump from ris.ripe.net to get raw data from > http://data.ris.ripe.net/ (you're looking for newest bview file), > and dump them using bgpdump to something easily to parse. Then > using bgpsimple (from googlecode) simulate a peer with specific > number of prefixes advertised - up to the limit of the contents > of the file. You can spoof next-hop, AS, etc. As for the attribute > manipulation, fire up a couple of VMWare/VirtualBox/vimage instances > with quagga/openbgpd to accept the prefixes from bgpsimple and > mangle them in some manner. Thanks everyone. bgpsimple ended up being the tool I wanted, and I just used the RIPE data. If I was more adventurous I would have hooked Quagga up with a BGP session to the production routers and generated my own dumps, but the RIPE data was good enough for now. -Ben From tme at americafree.tv Wed Jan 13 10:38:28 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 13 Jan 2010 11:38:28 -0500 Subject: more news from Google In-Reply-To: <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> Message-ID: <4F25BB7F-2F86-4DEF-B8E2-2E7B987D8A2E@americafree.tv> On Jan 13, 2010, at 11:14 AM, Patrick W. Gilmore wrote: > On Jan 13, 2010, at 2:05 AM, Stefan Fouant wrote: > >> I for one would be really happy to see them follow through with >> this. I was >> very disappointed when they agreed to censor search results, >> although I can >> understand why they did so from a business standpoint... it seemed >> to go >> against the google mantra of "do no evil"... >> >> I'm skeptical if they'll go through with it... > > According to their spokesperson, they have already stopped censoring. > > That sounds a bit iffy to me. It's one thing to say "we want to > stop censoring, and will pull out if you don't let us", and "we are > breaking the law, nah, nah, nah". > I assume that this is coupled with the message that they will pull out of China. http://news.bbc.co.uk/2/hi/business/8455712.stm I think it is the modern corporate equivalent of recalling your ambassador. Regards Marshall > You don't like the law, don't do biz in that country. But blatantly > breaking a law is bad joo-joo. > > -- > TTFN, > patrick > > >>> -----Original Message----- >>> From: Ken Chase [mailto:math at sizone.org] >>> Sent: Wednesday, January 13, 2010 12:24 AM >>> To: nanog at nanog.org >>> Subject: more news from Google >>> >>> I must say I'll have to take a step back from my previous >>> position/postings >>> having read this article. >>> >>> I just can't figure out their /ANGLE/. :) >>> >>> http://googleblog.blogspot.com/2010/01/new-approach-to-china.html >>> >>> Well played, google? >>> >>> /kc >>> -- >>> Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA >>> Heavy Computing - Clued bandwidth, colocation and managed linux VPS >>> @151 Front St. W. >> >> > > > From Valdis.Kletnieks at vt.edu Wed Jan 13 10:39:22 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Jan 2010 11:39:22 -0500 Subject: SORBS on autopilot? In-Reply-To: Your message of "Wed, 13 Jan 2010 09:07:28 +0100." <275E689A52D3FD4E922743D02EAEA8FA2C2B63@server1.hotze.local> References: <275E689A52D3FD4E922743D02EAEA8FA2C2B63@server1.hotze.local> Message-ID: <6247.1263400762@localhost> On Wed, 13 Jan 2010 09:07:28 +0100, Martin Hotze said: > ... without need of providing any services "back" to the 'net. At > least with IPv6 one has to rethink this position as there finally is > end-to-end communication "as we finally *return to* end-to-end communication". An important distinction. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From richcasto at gmail.com Wed Jan 13 10:45:59 2010 From: richcasto at gmail.com (Rich Casto) Date: Wed, 13 Jan 2010 11:45:59 -0500 Subject: cable provider problems yesterday around 1pm EST? In-Reply-To: <2f1d68351001130829p6b497ce4sedf4d85e9cca6cd2@mail.gmail.com> References: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> <20100113162323.GB29245@mara.org> <2f1d68351001130829p6b497ce4sedf4d85e9cca6cd2@mail.gmail.com> Message-ID: <4946caa51001130845gefd737dx6a0db7901cb0a3a3@mail.gmail.com> We experienced connectivity loss from both our Level 3 and AT&T connections to our telecommuter population who primarily use the following cable providers: Time-Warner (RoadRunner), Cox, and Comcast. Our AT&T circuits go into NYC and our Level 3 goes into Newark, NJ. -- Rich On Wed, Jan 13, 2010 at 11:29 AM, Ronald Cotoni wrote: > Were there any problems on the internet at 1 PM EST yesterday :) But > honestly which provider and in what area? > > On Wed, Jan 13, 2010 at 11:23 AM, Steve Meuse wrote: > > Rich Casto expunged (richcasto at gmail.com): > > > >> Is anyone aware of any routing problems with any cable providers > yesterday > >> around 1pm EST? Thanks! > > > > I dare you to be more vague.... > > > > -Steve > > > > > > > From jeje at jeje.org Wed Jan 13 10:52:54 2010 From: jeje at jeje.org (=?ISO-8859-1?Q?J=E9r=F4me_Fleury?=) Date: Wed, 13 Jan 2010 17:52:54 +0100 Subject: more news from Google In-Reply-To: <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> Message-ID: <80b7d9f61001130852n70f88e46mc53dff01d9bad5e0@mail.gmail.com> On Wed, Jan 13, 2010 at 17:14, Patrick W. Gilmore wrote: > On Jan 13, 2010, at 2:05 AM, Stefan Fouant wrote: > >> I for one would be really happy to see them follow through with this. ?I was >> very disappointed when they agreed to censor search results, although I can >> understand why they did so from a business standpoint... it seemed to go >> against the google mantra of "do no evil"... >> >> I'm skeptical if they'll go through with it... > > According to their spokesperson, they have already stopped censoring. They probably haven't yet http://images.google.cn/images?hl=zh-CN&um=1&sa=1&q=tiananmen+square+protest&btnG=Google+??&aq=0&oq=tian&start=0 http://images.google.com/images?hl=fr&source=hp&q=tiananmen+square+protest&btnG=Recherche+d%27images&gbv=2&aq=1&oq=tian From paul at telcodata.us Wed Jan 13 10:56:23 2010 From: paul at telcodata.us (Paul Timmins) Date: Wed, 13 Jan 2010 11:56:23 -0500 Subject: more news from Google In-Reply-To: <80b7d9f61001130852n70f88e46mc53dff01d9bad5e0@mail.gmail.com> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> <80b7d9f61001130852n70f88e46mc53dff01d9bad5e0@mail.gmail.com> Message-ID: <4B4DFB37.50905@telcodata.us> J?r?me Fleury wrote: > On Wed, Jan 13, 2010 at 17:14, Patrick W. Gilmore wrote: > >> On Jan 13, 2010, at 2:05 AM, Stefan Fouant wrote: >> >> >>> I for one would be really happy to see them follow through with this. I was >>> very disappointed when they agreed to censor search results, although I can >>> understand why they did so from a business standpoint... it seemed to go >>> against the google mantra of "do no evil"... >>> >>> I'm skeptical if they'll go through with it... >>> >> According to their spokesperson, they have already stopped censoring. >> > > They probably haven't yet > > http://images.google.cn/images?hl=zh-CN&um=1&sa=1&q=tiananmen+square+protest&btnG=Google+??&aq=0&oq=tian&start=0 > > http://images.google.com/images?hl=fr&source=hp&q=tiananmen+square+protest&btnG=Recherche+d%27images&gbv=2&aq=1&oq=tian > I'm thinking they have. http://images.google.cn/images?hl=zh-CN&um=1&sa=1&q=falun+gong&btnG=Google+%E6%90%9C%E7%B4%A2&aq=f&oq=&start=0 From jmamodio at gmail.com Wed Jan 13 11:01:49 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 13 Jan 2010 11:01:49 -0600 Subject: more news from Google In-Reply-To: <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> Message-ID: <202705b1001130901o63e799a8mb119a62213711eb8@mail.gmail.com> > You don't like the law, don't do biz in that country. ?But blatantly breaking a law is bad joo-joo. OT. Please don't say "joo-joo" every time the TechCrunch folks see that they get diarrhea Cheers Jorge PS what about all the property and copyright laws being supposedly broken over there ? From jesler at sourcefire.com Wed Jan 13 11:09:11 2010 From: jesler at sourcefire.com (Joel Esler) Date: Wed, 13 Jan 2010 12:09:11 -0500 Subject: more news from Google In-Reply-To: <202705b1001130901o63e799a8mb119a62213711eb8@mail.gmail.com> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> <202705b1001130901o63e799a8mb119a62213711eb8@mail.gmail.com> Message-ID: <206FF73F-5FD3-467E-8BA9-E1C1D27CB0D9@sourcefire.com> On Jan 13, 2010, at 12:01 PM, Jorge Amodio wrote: >> You don't like the law, don't do biz in that country. But blatantly breaking a law is bad joo-joo. > > OT. > Please don't say "joo-joo" every time the TechCrunch folks see that > they get diarrhea That is a horrible name for a product. Just saying. From msmith at internap.com Wed Jan 13 11:12:11 2010 From: msmith at internap.com (Michael Smith) Date: Wed, 13 Jan 2010 12:12:11 -0500 Subject: more news from Google In-Reply-To: <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> References: <20100113052416.GB12526@sizone.org><00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB0385A422@cx49.800onemail.com> >>> You don't like the law, don't do biz in that country. But blatantly breaking a law is bad joo-joo. Is it? http://images.google.cn/images?hl=zh-CN&um=1&sa=1&q=civil+disobedience -- TTFN, patrick >> -----Original Message----- >> From: Ken Chase [mailto:math at sizone.org] >> Sent: Wednesday, January 13, 2010 12:24 AM >> To: nanog at nanog.org >> Subject: more news from Google >> >> I must say I'll have to take a step back from my previous >> position/postings >> having read this article. >> >> I just can't figure out their /ANGLE/. :) >> >> http://googleblog.blogspot.com/2010/01/new-approach-to-china.html >> >> Well played, google? >> >> /kc >> -- >> Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA >> Heavy Computing - Clued bandwidth, colocation and managed linux VPS >> @151 Front St. W. > > From chort at smtps.net Wed Jan 13 11:14:22 2010 From: chort at smtps.net (Brian Keefer) Date: Wed, 13 Jan 2010 09:14:22 -0800 Subject: SORBS on autopilot? In-Reply-To: <20100112210927.GA6931@gsp.org> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> <20100112210927.GA6931@gsp.org> Message-ID: <8FC1F0E4-2D6E-4B2C-BD7C-E1CA57FBBA06@smtps.net> On Jan 12, 2010, at 1:09 PM, Rich Kulawiec wrote: > On Tue, Jan 12, 2010 at 10:48:31AM -0800, Brian Keefer wrote: >> I wouldn't say that necessarily accurate. I could be considered >> part of the "anti-spam crowd", seeing as that's my line of work. > >> I think DULs are a really dumb way to block spam. Making a binary >> decision off of information that's wrong as often as it's right it's >> a great way to create collateral damage and just generally cause more >> headaches for everyone. > > I've done a little bit of work in the anti-spam area as well (starting > around 1983) and I can tell you that your viewpoint about DULs is > roughly half a decade out of date. Well not to drag this into a meta-thread, but you're not the only one with experience. I've been doing this for well over a decade too, so have a great many of my colleagues, not only at my employer, but at competing companies. I can tell you that your view on this is far from universal. Parties who believe blanket blocking of IP space (sounds very 1999 to me, I was there, I did that stuff) is the best thing ever tend to not have access to high-quality reputation services and/or content-based analysis. See Joel Snyder's comments. BTW I'm not talking about anything Open Source. There are lots of ways to block a lot of spam, but most of the perceived "low-cost" ways block a non-trivial amount of wanted mail. Call it whatever you like, the fact remains that most organizations that value e-mail as a communication medium do care about missing those wanted messages. If it was as simple as blocking dynamic IP pools and spammy .TLDs, organizations would be doing that instead of paying $$$ for sophisticated services & software. That's the last I'll say on blanketing vs. intelligent blocking for this thread. PS We agree on quite a few subjects, just not this one. -- bk From bzs at world.std.com Wed Jan 13 11:21:06 2010 From: bzs at world.std.com (Barry Shein) Date: Wed, 13 Jan 2010 12:21:06 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <13915.1263355426@localhost> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> Message-ID: <19278.258.350014.385990@world.std.com> On January 12, 2010 at 23:03 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > On Tue, 12 Jan 2010 17:50:37 PST, Bill Stewart said: > > A password recovery method I've found very frustrating is to use the > > serial number or similar value that's on a label on the bottom of the > > equipment. > > Related pet peeve: Inventory and asset control people that stick a sticker on > hardware and then expect to be able to scan the barcode at a later date. Works > fine if the barcode sticker actually ends up facing the front or the back of > the rack. But occasionally, the sticker ends up stuck on an empty space on the > printed circuit board of a upgrade blade that's plugged into a chassis... > Sounds like RFID FTW! Actually, I have no idea if it'd work, maybe someone else does. Seems like it'd be nice to be able to just wand a rack and poof out comes a list of everything in it. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From standalone.sysadmin at gmail.com Wed Jan 13 11:55:00 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Wed, 13 Jan 2010 12:55:00 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <19278.258.350014.385990@world.std.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> <19278.258.350014.385990@world.std.com> Message-ID: <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> That would be excellent for both the administrator, and anyone walking down the row with a wand in their pocket. On Wed, Jan 13, 2010 at 12:21 PM, Barry Shein wrote: > > On January 12, 2010 at 23:03 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > ?> On Tue, 12 Jan 2010 17:50:37 PST, Bill Stewart said: > ?> > A password recovery method I've found very frustrating is to use the > ?> > serial number or similar value that's on a label on the bottom of the > ?> > equipment. > ?> > ?> Related pet peeve: ?Inventory and asset control people that stick a sticker on > ?> hardware and then expect to be able to scan the barcode at a later date. Works > ?> fine if the barcode sticker actually ends up facing the front or the back of > ?> the rack. ?But occasionally, the sticker ends up stuck on an empty space on the > ?> printed circuit board of a upgrade blade that's plugged into a chassis... > ?> > > Sounds like RFID FTW! > > Actually, I have no idea if it'd work, maybe someone else does. Seems > like it'd be nice to be able to just wand a rack and poof out comes a > list of everything in it. > > > -- > ? ? ? ?-Barry Shein > > The World ? ? ? ? ? ? ?| bzs at TheWorld.com ? ? ? ? ? | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD ? ? ? ?| Dial-Up: US, PR, Canada > Software Tool & Die ? ?| Public Access Internet ? ? | SINCE 1989 ? ? *oo* > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From Valdis.Kletnieks at vt.edu Wed Jan 13 12:06:26 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Jan 2010 13:06:26 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: Your message of "Wed, 13 Jan 2010 12:55:00 EST." <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> <19278.258.350014.385990@world.std.com> <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> Message-ID: <9504.1263405986@localhost> On Wed, 13 Jan 2010 12:55:00 EST, Matt Simmons said: > That would be excellent for both the administrator, and anyone walking > down the row with a wand in their pocket. Barry's right, for at least some scenarios. If I have an unauthorized somebody walking down the row with a wand in their pocket, the fact they have a wand in their pocket is the least of my problems. It's of course different if your biggest competitor is colo'd in the same room, two cages over. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jlewis at lewis.org Wed Jan 13 12:08:23 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 13 Jan 2010 13:08:23 -0500 (EST) Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> <19278.258.350014.385990@world.std.com> <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> Message-ID: We have an internally written app that allows us to either find where in the data center a server is, or pull up a rack and see what's in it. It wouldn't be a very big leap to assign each rack a bar code and have an app (you could even write it as a smartphone app) that scans the bar code and looks up what's in the rack. Of course, without access to (authentication is required) the web app front end for the database of what's where, just scanning the bar code wouldn't get you anything but a rack serial number...so you don't have to worry about random people scanning the rack bar code. BTW...a friend who works for a mostly failed .com patented something like this some years ago. I think his patent was actually for a system in which a bar code on the front of a server could be scanned by a portable device, and you'd get current system health information for that system. On Wed, 13 Jan 2010, Matt Simmons wrote: > That would be excellent for both the administrator, and anyone walking > down the row with a wand in their pocket. > > On Wed, Jan 13, 2010 at 12:21 PM, Barry Shein wrote: >> >> On January 12, 2010 at 23:03 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: >> ?> On Tue, 12 Jan 2010 17:50:37 PST, Bill Stewart said: >> ?> > A password recovery method I've found very frustrating is to use the >> ?> > serial number or similar value that's on a label on the bottom of the >> ?> > equipment. >> ?> >> ?> Related pet peeve: ?Inventory and asset control people that stick a sticker on >> ?> hardware and then expect to be able to scan the barcode at a later date. Works >> ?> fine if the barcode sticker actually ends up facing the front or the back of >> ?> the rack. ?But occasionally, the sticker ends up stuck on an empty space on the >> ?> printed circuit board of a upgrade blade that's plugged into a chassis... >> ?> >> >> Sounds like RFID FTW! >> >> Actually, I have no idea if it'd work, maybe someone else does. Seems >> like it'd be nice to be able to just wand a rack and poof out comes a >> list of everything in it. >> >> >> -- >> ? ? ? ?-Barry Shein >> >> The World ? ? ? ? ? ? ?| bzs at TheWorld.com ? ? ? ? ? | http://www.TheWorld.com >> Purveyors to the Trade | Voice: 800-THE-WRLD ? ? ? ?| Dial-Up: US, PR, Canada >> Software Tool & Die ? ?| Public Access Internet ? ? | SINCE 1989 ? ? *oo* >> >> > > > > -- > > LITTLE GIRL: But which cookie will you eat FIRST? > COOKIE MONSTER: Me think you have misconception of cookie-eating process. > > ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nathan at atlasnetworks.us Wed Jan 13 12:13:30 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 13 Jan 2010 10:13:30 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> <19278.258.350014.385990@world.std.com> <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> Message-ID: <11B064048F34FD4094CBA16FC04BE2198655E4C6@ex01> > -----Original Message----- > From: Matt Simmons [mailto:standalone.sysadmin at gmail.com] > Sent: Wednesday, January 13, 2010 9:55 AM > To: Barry Shein > Cc: nanog at nanog.org; Bill Stewart > Subject: Re: Default Passwords for World Wide Packets/Lightning Edge > Equipment > > That would be excellent for both the administrator, and anyone walking > down the row with a wand in their pocket. I'm not sure there's an attack vector utilizing inventory ID numbers. Even if there is, they can just as easily scan a barcode or read a label from that distance, so I'm not sure there's a huge difference. Best Regards, Nathan Eisenberg From bzs at world.std.com Wed Jan 13 12:15:37 2010 From: bzs at world.std.com (Barry Shein) Date: Wed, 13 Jan 2010 13:15:37 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> <19278.258.350014.385990@world.std.com> <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> Message-ID: <19278.3529.451527.311481@world.std.com> On January 13, 2010 at 12:55 standalone.sysadmin at gmail.com (Matt Simmons) wrote: > That would be excellent for both the administrator, and anyone walking > down the row with a wand in their pocket. All an RFID wand would give you is a unique id number for each tag in range which someone with access to an inventory database would look up to find the associated record for other info. It would be mostly useless info to "anyone...with a wand." I suppose my question is more in the realm of whether the environment is too RF noisy for RFIDs to be reliable, do such systems exist at that scale (can I buy 1,000 RFID tags and a wand? I'd think so but I don't know.) Also, would RF shielding in racks make it tricky to get a good wanding? Anyhow, just a thought. > > On Wed, Jan 13, 2010 at 12:21 PM, Barry Shein wrote: > > > > On January 12, 2010 at 23:03 Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) wrote: > > ??> On Tue, 12 Jan 2010 17:50:37 PST, Bill Stewart said: > > ??> > A password recovery method I've found very frustrating is to use the > > ??> > serial number or similar value that's on a label on the bottom of the > > ??> > equipment. > > ??> > > ??> Related pet peeve: ??Inventory and asset control people that stick a sticker on > > ??> hardware and then expect to be able to scan the barcode at a later date. Works > > ??> fine if the barcode sticker actually ends up facing the front or the back of > > ??> the rack. ??But occasionally, the sticker ends up stuck on an empty space on the > > ??> printed circuit board of a upgrade blade that's plugged into a chassis... > > ??> > > > > Sounds like RFID FTW! > > > > Actually, I have no idea if it'd work, maybe someone else does. Seems > > like it'd be nice to be able to just wand a rack and poof out comes a > > list of everything in it. > > > > > > -- > > ?? ?? ?? ??-Barry Shein > > > > The World ?? ?? ?? ?? ?? ?? ??| bzs at TheWorld.com ?? ?? ?? ?? ?? | http://www.TheWorld.com > > Purveyors to the Trade | Voice: 800-THE-WRLD ?? ?? ?? ??| Dial-Up: US, PR, Canada > > Software Tool & Die ?? ??| Public Access Internet ?? ?? | SINCE 1989 ?? ?? *oo* > > > > > > > > -- > > LITTLE GIRL: But which cookie will you eat FIRST? > COOKIE MONSTER: Me think you have misconception of cookie-eating process. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lyndon at orthanc.ca Wed Jan 13 12:23:59 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Wed, 13 Jan 2010 11:23:59 -0700 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <9504.1263405986@localhost> Message-ID: <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> > Barry's right, for at least some scenarios. If I have an unauthorized somebody > walking down the row with a wand in their pocket, the fact they have a wand in > their pocket is the least of my problems. Encrypt the data? From bzs at world.std.com Wed Jan 13 12:45:42 2010 From: bzs at world.std.com (Barry Shein) Date: Wed, 13 Jan 2010 13:45:42 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> Message-ID: <19278.5334.402304.466638@world.std.com> There seem to be a lot of misconceptions about RFID tags. I'm hardly an expert but I do know this much: RFID tags are generic, you don't put data into them unique to your application. All they are is a range of long serial numbers guaranteed to be globally unique, like ethernet macs more or less. You get an RFID tag, associate it with a piece of equipment, enter the tag serial number and other info INTO YOUR OWN INVENTORY DATABASE, and stick it on the equipment. Then you can later use a wand which can retrieve the RFID tag number at some distance, a few feet, think: supermarket checkout. The big advantage of RFIDs is that you don't need line of sight access like you do with bar codes, they use RF, radio frequency. Think: anti-shoplifting tags, most of them are basically RFID tags tho older ones don't have a unique id which is why they had to be physically removed or disabled. More modern anti-shoplifting systems wand the tag id (possibly via an externally printed bar code because point of sale (POS) systems aren't quite there yet) into the POS system so the anti-shoplifting exit system can look it up to see if the item has been paid for. A system which also used these to track equipment being removed from an area or building would be a relatively straightforward plus. It may not stop someone but it might know exactly what time it passed out the door to help with any investigation, or in a more secure environment one might have to mark the RFID tag as authorized to go out the door via some security process, or at least associate its leaving with a security badge or whatever id is used. It's much better than sliced bread for some apps except that they make for really lousy BLTs. On January 13, 2010 at 11:23 lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) wrote: > > Barry's right, for at least some scenarios. If I have an unauthorized somebody > > walking down the row with a wand in their pocket, the fact they have a wand in > > their pocket is the least of my problems. > > Encrypt the data? > -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lyndon at orthanc.ca Wed Jan 13 13:01:28 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Wed, 13 Jan 2010 12:01:28 -0700 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <19278.5334.402304.466638@world.std.com> Message-ID: > RFID tags are generic, you don't put data into them unique to your > application. Field programmable RFID-like tags do exist. They aren't common, but they're out there. From uk-nanog at dataway.ch Wed Jan 13 10:31:44 2010 From: uk-nanog at dataway.ch (Anthony Uk) Date: Wed, 13 Jan 2010 17:31:44 +0100 Subject: more news from Google In-Reply-To: <20100113052416.GB12526@sizone.org> References: <20100113052416.GB12526@sizone.org> Message-ID: <4B4DF570.6090100@dataway.ch> On 13.01.2010 06:24, Ken Chase wrote: > I must say I'll have to take a step back from my previous position/postings > having read this article. > > I just can't figure out their /ANGLE/. :) > > http://googleblog.blogspot.com/2010/01/new-approach-to-china.html > > Well played, google? > > /kc > From the article: "Second, we have evidence to suggest that a primary goal of the attackers was accessing the Gmail accounts of Chinese human rights activists. " I have orders of magnitude fewer users than gmail does, and often look at their mailboxes (with their consent, of course), but I still couldn't tell you the political position of any of them (apart from the politicians). The ability to automatically discern users' political positions from their inbox is not one that any email provider reasonably needs. Anthony -- | Anthony Uk | dataway GmbH | Tel. +41 44 299 9988 | | uk at dataway.ch | Hohlstrasse 216 | Fax +41 44 299 9989 | | PGP key ID 10DE1D2C | CH-8021 Zuerich | http://www.dataway.ch | From nanog at armorfirewall.com Wed Jan 13 12:51:41 2010 From: nanog at armorfirewall.com (George Imburgia) Date: Wed, 13 Jan 2010 13:51:41 -0500 (EST) Subject: RFID in datacenter (was Re: Default Passwords for World Wide Packets/Lightning Edge Equipment) In-Reply-To: <19278.5334.402304.466638@world.std.com> References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> Message-ID: On Wed, 13 Jan 2010, Barry Shein wrote: > The big advantage of RFIDs is that you don't need line of sight access > like you do with bar codes, they use RF, radio frequency. Which is also a big disadvantage in a datacenter. Ever tried to use a radio in one? The RF noise generated by digital equipment seriously erodes signal quality. Considering the relatively weak signal returned from RFID tags, I'd be surprised if you'd get any kind of useful range. Has anybody tried it out? From jabley at hopcount.ca Wed Jan 13 13:22:28 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 13 Jan 2010 14:22:28 -0500 Subject: more news from Google In-Reply-To: <4B4DF570.6090100@dataway.ch> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> Message-ID: <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> On 2010-01-13, at 11:31, Anthony Uk wrote: > The ability to automatically discern users' political positions from their inbox is not one that any email provider reasonably needs. It's arguably something that gmail users consent to when they give Google rights to index and process their mail, though. Joe From rbf at rbfnet.com Wed Jan 13 13:22:47 2010 From: rbf at rbfnet.com (Brett Frankenberger) Date: Wed, 13 Jan 2010 13:22:47 -0600 Subject: RFID in datacenter (was Re: Default Passwords for World Wide Packets/Lightning Edge Equipment) In-Reply-To: References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> Message-ID: <20100113192247.GA6801@panix.com> On Wed, Jan 13, 2010 at 01:51:41PM -0500, George Imburgia wrote: > > On Wed, 13 Jan 2010, Barry Shein wrote: > >> The big advantage of RFIDs is that you don't need line of sight access >> like you do with bar codes, they use RF, radio frequency. > > Which is also a big disadvantage in a datacenter. Ever tried to use a > radio in one? > > The RF noise generated by digital equipment seriously erodes signal > quality. Considering the relatively weak signal returned from RFID tags, > I'd be surprised if you'd get any kind of useful range. > > Has anybody tried it out? > From smb at cs.columbia.edu Wed Jan 13 13:26:25 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 13 Jan 2010 14:26:25 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <19278.5334.402304.466638@world.std.com> References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> Message-ID: On Jan 13, 2010, at 1:45 PM, Barry Shein wrote: > > There seem to be a lot of misconceptions about RFID tags. I'm hardly > an expert but I do know this much: > > RFID tags are generic, you don't put data into them unique to your > application. > Part of the original (or at least early) context for this thread was recovery of default passwords. If the password is F(ser#), it's only learnable if you know both F() and ser#. The vendor knows F() -- who knows ser#? If it's in an RFID tag, or is DBlookup(tag#,vendor_db), being able to read this admittedly-arbitrary number may indeed be a threat. --Steve Bellovin, http://www.cs.columbia.edu/~smb From brandon at shrader.net Wed Jan 13 13:38:39 2010 From: brandon at shrader.net (Brandon M. Lapointe) Date: Wed, 13 Jan 2010 13:38:39 -0600 Subject: RFID in datacenter (was Re: Default Passwords for World WidePackets/Lightning Edge Equipment) In-Reply-To: References: <9504.1263405986@localhost><131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca><19278.5334.402304.466638@world.std.com> Message-ID: <62B051F561B10F4897A7120430E590EE85AF8F@SEC-EXCHANGE.shrader.net> I have something akin to experience in this arena at least as it applies to the ambient RF environment and the security of the data transferred. As a matter of fact the two usually go hand in hand. The issue that I usually see is how to protect your new drivers license / passport / ID badge (with embedded RFID) from someone stopping next to you at a subway station with an RFID reader hidden in their briefcase, although densely populated CoLo's wouldn't be much different. The preferred standard is usually the FIPS 201 standard and is deployed at 13.56Mhz which ensures you have to be pretty darn near the transceiver to "get a read" but also makes the problem of ambient (RF) noise pretty much a non-issue. The issue arises in tags placed so close together that they are in the read field at the same time causing multiple emitters in the same channel. Recent implementations have a built in collision avoidance mechanism that eliminates the issue entirely in my testing (understanding channel contention for this exercise is at most dozens of transmitters, and wouldn't scale up to anything larger). These same recent implementations use 3DES to secure the open-air channel, reducing prevalence of man-in-the-middle type attacks. Finally, it is common now to retrieve the encrypted contents of the RFID tags and require that a CA hierarchy validate both sides of the transaction prior to decryption which can contain 4K in the data sectors or more. Brandon L. -----Original Message----- From: George Imburgia [mailto:nanog at armorfirewall.com] Sent: Wednesday, January 13, 2010 12:52 PM Cc: nanog at nanog.org Subject: RFID in datacenter (was Re: Default Passwords for World WidePackets/Lightning Edge Equipment) On Wed, 13 Jan 2010, Barry Shein wrote: >> The big advantage of RFIDs is that you don't need line of sight access >> like you do with bar codes, they use RF, radio frequency. >Which is also a big disadvantage in a datacenter. Ever tried to use a >radio in one? >The RF noise generated by digital equipment seriously erodes signal >quality. Considering the relatively weak signal returned from RFID tags, >I'd be surprised if you'd get any kind of useful range. >Has anybody tried it out? I have something akin to experience in this arena at least as it applies to the ambient RF environment and the security of the data transferred. As a matter of fact the two usually go hand in hand. The issue that I usually see is how to protect your new drivers license / passport / ID badge (with embedded RFID) from someone stopping next to you at a subway station with an RFID reader hidden in their briefcase, although densely populated CoLo's wouldn't be much different. The preferred standard is usually the FIPS 201 and is deployed at 13.56Mhz which ensures you have to be pretty darn near the transceiver to "get a read" but also makes the problem of ambient (RF) noise pretty much a non-issue. The issue arises in tags placed so close together that they are in the read field at the same time causing multiple emitters in the same channel. Recent implementations have a built-in collision avoidance mechanism that eliminates the issue entirely in my testing (understanding channel contention for this exercise is at most dozens of transmitters, and wouldn't scale up to anything larger). These same recent implementations use 3DES to secure the open-air channel, reducing prevalence of man-in-the-middle type attacks. Finally, it is common now to retrieve the encrypted contents of the RFID tags and require that a CA hierarchy validate both sides of the transaction prior to decryption which can contain 4K in the data sectors or more. Brandon L. From netfortius at gmail.com Wed Jan 13 13:43:14 2010 From: netfortius at gmail.com (Stefan) Date: Wed, 13 Jan 2010 13:43:14 -0600 Subject: RFID in datacenter (was Re: Default Passwords for World Wide Packets/Lightning Edge Equipment) In-Reply-To: References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> Message-ID: On Wed, Jan 13, 2010 at 12:51 PM, George Imburgia wrote: > > On Wed, 13 Jan 2010, Barry Shein wrote: > > The big advantage of RFIDs is that you don't need line of sight access >> like you do with bar codes, they use RF, radio frequency. >> > > Which is also a big disadvantage in a datacenter. Ever tried to use a radio > in one? > > The RF noise generated by digital equipment seriously erodes signal > quality. Considering the relatively weak signal returned from RFID tags, I'd > be surprised if you'd get any kind of useful range. > > Has anybody tried it out? > > FYI: Looked into this in my previous job-project, and bookmarked this as a positive record of such: http://www.datacenterknowledge.com/archives/2008/11/03/rfid-in-the-data-center/I think it works. ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From nathan at atlasnetworks.us Wed Jan 13 13:47:38 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 13 Jan 2010 11:47:38 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> Message-ID: <11B064048F34FD4094CBA16FC04BE2198655E544@ex01> Not if you change the default password like any sane admin does... -----Original Message----- From: Steven Bellovin [mailto:smb at cs.columbia.edu] Sent: Wednesday, January 13, 2010 11:26 AM To: Barry Shein Cc: nanog at nanog.org; nonobvious at gmail.com Subject: Re: Default Passwords for World Wide Packets/Lightning Edge Equipment On Jan 13, 2010, at 1:45 PM, Barry Shein wrote: > > There seem to be a lot of misconceptions about RFID tags. I'm hardly > an expert but I do know this much: > > RFID tags are generic, you don't put data into them unique to your > application. > Part of the original (or at least early) context for this thread was recovery of default passwords. If the password is F(ser#), it's only learnable if you know both F() and ser#. The vendor knows F() -- who knows ser#? If it's in an RFID tag, or is DBlookup(tag#,vendor_db), being able to read this admittedly-arbitrary number may indeed be a threat. --Steve Bellovin, http://www.cs.columbia.edu/~smb From joelja at bogus.com Wed Jan 13 13:49:36 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 13 Jan 2010 11:49:36 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> Message-ID: <4B4E23D0.2040503@bogus.com> Steven Bellovin wrote: > On Jan 13, 2010, at 1:45 PM, Barry Shein wrote: > >> There seem to be a lot of misconceptions about RFID tags. I'm hardly >> an expert but I do know this much: >> >> RFID tags are generic, you don't put data into them unique to your >> application. Not true, the simplest rfid tags are energized and play back whatever string is embedded, passive tags, however, plenty of device that fall under the moniker rfid are at a minimum field programmable. Moreover when you get beyond passive tags, the devices can be found with full on java stacks, challenge response system, fips certified crypto engines, flash for stored value etc. > Part of the original (or at least early) context for this thread was recovery of default passwords. If the password is F(ser#), it's only learnable if you know both F() and ser#. The vendor knows F() -- who knows ser#? If it's in an RFID tag, or is DBlookup(tag#,vendor_db), being able to read this admittedly-arbitrary number may indeed be a threat. > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > From setient at gmail.com Wed Jan 13 13:51:48 2010 From: setient at gmail.com (Ronald Cotoni) Date: Wed, 13 Jan 2010 14:51:48 -0500 Subject: more news from Google In-Reply-To: <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> Message-ID: <2f1d68351001131151v5c9002d4ybe462560b5b759ca@mail.gmail.com> You should most likely read their terms of service and that would actually answer this instead of guessing. Also, if your reading your own employee's email, that is most likely perfectly legal. On Wed, Jan 13, 2010 at 2:22 PM, Joe Abley wrote: > > On 2010-01-13, at 11:31, Anthony Uk wrote: > >> The ability to automatically discern users' political positions from their inbox is not one that any email provider reasonably needs. > > It's arguably something that gmail users consent to when they give Google rights to index and process their mail, though. > > > Joe > From jabley at hopcount.ca Wed Jan 13 13:56:29 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 13 Jan 2010 14:56:29 -0500 Subject: more news from Google In-Reply-To: <2f1d68351001131151v5c9002d4ybe462560b5b759ca@mail.gmail.com> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> <2f1d68351001131151v5c9002d4ybe462560b5b759ca@mail.gmail.com> Message-ID: <478FDE13-8B6C-460A-A6F5-21DF04988836@hopcount.ca> On 2010-01-13, at 14:51, Ronald Cotoni wrote: > You should most likely read their terms of service and that would > actually answer this instead of guessing. I've read the terms of service. I may be interpreting them incorrectly, sure, but I'm not guessing. If your comment was not directed at me, but was a more general recommendation for all people who might guess rather than read, then sure, I agree. Joe From Valdis.Kletnieks at vt.edu Wed Jan 13 14:00:16 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Jan 2010 15:00:16 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: Your message of "Wed, 13 Jan 2010 11:23:59 MST." <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> References: <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> Message-ID: <13468.1263412816@localhost> On Wed, 13 Jan 2010 11:23:59 MST, "Lyndon Nerenberg (VE6BBM/VE7TFX)" said: > > Barry's right, for at least some scenarios. If I have an unauthorized somebody > > walking down the row with a wand in their pocket, the fact they have a wand in > > their pocket is the least of my problems. > > Encrypt the data? That's a possible solution to the wand, which is the least of my problems. My *big* problem at that point is I have an unauthorized person in my server room. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From setient at gmail.com Wed Jan 13 14:11:25 2010 From: setient at gmail.com (Ronald Cotoni) Date: Wed, 13 Jan 2010 15:11:25 -0500 Subject: more news from Google In-Reply-To: <478FDE13-8B6C-460A-A6F5-21DF04988836@hopcount.ca> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> <2f1d68351001131151v5c9002d4ybe462560b5b759ca@mail.gmail.com> <478FDE13-8B6C-460A-A6F5-21DF04988836@hopcount.ca> Message-ID: <2f1d68351001131211t4a8f3459h53a3fff494cbd32f@mail.gmail.com> It was to others :) But in the process of troubleshooting, an admin may come across something say by looking at a bounce message or other statistics such as which domains the user sends to on a regular basis. cPanel even comes with Eximstats which does some of that for you. On Wed, Jan 13, 2010 at 2:56 PM, Joe Abley wrote: > > On 2010-01-13, at 14:51, Ronald Cotoni wrote: > >> You should most likely read their terms of service and that would >> actually answer this instead of guessing. > > I've read the terms of service. I may be interpreting them incorrectly, sure, but I'm not guessing. > > If your comment was not directed at me, but was a more general recommendation for all people who might guess rather than read, then sure, I agree. > > > Joe > > From orangewinds at gmail.com Wed Jan 13 14:12:06 2010 From: orangewinds at gmail.com (Jacob Taylor) Date: Wed, 13 Jan 2010 12:12:06 -0800 Subject: cable provider problems yesterday around 1pm EST? In-Reply-To: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> References: <4946caa51001130744y60c16779g696695e8cdbbad84@mail.gmail.com> Message-ID: <4B4E2916.1040308@gmail.com> On 1/13/2010 7:44 AM, Rich Casto wrote: > Is anyone aware of any routing problems with any cable providers yesterday > around 1pm EST? Thanks! > > -- Rich > I experienced significant packet loss and dropped connections (possibly caused by that) at about that time yesterday. My ISP is Charter Cable. -J From Valdis.Kletnieks at vt.edu Wed Jan 13 14:11:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Jan 2010 15:11:56 -0500 Subject: more news from Google In-Reply-To: Your message of "Wed, 13 Jan 2010 17:31:44 +0100." <4B4DF570.6090100@dataway.ch> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> Message-ID: <14035.1263413516@localhost> On Wed, 13 Jan 2010 17:31:44 +0100, Anthony Uk said: > "Second, we have evidence to suggest that a primary goal of the > attackers was accessing the Gmail accounts of Chinese human rights > activists. " > I have orders of magnitude fewer users than gmail does, and often look > at their mailboxes (with their consent, of course), but I still couldn't > tell you the political position of any of them (apart from the politicians). If you can tell the political position of the politicians by looking at their mailboxes, you can probably tell the political position of a suspected human rights activist by looking at their mailbox. Remember - the Chinese government doesn't care about the users who's political position can't be identified. They care about the ones that *can* be identified as having an inconvenient viewpoint... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From smb at cs.columbia.edu Wed Jan 13 14:12:28 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 13 Jan 2010 15:12:28 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <11B064048F34FD4094CBA16FC04BE2198655E544@ex01> References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> <11B064048F34FD4094CBA16FC04BE2198655E544@ex01> Message-ID: On Jan 13, 2010, at 2:47 PM, Nathan Eisenberg wrote: > Not if you change the default password like any sane admin does... This is from the OP: I have recently inherited the management of an undocumented network (failed FTTH provider) which utilizes World Wide Packets' LightningEdge 427 (16 port GBIC switch) and 311v (24/4 port Ethernet/GBIC switch) switches. ... Does anyone know the default passwords for World Wide Packets 427 and 311v switches? Lots of gear has a button/jumper/pop_the_CMOS battery/other_physical_presence_magic to reset things to factory state, including the default pw. The threat went on to why default passwords are bad, to passwords on the bottom of the device, to RFIDs because the devices of interest to this community are racked and stacked -- and back to theme #2: default passwords are bad... --Steve Bellovin, http://www.cs.columbia.edu/~smb From graeme at graemef.net Wed Jan 13 14:34:44 2010 From: graeme at graemef.net (Graeme Fowler) Date: Wed, 13 Jan 2010 20:34:44 +0000 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> <11B064048F34FD4094CBA16FC04BE2198655E544@ex01> Message-ID: <1263414884.30720.14.camel@ernie.internal.graemef.net> On Wed, 2010-01-13 at 15:12 -0500, Steven Bellovin wrote: > Lots of gear has a button/jumper/pop_the_CMOS battery/other_physical_presence_magic to reset things to factory state, including the default pw. The threat went on to why default passwords are bad, to passwords on the bottom of the device, to RFIDs because the devices of interest to this community are racked and stacked -- and back to theme #2: default passwords are bad... And somewhere in the dim and distant past (Jan 6th), Nathan announced that he'd sorted out his original problem and now had the defaults. What a peculiar bunch we are. And this from the group lauded as anonymously and peacefully co-existing to hold the Internet together, eh? Graeme From bicknell at ufp.org Wed Jan 13 14:49:09 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 13 Jan 2010 12:49:09 -0800 Subject: more news from Google In-Reply-To: <4B4DF570.6090100@dataway.ch> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> Message-ID: <20100113204909.GA81340@ussenterprise.ufp.org> In a message written on Wed, Jan 13, 2010 at 05:31:44PM +0100, Anthony Uk wrote: > I have orders of magnitude fewer users than gmail does, and often look > at their mailboxes (with their consent, of course), but I still couldn't > tell you the political position of any of them (apart from the politicians). It's not clear to me you have to read any e-mail to figure out that "help_us_free_tibet at gmail.com" might be someone who's taking a political position. A search company may also, say, look for e-mail addresses listed on the web sites that must be censored, and when it's the same list being hacked, draw a conclusion. -- 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: 826 bytes Desc: not available URL: From nathan at atlasnetworks.us Wed Jan 13 14:50:03 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 13 Jan 2010 12:50:03 -0800 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <1263414884.30720.14.camel@ernie.internal.graemef.net> References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> <11B064048F34FD4094CBA16FC04BE2198655E544@ex01> <1263414884.30720.14.camel@ernie.internal.graemef.net> Message-ID: <11B064048F34FD4094CBA16FC04BE2198655E5CB@ex01> > From: Graeme Fowler [mailto:graeme at graemef.net] > And somewhere in the dim and distant past (Jan 6th), Nathan announced > that he'd sorted out his original problem and now had the defaults. > > What a peculiar bunch we are. And this from the group lauded as > anonymously and peacefully co-existing to hold the Internet together, > eh? > > Graeme I think the impulse to challenge and question assertions probably tends to be a common personality feature in (good) network admins. The resulting conversations are often lively, oddly passionate arguments - but I firmly believe that there is a friendly nature behind it all. Nathan From nathan at atlasnetworks.us Wed Jan 13 14:53:49 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 13 Jan 2010 12:53:49 -0800 Subject: more news from Google In-Reply-To: <20100113204909.GA81340@ussenterprise.ufp.org> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <20100113204909.GA81340@ussenterprise.ufp.org> Message-ID: <11B064048F34FD4094CBA16FC04BE2198655E5D2@ex01> > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Wednesday, January 13, 2010 12:49 PM > To: nanog at nanog.org > Subject: Re: more news from Google > > It's not clear to me you have to read any e-mail to figure out that > "help_us_free_tibet at gmail.com" might be someone who's taking a > political position. A search company may also, say, look for e-mail > addresses listed on the web sites that must be censored, and when it's > the same list being hacked, draw a conclusion. It's also possible that far less questionable means are being utilized. Perhaps there are a sufficient number of pro-free-speech'ers at Google.cn (which is presumably largely composed of Chinese nationals) that are privy to such information. It only takes one guy going "hey! I know some of these email addresses!"... Nathan From davei at otd.com Wed Jan 13 15:22:31 2010 From: davei at otd.com (Dave Israel) Date: Wed, 13 Jan 2010 16:22:31 -0500 Subject: more news from Google In-Reply-To: <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <83D253DD-592E-4402-B41F-A987A15B1A9C@hopcount.ca> Message-ID: <4B4E3997.3040106@otd.com> Joe Abley wrote: > On 2010-01-13, at 11:31, Anthony Uk wrote: > > >> The ability to automatically discern users' political positions from their inbox is not one that any email provider reasonably needs. >> > > It's arguably something that gmail users consent to when they give Google rights to index and process their mail, though. > > Or... Maybe account X is attacked, and it is registered to somebody named Liu Xiaobo, and Liu Xiaobo turns out to be a prominent human rights activist. After some investigation, it turns out accounts belonging to people whose names match known human rights activists were attacked and those that don't, weren't. Sure, assuming Google is being Sinister Santa Claus (brings gifts ostensibly from the goodness of their hearts, but mysteriously knows what you want, knows when you've been sleeping, knows when you're awake, etc) through data mining makes a good story, but it isn't the obvious conclusion. From Valdis.Kletnieks at vt.edu Wed Jan 13 15:55:36 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 13 Jan 2010 16:55:36 -0500 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: Your message of "Wed, 13 Jan 2010 12:50:03 PST." <11B064048F34FD4094CBA16FC04BE2198655E5CB@ex01> References: <9504.1263405986@localhost> <131bdfb5cefa3ffcec401bc35352ad8f@yyc.orthanc.ca> <19278.5334.402304.466638@world.std.com> <11B064048F34FD4094CBA16FC04BE2198655E544@ex01> <1263414884.30720.14.camel@ernie.internal.graemef.net> <11B064048F34FD4094CBA16FC04BE2198655E5CB@ex01> Message-ID: <17814.1263419736@localhost> On Wed, 13 Jan 2010 12:50:03 PST, Nathan Eisenberg said: > I think the impulse to challenge and question assertions probably tends to > be a common personality feature in (good) network admins. Something to keep in mind is that this list is, by and large, comprised of people who are paid large sums of money for their ability to have meaningful conversations with inanimate objects made of melted sand. You gotta expect their people skills will be.... different. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Wed Jan 13 16:15:00 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 13 Jan 2010 14:15:00 -0800 Subject: more news from Google In-Reply-To: <14035.1263413516@localhost> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <14035.1263413516@localhost> Message-ID: <4B4E45E4.1080307@bogus.com> Valdis.Kletnieks at vt.edu wrote: > On Wed, 13 Jan 2010 17:31:44 +0100, Anthony Uk said: > >> "Second, we have evidence to suggest that a primary goal of the >> attackers was accessing the Gmail accounts of Chinese human rights >> activists. " > >> I have orders of magnitude fewer users than gmail does, and often look >> at their mailboxes (with their consent, of course), but I still couldn't >> tell you the political position of any of them (apart from the politicians). > > If you can tell the political position of the politicians by looking at their > mailboxes, you can probably tell the political position of a suspected human > rights activist by looking at their mailbox. Remember - the Chinese government > doesn't care about the users who's political position can't be identified. > They care about the ones that *can* be identified as having an inconvenient > viewpoint... you can probably also simply compare the usernames with the search term blacklist that the government provides you... From msheldon at cox.net Wed Jan 13 16:26:22 2010 From: msheldon at cox.net (msheldon at cox.net) Date: Wed, 13 Jan 2010 22:26:22 +0000 Subject: more news from Google Message-ID: <255275490-1263421495-cardhu_decombobulator_blackberry.rim.net-196880606-@bda062.bisx.prod.on.blackberry> From a single detection of one hostile email you can often expand the picture to many mail recipients. A little open source research identifies the common community the recipients belong to. It's pretty straight forward. Mike ------Original Message------ From: Nathan Eisenberg To: nanog at nanog.org Subject: RE: more news from Google Sent: Jan 13, 2010 12:53 PM > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Wednesday, January 13, 2010 12:49 PM > To: nanog at nanog.org > Subject: Re: more news from Google > > It's not clear to me you have to read any e-mail to figure out that > "help_us_free_tibet at gmail.com" might be someone who's taking a > political position. A search company may also, say, look for e-mail > addresses listed on the web sites that must be censored, and when it's > the same list being hacked, draw a conclusion. It's also possible that far less questionable means are being utilized. Perhaps there are a sufficient number of pro-free-speech'ers at Google.cn (which is presumably largely composed of Chinese nationals) that are privy to such information. It only takes one guy going "hey! I know some of these email addresses!"... Nathan Sent on the Sprint? Now Network from my BlackBerry? From smb at cs.columbia.edu Wed Jan 13 16:31:46 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 13 Jan 2010 17:31:46 -0500 Subject: more news from Google In-Reply-To: <255275490-1263421495-cardhu_decombobulator_blackberry.rim.net-196880606-@bda062.bisx.prod.on.blackberry> References: <255275490-1263421495-cardhu_decombobulator_blackberry.rim.net-196880606-@bda062.bisx.prod.on.blackberry> Message-ID: <6F4C2201-A75A-4F88-B108-3021058544CA@cs.columbia.edu> On Jan 13, 2010, at 5:26 PM, msheldon at cox.net wrote: > From a single detection of one hostile email you can often expand the picture to many mail recipients. A little open source research identifies the common community the recipients belong to. It's pretty straight forward. > The magic phrase is "traffic analysis" -- look at the accounts of known targets of interest, and see the usernames, IP addresses, etc., of their correspondents. Recurse as needed. --Steve Bellovin, http://www.cs.columbia.edu/~smb From mpalmer at hezmatt.org Wed Jan 13 16:34:37 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 14 Jan 2010 09:34:37 +1100 Subject: Default Passwords for World Wide Packets/Lightning Edge Equipment In-Reply-To: <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> References: <201001080722.o087Mfb1010074@aurora.sol.net> <18a5e7cb1001121750u238a8ba4p1ffb373352159d27@mail.gmail.com> <13915.1263355426@localhost> <19278.258.350014.385990@world.std.com> <5bcb62b61001130955l32ec2a84u9a3ae538831e1c88@mail.gmail.com> Message-ID: <20100113223437.GT25450@hezmatt.org> On Wed, Jan 13, 2010 at 12:55:00PM -0500, Matt Simmons wrote: > That would be excellent for both the administrator, and anyone walking > down the row with a wand in their pocket. So... someone has a list of the "barcodes" on all my equipment. ONOES! Without access to the asset database that backs it, I'm not sure what damage they're going to do. It's not as though one of my core switches is going to try and get through airport security with it. - Matt From joelja at bogus.com Wed Jan 13 11:10:19 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 13 Jan 2010 09:10:19 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <9e246b4d1001130724h6a28a6aeo47584fc6f3d28e3b@mail.gmail.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> <29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu> <29A54911243620478FF59F00EBB12F4701BFF4A0@ex01.drtel.lan> <9e246b4d1001130724h6a28a6aeo47584fc6f3d28e3b@mail.gmail.com> Message-ID: <4B4DFE7B.9080803@bogus.com> Tim Durack wrote: > Replace all the routers on the Internet with stateful firewalls. What happens? the same thing that happened with flow-cached routers, they melt, you go out of business, the end. From sfouant at shortestpathfirst.net Wed Jan 13 18:31:07 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 13 Jan 2010 19:31:07 -0500 Subject: more news from Google In-Reply-To: <20100113052416.GB12526@sizone.org> References: <20100113052416.GB12526@sizone.org> Message-ID: <014c01ca94b0$ddb39810$991ac830$@net> > -----Original Message----- > From: Ken Chase [mailto:math at sizone.org] > Sent: Wednesday, January 13, 2010 12:24 AM > To: nanog at nanog.org > Subject: more news from Google > > I must say I'll have to take a step back from my previous > position/postings > having read this article. > > I just can't figure out their /ANGLE/. :) > > http://googleblog.blogspot.com/2010/01/new-approach-to-china.html > > Well played, google? Interesting radio piece re:Google in China this evening on NPR's radio program "All Things Considered". http://www.npr.org/templates/story/story.php?storyId=122540813 Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From jgreco at ns.sol.net Wed Jan 13 20:56:30 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 13 Jan 2010 20:56:30 -0600 (CST) Subject: more news from Google In-Reply-To: <6F4C2201-A75A-4F88-B108-3021058544CA@cs.columbia.edu> from "Steven Bellovin" at Jan 13, 2010 05:31:46 PM Message-ID: <201001140256.o0E2uUoL062611@aurora.sol.net> > On Jan 13, 2010, at 5:26 PM, msheldon at cox.net wrote: > > > From a single detection of one hostile email you can often expand the picture to many mail recipients. A little open source research identifies the common community the recipients belong to. It's pretty straight forward. > > > > The magic phrase is "traffic analysis" -- look at the accounts of > known targets of interest, and see the usernames, IP addresses, > etc., of their correspondents. Recurse as needed. This could, however, go beyond traffic analysis. What happens when China slaps Google by taking over "google.cn" and places a web site that appears to be Google there? This then leads to the interesting question of exactly what sort of things were taken from Google (which is what I guess based on "corporate infrastructure [...] theft of intellectual property). Is it completely outside the realm of possibility that China might have stolen sufficient technology to replicate resources such as Google search and mail? Or things such as SSL certificates? I keep thinking about it, and it seems to me like Google decided it was better to cry fire now... before Chinese citizens ended up submitting searches to "Google.cn" and having them intercepted and analyzed by the Chinese government. There are, of course, numerous possibilities as to what's really going on, but whatever it is, I get the distinct feeling that we're getting a carefully spun story. ... 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 courtneysmith at comcast.net Wed Jan 13 21:50:47 2010 From: courtneysmith at comcast.net (courtneysmith at comcast.net) Date: Thu, 14 Jan 2010 03:50:47 +0000 (UTC) Subject: Anyone having issues updating RADB tonight? In-Reply-To: <421769197.10378141263440940299.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> Message-ID: <1957404719.10378551263441047762.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> Anyone having issues updating RADB tonight? I am getting 403 message from URL to web form. No response from two updates I submitted this evening via email. I noticed a few other URL's are also giving a 403 message. http://www.radb.net/cgi-bin/radb/irr-web.cgi http://www.radb.net/faq.html http://www.radb.net/emailupdates.html From jbfixurpc at gmail.com Wed Jan 13 22:19:35 2010 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Wed, 13 Jan 2010 23:19:35 -0500 Subject: Anyone having issues updating RADB tonight? In-Reply-To: <1957404719.10378551263441047762.JavaMail.root@sz0003a.westchester.pa.mail.comcast.net> Message-ID: <000001ca94d0$c8715760$0c01a8c0@E520> Looks like someone messed up permissions on the directories and/or files. Even the images for the buttons don't appear to work.. http://www.radb.net/images/navbar_bottom_off_02.jpg 403 permission denied... Game over. :o -Joe > -----Original Message----- > From: courtneysmith at comcast.net [mailto:courtneysmith at comcast.net] > Sent: Wednesday, January 13, 2010 10:51 PM > To: nanog at nanog.org > Subject: Anyone having issues updating RADB tonight? > > Anyone having issues updating RADB tonight? I am getting 403 > message from URL to web form. No response from two updates I > submitted this evening via email. I noticed a few other URL's > are also giving a 403 message. > > http://www.radb.net/cgi-bin/radb/irr-web.cgi > > http://www.radb.net/faq.html > > http://www.radb.net/emailupdates.html > > > From warren at kumari.net Wed Jan 13 23:37:04 2010 From: warren at kumari.net (Warren Kumari) Date: Thu, 14 Jan 2010 00:37:04 -0500 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> Message-ID: <6BD6F623-E730-4FAE-8825-AE3293E2966A@kumari.net> On Jan 10, 2010, at 1:32 AM, Dobbins, Roland wrote: > > On Jan 10, 2010, at 1:22 PM, harbor235 wrote: > >> Again, a firewall has it's place just like any other device in the >> network, defense in >>> depth is a prudent philosophy to reduce the >> chances of compromise, it does not >>>eliminate it nor does any >> architecture you can think of, period > Bah, I was trying not to get sucked into the roaring vortex of this thread, but I think that folks are ignoring one of the primary benefits of firewalls: Quite simply, its this: I can now place a checkbox in the "Is there a firewall?" column of the audit. While it may be fun to rail against the stupidity, after the Nth time that you have had the "This is in no way going to help improves security and will actually decrease it" argument, you realize that, if you want to get real work done, you need to choose your battles. In may cases the auditor knows that the firewall may not make thing better, and may make them worse, but he has a set of guidelines that the contracting company he is working for dictates, and he needs to see the widget to sign on the dotted line. I have had auditors cheerfully point out that the way that their specific requirement is worded, a commodity CPE device plugged into port somewhere will fully satisfy their requirements and did I know that BestBuy has them on sale this week? W > What a ridiculous statement - of course it does. > > *The place of the stateful firewall is in front of clients, not > servers*. > > I'm not going to continue the unequal contest of pitting real-world > operational experience against Confused Information Systems Security > Professional brainwashing. One can spout all the buzzwords and > catchphrases one wishes, but at the end of the day, it's all dead > wrong - and anyone naive enough to fall for it is setting himself up > for a world of hurt. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2173 bytes Desc: not available URL: From rdobbins at arbor.net Wed Jan 13 23:45:50 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 14 Jan 2010 05:45:50 +0000 Subject: I don't need no stinking firewall! In-Reply-To: <6BD6F623-E730-4FAE-8825-AE3293E2966A@kumari.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> <6BD6F623-E730-4FAE-8825-AE3293E2966A@kumari.net> Message-ID: <6527B1CC-E87A-485B-9CB3-6320B969E7A8@arbor.net> On Jan 14, 2010, at 12:37 PM, Warren Kumari wrote: > I can now place a checkbox in the "Is there a firewall?" column of the audit. mod_security is your friend. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From courtneysmith at comcast.net Thu Jan 14 00:00:43 2010 From: courtneysmith at comcast.net (Courtney Smith) Date: Thu, 14 Jan 2010 01:00:43 -0500 Subject: Anyone having issues updating RADB tonight? Message-ID: My update completed eventually. Not sure if the delay had any relation to the URL issues. Sorry for top post. Haven't figured how to put inline when using my Droid. Joe Blanchard wrote: > > >Looks like someone messed up permissions on the directories and/or files. >Even the images for the buttons don't appear to work.. > >http://www.radb.net/images/navbar_bottom_off_02.jpg > > >403 permission denied... Game over. :o > > >-Joe > > > >> -----Original Message----- >> From: courtneysmith at comcast.net [mailto:courtneysmith at comcast.net] >> Sent: Wednesday, January 13, 2010 10:51 PM >> To: nanog at nanog.org >> Subject: Anyone having issues updating RADB tonight? >> >> Anyone having issues updating RADB tonight? I am getting 403 >> message from URL to web form. No response from two updates I >> submitted this evening via email. I noticed a few other URL's >> are also giving a 403 message. >> >> http://www.radb.net/cgi-bin/radb/irr-web.cgi >> >> http://www.radb.net/faq.html >> >> http://www.radb.net/emailupdates.html >> >> >> > From nanog2 at adns.net Thu Jan 14 00:12:19 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Thu, 14 Jan 2010 00:12:19 -0600 Subject: Anyone having issues updating RADB tonight? References: Message-ID: <0D059F73D15D49E5B80F032485E7638E@TAKA> Updates completing is fine for everyone but Level 3. Switched to a new data center and both they and I updated our records and Level 3 still hasn't picked up the updates and its been 9 days. Sigh.... ----- Original Message ----- From: "Courtney Smith" To: Sent: Thursday, January 14, 2010 12:00 AM Subject: RE: Anyone having issues updating RADB tonight? > My update completed eventually. Not sure if the delay had any relation to the URL issues. > > Sorry for top post. Haven't figured how to put inline when using my Droid. > > > Joe Blanchard wrote: > >> >> >>Looks like someone messed up permissions on the directories and/or files. >>Even the images for the buttons don't appear to work.. >> >>http://www.radb.net/images/navbar_bottom_off_02.jpg >> >> >>403 permission denied... Game over. :o >> >> >>-Joe >> >> >> >>> -----Original Message----- >>> From: courtneysmith at comcast.net [mailto:courtneysmith at comcast.net] >>> Sent: Wednesday, January 13, 2010 10:51 PM >>> To: nanog at nanog.org >>> Subject: Anyone having issues updating RADB tonight? >>> >>> Anyone having issues updating RADB tonight? I am getting 403 >>> message from URL to web form. No response from two updates I >>> submitted this evening via email. I noticed a few other URL's >>> are also giving a 403 message. >>> >>> http://www.radb.net/cgi-bin/radb/irr-web.cgi >>> >>> http://www.radb.net/faq.html >>> >>> http://www.radb.net/emailupdates.html >>> >>> >>> >> > From randy at psg.com Thu Jan 14 02:14:06 2010 From: randy at psg.com (Randy Bush) Date: Thu, 14 Jan 2010 17:14:06 +0900 Subject: I don't need no stinking firewall! In-Reply-To: <4B4DFE7B.9080803@bogus.com> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <39D0F5E6-5115-49EC-99A9-242C51E04F75@arbor.net> <29A54911243620478FF59F00EBB12F4701B27F1E@ex01.drtel.lan> <29A54911243620478FF59F00EBB12F4701B27F3E@ex01.drtel.lan> <24D317F9-2D50-4705-9669-84123E2ABC73@smtps.net> <29A54911243620478FF59F00EBB12F4701B27F5C@ex01.drtel.lan> <97113335-6535-4B1D-9C77-EB4E61704B49@ndsu.edu> <29A54911243620478FF59F00EBB12F4701BFF4A0@ex01.drtel.lan> <9e246b4d1001130724h6a28a6aeo47584fc6f3d28e3b@mail.gmail.com> <4B4DFE7B.9080803@bogus.com> Message-ID: >> Replace all the routers on the Internet with stateful firewalls. What >> happens? > the same thing that happened with flow-cached routers, they melt, you go > out of business, the end. ^ a bunch of us LOAO, ^ From randy at psg.com Thu Jan 14 02:23:05 2010 From: randy at psg.com (Randy Bush) Date: Thu, 14 Jan 2010 17:23:05 +0900 Subject: ICSI Netalyzr launch #2 In-Reply-To: <201001131542.o0DFgXra021480@pork.ICSI.Berkeley.EDU> References: <201001131542.o0DFgXra021480@pork.ICSI.Berkeley.EDU> Message-ID: there are no data in the report, just OK lines with no numbers. and clicking the links on the lines gave me docs not numbers. bring back the old version! macosx 10.6.2 firefox 3.5.7 randy From fergdawgster at gmail.com Thu Jan 14 02:29:36 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 14 Jan 2010 00:29:36 -0800 Subject: ICSI Netalyzr launch #2 In-Reply-To: References: <201001131542.o0DFgXra021480@pork.ICSI.Berkeley.EDU> Message-ID: <6cd462c01001140029o3886e255pdaafb3e6840337c0@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jan 14, 2010 at 12:23 AM, Randy Bush wrote: > there are no data in the report, just OK lines with no numbers. and > clicking the links on the lines gave me docs not numbers. bring back > the old version! > > macosx 10.6.2 > firefox 3.5.7 > Works for me. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLTtXsq1pz9mNUZTMRAoLyAKCjnybFLTp7E8Xs+zTvPH0w8Dp4PQCeIrXG +aCh2RYeV1RDL2MMULBUzK0= =yT4V -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From llynch at civil-tongue.net Thu Jan 14 09:24:54 2010 From: llynch at civil-tongue.net (Lucy Lynch) Date: Thu, 14 Jan 2010 07:24:54 -0800 (PST) Subject: ICSI Netalyzr launch #2 In-Reply-To: References: <201001131542.o0DFgXra021480@pork.ICSI.Berkeley.EDU> Message-ID: On Thu, 14 Jan 2010, Randy Bush wrote: > there are no data in the report, just OK lines with no numbers. and > clicking the links on the lines gave me docs not numbers. bring back > the old version! > > macosx 10.6.2 > firefox 3.5.7 still there, just hiding. click the + sign at the top to "expand all". > randy > From jmaimon at ttec.com Thu Jan 14 11:13:07 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 14 Jan 2010 12:13:07 -0500 Subject: I don't need no stinking firewall! In-Reply-To: References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <4B473178.7010100@kruchas.com> <20B7B3C0-434E-4A73-81F2-DCA7E3A790BD@arbor.net> <4B473AE4.7000102@kruchas.com> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> Message-ID: <4B4F50A3.4080409@ttec.com> Dobbins, Roland wrote: > > On Jan 10, 2010, at 1:22 PM, harbor235 wrote: > >> Again, a firewall has it's place just like any other device in the network, defense in>>> depth is a prudent philosophy to reduce the chances of compromise, it does not>>>eliminate it nor does any architecture you can think of, period > > What a ridiculous statement - of course it does. > > *The place of the stateful firewall is in front of clients, not servers*. > Servers can also be clients who can benefit from state tracking. The best answer I have to that scenario is to make the client path different than the server path. Joe From joe at riversidecg.com Thu Jan 14 11:31:27 2010 From: joe at riversidecg.com (Joe Johnson) Date: Thu, 14 Jan 2010 11:31:27 -0600 Subject: Cogent Outage? Message-ID: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? Joe Johnson Chief Information Officer Riverside Consulting Group, Ltd. Phone: 708.442.6033 x3456 Fax: 708.442.9722 joe at riversidecg.com www.riversidecg.com From robertg at garlic.com Thu Jan 14 11:36:27 2010 From: robertg at garlic.com (Robert Glover) Date: Thu, 14 Jan 2010 09:36:27 -0800 Subject: Cogent Outage? In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <4B4F561B.5050607@garlic.com> Hello, Our 100Mb Metro-E link is up and running just fine... We are fed out of their San Francisco, CA facility. However, this is posted on the Cogent Status page: ****************************************************************************** ** Cogent Network Status Report Last Updated Thu Jan 14 10:38:30 2010 ** ****************************************************************************** ****************************************************************************** *Network Status:* Warning *DNS Servers Status:* Normal *Dialup/IPASS Status: *Normal *Mail Servers Status:* Normal *Webservers Status: *Normal *Cogent Network Status/DNS Server Status Description: * Welcome to Cogent Communications' Network Status Message. Customers with traffic going through or on the east coast may be experiencing packet loss and higher than normal latency due to a fiber cut in New Jersey. There is no ETR at this time. The Cogent ticket to reference for this issue is HD2082680. Sincerely, Bobby Glover Director of Information Services South Valley Internet On 1/14/2010 9:31 AM, Joe Johnson wrote: > We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? > > Joe Johnson > Chief Information Officer > Riverside Consulting Group, Ltd. > Phone: 708.442.6033 x3456 > Fax: 708.442.9722 > joe at riversidecg.com > www.riversidecg.com > > > > > From aaron at wholesaleinternet.net Thu Jan 14 11:36:44 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 14 Jan 2010 11:36:44 -0600 Subject: Cogent Outage? In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <001801ca9540$23f64c70$6be2e550$@net> Sitting on hold with them now. We lost them completely in Kansas City for about 5 minutes. We're back but connectivity through them is spotty. Can't even resolve google.com. Same with other DCs in the area. -----Original Message----- From: Joe Johnson [mailto:joe at riversidecg.com] Sent: Thursday, January 14, 2010 11:31 AM To: nanog at nanog.org Subject: Cogent Outage? We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? Joe Johnson Chief Information Officer Riverside Consulting Group, Ltd. Phone: 708.442.6033 x3456 Fax: 708.442.9722 joe at riversidecg.com www.riversidecg.com No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.725 / Virus Database: 270.14.140/2621 - Release Date: 01/14/10 06:39:00 From kmangal at epiknetworks.com Thu Jan 14 11:37:45 2010 From: kmangal at epiknetworks.com (Ketan Mangal) Date: Thu, 14 Jan 2010 12:37:45 -0500 Subject: Cogent Outage? References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local> Yes there is a Newyork to Philadelphia fiber cut is there It might not be an outage it might be high latency due to multiple routes going out via there buffalo POP. Ketan Mangal 2 Bloor St W, Ste 2004 Toronto, Ontario M4W 3E2 Toll Free: 1.866.353.9333 Fax: 416.855.7636 Client Services: 416.921.7000 Technical Support: 416.921.2221 Client Services e-mail: care at epiknetworks.com www.epiknetworks.com Toronto . Vancouver . Atlanta . Los Angeles -----Original Message----- From: Joe Johnson [mailto:joe at riversidecg.com] Sent: Thursday, January 14, 2010 12:31 PM To: nanog at nanog.org Subject: Cogent Outage? We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? Joe Johnson Chief Information Officer Riverside Consulting Group, Ltd. Phone: 708.442.6033 x3456 Fax: 708.442.9722 joe at riversidecg.com www.riversidecg.com No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.432 / Virus Database: 270.14.138/2618 - Release Date: 01/14/10 07:35:00 From brandon.galbraith at gmail.com Thu Jan 14 11:38:28 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 14 Jan 2010 11:38:28 -0600 Subject: Cogent Outage? In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <366100671001140938j5cda7320lf94b4d56857b5601@mail.gmail.com> Fiber cut in New Jersey, affecting most of the easy coast (per their support number). I didn't jot the master ticket number down though. Our gear in Chicago seems partially affected though. On Thu, Jan 14, 2010 at 11:31 AM, Joe Johnson wrote: > We just lost Cogent across the country, along with several sister > companies. Can't get through to a support person. Any idea what's going on? > > Joe Johnson > Chief Information Officer > Riverside Consulting Group, Ltd. > Phone: 708.442.6033 x3456 > Fax: 708.442.9722 > joe at riversidecg.com > www.riversidecg.com > > > > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From rmaunier at neotelecoms.com Thu Jan 14 11:40:12 2010 From: rmaunier at neotelecoms.com (Raphael Maunier) Date: Thu, 14 Jan 2010 18:40:12 +0100 Subject: Cogent Outage? In-Reply-To: <4B4F561B.5050607@garlic.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <4B4F561B.5050607@garlic.com> Message-ID: <8567E5DB-5D13-4C23-BA93-F5FA481F4706@neotelecoms.com> There is a fiber cut and it's located near Brunswick, NJ -- Rapha?l Maunier NEO TELECOMS On Jan 14, 2010, at 6:36 PM, Robert Glover wrote: > Hello, > > Our 100Mb Metro-E link is up and running just fine... We are fed out of their San Francisco, CA facility. > > However, this is posted on the Cogent Status page: > > > ****************************************************************************** > ** Cogent Network Status Report Last Updated Thu Jan 14 10:38:30 2010 ** > ****************************************************************************** > ****************************************************************************** > *Network Status:* Warning > *DNS Servers Status:* Normal > *Dialup/IPASS Status: *Normal > *Mail Servers Status:* Normal > *Webservers Status: *Normal > > > *Cogent Network Status/DNS Server Status Description: * Welcome to Cogent Communications' Network Status Message. Customers with traffic going through or on the east coast may be experiencing packet loss and higher than normal latency due to a fiber cut in New Jersey. There is no ETR at this time. The Cogent ticket to reference for this issue is HD2082680. > > > Sincerely, > Bobby Glover > Director of Information Services > South Valley Internet > > On 1/14/2010 9:31 AM, Joe Johnson wrote: >> We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? >> >> Joe Johnson >> Chief Information Officer >> Riverside Consulting Group, Ltd. >> Phone: 708.442.6033 x3456 >> Fax: 708.442.9722 >> joe at riversidecg.com >> www.riversidecg.com >> >> >> >> >> > From todd at velocitytelephone.com Thu Jan 14 11:40:04 2010 From: todd at velocitytelephone.com (Todd Mueller) Date: Thu, 14 Jan 2010 11:40:04 -0600 (CST) Subject: Cogent Outage? In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <47B0A0C1ADE1ED4BA114480988FE878F1D1B07@dc1.gv-office.local> Seems like there may an issue in Chicago, lots of traceroutes bombing out there. -----Original Message----- From: Joe Johnson [mailto:joe at riversidecg.com] Sent: Thursday, January 14, 2010 11:33 AM To: nanog at nanog.org Subject: Cogent Outage? We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? Joe Johnson Chief Information Officer Riverside Consulting Group, Ltd. Phone: 708.442.6033 x3456 Fax: 708.442.9722 joe at riversidecg.com www.riversidecg.com From jhorstman at adknowledge.com Thu Jan 14 11:40:46 2010 From: jhorstman at adknowledge.com (Justin Horstman) Date: Thu, 14 Jan 2010 11:40:46 -0600 Subject: Cogent Outage? In-Reply-To: <4B4F561B.5050607@garlic.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <4B4F561B.5050607@garlic.com> Message-ID: Lost connectivity to a few things....Namely google. Kansas City ~J -----Original Message----- From: Robert Glover [mailto:robertg at garlic.com] Sent: Thursday, January 14, 2010 11:36 AM To: Joe Johnson Cc: nanog at nanog.org Subject: Re: Cogent Outage? Hello, Our 100Mb Metro-E link is up and running just fine... We are fed out of their San Francisco, CA facility. However, this is posted on the Cogent Status page: ****************************************************************************** ** Cogent Network Status Report Last Updated Thu Jan 14 10:38:30 2010 ** ****************************************************************************** ****************************************************************************** *Network Status:* Warning *DNS Servers Status:* Normal *Dialup/IPASS Status: *Normal *Mail Servers Status:* Normal *Webservers Status: *Normal *Cogent Network Status/DNS Server Status Description: * Welcome to Cogent Communications' Network Status Message. Customers with traffic going through or on the east coast may be experiencing packet loss and higher than normal latency due to a fiber cut in New Jersey. There is no ETR at this time. The Cogent ticket to reference for this issue is HD2082680. Sincerely, Bobby Glover Director of Information Services South Valley Internet On 1/14/2010 9:31 AM, Joe Johnson wrote: > We just lost Cogent across the country, along with several sister companies. Can't get through to a support person. Any idea what's going on? > > Joe Johnson > Chief Information Officer > Riverside Consulting Group, Ltd. > Phone: 708.442.6033 x3456 > Fax: 708.442.9722 > joe at riversidecg.com > www.riversidecg.com > > > > > From robertg at garlic.com Thu Jan 14 11:42:47 2010 From: robertg at garlic.com (Robert Glover) Date: Thu, 14 Jan 2010 09:42:47 -0800 Subject: Cogent Outage? In-Reply-To: <001801ca9540$23f64c70$6be2e550$@net> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <001801ca9540$23f64c70$6be2e550$@net> Message-ID: <4B4F5797.8000002@garlic.com> Hello, Internet Pulse shows some bad-mojo right now: http://www.internetpulse.com/Main.aspx?OriginValue=Cogent&OriginLevel=1 Sincerely, Bobby Glover Director of Information Services South Valley Internet On 1/14/2010 9:36 AM, Aaron Wendel wrote: > Sitting on hold with them now. We lost them completely in Kansas City for > about 5 minutes. We're back but connectivity through them is spotty. Can't > even resolve google.com. Same with other DCs in the area. > > > > -----Original Message----- > From: Joe Johnson [mailto:joe at riversidecg.com] > Sent: Thursday, January 14, 2010 11:31 AM > To: nanog at nanog.org > Subject: Cogent Outage? > > We just lost Cogent across the country, along with several sister companies. > Can't get through to a support person. Any idea what's going on? > > Joe Johnson > Chief Information Officer > Riverside Consulting Group, Ltd. > Phone: 708.442.6033 x3456 > Fax: 708.442.9722 > joe at riversidecg.com > www.riversidecg.com > > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.725 / Virus Database: 270.14.140/2621 - Release Date: 01/14/10 > 06:39:00 > > > From Brian.Knight at us.mizuho-sc.com Thu Jan 14 11:56:16 2010 From: Brian.Knight at us.mizuho-sc.com (Knight, Brian) Date: Thu, 14 Jan 2010 12:56:16 -0500 Subject: Cogent Outage? In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <54777E145E97BE4E8C5A26DD78EFB11B01FEEF3D@EXMAIL.usi.mizuho-sc.com> > -----Original Message----- > From: Joe Johnson [mailto:joe at riversidecg.com] > Sent: Thursday, January 14, 2010 11:31 AM > To: nanog at nanog.org > Subject: Cogent Outage? > > We just lost Cogent across the country, along with several > sister companies. Can't get through to a support person. Any > idea what's going on? We lost access through Cogent in the Chicago area for a small number of sites. Some partners also reported problems getting to us. Cogent's updated status page includes the Jersey fiber cut and a routing problem: "Customers with traffic going through or on the east coast may be experiencing packet loss and higher than normal latency due to a fiber cut in New Jersey. Splice crews are at the site. There is no ETR at this time. The Cogent ticket to reference for this issue is HD2082680. A separate issue has been identified for customers in Toronto and Chicago. This appears to be a routing issue and the Cogent NOC is looking into the problem. There is no ETR at this time. The Cogent ticket to reference for this issue is HD2082851 " > Joe Johnson > Chief Information Officer > Riverside Consulting Group, Ltd. > Phone: 708.442.6033 x3456 > Fax: 708.442.9722 > joe at riversidecg.com > www.riversidecg.com -Brian Knight Sr. Network Engineer Mizuho Securities USA Inc http://www.mizuho-sc.com/ * Please note that I do not speak for my employer - only for myself. ** The below disclaimer is standard; the reader may consider addressees, mailing list members, and archive viewers to be intended recipients. CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. It is neither an offer to buy or sell, nor a solicitation of an offer to buy or sell, any securities or any related financial instruments mentioned in it. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Unless otherwise indicated, copyright and any other intellectual property rights in its contents are the sole property of Mizuho Securities USA Inc. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). ##################################################################################### From nonobvious at gmail.com Thu Jan 14 12:26:32 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 14 Jan 2010 10:26:32 -0800 Subject: I don't need no stinking firewall! In-Reply-To: <6BD6F623-E730-4FAE-8825-AE3293E2966A@kumari.net> References: <29A54911243620478FF59F00EBB12F4701B27EDF@ex01.drtel.lan> <5CD643B0-68FE-44DD-8345-549F72C19E9A@arbor.net> <4B47D331.1040706@bogus.com> <7EF60B80-4270-4128-BC6F-1680A7B94757@arbor.net> <4B4803A3.50400@bogus.com> <836bf1f91001091451la8a2a2dy356ab1a5d7aa4e7b@mail.gmail.com> <85FE6E82-651C-431C-813C-B8FDA56AD85B@arbor.net> <836bf1f91001092222k304f2ba0o288cf0cf5b83cf6b@mail.gmail.com> <6BD6F623-E730-4FAE-8825-AE3293E2966A@kumari.net> Message-ID: <18a5e7cb1001141026v41e0cf78g3e846d27055223c2@mail.gmail.com> On Wed, Jan 13, 2010 at 9:37 PM, Warren Kumari wrote: > I can now place a checkbox in the "Is there a firewall?" column of the > audit. In most cases, you can check the same box if you use an appropriately designed stateless firewall instead of an inappropriate stateful firewall. (Not always, of course.) And it will keep out some fraction of noise and anklebiters, and optionally give you a place to hang limited intrusion detection, without providing an easy path for attackers to crash your connection. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From joe at riversidecg.com Thu Jan 14 12:28:19 2010 From: joe at riversidecg.com (Joe Johnson) Date: Thu, 14 Jan 2010 12:28:19 -0600 Subject: Cogent Outage? In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> Message-ID: <154EDE9026B3D54F883B20F2BBDCF8790177E4CA@exbe01.windows.riversidecg.com> Joe Johnson said: > We just lost Cogent across the country, along with several sister companies. > Can't get through to a support person. Any idea what's going on? We're back up in both Chicago locations, Troy, LA, Dallas, and NY now. Chicago, Troy, and LA were complete losses for close to 35 minutes and Dallas and NY were 50-60% packet loss, so they were practically worthless. Thanks! Joe From kloch at kl.net Thu Jan 14 12:41:23 2010 From: kloch at kl.net (Kevin Loch) Date: Thu, 14 Jan 2010 13:41:23 -0500 Subject: Cogent Outage? In-Reply-To: <61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local> Message-ID: <4B4F6553.5040005@kl.net> Ketan Mangal wrote: > Yes there is a Newyork to Philadelphia fiber cut is there > It might not be an outage it might be high latency due to multiple > routes going out via there buffalo POP. That fiber cut was at 9:30EST this morning, the major Cogent internal routing problems started around 12:10 and lasted about 30 mins. - Kevin From john at sackheads.org Thu Jan 14 12:53:45 2010 From: john at sackheads.org (John Payne) Date: Thu, 14 Jan 2010 13:53:45 -0500 Subject: Cogent Outage? In-Reply-To: <4B4F6553.5040005@kl.net> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local> <4B4F6553.5040005@kl.net> Message-ID: <5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org> On Jan 14, 2010, at 1:41 PM, Kevin Loch wrote: > Ketan Mangal wrote: >> Yes there is a Newyork to Philadelphia fiber cut is there It might not be an outage it might be high latency due to multiple >> routes going out via there buffalo POP. > > That fiber cut was at 9:30EST this morning, the major Cogent internal > routing problems started around 12:10 and lasted about 30 mins. Isn't this what the outages list is for? From cb.list6 at gmail.com Thu Jan 14 13:10:08 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 14 Jan 2010 11:10:08 -0800 Subject: Are IPv6-only Internet services viable today? Message-ID: Folks, My question to the community is: assuming a network based IPv6 to IP4 translator is in place (like NAT64 / DNS64), are IPv6-only Internet services viable as a product today? In particular, would it be appropriate for a 3G /smartphone or wireless broadband focused on at casual (web and email) Internet users? Keep in mind, these users have NAT44 today. There has been a lot of discussion about CGN / LSN / and other technologies around the corner. In the mobile network operator space, the lack of IPv4 addresses, both public and RFC 1918, has been very real for a long time. In North America, mobile network operators have numbered subscribers with BOGON space (obvious risk) and relaunched multiple instances of RFC1918 space multiple times within their AS (breaking end-to-end even within their own AS, which is a problem with technologies increasingly moving towards any-to-any SIP and IMS). In any event, we can clearly state the addressing issue has compromised both engineering and business decisions in today's major mobile networks. Both scenarios above require tremendous NAT44 infrastructure. And, future CGN technologies don't give me much comfort that things will get better for the operator or the consumer. So, i have been looking more at offering IPv6-only service with NAT64 translation to access the IPv4 Internet. For the network operator, the NAT44 and NAT64 aggregate network state / number of translation is the same to start, and as more native IPv6 content come on the NAT64 gracefully. In fact, given that Google is IPv6 now, and Google is content leader, moving to NAT64 would actually be a reduction in NET NAT translations. IMHO, any dual-stack solution is not an adequate interim solution since both private and public IPv4 addresses are simply not available or will be soon completely exhausted. Dual-stack will have a role in the future, just like public IPv4 addresses have a role today. Dual-stack will be a required service for users with special requirements (legacy IPv4 VPNs ....) , not average web and email users that account for greater than ~80% of a mobile operator's customer base. I also want to stress that this solution best fits new subscribers and devices, it will not be a solution for Window 98 ... or Windows XP in fact. This draft is helpful in understanding the issues as well as the IETF's work on NAT64 draft-penno-behave-64-analysis-02 Some folks in a lab decided to see what type of user experience can be expected using NAT64 and DNS64 and IPv6-only on the end system -- using commonly available hardware and software that's available today, but different from the kit used for the NANOG IPv6 hour. In this case, there is a NAT-PT box in place of NAT64, they used an open source DNS64 implementation, and a standard WIndows 7 Starter edition netbook. I think the conclusion is that casual Internet use, as a product, is possible today. It is not everything IPv4 offers today, but as IPv6 content and applications come on-line the IPv6 capabilities will exceed what IPv4 could do (no NAT for native flows). Screenshot video below, best viewed in HQ mode. This is just a data point with regard to functionality that is akin to NAT64 / DNS64 that is available today. http://www.youtube.com/theipv6guy From dts at senie.com Thu Jan 14 13:16:19 2010 From: dts at senie.com (Daniel Senie) Date: Thu, 14 Jan 2010 14:16:19 -0500 Subject: Cogent Outage? In-Reply-To: <5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local> <4B4F6553.5040005@kl.net> <5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org> Message-ID: <81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com> On Jan 14, 2010, at 1:53 PM, John Payne wrote: > > On Jan 14, 2010, at 1:41 PM, Kevin Loch wrote: > >> Ketan Mangal wrote: >>> Yes there is a Newyork to Philadelphia fiber cut is there It might not be an outage it might be high latency due to multiple >>> routes going out via there buffalo POP. >> >> That fiber cut was at 9:30EST this morning, the major Cogent internal >> routing problems started around 12:10 and lasted about 30 mins. > > Isn't this what the outages list is for? Indeed. Please keep NANOG clear for inane pontification and religious wars regarding firewalls, for non-lawyers arguing the finer points of the law, and for most anything else that is non-operational in nature. From bjohnson at drtel.com Thu Jan 14 13:45:35 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 14 Jan 2010 13:45:35 -0600 Subject: Cogent Outage? In-Reply-To: <81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org> <81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com> Message-ID: <29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> > -----Original Message----- > From: Daniel Senie [mailto:dts at senie.com] > Sent: Thursday, January 14, 2010 1:16 PM > To: NANOG list > Subject: Re: Cogent Outage? > > Indeed. Please keep NANOG clear for inane pontification and religious > wars regarding firewalls, for non-lawyers arguing the finer points of > the law, and for most anything else that is non-operational in nature. Daniel, I may not understand the NANOG list charter, but I think operational issues would not be just YOUR operational issues. I would agree that not everything discussed here is operational for you. :) - Brian CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From Kevin_Burns at Cable.Comcast.com Thu Jan 14 14:00:29 2010 From: Kevin_Burns at Cable.Comcast.com (Burns, Kevin) Date: Thu, 14 Jan 2010 13:00:29 -0700 Subject: No subject In-Reply-To: <29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com> <29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> Message-ID: <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> Unsubscribe From LarrySheldon at cox.net Thu Jan 14 14:03:55 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 14 Jan 2010 14:03:55 -0600 Subject: In-Reply-To: <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com> <29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> Message-ID: <4B4F78AB.3020409@cox.net> On 1/14/2010 2:00 PM, Burns, Kevin wrote: > Unsubscribe No! I just re-subscribed for the fist time in years. Who are you to tell me to unsubscribe? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From srgqwerty at gmail.com Thu Jan 14 16:14:45 2010 From: srgqwerty at gmail.com (Srg) Date: Thu, 14 Jan 2010 23:14:45 +0100 Subject: vlan translation and stp Message-ID: <1263507285.3063.29.camel@ping01> Hello: We are going to have the following (simplified scenario): - vlans 101,102 are going to have servers. - vlan 101 uses 10.101.101.0/24 addressing and vlan 102 uses 10.102.102.0/24 addressing. - vlans 101 and 102 doesn't have level 3. - vlans 201,202 are going to have the level3 interfaces corresponding to vlans 101 and 102 respectively, so vlan201 will have the "interface vlan 201" defined as 10.101.101.1/24 and vlan202 will have the "interface vlan 202" defined as 10.102.102.1/24 At this point, if we do not any more things, servers from vlan101 or vlan102 will not be able to reach their default gateway because the default gateway is in another vlan. OK, Then we get two devices (IPS1 & IPS2), each of them having two interfaces. IPS1,interface 1 is connected to switch1 port 1/1. IPS1,interface 2 is connected to switch2 port 2/1. IPS2,interface 1 is connected to switch1 port 1/2. IPS2,interface 2 is connected to switch2 port 2/2. switch1,port 1/1 is a trunk with allowed vlans 101,102. switch1,port 1/2 is a trunk with allowed vlans 101,102. switch2,port 2/1 is a trunk with allowed vlans 201,202. switch2,port 2/2 is a trunk with allowed vlans 201,202. IPS1 will have the following config: Traffic entering interface 1 must be forwarded to interface 2 with the following vlan translations: original_vlan 101 is translated_to_vlan 201 original_vlan 102 is translated_to_vlan 202 Traffic entering interface 2 must be forwarded to interface 1 with the following vlan translations: original_vlan 201 is translated_to_vlan 101 original_vlan 202 is translated_to_vlan 102 Exactly the same config to IPS2. My question is if this is a valid configuration from the spanning-tree point of view, I ask this because we translate de vlan tags and we are thinking that this can affect the correct operation of stp. In other words... with this config will we have a loop or stp will operate OK and put one port (1/1,1/2,2/1 or 2/2) as blocking? Keep in mind that doing an etherchannel between 1/1 and 2/1 and another etherchannel between 2/1 and 2/2 is not an option in this case (remember the explanation is a "simplified scenario" :-) the real one is a lot bigger and is nor possible for us to make the etherchannels). Thanks a lot and best regards From jfbeam at gmail.com Thu Jan 14 16:21:31 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 14 Jan 2010 17:21:31 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B4CC5C1.4010806@gmail.com> References: <20100111154759.GK6617@sizone.org> <9E57EFB7-12FB-4A5F-A82E-B67DBEC52C57@jedsmith.org> <20100112174258.GB9961@hesketh.com> <4B4CC5C1.4010806@gmail.com> Message-ID: On Tue, 12 Jan 2010 13:56:01 -0500, JC Dill wrote: > It's a common belief among network operators that if a "server operator" > doesn't have access/ability to modify the PTR record for a server, it's > a good sign that the server shouldn't be used to send email, but instead > should send email thru an email server provided by their upstream access > provider. That would be fine *IF* SORBS, et. al., actually paid any attention to such things. I have dealt with SORBS several times over the years, and NEVER, EVER, have they given a single shit. Your connection is "ADSL" and therefore "residential"... We were told by the ISP that address range is "residential" -- a verified f***ing lie, btw. The request has to come from the ISP -- which they will ignore as well. To date, everyone who's ever blocked an email from me due to SORBS DUL, *NO LONGER USES SORBS*. (I also rewrote the sendmail macro to explicitly ignore their spamtrap list as well. It only takes one message, EVER, to get listed forever. And they will not show you the message(s) that got you listed.) --Ricky From randy at psg.com Thu Jan 14 16:31:12 2010 From: randy at psg.com (Randy Bush) Date: Fri, 15 Jan 2010 07:31:12 +0900 Subject: ICSI Netalyzr launch #2 In-Reply-To: References: <201001131542.o0DFgXra021480@pork.ICSI.Berkeley.EDU> Message-ID: >> there are no data in the report, just OK lines with no numbers. and >> clicking the links on the lines gave me docs not numbers. bring back >> the old version! > still there, just hiding. > click the + sign at the top to "expand all". aha! thank you! randy From jimb at jsbc.cc Thu Jan 14 17:00:36 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Thu, 14 Jan 2010 15:00:36 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: Message-ID: <4B4FA214.4030808@jsbc.cc> On 1/14/2010 11:10, Cameron Byrne wrote: > Folks, > > My question to the community is: assuming a network based IPv6 to IP4 > translator is in place (like NAT64 / DNS64), are IPv6-only Internet > services viable as a product today? In particular, would it be > appropriate for a 3G /smartphone or wireless broadband focused on at > casual (web and email) Internet users? Keep in mind, these users have > NAT44 today. > You may also want to read up on Dual Stack Lite (DS-Lite) , presuming you haven't. I know you mentioned you didn't like any dual-stack solutions, but the thing about DS-Lite I like is that it has no problem with RFC1918 overlap of different customers, since the CGN uses a tunnel ID in the connection/NAT table in addition to the other typical data. I just wonder how it will scale, since each device, or a gateway the device goes though, will require a IPv4-in-IPv6 tunnel to the CGN box(es). Also, it doesn't require a DNS-ALG like NAT64/DNS64. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From cb.list6 at gmail.com Thu Jan 14 17:20:32 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 14 Jan 2010 15:20:32 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: <4B4FA214.4030808@jsbc.cc> References: <4B4FA214.4030808@jsbc.cc> Message-ID: On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell wrote: > On 1/14/2010 11:10, Cameron Byrne wrote: >> Folks, >> >> My question to the community is: ?assuming a network based IPv6 to IP4 >> translator is in place (like NAT64 / DNS64), are IPv6-only Internet >> services viable as a product today? ?In particular, would it be >> appropriate for a 3G /smartphone or wireless broadband focused on at >> casual (web and email) Internet users? ?Keep in mind, these users have >> NAT44 today. >> > You may also want to read up on Dual Stack Lite (DS-Lite) > , I have looked at DS-lite very carefully. First, DS-Lite fits better for cable operators since they have CPE and can have a DS-lite function in the CPE that they control, and that in turn allows them to provide IPv4, IPv6, and dual-stack to the end-host that they do not control. DS-Lite does not fit as well for a mobile phones since it would require a major change to the phone's OS. Second, DS-Lite requires tunneling as well as translation, so it is one more piece of overhead in addition to NAT64 solution. For me, i believe it is less complex to manage a single stack IPv6 host with NAT64 translation than a dual stack host, tunneling infrastructure, as well as NAT44 CGN, which is what DS-lite requires. They both achieve the same result, but I believe in the mobile space there is a quicker time to market as well as more progress toward the end-goal of IPv6-only using NAT64 than DS-lite. > presuming you haven't. ?I know you mentioned you didn't like any > dual-stack solutions, but the thing about DS-Lite I like is that it has > no problem with RFC1918 overlap of different customers, since the CGN > uses a tunnel ID in the connection/NAT table in addition to the other > typical data. ?I just wonder how it will scale, since each device, or a > gateway the device goes though, will require a IPv4-in-IPv6 tunnel to > the CGN box(es). ?Also, it doesn't require a DNS-ALG like NAT64/DNS64. NAT64/DNS64 does not use a DNS-ALG. DNS-ALG died with NAT-PT. DNS64 is a standalone function which is decoupled from the translation process. > From xleonzhao at gmail.com Thu Jan 14 21:58:32 2010 From: xleonzhao at gmail.com (Xiaoliang Zhao) Date: Fri, 15 Jan 2010 11:58:32 +0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: Message-ID: <4e913c5d1001141958vc5fd450xd95ec432ea999b40@mail.gmail.com> > > My question to the community is: ?assuming a network based IPv6 to IP4 > translator is in place (like NAT64 / DNS64), are IPv6-only Internet > services viable as a product today? Well, speaking for CERNET2 (2nd Gen. of China Education and Research Network), it is a "production" network today in the sense that it connects 100+ china universities, and it runs IPv6 only. > In particular, would it be > appropriate for a 3G /smartphone or wireless broadband focused on at > casual (web and email) Internet users? ?Keep in mind, these users have > NAT44 today. That's actually a very good question. My personal take is 3G/4G *is* the best fit to IPv6, and it will be a win-win situation if we combine them together. At wireless side, there will be a LOT more addresses, unblocked end-to-end communication, location and ID separation, and maybe more new applications based on information carried in IPv6 header. At IPv6 side, we need larger user base, more contents, more applications to make IPv6 really take off, and 3G/4G can make that push. Regards, Leon From aforestal at wolve.com Thu Jan 14 22:09:50 2010 From: aforestal at wolve.com (Forestal, Andre Jr.) Date: Thu, 14 Jan 2010 22:09:50 -0600 Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT In-Reply-To: <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com><29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> Message-ID: <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> Hello: As many of you are aware right now, Haiti is in Chaos. This website has been put up to provide a central repository where relatives from the States can register information about their loved ones. Looking at a report that 1And1 has turned-off the site because it is suspected as a "spam" site, due to the influx of posts. Please, this site is critical in this very fluid, and horrible situation. If anyone can help, please get 1And1 to take action here. Here is a post regarding the issue: "Koneksyon.com will be right back We are sorry but koneksyon.com will be right back. We are experiencing some technical difficulties and we cannot get in touch with 1and1.com our hosting company. It seems that our website has been reported for spamming when all we are trying to do is help people find information about their loved ones in Haiti. Published on January 14, 2010 10:43 pm. Filed under: News Tags: 1and1, haiti, help, hosting, koneksyon.com" This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. From chaim.rieger at gmail.com Thu Jan 14 22:12:48 2010 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Fri, 15 Jan 2010 04:12:48 +0000 Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT In-Reply-To: <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com><29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan><806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com><6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> Message-ID: <1760493820-1263528777-cardhu_decombobulator_blackberry.rim.net-258970930-@bda123.bisx.prod.on.blackberry> No offense but let the red cross do its job. Sent via BlackBerry from T-Mobile -----Original Message----- From: "Forestal, Andre Jr." Date: Thu, 14 Jan 2010 22:09:50 To: NANOG list Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT Hello: As many of you are aware right now, Haiti is in Chaos. This website has been put up to provide a central repository where relatives from the States can register information about their loved ones. Looking at a report that 1And1 has turned-off the site because it is suspected as a "spam" site, due to the influx of posts. Please, this site is critical in this very fluid, and horrible situation. If anyone can help, please get 1And1 to take action here. Here is a post regarding the issue: "Koneksyon.com will be right back We are sorry but koneksyon.com will be right back. We are experiencing some technical difficulties and we cannot get in touch with 1and1.com our hosting company. It seems that our website has been reported for spamming when all we are trying to do is help people find information about their loved ones in Haiti. Published on January 14, 2010 10:43 pm. Filed under: News Tags: 1and1, haiti, help, hosting, koneksyon.com" This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. From aforestal at wolve.com Thu Jan 14 22:17:33 2010 From: aforestal at wolve.com (Forestal, Andre Jr.) Date: Thu, 14 Jan 2010 22:17:33 -0600 Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT In-Reply-To: <1760493820-1263528777-cardhu_decombobulator_blackberry.rim.net-258970930-@bda123.bisx.prod.on.blackberry> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com><29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan><806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com><6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> <1760493820-1263528777-cardhu_decombobulator_blackberry.rim.net-258970930-@bda123.bisx.prod.on.blackberry> Message-ID: <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD9@WOLVE-MAILBOX.wolve.com> I completely understand, however this website went up since yesterday morning, way before anything else of its kind went up, and there were already thousands of entries and folks were already relying on it as a mean to locate loved ones. It is certainly not a substitute to the registry that the Redcross has in place, but it has already helped relatives track each other. I am simply appealing to this community as a way to get through to 1And1. That's all. Thx -----Original Message----- From: chaim.rieger at gmail.com [mailto:chaim.rieger at gmail.com] Sent: Thursday, January 14, 2010 11:13 PM To: Forestal, Andre Jr.; NANOG list Subject: Re: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT No offense but let the red cross do its job. Sent via BlackBerry from T-Mobile -----Original Message----- From: "Forestal, Andre Jr." Date: Thu, 14 Jan 2010 22:09:50 To: NANOG list Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT Hello: As many of you are aware right now, Haiti is in Chaos. This website has been put up to provide a central repository where relatives from the States can register information about their loved ones. Looking at a report that 1And1 has turned-off the site because it is suspected as a "spam" site, due to the influx of posts. Please, this site is critical in this very fluid, and horrible situation. If anyone can help, please get 1And1 to take action here. Here is a post regarding the issue: "Koneksyon.com will be right back We are sorry but koneksyon.com will be right back. We are experiencing some technical difficulties and we cannot get in touch with 1and1.com our hosting company. It seems that our website has been reported for spamming when all we are trying to do is help people find information about their loved ones in Haiti. Published on January 14, 2010 10:43 pm. Filed under: News Tags: 1and1, haiti, help, hosting, koneksyon.com" This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. From jmamodio at gmail.com Thu Jan 14 22:34:01 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 14 Jan 2010 22:34:01 -0600 Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT In-Reply-To: <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com> <61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local> <4B4F6553.5040005@kl.net> <5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org> <81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com> <29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> Message-ID: <202705b1001142034v2c7985f6j10155f1bb8159846@mail.gmail.com> I'm not sure if it relates to this site, you didn't provide a link to the report about 1and1 actions but the FBI is very active tracking many sites and hundreds of domains that are popping up in several places after the quake and that are a scam. I'm not saying this site is legit, but just starting with the name it sounds very suspicious. I second the recommendation to support the Red Cross or other well established relief organizations. If you are willing to provide a contribution another option is http://www.unfoundation.org/. UNDP is also providing updates via youtube http://www.youtube.com/user/undp Regards Jorge On Thu, Jan 14, 2010 at 10:09 PM, Forestal, Andre Jr. wrote: > Hello: > > As many of you are aware right now, Haiti is in Chaos. ?This website has been put up to provide a central repository where relatives from the States can register information about their loved ones. > > Looking at a report that 1And1 has turned-off the site because it is suspected as a "spam" site, due to the influx of posts. > Please, this site is critical in this very fluid, and horrible situation. > > If anyone can help, please get 1And1 to take action here. > > Here is a post regarding the issue: > > "Koneksyon.com will be right back > We are sorry but koneksyon.com will be right back. We are experiencing some technical difficulties ?and we cannot get in touch with 1and1.com our hosting company. ?It seems that our website has been reported for spamming when all we are trying to do is help people find information about their loved ones in Haiti. > > Published on January 14, 2010 10:43 pm. > Filed under: News Tags: 1and1, haiti, help, hosting, koneksyon.com" From aforestal at wolve.com Thu Jan 14 22:37:07 2010 From: aforestal at wolve.com (Forestal, Andre Jr.) Date: Thu, 14 Jan 2010 22:37:07 -0600 Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com><29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan><806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com><6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> <202705b1001142034v2c7985f6j10155f1bb8159846@mail.gmail.com> Message-ID: <6BCBFA220A7F4F49BD5A8EEA0A0F7709100B036A@WOLVE-MAILBOX.wolve.com> Thanks all for the quick responses. Got what we needed. for clarification: This website does not involve any donations at all. It is simply a bulletin board application that allows US based relatives to post name, last known location of people in Haiti whom they can not get in touch with. Since there is still internet access available in Haiti via satellite, there are people in Haiti who would frequent the list and post a response if they happen to know of the whereabouts of someone listed on the site. once again thank you all. ________________________________ From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Thu 1/14/2010 11:34 PM To: Forestal, Andre Jr. Cc: NANOG list Subject: Re: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT I'm not sure if it relates to this site, you didn't provide a link to the report about 1and1 actions but the FBI is very active tracking many sites and hundreds of domains that are popping up in several places after the quake and that are a scam. I'm not saying this site is legit, but just starting with the name it sounds very suspicious. I second the recommendation to support the Red Cross or other well established relief organizations. If you are willing to provide a contribution another option is http://www.unfoundation.org/. UNDP is also providing updates via youtube http://www.youtube.com/user/undp Regards Jorge On Thu, Jan 14, 2010 at 10:09 PM, Forestal, Andre Jr. wrote: > Hello: > > As many of you are aware right now, Haiti is in Chaos. This website has been put up to provide a central repository where relatives from the States can register information about their loved ones. > > Looking at a report that 1And1 has turned-off the site because it is suspected as a "spam" site, due to the influx of posts. > Please, this site is critical in this very fluid, and horrible situation. > > If anyone can help, please get 1And1 to take action here. > > Here is a post regarding the issue: > > "Koneksyon.com will be right back > We are sorry but koneksyon.com will be right back. We are experiencing some technical difficulties and we cannot get in touch with 1and1.com our hosting company. It seems that our website has been reported for spamming when all we are trying to do is help people find information about their loved ones in Haiti. > > Published on January 14, 2010 10:43 pm. > Filed under: News Tags: 1and1, haiti, help, hosting, koneksyon.com" This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of email transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice. From r.engehausen at gmail.com Fri Jan 15 00:42:13 2010 From: r.engehausen at gmail.com (Roy) Date: Thu, 14 Jan 2010 22:42:13 -0800 Subject: Contact @ 1And1 hosting re: http://www.koneksyon.com/ - URGENT In-Reply-To: <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> References: <154EDE9026B3D54F883B20F2BBDCF8790177E4C0@exbe01.windows.riversidecg.com><61DCB7099770A24094E1A2B5D6C639C625363B@exchange151.Epik.local><4B4F6553.5040005@kl.net><5B6D85D7-4430-46F0-A957-D9D5C22B8A7C@sackheads.org><81F9A96A-B8BA-4C24-8E20-F82DCAA6D068@senie.com><29A54911243620478FF59F00EBB12F4701BFF563@ex01.drtel.lan> <806369B5EB737E45A01CF4A1D58FA0AE0CC4C063@COENGEXCMB01.cable.comcast.com> <6BCBFA220A7F4F49BD5A8EEA0A0F77092C80FBD7@WOLVE-MAILBOX.wolve.com> Message-ID: <4B500E45.9020903@gmail.com> Lots of these web sites popping up http://apps.facebook.com/haiti_survivors From david.binet at orange-ftgroup.com Fri Jan 15 03:37:02 2010 From: david.binet at orange-ftgroup.com (david.binet at orange-ftgroup.com) Date: Fri, 15 Jan 2010 10:37:02 +0100 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: Message-ID: <12206_1263548224_4B503740_12206_39090_1_1B2E7539FECD9048B261B791B1B24A7C18ADD79BB0@PUEXCB1A.nanterre.francetelecom.fr> Hello, Thank you for launching such useful discussions for operators. IPv6 introduction in mobile networks is certainly one major issue we have to consider for services and business development. As you stated, pressure on public and private IPv4 addresses is more and more important and we have to envisage IPv6 deployment in following years to avoid issues you are presenting in your mail. To do so, I think we need to converge on IPv6 introduction scenarios and requirements before investgating technical solutions. For example, if one trigger for IPv6 introduction is the lack of IPv4 addresses, we can not rely on some dual stack connectivity for IPv6 introduction and the only perennial solution will consist in allocating IPv6 only prefixes to UE, allowing to identify them without any ambiguity at least. Once such option has been retained we have to consider valid scenarios. Do we want that these only-v6 connected terminal access to IPv4-only Internet and walled garden services ? Do we want that some (piece of) IPv4 applications on the terminal access to IPv4 applications with an IPv6-only connectivity ?...IPv6 only services may be relevant, at least in some further stages of IPv6 integration. Once we have retained valid scenarios we have to deploy technical solutions to answer such needs. NAT64 for example may be needed but it has to be challenged with other solutions, including proxys solutions, DS-Lite, A+P...Actually NAT64 that is a flavor of NAT44, already largely deployed in mobile networks, may be a solution hoping that applications will be more and more DS and that IPv6 native communications will grow. I think we have to avoid some technical solutions based on some several translation mechanisms for an IP session. David > -----Message d'origine----- > De : Cameron Byrne [mailto:cb.list6 at gmail.com] > Envoy? : jeudi 14 janvier 2010 20:10 > ? : nanog at nanog.org > Objet : Are IPv6-only Internet services viable today? > > Folks, > > My question to the community is: assuming a network based > IPv6 to IP4 translator is in place (like NAT64 / DNS64), are > IPv6-only Internet services viable as a product today? In > particular, would it be appropriate for a 3G /smartphone or > wireless broadband focused on at casual (web and email) > Internet users? Keep in mind, these users have > NAT44 today. > > There has been a lot of discussion about CGN / LSN / and > other technologies around the corner. In the mobile network > operator space, the lack of IPv4 addresses, both public and > RFC 1918, has been very real for a long time. In North > America, mobile network operators have numbered subscribers > with BOGON space (obvious risk) and relaunched multiple > instances of RFC1918 space multiple times within their AS > (breaking end-to-end even within their own AS, which is a > problem with technologies increasingly moving towards > any-to-any SIP and IMS). In any event, we can clearly state > the addressing issue has compromised both engineering and > business decisions in today's major mobile networks. Both > scenarios above require tremendous NAT44 infrastructure. > And, future CGN technologies don't give me much comfort that > things will get better for the operator or the consumer. > So, i have been looking more at offering IPv6-only service > with NAT64 translation to access the IPv4 Internet. For the > network operator, the NAT44 and NAT64 aggregate network state > / number of translation is the same to start, and as more > native IPv6 content come on the NAT64 gracefully. In fact, > given that Google is IPv6 now, and Google is content leader, > moving to NAT64 would actually be a reduction in NET NAT translations. > > IMHO, any dual-stack solution is not an adequate interim > solution since both private and public IPv4 addresses are > simply not available or will be soon completely exhausted. > Dual-stack will have a role in the future, just like public > IPv4 addresses have a role today. > Dual-stack will be a required service for users with special > requirements (legacy IPv4 VPNs ....) , not average web and > email users that account for greater than ~80% of a mobile > operator's customer base. I also want to stress that this > solution best fits new subscribers and devices, it will not > be a solution for Window 98 ... > or Windows XP in fact. This draft is helpful in understanding > the issues as well as the IETF's work on NAT64 > draft-penno-behave-64-analysis-02 > > Some folks in a lab decided to see what type of user > experience can be expected using NAT64 and DNS64 and > IPv6-only on the end system -- using commonly available > hardware and software that's available today, but different > from the kit used for the NANOG IPv6 hour. In this case, > there is a NAT-PT box in place of NAT64, they used an open > source DNS64 implementation, and a standard WIndows 7 Starter > edition netbook. I think the conclusion is that casual > Internet use, as a product, is possible today. It is not > everything IPv4 offers today, but as IPv6 content and > applications come on-line the IPv6 capabilities will exceed > what IPv4 could do (no NAT for native flows). > > Screenshot video below, best viewed in HQ mode. This is just > a data point with regard to functionality that is akin to > NAT64 / DNS64 that is available today. > > http://www.youtube.com/theipv6guy > > ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From alain_durand at cable.comcast.com Fri Jan 15 07:29:46 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Fri, 15 Jan 2010 08:29:46 -0500 Subject: Are IPv6-only Internet services viable today? In-Reply-To: Message-ID: > > I have looked at DS-lite very carefully. First, DS-Lite fits better > for cable operators since they have CPE and can have a DS-lite > function in the CPE that they control, and that in turn allows them to > provide IPv4, IPv6, and dual-stack to the end-host that they do not > control. DS-Lite does not fit as well for a mobile phones since it > would require a major change to the phone's OS. Second, DS-Lite > requires tunneling as well as translation, so it is one more piece of > overhead in addition to NAT64 solution. For me, i believe it is less > complex to manage a single stack IPv6 host with NAT64 translation than > a dual stack host, tunneling infrastructure, as well as NAT44 CGN, > which is what DS-lite requires. They both achieve the same result, > but I believe in the mobile space there is a quicker time to market as > well as more progress toward the end-goal of IPv6-only using NAT64 > than DS-lite. > > ===> DS-lite can work both for fixed and wireless scenario, where you have a > laptop/pda/smarphone/tablet > that is only configured by the access network with IPv6 but want to access > IPv4 content FROM IPv4 applications. > This is the main difference between DS-lite and NAT64. NAT64 requires all > application on the user device to be IPv6 compatible. > Now, that may or may not be an issue. If you are talking about a proprietary > wireless device that run only proprietary apps, > porting all those apps to IPv6 prior to launching the service may be ok... > However, if the device can run external apps, like those coming > from an app store, or running pre-existing apps (I?m thinking about the > gazillions apps existing on the iPhone), then a NAT64 solution > will force a complete rewrite of every single one of those apps... DS-lite > would enable all those apps to keep working. Big difference. > > - Alain. > From alain_durand at cable.comcast.com Fri Jan 15 07:37:52 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Fri, 15 Jan 2010 08:37:52 -0500 Subject: Are IPv6-only Internet services viable today? Message-ID: [resending with more readable, apologies for the duplicate] DS-lite can work both for fixed and wireless scenario, where you have a laptop/pda/smarphone/tablet that is only configured by the access network with IPv6 but want to access IPv4 content FROM IPv4 applications. This is the main difference between DS-lite and NAT64. NAT64 requires all applications on the user device to be IPv6 compatible. Now, that may or may not be an issue. If you are talking about a proprietary wireless device that run only proprietary apps, porting all those apps to IPv6 prior to launching the service may be ok... However, if the device can run external apps, like those coming from an app store, or running pre-existing apps (I?m thinking about the gazillions apps existing on the iPhone), then a NAT64 solution will force a complete rewrite of every single one of those apps... DS-lite would enable all those apps to keep working. Big difference. - Alain. From williams.bruce at gmail.com Fri Jan 15 08:07:52 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Fri, 15 Jan 2010 06:07:52 -0800 Subject: Anyone see a game changer here? Message-ID: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Part of the discussion of recent attacks by targeted email to individuals crafted to deceive that particular individual based on intelligence gathered for this use by governments. "The alleged attacks from China are troubling on many fronts. On Thursday, security firm McAfee released a report saying the program used to target U.S. firms involved a so-called "zero day" vulnerability -- one that was to this point unknown to the security community, and thus indefensible by anti-virus software. The flaw involved Microsoft's Internet Explorer, McAfee said. Microsoft says it is working quickly to provide a software patch. But the malicious software attacks other software flaws too, McAfee said, adding this ominous note: "There very well may be other attack vectors that are not known to us at this time." "These highly customized attacks known as advanced persistent threats were primarily seen by governments and the mere mention of them strikes fear in any cyberwarrior,? wrote McAfee's George Kurtz in a blog post today. ?They are in fact the equivalent of the modern drone on the battle field. With pinpoint accuracy they deliver their deadly payload and once discovered - it is too late?All I can say is wow. The world has changed. Everyone's threat model now needs to be adapted to the new reality of these advanced persistent threats. In addition to worrying about Eastern European cybercriminals trying to siphon off credit card databases, you have to focus on protecting all of your core intellectual property." Mark Rasch, former head of the Department of Justice computer crime unit, called the attacks ?cyberwarfare,? and said it was clearly an escalation of a digital conflict between China and the U.S. As if the old threat models weren't bad enough... Bruce From ge at linuxbox.org Fri Jan 15 08:21:15 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 15 Jan 2010 16:21:15 +0200 Subject: Anyone see a game changer here? In-Reply-To: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Message-ID: <4B5079DB.6070504@linuxbox.org> On 1/15/10 4:07 PM, Bruce Williams wrote: > As if the old threat models weren't bad enough... The old threat models were simply not up to date. Gadi. > > > Bruce > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From marcus.sachs at verizon.com Fri Jan 15 08:32:21 2010 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Fri, 15 Jan 2010 09:32:21 -0500 Subject: Anyone see a game changer here? Message-ID: <81D582C724CA1046A279A7EE1299638B01C7FE9A@FHDP1LUMXCV24.us.one.verizon.com> The APT is the new game. Old rules, new game. -------------------------- Marcus H. Sachs Verizon +1 202 515 2463 Sent from my Verizon BlackBerry Storm http://www.verizonwireless.com/storm ----- Original Message ----- From: Gadi Evron To: nanog at nanog.org Sent: Fri Jan 15 09:21:15 2010 Subject: Re: Anyone see a game changer here? On 1/15/10 4:07 PM, Bruce Williams wrote: > As if the old threat models weren't bad enough... The old threat models were simply not up to date. Gadi. > > > Bruce > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From matthew at sorbs.net Fri Jan 15 09:17:44 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 16:17:44 +0100 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> Message-ID: <4B508718.30606@sorbs.net> telmnstr at 757.org wrote: >> Did SORBS really cause you that much pain? > > Yes. We purchased colo space for some systems that didn't need high > class of service (mostly development systems.) The IP space in a > former lifetime was a dialup pool for analog modems. > > We of course changed the reverse DNS entries, and did the normal > request with SORBS. Nothign really happened. I started looking into > it, and finding stories of people doing the mandatory $90 donation to > get express attention, ...and at this point we know the poster (like a fair few other in this thread) is either talking c**p or mixing SORBS with some other list. There is NO donation required for non spam listings (a DUHL entry is not a spam listing) and $90 is plucked from thin air... a cursory look at the SORBS website will attest to that. Michelle Note: The original poster was noted to have never opened a ticket @ SORBS by one of the staff.. I haven't verified that personally, but it does follow a common theme.. People complain about listings and have subsequently been found to have *not* requested delisting through the correct channel (the SORBS support system)... I wonder how many would get this sort of response (a firey NANOG thread) if they complained their ADSL was broken to the yellowpages sales line...?!?!? From ge at linuxbox.org Fri Jan 15 09:20:00 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 15 Jan 2010 17:20:00 +0200 Subject: Anyone see a game changer here? In-Reply-To: <81D582C724CA1046A279A7EE1299638B01C7FE9A@FHDP1LUMXCV24.us.one.verizon.com> References: <81D582C724CA1046A279A7EE1299638B01C7FE9A@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <4B5087A0.3080009@linuxbox.org> On 1/15/10 4:32 PM, Sachs, Marcus Hans (Marc) wrote: > The APT is the new game. Old rules, new game. I don't see why it's new just because suddenly people know what's going on around them. A bit like with botnets before 2004. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From tme at americafree.tv Fri Jan 15 09:20:33 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 15 Jan 2010 10:20:33 -0500 Subject: Anyone see a game changer here? In-Reply-To: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Message-ID: Where are these quotes coming from ? Marshall On Jan 15, 2010, at 9:07 AM, Bruce Williams wrote: > Part of the discussion of recent attacks by targeted email to > individuals crafted to deceive that particular individual based on > intelligence gathered for this use by governments. > > "The alleged attacks from China are troubling on many fronts. On > Thursday, security firm McAfee released a report saying the program > used to target U.S. firms involved a so-called "zero day" > vulnerability -- one that was to this point unknown to the security > community, and thus indefensible by anti-virus software. The flaw > involved Microsoft's Internet Explorer, McAfee said. Microsoft says it > is working quickly to provide a software patch. But the malicious > software attacks other software flaws too, McAfee said, adding this > ominous note: "There very well may be other attack vectors that are > not known to us at this time." > > "These highly customized attacks known as advanced persistent threats > were primarily seen by governments and the mere mention of them > strikes fear in any cyberwarrior,? wrote McAfee's George Kurtz in a > blog post today. ?They are in fact the equivalent of the modern drone > on the battle field. With pinpoint accuracy they deliver their deadly > payload and once discovered - it is too late?All I can say is wow. The > world has changed. Everyone's threat model now needs to be adapted to > the new reality of these advanced persistent threats. In addition to > worrying about Eastern European cybercriminals trying to siphon off > credit card databases, you have to focus on protecting all of your > core intellectual property." > > Mark Rasch, former head of the Department of Justice computer crime > unit, called the attacks ?cyberwarfare,? and said it was clearly an > escalation of a digital conflict between China and the U.S. > > As if the old threat models weren't bad enough... > > > Bruce > > From marcus.sachs at verizon.com Fri Jan 15 09:23:26 2010 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Fri, 15 Jan 2010 10:23:26 -0500 Subject: Anyone see a game changer here? Message-ID: <81D582C724CA1046A279A7EE1299638B01C7FE9F@FHDP1LUMXCV24.us.one.verizon.com> The botnet concept is one of the old rules. The way the APT works and what it is used for is the new game. -------------------------- Marcus H. Sachs Verizon +1 202 515 2463 Sent from my Verizon BlackBerry Storm http://www.verizonwireless.com/storm ----- Original Message ----- From: Gadi Evron To: Sachs, Marcus Hans (Marc) Cc: nanog at nanog.org Sent: Fri Jan 15 10:20:00 2010 Subject: Re: Anyone see a game changer here? On 1/15/10 4:32 PM, Sachs, Marcus Hans (Marc) wrote: > The APT is the new game. Old rules, new game. I don't see why it's new just because suddenly people know what's going on around them. A bit like with botnets before 2004. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From smb at cs.columbia.edu Fri Jan 15 09:26:14 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 15 Jan 2010 10:26:14 -0500 Subject: Anyone see a game changer here? In-Reply-To: <4B5079DB.6070504@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <4B5079DB.6070504@linuxbox.org> Message-ID: <478234AE-18A8-496B-93AF-C208EAC73B9E@cs.columbia.edu> On Jan 15, 2010, at 9:21 AM, Gadi Evron wrote: > On 1/15/10 4:07 PM, Bruce Williams wrote: >> As if the old threat models weren't bad enough... > > The old threat models were simply not up to date. Precisely correct. This has been going on for quite some time; some people simply weren't paying attention. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jlewis at lewis.org Fri Jan 15 09:37:30 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 15 Jan 2010 10:37:30 -0500 (EST) Subject: Anyone see a game changer here? In-Reply-To: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Message-ID: On Fri, 15 Jan 2010, Bruce Williams wrote: > "The alleged attacks from China are troubling on many fronts. On > Thursday, security firm McAfee released a report saying the program > used to target U.S. firms involved a so-called "zero day" > vulnerability -- one that was to this point unknown to the security > community, and thus indefensible by anti-virus software. The flaw ... > "These highly customized attacks known as advanced persistent threats > were primarily seen by governments and the mere mention of them > strikes fear in any cyberwarrior, wrote McAfee's George Kurtz in a He makes it sound like nobody's ever discovered 0-day sploits in use in the wild / had 0-day sploits used against them. The term 0-day has been around for quite some time for a reason. I don't see anything new here other than the insinuation that the Chinese government might have been behind their use. Does anyone really believe that the use of targeted 0-day exploits to gain unauthorized access to information hasn't been at least considered if not used by spies working for other [than China] countries? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From brunner at nic-naa.net Fri Jan 15 09:40:23 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 15 Jan 2010 10:40:23 -0500 Subject: Katrina response, private and public Message-ID: <4B508C67.5000309@nic-naa.net> Folks, After the Katrina landfall a diverse group of wireless people started organizing a relief effort, culminating in work around Waveland. There was also a group from the NPGS in Monterey, who worked on the Boxing Day Tsunami aftermath. Does anyone have a similar contact set? Eric From jared at puck.nether.net Fri Jan 15 09:43:35 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 15 Jan 2010 10:43:35 -0500 Subject: Anyone see a game changer here? In-Reply-To: References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Message-ID: <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> On Jan 15, 2010, at 10:37 AM, Jon Lewis wrote: > Does anyone really believe that the use of targeted 0-day exploits to gain unauthorized access to information hasn't been at least considered if not used by spies working for other [than China] countries? I think only those not paying attention would be left with that impression. Spying has been done for years on every side of various issues. Build a more complex system, someone will eventually find the weak points. Personally I was amused at people adding cement to USB ports to mitigate against the "removable media threat". The issue I see is people forget that floppies posed the same threat back in the day. The reality is that the technology is complex and easily used in asymmetrical ways, either for DDoS or for other purposes. The game is the same, it's just that some people are paying attention this week. It will soon go back to being harmless background radiation for most of us soon. - Jared From marks at bit.nl Fri Jan 15 09:50:25 2010 From: marks at bit.nl (Mark Schouten) Date: Fri, 15 Jan 2010 16:50:25 +0100 Subject: Virbl: The First IPv6 enabled dnsbl? Message-ID: <1263570625.5089.29.camel@highway.office.bit.nl> Hi, FYI: http://virbl.bit.nl/index.php#ipv6 Comments on the listing method are appreciated. Regards, -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 | KvK: 09090351 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 17FF From setient at gmail.com Fri Jan 15 09:52:10 2010 From: setient at gmail.com (Ronald Cotoni) Date: Fri, 15 Jan 2010 10:52:10 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B508718.30606@sorbs.net> References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> <4B508718.30606@sorbs.net> Message-ID: <2f1d68351001150752r60e6cei87e500702328f8ea@mail.gmail.com> On Fri, Jan 15, 2010 at 10:17 AM, Michelle Sullivan wrote: > telmnstr at 757.org wrote: >>> >>> Did SORBS really cause you that much pain? >> >> Yes. We purchased colo space for some systems that didn't need high class >> of service (mostly development systems.) The IP space in a former lifetime >> was a dialup pool for analog modems. >> >> We of course changed the reverse DNS entries, and did the normal request >> with SORBS. Nothign really happened. I started looking into it, and finding >> stories of people doing the mandatory $90 donation to get express attention, > > ...and at this point we know the poster (like a fair few other in this > thread) is either talking c**p or mixing SORBS with some other list. ?There > is NO donation required for non spam listings (a DUHL entry is not a spam > listing) and $90 is plucked from thin air... a ?cursory look at the SORBS > website will attest to that. > > > Michelle > > Note: The original poster was noted to have never opened a ticket @ SORBS by > one of the staff.. ?I haven't verified that personally, but it does follow a > common theme.. ?People complain about listings and have subsequently been > found to have *not* requested delisting through the correct channel (the > SORBS support system)... ?I wonder how many would get this sort of response > (a firey NANOG thread) if they complained their ADSL was broken to the > yellowpages sales line...?!?!? > > At the same time, I never hear this about spamhaus or outblaze. Go figure :( Maybe your system is too confusing and you might want to take a survey and revamp it to something a bit more functional. From smb at cs.columbia.edu Fri Jan 15 09:52:31 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 15 Jan 2010 10:52:31 -0500 Subject: Anyone see a game changer here? In-Reply-To: <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> Message-ID: <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> On Jan 15, 2010, at 10:43 AM, Jared Mauch wrote: > > On Jan 15, 2010, at 10:37 AM, Jon Lewis wrote: > >> Does anyone really believe that the use of targeted 0-day exploits to gain unauthorized access to information hasn't been at least considered if not used by spies working for other [than China] countries? > > I think only those not paying attention would be left with that impression. > > Spying has been done for years on every side of various issues. Build a more complex system, someone will eventually find the weak points. > > Personally I was amused at people adding cement to USB ports to mitigate against the "removable media threat". The issue I see is people forget that floppies posed the same threat back in the day. > > The reality is that the technology is complex and easily used in asymmetrical ways, either for DDoS or for other purposes. > > The game is the same, it's just that some people are paying attention this week. It will soon go back to being harmless background radiation for most of us soon. > The "difference" this week is motive. In the 1980s-1990s, we had joy-hacking. In the 2000s, we had profit-motivated hacking by criminals. We now have (and have had for a few years) what appears to be nation-state hacking. The differences are in targets and resources available to the attacker. --Steve Bellovin, http://www.cs.columbia.edu/~smb From marcus at blazingdot.com Fri Jan 15 10:06:01 2010 From: marcus at blazingdot.com (Marcus Reid) Date: Fri, 15 Jan 2010 08:06:01 -0800 Subject: Anyone see a game changer here? In-Reply-To: References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Message-ID: <20100115160601.GA34760@blazingdot.com> On Fri, Jan 15, 2010 at 10:20:33AM -0500, Marshall Eubanks wrote: > Where are these quotes coming from ? That particular one: http://redtape.msnbc.com/2010/01/gregory-fayer-opened-an-e-mail-on-monday-night-that-looked-like-it-was-from-a-fellow-lawyer-at-gipson-hoffman-pancione-inst.html Some more commentary: http://www.wired.com/threatlevel/2010/01/operation-aurora/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+wired27b+%28Blog+-+27B+Stroke+6+%28Threat+Level%29%29&utm_content=Google+Reader Of course, you'll have to follow links in an email in order to read those, if you dare. Marcus From matthew at sorbs.net Fri Jan 15 10:06:18 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 17:06:18 +0100 Subject: SORBS on autopilot? In-Reply-To: <20100111154759.GK6617@sizone.org> References: <20100111154759.GK6617@sizone.org> Message-ID: <4B50927A.9030500@sorbs.net> Ken Chase wrote: > Anyone got some pointers on how to get off SORBS' Dynamic IP lists? > > We've followed their RFC proposed static reverse DNS assignment naming and all > elements of their FAQ. > > We are not spammers. The /24 in question isnt listed on any RBLs except SORBS DUL. > > We've submitted requests in various different formats, but get a robot reply > and -ENOJOY. > > We've even had our upstream that is listed at the RIR as managing the supernet > of our BGP announced prefixes submit requests to delist for the /24, but > we are only ever replied to by a robot that lists 67.196.137.0/24 as > dynamic except .163 (somehow manually excluded from their db, I think when > they werent adrift in years past). Our upstream's techs are also at a loss now > and suggested I seek arcane clue amongst the sages here. > > Pointers appreciated. > > /kc > OK, following my last post I have been given 4 ticket numbers for the same network. 3 appear to be from Ken using a different email address (hence why we couldn't find a ticket from him.) Normally I would not post a public response, but this case is what seems to be a reoccurring theme, so maybe it's time to post comment. Each of the tickets are similar in that they all refer to the same space. All were rejected by the robot with the following text at the end of the reply: > I'm now marking this request as 'answered' as I think there's nothing > more for me to do. If you feel otherwise, please reply to this message > to re-open your ticket. In particular, if you change your rDNS > information. Each of the 4 tickets (the three by Ken) are all sitting in the state of "Answered" ... so at no point has a human had chance to see the issue and override the bot's decision. The common a reoccurring issue is the response by the robot has given the next logical step to progress any delisting request (as has been stated here recently, in another thread).. and the requester has either not read the response or chosen to ignore the response or ... then the come here complaining about not getting a response from SORBS. The reality is they got a response from SORBS and did not act upon the response. Sorry Ken, this is not having a go at you, but it is a very common theme and deserves airing. Other issues are where the appropriate contact (as listed in the whois record at the RIR) also ignore the same two sentences, get rejected by the robot and choose to log a new ticket only to get the same response over and over again. Is it bad English? Is it not clear? Can anyone else give better wording that might result in less of an issue? The process is relatively simple: For fast approval: Log ticket -> robot checks rDNS for all networks listed in ticket -> robot confirms all space is static and submits the ticket to the removals queue where it is manually checked by a human and processed. For manual approval: Log ticket -> robot checks rDNS for all networks listed in ticket -> robot denies delisting request sending response -> OP changes something and replies, just states they are the whois listed appropriate contact, or gives some reason why the robot is wrong and reopens the ticket with the reply -> SORBS volunteer reviews the available information from the robot and the subsequent reply from the OP and manually submits to the removals queue or rejects and gives a human response as to why (eg like with Shaw, Road Runner, Verizon, etc listings) the information is provided by the ISP and any delisting will be reversed within a week. No NANOG is not about SORBS and SORBS should not really be discussed here, but telling people they would be better discussing it on Spam-L will not help you at all as I cannot post there and consequently I have since unsubscribed, as I have suggested to all my staff. Messaging me directly about listings will not help your case, unless something has gone wrong (and since Jan 09 I have only had one issue where something went wrong in the SORBS systems, all other requests were without tickets or twits that logged a ticket and sent me the ticket number before the robot had replied because they thought they might get special attention.) The best thing anyone can do is read the automated responses (some are from the system as the ticket is logged, some are from the robots) completely, and act upon what they say as majority of the time this will result in a fast delisting.. Christmas Eve 2009, DUHL delisting requests were happening within an hour of requesting a delisting. My moving internationally and 30 hours in the air have slowed that process, but I intend to get it back to within 60 minute responses again by the end of January. Michelle From jmamodio at gmail.com Fri Jan 15 10:13:36 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 15 Jan 2010 10:13:36 -0600 Subject: Anyone see a game changer here? In-Reply-To: <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> Message-ID: <202705b1001150813v46793213t51ffe76969f9756b@mail.gmail.com> > We now have (and have had for a few years) what appears to be nation-state hacking. ?The differences are in targets and resources available to the attacker. Agreed, and given that is more easy to aggregate bits of information from different sources to put together the puzzle it makes more sense for a nation-state to do so when they are pursuing information about advanced technology. Folks are concerned about the coming fall IETF meeting, without drinking from the conspiracy theory fountain, I'm almost sure that -unless somebody do something really stupid- nobody will have any problems, the host country will be delighted to have so many "technologists" with juicy information and experience under their roof and "surveillance." Regards Jorge From matthew at sorbs.net Fri Jan 15 10:13:34 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 17:13:34 +0100 Subject: SORBS on autopilot? In-Reply-To: <2f1d68351001150752r60e6cei87e500702328f8ea@mail.gmail.com> References: <20100111154759.GK6617@sizone.org> <5A587D3A-6F09-4F0B-8790-91EB58A46068@ianai.net> <4B508718.30606@sorbs.net> <2f1d68351001150752r60e6cei87e500702328f8ea@mail.gmail.com> Message-ID: <4B50942E.9070205@sorbs.net> Ronald Cotoni wrote: > > At the same time, I never hear this about spamhaus or outblaze. Go > figure :( Maybe your system is too confusing and you might want to > take a survey and revamp it to something a bit more functional. > I have never heard it about Outblaze, but I have heard "at least we get a reply from you unlike with Spamhaus" several times. The only thing I can't work out is why those people never post that publicly... and yet the same 50-100 people keep getting the same attention over SORBS time and time again. I love searching "SORBS Sucks" in Google and counting the number of hits that are actually the same people over and over again on multiple lists (especially Mr "Be good to pigeons".) The SORBS support system has become more and more stricter because of the people trying to circumvent the process. There are many people that have no problem at all with the SORBS support system so why it is so hard for a few? Perhaps it's because they don't really care about delisting but do care about making noise? (for example there are a number of people on this list that are here only to response negatively to SORBS issues.) Michelle From ge at linuxbox.org Fri Jan 15 10:13:57 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 15 Jan 2010 18:13:57 +0200 Subject: Anyone see a game changer here? In-Reply-To: <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> Message-ID: <4B509445.1030809@linuxbox.org> On 1/15/10 5:52 PM, Steven Bellovin wrote: > > On Jan 15, 2010, at 10:43 AM, Jared Mauch wrote: > >> >> On Jan 15, 2010, at 10:37 AM, Jon Lewis wrote: >> >>> Does anyone really believe that the use of targeted 0-day exploits to gain unauthorized access to information hasn't been at least considered if not used by spies working for other [than China] countries? >> >> I think only those not paying attention would be left with that impression. >> >> Spying has been done for years on every side of various issues. Build a more complex system, someone will eventually find the weak points. >> >> Personally I was amused at people adding cement to USB ports to mitigate against the "removable media threat". The issue I see is people forget that floppies posed the same threat back in the day. >> >> The reality is that the technology is complex and easily used in asymmetrical ways, either for DDoS or for other purposes. >> >> The game is the same, it's just that some people are paying attention this week. It will soon go back to being harmless background radiation for most of us soon. >> > > The "difference" this week is motive. > > In the 1980s-1990s, we had joy-hacking. > > In the 2000s, we had profit-motivated hacking by criminals. > > We now have (and have had for a few years) what appears to be nation-state hacking. The differences are in targets and resources available to the attacker. > And indeed, what do we even know of this incident _for_sure_ so far? The reports, depending on vendor, blame either PDF files via email as the original perpetrator, or lay most of the blame on an Internet Explorer 0day. Both are likely vectors which have been seen used before. Regardless of what really happened, which I hope we will know more on later, these things are clear: 1. Unlike GhostNet, which showed an interesting attack but jumped to conclusions without evidence that it was China behind them -- based on Ethos alone I'd like to think that when Google says China did it, they know. Although being a commercial company with their own agenda, I am saving final judgement. Did Google ever say it's China rather than from China? 2. The 0day disclosed here shows a higher level of sophistication, as well as m.o. which has been shown to be used by China in the past (consider 0days patched by Microsoft and reported by the Taiwanese government). 3. If this was China, which some recent talk seems to make ambiguous, but still likely; they would have more than just one weapon in their arsenal. The attack would not have been against all these corporations, but rather multiple attacks, and possibly multiple tools. 4. This incident has brought cyber security once again to the awareness of the public, in a way no other incident since Georgia has succeeded, and to political awareness in a way no incident since Estonia has done. As to "everyone does it", here is an example I wrote of the German experience (not my best writing, but good analysis): http://www.darkreading.com/blog/archives/2009/03/german_intellig.html Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From bill at herrin.us Fri Jan 15 10:14:46 2010 From: bill at herrin.us (William Herrin) Date: Fri, 15 Jan 2010 11:14:46 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B50927A.9030500@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> Message-ID: <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> On Fri, Jan 15, 2010 at 11:06 AM, Michelle Sullivan wrote: >> I'm now marking this request as 'answered' as I think there's nothing >> more for me to do. If you feel otherwise, please reply to this message >> to re-open your ticket. In particular, if you change your rDNS >> information. > > Each of the 4 tickets (the three by Ken) are all sitting in the state of > "Answered" ... so at no point has a human had chance to see the issue and > override the bot's decision. > Is it bad English? ?Is it not clear? No, it is not clear. > Can anyone else give better wording > that might result in less of an issue? "Please reply to this message to reopen your ticket and escalate your case to a live human being." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From math at sizone.org Fri Jan 15 10:17:20 2010 From: math at sizone.org (Ken Chase) Date: Fri, 15 Jan 2010 11:17:20 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B50927A.9030500@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> Message-ID: <20100115161718.GA13448@sizone.org> Fair enough, but it wasnt just me. I have the customer who submitted his own tickets as well, as well as NAC.net who has admins (an email admin, actually), who seems to know his way around RBLs and the current state/reputation/happenings in the spam/RBL/mail world. Customer has posted these tickets: 260573, 260695, 261026, 261204, 261325, 261377, 261624 and the last ticket I posted was from NAC's admin, who received and acted on replies too. That makes 3 semi-clued people who found your system somewhat confusing (+1 interested party @coplanar = 4). The ironic thing is that if you make it any clearer, spammers may also figure out how to clear their networks easily as well from your list. :/ So I can see the reason for not doing so to some extent. At any rate, thanks for the pointers, I think that many others on Nanog will also find this useful as I had many private replies indicating frustration. I will attempt to follow your instructions closely, get the block rescanned now that it matches your RFC-proposal requirements. /kc On Fri, Jan 15, 2010 at 05:06:18PM +0100, Michelle Sullivan's said: >Ken Chase wrote: >>Anyone got some pointers on how to get off SORBS' Dynamic IP lists? >> >>We've followed their RFC proposed static reverse DNS assignment naming and >>all >>elements of their FAQ. >> >>We are not spammers. The /24 in question isnt listed on any RBLs except >>SORBS DUL. >> >>We've submitted requests in various different formats, but get a robot >>reply >>and -ENOJOY. >> >>We've even had our upstream that is listed at the RIR as managing the >>supernet >>of our BGP announced prefixes submit requests to delist for the /24, but >>we are only ever replied to by a robot that lists 67.196.137.0/24 as >>dynamic except .163 (somehow manually excluded from their db, I think when >>they werent adrift in years past). Our upstream's techs are also at a loss >>now >>and suggested I seek arcane clue amongst the sages here. >> >>Pointers appreciated. >> >>/kc >> > >OK, following my last post I have been given 4 ticket numbers for the >same network. 3 appear to be from Ken using a different email address >(hence why we couldn't find a ticket from him.) > >Normally I would not post a public response, but this case is what seems >to be a reoccurring theme, so maybe it's time to post comment. > >Each of the tickets are similar in that they all refer to the same >space. All were rejected by the robot with the following text at the >end of the reply: > >>I'm now marking this request as 'answered' as I think there's nothing >>more for me to do. If you feel otherwise, please reply to this message >>to re-open your ticket. In particular, if you change your rDNS >>information. > > >Each of the 4 tickets (the three by Ken) are all sitting in the state of >"Answered" ... so at no point has a human had chance to see the issue >and override the bot's decision. > >The common a reoccurring issue is the response by the robot has given >the next logical step to progress any delisting request (as has been >stated here recently, in another thread).. and the requester has either >not read the response or chosen to ignore the response or reason which results in not responding to the ticket>... then the come >here complaining about not getting a response from SORBS. The reality >is they got a response from SORBS and did not act upon the response. >Sorry Ken, this is not having a go at you, but it is a very common theme >and deserves airing. Other issues are where the appropriate contact (as >listed in the whois record at the RIR) also ignore the same two >sentences, get rejected by the robot and choose to log a new ticket only >to get the same response over and over again. > >Is it bad English? Is it not clear? Can anyone else give better >wording that might result in less of an issue? The process is >relatively simple: > >For fast approval: > >Log ticket -> robot checks rDNS for all networks listed in ticket -> >robot confirms all space is static and submits the ticket to the >removals queue where it is manually checked by a human and processed. > >For manual approval: > >Log ticket -> robot checks rDNS for all networks listed in ticket -> >robot denies delisting request sending response -> OP changes something >and replies, just states they are the whois listed appropriate contact, >or gives some reason why the robot is wrong and reopens the ticket with >the reply -> SORBS volunteer reviews the available information from the >robot and the subsequent reply from the OP and manually submits to the >removals queue or rejects and gives a human response as to why (eg like >with Shaw, Road Runner, Verizon, etc listings) the information is >provided by the ISP and any delisting will be reversed within a week. > >No NANOG is not about SORBS and SORBS should not really be discussed >here, but telling people they would be better discussing it on Spam-L >will not help you at all as I cannot post there and consequently I have >since unsubscribed, as I have suggested to all my staff. Messaging me >directly about listings will not help your case, unless something has >gone wrong (and since Jan 09 I have only had one issue where something >went wrong in the SORBS systems, all other requests were without tickets >or twits that logged a ticket and sent me the ticket number before the >robot had replied because they thought they might get special attention.) > >The best thing anyone can do is read the automated responses (some are >from the system as the ticket is logged, some are from the robots) >completely, and act upon what they say as majority of the time this will >result in a fast delisting.. Christmas Eve 2009, DUHL delisting >requests were happening within an hour of requesting a delisting. My >moving internationally and 30 hours in the air have slowed that process, >but I intend to get it back to within 60 minute responses again by the >end of January. > >Michelle -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From ge at linuxbox.org Fri Jan 15 10:24:55 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 15 Jan 2010 18:24:55 +0200 Subject: Anyone see a game changer here? In-Reply-To: <81D582C724CA1046A279A7EE1299638B01C7FE9F@FHDP1LUMXCV24.us.one.verizon.com> References: <81D582C724CA1046A279A7EE1299638B01C7FE9F@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <4B5096D7.5060305@linuxbox.org> On 1/15/10 5:23 PM, Sachs, Marcus Hans (Marc) wrote: > The botnet concept is one of the old rules. The way the APT works and > what it is used for is the new game. Perhaps for talking about, but it is far from new. Come on Marc. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From bill at edisys.co.uk Fri Jan 15 10:26:54 2010 From: bill at edisys.co.uk (William Hamilton) Date: Fri, 15 Jan 2010 16:26:54 +0000 Subject: SORBS on autopilot? In-Reply-To: <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> Message-ID: <4B50974E.3080308@edisys.co.uk> On 15/01/2010 16:14, William Herrin wrote: >> Is it bad English? Is it not clear? > > No, it is not clear. It's perfectly clear. >> Can anyone else give better wording >> that might result in less of an issue? > > "Please reply to this message to reopen your ticket and escalate your > case to a live human being." You: "Please reply to this message to reopen your ticket and escalate your case to a live human being." And now SORBS: "If you feel otherwise, please reply to this message to re-open your ticket." Try as I might I really can't see what is not clear here... B From bicknell at ufp.org Fri Jan 15 10:32:35 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Jan 2010 08:32:35 -0800 Subject: SORBS on autopilot? In-Reply-To: <4B50927A.9030500@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> Message-ID: <20100115163235.GA95587@ussenterprise.ufp.org> In a message written on Fri, Jan 15, 2010 at 05:06:18PM +0100, Michelle Sullivan wrote: > The common a reoccurring issue is the response by the robot has given > the next logical step to progress any delisting request (as has been > stated here recently, in another thread).. and the requester has either > not read the response or chosen to ignore the response or reason which results in not responding to the ticket>... then the come > here complaining about not getting a response from SORBS. The reality > is they got a response from SORBS and did not act upon the response. > Sorry Ken, this is not having a go at you, but it is a very common theme > and deserves airing. Other issues are where the appropriate contact (as > listed in the whois record at the RIR) also ignore the same two > sentences, get rejected by the robot and choose to log a new ticket only > to get the same response over and over again. So, let me see if I got this right: 1) Network reports 1.2.3.0/24 has no dynamic IP addresses in it. 2) SORBS robot reponds with "you must change your rDNS." 3) Profit? What your telling me is the SORBS list of "dynamic IP's" is in fact not a list of dynamic IP's. Rather it is the "SORBS list of things that have DNS names that look like dynamic IP's". Rather than take on the burden of making the list reflect what you say it does (dynamic IP's) by for instance taking the report and putting it in some sort of exception list (possibly with some investigation) you're putting all the burden back on the network operator. Given that it only operates on DNS names, one has to wonder if there is any value to the list. I can easily put a list of prohibited dns forms in my local blackist (e.g. dhcp-.*) and then I don't have to query the DNSbl, reducing network traffic and latency. It would appear to me SORBS is providing no value (in the specific cause of the dynamic IP list) if this is the case. The entire point of "outsourcing" the list to SORBS would be to get something better than just a regex on DNS names, but that appears to be all that is being provided. -- 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: 826 bytes Desc: not available URL: From sghuter at nsrc.org Fri Jan 15 10:34:55 2010 From: sghuter at nsrc.org (Steven G. Huter) Date: Fri, 15 Jan 2010 16:34:55 +0000 (GMT) Subject: Katrina response, private and public In-Reply-To: <4B508C67.5000309@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> Message-ID: <20100115162903.S39848@psg.com> > After the Katrina landfall a diverse group of wireless people started > organizing a relief effort, culminating in work around Waveland. There was > also a group from the NPGS in Monterey, who worked on the Boxing Day Tsunami > aftermath. > > Does anyone have a similar contact set? hello eric i rec'd email yesterday from a colleague at inveneo.org that they and nethope.org are putting together a team to travel to haiti and work on an emergency comms wireless network for the numerous NGOs/relief workers so they can communicate more efficiently. they were part of the katrina relief effort team. contact Kristin Peterson for more info on how to help. steve From bill at herrin.us Fri Jan 15 10:36:25 2010 From: bill at herrin.us (William Herrin) Date: Fri, 15 Jan 2010 11:36:25 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B50974E.3080308@edisys.co.uk> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> <4B50974E.3080308@edisys.co.uk> Message-ID: <3c3e3fca1001150836n7cd129a8k3652fbdb90848fef@mail.gmail.com> On Fri, Jan 15, 2010 at 11:26 AM, William Hamilton wrote: >>> Is it bad English? ?Is it not clear? >> No, it is not clear. > > Try as I might I really can't see what is not clear here... It isn't clear that there's a way to reach a human being at sorbs other than complaining acerbically on a newsgroup or mailing list. Question asked. Question answered. I don't care to debate the matter, so make of it what you wish. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From paul at hessels.ca Fri Jan 15 10:40:07 2010 From: paul at hessels.ca (paul) Date: Fri, 15 Jan 2010 11:40:07 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <20100115161718.GA13448@sizone.org> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115161718.GA13448@sizone.org> Message-ID: Michelle, Thanks for your email. Please specifically look at ticket 260695. I created the ticket on January 5th at about 1:30EST. Immediately I got my response from the robot. I replied a few minutes later with: > 67.196.137.188/32 > > TTL is right. PTR is right. >From your email, it is my understanding this should have went to a human. I have no idea why my IP address wasn't accepted in the first place. And I have no idea why I didn't get a human response. A couple suggestions: -program the robot to give the exact reason why it is denying: TTL wrong or PTR indicates dynamic or whatever -kind of leaping to conclusions here, but possibly the robot is caching DNS? Which means even if what was broken had been fixed, the robot wouldn't see it? Thanks, -- Paul Hessels From matthew at sorbs.net Fri Jan 15 10:49:09 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 17:49:09 +0100 Subject: SORBS on autopilot? In-Reply-To: <20100115161718.GA13448@sizone.org> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115161718.GA13448@sizone.org> Message-ID: <4B509C85.4060700@sorbs.net> Ken Chase wrote: > Fair enough, but it wasnt just me. > > I have the customer who submitted his own tickets as well, as well as NAC.net > who has admins (an email admin, actually), who seems to know his way around RBLs > and the current state/reputation/happenings in the spam/RBL/mail world. > > Customer has posted these tickets: > > 260573, 260695, 261026, 261204, 261325, 261377, 261624 > 260573 - waiting for a response from a SORBS admin (originally requested the /22, but really only meant to request a /32) 260695 - is 260573 261026 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261204 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261325 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261377 - had no information about any ticket and was logged to the lowest priority queue, and is actually the same as the above from the same requestor. 261624 - waiting for response from the requestor (and 260573, 260695, 261026, 261204, 261325, 261377 are all merged into it as then are all for the same host.) > and the last ticket I posted was from NAC's admin, who received and acted on replies > too. > The NAC admin had not replied to the ticket as I stated previously. > That makes 3 semi-clued people who found your system somewhat confusing (+1 > interested party @coplanar = 4). The ironic thing is that if you make it > any clearer, spammers may also figure out how to clear their networks easily > as well from your list. :/ So I can see the reason for not doing so to some > extent. > Well 3 people have ignored the last 2 sentences... so please tell me what is unclear in them? The only correct response was in 260573 when someone responded to the robot response. For the onlookers, please note that the SORBS stated reply time has been complied with in all cases, and had the other tickets not been logged for the same issue by the same requestor it would have been answered by today to stay in that response time compliance. Michelle From LarrySheldon at cox.net Fri Jan 15 10:50:49 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 15 Jan 2010 10:50:49 -0600 Subject: SORBS on autopilot? In-Reply-To: <4B50974E.3080308@edisys.co.uk> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> <4B50974E.3080308@edisys.co.uk> Message-ID: <4B509CE9.9040801@cox.net> On 1/15/2010 10:26 AM, William Hamilton wrote: > On 15/01/2010 16:14, William Herrin wrote: >>> Is it bad English? Is it not clear? >> No, it is not clear. > > It's perfectly clear. > >>> Can anyone else give better wording >>> that might result in less of an issue? >> >> "Please reply to this message to reopen your ticket and escalate your >> case to a live human being." > > You: > > "Please reply to this message to reopen your ticket and escalate your > case to a live human being." > > And now SORBS: > > "If you feel otherwise, please reply to this message > to re-open your ticket." > > Try as I might I really can't see what is not clear here... Standard English vs. British English vs. Northeast U.S. English, vs. Geek vs. ...? Second seems more logical to me (allowing for a moment that some thing about this whole subject is "logical". -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From woody at pch.net Fri Jan 15 10:52:57 2010 From: woody at pch.net (Bill Woodcock) Date: Fri, 15 Jan 2010 08:52:57 -0800 (PST) Subject: Katrina response, private and public In-Reply-To: <4B508C67.5000309@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> Message-ID: On Fri, 15 Jan 2010, Eric Brunner-Williams wrote: > After the Katrina landfall a diverse group of wireless people started > organizing a relief effort... There are quite a lot of us working on it, is there something specific you're volunteering to do? -Bill From bortzmeyer at nic.fr Fri Jan 15 10:49:00 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 15 Jan 2010 17:49:00 +0100 Subject: News about the .HT domain Message-ID: <20100115164900.GA30469@sources.org> I have no information about the state of the Internet links in Haiti (everything seems down) but, for the .HT top-level domain, here are a few news. .HT has six name servers, four outside of the country. They were not affected so .HT never had a problem resolving. Main DNS lesson: always put name servers in very diverse places. The master was in Port-au-Prince and is unreachable, probably for a long time. A new (stealth) master has been set up in Australia by Cocca and the slaves are now reconfigured to use it. Two already do it and therefore the zone no longer risks expiration (and can even be modified). You may find information at . % check_soa ht There was no response from ns2.nic.ht There was no response from ns1.nic.ht dns.princeton.edu has serial number 2010011198 charles.cdec.polymtl.ca has serial number 2010011198 ht-ns.anycast.pch.net has serial number 2010011615 ns3.nic.fr has serial number 2010011615 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mike at mtcc.com Fri Jan 15 10:57:28 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 15 Jan 2010 08:57:28 -0800 Subject: Bad Support Bots (was: SORBS on autopilot?) In-Reply-To: <4B50974E.3080308@edisys.co.uk> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> <4B50974E.3080308@edisys.co.uk> Message-ID: <4B509E78.6050307@mtcc.com> William Hamilton wrote: > "Please reply to this message to reopen your ticket and escalate your > case to a live human being." > > And now SORBS: > > "If you feel otherwise, please reply to this message > to re-open your ticket." > > Try as I might I really can't see what is not clear here... The difference is that nobody wants to "talk" to a robot when they're the victim of a false positive which is causing business impacting interruption. A robot is not empowered to go beyond its instructions, and if it's programmed either wrong or with inadequate nuance, there is no escalation. Let's not forget that IVR mazes and their modern day counterparts have been built in large part not to resolve problems but to reduce the cost of "support" by expensive human automatons to the point that it's often incidental if they actually solve problems. This is not a well kept secret, and when you're trapped by one especially when it's produced a crisis, its rather disingenuous and maddening for the IVR's keeper to cop attitude. A much better approach -- assuming that the goal is actually to resolve problems rather than shield resources -- is to at least make the escalation process transparent. Knowing what you have to do in order to get ahold of some of something empowered to resolve problems is a lot better than a robot telling you to take the next turn in a twisty maze. Mike, this is hardly SORBS specific lest anybody be confused From matthew at sorbs.net Fri Jan 15 11:01:43 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 18:01:43 +0100 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115161718.GA13448@sizone.org> Message-ID: <4B509F77.1020007@sorbs.net> paul wrote: > Michelle, > > Thanks for your email. Please specifically look at ticket 260695. I > created the ticket on January 5th at about 1:30EST. Immediately I got > my response from the robot. See my other message in addition. > > I replied a few minutes later with: > >> 67.196.137.188/32 >> >> TTL is right. PTR is right. > That is my view, however most (if not all) of the tickets were for the /22 not the /32 which is why it was rejected. > From your email, it is my understanding this should have went to a > human. I have no idea why my IP address wasn't accepted in the first > place. And I have no idea why I didn't get a human response. So go back to the robot response and tell me where it says it'll be sent to a human...please...? > > A couple suggestions: > -program the robot to give the exact reason why it is denying: TTL > wrong or PTR indicates dynamic or whatever It does give several responses, however the more exact the response the more issues we have had with people not understanding the reply. Our response has been to format the message with a link to the FAQ where there is a lot more of a detailed response. I will review the response with your suggestions and see if we can change it to some sort of compromise. > -kind of leaping to conclusions here, but possibly the robot is > caching DNS? Which means even if what was broken had been fixed, the > robot wouldn't see it? The robot caches results for 48 hours to prevent people launching DoS attacks on our systems as well as yours. The results are easily checked here: http://nemesis.sorbs.net:82///.txt eg: http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt In this case you can easily see why the robot was unable to process the request... PTR's were requested from the nominated authoritive servers, only to receive a "NODATA" response (commonly seen if TCP responses are required or CNAMEs are returned without the PTR.) There is an issue with the robot and some correctly assigned classless delegations due to the way we process the data, there are various catches to correct this and re-process the network with a more reliable (but considerably more resource hungry) method. Unfortunately it's not fool proof though, which is why we tell people to respond to the robot response to get a human to review it. If anyone out there is knowledgable in Perl, C and DNS and wants to take a shot at fixing that issue I'd love to have the help. Michelle From bill at edisys.co.uk Fri Jan 15 11:01:54 2010 From: bill at edisys.co.uk (William Hamilton) Date: Fri, 15 Jan 2010 17:01:54 +0000 Subject: Bad Support Bots In-Reply-To: <4B509E78.6050307@mtcc.com> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> <4B50974E.3080308@edisys.co.uk> <4B509E78.6050307@mtcc.com> Message-ID: <4B509F82.7040205@edisys.co.uk> On 15/01/2010 16:57, Michael Thomas wrote: > The difference is that nobody wants to "talk" to a robot when they're > the victim > of a false positive which is causing business impacting interruption. A > robot is not > empowered to go beyond its instructions, and if it's programmed either > wrong or with > inadequate nuance, there is no escalation. Sure, and that's understandable. > Let's not forget that IVR mazes and their modern day counterparts have > been built in > large part not to resolve problems but to reduce the cost of "support" > by expensive human > automatons to the point that it's often incidental if they actually > solve problems. This is not > a well kept secret, and when you're trapped by one especially when it's > produced a crisis, > its rather disingenuous and maddening for the IVR's keeper to cop attitude. > > A much better approach -- assuming that the goal is actually to resolve > problems rather than > shield resources -- is to at least make the escalation process > transparent. Knowing what you > have to do in order to get ahold of some of something empowered to > resolve problems is a > lot better than a robot telling you to take the next turn in a twisty maze. I agree it's perhaps not clear how to get hold of a human, but you can't really argue that it's not clear how to progress the issue in general as the message quite clearly tells you to respond if you wish for it to be re-opened. I can't accept that the instructions that the bot provided were unclear, but can organisations in general (again, not SORBS-specific) do better when dealing with their "customers"? Absolutely. B From matthew at sorbs.net Fri Jan 15 11:08:37 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 18:08:37 +0100 Subject: SORBS on autopilot? In-Reply-To: <20100115163235.GA95587@ussenterprise.ufp.org> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115163235.GA95587@ussenterprise.ufp.org> Message-ID: <4B50A115.5040104@sorbs.net> Leo Bicknell wrote: > So, let me see if I got this right: > > 1) Network reports 1.2.3.0/24 has no dynamic IP addresses in it. > Networks don't report anything, people do, and in the majority of cases not the network owner (where network owner = person listed in the RIR as the POC) > 2) SORBS robot reponds with "you must change your rDNS." > ... or respond to indicate why you think the robot is wrong... > 3) Profit? > What profit? > What your telling me is the SORBS list of "dynamic IP's" is in fact > not a list of dynamic IP's. Rather it is the "SORBS list of things > that have DNS names that look like dynamic IP's". > No, it's much more. Delisting requests are processed in the initial instance by a robot to save wasting valuable human time as we have received several 1000 messages a day from dynamic users demanding delisting. The robot leaves us with 50-100 messages a day to process manually (for the DUHL only.) Michelle From paul at hessels.ca Fri Jan 15 11:26:12 2010 From: paul at hessels.ca (paul) Date: Fri, 15 Jan 2010 12:26:12 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <4B509F77.1020007@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115161718.GA13448@sizone.org> <4B509F77.1020007@sorbs.net> Message-ID: Michelle, -- Paul In the beginner's mind there are many possibilities, but in the expert's mind there are few. Shunryu Suzuki On Fri, 15 Jan 2010, Michelle Sullivan wrote: > That is my view, however most (if not all) of the tickets were for the /22 > not the /32 which is why it was rejected. On all of my tickets but one the robot said: "I've analyzed the following IP space, based on the text of your request: 67.196.137.188/32" > >> From your email, it is my understanding this should have went to a human. I > > So go back to the robot response and tell me where it says it'll be sent to a > human...please...? Until you told me it was going to a human, I didn't know. In fact, I only replied to the robot out of frustration; who would reply to a robot expecting a different answer the second time? Its been 10 days without a response, maybe my ticket got caught up some where? >> -kind of leaping to conclusions here, but possibly the robot is caching >> DNS? Which means even if what was broken had been fixed, the robot >> wouldn't see it? > > The robot caches results for 48 hours to prevent people launching DoS attacks > on our systems as well as yours. The results are easily checked here: > Perhaps require them to login. > http://nemesis.sorbs.net:82///.txt > > eg: > > http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt > Access to this would have helped a lot. Atleast I would have had some place to start. I see the last scan was on Jan 12th. I see an error I can't really account for. > In this case you can easily see why the robot was unable to process the > request... PTR's were requested from the nominated authoritive servers, only > to receive a "NODATA" response (commonly seen if TCP responses are required > or CNAMEs are returned without the PTR.) > > There is an issue with the robot and some correctly assigned classless > delegations due to the way we process the data, there are various catches to > correct this and re-process the network with a more reliable (but > considerably more resource hungry) method. Unfortunately it's not fool proof > though, which is why we tell people to respond to the robot response to get a > human to review it. If anyone out there is knowledgable in Perl, C and DNS > and wants to take a shot at fixing that issue I'd love to have the help. I seem to have gotten caught in a corner case then? Because as far as I can see everything is setup correctly on my end. Your help would be appreciated. > > Michelle > From cb.list6 at gmail.com Fri Jan 15 11:26:33 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 15 Jan 2010 09:26:33 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: Message-ID: On Fri, Jan 15, 2010 at 5:37 AM, Durand, Alain wrote: > [resending with more readable, apologies for the duplicate] > > DS-lite can work both for fixed and wireless scenario, where you have a > laptop/pda/smarphone/tablet > that is only configured by the access network with IPv6 but want to access > IPv4 content FROM IPv4 > applications. This is the main difference between DS-lite and NAT64. NAT64 Agreed, DS-lite can be deployed in many environments. But, a 3GPP style mobile operators would have to be working under some very specific circumstances to choose DS-lite given that dual-stack features (IPv6 PDP before release 7 and dual-stack EPS bearer after release 8) have long been part of the standards and ecosystem without the need for DS-lite. But, honestly, i am trying to focus this thread on viable services that can be launched and supported today or the very near future with IPv6-only, not a religious war about technology selection. > requires all applications > on the user device to be IPv6 compatible. Now, that may or may not be an > issue. If you are talking > about a proprietary wireless device that run only proprietary apps, porting > all those apps to IPv6 > prior to launching the service may be ok... However, if the device can run > external apps, like those > coming from an app store, or running pre-existing apps (I?m thinking about > the gazillions apps > existing on the iPhone), then a NAT64 solution will force a complete rewrite > of every single one > of those apps... The purpose of me posting the video was to show that a casual internet user (majority of my customers) can have a normal user experience with an IPv6-only transport on today's network with today's software. No special configuration required or special software to install. Every part of the environment i demonstrated is stock off-the shelf that anyone can deploy today. I work in a mobile operator, i know the traffic profiles, and I won't be scared by FUD about billions of apps that power-users may be using. I am not saying you are pushing FUD, but i bet you are familiar with some folks that do push FUD citing indefinite support for IPv4 apps on cell phones. Nonetheless, I will have a service plan to meet their needs for native dual-stack. Smart-phones generally have a life span of less than 2-3 years, and i am not focused on legacy support. IPv4 is not going away soon, i want to talk about new products and services. My question to the community is regarding the viability of specific service for casual Internet user to have web and email via an IPv6-only network. Web and email is the vast majority of my traffic, and maybe yours too. Beyond web and email (supported by NAT64), with an IPv6-only native service i can offer the customer true end-to-end IPv6 which may spur a watershed of innovation in the application and content space that is currently hobbled by NAT and will be further hobbled by CGN (including NAT64). I say this because as a network operator with CGN already in place, the more traffic i can shift to innovative end-to-end IPv6 flows the more money i save in CGN costs. > > DS-lite would enable all those apps to keep working. Big difference. > If a user needs dual stack in a 3GPP network, i have the technology to do that today within today's 3GPP specs. Software is deployed, I just need market demand (or more likely supply side push from IPv6). I don't need yet another tunnel or piece of host software, it works today. Also, a big difference. But, that's just my scenario. DS-lite will work great and make sense in many environments. - Cameron > ??- Alain. From mike at mtcc.com Fri Jan 15 12:14:54 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 15 Jan 2010 10:14:54 -0800 Subject: Bad Support Bots In-Reply-To: <4B509F82.7040205@edisys.co.uk> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> <4B50974E.3080308@edisys.co.uk> <4B509E78.6050307@mtcc.com> <4B509F82.7040205@edisys.co.uk> Message-ID: <4B50B09E.9020505@mtcc.com> William Hamilton wrote: > On 15/01/2010 16:57, Michael Thomas wrote: > >> The difference is that nobody wants to "talk" to a robot when they're >> the victim >> of a false positive which is causing business impacting interruption. A >> robot is not >> empowered to go beyond its instructions, and if it's programmed either >> wrong or with >> inadequate nuance, there is no escalation. > > Sure, and that's understandable. > >> Let's not forget that IVR mazes and their modern day counterparts have >> been built in >> large part not to resolve problems but to reduce the cost of "support" >> by expensive human >> automatons to the point that it's often incidental if they actually >> solve problems. This is not >> a well kept secret, and when you're trapped by one especially when it's >> produced a crisis, >> its rather disingenuous and maddening for the IVR's keeper to cop >> attitude. >> >> A much better approach -- assuming that the goal is actually to resolve >> problems rather than >> shield resources -- is to at least make the escalation process >> transparent. Knowing what you >> have to do in order to get ahold of some of something empowered to >> resolve problems is a >> lot better than a robot telling you to take the next turn in a twisty >> maze. > > I agree it's perhaps not clear how to get hold of a human, but you > can't really argue that it's not clear how to progress the issue in > general as the message quite clearly tells you to respond if you wish > for it to be re-opened. > > I can't accept that the instructions that the bot provided were > unclear, but can organisations in general (again, not SORBS-specific) > do better when dealing with their "customers"? Here's the general problem I have. As "customers", we've gone from the expectation that support was there to support us, to the general presumption that the "customers" are the problem and need to take Turing Tests, and jump through all manner of hoops in order to be deigned worthy of help. That's great if your base motivation is to reduce the bottom line of support costs, but lets not equivocate that the experience isn't on average far, far worse for those on the receiving end of these systems. In this particular case, it isn't whether the instructions aren't clear per se. It's that there isn't any recourse if for whatever reason they are not. Badgering the "customers" who don't understand your process is either cynical or clueless. If your customers don't understand, that's your problem. Always. Assuming that support is there to support, of course. So in general, it's this new age attitude of "you must conform to my cost targets" toward support that sucks. Mike From jed at jedsmith.org Fri Jan 15 12:26:49 2010 From: jed at jedsmith.org (Jed Smith) Date: Fri, 15 Jan 2010 13:26:49 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B50A115.5040104@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115163235.GA95587@ussenterprise.ufp.org> <4B50A115.5040104@sorbs.net> Message-ID: <4CF2B345-18A6-4193-AA42-EEBF56E3BAF8@jedsmith.org> This will be my only reply to the conversation now that Michelle has poked in and taken control of the thread. I had a beef with SORBS a while back on behalf of my day job, and it cost me quite a bit -- in frustration, in doing a few things publicly that I regret, and ultimately in spending a month of my life fighting with Michelle over a God damned /24 and its erroneous listing. That confrontation haunts me today, and not necessarily because either of us screwed up at any level. We both did, but I'm haunted today because of the bad blood that the confrontation produced. I am not going to revisit that experience, but it did grant something to share. I can only hope that differences aside, Michelle respects my wishes and does not turn NANOG into his/her and my personal fighting ground -- what's in the past is done, and I'm only sharing what I learned from it, not the events that transpired over said /24. I walked away from that experience having learned a number of things. Firstly, I damaged my reputation at my employer as a direct result of getting sucked in to the emotional vortex that dealing with Michelle caused -- something in the callous, biting, confrontational demeanor with which Michelle composes herself brings out the worst in me and summons forth tribal battle rage. The fact that the medium is a keyboard and not a face-to-face conversation does not help. Secondly, I learned about myself and my weaknesses, particularly in dealing with the public. If there's anything a competent network administrator needs to master, it's dismissing a sense of entitlement. SORBS is going to do whatever the hell it wants, and Michelle may or may not work with you on getting SORBS to stop doing what's bugging you. The biggest mistake I made was turning that into a crusade to prove her wrong; I am reminded about the (ever inappropriate) Special Olympics analogy relating to Internet arguing which is strangely appropriate when dealing with Michelle. (As an aside, this second point has drastically altered my dealings with service providers. I yell a /lot/ less when my home Internet connection goes out now, and I'm all that much better for it. I'm really pleased I learned to let go.) Thirdly, and possibly most importantly, I learned a valuable life lesson about dealing with people like Michelle and how much it isn't worth it. SORBS has a particularly vile reputation, and given Michelle's treatment of folks in this thread it is no mystery why. Aside from Ricky's solitary post of January 14th, this thread had mostly moved on from SORBS and addressed other topics -- granted, it was frightfully meta and a candidate for leaving well enough alone. Spam-L moderated Michelle for the exact same fault she is demonstrating here -- even on a mailing list comprised of the who's-who of Internet network administration, she will drag everybody subscribed through torment and misery while attempting to defend supposed SORBS reputation in an ongoing crusade to prove herself right. In Spam-L's case, it was with me; in NANOG's case, it's with a number of people who have spoken negatively re: SORBS. I am not dismissing blame from those fanning the conversation, but merely giving credit where credit is due. Let me reiterate for the benefit of Ricky Beam, Ken Chase, Leo Bicknell, Paul, and anybody else who is tempted to debate Michelle in this thread: you are 100% wasting your time. Your time is much better spent contacting every mail administrator on the Internet who 5xx's your relay's mail, or asking your upstream to move you out of the affected block. Both will result in more productivity than debating anybody that works for SORBS or who is a colleague of Michelle Sullivan. You might be right, she might be right, and in either case it doesn't matter. Move on. There are far more pressing matters in life. Now then, that said... I'm going to humbly request as a subscriber to NANOG that "my ticket wasn't handled to my satisfaction" mails, even in spite of the above advice, remove nanog at nanog.org from the distribution list and become a private matter. If Michelle genuinely cares about cleaning up SORBS and raising its reputation, she will not have a problem with this. If moving to a private conversation is problematic for all involved parties, I hope it moves to another list. JS From jlewis at lewis.org Fri Jan 15 12:29:25 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 15 Jan 2010 13:29:25 -0500 (EST) Subject: SORBS on autopilot? In-Reply-To: <4B509C85.4060700@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115161718.GA13448@sizone.org> <4B509C85.4060700@sorbs.net> Message-ID: On Fri, 15 Jan 2010, Michelle Sullivan wrote: > Well 3 people have ignored the last 2 sentences... so please tell me what is > unclear in them? The only correct response was in 260573 when someone The robot response, like much of the SORBS web site is rather longwinded, and I suspect many people, by the time they process Not all the IP space you requested can be delisted at this time. Please review carefully our FAQ, located at the following URI are so fuming mad that they either don't read all the way down to the final paragraph or aren't thinking clearly by the time they get there. I know from personal experience, that my reaction was to get to this point, read/re-read the above mentioned FAQ, make changes to the in-addr.arpa, and resubmit the request. This was clearly the wrong way to proceed, but even if you read as far as: I'm now marking this request as 'answered' as I think there's nothing more for me to do. If you feel otherwise, please reply to this message to re-open your ticket. In particular, if you change your rDNS information. This really doesn't make it clear that a reply to this response will reopen the ticket in a human processed queue...so "what's the difference between massaging my rDNS and resubmitting vs massaging my rDNS and replying?" The assumption might well be "no difference" so we keep tweaking the rDNS and banging our heads against R2D2. Now, if that final paragraph was replaced with I'm now marking this request as 'answered' as I think there's nothing more for me to do. If you feel otherwise, please reply to this message. Your reply will re-open this ticket in a queue handled by our human support staff. If you make changes to your rDNS and submit a new request, that request will open a new ticket which will be handled by this robot. Since SORBS caches all rDNS for [some TTL] which may be longer than your TTL, we may not even recognize that your rDNS has changed. some of the SORBS DUL hate mail might be avoided. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cscora at apnic.net Fri Jan 15 12:41:28 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Jan 2010 04:41:28 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201001151841.o0FIfSVB025877@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 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 309127 Prefixes after maximum aggregation: 143543 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 151934 Total ASes present in the Internet Routing Table: 33091 Prefixes per ASN: 9.34 Origin-only ASes present in the Internet Routing Table: 28731 Origin ASes announcing only one prefix: 14027 Transit ASes present in the Internet Routing Table: 4360 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 9503) 21 Prefixes from unregistered ASNs in the Routing Table: 765 Unregistered ASNs in the Routing Table: 136 Number of 32-bit ASNs allocated by the RIRs: 393 Prefixes from 32-bit ASNs in the Routing Table: 345 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 185 Number of addresses announced to Internet: 2176160448 Equivalent to 129 /8s, 181 /16s and 146 /24s Percentage of available address space announced: 58.7 Percentage of allocated address space announced: 66.5 Percentage of available address space allocated: 88.2 Percentage of address space in use by end-sites: 80.8 Total number of prefixes smaller than registry allocations: 149064 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 74756 Total APNIC prefixes after maximum aggregation: 25793 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 71440 Unique aggregates announced from the APNIC address blocks: 31551 APNIC Region origin ASes present in the Internet Routing Table: 3907 APNIC Prefixes per ASN: 18.29 APNIC Region origin ASes announcing only one prefix: 1065 APNIC Region transit ASes present in the Internet Routing Table: 614 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 488804384 Equivalent to 29 /8s, 34 /16s and 144 /24s Percentage of available APNIC address space announced: 80.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/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, 133/8, 175/8, 180/8, 182/8, 183/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: 129389 Total ARIN prefixes after maximum aggregation: 67564 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 103522 Unique aggregates announced from the ARIN address blocks: 39181 ARIN Region origin ASes present in the Internet Routing Table: 13450 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5209 ARIN Region transit ASes present in the Internet Routing Table: 1334 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 735534112 Equivalent to 43 /8s, 215 /16s and 92 /24s Percentage of available ARIN address space announced: 64.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 71034 Total RIPE prefixes after maximum aggregation: 41545 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 64168 Unique aggregates announced from the RIPE address blocks: 42760 RIPE Region origin ASes present in the Internet Routing Table: 13981 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7265 RIPE Region transit ASes present in the Internet Routing Table: 2100 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 413123840 Equivalent to 24 /8s, 159 /16s and 197 /24s Percentage of available RIPE address space announced: 77.0 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27130 Total LACNIC prefixes after maximum aggregation: 6521 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 25496 Unique aggregates announced from the LACNIC address blocks: 13826 LACNIC Region origin ASes present in the Internet Routing Table: 1230 LACNIC Prefixes per ASN: 20.73 LACNIC Region origin ASes announcing only one prefix: 393 LACNIC Region transit ASes present in the Internet Routing Table: 203 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 69936128 Equivalent to 4 /8s, 43 /16s and 36 /24s Percentage of available LACNIC address space announced: 69.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 6243 Total AfriNIC prefixes after maximum aggregation: 1767 AfriNIC Deaggregation factor: 3.53 Prefixes being announced from the AfriNIC address blocks: 4645 Unique aggregates announced from the AfriNIC address blocks: 1589 AfriNIC Region origin ASes present in the Internet Routing Table: 338 AfriNIC Prefixes per ASN: 13.74 AfriNIC Region origin ASes announcing only one prefix: 95 AfriNIC Region transit ASes present in the Internet Routing Table: 69 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14818048 Equivalent to 0 /8s, 226 /16s and 27 /24s Percentage of available AfriNIC address space announced: 44.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1857 7511 473 Korea Telecom (KIX) 17488 1464 144 140 Hathway IP Over Cable Interne 4755 1310 303 136 TATA Communications formerly 18101 1036 220 38 Reliance Infocom Ltd Internet 4134 1019 19477 400 CHINANET-BACKBONE 9583 999 75 504 Sify Limited 7545 926 198 100 TPG Internet Pty Ltd 17974 853 272 54 PT TELEKOMUNIKASI INDONESIA 9829 839 683 24 BSNL National Internet Backbo 4808 837 1583 213 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 4165 3891 302 bellsouth.net, inc. 4323 3785 1088 397 Time Warner Telecom 1785 1794 699 133 PaeTec Communications, Inc. 7018 1593 5791 1031 AT&T WorldNet Services 20115 1544 1490 671 Charter Communications 2386 1282 615 921 AT&T Data Communications Serv 3356 1200 10929 423 Level 3 Communications, LLC 11492 1128 222 14 Cable One 22773 1124 2600 66 Cox Communications, Inc. 6478 1103 241 273 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 35805 470 40 5 United Telecom of Georgia 3292 450 1903 394 TDC Tele Danmark 30890 436 98 205 Evolva Telecom 702 421 1821 335 UUNET - Commercial IP service 8551 397 353 37 Bezeq International 8866 376 110 24 Bulgarian Telecommunication C 3320 363 7068 308 Deutsche Telekom AG 3301 355 1412 308 TeliaNet Sweden 3215 351 3176 108 France Telecom Transpac 12479 318 578 6 Uni2 Autonomous System 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 1582 2899 233 UniNet S.A. de C.V. 10620 1003 224 131 TVCABLE BOGOTA 28573 840 674 85 NET Servicos de Comunicao S.A 7303 670 355 100 Telecom Argentina Stet-France 22047 547 302 14 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 6503 445 163 184 AVANTEL, S.A. 11172 444 99 69 Servicios Alestra S.A de C.V 14117 437 29 12 Telefonica del Sur S.A. 7738 431 858 29 Telecomunicacoes da Bahia 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 8452 1018 444 8 TEDATA 24863 722 143 53 LINKdotNET AS number 36992 317 81 161 Etisalat MISR 3741 273 857 233 The Internet Solution 2018 190 197 111 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 161 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 122 7 11 Starcomms Nigeria Limited 5536 117 7 17 Internet Egypt Network 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 4165 3891 302 bellsouth.net, inc. 4323 3785 1088 397 Time Warner Telecom 4766 1857 7511 473 Korea Telecom (KIX) 1785 1794 699 133 PaeTec Communications, Inc. 7018 1593 5791 1031 AT&T WorldNet Services 8151 1582 2899 233 UniNet S.A. de C.V. 20115 1544 1490 671 Charter Communications 17488 1464 144 140 Hathway IP Over Cable Interne 4755 1310 303 136 TATA Communications formerly 2386 1282 615 921 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3785 3388 Time Warner Telecom 1785 1794 1661 PaeTec Communications, Inc. 4766 1857 1384 Korea Telecom (KIX) 8151 1582 1349 UniNet S.A. de C.V. 17488 1464 1324 Hathway IP Over Cable Interne 4755 1310 1174 TATA Communications formerly 11492 1128 1114 Cable One 22773 1124 1058 Cox Communications, Inc. 18566 1059 1049 Covad Communications 8452 1018 1010 TEDATA 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 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 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:21 /9:10 /10:25 /11:66 /12:183 /13:383 /14:656 /15:1242 /16:10877 /17:5080 /18:8662 /19:17764 /20:21725 /21:21659 /22:27993 /23:28180 /24:161693 /25:923 /26:1154 /27:588 /28:219 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2723 4165 bellsouth.net, inc. 4323 2363 3785 Time Warner Telecom 4766 1474 1857 Korea Telecom (KIX) 1785 1263 1794 PaeTec Communications, Inc. 17488 1230 1464 Hathway IP Over Cable Interne 11492 1048 1128 Cable One 18566 1040 1059 Covad Communications 7018 960 1593 AT&T WorldNet Services 18101 916 1036 Reliance Infocom Ltd Internet 8452 914 1018 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:232 12:2016 13:10 15:22 16:3 17:8 20:39 24:1298 32:49 38:640 40:99 41:1910 44:3 46:1 47:30 52:6 55:2 56:2 57:23 58:631 59:644 60:445 61:1096 62:977 63:2004 64:3790 65:2355 66:4098 67:1829 68:1048 69:2839 70:689 71:228 72:1859 73:3 74:2079 75:220 76:354 77:870 78:574 79:409 80:963 81:784 82:471 83:438 84:555 85:1020 86:381 87:699 88:416 89:1547 90:65 91:2684 92:409 93:1162 94:1286 95:789 96:193 97:290 98:490 99:23 100:1 109:220 110:263 111:411 112:168 113:221 114:308 115:498 116:1125 117:600 118:382 119:809 120:141 121:835 122:1389 123:830 124:1038 125:1314 128:198 129:202 130:137 131:458 132:84 133:16 134:193 135:41 136:220 137:173 138:234 139:80 140:464 141:122 142:376 143:345 144:387 145:51 146:404 147:178 148:564 149:193 150:151 151:171 152:244 153:165 154:2 155:271 156:177 157:331 158:98 159:355 160:304 161:175 162:271 163:190 164:309 165:473 166:491 167:388 168:759 169:157 170:567 171:46 172:2 173:436 174:532 175:23 180:278 183:212 184:3 186:267 187:222 188:1259 189:601 190:3469 192:5725 193:4402 194:3350 195:2760 196:1169 198:3552 199:3395 200:5282 201:1468 202:8069 203:8312 204:3996 205:2173 206:2426 207:3051 208:3916 209:3397 210:2538 211:1178 212:1661 213:1649 214:253 215:60 216:4418 217:1477 218:481 219:443 220:1145 221:463 222:299 End of report From patrick at ianai.net Fri Jan 15 12:42:44 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 15 Jan 2010 13:42:44 -0500 Subject: SORBS on autopilot? In-Reply-To: <4B50A115.5040104@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115163235.GA95587@ussenterprise.ufp.org> <4B50A115.5040104@sorbs.net> Message-ID: <75A98669-38D0-4EA3-BA9C-A9AC557B0217@ianai.net> On Jan 15, 2010, at 12:08 PM, Michelle Sullivan wrote: >> 2) SORBS robot reponds with "you must change your rDNS." > ... or respond to indicate why you think the robot is wrong... This does not work. Our provider has been told that unless the in-addr was changed to include the word "static", the listing would not be lifted, full stop. And yes, this was after entering tickets & following other procedures. (How do you think we got a human to respond? I don't post these things to mailing lists or newsgroups, just like I am not giving the provider's name or ticket number here.) Personally, I do not mind telling people "you must enter a ticket" or at least try the automated system. If there are ways to have the user help themselves, all the better. But lying (either Michelle in this thread, or the volunteer who responded to us) is not only unproductive, it is downright destructive. I also note that many other DULs have self-removal for nothing more than asking. Bots do not ask. These other DULs are more widely used, some have better metrics (both FPs and blocking rates, probably because providers are willing to work with them), and no one bitches about them in public, as people do about SORBS every week or few. -- TTFN, patrick From l.vig at limestonenetworks.com Fri Jan 15 12:50:08 2010 From: l.vig at limestonenetworks.com (Logan Vig) Date: Fri, 15 Jan 2010 12:50:08 -0600 Subject: SORBS on autopilot? In-Reply-To: <4B50927A.9030500@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> Message-ID: On Jan 15, 2010, at 10:06 AM, Michelle Sullivan wrote: For fast approval: Log ticket -> robot checks rDNS for all networks listed in ticket -> robot confirms all space is static and submits the ticket to the removals queue where it is manually checked by a human and processed. For manual approval: Log ticket -> robot checks rDNS for all networks listed in ticket -> robot denies delisting request sending response -> OP changes something and replies, just states they are the whois listed appropriate contact, or gives some reason why the robot is wrong and reopens the ticket with the reply -> SORBS volunteer reviews the available information from the robot and the subsequent reply from the OP and manually submits to the removals queue or rejects and gives a human response as to why (eg like with Shaw, Road Runner, Verizon, etc listings) the information is provided by the ISP and any delisting will be reversed within a week. Neither of these were the case in July-August 2008 when I was attempting to have a /18 from 69.0.0.0/8 delisted from your DUHL. It had previously been part of an Adelphia /14 which had been reclaimed by ARIN. I submitted numerous tickets, changed my RDNS (entries and TTL's), and submitted numerous replies via your RT system after the robot denied the requests. Not a single one of my tickets ever received a human reply from one of your administrators despite numerous replies from me via RT to the delisting tickets, and no errors in my RDNS configuration. After a month of head scratching and growing tired of submitting tickets and replies, I decided to submit the blocks one /24 at a time to see if I could get at least part of the /18 usable that way. The first few /24 delisting requests I submitted were immediately delisted by the robot. So I continued through the entire /18 and by the end of the day the whole /18 had been removed from your DUHL. That leads me to believe your DUHL robot cannot process subnets larger than /24, as nothing had changed on my end in the 24 hours between my last /18 removal request and the numerous /24 delisting requests I submitted. Between the lack of responses to my RT tickets, and the seeming inability of your automated system to properly process removal requests for ISP sized subnet allocations, I would have to say from experience that your DUHL delisting procedure is extremely flawed and was a total nightmare to get the /18 I was assigned from ARIN to a usable state. Here are some tickets to review: 205929 206524 207964 208986 and for the /24's which finally resulted in the /18 being delisted: 208996-209062 From bmanning at vacation.karoshi.com Fri Jan 15 12:52:30 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 15 Jan 2010 18:52:30 +0000 Subject: excessive automation In-Reply-To: <4B509F82.7040205@edisys.co.uk> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <3c3e3fca1001150814g3af73852w2d5ce2dd8302b30b@mail.gmail.com> <4B50974E.3080308@edisys.co.uk> <4B509E78.6050307@mtcc.com> <4B509F82.7040205@edisys.co.uk> Message-ID: <20100115185230.GA10967@vacation.karoshi.com.> On Fri, Jan 15, 2010 at 05:01:54PM +0000, William Hamilton wrote: > > I agree it's perhaps not clear how to get hold of a human, but you can't > really argue that it's not clear how to progress the issue in general as > the message quite clearly tells you to respond if you wish for it to be > re-opened. and to the creative mind, a wide range of responses opens for consideration. > I can't accept that the instructions that the bot provided were unclear, > but can organisations in general (again, not SORBS-specific) do better > when dealing with their "customers"? like the autobot on Magrathea? > > Absolutely. > > B > From bicknell at ufp.org Fri Jan 15 13:08:52 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 15 Jan 2010 11:08:52 -0800 Subject: SORBS on autopilot? In-Reply-To: <4CF2B345-18A6-4193-AA42-EEBF56E3BAF8@jedsmith.org> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <20100115163235.GA95587@ussenterprise.ufp.org> <4B50A115.5040104@sorbs.net> <4CF2B345-18A6-4193-AA42-EEBF56E3BAF8@jedsmith.org> Message-ID: <20100115190852.GA11508@ussenterprise.ufp.org> In a message written on Fri, Jan 15, 2010 at 01:26:49PM -0500, Jed Smith wrote: > Let me reiterate for the benefit of Ricky Beam, Ken Chase, Leo Bicknell, Paul, > and anybody else who is tempted to debate Michelle in this thread: you are 100% > wasting your time. Good advice, for sure. Fortunately in this case I have no interest in debate. I've posted my $0.02, and I'll let people take that for what it is.... > Your time is much better spent contacting every mail administrator on the > Internet who 5xx's your relay's mail, or asking your upstream to move you out of > the affected block. Both will result in more productivity than debating anybody > that works for SORBS or who is a colleague of Michelle Sullivan. You might be > right, she might be right, and in either case it doesn't matter. Move on. > There are far more pressing matters in life. There is something to be learned here. Blocking e-mail based on ANY single service is likely to be a disservice to you and your customers. I have yet to see a "mistake free" block list from anyone. Tools such as SpamAssassin allow you to score e-mail based on responses from many services, including SORBS. Make sure you're using 6+ services, and at least two, and preferrably three must agree before you toss the mail as spam. So when you contact that mail admin, tell them to remove whatever DNSBL's they have at the SMTP transport level and let SpamAssassin, or a Barracuda, or other similar tool make decisions based on corroborating multiple sources of information. -- 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: 826 bytes Desc: not available URL: From fred at cisco.com Fri Jan 15 14:15:10 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 15 Jan 2010 12:15:10 -0800 Subject: Anyone see a game changer here? In-Reply-To: <4B509445.1030809@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B509445.1030809@linuxbox.org> Message-ID: <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> On Jan 15, 2010, at 8:13 AM, Gadi Evron wrote: > 1. Unlike GhostNet, which showed an interesting attack but jumped to > conclusions without evidence that it was China behind them -- based > on Ethos alone I'd like to think that when Google says China did it, > they know. Although being a commercial company with their own > agenda, I am saving final judgement. Did Google ever say it's China > rather than from China? To my understanding they believe that people that live in China are relevant (which is why they brought it up in the context), but they are very carefully saying that they don't know the exact perpetrators. http://www.ipinc.net/IPv4.GIF From matthew at sorbs.net Fri Jan 15 14:17:11 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Fri, 15 Jan 2010 21:17:11 +0100 Subject: SORBS on autopilot? In-Reply-To: References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> Message-ID: <4B50CD47.60208@sorbs.net> Logan Vig wrote: > > Here are some tickets to review: > > 205929 > > 206524 > > 207964 > > 208986 > > and for the /24's which finally resulted in the /18 being delisted: > > 208996-209062 > Well from the initial look you kept submitting new tickets and the SORBS staff kept merging them into the latest ticket as previously stated. You in effect delayed any human response yourself.... and it looks like you managed to exploit a flaw in the system to bypass the delisting rules as you were not entitled to be delisted at the time. I'd suggest you might want to not push things or I will review the entire entry with a view to correcting any incorrect delisting. No that's not retaliatory, that's just correcting an error that you have just alerted me to... (if however, you are entitled not to be listed now, the entry would not be re-instated..) Michelle From ge at linuxbox.org Fri Jan 15 14:51:07 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 15 Jan 2010 22:51:07 +0200 Subject: Anyone see a game changer here? In-Reply-To: <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B509445.1030809@linuxbox.org> <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> Message-ID: <4B50D53B.5010303@linuxbox.org> On 1/15/10 10:15 PM, Fred Baker wrote: > > On Jan 15, 2010, at 8:13 AM, Gadi Evron wrote: > >> 1. Unlike GhostNet, which showed an interesting attack but jumped to >> conclusions without evidence that it was China behind them -- based on >> Ethos alone I'd like to think that when Google says China did it, they >> know. Although being a commercial company with their own agenda, I am >> saving final judgement. Did Google ever say it's China rather than >> from China? > > > To my understanding they believe that people that live in China are > relevant (which is why they brought it up in the context), but they are > very carefully saying that they don't know the exact perpetrators. > > http://www.ipinc.net/IPv4.GIF > Absolutely, they pointed it out to me elsewhere (I copy-pasted). I made a mistake. I mention them as #1 before the current incident out of respect. This should have said "but many jumped to conclusions..." which is also what I said at the time, and supports my third point. Thanks for pointing this out. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From mksmith at adhost.com Fri Jan 15 15:19:05 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 15 Jan 2010 13:19:05 -0800 Subject: Moderated Post - SORBS... Message-ID: <17838240D9A5544AAA5FF95F8D520316077353AB@ad-exh01.adhost.lan> Hello Everyone: The thread "Sorbs on autopilot?" has been moderated. Kind Regards, Mike (on behalf of the NANOG CC) -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From bmanning at vacation.karoshi.com Fri Jan 15 15:54:01 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 15 Jan 2010 21:54:01 +0000 Subject: um... human generated requests In-Reply-To: <4B50CD47.60208@sorbs.net> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <4B50CD47.60208@sorbs.net> Message-ID: <20100115215401.GA12232@vacation.karoshi.com.> If I may ... two questions: a) do the humans @ SORBS use the AI/GUI that everyone else uses to query/request changes or do all SORBS internal manipulations use an entirely different AI/GUI? b) is there any method for someone to request their (as opposed to someone elses) prefix be added to SORBS? e.g. whois 192.0.2.0 OrgName: BillsBaitandSushi OrgID: BBS Address: 4676 Admiralty Way, Suite 1000 City: Marina del Rey StateProv: CA PostalCode: 90292-6695 Country: US OrgTechHandle: BBS-IP-ARIN OrgTechName: BillsBaitandSushi OrgTechPhone: +1-310-555.1212 OrgTechEmail: bmanning at example.net and I, as bmanning at example.net -REQUEST- that 192.0.2.0/24 be added to SORBS - even though your tests do not indicate any other reason to add said prefix to SORBS, would it get added? --bill From cidr-report at potaroo.net Fri Jan 15 16:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Jan 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201001152200.o0FM03kQ095140@wattle.apnic.net> BGP Update Report Interval: 07-Jan-10 -to- 14-Jan-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5800 29398 2.6% 133.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 2 - AS1790 17936 1.6% 2242.0 -- Sprint US 3 - AS17488 16692 1.5% 15.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 4 - AS4755 14041 1.2% 16.4 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 5 - AS9829 12287 1.1% 22.4 -- BSNL-NIB National Internet Backbone 6 - AS9430 11407 1.0% 393.3 -- STPI-NOIDA Software Technology Parks of India,Block-IV 7 - AS7643 11061 1.0% 42.4 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - AS31055 10480 0.9% 2620.0 -- CONSULTIX-AS Consultix GmbH 9 - AS3255 9975 0.9% 62.7 -- UARNET-AS Ukrainian Academic and Research Network 10 - AS4270 9792 0.8% 3264.0 -- Red de Interconexion Universitaria 11 - AS9198 8979 0.8% 21.0 -- KAZTELECOM-AS JSC Kazakhtelecom 12 - AS37986 7350 0.6% 84.5 -- TULIP Tulip Telecom Ltd. 13 - AS17964 6394 0.6% 57.1 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 14 - AS7029 6055 0.5% 10.4 -- WINDSTREAM - Windstream Communications Inc 15 - AS9299 5751 0.5% 11.9 -- IPG-AS-AP Philippine Long Distance Telephone Company 16 - AS11139 5714 0.5% 12.6 -- CWRIN CW BARBADOS 17 - AS8452 5521 0.5% 5.9 -- TEDATA TEDATA 18 - AS7738 5348 0.5% 12.7 -- Telecomunicacoes da Bahia S.A. 19 - AS11492 5308 0.5% 7.2 -- CABLEONE - CABLE ONE, INC. 20 - AS20771 5154 0.5% 105.2 -- CAUCASUS-CABLE-SYSTEM CCS Autonomous System TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4270 9792 0.8% 3264.0 -- Red de Interconexion Universitaria 2 - AS20066 2643 0.2% 2643.0 -- MORRISTECH - Morris Technologies, Inc. 3 - AS31055 10480 0.9% 2620.0 -- CONSULTIX-AS Consultix GmbH 4 - AS48754 2399 0.2% 2399.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 5 - AS1790 17936 1.6% 2242.0 -- Sprint US 6 - AS46069 1059 0.1% 1059.0 -- CNA-AS-AP Catholic Network Australia Limited 7 - AS12122 1558 0.1% 779.0 -- STJHS - St. Joseph Health System 8 - AS45953 748 0.1% 748.0 -- CNAPOPS-AS-AP Catholic Network Australia Limited 9 - AS27667 680 0.1% 680.0 -- Universidad Autonoma de la Laguna 10 - AS36988 1148 0.1% 574.0 -- MILLICOM-SL 11 - AS22570 471 0.0% 471.0 -- AUTODESK-1 Autodesk, Inc. 12 - AS41330 410 0.0% 410.0 -- STEKGSM-AS CTeK GSM autonomous system 13 - AS43818 394 0.0% 394.0 -- MELLAT-AS bankmellat 14 - AS9430 11407 1.0% 393.3 -- STPI-NOIDA Software Technology Parks of India,Block-IV 15 - AS6822 2206 0.2% 367.7 -- SUPERONLINE-AS SuperOnline autonomous system 16 - AS10445 2907 0.2% 363.4 -- HTG - Huntleigh Telcom 17 - AS44189 294 0.0% 294.0 -- MEA Middle East Airlines 18 - AS5468 566 0.1% 283.0 -- EUNnet - Ekaterinburg UNiversities network 19 - AS45960 268 0.0% 268.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 20 - AS49697 248 0.0% 248.0 -- SHABAKIEH-AS Shabakieh Isfahan Co. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 10456 0.8% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 170.210.56.0/22 9724 0.8% AS4270 -- Red de Interconexion Universitaria 3 - 69.34.252.0/23 3604 0.3% AS1790 -- Sprint US 4 - 69.34.220.0/22 3603 0.3% AS1790 -- Sprint US 5 - 69.69.228.0/22 3603 0.3% AS1790 -- Sprint US 6 - 67.77.98.0/23 3601 0.3% AS1790 -- Sprint US 7 - 204.214.88.0/24 3514 0.3% AS1790 -- Sprint US 8 - 203.162.118.128/ 3131 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 9 - 174.47.118.0/24 2643 0.2% AS20066 -- MORRISTECH - Morris Technologies, Inc. 10 - 202.177.223.0/24 2524 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 11 - 192.12.120.0/24 2517 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 12 - 91.212.23.0/24 2399 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 13 - 202.5.154.0/24 2157 0.2% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 14 - 222.255.186.0/25 2147 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 15 - 110.234.204.0/23 1709 0.1% AS37986 -- TULIP Tulip Telecom Ltd. 16 - 110.234.206.0/23 1707 0.1% AS37986 -- TULIP Tulip Telecom Ltd. 17 - 110.234.208.0/23 1707 0.1% AS37986 -- TULIP Tulip Telecom Ltd. 18 - 143.138.107.0/24 1628 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 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 Jan 15 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Jan 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201001152200.o0FM009Q095132@wattle.apnic.net> This report has been generated at Fri Jan 15 21:11:26 2010 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-01-10 313220 193186 09-01-10 313086 192232 10-01-10 312970 191801 11-01-10 313035 191733 12-01-10 313025 191707 13-01-10 313292 191755 14-01-10 313500 191987 15-01-10 314098 192183 AS Summary 33348 Number of ASes in routing system 14205 Number of ASes announcing only one prefix 4379 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 92652032 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 15Jan10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 314662 192179 122483 38.9% All ASes AS6389 4166 309 3857 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4379 1667 2712 61.9% TWTC - tw telecom holdings, inc. AS4766 1984 593 1391 70.1% KIXS-AS-KR Korea Telecom AS1785 1794 570 1224 68.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS17488 1464 295 1169 79.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1125 71 1054 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 35 1024 96.7% COVAD - Covad Communications Co. AS4755 1310 406 904 69.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1580 686 894 56.6% Uninet S.A. de C.V. AS10620 1004 151 853 85.0% TV Cable S.A. AS19262 1052 238 814 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 1036 292 744 71.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8452 1018 299 719 70.6% TEDATA TEDATA AS17908 758 58 700 92.3% TCISL Tata Communications AS6478 1103 463 640 58.0% ATT-INTERNET3 - AT&T WorldNet Services AS4808 837 224 613 73.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 832 228 604 72.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1202 624 578 48.1% LEVEL3 Level 3 Communications AS4804 634 71 563 88.8% MPX-AS Microplex PTY LTD AS7303 670 107 563 84.0% Telecom Argentina S.A. AS7018 1593 1032 561 35.2% ATT-INTERNET4 - AT&T WorldNet Services AS4134 1019 479 540 53.0% CHINANET-BACKBONE No.31,Jin-rong Street AS11492 1128 620 508 45.0% CABLEONE - CABLE ONE, INC. AS7545 943 438 505 53.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 547 67 480 87.8% VTR BANDA ANCHA S.A. AS855 607 129 478 78.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS28573 840 375 465 55.4% NET Servicos de Comunicao S.A. AS4780 615 153 462 75.1% SEEDNET Digital United Inc. AS9443 539 79 460 85.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS5668 786 337 449 57.1% AS-5668 - CenturyTel Internet Holdings, Inc. Total 37624 11096 26528 70.5% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.8.64.0/18 AS19166 ACRONOC - ACRONOC INC 96.8.127.0/24 AS19166 ACRONOC - ACRONOC INC 100.100.100.0/24 AS36992 ETISALAT-MISR 109.237.160.0/20 AS47358 NTRNET NTRnet s.r.l. 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.207.128.0/20 AS26452 BRING-AS - BringCom, Inc. 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.50.74.0/24 AS25984 198.50.88.0/24 AS6079 RCN-AS - RCN Corporation 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.32.0/24 AS25984 198.133.139.0/24 AS25984 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet 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.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/23 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.192.0/20 AS14697 VDOTNET - VDot.Net 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.243.240.0/20 AS12182 INTERNAP-2BLK - Internap Network Services Corporation 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 nathan at atlasnetworks.us Fri Jan 15 16:14:03 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 15 Jan 2010 14:14:03 -0800 Subject: um... human generated requests In-Reply-To: <20100115215401.GA12232@vacation.karoshi.com.> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <4B50CD47.60208@sorbs.net> <20100115215401.GA12232@vacation.karoshi.com.> Message-ID: <11B064048F34FD4094CBA16FC04BE219865D2EB3@ex01> > -----Original Message----- > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > Sent: Friday, January 15, 2010 1:54 PM > To: Michelle Sullivan > Cc: nanog at nanog.org > Subject: um... human generated requests > > > > If I may ... two questions: > > a) do the humans @ SORBS use the AI/GUI that everyone else uses > to query/request > changes or do all SORBS internal manipulations use an entirely > different AI/GUI? > > b) is there any method for someone to request their (as opposed > to someone elses) > prefix be added to SORBS? e.g. > > whois 192.0.2.0 Slightly confused - it sounds like you're asking if you can list yourself on a blacklist? Is that a self-immolating form of protest, or did I misread? Best Regards, Nathan Eisenberg From bruns at 2mbit.com Fri Jan 15 16:18:50 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 15 Jan 2010 15:18:50 -0700 Subject: um... human generated requests In-Reply-To: <11B064048F34FD4094CBA16FC04BE219865D2EB3@ex01> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <4B50CD47.60208@sorbs.net> <20100115215401.GA12232@vacation.karoshi.com.> <11B064048F34FD4094CBA16FC04BE219865D2EB3@ex01> Message-ID: <4B50E9CA.8040802@2mbit.com> On 1/15/10 3:14 PM, Nathan Eisenberg wrote: > > Slightly confused - it sounds like you're asking if you can list > yourself on a blacklist? Is that a self-immolating form of protest, > or did I misread? Sounds more like to me an attempt to engineer a situation to cause grief on SORBS end. Maybe its because the fact i'm a DNSbl maintainer, and people have tried these things before that my spammy sense is tingling. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From ge at linuxbox.org Fri Jan 15 16:27:34 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 16 Jan 2010 00:27:34 +0200 Subject: more news from Google In-Reply-To: <6F4C2201-A75A-4F88-B108-3021058544CA@cs.columbia.edu> References: <255275490-1263421495-cardhu_decombobulator_blackberry.rim.net-196880606-@bda062.bisx.prod.on.blackberry> <6F4C2201-A75A-4F88-B108-3021058544CA@cs.columbia.edu> Message-ID: <4B50EBD6.7030606@linuxbox.org> On 1/14/10 12:31 AM, Steven Bellovin wrote: > > On Jan 13, 2010, at 5:26 PM, msheldon at cox.net wrote: > >> From a single detection of one hostile email you can often expand the picture to many mail recipients. A little open source research identifies the common community the recipients belong to. It's pretty straight forward. >> > > The magic phrase is "traffic analysis" -- look at the accounts of known targets of interest, and see the usernames, IP addresses, etc., of their correspondents. Recurse as needed. I am unsure about the term straight-forward, as even the easy cases take a lot of time. Gadi > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From fred at cisco.com Fri Jan 15 17:01:33 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 15 Jan 2010 15:01:33 -0800 Subject: more news from Google In-Reply-To: <80b7d9f61001130852n70f88e46mc53dff01d9bad5e0@mail.gmail.com> References: <20100113052416.GB12526@sizone.org> <00af01ca941e$ba3c6390$2eb52ab0$@net> <55117F5B-6E2F-4813-BD9B-E984CCA0763B@ianai.net> <80b7d9f61001130852n70f88e46mc53dff01d9bad5e0@mail.gmail.com> Message-ID: <1AC2C923-ADEB-462F-85E9-52F81EE65F99@cisco.com> The Google Spokesperson I heard on the radio yesterday evening said that they had not yet stopped censoring, and declined to give a date when they would. His point was that the clock is ticking and Google can see it. On Jan 13, 2010, at 8:52 AM, J?r?me Fleury wrote: > On Wed, Jan 13, 2010 at 17:14, Patrick W. Gilmore > wrote: >> On Jan 13, 2010, at 2:05 AM, Stefan Fouant wrote: >> >>> I for one would be really happy to see them follow through with >>> this. I was >>> very disappointed when they agreed to censor search results, >>> although I can >>> understand why they did so from a business standpoint... it seemed >>> to go >>> against the google mantra of "do no evil"... >>> >>> I'm skeptical if they'll go through with it... >> >> According to their spokesperson, they have already stopped censoring. > > They probably haven't yet > > http://images.google.cn/images?hl=zh-CN&um=1&sa=1&q=tiananmen+square+protest&btnG=Google+??&aq=0&oq=tian&sta > rt=0 > > http://images.google.com/images?hl=fr&source=hp&q=tiananmen+square+protest&btnG=Recherche+d%27images&gbv=2&aq=1&oq=tian > http://www.ipinc.net/IPv4.GIF From fred at cisco.com Fri Jan 15 17:05:07 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 15 Jan 2010 15:05:07 -0800 Subject: more news from Google In-Reply-To: <4B4DF570.6090100@dataway.ch> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> Message-ID: <00C3E516-7003-4C28-BEEA-73BF6948EB97@cisco.com> On Jan 13, 2010, at 8:31 AM, Anthony Uk wrote: > The ability to automatically discern users' political positions from > their inbox is not one that any email provider reasonably needs. I'm not Chinese, but putting myself in their position... I would be surprised if they were trying to determine anyone's political positions. Google's observation that the targeted parties were dissidents suggests that they are known to be dissidents without looking at their gmail content. If I were of the specified mindset and were looking at their mail, I think I might be mapping dissident networks to identify potential dissidents I was unaware of and looking to see if they mentioned any specific plans or pointed to specific content. From williams.bruce at gmail.com Fri Jan 15 17:05:19 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Fri, 15 Jan 2010 15:05:19 -0800 Subject: Anyone see a game changer here? In-Reply-To: <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B509445.1030809@linuxbox.org> <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> Message-ID: <775e001a1001151505y77c663e5xeafa379bbc65b662@mail.gmail.com> > To my understanding they believe that people that live in China are relevant > (which is why they brought it up in the context), but they are very > carefully saying that they don't know the exact perpetrators. > > http://www.ipinc.net/IPv4.GIF > > > Uh, Fred the link is to an image that has nothing to do with the topic. Can you prove you are not Chinese and my computer is not hacked? Fred is your real name, isn't it? You are Fred, aren't you? Seriously, it suddenly came to mind that this list is a "high value target" and many people click away on links from who knows who. I guess it's the classic the shoemakers kids have no shoes situation.... Bruce -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From fred at cisco.com Fri Jan 15 17:15:36 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 15 Jan 2010 15:15:36 -0800 Subject: Anyone see a game changer here? In-Reply-To: <775e001a1001151505y77c663e5xeafa379bbc65b662@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B509445.1030809@linuxbox.org> <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> <775e001a1001151505y77c663e5xeafa379bbc65b662@mail.gmail.com> Message-ID: <5B025C75-BBBE-4866-AF9D-71873DB99BFD@cisco.com> On Jan 15, 2010, at 3:05 PM, Bruce Williams wrote: > Can you prove you are not Chinese and my computer is not hacked? > Fred is your real name, isn't it? You are Fred, aren't you? You. Says so on my business card... -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_2226_2.jpg Type: image/jpeg Size: 14827 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Fri Jan 15 17:30:16 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 15 Jan 2010 23:30:16 +0000 Subject: um... human generated requests In-Reply-To: <11B064048F34FD4094CBA16FC04BE219865D2EB3@ex01> References: <20100111154759.GK6617@sizone.org> <4B50927A.9030500@sorbs.net> <4B50CD47.60208@sorbs.net> <20100115215401.GA12232@vacation.karoshi.com.> <11B064048F34FD4094CBA16FC04BE219865D2EB3@ex01> Message-ID: <20100115233016.GB12232@vacation.karoshi.com.> On Fri, Jan 15, 2010 at 02:14:03PM -0800, Nathan Eisenberg wrote: > > -----Original Message----- > > From: bmanning at vacation.karoshi.com > > [mailto:bmanning at vacation.karoshi.com] > > Sent: Friday, January 15, 2010 1:54 PM > > To: Michelle Sullivan > > Cc: nanog at nanog.org > > Subject: um... human generated requests > > > > > > > > If I may ... two questions: > > > > a) do the humans @ SORBS use the AI/GUI that everyone else uses > > to query/request > > changes or do all SORBS internal manipulations use an entirely > > different AI/GUI? > > > > b) is there any method for someone to request their (as opposed > > to someone elses) > > prefix be added to SORBS? e.g. > > > > whois 192.0.2.0 > > > Slightly confused - it sounds like you're asking if you can list yourself on a blacklist? Is that a self-immolating form of protest, or did I misread? > > Best Regards, > Nathan Eisenberg > pegged it in one. to borrow lines from Arlo Guthrie... "And the only reason I'm singing you this song now is cause you may know somebody in a similar situation, or you may be in a similar situation, and if your in a situation like that there's only one thing you can do and that's walk into the shrink wherever you are, just walk in say "Shrink, You can get anything you want, at Alice's restaurant.". And walk out. You know, if one person, just one person does it they may think he's really sick and they won't take him. And if two people, two people do it, in harmony, they may think they're both faggots and they won't take either of them. And three people do it, three, can you imagine, three people walking in singin a bar of Alice's Restaurant and walking out. They may think it's an organization. And can you, can you imagine fifty people a day,I said fifty people a day walking in singin a bar of Alice's Restaurant and walking out. And friends they may thinks it's a movement. And that's what it is , the Alice's Restaurant Anti-Massacre Movement, and all you got to do to join is sing it the next time it come's around on the guitar. With feeling.".... --bill From tvest at eyeconomics.com Fri Jan 15 18:34:23 2010 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Sat, 16 Jan 2010 01:34:23 +0100 Subject: Anyone see a game changer here? In-Reply-To: <5B025C75-BBBE-4866-AF9D-71873DB99BFD@cisco.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B509445.1030809@linuxbox.org> <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> <775e001a1001151505y77c663e5xeafa379bbc65b662@mail.gmail.com> <5B025C75-BBBE-4866-AF9D-71873DB99BFD@cisco.com> Message-ID: <30AEB813-A63F-44BD-9BEF-2291F60A048F@eyeconomics.com> On Jan 16, 2010, at 12:15 AM, Fred Baker wrote: > > On Jan 15, 2010, at 3:05 PM, Bruce Williams wrote: >> Can you prove you are not Chinese and my computer is not hacked? >> Fred is your real name, isn't it? You are Fred, aren't you? > > You. Says so on my business card... > > ?????? TV From andrew.wallace at rocketmail.com Fri Jan 15 18:43:18 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 16 Jan 2010 00:43:18 +0000 Subject: U.S. plans formal complaint over Google attacks Message-ID: <4b6ee9311001151643v22c7c380h12b35af62b80e374@mail.gmail.com> Hey Marcus, you got what you wanted pal (http://www.youtube.com/watch?v=FSUPTZVlkyU), cyber security ramped up as a national security agenda item. http://news.cnet.com/8301-30684_3-10436018-265.html Congrats, Andrew From randy at psg.com Fri Jan 15 19:00:38 2010 From: randy at psg.com (Randy Bush) Date: Sat, 16 Jan 2010 10:00:38 +0900 Subject: more news from Google In-Reply-To: <00C3E516-7003-4C28-BEEA-73BF6948EB97@cisco.com> References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <00C3E516-7003-4C28-BEEA-73BF6948EB97@cisco.com> Message-ID: i am confused here, which is not at all unusual. did the chinese get any data which google does not give to american LEAs in answer to an administrative request, i.e. not even a court order? randy From lyndon at orthanc.ca Fri Jan 15 19:01:47 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Fri, 15 Jan 2010 18:01:47 -0700 Subject: Network Provider Recommendation in Edmonton AB Message-ID: <894ad1e23fc60ce28226727bd19ab1fd@yyc.orthanc.ca> I have a client in Edmonton who's looking for a network drop to their office, something in the 2-10 MB/s range. The location is at 46 Ave. and 99 St. The core requirement is for a bare unfiltered *symmetric* pipe (no ADSL). Traffic volume will be low: 2-4 laptop VPNs plus some light web server and email traffic. 2 Mb/s as a lower bound should be fine, with a /28 IPv4 address block (either bridged or routed). I've been away from Edmonton long enough now that I no longer know who's active there, so any and all feedback is welcome. (Vendors, too, provided you include some real content.) Please respect the Reply-To header. Cheers, --lyndon From nanog304985 at aquick.org Fri Jan 15 19:22:23 2010 From: nanog304985 at aquick.org (Adam Fields) Date: Fri, 15 Jan 2010 20:22:23 -0500 Subject: more news from Google In-Reply-To: References: <20100113052416.GB12526@sizone.org> <4B4DF570.6090100@dataway.ch> <00C3E516-7003-4C28-BEEA-73BF6948EB97@cisco.com> Message-ID: <20100116012223.GO17327@lola.aquick.org> On Sat, Jan 16, 2010 at 10:00:38AM +0900, Randy Bush wrote: > i am confused here, which is not at all unusual. did the chinese get > any data which google does not give to american LEAs in answer to an > administrative request, i.e. not even a court order? You mean why didn't they just ask for it instead of going through all this trouble? -- - Adam -- ** I design intricate-yet-elegant processes for user and machine problems. ** Custom development project broken? Contact me, I can help. ** Some of what I do: http://workstuff.tumblr.com/post/70505118/aboutworkstuff [ http://workstuff.tumblr.com ] ........... Technology Blog [ http://www.aquick.org/blog ] ............ Personal Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.twitter.com/fields ].......... Twitter [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder From fred at cisco.com Fri Jan 15 19:28:01 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 15 Jan 2010 17:28:01 -0800 Subject: Anyone see a game changer here? In-Reply-To: <30AEB813-A63F-44BD-9BEF-2291F60A048F@eyeconomics.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B509445.1030809@linuxbox.org> <4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com> <775e001a1001151505y77c663e5xeafa379bbc65b662@mail.gmail.com> <5B025C75-BBBE-4866-AF9D-71873DB99BFD@cisco.com> <30AEB813-A63F-44BD-9BEF-2291F60A048F@eyeconomics.com> Message-ID: <4767F86F-FBD1-4B53-8C22-DAB05665BF7F@cisco.com> On Jan 15, 2010, at 4:34 PM, tvest at eyeconomics.com wrote: > > On Jan 16, 2010, at 12:15 AM, Fred Baker wrote: > >> >> On Jan 15, 2010, at 3:05 PM, Bruce Williams wrote: >>> Can you prove you are not Chinese and my computer is not hacked? >>> Fred is your real name, isn't it? You are Fred, aren't you? >> >> You. Says so on my business card... >> >> > > ?????? Google Translation tells me this means "see never see!". Let me guess, there's a better translation. From wbailey at gci.com Fri Jan 15 19:32:04 2010 From: wbailey at gci.com (Warren Bailey) Date: Fri, 15 Jan 2010 16:32:04 -0900 Subject: Anyone see a game changer here? In-Reply-To: <4767F86F-FBD1-4B53-8C22-DAB05665BF7F@cisco.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com><878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net><13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu><4B509445.1030809@linuxbox.org><4E85EA0F-4CEF-4034-AFF8-DACD9A0A42C4@cisco.com><775e001a1001151505y77c663e5xeafa379bbc65b662@mail.gmail.com><5B025C75-BBBE-4866-AF9D-71873DB99BFD@cisco.com><30AEB813-A63F-44BD-9BEF-2291F60A048F@eyeconomics.com> <4767F86F-FBD1-4B53-8C22-DAB05665BF7F@cisco.com> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10CBC38D2@DTN1EX01.gci.com> That's the translation the Chinese Government has inserted into the Google Translation service. ;) -----Original Message----- From: Fred Baker [mailto:fred at cisco.com] Sent: Friday, January 15, 2010 4:28 PM To: tvest at eyeconomics.com Cc: NANOG Subject: Re: Anyone see a game changer here? On Jan 15, 2010, at 4:34 PM, tvest at eyeconomics.com wrote: > > On Jan 16, 2010, at 12:15 AM, Fred Baker wrote: > >> >> On Jan 15, 2010, at 3:05 PM, Bruce Williams wrote: >>> Can you prove you are not Chinese and my computer is not hacked? >>> Fred is your real name, isn't it? You are Fred, aren't you? >> >> You. Says so on my business card... >> >> > > ?????? Google Translation tells me this means "see never see!". Let me guess, there's a better translation. From ops.lists at gmail.com Fri Jan 15 19:47:50 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 16 Jan 2010 07:17:50 +0530 Subject: Virbl: The First IPv6 enabled dnsbl? In-Reply-To: <1263570625.5089.29.camel@highway.office.bit.nl> References: <1263570625.5089.29.camel@highway.office.bit.nl> Message-ID: The listing method is if you actually receive virus traffic over v6. Which someone will, sooner or later .. Yes, I agree with listing a slightly larger range - given that /64 seems to be what most anyone gets these days with a free tunnel. I wish you all the very best of fun trying to run dnsbl zones serving up v6. --srs On Fri, Jan 15, 2010 at 9:20 PM, Mark Schouten wrote: > Hi, > > FYI: > > http://virbl.bit.nl/index.php#ipv6 > > Comments on the listing method are appreciated. > > Regards, -- Suresh Ramasubramanian (ops.lists at gmail.com) From jimb at jsbc.cc Fri Jan 15 21:53:43 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 15 Jan 2010 19:53:43 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <4B4FA214.4030808@jsbc.cc> Message-ID: <4B513847.7090204@jsbc.cc> Sorry for late response here... On 1/14/2010 15:20, Cameron Byrne wrote: > On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell wrote: > >> On 1/14/2010 11:10, Cameron Byrne wrote: >> >>> Folks, >>> >>> My question to the community is: assuming a network based IPv6 to IP4 >>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet >>> services viable as a product today? In particular, would it be >>> appropriate for a 3G /smartphone or wireless broadband focused on at >>> casual (web and email) Internet users? Keep in mind, these users have >>> NAT44 today. >>> >>> >> You may also want to read up on Dual Stack Lite (DS-Lite) >> , >> > I have looked at DS-lite very carefully. First, DS-Lite fits better > for cable operators since they have CPE and can have a DS-lite > function in the CPE that they control, and that in turn allows them to > provide IPv4, IPv6, and dual-stack to the end-host that they do not > control. DS-Lite does not fit as well for a mobile phones since it > would require a major change to the phone's OS. Second, DS-Lite > requires tunneling as well as translation, so it is one more piece of > overhead in addition to NAT64 solution. For me, i believe it is less > complex to manage a single stack IPv6 host with NAT64 translation than > a dual stack host, tunneling infrastructure, as well as NAT44 CGN, > which is what DS-lite requires. They both achieve the same result, > but I believe in the mobile space there is a quicker time to market as > well as more progress toward the end-goal of IPv6-only using NAT64 > than DS-lite. > I guess the choice here is between standing up and managing a NAT64 CGN + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite tunneling infrastructure (you'd be able to keep existing "vanilla" DNS servers). Presuming you could set up DS-Lite capable routers somewhere in the path, one nice thing about DS-Lite would be that you could allow a mix of dual-stack phones, IPv4 only phones, and even DS-Lite capable phones on the same network. This could be an advantage if IPv6 stacks or DS-Lite virtual nic/tunnel drivers weren't available on all customer phones. Also, as Mr. Durand mentioned earlier, DS-Lite has an advantage in application compatibility too. And, admittedly getting a bit speculative here, by virtue of the fact that a DS-Lite solution would give each phone an IPv4 address, "NAT compatibility" of various applications may also be better on the CGN, since NAT44 is so well understood and generally "worked out" today, where a NAT64 CGN might not support as many "problem apps" which require "fixups" as a DS-lite NAT44 CGN. But if we can presume all phones will have IPv6, and all applications running on them are IPv6 capable, then DNS64/NAT64 would in some ways be cleaner, since it'd eliminate the traffic overhead of tunneling, etc. You'd just have to stand up and manage the DNS64 servers and NAT64 CGNs. >> presuming you haven't. I know you mentioned you didn't like any >> dual-stack solutions, but the thing about DS-Lite I like is that it has >> no problem with RFC1918 overlap of different customers, since the CGN >> uses a tunnel ID in the connection/NAT table in addition to the other >> typical data. I just wonder how it will scale, since each device, or a >> gateway the device goes though, will require a IPv4-in-IPv6 tunnel to >> the CGN box(es). Also, it doesn't require a DNS-ALG like NAT64/DNS64. >> > NAT64/DNS64 does not use a DNS-ALG. DNS-ALG died with NAT-PT. DNS64 > is a standalone function which is decoupled from the translation > process. > Yeah this is improper terminology I suppose. I use "DNS-ALG" in the IPv6 transition context as a generic term for any specialized DNS server which hacks IPv4 addresses into fake IPv6 addresses for these sorts of purposes, which is further overloading the term I guess. :p Not sure what to use as a better generic term for this. The point I was trying to make is that DS-Lite doesn't require any DNS hackery, unlike NAT64/DNS64, for what it's worth. Anyway, plenty to weigh/consider here. PS: Nice to see the author of the DS-Lite drafts participating here too. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From tammy-lists at wiztech.biz Fri Jan 15 23:30:45 2010 From: tammy-lists at wiztech.biz (Tammy A. Wisdom) Date: Fri, 15 Jan 2010 22:30:45 -0700 (MST) Subject: [mailop] Virbl: The First IPv6 enabled dnsbl? In-Reply-To: <1263571112.5089.34.camel@highway.office.bit.nl> Message-ID: <757220502.276.1263619845706.JavaMail.root@lordsofacid.wiztech.biz> ----- "Mark Schouten" wrote: > Hi, > > FYI: > > http://virbl.bit.nl/index.php#ipv6 > > Comments on the listing method are appreciated. > > Regards, > wow bind? thats gonna get slower and slower and slower. I hope you have a TON of ram for that box. for example if we loaded the current contents of the ahbl from rbldnsd to bind it would take up a TON of ram. bind would take forever to load and and would be screaming for its dear life. --Tammy Tammy A Wisdom The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org ****************************************************************************** Disclaimer: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. ****************************************************************************** From owen at delong.com Sat Jan 16 01:45:56 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jan 2010 23:45:56 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: <4B513847.7090204@jsbc.cc> References: <4B4FA214.4030808@jsbc.cc> <4B513847.7090204@jsbc.cc> Message-ID: On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote: > Sorry for late response here... > > On 1/14/2010 15:20, Cameron Byrne wrote: >> On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell wrote: >> >>> On 1/14/2010 11:10, Cameron Byrne wrote: >>> >>>> Folks, >>>> >>>> My question to the community is: assuming a network based IPv6 to IP4 >>>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet >>>> services viable as a product today? In particular, would it be >>>> appropriate for a 3G /smartphone or wireless broadband focused on at >>>> casual (web and email) Internet users? Keep in mind, these users have >>>> NAT44 today. >>>> >>>> >>> You may also want to read up on Dual Stack Lite (DS-Lite) >>> , >>> >> I have looked at DS-lite very carefully. First, DS-Lite fits better >> for cable operators since they have CPE and can have a DS-lite >> function in the CPE that they control, and that in turn allows them to >> provide IPv4, IPv6, and dual-stack to the end-host that they do not >> control. DS-Lite does not fit as well for a mobile phones since it >> would require a major change to the phone's OS. Second, DS-Lite >> requires tunneling as well as translation, so it is one more piece of >> overhead in addition to NAT64 solution. For me, i believe it is less >> complex to manage a single stack IPv6 host with NAT64 translation than >> a dual stack host, tunneling infrastructure, as well as NAT44 CGN, >> which is what DS-lite requires. They both achieve the same result, >> but I believe in the mobile space there is a quicker time to market as >> well as more progress toward the end-goal of IPv6-only using NAT64 >> than DS-lite. >> > I guess the choice here is between standing up and managing a NAT64 CGN > + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite > tunneling infrastructure (you'd be able to keep existing "vanilla" DNS > servers). > > As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable device without any modification. The DS-Lite Gateway does all the heavy lifting to provide IPv4 services and do the NAT64 translation between the IPv6-only end-user device (phone) and the IPv4 internet. Owen From andrew.wallace at rocketmail.com Sat Jan 16 05:42:56 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 16 Jan 2010 11:42:56 +0000 Subject: Anyone see a game changer here? In-Reply-To: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> Message-ID: <4b6ee9311001160342n3d076465re353cc9d938ccef2@mail.gmail.com> On Fri, Jan 15, 2010 at 2:07 PM, Bruce Williams wrote: > Mark Rasch, former head of the Department of Justice computer crime > unit, called the attacks ?cyberwarfare,? and said it was clearly an > escalation of a digital conflict between China and the U.S. > > As if the old threat models weren't bad enough... > > > Bruce It appears this is just western propaganda because: One analyst said Friday that he is not sure the attacks point to the Chinese government. Rob Knake, a cybersecurity expert with the Council on Foreign Relations, said his analysis of results from a technology firm investigating the attacks suggests that they "were not state-sponsored or the work of an elite, sophisticated group such as the Chinese military." http://www.washingtonpost.com/wp-dyn/content/article/2010/01/15/AR2010011503321.html Andrew From brunner at nic-naa.net Sat Jan 16 06:48:12 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 16 Jan 2010 07:48:12 -0500 Subject: Katrina response, private and public Message-ID: <4B51B58C.5050400@nic-naa.net> On 1/15/10 11:52 AM, Bill Woodcock wrote: > On Fri, 15 Jan 2010, Eric Brunner-Williams wrote: > > After the Katrina landfall a diverse group of wireless people started > > organizing a relief effort... > > There are quite a lot of us working on it, is there something specific > you're volunteering to do? > > -Bill > > > Thank you Bill, As I'm in Geneva this morning so the only thing I can share that is immediately accessible is the experience of living for four of the past five years off-grid. My best generator was the Honda 2000 watt, 120V, super quiet, 15 hours/gal unit. My second best was the (PRC knock-off) Pony 1000 Watt 120V super quiet. Everything begins at the generator. Gas is useful. For batteries a series of 6V AGM. A single 6V AGM can power a VSAT (HughesNet) for several hours. With three and even a 1000 watt 120V genset a VSAT link can be kept up a large part of 24/7. They are heavy and never pre-positioned (gensets aren't either), but they are the stable, long-term uptime must have. An efficient pure-sine wave inverter completes the electrical basic of a mobile programmer's electrical infrastructure. Non-pure-sine eats voltage and phase delta sensitive gear. Learning about Electrical Cost of Link Characteristics (ECLC, a low energy pun on the PILC WG abbreviation) was the most important thing I learned going off-grid. Some of these points are made within the larger ICT donor framework, at http://www.inveneo.org/download/Inveneo_ICT-Sustainability_Primer0809.pdf , the Inveneo ICT Sustainability Primer, which is worth the read (particularly on why "donated kit" and Windoz are wicked expensive to field), see pages 2 and 3. Things overlooked in the Inveneo paper is the role of portable generators, 6V battery management, and VSAT, which are what I see as the "off-grid" critical toolkit. I had educational and medical requirements in addition to my always-connected-to-my-racks-in-Maine needs. I'm wicked pleased to see the NSRC kit in route, and as I'm in Geneva I'll start on our IRC PoC and our own donor commit. When I get back to Cornell I'll start there too, as I know there is an interest at Cornell Law in the Maison des Infants de Dieu orphanage in Port au Prince. Eric From jimb at jsbc.cc Sat Jan 16 07:03:44 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 16 Jan 2010 05:03:44 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <4B4FA214.4030808@jsbc.cc> <4B513847.7090204@jsbc.cc> Message-ID: <4B51B930.8040407@jsbc.cc> On 1/15/2010 23:45, Owen DeLong wrote: > > On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote: > >> Sorry for late response here... >> >> On 1/14/2010 15:20, Cameron Byrne wrote: >>> On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell >> > wrote: >>> >>>> On 1/14/2010 11:10, Cameron Byrne wrote: >>>> >>>>> Folks, >>>>> >>>>> My question to the community is: assuming a network based IPv6 to IP4 >>>>> translator is in place (like NAT64 / DNS64), are IPv6-only Internet >>>>> services viable as a product today? In particular, would it be >>>>> appropriate for a 3G /smartphone or wireless broadband focused on at >>>>> casual (web and email) Internet users? Keep in mind, these users have >>>>> NAT44 today. >>>>> >>>>> >>>> You may also want to read up on Dual Stack Lite (DS-Lite) >>>> , >>>> >>> I have looked at DS-lite very carefully. First, DS-Lite fits better >>> for cable operators since they have CPE and can have a DS-lite >>> function in the CPE that they control, and that in turn allows them to >>> provide IPv4, IPv6, and dual-stack to the end-host that they do not >>> control. DS-Lite does not fit as well for a mobile phones since it >>> would require a major change to the phone's OS. Second, DS-Lite >>> requires tunneling as well as translation, so it is one more piece of >>> overhead in addition to NAT64 solution. For me, i believe it is less >>> complex to manage a single stack IPv6 host with NAT64 translation than >>> a dual stack host, tunneling infrastructure, as well as NAT44 CGN, >>> which is what DS-lite requires. They both achieve the same result, >>> but I believe in the mobile space there is a quicker time to market as >>> well as more progress toward the end-goal of IPv6-only using NAT64 >>> than DS-lite. >>> >> I guess the choice here is between standing up and managing a NAT64 CGN >> + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite >> tunneling infrastructure (you'd be able to keep existing "vanilla" DNS >> servers). >> >> > As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable > device > without any modification. The DS-Lite Gateway does all the heavy lifting > to provide IPv4 services and do the NAT64 translation between the > IPv6-only > end-user device (phone) and the IPv4 internet. > Could well be the case. My idea was that you could do it either way. You could have a DS-Lite gateway (Typical. Likely built into the "cable modem" or similar device), or in the case where no gateway is available, a DS-Lite "client" (basically a virtual nic/tunnel driver) on the machine would establish the tunnel and an IPv4 address itself. But perhaps this latter method was never intended? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From cb.list6 at gmail.com Sat Jan 16 08:01:13 2010 From: cb.list6 at gmail.com (Cam Byrne) Date: Sat, 16 Jan 2010 06:01:13 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <4B4FA214.4030808@jsbc.cc> <4B513847.7090204@jsbc.cc> Message-ID: <1263650473.2802.5.camel@Nokia-N900-42-11> ----- Original message ----- > > On Jan 15, 2010, at 7:53 PM, Jim Burwell wrote: > > > Sorry for late response here... > > > > On 1/14/2010 15:20, Cameron Byrne wrote: > > > On Thu, Jan 14, 2010 at 3:00 PM, Jim Burwell wrote: > > > > > > > On 1/14/2010 11:10, Cameron Byrne wrote: > > > > > > > > > Folks, > > > > > > > > > > My question to the community is:? assuming a network based IPv6 to IP4 > > > > > translator is in place (like NAT64 / DNS64), are IPv6-only Internet > > > > > services viable as a product today?? In particular, would it be > > > > > appropriate for a 3G /smartphone or wireless broadband focused on at > > > > > casual (web and email) Internet users?? Keep in mind, these users have > > > > > NAT44 today. > > > > > > > > > > > > > > You may also want to read up on Dual Stack Lite (DS-Lite) > > > > , > > > > > > > I have looked at DS-lite very carefully.? ? First, DS-Lite fits better > > > for cable operators since they have CPE and can have a DS-lite > > > function in the CPE that they control, and that in turn allows them to > > > provide IPv4, IPv6, and dual-stack to the end-host that they do not > > > control.? DS-Lite does not fit as well for a mobile phones since it > > > would require a major change to the phone's OS.? Second, DS-Lite > > > requires tunneling as well as translation, so it is one more piece of > > > overhead in addition to NAT64 solution.? For me, i believe it is less > > > complex to manage a single stack IPv6 host with NAT64 translation than > > > a dual stack host, tunneling infrastructure, as well as NAT44 CGN, > > > which is what DS-lite requires.? They both achieve the same result, > > > but I believe in the mobile space there is a quicker time to market as > > > well as more progress toward the end-goal of IPv6-only using NAT64 > > > than DS-lite. > > > > > I guess the choice here is between standing up and managing a NAT64 CGN > > + special DNS64 DNS server infrastructure, or a DS-Lite CGN + DS-Lite > > tunneling infrastructure (you'd be able to keep existing "vanilla" DNS > > servers). > > > > > As I understand DS-Lite, an IPv6-capable device is a DS-Lite capable device > without any modification.? The DS-Lite Gateway does all the heavy lifting > to provide IPv4 services and do the NAT64 translation between the IPv6-only > end-user device (phone) and the IPv4 internet. > > Owen ummm. An ipv6 device is not natively a ds-lite device. There is always a tunneling component which is generally after market client software (in the case of mobile devices) or some cpe function. If you are interested you can read the ietf draft. Assuming you have a ds-lite cpe, you can park dual-stack hosts behind it. But, it does not "just work" today like the demonstration i posted. > > From tony at lava.net Sat Jan 16 09:01:04 2010 From: tony at lava.net (Antonio Querubin) Date: Sat, 16 Jan 2010 05:01:04 -1000 (HST) Subject: Are IPv6-only Internet services viable today? In-Reply-To: <1263650473.2802.5.camel@Nokia-N900-42-11> References: <4B4FA214.4030808@jsbc.cc> <4B513847.7090204@jsbc.cc> <1263650473.2802.5.camel@Nokia-N900-42-11> Message-ID: On Sat, 16 Jan 2010, Cam Byrne wrote: > interested you can read the ietf draft. Assuming you have a ds-lite > cpe, you can park dual-stack hosts behind it. But, it does not "just If your hosts are dual-stacked, why would you need a ds-lite cpe in the first place? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From reygue at gmail.com Sat Jan 16 09:25:23 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Sat, 16 Jan 2010 10:25:23 -0500 Subject: News about the .HT domain In-Reply-To: <20100115164900.GA30469@sources.org> References: <20100115164900.GA30469@sources.org> Message-ID: <9ab36b821001160725m411ad9e1nf1e0d0c6d1aa7651@mail.gmail.com> Thank you Stephane. Max Larson Henry who is the technical contact has lost his house nad his mother in-law. So guys do all you can to have it up and running. Down here we are working to keep the remaining of the network up and running. But we might have some energy problem in the coming days. Reynold Guerrier AHTIC Treasurer On Fri, Jan 15, 2010 at 11:49 AM, Stephane Bortzmeyer wrote: > I have no information about the state of the Internet links in Haiti > (everything seems down) but, for the .HT top-level domain, here are a > few news. > > .HT has six name servers, four outside of the country. They were not > affected so .HT never had a problem resolving. Main DNS lesson: always > put name servers in very diverse places. > > The master was in Port-au-Prince and is unreachable, probably for a > long time. A new (stealth) master has been set up in Australia by > Cocca and the slaves are now reconfigured to use it. Two already do it > and therefore the zone no longer risks expiration (and can even be > modified). > > You may find information at . > > % check_soa ht > There was no response from ns2.nic.ht > There was no response from ns1.nic.ht > dns.princeton.edu has serial number 2010011198 > charles.cdec.polymtl.ca has serial number 2010011198 > ht-ns.anycast.pch.net has serial number 2010011615 > ns3.nic.fr has serial number 2010011615 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iD8DBQFLUJx8QTZHl5fW0kYRAsgwAJ9pZ26tNlxHpBkLNKvy9HgjIWCK6gCfYBOq > 5VCVBIVyiUdAOwDxPzKBphE= > =B1vY > -----END PGP SIGNATURE----- > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From jgreco at ns.sol.net Sat Jan 16 09:36:45 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 16 Jan 2010 09:36:45 -0600 (CST) Subject: Anyone see a game changer here? In-Reply-To: <4b6ee9311001160342n3d076465re353cc9d938ccef2@mail.gmail.com> from "andrew.wallace" at Jan 16, 2010 11:42:56 AM Message-ID: <201001161536.o0GFaja0028086@aurora.sol.net> > On Fri, Jan 15, 2010 at 2:07 PM, Bruce Williams > wrote: > > Mark Rasch, former head of the Department of Justice computer crime > > unit, called the attacks ?cyberwarfare,? and said it was clearly an > > escalation of a digital conflict between China and the U.S. > > > > As if the old threat models weren't bad enough... > > > > > > Bruce > > It appears this is just western propaganda because: > > One analyst said Friday that he is not sure the attacks point to the > Chinese government. Rob Knake, a cybersecurity expert with the Council > on Foreign Relations, said his analysis of results from a technology > firm investigating the attacks suggests that they "were not > state-sponsored or the work of an elite, sophisticated group such as > the Chinese military." > > http://www.washingtonpost.com/wp-dyn/content/article/2010/01/15/AR2010011503321.html It's kind of a stretch to go calling it "western propaganda" just because one cybersecurity expert "is not sure". If another cybersecurity expert suggested that it seemed possible that little green men might be responsible for the attacks, would you suddenly believe in Martians? There is almost always someone who will take up an opposing point of view. It's certainly good to keep in mind that there's a margin for error in these sorts of things. However, it's also smart to keep in mind that a large number of people have looked at this issue, most certainly including a slew of experts from the government, who would have had to agree with the China assessment prior to the State Department decision to issue a formal protest. ... 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 reygue at gmail.com Sat Jan 16 09:43:39 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Sat, 16 Jan 2010 10:43:39 -0500 Subject: Katrina response, private and public In-Reply-To: <4B508C67.5000309@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> Message-ID: <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> Guys The buggest issues in the 2 coming days will be energy. And I can't assure that we will be able to get fuel for the generator. Equipment with Solar energy will be our best shot. Reynold Guerrier AHTIC Treasurer Network Engineer Haiti Earthquake Survivor On Fri, Jan 15, 2010 at 10:40 AM, Eric Brunner-Williams wrote: > Folks, > > After the Katrina landfall a diverse group of wireless people started > organizing a relief effort, culminating in work around Waveland. There was > also a group from the NPGS in Monterey, who worked on the Boxing Day Tsunami > aftermath. > > Does anyone have a similar contact set? > > Eric > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From cb.list6 at gmail.com Sat Jan 16 09:52:02 2010 From: cb.list6 at gmail.com (Cam Byrne) Date: Sat, 16 Jan 2010 07:52:02 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <4B4FA214.4030808@jsbc.cc> <4B513847.7090204@jsbc.cc> <1263650473.2802.5.camel@Nokia-N900-42-11> Message-ID: <1263657122.2995.6.camel@Nokia-N900-42-11> ----- Original message ----- > On Sat, 16 Jan 2010, Cam Byrne wrote: > > > interested you can read the ietf draft.? Assuming you have a ds-lite > > cpe, you can park dual-stack hosts behind it.? But, it does not "just > > If your hosts are dual-stacked, why would you need a ds-lite cpe in the > first place? A dual-stack capable host like windows 7 does not ensure any ipv6 network access beyond the local LAN, especially given todays ipv4-only service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp:? tony at lava.net From kmedcalf at dessus.com Sat Jan 16 10:34:45 2010 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 16 Jan 2010 11:34:45 -0500 Subject: Anyone see a game changer here? In-Reply-To: <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> Message-ID: <32700f35d82ebe459c71ece88c62d46b@mail.dessus.com> >Personally I was amused at people adding cement to USB ports to mitigate >against the "removable media threat". The issue I see is people forget >that floppies posed the same threat back in the day. Do you mean the "AutoRun" threat, since this sort of thing is usually done by people who (a) run M$ Winders and (b) do not know how to turn off the really annoying "helpful" features created by the clueless idiots in Redmond ... and those idiots keep on creating more and more security hole "features" that have to be disabled. Someone should tell the idiots who design API's that API's are designed to be used -- and they will be used to do what it was designed to do -- and if that design constitutes a security flaw, then it will be used as such and the only solution is to stop designing stupid APIs. The most laughable example is the creation of API hooks into the kernel for use by AntiVirus vendors. Unfortunately, these APIs can, by their very definition, be used by anyone who wants for any purpose they desire. Personally I would prefer a secure kernel that cannot be tampered with or compromised by anyone. Adding a deliberately designed security flaw to enable a third party to stay in business providing a partial plug for the deliberately designed hole is utter lunacy! Back to removable media, AutoRun is, and always has been, completely trivial to completely, utterly and irrevocably disable -- and I have been doing so since, well, since this idiotic mis-feature first appeared somewhere in the early 90's. The same applies to other crap-ware vectors such as Flash. Just because some people are slow or do not pay attention to what has been going on in the world for 20 years on, does not make these "new". Its like dogs -- they have been around for thousands of years. Some people just don't notice that they have teeth until they, through their own stupidity, get bitten by one. Now, back to your regularly scheduled programming ... From gbonser at seven.com Sat Jan 16 13:46:02 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 16 Jan 2010 11:46:02 -0800 Subject: Anyone see a game changer here? In-Reply-To: <4b6ee9311001160342n3d076465re353cc9d938ccef2@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <4b6ee9311001160342n3d076465re353cc9d938ccef2@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F729A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: andrew.wallace > It appears this is just western propaganda because: > > One analyst said Friday that he is not sure the attacks point to the > Chinese government. Rob Knake, a cybersecurity expert with the Council > on Foreign Relations, said his analysis of results from a technology > firm investigating the attacks suggests that they "were not > state-sponsored or the work of an elite, sophisticated group such as > the Chinese military." > > http://www.washingtonpost.com/wp- > dyn/content/article/2010/01/15/AR2010011503321.html > > Andrew At some point, due to fundamental human nature, it doesn't matter if a government is doing it or not. Imagine if private citizens of one country were shooting at the citizens of another country across the border while the army stood by and simply watched. The country on the receiving end asks for it to stop but the country where the shooting is originating from says "hey, we aren't doing it! It is originating from our country but it isn't the government doing it" where the receiving side says "I don't care who is doing it, please make them stop." It can be damaging to a country's or network operator's reputation as a good neighbor if they allow such chaos to continue without doing anything about it. In many other countries where governments exert less control, the network operators themselves often police their users by disconnecting those who are seen to engage in such activities. A network operator who refuses to cooperate is often seen by their peers as somehow "rogue" and may be shunned by the community. The point is that it doesn't matter who is at the keyboard or who is coding the malware. If they are enabled by their network operator or government looking the other way, then it is a natural tendency for people to instinctively hold them partially responsible for the conduct as being complicit in it. And that isn't anything unique with China in particular, the same thing goes for a network operator or government anywhere on the planet. I think in this case because China does exercise a lot of control over their network traffic, there is a natural tendency for people to become frustrated when they get the feeling that the government is doing nothing to stop this sort of traffic while other types of traffic are vigorously policed. So the next question would be, to what extent do the various network operators in China assist in disconnecting the sources of such traffic? I think I already know the answer. From brunner at nic-naa.net Sat Jan 16 16:36:24 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 16 Jan 2010 17:36:24 -0500 Subject: Katrina response, private and public In-Reply-To: <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> Message-ID: <4B523F68.6080305@nic-naa.net> At around noon, Eastern, the State Department was provided with information on the fuel situation at the Port au Prince NAP, which has used 2/3rds of the available diesel (8gal/hour run rate, 160 gal remaining) keeping the microwave backhaul to the DR up, and all remaining governmental and NGO network access. Eric On 1/16/10 10:43 AM, Reynold Guerrier wrote: > Guys > > The buggest issues in the 2 coming days will be energy. And I can't > assure that we will be able to get fuel for the generator. Equipment > with Solar energy will be our best shot. > > > Reynold Guerrier > AHTIC > Treasurer > Network Engineer > Haiti Earthquake Survivor > > On Fri, Jan 15, 2010 at 10:40 AM, Eric Brunner-Williams > > wrote: > > Folks, > > After the Katrina landfall a diverse group of wireless people > started organizing a relief effort, culminating in work around > Waveland. There was also a group from the NPGS in Monterey, who > worked on the Boxing Day Tsunami aftermath. > > Does anyone have a similar contact set? > > Eric > > > > > -- > =================================== > Reynold Guerrier > IT Consultant > 509-3446-0099 > IM: reygue at hotmail.com > Skype: reygji From jimb at jsbc.cc Sat Jan 16 18:01:47 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 16 Jan 2010 16:01:47 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <4B4FA214.4030808@jsbc.cc> <4B513847.7090204@jsbc.cc> <1263650473.2802.5.camel@Nokia-N900-42-11> Message-ID: <4B52536B.7000608@jsbc.cc> On 1/16/2010 07:01, Antonio Querubin wrote: > On Sat, 16 Jan 2010, Cam Byrne wrote: > >> interested you can read the ietf draft. Assuming you have a ds-lite >> cpe, you can park dual-stack hosts behind it. But, it does not "just > > If your hosts are dual-stacked, why would you need a ds-lite cpe in > the first place? > The point of DS-Lite is to provide IPv4 internet access to hosts which only have IPv6 addresses in an IPv6 only network environment. That is, IPv4 connectivity isn't available all the way through to the provider's CGN. If you did straight dual-stack, the provider would have to do IPv4 connectivity all the way to the CGN, and also maintain unique RFC1918 IP address assignments to every customer going through a particular CGN. With DS-Lite, the IPv4 traffic is tunneled from a DS-Lite router fronting the customer's LAN, or from a host itself (a presumption) running some sort of DS-Lite driver. Because the traffic can by identified by the CGN from the tunnel it came in on, the RFC1918s don't have to be unique (the customer can pick whatever he wants for his/her LAN). A full DS network isn't needed throughout the entire provider infrastructure, hence the name DS "Lite". -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From netfortius at gmail.com Sun Jan 17 08:10:05 2010 From: netfortius at gmail.com (Stefan) Date: Sun, 17 Jan 2010 08:10:05 -0600 Subject: AT&T planned maintenance - country-wide - MPLS?!? Message-ID: Our NOC reported at 2:00AM MPLS "blips" on some of our networks because of AT&T stating that?"there is currently country-wide planned maintenance that is affecting a large number of circuits, he [AT&T person answering the request for clarification] did not clarify which ones." We have received no communication in this regard. Anybody else knowing anything about this? Thank you, ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From alain_durand at cable.comcast.com Sun Jan 17 08:43:44 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Sun, 17 Jan 2010 09:43:44 -0500 Subject: Are IPv6-only Internet services viable today? In-Reply-To: <4B51B930.8040407@jsbc.cc> Message-ID: On 1/16/10 8:03 AM, "Jim Burwell" wrote: > Could well be the case. My idea was that you could do it either way. > You could have a DS-Lite gateway (Typical. Likely built into the "cable > modem" or similar device), or in the case where no gateway is available, > a DS-Lite "client" (basically a virtual nic/tunnel driver) on the > machine would establish the tunnel and an IPv4 address itself. But > perhaps this latter method was never intended? You mean, tunnel directly to the end host? We have been thinking about extensions to allow that 'short-cut', AFTR-less mode. It is doable if you can establish a 1 to 1 mapping between the IPv4 and the IPv6 address **and** you find a way for host A to figure out host B's IPv4 and IPv6 addresses... - Alain. From alain_durand at cable.comcast.com Sun Jan 17 09:04:32 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Sun, 17 Jan 2010 10:04:32 -0500 Subject: Are IPv6-only Internet services viable today? In-Reply-To: <1263657122.2995.6.camel@Nokia-N900-42-11> Message-ID: On 1/16/10 10:52 AM, "Cam Byrne" wrote: > >A dual-stack capable host like windows 7 does not ensure any ipv6 network access beyond the local LAN, especially given todays ipv4-only >service dominance. There are various ways to translate or tunnel to solve this problem, connecting v6 and v4 islands, including nat64 and ds-lite ===> Well, it all depends on which applications are in use. If the app running on the windows 7 side only works in IPv4 or if the app on the other side is only serving IPv4, there is little choice but to tunnel IPv4 over IPv6 in the middle. See, for many years, when we were thinking about IPv4/IPv6 transition, we looked at it a stack issue. I think we were missing something. We now have seen tons of IPv6 capable stacks (Win XP, Vista, 7, MacOS, Linux, Solaris,...) and still very little apps that take advantage of this, either on the client side, or on the content side. Just ask how many of the 100,000+ apps on the iPhone are IPv6 ready... Btw, on the content side, the situation is quite complex too, because it is not just about configuring apache for IPv6, this is about having a load balancing, content delivery, monitoring,... solution in place. What DS-lite gives you is the ability to de-couple the deployment of the network (including the host stacks) with IPv6 from the deployment of the applications with IPv6. I do believe there is a lot of value in this. > > - Alain. On 1/16/10 10:52 AM, "Cam Byrne" wrote: > > A dual-stack capable host like windows 7 does not ensure any ipv6 network > access beyond the local LAN, especially given todays ipv4-only service > dominance. There are various ways to translate or tunnel to solve this > problem, connecting v6 and v4 islands, including nat64 and ds-lite > > From cb.list6 at gmail.com Sun Jan 17 10:59:00 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 17 Jan 2010 08:59:00 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <1263657122.2995.6.camel@Nokia-N900-42-11> Message-ID: It's unfortunate for me that nobody is interested in talking about the question I asked in light of the data i supplied. The question being, is it possible for a mobile operator to offer an IPv6-only service today to casual Internet users on new devices with new service plans? Perhaps it is just a rhetorical question because the video obviously shows it is possible. But, i am legitimately interested in perceived service gaps or issues, given this tightly controlled service definition (web and email). On Sun, Jan 17, 2010 at 7:04 AM, Durand, Alain wrote: > On 1/16/10 10:52 AM, "Cam Byrne" wrote: >> >>A dual-stack capable host like windows 7 does not ensure any ipv6 network >> access beyond the local LAN, especially given todays ipv4-only >service >> dominance. ?There are various ways to translate or tunnel to solve this >> problem, connecting v6 and v4 islands, including nat64 and ds-lite > > ===> Well, it all depends on which applications are in use. If the app > running on the windows 7 side only works in IPv4 or if the app on the other > side is only serving IPv4, there is little choice but to tunnel IPv4 over > IPv6 in the middle. Once again, the focus is our ability to deploy today. DS-lite is not here today in off-the-shelf support. It's not a core part of Windows 7 or Android. And, the focus is 90% of my users, not 1% that are running windows 98 or Citrix clients. > > See, for many years, when we were thinking about IPv4/IPv6 transition, we > looked at it a stack issue. I think we were missing something. We now have > seen tons of IPv6 capable stacks (Win XP, Vista, 7, MacOS, Linux, > Solaris,...) and still very little apps that take advantage of this, either All the major web and email apps do IPv6 today (Outlook, IE, Firefox, Chrome, Thunderbird ...), and i don't believe i need to support all the legacy apps, i do have the ability to define explicit terms and conditions of the service. Once gain, i am looking at 90% of my users, not 1%. And, I am further saying that this service would be sold for new devices (new smartphones, new netbooks ...), not legacy devices. I understand your world may be different. > on the client side, or on the content side. Just ask how many of the > 100,000+ apps on the iPhone are IPv6 ready... Btw, on the content side, the > situation is quite complex too, because it is not just about configuring > apache for IPv6, this is about having a load balancing, content delivery, > monitoring,... solution in place. I call FUD. On the app side, how many of those iphone apps just call the web browser or in-built email client? .... such that enabling a few common core elements make the majority of the ecosystem IPv6 enabled. I believe Fred Baker has said that the iphone apps store is an example of IPv6 success in the making -- Quoting: "As to applications, yes, of course. In point of fact, many applications have already been ported to IPv6 and operate just fine. I understand that Apple made a requirement that applications on the iPhone must be IPv6-capable, and as a result several tens of thousands of applications are in fact IPv6-capable." http://www.ietf.org/mail-archive/web/3gv6/current/msg00021.html On the content side, please... How many NANOGs in a row do major players like Google, Netflix, Limelight and others trot on stage and tell us how easy it is to roll out IPv6? I have done content proof of concepts in my lab, enabling my intranet for IPv6 via a VIP on loadbalancer, it took about 45 minutes to figure it out and works flawlessly. Many major load balancer vendors take care of the dirty work for us, such that putting an IPv6 face to the world is easy. The fact that the server is technically IPv4 and the the load balancer is doing protocol translation / proxying is irrelevant and steady-state for the overall architecture in terms of where network state is located. Further, given the consolidation of content to a few major players (2009 Internet Observatory Report), moving IPv6 from where it is today to where it needs to be is getting easier. If Google is ~20% of your traffic, you are already 1/5 the way to being native IPv6. > > What DS-lite gives you is the ability to de-couple the deployment of the > network (including the host stacks) with IPv6 from the deployment of the > applications with IPv6. I do believe there is a lot of value in this. Yes, value in some environments. Once again, I am not trying to have a religious war. I am just to trying to explore a simple question for my environment based on facts. Thanks for this discussion. -Cameron > > ???- Alain. > > > On 1/16/10 10:52 AM, "Cam Byrne" wrote: > > A dual-stack capable host like windows 7 does not ensure any ipv6 network > access beyond the local LAN, especially given todays ipv4-only service > dominance. ?There are various ways to translate or tunnel to solve this > problem, connecting v6 and v4 islands, including nat64 and ds-lite > > > From bicknell at ufp.org Sun Jan 17 12:01:17 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 17 Jan 2010 10:01:17 -0800 Subject: Are IPv6-only Internet services viable today? In-Reply-To: References: <1263657122.2995.6.camel@Nokia-N900-42-11> Message-ID: <20100117180117.GA26757@ussenterprise.ufp.org> In a message written on Sun, Jan 17, 2010 at 08:59:00AM -0800, Cameron Byrne wrote: > It's unfortunate for me that nobody is interested in talking about the > question I asked in light of the data i supplied. The question being, > is it possible for a mobile operator to offer an IPv6-only service > today to casual Internet users on new devices with new service plans? Yes it is possible. Yes you will exclude some segment of customers today. > Perhaps it is just a rhetorical question because the video obviously > shows it is possible. But, i am legitimately interested in perceived > service gaps or issues, given this tightly controlled service > definition (web and email). I think the phones stopped being "tightly controlled" with the iPhone and Android phones. They expect generic IP connectivty, and are very much not web and e-mail only. Moreso than an IPv6 only provider, a web and e-mail only provider would probbaly find themselves at a huge disadvantage to a significant and growing segment of the market. -- 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: 826 bytes Desc: not available URL: From Jon.Kibler at aset.com Sun Jan 17 12:46:21 2010 From: Jon.Kibler at aset.com (Jon Kibler) Date: Sun, 17 Jan 2010 13:46:21 -0500 Subject: Yahoo Postmaster Contact Message-ID: <4B535AFD.7030106@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Will a Yahoo Postmaster please contact me off list? No one is responding to my web based complaints about Yahoo dropping email we are sending to our own staff's Yahoo email accounts. TIA! Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o/c/s: 843-849-8214 / 843-813-2924 / 843-564-4224 e: Jon.Kibler at aset.com or Jon.R.Kibler at gmail.com s: JonRKibler http://www.linkedin.com/in/jonrkibler 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/ iEYEARECAAYFAktTWv0ACgkQUVxQRc85QlNwjACfQ13IYf08/LLjqZo0Bg9QQ9WE 5J0AnAsRk9uajgbm/hV2j1wOrU7ED78D =MVEN -----END PGP SIGNATURE----- From andy at nosignal.org Sun Jan 17 13:16:58 2010 From: andy at nosignal.org (Andy Davidson) Date: Sun, 17 Jan 2010 19:16:58 +0000 Subject: Virbl: The First IPv6 enabled dnsbl? In-Reply-To: <757220502.276.1263619845706.JavaMail.root@lordsofacid.wiztech.biz> References: <757220502.276.1263619845706.JavaMail.root@lordsofacid.wiztech.biz> Message-ID: On 16 Jan 2010, at 05:30, Tammy A. Wisdom wrote: > Mark Schouten wrote: >> http://virbl.bit.nl/index.php#ipv6 >> Comments on the listing method are appreciated. > wow bind? thats gonna get slower and slower and slower. I hope you have a TON of ram for that box. for example > if we loaded the current contents of the ahbl from rbldnsd to bind it would take up a TON of ram. bind would take forever to load and and would be screaming for its dear life. These problems tend to have a way of solving themselves... This dnsbl is trying to get experience handling v6 data in an anti-spam environment. We do not know how to do that today - and this is a problem which only reduces with experience. The problems of how to scale it, to me seem like a smaller challenge. There are enough clever people who understand how to scale specific dns issues. :-) Good luck to the team at Virbl ! Andy From brunner at nic-naa.net Sun Jan 17 17:02:35 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 17 Jan 2010 18:02:35 -0500 Subject: Katrina response, private and public In-Reply-To: <4B523F68.6080305@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net> Message-ID: <4B53970B.7050600@nic-naa.net> As of this hour Reynold Guerrier has managed to obtain 56 gallons of diesel, moving the NAP's dry tank fail point some 8 hours, into the morning of the 18th. No other fuel has been delivered to the NAP. The SitRep of the 16th to the State Department has just been updated with information current as of this hour. Eric On 1/16/10 5:36 PM, Eric Brunner-Williams wrote: > At around noon, Eastern, the State Department was provided with > information on the fuel situation at the Port au Prince NAP, which has > used 2/3rds of the available diesel (8gal/hour run rate, 160 gal > remaining) keeping the microwave backhaul to the DR up, and all > remaining governmental and NGO network access. > > Eric > > On 1/16/10 10:43 AM, Reynold Guerrier wrote: >> Guys >> >> The buggest issues in the 2 coming days will be energy. And I can't >> assure that we will be able to get fuel for the generator. Equipment >> with Solar energy will be our best shot. >> >> >> Reynold Guerrier >> AHTIC >> Treasurer >> Network Engineer >> Haiti Earthquake Survivor >> >> On Fri, Jan 15, 2010 at 10:40 AM, Eric Brunner-Williams >> > wrote: >> >> Folks, >> >> After the Katrina landfall a diverse group of wireless people >> started organizing a relief effort, culminating in work around >> Waveland. There was also a group from the NPGS in Monterey, who >> worked on the Boxing Day Tsunami aftermath. >> >> Does anyone have a similar contact set? >> >> Eric >> >> >> >> >> -- >> =================================== >> Reynold Guerrier >> IT Consultant >> 509-3446-0099 >> IM: reygue at hotmail.com >> Skype: reygji > > > > From alain_durand at cable.comcast.com Sun Jan 17 17:47:19 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Sun, 17 Jan 2010 18:47:19 -0500 Subject: Are IPv6-only Internet services viable today? In-Reply-To: Message-ID: On 1/17/10 11:59 AM, "Cameron Byrne" wrote: > It's unfortunate for me that nobody is interested in talking about the > question I asked in light of the data i supplied. The question being, > is it possible for a mobile operator to offer an IPv6-only service > today to casual Internet users on new devices with new service plans? > Perhaps it is just a rhetorical question because the video obviously > shows it is possible. But, i am legitimately interested in perceived > service gaps or issues, given this tightly controlled service > definition (web and email). I would hope my last emails start to address this point. The single most impediment I see to deploy IPv6-only networks is the combined effect of the 2 long tails: on one side, the content is today mostly IPv4-only accessible, making it a disincentive to build v6-only access network, and on the other side, the apps are for the vast majority IPv4 centric, making it a disincentive to offer content over IPv6, to build an Ipv6 capable device that cannot use those apps or to build v6-only access networks in the first place... This realization was the starting point of the development of the DS-lite technology. - Alain. From alain_durand at cable.comcast.com Sun Jan 17 17:54:02 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Sun, 17 Jan 2010 18:54:02 -0500 Subject: Are IPv6-only Internet services viable today? In-Reply-To: <20100117180117.GA26757@ussenterprise.ufp.org> Message-ID: On 1/17/10 1:01 PM, "Leo Bicknell" wrote: But, i am legitimately interested in perceived >> service gaps or issues, given this tightly controlled service >> definition (web and email). > > I think the phones stopped being "tightly controlled" with the > iPhone and Android phones. They expect generic IP connectivty, and > are very much not web and e-mail only. Moreso than an IPv6 only > provider, a web and e-mail only provider would probbaly find > themselves at a huge disadvantage to a significant and growing > segment of the market. +1 I made a number of demonstration of mail and web service on an IPv6-only workstation back in early 2000, in my Solaris days. Even ten years ago, it was clear this would not be enough... - Alain. From nathan at atlasnetworks.us Sun Jan 17 21:22:33 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 17 Jan 2010 19:22:33 -0800 Subject: Katrina response, private and public In-Reply-To: <4B53970B.7050600@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>,<4B53970B.7050600@nic-naa.net> Message-ID: <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> Isn't there a US destroyer taskforce off the coast now? One would think they'd have a supply of diesel available. Best Regards, Nathan Eisenberg ________________________________________ From: Eric Brunner-Williams [brunner at nic-naa.net] Sent: Sunday, January 17, 2010 3:02 PM To: nanog at nanog.org Subject: Re: Katrina response, private and public As of this hour Reynold Guerrier has managed to obtain 56 gallons of diesel, moving the NAP's dry tank fail point some 8 hours, into the morning of the 18th. No other fuel has been delivered to the NAP. The SitRep of the 16th to the State Department has just been updated with information current as of this hour. Eric On 1/16/10 5:36 PM, Eric Brunner-Williams wrote: > At around noon, Eastern, the State Department was provided with > information on the fuel situation at the Port au Prince NAP, which has > used 2/3rds of the available diesel (8gal/hour run rate, 160 gal > remaining) keeping the microwave backhaul to the DR up, and all > remaining governmental and NGO network access. > > Eric > > On 1/16/10 10:43 AM, Reynold Guerrier wrote: >> Guys >> >> The buggest issues in the 2 coming days will be energy. And I can't >> assure that we will be able to get fuel for the generator. Equipment >> with Solar energy will be our best shot. >> >> >> Reynold Guerrier >> AHTIC >> Treasurer >> Network Engineer >> Haiti Earthquake Survivor >> >> On Fri, Jan 15, 2010 at 10:40 AM, Eric Brunner-Williams >> > wrote: >> >> Folks, >> >> After the Katrina landfall a diverse group of wireless people >> started organizing a relief effort, culminating in work around >> Waveland. There was also a group from the NPGS in Monterey, who >> worked on the Boxing Day Tsunami aftermath. >> >> Does anyone have a similar contact set? >> >> Eric >> >> >> >> >> -- >> =================================== >> Reynold Guerrier >> IT Consultant >> 509-3446-0099 >> IM: reygue at hotmail.com >> Skype: reygji > > > > From brunner at nic-naa.net Sun Jan 17 23:37:20 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 18 Jan 2010 00:37:20 -0500 Subject: Katrina response, private and public In-Reply-To: <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> Message-ID: <4B53F390.4040007@nic-naa.net> There are significant US naval and land assets in place. However, resupply to the NAP/microwave backhaul out of the FERA (Front Edge Rescue Area, to delta off the usual FEBA acronym) and local government data communications continuity apparently aren't on the first day task order, nor any subsequent day's task order. Drill. Drill Now. Drill Baby Drill. Palin may be insane, but skipping on emergency procedures and drills, which at least one government has done, is not sane. (Doing something twice, e.g., failure to prepare for Katrina class events, and expecting a different outcome measure of sanity.) Eric On 1/17/10 10:22 PM, Nathan Eisenberg wrote: > Isn't there a US destroyer taskforce off the coast now? One would think they'd have a supply of diesel available. > > Best Regards, > Nathan Eisenberg > ________________________________________ > From: Eric Brunner-Williams [brunner at nic-naa.net] > Sent: Sunday, January 17, 2010 3:02 PM > To: nanog at nanog.org > Subject: Re: Katrina response, private and public > > As of this hour Reynold Guerrier has managed to obtain 56 gallons of > diesel, moving the NAP's dry tank fail point some 8 hours, into the > morning of the 18th. > > No other fuel has been delivered to the NAP. The SitRep of the 16th to > the State Department has just been updated with information current as > of this hour. > > Eric > > On 1/16/10 5:36 PM, Eric Brunner-Williams wrote: >> At around noon, Eastern, the State Department was provided with >> information on the fuel situation at the Port au Prince NAP, which has >> used 2/3rds of the available diesel (8gal/hour run rate, 160 gal >> remaining) keeping the microwave backhaul to the DR up, and all >> remaining governmental and NGO network access. >> >> Eric >> >> On 1/16/10 10:43 AM, Reynold Guerrier wrote: >>> Guys >>> >>> The buggest issues in the 2 coming days will be energy. And I can't >>> assure that we will be able to get fuel for the generator. Equipment >>> with Solar energy will be our best shot. >>> >>> >>> Reynold Guerrier >>> AHTIC >>> Treasurer >>> Network Engineer >>> Haiti Earthquake Survivor >>> >>> On Fri, Jan 15, 2010 at 10:40 AM, Eric Brunner-Williams >>> > wrote: >>> >>> Folks, >>> >>> After the Katrina landfall a diverse group of wireless people >>> started organizing a relief effort, culminating in work around >>> Waveland. There was also a group from the NPGS in Monterey, who >>> worked on the Boxing Day Tsunami aftermath. >>> >>> Does anyone have a similar contact set? >>> >>> Eric >>> >>> >>> >>> >>> -- >>> =================================== >>> Reynold Guerrier >>> IT Consultant >>> 509-3446-0099 >>> IM: reygue at hotmail.com >>> Skype: reygji >> >> >> >> > > > > > > > From wade.peacock at sunwave.net Mon Jan 18 09:35:22 2010 From: wade.peacock at sunwave.net (Wade Peacock) Date: Mon, 18 Jan 2010 07:35:22 -0800 Subject: Network Provider Recommendation in Edmonton AB In-Reply-To: <894ad1e23fc60ce28226727bd19ab1fd@yyc.orthanc.ca> References: <894ad1e23fc60ce28226727bd19ab1fd@yyc.orthanc.ca> Message-ID: <4B547FBA.4080602@sunwave.net> Have you tried contacting Shaw Business Solutions (Formally BigPipe Inc) or Bell (GT /360 Networks) or even Telus? I would expect that all should be able to provide symmetric (non cable or adsl) solution. Wade Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > I have a client in Edmonton who's looking for a network drop to their > office, something in the 2-10 MB/s range. The location is at 46 Ave. > and 99 St. > > The core requirement is for a bare unfiltered *symmetric* pipe (no > ADSL). Traffic volume will be low: 2-4 laptop VPNs plus some light > web server and email traffic. 2 Mb/s as a lower bound should be fine, > with a /28 IPv4 address block (either bridged or routed). > > I've been away from Edmonton long enough now that I no longer know > who's active there, so any and all feedback is welcome. (Vendors, > too, provided you include some real content.) Please respect the > Reply-To header. > > Cheers, > > --lyndon > > From eric.rosenberry at iovation.com Mon Jan 18 16:27:30 2010 From: eric.rosenberry at iovation.com (Rosenberry, Eric) Date: Mon, 18 Jan 2010 14:27:30 -0800 Subject: New netblock Geolocate wrong (Google) Message-ID: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> I just lit up a new IP netblock (assigned directly from ARIN) and the companies that provide Geolocate databases do not have the correct location information available yet. Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada and IP2LOCATION (http://www.ip2location.com/) has no data. For the most part this is benign or at worst slightly impacting since I often get redirected to global load balance nodes up in Canada instead of locally in the North West, however, the more major issue I am running into is that Google chooses to redirect all my users to www.google.ca. So my questions to others are: 1. How do I get my data updated in all of the geolocate providers databases as quickly as possible? 2. What geolocate database does Google use (is it homegrown?) and how do I get them to update my data? Thanks. -Eric _______________________________________________________________ Eric Rosenberry Sr. Network Engineer | Chief Bit Plumber iovation 111 SW Fifth Avenue Suite 3200 Portland, OR 97204 www.iovation.com The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. From lists at explosivemind.org Mon Jan 18 16:49:49 2010 From: lists at explosivemind.org (Olaf Baumert) Date: Mon, 18 Jan 2010 23:49:49 +0100 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> Message-ID: <20100118224946.GA13215@obnh.org> Hi Eric, On 18/01/10 14:27 -0800, Rosenberry, Eric wrote: > So my questions to others are: > 1. How do I get my data updated in all of the geolocate providers databases as quickly as possible? > 2. What geolocate database does Google use (is it homegrown?) and how do I get them to update my data? from past questions here i recall http://nanog.cluepon.net/index.php/GeoIP which leads to http://www.google.com/support/websearch/bin/request.py?contact_type=ip for google and others as well. Regards, Olaf -- Olaf Baumert - https://baumert.eu - olaf at baumert.eu work +49 231 9721335 private +49 231 5702579 cell +49 172 5654177 From darcy at druid.net Mon Jan 18 17:42:23 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Mon, 18 Jan 2010 18:42:23 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> Message-ID: <20100118184223.ed2d2762.darcy@druid.net> On Mon, 18 Jan 2010 14:27:30 -0800 "Rosenberry, Eric" wrote: > I just lit up a new IP netblock (assigned directly from ARIN) and the companies that provide Geolocate databases do not have the correct location information available yet. > > Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada and IP2LOCATION (http://www.ip2location.com/) has no data. > > For the most part this is benign or at worst slightly impacting since I often get redirected to global load balance nodes up in Canada instead of locally in the North West, however, the more major issue I am running into is that Google chooses to redirect all my users to www.google.ca. You may also find that certain things are unavailable to your users. Sometimes sheet music or books are only available in the US for copyright reasons. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From tim at broadlinenetworks.com Mon Jan 18 17:37:09 2010 From: tim at broadlinenetworks.com (Tim Lampman) Date: Mon, 18 Jan 2010 18:37:09 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <20100118184223.ed2d2762.darcy@druid.net> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <20100118184223.ed2d2762.darcy@druid.net> Message-ID: <4B54F0A5.1000500@broadlinenetworks.com> Services such as Hulu could also be affected, certain youtube files even. D'Arcy J.M. Cain wrote: > On Mon, 18 Jan 2010 14:27:30 -0800 > "Rosenberry, Eric" wrote: > >> I just lit up a new IP netblock (assigned directly from ARIN) and the companies that provide Geolocate databases do not have the correct location information available yet. >> >> Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada and IP2LOCATION (http://www.ip2location.com/) has no data. >> >> For the most part this is benign or at worst slightly impacting since I often get redirected to global load balance nodes up in Canada instead of locally in the North West, however, the more major issue I am running into is that Google chooses to redirect all my users to www.google.ca. >> > > You may also find that certain things are unavailable to your users. > Sometimes sheet music or books are only available in the US for > copyright reasons. > > -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *p.* 1-866-546-8486 *c.* 905-746-3114 www.broadlinenetworks.com | tim at broadlinenetworks.com From warren at kumari.net Mon Jan 18 19:22:34 2010 From: warren at kumari.net (Warren Kumari) Date: Mon, 18 Jan 2010 20:22:34 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> Message-ID: <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> On Jan 18, 2010, at 5:27 PM, Rosenberry, Eric wrote: > I just lit up a new IP netblock (assigned directly from ARIN) and the companies that provide Geolocate databases do not have the correct location information available yet. > > Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada and IP2LOCATION (http://www.ip2location.com/) has no data. > > For the most part this is benign or at worst slightly impacting since I often get redirected to global load balance nodes up in Canada instead of locally in the North West, however, the more major issue I am running into is that Google chooses to redirect all my users to www.google.ca. > > So my questions to others are: > > 1. How do I get my data updated in all of the geolocate providers databases as quickly as possible? > > 2. What geolocate database does Google use (is it homegrown?) and how do I get them to update my data? http://www.google.com/support/websearch/bin/request.py?contact_type=ip If it is urgent / lots of users are grumping at you, feel free to send me an off-list mail including the information asked for on that page and I'll follow up internally. Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point.... W > > Thanks. > > -Eric > _______________________________________________________________ > Eric Rosenberry > Sr. Network Engineer | Chief Bit Plumber > > > > iovation > 111 SW Fifth Avenue > Suite 3200 > Portland, OR 97204 > www.iovation.com > > The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. -- "Beware that the most effective way for someone to decrypt your data may be with rubber hose." --- SSH 1.2.12 README From smb at cs.columbia.edu Mon Jan 18 19:38:32 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 18 Jan 2010 20:38:32 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> Message-ID: On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote: > Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point.... I don't think that that works. Apart from the problem that you allude to -- people not bothering to set it up in the first place -- IP geolocation is often used for certain forms of access control and policy enforcement. For example: "Regular Season Local Live Blackout: All live, regular season games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription services are subject to local blackouts. Such live games will be blacked out in each applicable Club's home television territory, regardless of whether that Club is playing at home or away." (http://www.mlb.com/mediacenter/). EBay has apparently used IP geolocation (poorly) to control access to certain auctions for items that are illegal in certain jurisdictions or that cannot be exported. --Steve Bellovin, http://www.cs.columbia.edu/~smb From patrick at ianai.net Mon Jan 18 20:10:49 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 18 Jan 2010 21:10:49 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> Message-ID: <2D63596D-24DA-4688-B1B5-B603587AF625@ianai.net> On Jan 18, 2010, at 8:38 PM, Steven Bellovin wrote: > On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote: > >> Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point.... > > I don't think that that works. Apart from the problem that you allude to -- people not bothering to set it up in the first place -- IP geolocation is often used for certain forms of access control and policy enforcement. For example: "Regular Season Local Live Blackout: All live, regular season games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription services are subject to local blackouts. Such live games will be blacked out in each applicable Club's home television territory, regardless of whether that Club is playing at home or away." (http://www.mlb.com/mediacenter/). EBay has apparently used IP geolocation (poorly) to control access to certain auctions for items that are illegal in certain jurisdictions or that cannot be exported. These are just ways of satisfying lawyers & courts that you at least tried to live up to your end of the bargain (licensing, laws, etc.). Since many geo-location DBs work off SWIP records, which are obviously controlled by the user, and some even use in-addrs already for info, I don't see why it wouldn't work. Also, this is not a silver-bullet kinda problem. Every little bit helps. If even a few % of people put LOC records into the DNS, it would help some people. The danger is not of poor uptake, it's of kruft. But that is a huge danger. Just no larger than SWIP or current in-addr. -- TTFN, patrick From morrowc.lists at gmail.com Mon Jan 18 20:11:08 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 18 Jan 2010 21:11:08 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> Message-ID: <75cb24521001181811y4be3f42aief6e0224770c535e@mail.gmail.com> On Mon, Jan 18, 2010 at 8:38 PM, Steven Bellovin wrote: > > On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote: > >> Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point.... > > I don't think that that works. ?Apart from the problem that you allude to -- people not bothering to > set it up in the first place -- IP geolocation is often used for certain forms of access control and > policy enforcement. ?For example: "Regular Season Local Live Blackout: All live, regular season Sure, but I don't think that warren meant s sole signal here... having a hint is nice :) > games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription > services are subject to local blackouts. Such live games will be blacked out in each applicable > Club's home television territory, regardless of whether that Club is playing at home or away." > (http://www.mlb.com/mediacenter/). ?EBay has apparently used IP geolocation (poorly) to control > access to certain auctions for items that are illegal in certain jurisdictions or that cannot be > exported. this describes any use of geo-location for ips though, in most cases it's probably not half bad, but with determined 'attackers' there's very little that can protect your spotify-music from non-swedish folks, for instance. Speaking of geoloc fail: (vpn your boxee traffic to a location more suitable to your watching desires) (I think the users of geoloc in these cases understand they have a 95-98% success rate, and are willing to take the hit on the folks who take an effort to avoid them.) -Chris > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > From warren at kumari.net Mon Jan 18 20:30:28 2010 From: warren at kumari.net (Warren Kumari) Date: Mon, 18 Jan 2010 21:30:28 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> Message-ID: <12BF64C3-D704-44B6-B38D-FAB76B8FFA98@kumari.net> On Jan 18, 2010, at 8:38 PM, Steven Bellovin wrote: > > On Jan 18, 2010, at 8:22 PM, Warren Kumari wrote: > >> Something that I have often wondered is how folks would feel about publishing some sort of geo information in reverse DNS (something like LOC records, with whatever precision you like) -- this would allow the folks that geo stuff to automagically provide the best answer, and because you control the record, you can specify whatever resolution / precision you like. Based upon the sorry state of existing reverse, I'm suspecting that there is no point.... > > I don't think that that works. Apart from the problem that you allude to -- people not bothering to set it up in the first place -- IP geolocation is often used for certain forms of access control and policy enforcement. For example: "Regular Season Local Live Blackout: All live, regular season games available via MLB.TV, MLB.com At Bat 2009 and certain other MLB.com subscription services are subject to local blackouts. Such live games will be blacked out in each applicable Club's home television territory, regardless of whether that Club is playing at home or away." (http://www.mlb.com/mediacenter/). EBay has apparently used IP geolocation (poorly) to control access to certain auctions for items that are illegal in certain jurisdictions or that cannot be exported. Ah, yes, sorry, I guess I didn't fully explain this... This wouldn't (well, shouldn't) be used as an authoritative source -- it would simple be yet another signal that could be used, and would provide (if the ISP so chose) higher resolution. If you think that the IP is in Uzbekistan and traceroutes, whois and RTT all seem to agree with that, but the published LOC type record claims that it is just down the road from you in NJ then, well, you would be silly to believe it. Folks who are currently using geolocation for policy (like MLB.com) must[0] realize that this is a fundamentally flawed approach and is only effective against a non-determined audience, mustn't they? TOR / proxies / etc will all happily get around this blocking and seem much easier for the average user than poking at DNS. W [0]: Ok, they probably don't, but.... > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > -- She'd even given herself a middle initial - X - which stood for "someone who has a cool and exciting middle name". -- (Terry Pratchett, Maskerade) From randy at psg.com Mon Jan 18 20:45:27 2010 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jan 2010 11:45:27 +0900 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> Message-ID: > Something that I have often wondered is how folks would feel about > publishing some sort of geo information in reverse DNS (something like > LOC records, with whatever precision you like) -- this would allow the > folks that geo stuff to automagically provide the best answer, and > because you control the record, you can specify whatever resolution / > precision you like. yes! and smb sez: > geolocation is often used for certain forms of access control and > policy enforcement. For example: "Regular Season Local Live Blackout: > All live, regular season games available via MLB.TV, MLB.com At Bat > 2009 and certain other MLB.com subscription services are subject to > local blackouts. Such live games will be blacked out in each > applicable Club's home television territory, regardless of whether > that Club is playing at home or away." first, i don't think the proportion of in-addr hackers is anywhere near the basic inaccuracy rate of geo-loc. so may not be of big concern. if it is of big concern, those concerned should not believe the in-addr hack. given that our westin, ashburn, and infomart equipment is often considered to be in tokyo, this would be a big win. randy From smb at cs.columbia.edu Mon Jan 18 20:52:03 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 18 Jan 2010 21:52:03 -0500 Subject: DIMACS/CCICADA Workshop on Secure Routing Message-ID: Note: we really want ops clue! ********************************************************************* DIMACS/CCICADA Workshop on Secure Routing February 22 - 24, 2010 DIMACS Center, CoRE Building, Rutgers University Organizers: Steve Bellovin, Columbia University, smb at cs.columbia.edu Nick Feamster, Georgia Institute of Technology, feamster at cc.gatech.edu Aaron D. Jaggard, Rutgers University, adj at dimacs.rutgers.edu Vijay Ramachandran, Colgate University, vramachandran at colgate.edu Presented under the auspices of the DIMACS Special Focus on Algorithmic Foundations of the Internet and the Command, Control, and Interoperability Center for Advanced Data Analysis (CCICADA). ************************************************ This workshop will bring together experts in networking, algorithms, mechanism design, and other areas to discuss recent progress and future directions in securing network routing, including robustness in the face of misconfiguration or rational behavior and defense against active attacks. ******************************************************************** Participation: We are soliciting short abstract submissions to be considered for a presentation at the workshop. Abstracts should be on recent progress and future directions in secure network routing; this includes (but is not limited to) theory, analysis, design, and experimental work related to robustness in the face of misconfiguration or rational behavior, defense against active attacks, and other problems relevant to secure routing. Because there will be no published proceedings we welcome submissions covering material that was previously presented elsewhere (and referenced as such). Instructions for authors: Submissions should include talk title, speaker name, affiliation, contact information, and a short abstract. Please mail abstracts to Aaron Jaggard (adj at dimacs.rutgers.edu) by Friday, January 22, 2010. ******************************************************************** Registration: (Pre-registration deadline: February 15, 2010) Please see website for complete registration details. ********************************************************************* Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/SecureRouting/ **PLEASE BE SURE TO PRE-REGISTER EARLY** ******************************************************************** From jeroen at unfix.org Mon Jan 18 20:56:39 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 19 Jan 2010 03:56:39 +0100 Subject: DIMACS/CCICADA Workshop on Secure Routing In-Reply-To: References: Message-ID: <4B551F67.3060907@spaghetti.zurich.ibm.com> Steven Bellovin wrote: > Note: we really want ops clue! > > > ********************************************************************* > DIMACS/CCICADA Workshop on Secure Routing > > February 22 - 24, 2010 I recognize those dates.... they match NANOG48, I guess we can guess where people will be thus: Austin, Texas and not New Jersey (magical routing properties still doesn't allow people to be at two places at once unfortunately...) Might want to move those dates around a bit... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From smb at cs.columbia.edu Mon Jan 18 20:59:18 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 18 Jan 2010 21:59:18 -0500 Subject: DIMACS/CCICADA Workshop on Secure Routing In-Reply-To: <4B551F67.3060907@spaghetti.zurich.ibm.com> References: <4B551F67.3060907@spaghetti.zurich.ibm.com> Message-ID: <3FAA8004-A2A2-4410-9E53-D51D0F199B68@cs.columbia.edu> On Jan 18, 2010, at 9:56 PM, Jeroen Massar wrote: > Steven Bellovin wrote: >> Note: we really want ops clue! >> >> >> ********************************************************************* >> DIMACS/CCICADA Workshop on Secure Routing >> >> February 22 - 24, 2010 > > I recognize those dates.... they match NANOG48, I guess we can guess > where people will be thus: Austin, Texas and not New Jersey (magical > routing properties still doesn't allow people to be at two places at > once unfortunately...) > > Might want to move those dates around a bit... > Probably not possible at this point, but yes, I should have realized that, especially given that I do have both on my calendar and I explained that I wouldn't be at NANOG because... Oops. --Steve Bellovin, http://www.cs.columbia.edu/~smb From netyourlife2007 at gmail.com Tue Jan 19 01:50:26 2010 From: netyourlife2007 at gmail.com (=?utf-8?B?TmV0WW91ckxpZmUyMDA3?=) Date: Tue, 19 Jan 2010 15:50:26 +0800 Subject: =?utf-8?B?UmU6IEFTUjEwMDI=?= References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> Message-ID: <201001191550193802132@gmail.com> HI? Who knows how to unsubscribe the mail list? Thanks a looooooooooooooot! ???? Kenny Sallee ????? 2010-01-07 08:36:23 ???? nanog ??? ??? ASR1002 Anyone have recommendations on solid IOS XE code for ASR 1002 that's just doing: - BGP - VRF's - Many sub-interfaces and ACL's It shipped with 02.04.02.122-33.XND2.bin Thanks, Kenny From randy at psg.com Tue Jan 19 02:20:59 2010 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jan 2010 17:20:59 +0900 Subject: ASR1002 In-Reply-To: <201001191550193802132@gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> Message-ID: > Who knows how to unsubscribe the mail list? look at the headers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , randy From jim at reptiles.org Tue Jan 19 02:24:39 2010 From: jim at reptiles.org (Jim Mercer) Date: Tue, 19 Jan 2010 03:24:39 -0500 Subject: ASR1002 In-Reply-To: References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> Message-ID: <20100119082439.GA17403@reptiles.org> On Tue, Jan 19, 2010 at 05:20:59PM +0900, Randy Bush wrote: > > Who knows how to unsubscribe the mail list? > > look at the headers i still read most of my mail with mutt, but in my experience, many "modern" interfaces (gmail/thunderrbird/etc) don't make it intuative to find and/or read the headers. i'm just sayin'.... > > List-Unsubscribe: , > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > randy -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 swmike at swm.pp.se Tue Jan 19 02:50:56 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 19 Jan 2010 09:50:56 +0100 (CET) Subject: ASR1002 In-Reply-To: <20100119082439.GA17403@reptiles.org> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <20100119082439.GA17403@reptiles.org> Message-ID: On Tue, 19 Jan 2010, Jim Mercer wrote: > i still read most of my mail with mutt, but in my experience, many > "modern" interfaces (gmail/thunderrbird/etc) don't make it intuative to > find and/or read the headers. In gmail you click "show details" and then there is a "unsubscribe from this mailing list"-link you can click. Might not be perfectly intuitive, but it's full functionality and quite easy. -- Mikael Abrahamsson email: swmike at swm.pp.se From richard.barnes at gmail.com Tue Jan 19 06:13:08 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 19 Jan 2010 07:13:08 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> Message-ID: <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> >> Something that I have often wondered is how folks would feel about >> publishing some sort of geo information in reverse DNS (something like >> LOC records, with whatever precision you like) -- this would allow the >> folks that geo stuff to automagically provide the best answer, and >> because you control the record, you can specify whatever resolution / >> precision you like. > > yes! FWIW, there has been some work in the IETF on creating protocols to allow pretty rich location information to be published in reverse DNS. Basically, you publish a NAPTR pointer to a location server [1] where an interested client can ask for the location of a specific IP address [2][3]. (Publishing location in this way is a requirement in several systems for VoIP 9-1-1 around the world to allow first responders to ask networks for location. See for example the NENA i3 architecture in the US and a similar "Canadian i2" for Canada.) The location representation these protocols use is a profile of the Geospatial Markup Language, so you can represent anything from a simple point to full GIS-like layers; you can also represent civic addresses (i.e., postal addresses) directly. If people are interested, let me know and I can provide pointers to some useful open-source software. --Richard [1] [2] [3] [4] From randy at psg.com Tue Jan 19 06:23:41 2010 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jan 2010 21:23:41 +0900 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> Message-ID: >>> Something that I have often wondered is how folks would feel about >>> publishing some sort of geo information in reverse DNS (something like >>> LOC records, with whatever precision you like) -- this would allow the >>> folks that geo stuff to automagically provide the best answer, and >>> because you control the record, you can specify whatever resolution / >>> precision you like. >> >> yes! > > FWIW, there has been some work in the IETF on creating protocols to > allow pretty rich location information to be published in reverse DNS. > Basically, you publish a NAPTR pointer to a location server [1] where > an interested client can ask for the location of a specific IP address > [2][3]. (Publishing location in this way is a requirement in several > systems for VoIP 9-1-1 around the world to allow first responders to > ask networks for location. See for example the NENA i3 architecture > in the US and a similar "Canadian i2" for Canada.) > > The location representation these protocols use is a profile of the > Geospatial Markup Language, so you can represent anything from a > simple point to full GIS-like layers; you can also represent civic > addresses (i.e., postal addresses) directly. surely, with its vast talents, the ietf can make this more complex. after all, look at the inflate-and-embellish stupidity that made the simple idea of bgp communities for data collecion, completely ueless, draft-meyer-collection-communities-00.txt i just wanna deal with a cidr block for stupid simple thing, not boil the ocean. and we have LOC RRs. no brilliance or inventiveness needed. randy From richard.barnes at gmail.com Tue Jan 19 06:29:04 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 19 Jan 2010 07:29:04 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> Message-ID: <88ac5c711001190429w70fa20d4le41ea39e226accee@mail.gmail.com> Just to be fair here, I appreciate that there's some additional complexity here (not much -- I implemented a client for this yesterday in ~80 lines of Javascript), but LOC records don't cover everything. They're fine for stationary stuff, but not so great for anything that moves with any frequency (unless you're willing to make the DNS really dynamic). --Richard On Tue, Jan 19, 2010 at 7:23 AM, Randy Bush wrote: >>>> Something that I have often wondered is how folks would feel about >>>> publishing some sort of geo information in reverse DNS (something like >>>> LOC records, with whatever precision you like) -- this would allow the >>>> folks that geo stuff to automagically provide the best answer, and >>>> because you control the record, you can specify whatever resolution / >>>> precision you like. >>> >>> yes! >> >> FWIW, there has been some work in the IETF on creating protocols to >> allow pretty rich location information to be published in reverse DNS. >> ?Basically, you publish a NAPTR pointer to a location server [1] where >> an interested client can ask for the location of a specific IP address >> [2][3]. ?(Publishing location in this way is a requirement in several >> systems for VoIP 9-1-1 around the world to allow first responders to >> ask networks for location. ?See for example the NENA i3 architecture >> in the US and a similar "Canadian i2" for Canada.) >> >> The location representation these protocols use is a profile of the >> Geospatial Markup Language, so you can represent anything from a >> simple point to full GIS-like layers; you can also represent civic >> addresses (i.e., postal addresses) directly. > > surely, with its vast talents, the ietf can make this more complex. > > after all, look at the inflate-and-embellish stupidity that made the > simple idea of bgp communities for data collecion, completely ueless, > draft-meyer-collection-communities-00.txt > > > > i just wanna deal with a cidr block for stupid simple thing, not boil > the ocean. ?and we have LOC RRs. ?no brilliance or inventiveness needed. > > randy > From randy at psg.com Tue Jan 19 06:32:01 2010 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jan 2010 21:32:01 +0900 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <88ac5c711001190429w70fa20d4le41ea39e226accee@mail.gmail.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> <88ac5c711001190429w70fa20d4le41ea39e226accee@mail.gmail.com> Message-ID: > Just to be fair here, I appreciate that there's some additional > complexity here (not much -- I implemented a client for this yesterday > in ~80 lines of Javascript), but LOC records don't cover everything. > They're fine for stationary stuff, but not so great for anything that > moves with any frequency (unless you're willing to make the DNS really > dynamic). you want an rfc, or you want something actually deployed by operators? randy From jim at reptiles.org Tue Jan 19 06:39:55 2010 From: jim at reptiles.org (Jim Mercer) Date: Tue, 19 Jan 2010 07:39:55 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> Message-ID: <20100119123955.GA24890@reptiles.org> On Tue, Jan 19, 2010 at 09:23:41PM +0900, Randy Bush wrote: > surely, with its vast talents, the ietf can make this more complex. > > after all, look at the inflate-and-embellish stupidity that made the > simple idea of bgp communities for data collecion, completely ueless, > draft-meyer-collection-communities-00.txt > > sorta like how RFC1530, over the course of 10 years, plus some ITU fiddling, became RFC3761 its interesting how many wheels seem to need re-inventing. 8^) -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 gordslater at ieee.org Tue Jan 19 07:59:32 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 19 Jan 2010 13:59:32 +0000 Subject: ASR1002 In-Reply-To: <201001191550193802132@gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> Message-ID: <1263909572.18086.40.camel@ub-g-d2> Inline (and diverse) replies, as it's more of a rant, but slightly relevant to the list ops if not the OP topic: 1 - On Tue, 2010-01-19 at 15:50 +0800, NetYourLife2007 wrote (well, at least his mailer declared itself to be...): > Mailer: > Foxmail 6, 15, 201, 22 [cn] Kenny's mail client may be slightly unfamiliar to most nanog users :) Not sure if that's relevant but it may be a contributory factor. Maybe the problem is that we're all too old and can remember what headers are and what they're useful for, but developers of these "modern" mail clients just want to hide all feature that even so much as _look like_ they have come from a CLI client. For example, I know several otherwise competent people who glaze over and fall asleep when I mention the Reply To: field. 2 - On Tue, 19 Jan 2010, Jim Mercer wrote: > > > i still read most of my mail with mutt, but in my experience, many > > "modern" interfaces (gmail/thunderrbird/etc) don't make it intuative to > > find and/or read the headers. agreed, after 18 month of trying to comply I still can't drive this Evolution thing that most "new Linux-on-the-Desktop" users get as a default install. I couldn't even find out how to bind the "h" key to headers after a month of looking, for example. I live in hope for a Mutt Bindings `extension`, if some developer can wake their grandparents for some memories. On Tue, 2010-01-19 at 09:50 +0100, Mikael Abrahamsson wrote: > In gmail you click "show details" and then there is a "unsubscribe from > this mailing list"-link you can click. Might not be perfectly intuitive, > but it's full functionality and quite easy. Thank you, I've now (and only now) just found a similar thingy in this client. 18 months down the line....grrr Yet just testing it, it works for nanog, but not for 2 other lists I'm in, with similar correct headers 8-{ Are we (or rather the developers) losing the plot? I think many of today's "web-users" may consider email old-fashioned, so if the new `app-for-that` culture doesn't provide easy/basic access to `old-fashioned` features, things may slowly turn into interface soup. And while I'm ranting, why has my client suddenly borked into 132 column mode? Ahem now, rant off/relevance on: Prediction: We may have to, in the coming years, for the above reasons and more, reduce the monthly FAQ posting to bi-weekly if the unsubscribe-to-(signal+noise) ratio increases significantly. Or a single-line howto unsubscribe message biweekly. Or something. Meh. de Gord [in a bad, bad, depressive mood due to huge IMAP restore issues out of my control] -- Sudo is prior art. Fools or thieves? You decide. From jim at reptiles.org Tue Jan 19 10:00:01 2010 From: jim at reptiles.org (Jim Mercer) Date: Tue, 19 Jan 2010 11:00:01 -0500 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <1263909572.18086.40.camel@ub-g-d2> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> Message-ID: <20100119160001.GA30743@reptiles.org> for days now, i've been trying to remember a quotation, which i vaguely seem to remember popping up in trn/nn or some USENET newsreader of old, along the lines of: "the telephone, once commonly available in cities, ...." or something like that. ring a bell for anyone? -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 andy at nosignal.org Tue Jan 19 10:15:11 2010 From: andy at nosignal.org (Andy Davidson) Date: Tue, 19 Jan 2010 16:15:11 +0000 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> <5794EEA6-D4A8-457A-B820-46A1F12C1AE9@kumari.net> <88ac5c711001190413q57765a3bs89d80b4a7cec3c01@mail.gmail.com> Message-ID: <4B55DA8F.4030802@nosignal.org> On 19/01/2010 12:13, Richard Barnes wrote: > FWIW, there has been some work in the IETF on creating protocols to > allow pretty rich location information to be published in reverse DNS. This would be good, but it must be remembered that this would only ever be one clue about where a user actually is; for example we can not expect people who use geo-ip to try to honour international copy rights to ever use it. Sadly ;-) Andy From jed at jedsmith.org Tue Jan 19 10:27:54 2010 From: jed at jedsmith.org (Jed Smith) Date: Tue, 19 Jan 2010 11:27:54 -0500 Subject: New netblock Geolocate wrong (Google) In-Reply-To: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> References: <139EF7B8AE318D408CFCB51C899CAF3403B92793FC@cpexch01.iovation.com> Message-ID: On Jan 18, 2010, at 5:27 PM, Rosenberry, Eric wrote: > Specifically Maxmind (http://www.maxmind.com/) thinks we are in Canada My employer dealt with this recently, but I am unsure who specifically they communicated with at MaxMind. What I did notice is that once informed of the actual location of the block, MaxMind did not mind updating their database and kept them in the loop -- they were quite communicative. The data took a while to update, but it did happen to my employer's satisfaction. I'll ask the person who took care of it if he'll share his contact, but poke them through any public means you can...they do listen, in my experience. JS From jerome at phibee.net Tue Jan 19 01:46:22 2010 From: jerome at phibee.net (Jerome SCHEVINGT) Date: Tue, 19 Jan 2010 08:46:22 +0100 Subject: At&t and Sprint Contact USA Wholesales Message-ID: <4B55634E.8000800@phibee.net> Hi i am search a contact into AT&T and Sprint for T1/DSL/DS3 Wholesales services. if you know a name/email, please contact me Thanks for your Help Jerome -- Jerome Schevingt Ing?nieur Syst?mes et R?seaux PHIBEE Tel: +33(0)426847860 Mobile: +33(0)607759222 Fax: +33(0)426847861 Mail: jerome at phibee.net From brunner at nic-naa.net Tue Jan 19 11:35:31 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 19 Jan 2010 12:35:31 -0500 Subject: Katrina response, private and public In-Reply-To: <4B53F390.4040007@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> Message-ID: <4B55ED63.3050407@nic-naa.net> Yesterday the US provided 270 gallons of diesel, and the Dominican Republic provided 100 gallons of diesel. Including battery, the Xchange Boutilliers is fuel secure through Friday. Eric On 1/18/10 12:37 AM, Eric Brunner-Williams wrote: > There are significant US naval and land assets in place. > > However, resupply to the NAP/microwave backhaul out of the FERA (Front > Edge Rescue Area, to delta off the usual FEBA acronym) and local > government data communications continuity apparently aren't on the first > day task order, nor any subsequent day's task order. > > Drill. Drill Now. Drill Baby Drill. Palin may be insane, but skipping on > emergency procedures and drills, which at least one government has done, > is not sane. (Doing something twice, e.g., failure to prepare for > Katrina class events, and expecting a different outcome measure of sanity.) > > Eric > > On 1/17/10 10:22 PM, Nathan Eisenberg wrote: >> Isn't there a US destroyer taskforce off the coast now? One would >> think they'd have a supply of diesel available. >> >> Best Regards, >> Nathan Eisenberg >> ________________________________________ >> From: Eric Brunner-Williams [brunner at nic-naa.net] >> Sent: Sunday, January 17, 2010 3:02 PM >> To: nanog at nanog.org >> Subject: Re: Katrina response, private and public >> >> As of this hour Reynold Guerrier has managed to obtain 56 gallons of >> diesel, moving the NAP's dry tank fail point some 8 hours, into the >> morning of the 18th. >> >> No other fuel has been delivered to the NAP. The SitRep of the 16th to >> the State Department has just been updated with information current as >> of this hour. >> >> Eric >> >> On 1/16/10 5:36 PM, Eric Brunner-Williams wrote: >>> At around noon, Eastern, the State Department was provided with >>> information on the fuel situation at the Port au Prince NAP, which has >>> used 2/3rds of the available diesel (8gal/hour run rate, 160 gal >>> remaining) keeping the microwave backhaul to the DR up, and all >>> remaining governmental and NGO network access. >>> >>> Eric >>> >>> On 1/16/10 10:43 AM, Reynold Guerrier wrote: >>>> Guys >>>> >>>> The buggest issues in the 2 coming days will be energy. And I can't >>>> assure that we will be able to get fuel for the generator. Equipment >>>> with Solar energy will be our best shot. >>>> >>>> >>>> Reynold Guerrier >>>> AHTIC >>>> Treasurer >>>> Network Engineer >>>> Haiti Earthquake Survivor >>>> >>>> On Fri, Jan 15, 2010 at 10:40 AM, Eric Brunner-Williams >>>> > wrote: >>>> >>>> Folks, >>>> >>>> After the Katrina landfall a diverse group of wireless people >>>> started organizing a relief effort, culminating in work around >>>> Waveland. There was also a group from the NPGS in Monterey, who >>>> worked on the Boxing Day Tsunami aftermath. >>>> >>>> Does anyone have a similar contact set? >>>> >>>> Eric >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>> >>> >>> >>> >> >> >> >> >> >> >> > > > > From gordslater at ieee.org Tue Jan 19 11:48:44 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 19 Jan 2010 17:48:44 +0000 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <20100119160001.GA30743@reptiles.org> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> Message-ID: <1263923324.10985.4.camel@ub-g-d2> On Tue, 2010-01-19 at 11:00 -0500, Jim Mercer wrote: > for days now, i've been trying to remember a quotation, which i vaguely seem > to remember popping up in trn/nn or some USENET newsreader of old, along > the lines of: > > "the telephone, once commonly available in cities, ...." > > or something like that. > > ring a bell for anyone? > I get the distinct feeling it's a quite from an obscure scifi novel/film or MST3K style quote, though I could be wrong. It does ring a distant bell, but I'm not so sure about on Usenet. Maybe it was a Gopher thing? This newfangled Googly-thing finds nothing - it'll never catch on. Anyone got some old Winchesters lying around that need a spin? From sethm at rollernet.us Tue Jan 19 12:15:06 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 19 Jan 2010 10:15:06 -0800 Subject: Katrina response, private and public In-Reply-To: <4B55ED63.3050407@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> Message-ID: <4B55F6AA.9020903@rollernet.us> Eric Brunner-Williams wrote: > Yesterday the US provided 270 gallons of diesel, and the Dominican > Republic provided 100 gallons of diesel. Including battery, the Xchange > Boutilliers is fuel secure through Friday. > If I may ask, what's the long term plan? How long is utility power expected to be unavailable? ~Seth From brunner at nic-naa.net Tue Jan 19 12:31:47 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 19 Jan 2010 13:31:47 -0500 Subject: Katrina response, private and public In-Reply-To: <4B55F6AA.9020903@rollernet.us> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> Message-ID: <4B55FA93.5040408@nic-naa.net> I've no idea. I've just been focused on moving the "dry tank" moment to the right, along with several others. Mind, this was the first resupply, its not a stable replenishment schedule yet. The engineers on site had (as of yesterday) personal food and water through Thursday, and dependents in need. Eric On 1/19/10 1:15 PM, Seth Mattinen wrote: > Eric Brunner-Williams wrote: >> Yesterday the US provided 270 gallons of diesel, and the Dominican >> Republic provided 100 gallons of diesel. Including battery, the Xchange >> Boutilliers is fuel secure through Friday. >> > > If I may ask, what's the long term plan? How long is utility power > expected to be unavailable? > > ~Seth > > From rjoffe at centergate.com Tue Jan 19 13:27:36 2010 From: rjoffe at centergate.com (Rodney Joffe) Date: Tue, 19 Jan 2010 12:27:36 -0700 Subject: Katrina response, private and public In-Reply-To: <4B55FA93.5040408@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> Message-ID: <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> On Jan 19, 2010, at 11:31 AM, Eric Brunner-Williams wrote: > I've no idea. I've just been focused on moving the "dry tank" moment > to the right, along with several others. Mind, this was the first > resupply, its not a stable replenishment schedule yet. > > The engineers on site had (as of yesterday) personal food and water > through Thursday, and dependents in need. Is there anything that any of us cab do to help, exert influence, etc (short of donating which many of us are already doing). From brunner at nic-naa.net Tue Jan 19 14:15:52 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 19 Jan 2010 15:15:52 -0500 Subject: Katrina response, private and public In-Reply-To: <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> Message-ID: <4B5612F8.3080203@nic-naa.net> On 1/19/10 2:27 PM, Rodney Joffe wrote: > > > On Jan 19, 2010, at 11:31 AM, Eric Brunner-Williams wrote: > >> I've no idea. I've just been focused on moving the "dry tank" moment >> to the right, along with several others. Mind, this was the first >> resupply, its not a stable replenishment schedule yet. >> >> The engineers on site had (as of yesterday) personal food and water >> through Thursday, and dependents in need. > > Is there anything that any of us cab do to help, exert influence, etc > (short of donating which many of us are already doing). Yes there is Rodney. The visa problem isn't solved yet, and fundamentally it is a call-your-congress-critter problem. I'll have more on that this evening (EST). TiA, Eric From woody at pch.net Tue Jan 19 14:34:32 2010 From: woody at pch.net (Bill Woodcock) Date: Tue, 19 Jan 2010 12:34:32 -0800 Subject: Katrina response, private and public In-Reply-To: <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> Message-ID: <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> On Jan 19, 2010, at 11:27 AM, Rodney Joffe wrote: > Is there anything that any of us can do to help, exert influence, etc (short of donating which many of us are already doing). I'm sure other people involved in the relief work can suggest other things, but a few comments from my point of view: - Communications capability underpins the ability of other relief workers to do their jobs effectively, so although we, as a community, aren't feeding people or tending to their medical needs, we are helping those who are doing those crucial jobs by allowing them to focus on their work. - In the short-term, the equipment that's been requested by people on the ground has either already been delivered, is onboard a ship that left Jacksonville about twelve hours ago, or is being containerized to load on a ship that's leaving from Port Everglades tomorrow. - Also in the short-term, keep an eye out for con-artists who are trying to lure people in to fake aid-donation web sites with spam. Law enforcement is coordinating internationally to take those offline as promptly as possible. If you get fake aid-donation spam, please forward it to Tom Grasso or Randy Vickers . Either of them or I can pass things along to the international coordination group that's addressing this. - In the mid-term, what our community needs to do is to make sure that backhaul infrastructure gets into place to move traffic in the 1Gbps-10Gbps range from Port au Prince to Miami. There are several cable systems which land in Santo Domingo, and Columbus has a branching unit off Guantanamo, so our main efforts have been focused on getting a festoon cable run around from the Santo Domingo landing (the University of Puerto Rico Marine Research labs have committed their cable-laying ship, crew, and divers, but we're still looking for an appropriate spool of armored singlemode in the 12-24 core range (more certainly wouldn't hurt, as this would be unrepeatered), and on finding funding to get Columbus to run the spur in from their BU. BTC apparently has fiber already existing or in process of turn-up between Port au Prince and the Bahamas, but nobody's been able to get a response from them yet about its status. - More generally, as a community, we do good when we make sure that places like this, places that may not have large or lucrative markets, are still served by diverse fiber, rather than by a single fragile monopoly, or not at all, as in Haiti's case. There are many countries as vulnerable as Haiti, and many of them have no fiber. Most humanitarian disasters happen in poor countries and these are generally the countries our community currently has the least capacity to serve. We can think a little more broadly than that, looking to a future when people in poor countries have more smartphones, and students and small businesses are getting online. We don't need to wait for markets to develop... we can invest in those markets, and _cause_ them to develop. Then they won't be as vulnerable to disasters like this. - Thinking to the longer term... The majority of people who die in humanitarian disasters die of second-order effects like starvation and disease that come in the wake of an earthquake or flood or whatever. That's just beginning now in Haiti, and will continue for some time. The people who died in the earthquake itself will be far outnumbered by those who will die as a result of insufficiently prepared emergency response. PCH and Cisco have been trying for _years_ to get donors to support a ready-to-go emergency communications team for disaster response, but it's been impossible to get donors to fund _preparedness_ rather than after-the-fact response. But immediately after an emergency is the _most expensive_ time to acquire generators and fuel and solar panels and wind generators and batteries and satphones and fiber and space-segments and so forth. All of that can be _much more cheaply_ purchased or contracted for beforehand, and delivered on-site weeks earlier. And those weeks are the weeks of effective response that reduce second-order deaths in the wake of an emergency. People who think they're being helpful with a donation now should understand that the donation would have saved ten times as many lives if it had been made a year ago, than if it's made now. If your companies have charitable foundations, please get them to think about that. -Bill -------------- 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 davidn at astate.edu Tue Jan 19 14:59:36 2010 From: davidn at astate.edu (David Nguyen) Date: Tue, 19 Jan 2010 14:59:36 -0600 Subject: Grant Funding Message-ID: Does anyone have any good suggestions on grant funding for a network refresh? NSF? From jcdill.lists at gmail.com Tue Jan 19 15:03:18 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 19 Jan 2010 13:03:18 -0800 Subject: Katrina response, private and public In-Reply-To: <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> Message-ID: <4B561E16.8040808@gmail.com> Bill Woodcock wrote: > - Thinking to the longer term... The majority of people who die in > humanitarian disasters die of second-order effects like starvation and > disease that come in the wake of an earthquake or flood or whatever. > That's just beginning now in Haiti, and will continue for some time. > The people who died in the earthquake itself will be far outnumbered > by those who will die as a result of insufficiently prepared emergency > response. PCH and Cisco have been trying for _years_ to get donors to > support a ready-to-go emergency communications team for disaster > response, but it's been impossible to get donors to fund > _preparedness_ rather than after-the-fact response. But immediately > after an emergency is the _most expensive_ time to acquire generators > and fuel and solar panels and wind generators and batteries and > satphones and fiber and space-segments and so forth. All of that can > be _much more cheaply_ purchased or contracted for beforehand, and > delivered on-site weeks earlier. And those weeks are the weeks of > effective response that reduce second-order deaths in the wake of an > emergency. People who think they're being helpful with a donation now > should understand that the donation would have saved ten times as many > lives if it had been made a year ago, than if it's made now. If your > companies have charitable foundations, please get them to think about > that. Well said Bill. In addition, make sure everyone in your company has taken a CERT (Community Emergency Response Team) course. Aside from cash donations, the most important thing you can do is get CERT training so you can be effective in an emergency situation. http://www.citizencorps.gov/cert/ The biggest problem in Haiti is a lack of an incident command structure. Because of the lack of organization, resources are not effectively used and people die - the tools needed to rescue them aren't found in time, water isn't distributed in time, food and shelter isn't made available in time, etc. Yes, all of these things are in desperately short supply, but the problem is greatly magnified when there's a lack of organization. If they had better organization, then their scarce supplies would be used more effectively to benefit more people. If every US tourist visiting Haiti or US citizen working in Haiti who survived the quake unharmed had CERT training, they could have helped organize and mobilize uninjured Haitian survivors to band together and be more effective. This means being more effective at rescuing people, at triage, at providing emergency medical care, at communicating with municipal services (hospitals, doctors, police, fire departments), at determining what resources you have at hand (food, water, fuel, materials to build shelters) and how to best protect it, to ration it, to share and distribute it. It will be a long time before we can get CERT training in-place in third-world countries to ensure that their citizens can have this training, but we have it here in the US - just about every fire department offers the courses, often for free. Most offer the course to anyone who lives or works in their area. I don't know what CERT-like programs exist outside the US, but I'm pretty sure that other developed countries have similar programs. Brent Chapman has a presentation he gave at the USENIX/SAGE LISA Conference in San Diego on Thursday, 8 December 2005, and at the BayLISA meeting on Thursday, 20 October 2005: http://www.greatcircle.com/blog/author/brent_chapman/2005/10/ The presentation is about how CERT training applies to IT disasters. So not only will you be better positioned to provide personal help if you ever find yourself in a disaster situation like Haiti, you will also be able to apply the training to your day job in network operations. :-) You can also read about Brent's experience helping setup network communications in New Orleans after Katrina. jc From jared at puck.nether.net Tue Jan 19 15:11:49 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Jan 2010 16:11:49 -0500 Subject: Grant Funding In-Reply-To: References: Message-ID: <124135FE-94EB-4616-A8F7-ACC4E6E3448A@puck.nether.net> I'm interested in hearing from anyone that has gotten USDA RUS or similar funding myself. I'm fairly convinced that with the recent strategies of VZ and ATT they will fully divest themselves of regulated last-mile services as soon as reasonably feasible (exception: cellular) creating further demand/need to bridge the gap. - Jared On Jan 19, 2010, at 3:59 PM, David Nguyen wrote: > Does anyone have any good suggestions on grant funding for a network > refresh? NSF? From fkittred at staff.gwi.net Tue Jan 19 15:26:56 2010 From: fkittred at staff.gwi.net (Fletcher Kittredge) Date: Tue, 19 Jan 2010 16:26:56 -0500 Subject: Grant Funding In-Reply-To: <124135FE-94EB-4616-A8F7-ACC4E6E3448A@puck.nether.net> References: <124135FE-94EB-4616-A8F7-ACC4E6E3448A@puck.nether.net> Message-ID: What do you want to know? We were the first NTIA grant announced. $32 million project to build rural *dark* fiber networks. The model was to form a new company which would be carrier neutral and just build and maintain rural dark fiber. A carrier's carrier; structural separation; prices based on cost plus margin, not what the market would bear, open access, non-discrimination.... This model seemed to resonate with the Feds. The local incumbents still seem to have a hard time believing we would get a government subsidy and then immediately give it away. A model where any carrier, including them, could have access to dark fiber on equal terms is beyond their ken. regards, Fletcher On Tue, Jan 19, 2010 at 4:11 PM, Jared Mauch wrote: > I'm interested in hearing from anyone that has gotten USDA RUS or similar > funding myself. > > I'm fairly convinced that with the recent strategies of VZ and ATT they > will fully divest themselves of regulated last-mile services as soon as > reasonably feasible (exception: cellular) creating further demand/need to > bridge the gap. > > - Jared > > On Jan 19, 2010, at 3:59 PM, David Nguyen wrote: > > > Does anyone have any good suggestions on grant funding for a network > > refresh? NSF? > > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From jtk at cymru.com Tue Jan 19 15:29:36 2010 From: jtk at cymru.com (John Kristoff) Date: Tue, 19 Jan 2010 15:29:36 -0600 Subject: Grant Funding In-Reply-To: References: Message-ID: <20100119152936.1b8a8153@t61p> On Tue, 19 Jan 2010 14:59:36 -0600 David Nguyen wrote: > Does anyone have any good suggestions on grant funding for a network > refresh? NSF? You mean funding to help upgrade your network? Bail outs aside, its unlikely the NSF or similar entity is going to dole out money for a network upgrade. That is typically the operating organization's responsibility. You might be able to strike a good deal with a new vendor if you're willing to switch some of your major platforms. In some cases, if there is something new and novel that isn't part of the standard operating expense sheet, you may be awarded some funding for a well articulated proposal, that may just happen to get you some new gear, because its need for the new thing, but that still requires some non-trivial investment in coming up with a proposal and implementing it. However, I think most serious funding organizations will see through proposals thinly disguised as network upgrade projects. John From brunner at nic-naa.net Tue Jan 19 16:28:50 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 19 Jan 2010 17:28:50 -0500 Subject: Grant Funding In-Reply-To: References: <124135FE-94EB-4616-A8F7-ACC4E6E3448A@puck.nether.net> Message-ID: <4B563222.2070506@nic-naa.net> Fletcher, A belated "good job". Eric From reygue at gmail.com Tue Jan 19 16:39:21 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Tue, 19 Jan 2010 17:39:21 -0500 Subject: Katrina response, private and public In-Reply-To: <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net> <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> Message-ID: <9ab36b821001191439s8568498ha61ad495341e570d@mail.gmail.com> To any of you who wants to help: We would like to provide to the haitian government a UC systems with several branches: - President office: 10 Endpoints - PM office: 10 endpoints - 12 mayor city hall offices: 3 for each : 36 endpoints - Ministries (9 differents locations 3 for each) 27 - Communications Center 20 - emergency Clusters 14 Total 117 endpoints Redundant communications. So if someone can provide recommendations, equipment, skilled technician for that it would be fine. Reynold On Tue, Jan 19, 2010 at 2:27 PM, Rodney Joffe wrote: > > > On Jan 19, 2010, at 11:31 AM, Eric Brunner-Williams wrote: > > I've no idea. I've just been focused on moving the "dry tank" moment to >> the right, along with several others. Mind, this was the first resupply, its >> not a stable replenishment schedule yet. >> >> The engineers on site had (as of yesterday) personal food and water >> through Thursday, and dependents in need. >> > > Is there anything that any of us cab do to help, exert influence, etc > (short of donating which many of us are already doing). > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From martin at theicelandguy.com Tue Jan 19 17:56:31 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 19 Jan 2010 18:56:31 -0500 Subject: Katrina response, private and public In-Reply-To: <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> References: <4B508C67.5000309@nic-naa.net> <4B523F68.6080305@nic-naa.net> <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> Message-ID: On Tue, Jan 19, 2010 at 3:34 PM, Bill Woodcock wrote: > > [ snip ] > certainly wouldn't hurt, as this would be unrepeatered), and on finding > funding to get Columbus to run the spur in from their BU. BTC apparently > has fiber already existing or in process of turn-up between Port au Prince > and the Bahamas, but nobody's been able to get a response from them yet > about its status. > *Not speaking for BTC/AS8014* "Bahamas Telecommunications Company (BTC), the service provider that runs the Bahamas Domestic Submarine Network (BDSNi) submarine cable system linking to Haiti, reported that service has been disrupted as a result of the earthquake that struck the Port-au-Prince area." http://www.fiercetelecom.com/story/btcs-haitian-cable-suffers-damage-isps-remain-operational/2010-01-15 I forwarded the DHS contacts to them. Also, re your plan to potentially run a cable from SD to PaP. Interesting. Looks like 300nm to me. I think you're going to need op amp and power. On the Columbus run, they're going to need a landing station. I'm going to speculate that this is part of BTC's problem; no landing station of the subsea route was disrupted by the quake and depending upon the route that UPR is going to take I'd think harder about the effectiveness of this plan. I'd be thinking microwave and towers. Faster. Cheaper. Best, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jared at puck.nether.net Tue Jan 19 18:01:01 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Jan 2010 19:01:01 -0500 Subject: Grant Funding In-Reply-To: References: <124135FE-94EB-4616-A8F7-ACC4E6E3448A@puck.nether.net> Message-ID: <30F4F8E9-3101-4352-BD54-CC427BE62BAA@puck.nether.net> On Jan 19, 2010, at 4:26 PM, Fletcher Kittredge wrote: > > What do you want to know? We were the first NTIA grant announced. $32 million project to build rural *dark* fiber networks. The model was to form a new company which would be carrier neutral and just build and maintain rural dark fiber. A carrier's carrier; structural separation; prices based on cost plus margin, not what the market would bear, open access, non-discrimination.... This model seemed to resonate with the Feds. The local incumbents still seem to have a hard time believing we would get a government subsidy and then immediately give it away. A model where any carrier, including them, could have access to dark fiber on equal terms is beyond their ken. > This is similar to what I have been doing research on. I wonder if the cellular coverage outside the I-95 corridor will get better as a result of your efforts... I really should have gotten fed up with my local [ineffective] incumbents with enough time to develop a similar approach. I do wonder if the upcoming FCC broadband work will result in a similar policy being adopted. "We're all just overlay networks of the fiber" is a nice approach. - Jared From dga at cs.cmu.edu Tue Jan 19 22:02:04 2010 From: dga at cs.cmu.edu (David Andersen) Date: Tue, 19 Jan 2010 23:02:04 -0500 Subject: Grant Funding In-Reply-To: <30F4F8E9-3101-4352-BD54-CC427BE62BAA@puck.nether.net> References: <124135FE-94EB-4616-A8F7-ACC4E6E3448A@puck.nether.net> <30F4F8E9-3101-4352-BD54-CC427BE62BAA@puck.nether.net> Message-ID: You (the OP, not Jared) might also take a look at what the UTOPIA folks have been doing in Utah. It's been a state-funded, not federal-funded, project (I *believe* -- I may be incorrect in the details; I'm not involved and it's been a while since I looked at them), but they've met with some success. -Dave On Jan 19, 2010, at 7:01 PM, Jared Mauch wrote: > > On Jan 19, 2010, at 4:26 PM, Fletcher Kittredge wrote: > >> >> What do you want to know? We were the first NTIA grant announced. $32 million project to build rural *dark* fiber networks. The model was to form a new company which would be carrier neutral and just build and maintain rural dark fiber. A carrier's carrier; structural separation; prices based on cost plus margin, not what the market would bear, open access, non-discrimination.... This model seemed to resonate with the Feds. The local incumbents still seem to have a hard time believing we would get a government subsidy and then immediately give it away. A model where any carrier, including them, could have access to dark fiber on equal terms is beyond their ken. >> > > This is similar to what I have been doing research on. I wonder if the cellular coverage outside the I-95 corridor will get better as a result of your efforts... > > I really should have gotten fed up with my local [ineffective] incumbents with enough time to develop a similar approach. > > I do wonder if the upcoming FCC broadband work will result in a similar policy being adopted. "We're all just overlay networks of the fiber" is a nice approach. > > - Jared > From gordslater at ieee.org Wed Jan 20 02:30:52 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 20 Jan 2010 08:30:52 +0000 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> Message-ID: <1263976252.1183.20.camel@ub-g-d2> On Tue, 2010-01-19 at 17:42 -0800, Bill Stewart wrote: > Could the comment actually have been about pay telephones, which were > once common in cities? > Good point Bill, which, if so, would place the comment at or about the start of the cellfone introduction. @Jim, maybe it's more a telco/2600 thing? None of my overnite greps through old saved chats/snippets came up with anything remotely like it, sadly. I tried a few gopher/archie searches but the system is in very poor shape these days, a shadow of it's early 90's usefulness. Maybe it was on Fidonet or similar? Anyone else have any input? Please ask your old folks ;) Gord From jim at reptiles.org Wed Jan 20 02:35:34 2010 From: jim at reptiles.org (Jim Mercer) Date: Wed, 20 Jan 2010 03:35:34 -0500 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <1263976252.1183.20.camel@ub-g-d2> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> Message-ID: <20100120083534.GA63987@reptiles.org> On Wed, Jan 20, 2010 at 08:30:52AM +0000, gordon b slater wrote: > On Tue, 2010-01-19 at 17:42 -0800, Bill Stewart wrote: > > Could the comment actually have been about pay telephones, which were > > once common in cities? > > > > Good point Bill, which, if so, would place the comment at or about the > start of the cellfone introduction. > > @Jim, maybe it's more a telco/2600 thing? found it, actually was once in my .signature: "The telephone, for those of you who have forgotten, was a commonly used communications technology in the days before electronic mail. They're still easy to find in most large cities." -- Nathaniel Borenstein i'm guessing this is before the mobile phone explosion. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 gordslater at ieee.org Wed Jan 20 02:47:57 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 20 Jan 2010 08:47:57 +0000 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <20100120083534.GA63987@reptiles.org> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> Message-ID: <1263977277.1183.24.camel@ub-g-d2> On Wed, 2010-01-20 at 03:35 -0500, Jim Mercer wrote: > "The telephone, for those of you who have forgotten, was a commonly used > communications technology in the days before electronic mail. > They're still easy to find in most large cities." -- Nathaniel Borenstein Oh, the irony. A quote from Mr MIME himself :) > i'm guessing this is before the mobile phone explosion. ...or before acoustic couplers were junked perhaps. From jmamodio at gmail.com Wed Jan 20 08:01:50 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 20 Jan 2010 08:01:50 -0600 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <20100120083534.GA63987@reptiles.org> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> Message-ID: <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> > "The telephone, for those of you who have forgotten, was a commonly used > communications technology in the days before electronic mail. > They're still easy to find in most large cities." -- Nathaniel Borenstein > > i'm guessing this is before the mobile phone explosion. Good old one. It's funny how we circle around with technology, folks are dumping their phone land lines and adopting wireless/mobile that required a substantial technology leap and investment and now we are using the mobile phone to "text" an incompressible dialect worse than the early teletype/telex days but with a humongous infrastructure to support it. Ohh yeah, now we can send sort of a telegram with multiple fonts and colors almost from anywhere... Cheers Jorge From rdobbins at arbor.net Wed Jan 20 08:17:07 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 20 Jan 2010 14:17:07 +0000 Subject: 2009 Worldwide Infrastructure Security Report available for download. Message-ID: [Apologies for any duplication if you've seen this notification on other lists.] We've just posted the 2009 Worldwide Infrastructure Security Report for download at this URL: This year's WWISR is based upon the broadest set of survey data collected by Arbor to date, with the number of respondents doubling from 66 to 132, and much greater input from non-USA/non-EMEA, regional providers. The WWISR is based upon input from the global operational community, and as such, is unique in its focus on the operational security aspects of public-facing networks. Many of you contributed to the survey which forms the foundation of the report; as always, we're grateful for your insight and participation, and welcome your feedback and comments. Thanks much! ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From Valdis.Kletnieks at vt.edu Wed Jan 20 08:52:04 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 20 Jan 2010 09:52:04 -0500 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: Your message of "Wed, 20 Jan 2010 08:01:50 CST." <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> Message-ID: <28119.1263999124@localhost> On Wed, 20 Jan 2010 08:01:50 CST, Jorge Amodio said: > Ohh yeah, now we can send sort of a telegram with multiple fonts and > colors almost from anywhere... At least it doesn't do BLINK ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sfouant at shortestpathfirst.net Wed Jan 20 09:32:25 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 20 Jan 2010 10:32:25 -0500 Subject: 2009 Worldwide Infrastructure Security Report available for download. In-Reply-To: References: Message-ID: <017a01ca99e5$c4dcddd0$4e969970$@net> > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Wednesday, January 20, 2010 9:17 AM > To: NANOG list > Subject: 2009 Worldwide Infrastructure Security Report available for > download. > > > [Apologies for any duplication if you've seen this notification on > other lists.] > > We've just posted the 2009 Worldwide Infrastructure Security Report for > download at this URL: > > > > This year's WWISR is based upon the broadest set of survey data > collected by Arbor to date, with the number of respondents doubling > from 66 to 132, and much greater input from non-USA/non-EMEA, regional > providers. The WWISR is based upon input from the global operational > community, and as such, is unique in its focus on the operational > security aspects of public-facing networks. > > Many of you contributed to the survey which forms the foundation of the > report; as always, we're grateful for your insight and participation, > and welcome your feedback and comments. Thanks Roland. I'm wondering if you can clarify why 'Figure 1' only goes up to 2008 and states in key findings "This year, providers reported a peak rate of only 49 Gbps". I happen to personally recall looking at ATLAS sometime last year and seeing an ongoing attack that was on orders of magnitude larger than that. It was interesting to see the observation that DDoS attack scale growth has slowed over the past 12 months, including the authors belief that this is a result of "the upper bounds of IP backbone network capacity (e.g., Nx10 Gbps backbone link rates, awaiting upgrades to 100 Gbps rather than 40 Gbps deployment)". It is expected that 100 Gbps will be quickly adopted this year in order to remove the inefficiencies of Nx10 Gbps LAG bundles, and 10 Gbps is likely to start being adopted at the server level. Also there is already talk about Terabit Ethernet sometime in 2015. All of this leads me to believe that attack size will likely increase again as these technologies become more widely deployed. An interesting observation was the decrease in the use of flow-based tools, and the corresponding increase in the use of things like SNMP tools, DPI, and customer calls for attack detection. Surely this must have been a factor of a larger respondent pool... I'd really like to think people aren't opting not to use flow-based tools in favor or receiving customer calls :( Completely agree on the disturbing observation of the increase in rate-limiting as a primary mitigation mechanism for dealing with DDoS. I've seen more and more people using this as a mitigation strategy, against my advice. For anyone interested in more information on the topic, and why rate-limiting is akin to cutting your foot off, I highly recommend you take a look at the paper "Effectiveness of Rate-Limiting in Mitigating Flooding DoS Attacks" presented by Jarmo Molsa at the Third IASTED International conference. It's nice that the report includes respondent organization types, but what I'd really like to see is number of attacks broken down by industry. I think this would go a long way towards allowing companies to better quantify their risk-score and associated spend based on their associated industry. Otherwise, really good stuff. Thanks for sharing! Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From psirt at cisco.com Wed Jan 20 10:09:20 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 20 Jan 2010 11:09:20 -0500 Subject: Cisco Security Advisory: Cisco IOS XR Software SSH Denial of Service Vulnerability Message-ID: <201001201110.xr-ssh@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS XR Software SSH Denial of Service Vulnerability Advisory ID: cisco-sa-20100120-xr-ssh Revision 1.0 For Public Release 2010 January 20 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The SSH server implementation in Cisco IOS XR Software contains a vulnerability that an unauthenticated, remote user could exploit to cause a denial of service condition. An attacker could trigger this vulnerability by sending a crafted SSH version 2 packet that may cause a new SSH connection handler process to crash. Repeated exploitation may cause each new SSH connection handler process to crash and lead to a significant amount of memory being consumed, which could introduce instability that may adversely impact other system functionality. During this event, the parent SSH daemon process will continue to function normally. Cisco has released free software updates that address this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100120-xr-ssh.shtml. Affected Products ================= Vulnerable Products +------------------ This vulnerability affects Cisco IOS XR systems that are running an affected version of Cisco IOS XR Software and have the SSH server feature enabled. A system with the SSH server feature enabled will have the command ssh server [v2] present in its configuration. Refer to the "Cisco IOS XR System Security Configuration Guide" at http://www.cisco.com/en/US/docs/routers/crs/software/crs_r3.9/security/configuration/guide/sc39ssh.html#wp1044523 for additional details regarding configuration of the SSH server in Cisco IOS XR Software. The SSH server can only be enabled in Cisco IOS XR Software if the "security" Package Information Envelope (PIE) is installed. Administrators can issue the show install summary command to confirm if the security PIE is installed. This command will display an active package similar to "-k9sec-" or, for example, "c12k-k9sec-3.6.1" if the security PIE is installed. Refer to the "Software Version and Fixes" section of this advisory for information on specific affected software versions. Products Confirmed Not Vulnerable +-------------------------------- SSH server implementations in Cisco IOS Software and Cisco IOS XE Software are not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco IOS XR Software is a member of the Cisco IOS Software family that uses a microkernel-based distributed operating system infrastructure. Cisco IOS XR Software runs on the Cisco CRS-1 Carrier Routing System, Cisco 12000 Series Routers, and Cisco ASR 9000 Series Aggregation Services Routers. More information on Cisco IOS XR Software is available at http://www.cisco.com/en/US/products/ps5845/index.html. The SSH protocol was developed as a secure replacement for the Telnet, FTP, rlogin, remote shell (rsh), and Remote Copy Protocol (RCP) protocols, which allow for remote device access. SSH varies from these older protocols in that it provides strong authentication and confidentiality and uses encrypted transactions. The SSH server implementation in Cisco IOS XR Software contains a vulnerability that an unauthenticated, remote user could exploit to cause a denial of service condition. The vulnerability is triggered when a new SSH handler process handles a crafted SSH version 2 packet, which may cause the process to crash. During this event, a significant amount of memory may be consumed. Repeated exploitation may impact other system functionality, depending upon the size of the available memory and the duration of attack. Although exploitation of this vulnerability does not require user authentication, the TCP three-way handshake must be completed, and some SSH protocol negotiation must occur. The SSH service will continue to function normally during an after an attack. During exploitation of this vulnerability, the system may generate the following messages: RP/0/RP1/CPU0:Jan 14 16:56:34.885 : dumper[59]: %OS-DUMPER-7-DUMP_ATTRIBUTE : Dump request with attribute 407 for process pkg/bin/sshd_child_handler RP/0/RP1/CPU0:Jan 14 16:56:34.897 : dumper[59]: %OS-DUMPER-7-SIGSEGV : Thread 1 received SIGSEGV RP/0/RP1/CPU0:Jan 14 16:56:34.901 : dumper[59]: %OS-DUMPER-7-BUS_ADRERR : Accessed BadAddr 50199000 at PC 4a280c64 RP/0/RP1/CPU0:Jan 14 16:56:34.906 : dumper[59]: %OS-DUMPER-4-CRASH_INFO : Crashed pid = 21733716 (pkg/bin/sshd_child_handler) This vulnerability is documented in Cisco bug ID CSCsu10574 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2010-0137. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCsu10574 ("sshd_child_handler crashes with crafted SSHv2 packet") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability described in this advisory could result in a crash of the SSH connection handler process. Repeated exploitation may impact other system functionality, depending upon the size of the available memory and the duration of attack. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. This vulnerability can be addressed by applying the appropriate Software Maintenance Upgrade (SMU), per the table below. Installation of the appropriate SMU does not require a system reload. Refer to the document "Guidelines for Cisco IOS XR Software" (http://www.cisco.com/en/US/prod/collateral/iosswrel/ps8803/ps5845/product_bulletin_c25-478699.html) for additional information on Cisco IOS XR Software and SMUs. +---------------------------------------------------------------------------------+ | Cisco | SMU Name and SMU ID | |IOS XR |-----------------------------------------------------------------------| | Release | CRS-1 | XR12000 | ASR 9000 | | | | | (*) | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.4.1.CSCsu10574 | c12k-k9sec-3.4.1.CSCsu10574 | Not | | 3.4.1 | | | applicable | | | AA03509 | AA03532 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.4.2.CSCsu10574 | c12k-k9sec-3.4.2.CSCsu10574 | Not | | 3.4.2 | | | applicable | | | AA03510 | AA03531 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.4.3.CSCsu10574 | c12k-k9sec-3.4.3.CSCsu10574 | Not | | 3.4.3 | | | applicable | | | AA03511 | AA03530 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.5.2.CSCsu10574 | c12k-k9sec-3.5.2.CSCsu10574 | Not | | 3.5.2 | | | applicable | | | AA03512 | AA03529 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.5.3.CSCsu10574 | c12k-k9sec-3.5.3.CSCsu10574 | Not | | 3.5.3 | | | applicable | | | AA03513 | AA03528 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.5.4.CSCsu10574 | c12k-k9sec-3.5.4.CSCsu10574 | Not | | 3.5.4 | | | applicable | | | AA03514 | AA03527 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.6.0.CSCsu10574 | c12k-k9sec-3.6.0.CSCsu10574 | Not | | 3.6.0 | | | applicable | | | AA03515 | AA03526 | | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.6.1.CSCsu10574 | c12k-k9sec-3.6.1.CSCsu10574 | Not | | 3.6.1 | | | applicable | | | AA03516 | AA03525 | | |---------+----------------------------+-----------------------------+------------| | 3.6.2 | Not affected | Not affected | Not | | | | | applicable | |---------+----------------------------+-----------------------------+------------| | 3.6.3 | Not affected | Not affected | Not | | | | | applicable | |---------+----------------------------+-----------------------------+------------| | | hfr-k9sec-3.7.0.CSCsu10574 | c12k-k9sec-3.7.0.CSCsu10574 | Not | | 3.7.0 | | | applicable | | | AA03519 | AA03522 | | |---------+----------------------------+-----------------------------+------------| | 3.7.1 | Not affected | Not affected | Not | | | | | affected | |---------+----------------------------+-----------------------------+------------| | 3.7.2 | Not affected | Not affected | Not | | | | | affected | |---------+----------------------------+-----------------------------+------------| | 3.8.x | Not affected | Not affected | Not | | | | | applicable | |---------+----------------------------+-----------------------------+------------| | 3.9.x | Not affected | Not affected | Not | | | | | affected | +---------------------------------------------------------------------------------+ (*) Not all Cisco IOS XR Software versions are supported by the Cisco ASR 9000 Aggregation Services Routers. Workarounds =========== There are no workarounds for this vulnerability. Network administrators are advised to apply mitigation techniques to help limit exposure to the vulnerability. Mitigation techniques consist of allowing only legitimate devices to connect to the routers. These access restrictions can be accomplished by using interface access control lists (ACLs) or the Management Plane Protection (MPP) feature that is available in Cisco IOS XR Software Release 3.5 and later. For information on MPP, refer to the configuration guide at http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.8/security/configuration/guide/sc38mpp.html and the MPP command reference at http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.8/security/command/reference/sr38mpp.html. Infrastructure ACLs (iACLs) are also a useful technique to mitigate potential exploitation of this vulnerability. For more information on these mitigations, consult the Cisco Guide to Harden Cisco IOS XR Devices, which is available at http://www.cisco.com/web/about/security/intelligence/CiscoIOSXR.html. Note that access classes in line templates applied to VTY pools are not an effective mitigation for this vulnerability. Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered by Cisco during internal testing. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100120-xr-ssh.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2010-January-20 | Initial public release | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2008-2010 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- Updated: Jan 20, 2010 Document ID: 111459 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktXJ54ACgkQ86n/Gc8U/uAIqgCfaWWIDTslxxJspwldh8PiHYJD WUcAn3jmQ+LHb8nCfKdp6fxuI4LZptpd =4zi1 -----END PGP SIGNATURE----- From surfer at mauigateway.com Wed Jan 20 11:10:22 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Jan 2010 09:10:22 -0800 Subject: Idiotic Newstar Networking Equipment Sales Droid Message-ID: <20100120091022.4436CE8B@resin09.mta.everyone.net> Did anyone here get spam from this idiot? It appears someone is harvesting email addresses from nanog. If you do get any contact from this company PLEASE do not do business with them and tell them you don't buy from spammers. The bottom line is the only thing idiots like this understand and if we buy from them, they'll be encouraged to spam more nanog folks. The guy knows it's wrong as he doesn't even use his own name on the email, so we have to deny purchasing from anyone in the company to have an effect. scott --- Begin forwarded message: From: broadcast at nstnetmail.com To: surfer at mauigateway.com Subject: XENPAK/X2/XFP Date: Wed, 20 Jan 2010 10:28:45 +0800 Hello, How are you? We have below items for hot sale, Sending you the list for reference, please check it, X2-10GB-SR X2-10GB-LR X2-10GB-ER XFP-10G-ER XFP-10G-LR XFP-10G-SR XENPAK-10GB-SR XENPAK-10GB-LR XENPAK-10GB-ER If you have any interested, please contact with me, we will try our best for you,thanks! B.R Helen Newstar Networking Technology Co., Ltd. Email:nstnetworksales at gmail.com Aol: Buyfromnewstar From john-nanog at johnpeach.com Wed Jan 20 11:17:06 2010 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 20 Jan 2010 12:17:06 -0500 Subject: Idiotic Newstar Networking Equipment Sales Droid In-Reply-To: <20100120091022.4436CE8B@resin09.mta.everyone.net> References: <20100120091022.4436CE8B@resin09.mta.everyone.net> Message-ID: <20100120121706.621151f5@jpeach-desktop.anbg.mssm.edu> On Wed, 20 Jan 2010 09:10:22 -0800 "Scott Weeks" wrote: > > > Did anyone here get spam from this idiot? It appears someone is > harvesting email addresses from nanog. > > If you do get any contact from this company PLEASE do not do business > with them and tell them you don't buy from spammers. The bottom line > is the only thing idiots like this understand and if we buy from > them, they'll be encouraged to spam more nanog folks. > > The guy knows it's wrong as he doesn't even use his own name on the > email, so we have to deny purchasing from anyone in the company to > have an effect. I avoid that by only accepting mail to the address I use on this list from nanog.org. I have the reply-to header set to nanog at nanog.org, so no-one should be attempting to mail me directly..... -- John From brunner at nic-naa.net Wed Jan 20 11:33:10 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 20 Jan 2010 12:33:10 -0500 Subject: Katrina response, private and public -- call/fax/email specific congress-critters (please) In-Reply-To: <4B5612F8.3080203@nic-naa.net> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net>, <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <4B5612F8.3080203@nic-naa.net> Message-ID: <4B573E56.2090407@nic-naa.net> Folks, I'm trying to keep the competent engineer count at the Boutilliers NAP from decrementing to zero in the very proximal future. One of several problems being worked by several groups of people. Specifically, I want to get the paperwork done so that Dominique Theodore Guerrier, wife of Reynold Guerrier, Karl Nikolas Guerrier, age 3 and Hann Aurelie Guerrier, age 1, may exit Haiti and travel to Deerfield Beach, Florida, where Reynold's sister lives. If the wife and kids are safe, Reynold will stay on site until relieved. Dominique holds a valid passport, the young children do not. I want some of the NANOG list to do something -- a "write your congress critter" exercise. See below for instructions. Eric ==== There are three avenues to take: tourist visa from State, humanitarian parole from Homeland Security, and a private request by a member of Congress. Of these, the third is the most successful, so that is what I'm asking NANOG contributors to do. Here are the three primary targets: 1. Representative Ron Klein (D-FL), who represents the district in which Reynold's sister lives (Deerfield Beach) 2. Representative Earl Blumenauer (D-OR), who's staff agreed to "look into" the situation. 3. Senators Cantwell and Murray (D-WA) were both forwarded the information on Reynold, but have yet to commit. Ordered by effectiveness, there is calling the member's district office, calling the member's Washington office (particularly if you provide service in or near the Congressional District or State), followed by fax, followed by email (or ugly webform). When communicating with the staffers of members of Congress, please make the point that this is a key human technical resource for the basic function of government. There's not a lot of point in entertaining legislation to certify operators if we are indifferent to whether there is anyone technically competent left to run what remains after a network compromising event of the first magnitude. Feel free to use Reynold's mail to NANOG of the 19th: > To any of you who wants to help: > > We would like to provide to the haitian government a UC systems with several branches: > > * President office: 10 Endpoints > * PM office: 10 endpoints > * 12 mayor city hall offices: 3 for each : 36 endpoints > * Ministries (9 differents locations 3 for each) 27 > * Communications Center 20 > * emergency Clusters 14 > > Total 117 endpoints > > Redundant communications. > > So if someone can provide recommendations, equipment, skilled technician for that it would be fine. > > > Reynold If, after your message across to the initial contact, usually a staffer simply doing phones, you get to an immigration interest, either in the initial staffer, or better, the staffer who handles either immigration requests or technology (see below), and you want me to follow-up, send me email with the contact details and either I or a Cornell Law student will follow-up on the wonk details. In addition to the its-the-right-thing reason, there is a self-interest motivation I want you all to be aware of. The three members (above) and one more, Rep. Chellie Pingree of Maine's 1st CD, are targets because they responded to the Cornell Law effort on MLK Day and yesterday. There is another, larger class of Members to be informed -- the Members who currently sit on the House Committee on Science and Technology and the House Committee on Commerce and Energy. Our collective self-interest in informing these Members is that we, as operators, big and small, are capable of issue advocacy. They already know that our employers, particularly the big ones, are capable of issue advocacy ;-) Committee on Science and Technology: http://science.house.gov/about/members.shtml Commerce and Energy: http://energycommerce.house.gov/index.php?option=com_content&view=category&layout=blog&id=160&Itemid=61 Having completed this exercise, please drop me a line at brunner at nic-naa.net so I can keep count of how many inputs went into the system, and where, and possibly infer a causal relation between outputs, if any, and inputs, and routing within the system. ==== From cmadams at hiwaay.net Wed Jan 20 11:46:56 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 20 Jan 2010 11:46:56 -0600 Subject: Idiotic Newstar Networking Equipment Sales Droid In-Reply-To: <20100120091022.4436CE8B@resin09.mta.everyone.net> References: <20100120091022.4436CE8B@resin09.mta.everyone.net> Message-ID: <20100120174656.GB1303415@hiwaay.net> Once upon a time, Scott Weeks said: > Did anyone here get spam from this idiot? It appears someone is harvesting email addresses from nanog. I've been added to several used-equipment sales droids lists after posting here; I just procmail them straigt to the spam folder. I've also been recently added to some Internap newsletter list (without even an opt-out option). Way to make sure I never buy from you! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mylists at battleop.com Wed Jan 20 12:01:32 2010 From: mylists at battleop.com (Richey) Date: Wed, 20 Jan 2010 13:01:32 -0500 Subject: Idiotic Newstar Networking Equipment Sales Droid In-Reply-To: <20100120174656.GB1303415@hiwaay.net> References: <20100120091022.4436CE8B@resin09.mta.everyone.net> <20100120174656.GB1303415@hiwaay.net> Message-ID: <03d701ca99fa$99792e90$cc6b8bb0$@battleop.com> These guys don't get it. IF they call and pester me they miss out on a lot of sales. Richey -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Wednesday, January 20, 2010 12:47 PM To: nanog at merit.edu Subject: Re: Idiotic Newstar Networking Equipment Sales Droid Once upon a time, Scott Weeks said: > Did anyone here get spam from this idiot? It appears someone is harvesting email addresses from nanog. I've been added to several used-equipment sales droids lists after posting here; I just procmail them straigt to the spam folder. I've also been recently added to some Internap newsletter list (without even an opt-out option). Way to make sure I never buy from you! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From maxlarson.henry at mtptc.gouv.ht Wed Jan 20 12:20:39 2010 From: maxlarson.henry at mtptc.gouv.ht (Max Larson Henry) Date: Thu, 21 Jan 2010 02:20:39 +0800 Subject: Katrina response, private and public In-Reply-To: References: <4B508C67.5000309@nic-naa.net> <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> Message-ID: <90155a1e1001201020i22b3e39w3b86c67bf924bb8f@mail.gmail.com> > > "Bahamas Telecommunications Company (BTC), the service provider that runs > the Bahamas Domestic Submarine Network (BDSNi) submarine cable system > linking to Haiti, reported that service has been disrupted as a result of > the earthquake that struck the Port-au-Prince area." - The Teleco Facility that receive the fiber is completely broken (dust) but must of the Technicians are alive and in Port au Prince -M From smb at cs.columbia.edu Wed Jan 20 12:33:48 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 20 Jan 2010 13:33:48 -0500 Subject: Katrina response, private and public In-Reply-To: <90155a1e1001201020i22b3e39w3b86c67bf924bb8f@mail.gmail.com> References: <4B508C67.5000309@nic-naa.net> <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> <90155a1e1001201020i22b3e39w3b86c67bf924bb8f@mail.gmail.com> Message-ID: <50DAD568-349D-499B-A4FB-57444EA254D7@cs.columbia.edu> On Jan 20, 2010, at 1:20 PM, Max Larson Henry wrote: >> >> "Bahamas Telecommunications Company (BTC), the service provider that runs >> the Bahamas Domestic Submarine Network (BDSNi) submarine cable system >> linking to Haiti, reported that service has been disrupted as a result of >> the earthquake that struck the Port-au-Prince area." > > > - The Teleco Facility that receive the fiber is completely broken (dust) but > must of the Technicians are alive and in Port au Prince > There's an article on the subject in today's Wall Street Journal: http://online.wsj.com/article/SB10001424052748703657604575005453223257096.html -- not sure if it's behind the paywall or not. --Steve Bellovin, http://www.cs.columbia.edu/~smb From surfer at mauigateway.com Wed Jan 20 12:43:27 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Jan 2010 10:43:27 -0800 Subject: Idiotic Newstar Networking Equipment Sales Droid Message-ID: <20100120104327.44174538@resin11.mta.everyone.net> If they see all of us saying we won't buy from them when they do idiotic things like spamming nanog folks (I can't think of too many groups it world be worse to spam... ;-) they will realize that doing this will not only not generate sales, it will actually prevent future sales from occurring. scott --- mylists at battleop.com wrote: From: "Richey" These guys don't get it. IF they call and pester me they miss out on a lot of sales. -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] option). Way to make sure I never buy from you! From jim at reptiles.org Wed Jan 20 12:46:58 2010 From: jim at reptiles.org (Jim Mercer) Date: Wed, 20 Jan 2010 13:46:58 -0500 Subject: Idiotic Newstar Networking Equipment Sales Droid In-Reply-To: <20100120104327.44174538@resin11.mta.everyone.net> References: <20100120104327.44174538@resin11.mta.everyone.net> Message-ID: <20100120184658.GA87040@reptiles.org> On Wed, Jan 20, 2010 at 10:43:27AM -0800, Scott Weeks wrote: > If they see all of us saying we won't buy from them when they do idiotic things like spamming nanog folks (I can't think of too many groups it world be worse to spam... ;-) they will realize that doing this will not only not generate sales, it will actually prevent future sales from occurring. you are assuming they actually read the list. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 dmm at 1-4-5.net Tue Jan 19 17:07:51 2010 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 19 Jan 2010 15:07:51 -0800 Subject: [NANOG-announce] NANOG 48 is coming up Message-ID: <20100119230751.GB6024@1-4-5.net> Stretch your travel dollar further by registering now for NANOG 48, February 21-24, co-hosted by Data Foundry and Giganews in Austin, Texas. The early registration rate prevails through January 21, and the discounted hotel rate expires February 5 or when the room block is full. Rooms are limited so make your reservation soon. We have a great meeting planned, and you can review the draft agenda at http://www.nanog.org/meetings/nanog48/agenda.php. Hotel and travel information, meeting registration, and a list of meeting sponsors and sponsorship opportunities are available through http://www.nanog.org/meetings/nanog48/index.php. Look forward to seeing you there, David Meyer (for the NANOG Program Committee) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From paul at telcodata.us Wed Jan 20 14:50:21 2010 From: paul at telcodata.us (Paul Timmins) Date: Wed, 20 Jan 2010 15:50:21 -0500 Subject: Idiotic Newstar Networking Equipment Sales Droid In-Reply-To: <20100120104327.44174538@resin11.mta.everyone.net> References: <20100120104327.44174538@resin11.mta.everyone.net> Message-ID: <4B576C8D.6030507@telcodata.us> Scott Weeks wrote: > If they see all of us saying we won't buy from them when they do idiotic things like spamming nanog folks (I can't think of too many groups it world be worse to spam... ;-) they will realize that doing this will not only not generate sales, it will actually prevent future sales from occurring. > > scott > If their ISP is on the list, they could have a nice calm chat about their AUP and that would probably end the conversation for everyone... From bdfleming at kanren.net Wed Jan 20 16:04:40 2010 From: bdfleming at kanren.net (Brad Fleming) Date: Wed, 20 Jan 2010 16:04:40 -0600 Subject: 10Gbps Traffic Test Systems Message-ID: I am in the market for 10Gbps traffic testers. Here are some of the things I'd like to have: 1) Mixed packet sizes 2) Ramp TCP sessions up/down quickly 3) Many source and destination IPs 4) Ability to ramp traffic up and down 5) Simulate targeted SYN floods 6) 10,000+ packets per second We'll use these devices to test throughput and resource utilization on routers and firewalls/security systems. We'll also test and prove candidate QoS configurations (ie: DSCP41 still works well even when DSCP11 is saturating links). The catch is that I work for a charitable, non-profit with limited resources. I understand you can't have steak on a sardine budget; I'm just trying to find suggestions on a testing platform for "thrifty" customers! We do not have any existing testing systems other than iPerf on a Mac Mini. Any suggestions, either on-list or off, are welcome and appreciated. Brad Fleming From nanog at daork.net Wed Jan 20 17:54:11 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 21 Jan 2010 12:54:11 +1300 Subject: 10Gbps Traffic Test Systems In-Reply-To: References: Message-ID: <781D0092-DFF6-4846-B638-B4224F467850@daork.net> I have used Ixia, Spirent AX/4000, Spirent Testcenter and Spirent Smartbits for 1-10GE testing, they've all been able to do the things you ask for - they are quite basic features and any 10GE "router tester" unit will do what you want. In addition, you should demand much higher than 10Kpps, you should be able to fit roughly 120Mpps of TCP SYN packets in to a 10GE ethernet pipe. On 21/01/2010, at 11:04 AM, Brad Fleming wrote: > I am in the market for 10Gbps traffic testers. > > Here are some of the things I'd like to have: > 1) Mixed packet sizes > 2) Ramp TCP sessions up/down quickly > 3) Many source and destination IPs > 4) Ability to ramp traffic up and down > 5) Simulate targeted SYN floods > 6) 10,000+ packets per second > > We'll use these devices to test throughput and resource utilization on routers and firewalls/security systems. We'll also test and prove candidate QoS configurations (ie: DSCP41 still works well even when DSCP11 is saturating links). > > The catch is that I work for a charitable, non-profit with limited resources. I understand you can't have steak on a sardine budget; I'm just trying to find suggestions on a testing platform for "thrifty" customers! We do not have any existing testing systems other than iPerf on a Mac Mini. > > Any suggestions, either on-list or off, are welcome and appreciated. > > Brad Fleming > > > !DSPAM:22,4b577e41217795602264856! > > From babydr at baby-dragons.com Wed Jan 20 20:29:34 2010 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Wed, 20 Jan 2010 17:29:34 -0900 (AKST) Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <28119.1263999124@localhost> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> <28119.1263999124@localhost> Message-ID: Hello Valdis , On Wed, 20 Jan 2010, Valdis.Kletnieks at vt.edu wrote: > On Wed, 20 Jan 2010 08:01:50 CST, Jorge Amodio said: > >> Ohh yeah, now we can send sort of a telegram with multiple fonts and >> colors almost from anywhere... > > At least it doesn't do BLINK ;) > Are we really sure of this ?-} Wave of the future 3x the amount of data for 1/3 the information . Toodles , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From sfouant at shortestpathfirst.net Wed Jan 20 20:32:11 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 20 Jan 2010 21:32:11 -0500 Subject: 10Gbps Traffic Test Systems In-Reply-To: References: Message-ID: <01bb01ca9a41$f0787ba0$d16972e0$@net> > -----Original Message----- > From: Brad Fleming [mailto:bdfleming at kanren.net] > Sent: Wednesday, January 20, 2010 5:05 PM > > I am in the market for 10Gbps traffic testers. > > Here are some of the things I'd like to have: > 1) Mixed packet sizes > 2) Ramp TCP sessions up/down quickly > 3) Many source and destination IPs > 4) Ability to ramp traffic up and down > 5) Simulate targeted SYN floods > 6) 10,000+ packets per second > > We'll use these devices to test throughput and resource utilization on > routers and firewalls/security systems. We'll also test and prove > candidate QoS configurations (ie: DSCP41 still works well even when > DSCP11 is saturating links). > > The catch is that I work for a charitable, non-profit with limited > resources. I understand you can't have steak on a sardine budget; I'm > just trying to find suggestions on a testing platform for "thrifty" > customers! We do not have any existing testing systems other than > iPerf on a Mac Mini. Testing QoS generally requires highly specialized equipment that can send at line-rate and has highly accurate timing. This is necessary to analyze the impacts of latency and jitter, in addition to testing the impact of throughput in multi-queue prioritization tests. Likely this means that the cheaper options are not sufficient unfortunately, and doubly so because you want 10Gbps. I have used Spirent, Ixia, and Agilent boxes with great success, especially in the area of QoS testing. Any one of these should be able to perform well with all of the requirements stated above. Don't go for the Breakingpoint box unless you enjoy banging your head against the wall when you can't do many of the things they claim to be able to do - I was once a proponent of theirs until I really got under the hood, save yourself the headache and look at the other alternatives. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From woody at pch.net Wed Jan 20 20:47:45 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 20 Jan 2010 18:47:45 -0800 Subject: Katrina response, private and public In-Reply-To: References: <4B508C67.5000309@nic-naa.net> <4B523F68.6080305@nic-naa.net> <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <8CC79DE8-AE4E-4D94-A6E9-FEC11A216645@pch.net> Message-ID: On Jan 19, 2010, at 3:56 PM, Martin Hannigan wrote: > Re your plan to potentially run a cable from SD to PaP. Interesting. Looks like 300nm to me. I think you're going to need op amp and power. The idea was to do a festoon cable instead, landing at coastal towns along the way, and using Ethernet switches to break out local service as well as repeating signal. > On the Columbus run, they're going to need a landing station. Yep, I expect they hope that the situation will work in their favor, and that they'll be granted one, which would break Teleco's current landing monopoly. > I'm going to speculate that this is part of BTC's problem; no landing station of the subsea route was disrupted by the quake The landing station building collapsed. There's no evidence of any damage to the fiber, though that's possible as well. > I'd be thinking microwave and towers. Faster. Cheaper. They've already got that, but "faster" only in the sense that it's already done... They're limited to a few STM1s, which were quickly overwhelmed by the relief workers. This is a common problem in disaster relief, we saw it particularly when we were working in Indonesia and Thailand during the tsunami... An area that had quite modest Internet usage, and infrastructure which may not be great, but is sufficient to its present requirements, gets a flood of relief workers in who all want to use Skype simultaneously, and determine that the perfectly-functional and previously-sufficient Internet is "broken" and needs to be reengineered. The existing chain of microwave relays is the Haitian ISPs' fix for the problem of Teleco having a monopoly fiber landing and setting astronomical prices on access to it. I'm not interested in reengineering anything, but I am interested in making sure that if aid money goes to the incumbent to fix their fiber, at least the community gets something out of it in the form of the monopoly being broken. Otherwise the fiber being fixed does no one any good, because they still won't be able to use it, same as before the earthquake. It's very easy to spend money and make things worse than they were before. -Bill -------------- 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 springer.dennis at gmail.com Wed Jan 20 20:54:06 2010 From: springer.dennis at gmail.com (Doc Holiday) Date: Wed, 20 Jan 2010 20:54:06 -0600 Subject: 10Gbps Traffic Test Systems In-Reply-To: <01bb01ca9a41$f0787ba0$d16972e0$@net> References: <01bb01ca9a41$f0787ba0$d16972e0$@net> Message-ID: <7ed19b101001201854t456f97bfhcf4ad68c86eeba76@mail.gmail.com> Rent a EXFO TGE packet blazer On 1/20/10, Stefan Fouant wrote: >> -----Original Message----- >> From: Brad Fleming [mailto:bdfleming at kanren.net] >> Sent: Wednesday, January 20, 2010 5:05 PM >> >> I am in the market for 10Gbps traffic testers. >> >> Here are some of the things I'd like to have: >> 1) Mixed packet sizes >> 2) Ramp TCP sessions up/down quickly >> 3) Many source and destination IPs >> 4) Ability to ramp traffic up and down >> 5) Simulate targeted SYN floods >> 6) 10,000+ packets per second >> >> We'll use these devices to test throughput and resource utilization on >> routers and firewalls/security systems. We'll also test and prove >> candidate QoS configurations (ie: DSCP41 still works well even when >> DSCP11 is saturating links). >> >> The catch is that I work for a charitable, non-profit with limited >> resources. I understand you can't have steak on a sardine budget; I'm >> just trying to find suggestions on a testing platform for "thrifty" >> customers! We do not have any existing testing systems other than >> iPerf on a Mac Mini. > > Testing QoS generally requires highly specialized equipment that can send at > line-rate and has highly accurate timing. This is necessary to analyze the > impacts of latency and jitter, in addition to testing the impact of > throughput in multi-queue prioritization tests. Likely this means that the > cheaper options are not sufficient unfortunately, and doubly so because you > want 10Gbps. > > I have used Spirent, Ixia, and Agilent boxes with great success, especially > in the area of QoS testing. Any one of these should be able to perform well > with all of the requirements stated above. Don't go for the Breakingpoint > box unless you enjoy banging your head against the wall when you can't do > many of the things they claim to be able to do - I was once a proponent of > theirs until I really got under the hood, save yourself the headache and > look at the other alternatives. > > Stefan Fouant, CISSP, JNCIE-M/T > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > > -- Sent from my mobile device Kind Regards, Dennis Springer I'm your huckleberry - Doc Holiday - From the movie Tombstone. From steve at ibctech.ca Wed Jan 20 20:54:50 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 20 Jan 2010 21:54:50 -0500 Subject: Enhancing automation with network growth Message-ID: <4B57C1FA.5000207@ibctech.ca> Hi all, I'm reaching the point where adding in a new piece of infrastructure hardware, connecting up a new cable, and/or assigning address space to a client is nearly 50% documentation and 50% technical. One thing that would take a major load off would be if my MRTG system could simply update its config/index files for itself, instead of me having to do it on each and every port change. Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). Unless something else is out there that I've missed, I'm seriously considering writing up a module in Perl to put up on the CPAN that can scan my RANCID logs (and perhaps the devices directly for someone who doesn't use RANCID), send an aggregate 'are these changes authorized' email to an engineer, and then proceed to execute the proper commands within the proper MRTG directories if the engineer approves. I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for switches, so it is not as simple as throwing a single command at all configs. All feedback welcome, especially if you are in the same boat. My IP address documentation/DNS is far more important than my traffic stats, but it really hurts when you've forgotten about a port three months ago that you need to know about now. Steve From erik_list at caneris.com Wed Jan 20 21:52:39 2010 From: erik_list at caneris.com (Erik L) Date: Wed, 20 Jan 2010 22:52:39 -0500 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: > > I'm reaching the point where adding in a new piece of infrastructure > hardware, connecting up a new cable, and/or assigning address > space to a > client is nearly 50% documentation and 50% technical. > A common problem :) > One thing that would take a major load off would be if my MRTG system > could simply update its config/index files for itself, instead of me > having to do it on each and every port change. > > Can anyone offer up ideas on how you manage any automation in this > regard for their infrastructure gear traffic graphs? > (Commercial options > welcome, off-list, but we're as small as our budget is). > Not sure how you're doing your graphs currently, but have you considered Cacti? > I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for > switches, so it is not as simple as throwing a single command at all > configs. > > All feedback welcome, especially if you are in the same boat. My IP > address documentation/DNS is far more important than my traffic stats, > but it really hurts when you've forgotten about a port three > months ago > that you need to know about now. > First, I'll throw out a bit of what we do and it might give some ideas, though not necessarily good ones. We use Linux/Quagga routers, in-house-modified Linux-based LNSs, and HP switches. Some of our configuration and change management is done via cfengine, backed by subversion. The latter yields the added benefit of revision control and all the other good stuff you can get from svn in such a scenario. Unfortunately this is only part of the config/graphs/docs/DNS/IPs/OSS equation and we don't have everything fully integrated yet (nor is there a business case for it at the moment). Some of our OSS is based on a heavily in-house modified version of Freeside as well as our own app/layer that sits on top. This is essentially our base system which allows us to push data and prov services to other internal and external systems - e.g. DNS, IP assignment, vendor's portals/APIs, RADIUS, etc. (basically almost every piece of hardware and software we have) and which interfaces with our self-service (customer portal - aka the almighty call-avoidance "solution"). We also use IPPlan for managing IP assignment, but are moving away from it. In a perfect world, everything would be integrated with everything else, searching by every data element would be possible, every business process would be automated, all of your docs would be in one place, all linked to the network element / customer / ticket / order / whatever, and so on. For most organizations, this is neither feasible nor required. Each system tends to do one or two things well and you have much unavoidable data duplication and data moving back and forth. Usually the goal is to minimize the amount of manual data entry down to a single time and to push this aspect out towards the customer as much as possible. The extent of that will depend on your specific environment - everyone basically does the same thing, so often there's no need to re-invent the wheel (i.e. "let's develop everything from scratch in-house" is a very bad move - you're not in the OSS business). OSS/BSS is a huge and complex topic, so I'm only touching the tip of the iceberg here and speaking mostly in general terms. It's definitely something that will be of greater and greater importance as your network grows, so early planning is key, but don't get carried away trying to automate the hell out of everything because you'll lose focus on what you need to do in the short-term. There is often a naive pursuit of perfection in OSS/BSS by those who haven't been doing it for long enough - don't fall into that trap. I'd start by defining your requirements/scope more solidly and then considering whether it makes sense to try to automate or enhance a particular process. It may help to break things down step-by-step, perhaps based on dependencies or some other logical order, then think about how you would eliminate what you perceive to be manual/error-prone/inefficient/slow/whatever. From a costing perspective, you might find yourself in a (unfortunately frequently encountered by some) situation of "I just spent 50 hours writing a program to automate a task that would have taken me 2 hours to do manually" or "we just spent $50k buying a product which we won't use to any reasonable level of capacity for the next five years". -- Erik *** Remove the _list part in my e-mail address to reply. *** From cmadams at hiwaay.net Wed Jan 20 22:16:09 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 20 Jan 2010 22:16:09 -0600 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: <20100121041609.GA1320247@hiwaay.net> Once upon a time, Steve Bertrand said: > One thing that would take a major load off would be if my MRTG system > could simply update its config/index files for itself, instead of me > having to do it on each and every port change. Is MRTG a requirement, or just some type of statistical monitoring? There are other packages that can do (or be made to do) what you want. I switched from MRTG to Cricket many years ago, and a big improvement there is that you configure interface names (and Cricket handles tracking the index). There are add-ons like genDevConfig (replaces genRtrConfig) that can auto-generate configs for you. The only downside to Cricket is that development has stagnated (I think it is a case of "it works for me" for most everybody using it). There's also Cacti, which is newer and more current. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Jonathon.Exley at kordia.co.nz Wed Jan 20 22:20:24 2010 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 21 Jan 2010 17:20:24 +1300 Subject: 10Gbps Traffic Test Systems Message-ID: <9C3036CB473E8E4DA5821A2C0246C877E437773E@winexmp01> I have done QoS testing using Endace DAG cards - they can do capture as well as traffic generation. See http://www.endace.com/dag-8.1sx.html Jonathon This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From ops.lists at gmail.com Wed Jan 20 22:28:11 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 21 Jan 2010 09:58:11 +0530 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: This should help with part of what you're doing - snmpstat and cisco config repository. http://snmpstat.sourceforge.net/ On Thu, Jan 21, 2010 at 8:24 AM, Steve Bertrand wrote: > > One thing that would take a major load off would be if my MRTG system > could simply update its config/index files for itself, instead of me > having to ?do it on each and every port change. -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 20 22:29:59 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Jan 2010 14:59:59 +1030 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> Message-ID: <20100121145959.24290e9a@opy.nosense.org> On Wed, 20 Jan 2010 08:01:50 -0600 Jorge Amodio wrote: > > "The telephone, for those of you who have forgotten, was a commonly used > > communications technology in the days before electronic mail. > > They're still easy to find in most large cities." -- Nathaniel Borenstein > > > > i'm guessing this is before the mobile phone explosion. > > Good old one. > > It's funny how we circle around with technology, folks are dumping > their phone land lines and adopting wireless/mobile that required a > substantial technology leap and investment and now we are using the > mobile phone to "text" an incompressible dialect worse than the early > teletype/telex days but with a humongous infrastructure to support it. > I'm not sure how it is in other countries, but here in .au they're a fixed and predictable price before you pay it, are significantly cheaper than an equivalent phone call, and if you have anything that requires accurate recording e.g. email addresses, geo addresses or phone numbers, far less prone to errors. 25c for a text with 160 characters, or 50c flag fall for a phone call before I've even said a word and I don't know how many I'm going to say? I know which one I'm going to prefer.. > Ohh yeah, now we can send sort of a telegram with multiple fonts and > colors almost from anywhere... > > Cheers > Jorge > From ras at e-gerbil.net Wed Jan 20 23:13:19 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 20 Jan 2010 23:13:19 -0600 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: <20100121051318.GI75640@gerbil.cluepon.net> On Wed, Jan 20, 2010 at 09:54:50PM -0500, Steve Bertrand wrote: > Hi all, > > I'm reaching the point where adding in a new piece of infrastructure > hardware, connecting up a new cable, and/or assigning address space to > a client is nearly 50% documentation and 50% technical. > > One thing that would take a major load off would be if my MRTG system > could simply update its config/index files for itself, instead of me > having to do it on each and every port change. It is really quite trivial to auto-discover ifindex->ifdescr mappings on every poll cycle then track your interfaces by their names, pretty much every modern poller system can manage this. MRTG is absurdly old, slow, and generally nasty, and should not be used by anyone in this day and age. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From dwhite at olp.net Thu Jan 21 00:13:34 2010 From: dwhite at olp.net (Dan White) Date: Thu, 21 Jan 2010 00:13:34 -0600 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: <20100121061334.GB14173@dan.olp.net> On 20/01/10?21:54?-0500, Steve Bertrand wrote: >Can anyone offer up ideas on how you manage any automation in this >regard for their infrastructure gear traffic graphs? (Commercial options >welcome, off-list, but we're as small as our budget is). > >Unless something else is out there that I've missed, I'm seriously >considering writing up a module in Perl to put up on the CPAN that can >scan my RANCID logs (and perhaps the devices directly for someone who >doesn't use RANCID), send an aggregate 'are these changes authorized' >email to an engineer, and then proceed to execute the proper commands >within the proper MRTG directories if the engineer approves. > >I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for >switches, so it is not as simple as throwing a single command at all >configs. OpenNMS works great, but has a steeper learning curve than MRTG. It supports auto discovery of devices, and can pull interface statistics for all new devices/interfaces automatically. I'm graphing all interfaces on around 4 dozen Cisco switches and routers and various other devices on one fairly beefy Linux box. It also has a RANCID integration module, which I haven't had a chance to play with yet. > it is not as simple as throwing a single command at all configs Actually it is that simple. As long as the device supports the IF-MIB SNMP table, then your SNMP system should have little problem discovering all interfaces. All devices you list above should work, assuming you've got net-snmp running on the freebsd box. -- Dan White From randy at psg.com Thu Jan 21 01:25:54 2010 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jan 2010 16:25:54 +0900 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> Message-ID: > It's funny how we circle around with technology, folks are dumping > their phone land lines and adopting wireless/mobile that required a > substantial technology leap and investment and now we are using the > mobile phone to "text" an incompressible dialect worse than the early > teletype/telex days but with a humongous infrastructure to support it. and paying and exhorbitant price per word for negligible bandwidth. run your own servers or use a friend's and use email randy From karnaugh at karnaugh.za.net Thu Jan 21 02:36:50 2010 From: karnaugh at karnaugh.za.net (Colin) Date: Thu, 21 Jan 2010 10:36:50 +0200 Subject: Idiotic Newstar Networking Equipment Sales Droid In-Reply-To: <20100120104327.44174538@resin11.mta.everyone.net> References: <20100120104327.44174538@resin11.mta.everyone.net> Message-ID: <78bfcf051001210036s5fc1e32ci6c1ad926d39b18e2@mail.gmail.com> On Wed, Jan 20, 2010 at 8:43 PM, Scott Weeks wrote: > > > If they see all of us saying we won't buy from them when they do idiotic > things like spamming nanog folks (I can't think of too many groups it world > be worse to spam... ;-) they will realize that doing this will not only not > generate sales, it will actually prevent future sales from occurring. > > > First thing I ask anyone who phones me is where they got my contact information. If their answer starts with "uhhh", the phone gets hung up ;) From bill at edisys.co.uk Thu Jan 21 03:27:45 2010 From: bill at edisys.co.uk (William Hamilton) Date: Thu, 21 Jan 2010 09:27:45 +0000 Subject: OT: old farts recollecting -- Re: ASR1002 In-Reply-To: References: <4a80ecce1001061636y1a455246peaf75aec925ccc0@mail.gmail.com> <201001191550193802132@gmail.com> <1263909572.18086.40.camel@ub-g-d2> <20100119160001.GA30743@reptiles.org> <1263923324.10985.4.camel@ub-g-d2> <18a5e7cb1001191742sa77d955u188f3d282faaf2c8@mail.gmail.com> <1263976252.1183.20.camel@ub-g-d2> <20100120083534.GA63987@reptiles.org> <202705b1001200601r5bbedc2fl6578926cde45ae0c@mail.gmail.com> Message-ID: <4B581E11.2080707@edisys.co.uk> On 21/01/2010 07:25, Randy Bush wrote: >> It's funny how we circle around with technology, folks are dumping >> their phone land lines and adopting wireless/mobile that required a >> substantial technology leap and investment and now we are using the >> mobile phone to "text" an incompressible dialect worse than the early >> teletype/telex days but with a humongous infrastructure to support it. > > and paying and exhorbitant price per word for negligible bandwidth. > > run your own servers or use a friend's and use email > I don't know about anyone else, but the vast majority of my non-tech friends (and even most of my tech ones) don't use email on their phone. Anyone (i.e. everyone I know) who has a mobile phone has the ability to receive an SMS and some things in life are far too much hassle to nickel and dime over the cost per word of sending a communication - life is too short. B From pekkas at netcore.fi Thu Jan 21 05:34:51 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 21 Jan 2010 13:34:51 +0200 (EET) Subject: 2009 Worldwide Infrastructure Security Report available for download. In-Reply-To: <017a01ca99e5$c4dcddd0$4e969970$@net> References: <017a01ca99e5$c4dcddd0$4e969970$@net> Message-ID: On Wed, 20 Jan 2010, Stefan Fouant wrote: > Completely agree on the disturbing observation of the increase in > rate-limiting as a primary mitigation mechanism for dealing with DDoS. I've > seen more and more people using this as a mitigation strategy, against my > advice. For anyone interested in more information on the topic, and why > rate-limiting is akin to cutting your foot off, I highly recommend you take > a look at the paper "Effectiveness of Rate-Limiting in Mitigating Flooding > DoS Attacks" presented by Jarmo Molsa at the Third IASTED International > conference. Thanks to Arbor for collecting the report and your observations. One thing I found extremely strange is that almost 50% report they use BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer direction. (Figure 13, p20) I wonder if peering edge refers to "drop your own addresses" or real strict uRPF (or the like)? If not I'm curious if this is for real, and how in earth they're doing it, especially given that in Fig 15 (p22) shows they don't implement BGP prefix filtering. If you can't filter BGP, how could you filter packets? Based on my experience, even if you filter BGP, you may not be able to filter packets except in simple scenarios. -- 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 pfs at cisco.com Thu Jan 21 06:04:01 2010 From: pfs at cisco.com (Philip Smith) Date: Thu, 21 Jan 2010 22:04:01 +1000 Subject: Speaking slots at APRICOT 2010 still available Message-ID: <4B5842B1.5010009@cisco.com> Hi everyone, For those folks who may be going to NANOG 48 in Austin at the end of February, how about extending that trip a little and heading over to Kuala Lumpur in Malaysia for APRICOT which conveniently takes place the following week. :-) We still have a few speaking slots available for the main conference (which runs from Monday 1st to Thursday 4th March). If you have a presentation that you think might be of interest to the network operators in the Asia & Pacific region, the Program Committee would be delighted to hear from you. There is more info in the CfP: http://www.apricot2010.net/contribute/call-for-papers, but to submit a presentation proposal simply go to http://submission.apricot.net/paper/user/index.php?event=22 to submit title, abstract and your draft slides. Many thanks for reading, now back to regular programming... :-) philip For the APRICOT Program Committee -- From steve at ibctech.ca Thu Jan 21 08:21:55 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 21 Jan 2010 09:21:55 -0500 Subject: 2009 Worldwide Infrastructure Security Report available for download. In-Reply-To: References: <017a01ca99e5$c4dcddd0$4e969970$@net> Message-ID: <4B586303.4090805@ibctech.ca> Pekka Savola wrote: > On Wed, 20 Jan 2010, Stefan Fouant wrote: >> Completely agree on the disturbing observation of the increase in >> rate-limiting as a primary mitigation mechanism for dealing with >> DDoS. I've >> seen more and more people using this as a mitigation strategy, against my >> advice. For anyone interested in more information on the topic, and why >> rate-limiting is akin to cutting your foot off, I highly recommend you >> take >> a look at the paper "Effectiveness of Rate-Limiting in Mitigating >> Flooding >> DoS Attacks" presented by Jarmo Molsa at the Third IASTED International >> conference. > > Thanks to Arbor for collecting the report and your observations. Indeed. > One thing I found extremely strange is that almost 50% report they use > BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer > direction. (Figure 13, p20) > > I wonder if peering edge refers to "drop your own addresses" or real > strict uRPF (or the like)? Depends. It can do that, BOGON, and any other prefix you want your edge to discard. I would imagine that it would be difficult to use strict uRPF on a peering interface though, as packets through that peer may be received on a different interface than it was sent on (in a multi-homing situation). I do strict uRPF for any directly connected clients (SDSL, fibre, collocation etc) that are single-homed. It's literally one command on a router interface that is connected to the switch (subnet) of aggregated clients. For our clients that multi-home into two of our different edge gear via BGP, I use loose uRPF. This allows fail-over without packets being dropped. In some multi-homed client cases, I can get away with using strict. This is possible in situations where a client has one high-bandwidth link and one low-bandwidth link in a fail-over-only case. If BGP is set up correctly, the secondary link will never be used until the primary goes down. All packets are sent/received on the only interface in the network that knows about the client prefix, so it works. If the primary fails, the secondary takes over completely, so again, strict works. Loose uRPF allows a packet to come into any valid interface (and you can even allow default route). This seems counter-intuitive, however, the important point to note is that once uRPF is enabled even in loose mode, it will effectively allow you to drop based on source address when combined with RTBH on any interface it is configured on. > If not I'm curious if this is for real, and how in earth they're doing > it, especially given that in Fig 15 (p22) shows they don't implement BGP > prefix filtering. If you can't filter BGP, how could you filter > packets? Based on my experience, even if you filter BGP, you may not be > able to filter packets except in simple scenarios. This isn't about packet 'filtering', it's about 'dropping' (or sinking). Essentially, in a uRPF [S/]RTBH setup, your edge routers are configured with routes that point to a special address that is destined (eventually) to null (usually this is automated...the routes are sent to the edge via a 'trigger' box). When a packet comes in (or attempts to go out) of the interface configured with uRPF, the system treats the null route as best-path, and discards (or forwards) it. This setup does not require you to have ANY eBGP whatsoever, and also works in deployments where all of your eBGP peers are sending only default. As long as you have iBGP to all edge devices, this setup is pretty trivial to configure. Throw in a Team Cymru route-server peering on your trigger box, and you've automated BOGON management network-wide. I don't think I explained this very clearly (hopefully it was accurate... it is early in the morning ;). Here is a decent 'howto': http://www.packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/ Steve From rar at syssrc.com Thu Jan 21 09:23:42 2010 From: rar at syssrc.com (rar) Date: Thu, 21 Jan 2010 10:23:42 -0500 Subject: UC phone system for Haiti (was Katrina Response) In-Reply-To: <9ab36b821001191439s8568498ha61ad495341e570d@mail.gmail.com> References: <4B508C67.5000309@nic-naa.net><9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com><4B523F68.6080305@nic-naa.net> <4B53970B.7050600@nic-naa.net><11B064048F34FD4094CBA16FC04BE2198638C676@ex01><4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net><4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net><67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <9ab36b821001191439s8568498ha61ad495341e570d@mail.gmail.com> Message-ID: <15BDDC14871D2A49BFCEEEF409EB29830323771A@exchange.syssrcad.syssrc.com> I am willing to help/lead this effort. Bob Roswell System Source broswell at syssrc.com (410) 771-5544 ext 4336 -----Original Message----- From: Reynold Guerrier [mailto:reygue at gmail.com] Sent: Tuesday, January 19, 2010 5:39 PM To: Rodney Joffe Cc: nanog at nanog.org Subject: Re: Katrina response, private and public To any of you who wants to help: We would like to provide to the haitian government a UC systems with several branches: - President office: 10 Endpoints - PM office: 10 endpoints - 12 mayor city hall offices: 3 for each : 36 endpoints - Ministries (9 differents locations 3 for each) 27 - Communications Center 20 - emergency Clusters 14 Total 117 endpoints Redundant communications. So if someone can provide recommendations, equipment, skilled technician for that it would be fine. Reynold On Tue, Jan 19, 2010 at 2:27 PM, Rodney Joffe wrote: > > > On Jan 19, 2010, at 11:31 AM, Eric Brunner-Williams wrote: > > I've no idea. I've just been focused on moving the "dry tank" moment to >> the right, along with several others. Mind, this was the first resupply, its >> not a stable replenishment schedule yet. >> >> The engineers on site had (as of yesterday) personal food and water >> through Thursday, and dependents in need. >> > > Is there anything that any of us cab do to help, exert influence, etc > (short of donating which many of us are already doing). > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From dylan.ebner at crlmed.com Thu Jan 21 09:29:30 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 21 Jan 2010 15:29:30 +0000 Subject: Hardware recommendations for DWDM Message-ID: <017265BF3B9640499754DD48777C3D206717F09D3C@MBX9.EXCHPROD.USA.NET> Hi everyone. I am looking for some recommendations on implementation and hardware to handle a DWDM at 500Mbps with growth to 1Gbps over the next 2 years. My experience stops at 100Mb Ethernet services but my company may be taking on a large account that would dramatically increase our needs for additional bandwidth. We will most likely have an Ethernet over PTP DWDM circuit with metro Ethernet as a backup via iBGP or EIGRP. The routers or switches need to be able to carry the traffic as well as stateless access list at the same time. There is the possibility a need of needed stateful inspect as well on one of the routers/switches. So, what kind of hardware do you guys think is needed? Any input is appreciated. thanks From abhishekv.verma at gmail.com Thu Jan 21 09:35:46 2010 From: abhishekv.verma at gmail.com (Abhishek Verma) Date: Thu, 21 Jan 2010 21:05:46 +0530 Subject: Patents, IETF and Network Operators Message-ID: Hi, Network Ops folks use the IETF standards for their operations. I see lot of nifty things coming out from the IETF stable and i was wondering why those dont get patented? Why bother releasing some really good idea to IETF (i.e. open standards bodies) when the vendor could have patented it. The network operators can still use it as long as they are using that vendor's equipment. I understand that interop can be an issue, since it will be a patented technology, but it will always work between the boxes from the same vendor. If so, then whats the issue? Is interop the only issue because of which most ideas get released into IETF? I guess interop is *an* issue since nobody wants a single vendor network. Thanks, Abhishek From morrowc.lists at gmail.com Thu Jan 21 09:39:37 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Jan 2010 10:39:37 -0500 Subject: Patents, IETF and Network Operators In-Reply-To: References: Message-ID: <75cb24521001210739s6af89545k4ee9327fb7b20ea1@mail.gmail.com> On Thu, Jan 21, 2010 at 10:35 AM, Abhishek Verma wrote: > Is interop the only issue because of which most ideas get released > into IETF? I guess interop is *an* issue since nobody wants a single > vendor network. I would point you at the 14+ frame-relay networks (that can't interconnect in a meaningful manner) that MCI (still, mostly) runs today... go-go-vendor-proprietary solutions!! -chris From jmamodio at gmail.com Thu Jan 21 09:41:37 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 21 Jan 2010 09:41:37 -0600 Subject: Patents, IETF and Network Operators In-Reply-To: References: Message-ID: <202705b1001210741l81ee340j4bca8c954a6fbc38@mail.gmail.com> As an starting point you should read "The Tao of the IETF" RFC4677 (currently, update draft in progress). About your particular question read section 8.4.5. Regards Jorge On Thu, Jan 21, 2010 at 9:35 AM, Abhishek Verma wrote: > Hi, > > Network Ops folks use the IETF standards for their operations. I see > lot of nifty things coming out from the IETF stable and i was > wondering why those dont get patented? Why bother releasing some > really good idea to IETF (i.e. open standards bodies) when the vendor > could have patented it. The network operators can still use it as long > as they are using that vendor's equipment. I understand that interop > can be an issue, since it will be a patented technology, but it will > always work between the boxes from the same vendor. If so, then whats > the issue? > > Is interop the only issue because of which most ideas get released > into IETF? I guess interop is *an* issue since nobody wants a single > vendor network. > > Thanks, > Abhishek > > From scott.brim at gmail.com Thu Jan 21 10:09:45 2010 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 21 Jan 2010 11:09:45 -0500 Subject: Patents, IETF and Network Operators In-Reply-To: <202705b1001210741l81ee340j4bca8c954a6fbc38@mail.gmail.com> References: <202705b1001210741l81ee340j4bca8c954a6fbc38@mail.gmail.com> Message-ID: <4B587C49.5050204@gmail.com> Jorge Amodio allegedly wrote on 01/21/2010 10:41 EST: > As an starting point you should read "The Tao of the IETF" RFC4677 (currently, > update draft in progress). > > About your particular question read section 8.4.5. > > Regards > Jorge Right. And it's subtler than you think. Some network operators have patents (not just vendors). Some are held by organizations that only exist to hold patents and don't actually know much about networking. And just because something is patented doesn't mean it isn't interoperable -- most networking standards are patented. swb > > On Thu, Jan 21, 2010 at 9:35 AM, Abhishek Verma > wrote: >> Hi, >> >> Network Ops folks use the IETF standards for their operations. I see >> lot of nifty things coming out from the IETF stable and i was >> wondering why those dont get patented? Why bother releasing some >> really good idea to IETF (i.e. open standards bodies) when the vendor >> could have patented it. The network operators can still use it as long >> as they are using that vendor's equipment. I understand that interop >> can be an issue, since it will be a patented technology, but it will >> always work between the boxes from the same vendor. If so, then whats >> the issue? >> >> Is interop the only issue because of which most ideas get released >> into IETF? I guess interop is *an* issue since nobody wants a single >> vendor network. >> >> Thanks, >> Abhishek >> >> > > From jmamodio at gmail.com Thu Jan 21 10:38:56 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 21 Jan 2010 10:38:56 -0600 Subject: Patents, IETF and Network Operators In-Reply-To: <4B587C49.5050204@gmail.com> References: <202705b1001210741l81ee340j4bca8c954a6fbc38@mail.gmail.com> <4B587C49.5050204@gmail.com> Message-ID: <202705b1001210838u7f4176f6ifa63ff2ac26ba8fd@mail.gmail.com> On Thu, Jan 21, 2010 at 10:09 AM, Scott Brim wrote: > Jorge Amodio allegedly wrote on 01/21/2010 10:41 EST: >> As an starting point you should read "The Tao of the IETF" RFC4677 (currently, >> update draft in progress). >> >> About your particular question read section 8.4.5. >> >> Regards >> Jorge > > Right. ?And it's subtler than you think. ?Some network operators have > patents (not just vendors). ?Some are held by organizations that only > exist to hold patents and don't actually know much about networking. > And just because something is patented doesn't mean it isn't > interoperable -- most networking standards are patented. Just like as - "US Patent 6701329 - Aging and scavenging of DNS resource records" (Microsoft) - "US Patent 7337910 - Methods and devices for responding to request for unregistered domain name to indicate a predefined type of service" (Verisign SiteFinder fiasco) - "US Patent 6560634 - Method of determining unavailability of an internet domain name" (Verisign) - "US Patent 7580982 - Email filtering system and method" (Go Daddy) - "US Patent 7130878 - Systems and methods for domain name registration by proxy" (Go Daddy) Just to list a few. Be careful the next time you use "vi", somebody may have already patented that regular expression. Cheers Jorge From sronan at fattoc.com Thu Jan 21 11:32:44 2010 From: sronan at fattoc.com (Shane Ronan) Date: Thu, 21 Jan 2010 12:32:44 -0500 Subject: Patents, IETF and Network Operators In-Reply-To: References: Message-ID: The real question is why Patent something? The reality is even if you patent any idea/feature, other vendors will come out with a similar (although not patent infringing) version of the same idea/feature. While you might get a short term jump on other vendors, if the idea is really good, everyone else will catch up quickly. Further, customers REALLY like inter-op, I know for one I don't use protocols from vendors that aren't "standard" On Jan 21, 2010, at 10:35 AM, Abhishek Verma wrote: > Hi, > > Network Ops folks use the IETF standards for their operations. I see > lot of nifty things coming out from the IETF stable and i was > wondering why those dont get patented? Why bother releasing some > really good idea to IETF (i.e. open standards bodies) when the vendor > could have patented it. The network operators can still use it as long > as they are using that vendor's equipment. I understand that interop > can be an issue, since it will be a patented technology, but it will > always work between the boxes from the same vendor. If so, then whats > the issue? > > Is interop the only issue because of which most ideas get released > into IETF? I guess interop is *an* issue since nobody wants a single > vendor network. > > Thanks, > Abhishek > From mike-nanog at tiedyenetworks.com Thu Jan 21 11:48:17 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 21 Jan 2010 09:48:17 -0800 Subject: Emergency power generators Message-ID: <4B589361.7040209@tiedyenetworks.com> Hi Folks, Northern California is getting pounded hard by storms, as we do most every year, and have quite a few electric outages as a result. Of particular note however is that we have experienced a number of remote and inaccessible microwave backhaul sites where the on-site generator has failed to engage, leaving us with 9 hours of battery. Sometimes, fortunately, that's enough to carry us through. Other times, like now, it's not. I don't want to lecture the site owners about routine testing procedures and so forth, but it seems that we need to become experts on the topic and we would like to offer these site owners a solution to test and verify generator operation. Does anyone have any pointers to possible solutions or vendor white papers I could look at? We probably want to verify start, read voltage to verify output, and maybe even gauge fuel in the tanks if thats possible. No sales droids please, just helpful information based on experience at this time. Thank you. From jmamodio at gmail.com Thu Jan 21 11:57:45 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 21 Jan 2010 11:57:45 -0600 Subject: Patents, IETF and Network Operators In-Reply-To: References: Message-ID: <202705b1001210957q240bcf1epe91619db60eb29f@mail.gmail.com> On Thu, Jan 21, 2010 at 11:32 AM, Shane Ronan wrote: > The real question is why Patent something? Patents are a good source of revenue for companies that invest a lot on R&D and to create "intellectual property" (well sometimes not that much). As far as I know in the US you can patent any "original idea" (even the best approach to catch brain farts with a spoon) regardless of its application, usability, stupidity or interoperability. Some companies need to keep their attorneys entertained, but if by a chance you happen to "use" somebody else "original idea" in your product, the inventor of the "original idea" has the right to block you (many file patents just for that) to use the idea or request the payment of royalties until the protection expires (17 or 20 years after filing depending if it was after or before 1995, some design patents expire in 14 years) and you in theory are able to use the idea but probably it will be to old. Jorge From hans at is.nl Thu Jan 21 11:58:56 2010 From: hans at is.nl (Hans Goes) Date: Thu, 21 Jan 2010 18:58:56 +0100 Subject: AS3549 Message-ID: <2982D4EC0F226648BA4B87FD35318C0CD44A155071@is-exch-001.office.is.nl> Just wondering if other people on this list experience similar problems with BGP sessions behind AS3549 ? It seems our trouble ticket is currently being taken care of and the GlobalCrossing NOC is investigating. If other people experience the same thing please let me know. PS: we are located in Amsterdam, Netherlands Hans Goes Senior Network Engineer IS Interned Services - PROUD AND CLEAR. www.is.nl +31 299 476 185 Gorslaan 18 1441 RG Purmerend The Netherlands cr1.ams2#sho ip bgp flap-stat inc 208.50.59.105 *> 4.23.88.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.23.89.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.23.92.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.23.94.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.38.0.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.38.8.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.43.50.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.43.51.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.67.96.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.67.104.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 8.14.0.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 *> 8.14.16.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 *> 24.49.84.0/23 208.50.59.105 1 00:01:22 3549 3356 7843 *> 24.49.89.0/24 208.50.59.105 1 00:01:22 3549 3356 7843 * 38.97.109.0/24 208.50.59.105 2 00:25:18 3549 701 20417 * 41.0.144.0/20 208.50.59.105 2 00:21:47 3549 5713 36994 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6747 bytes Desc: not available URL: From gbonser at seven.com Thu Jan 21 12:29:28 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Jan 2010 10:29:28 -0800 Subject: Patents, IETF and Network Operators In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE081F733A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Shane Ronan > Sent: Thursday, January 21, 2010 9:33 AM > > The real question is why Patent something? > > The reality is even if you patent any idea/feature, other vendors will > come out with a similar (although not patent infringing) version of > the same idea/feature. While you might get a short term jump on other > vendors, if the idea is really good, everyone else will catch up > quickly. Further, customers REALLY like inter-op, I know for one I > don't use protocols from vendors that aren't "standard" The purpose of a patent is not to keep others from using your idea but exactly the opposite. It gives you exclusive use of an idea but also makes for a mechanism where your idea is then documented and can be used and improved upon by others once your exclusive use expires. It was designed (in the US, at least) as an alternative to keeping everything secret and an idea dying with the inventor/enterprise. The notion being that you would have exclusive use of the idea long enough to have a commercial advantage but eventually the world could benefit in a more general sense if the idea proved to be a good one. The way patents are used today as a commodity is against what the original purpose was. To quote http://www.uh.edu/engines/epi792.htm : As secretary of state, Jefferson ran our first American patent office. For him, its purpose was to promulgate inventions, not to protect them. He hated monopoly and was determined that the patent process shouldn't serve it. The peculiar character of an idea, said Jefferson, is that ... no one possesses the less because everyone possesses the whole of it. He who receives an idea from me receives [it] without lessening [me], as he who lights his [candle] at mine receives light without darkening me. Jefferson had used mathematics to design a wonderfully improved plow. When he was done, he gave it away -- to America -- then to Europe. He would turn in his grave at the way today's patents make ideas into property. From jmamodio at gmail.com Thu Jan 21 12:42:21 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 21 Jan 2010 12:42:21 -0600 Subject: Patents, IETF and Network Operators In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F733A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F733A@RWC-EX1.corp.seven.com> Message-ID: <202705b1001211042j50ebe016x75d28d3d04181c65@mail.gmail.com> > The purpose of a patent is not to keep others from using your idea but > exactly the opposite. ?It gives you exclusive use of an idea but also > makes for a mechanism where your idea is then documented and can be used > and improved upon by others once your exclusive use expires. Explain that to the pharma' boys http://www.earthinstitute.columbia.edu/cgsd/documents/lehman.pdf From smb at cs.columbia.edu Thu Jan 21 12:52:16 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Jan 2010 13:52:16 -0500 Subject: Patents, IETF and Network Operators In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F733A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F733A@RWC-EX1.corp.seven.com> Message-ID: On Jan 21, 2010, at 1:29 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Shane Ronan >> Sent: Thursday, January 21, 2010 9:33 AM >> >> The real question is why Patent something? >> >> The reality is even if you patent any idea/feature, other vendors will >> come out with a similar (although not patent infringing) version of >> the same idea/feature. While you might get a short term jump on other >> vendors, if the idea is really good, everyone else will catch up >> quickly. Further, customers REALLY like inter-op, I know for one I >> don't use protocols from vendors that aren't "standard" > > The purpose of a patent is not to keep others from using your idea but > exactly the opposite. It gives you exclusive use of an idea but also > makes for a mechanism where your idea is then documented and can be used > and improved upon by others once your exclusive use expires. Yes and no -- don't confuse the purpose of a patent with the rights it gives you. A patent is not the right to do something; it's the right to keep others from doing it. The purpose, though, is as you say: in exchange for publication of your ideas, society gives you a limited-term monopoly. I should add: patents can help society not just because it sees your ideas, but because of the monopoly: people are motivated to invent around your patent. --Steve Bellovin, http://www.cs.columbia.edu/~smb From tony at lava.net Thu Jan 21 13:04:45 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 21 Jan 2010 09:04:45 -1000 (HST) Subject: Emergency power generators In-Reply-To: <4B589361.7040209@tiedyenetworks.com> References: <4B589361.7040209@tiedyenetworks.com> Message-ID: On Thu, 21 Jan 2010, Mike wrote: > site owners a solution to test and verify generator operation. Does anyone > have any pointers to possible solutions or vendor white papers I could look > at? We probably want to verify start, read voltage to verify output, and > maybe even gauge fuel in the tanks if thats possible. Start with the generator owner's manual. You'd be amazed at what helpful maintenance suggestions can be found there. Sometimes they're even online... :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From telmnstr at 757.org Thu Jan 21 13:09:04 2010 From: telmnstr at 757.org (telmnstr at 757.org) Date: Thu, 21 Jan 2010 14:09:04 -0500 (EST) Subject: Emergency power generators In-Reply-To: References: <4B589361.7040209@tiedyenetworks.com> Message-ID: > Start with the generator owner's manual. You'd be amazed at what helpful > maintenance suggestions can be found there. Sometimes they're even online... > :) "Put oil in machine...." From LarrySheldon at cox.net Thu Jan 21 13:13:06 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 21 Jan 2010 13:13:06 -0600 Subject: Emergency power generators In-Reply-To: References: <4B589361.7040209@tiedyenetworks.com> Message-ID: <4B58A742.5000009@cox.net> On 1/21/2010 1:04 PM, Antonio Querubin wrote: > Start with the generator owner's manual. RTFM? I thought that kind of stuff was OT here. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jgreco at ns.sol.net Thu Jan 21 13:17:56 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 21 Jan 2010 13:17:56 -0600 (CST) Subject: Emergency power generators In-Reply-To: from "Antonio Querubin" at Jan 21, 2010 09:04:45 AM Message-ID: <201001211917.o0LJHu3P045495@aurora.sol.net> > On Thu, 21 Jan 2010, Mike wrote: > > > site owners a solution to test and verify generator operation. Does anyone > > have any pointers to possible solutions or vendor white papers I could look > > at? We probably want to verify start, read voltage to verify output, and > > maybe even gauge fuel in the tanks if thats possible. > > Start with the generator owner's manual. You'd be amazed at what helpful > maintenance suggestions can be found there. Sometimes they're even > online... :) Seriously, "talk to your vendor." You can frequently get gear with remote reporting, some of it will do dry contact or even talk RS232. If you can not, a lot of it can be measured anyways. If your gear doesn't "support" it, talk to generator service guys who are well-thought-of in your area. I'd place good odds that they'll be happy to outfit you with a computer-readable fuel level indicator, oil pressure, remote test, etc., etc., though they may be smiling their way to the bank and thanking you for all the custom work. ... 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 gordslater at ieee.org Thu Jan 21 15:21:23 2010 From: gordslater at ieee.org (gordon b slater) Date: Thu, 21 Jan 2010 21:21:23 +0000 Subject: Emergency power generators In-Reply-To: <201001211917.o0LJHu3P045495@aurora.sol.net> References: <201001211917.o0LJHu3P045495@aurora.sol.net> Message-ID: <1264108883.17421.112.camel@ub-g-d2> On Thu, 2010-01-21 at 13:17 -0600, Joe Greco wrote: > Seriously, "talk to your vendor." You can frequently get gear with > remote reporting, some of it will do dry contact or even talk RS232. > If you can not, a lot of it can be measured anyways. > > If your gear doesn't "support" it, talk to generator service guys who > are well-thought-of in your area. I'd place good odds that they'll be > happy to outfit you with a computer-readable fuel level indicator, > oil pressure, remote test, etc., etc., though they may be smiling their > way to the bank and thanking you for all the custom work. > > ... JG a lot of places just use a linux or BSD SFF/mini-ITX with a webcam grabbing a jpeg/png every few seconds or once a minute on a cron job, pointed at the controls/guages/meters. Just make sure the target area is well-lit so the cam can see needles/guages etc. Accessed by SSH (=scp/sftp/sshfs) and not running X or even a web/ftpserver, its pretty hard to pervert it for nefarious means. Much better than "IP webcams" which seem to be a magnet for google-hackers. It's cheap and known-tech to most of us, but may require a shiny black metal box (and a stainless bracket for the webcam) if the generator guys don't like the idea at first. Great for monitoring electrical breaker-boards, SAN hdd leds (using fast framerate grabs) or racks of switches for pretty blinking lights (or the lack of). Of course if you already have an old server box lying nearby, you're laughing. Make sure to buy a well-supported webcam for your kernel/distro to avoid madness. About 30-40$US will get a good one usually, GIYF for supported models. If you can get a RS232 fuel-gauge sender or enviro-sensors, you already have a SSH-to-RS232 gateway ;) Some SCADA gear is extremely expensive and a can of worms in its own right. Gord From brandon.galbraith at gmail.com Thu Jan 21 15:35:47 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 21 Jan 2010 15:35:47 -0600 Subject: Emergency power generators In-Reply-To: <1264108883.17421.112.camel@ub-g-d2> References: <201001211917.o0LJHu3P045495@aurora.sol.net> <1264108883.17421.112.camel@ub-g-d2> Message-ID: <366100671001211335l17aa9bdbpfc160015a9e23832@mail.gmail.com> On Thu, Jan 21, 2010 at 3:21 PM, gordon b slater wrote: > On Thu, 2010-01-21 at 13:17 -0600, Joe Greco wrote: > > If your gear doesn't "support" it, talk to generator service guys who > > are well-thought-of in your area. I'd place good odds that they'll be > > happy to outfit you with a computer-readable fuel level indicator, > > oil pressure, remote test, etc., etc., though they may be smiling their > > way to the bank and thanking you for all the custom work. > > > > ... JG > > a lot of places just use a linux or BSD SFF/mini-ITX with a webcam > grabbing a jpeg/png every few seconds or once a minute on a cron job, > pointed at the controls/guages/meters. Just make sure the target area is > well-lit so the cam can see needles/guages etc. > > I've solved this in several locations with Arduino (google is your friend) boards. They're cheap ($40-$100/pop), are easily networked, and can be used to send the required data back in a variety of formats (we have Nagios monitoring them, checking every X minutes). This, of course, is no replacement for running the genset every so often to verify it actually starts. -brandon -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From brian.e.carpenter at gmail.com Thu Jan 21 15:37:08 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 22 Jan 2010 10:37:08 +1300 Subject: IPv6 deployment scenarios Message-ID: <4B58C904.4030100@gmail.com> Hi, Sheng Jiang (Huawei) and Brian Carpenter (University of Auckland, research consultant to Huawei) are currently running a questionnaire on IPv6 deployment, addressed to every ISP. The purpose is to provide facts for a document about deployment scenarios that we are drafting for discussion in the IETF. We will keep your reply strictly confidential and we will publish only combined results. We will not identify information about individual ISPs in any published results. If you request it, we will not mention you or the ISP in the acknowledgments. Please find the questionnaire at http://www.cs.auckland.ac.nz/~brian/ISP-v6-QQ.html Answers are requested ASAP. (Hmm. As I write, the IPv6 access to that server is broken. Hopefully it will be back soon.) btw, we know that the questionnaire is imperfect; all questionnaires are imperfect. Also, this is not a marketing survey; we are after technical information. Regards Brian Carpenter From sethm at rollernet.us Thu Jan 21 16:00:01 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 21 Jan 2010 14:00:01 -0800 Subject: Emergency power generators In-Reply-To: <201001211917.o0LJHu3P045495@aurora.sol.net> References: <201001211917.o0LJHu3P045495@aurora.sol.net> Message-ID: <4B58CE61.1010908@rollernet.us> Joe Greco wrote: >> On Thu, 21 Jan 2010, Mike wrote: >> >>> site owners a solution to test and verify generator operation. Does anyone >>> have any pointers to possible solutions or vendor white papers I could look >>> at? We probably want to verify start, read voltage to verify output, and >>> maybe even gauge fuel in the tanks if thats possible. >> Start with the generator owner's manual. You'd be amazed at what helpful >> maintenance suggestions can be found there. Sometimes they're even >> online... :) > > Seriously, "talk to your vendor." You can frequently get gear with > remote reporting, some of it will do dry contact or even talk RS232. > If you can not, a lot of it can be measured anyways. > > If your gear doesn't "support" it, talk to generator service guys who > are well-thought-of in your area. I'd place good odds that they'll be > happy to outfit you with a computer-readable fuel level indicator, > oil pressure, remote test, etc., etc., though they may be smiling their > way to the bank and thanking you for all the custom work. > Many automatic generators have provisions for a remote annunciator which are typically just wired up as voltage out for each warning light/alarm. You could easily put a tiny relay on those and make it contact closure. It might not give you "the temp is 151" but it could give you "pre-alarm high temp" before "high temp shutdown" for cheap. ~Seth From brunner at nic-naa.net Thu Jan 21 16:07:47 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 21 Jan 2010 17:07:47 -0500 Subject: Housing situations sought for the family of Reynold Guerrier Message-ID: <4B58D033.2030101@nic-naa.net> Naturally, I didn't make all the local connections I could have before I needed them when I went to NANOG-45, graciously hosted by Terremark. I think it is unlikely that any of the three paths -- parole from Homeland Security, visa from State, and Congressional action, are likely to occur within finite time. Not only is the situation on the ground profoundly difficult, but we constantly encounter questions about the necessity of network continuity at all, or the value of any one person maintaining the operational integrity of the NAP/IXP/uW relay serving the Haitian government, on-site NGOs, and cellular traffic. So I'm turning again to the Operator Community for help. If you have contacts in the DR that could help Reynold's wife Dominique and their children, Nikki, age 3, and Aurelia, age 1, please send them to me. Housing for four. When Dominique and the kids are secure, Reynold is going back to the data center in Boutillers, which consists of the microwave relay to the Dominican Republic, the Internet Exchange point (IX) he normally operates, and Network Access Point (NAP), since the event. There is no other skilled person present. Basically, Reynold has inherited the entire facility, as the operator of the IXP hosted in the larger data center, and some technicians, who he now provides for and manages. The distance from Port au Prince to Santo Domingo is 5 hours, road condition and boarder control time included. Eric From tim at broadlinenetworks.com Thu Jan 21 16:19:28 2010 From: tim at broadlinenetworks.com (Tim Lampman) Date: Thu, 21 Jan 2010 17:19:28 -0500 Subject: Housing situations sought for the family of Reynold Guerrier In-Reply-To: <4B58D033.2030101@nic-naa.net> References: <4B58D033.2030101@nic-naa.net> Message-ID: <4B58D2F0.7090006@broadlinenetworks.com> Eric Brunner-Williams wrote: > Naturally, I didn't make all the local connections I could have before > I needed them when I went to NANOG-45, graciously hosted by Terremark. > > I think it is unlikely that any of the three paths -- parole from > Homeland Security, visa from State, and Congressional action, are > likely to occur within finite time. Not only is the situation on the > ground profoundly difficult, but we constantly encounter questions > about the necessity of network continuity at all, or the value of any > one person maintaining the operational integrity of the NAP/IXP/uW > relay serving the Haitian government, on-site NGOs, and cellular traffic. > > So I'm turning again to the Operator Community for help. If you have > contacts in the DR that could help Reynold's wife Dominique and their > children, Nikki, age 3, and Aurelia, age 1, please send them to me. > > Housing for four. When Dominique and the kids are secure, Reynold is > going back to the data center in Boutillers, which consists of the > microwave relay to the Dominican Republic, the Internet Exchange point > (IX) he normally operates, and Network Access Point (NAP), since the > event. There is no other skilled person present. Basically, Reynold > has inherited the entire facility, as the operator of the IXP hosted > in the larger data center, and some technicians, who he now provides > for and manages. > > The distance from Port au Prince to Santo Domingo is 5 hours, road > condition and boarder control time included. > > Eric > > > I have forwarded this to several friends that are currently in the DR. Two of them are involved with housing/building projects. Hopefully someone they know there is able to help out. I'll contact you off list if I get any information. -- Tim Lampman Co-Owner/CTO *Broadline Networks Inc.* 57 Colborne Street West, Brantford, ON, N3T 1K6 *p.* 1-866-546-8486 *c.* 905-746-3114 www.broadlinenetworks.com | tim at broadlinenetworks.com From mpalmer at hezmatt.org Thu Jan 21 16:29:41 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 22 Jan 2010 09:29:41 +1100 Subject: Enhancing automation with network growth In-Reply-To: References: <4B57C1FA.5000207@ibctech.ca> Message-ID: <20100121222941.GF31732@hezmatt.org> On Wed, Jan 20, 2010 at 10:52:39PM -0500, Erik L wrote: > > One thing that would take a major load off would be if my MRTG system > > could simply update its config/index files for itself, instead of me > > having to do it on each and every port change. > > > > Can anyone offer up ideas on how you manage any automation in this > > regard for their infrastructure gear traffic graphs? > > (Commercial options > > welcome, off-list, but we're as small as our budget is). > > Not sure how you're doing your graphs currently, but have you considered Cacti? If automating MRTG config is hard, automating Cacti config is about as close to "impossible" as one can get without popping around to the Augean stables. - Matt From LarrySheldon at cox.net Thu Jan 21 17:38:29 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 21 Jan 2010 17:38:29 -0600 Subject: Enhancing automation with network growth In-Reply-To: <20100121222941.GF31732@hezmatt.org> References: <4B57C1FA.5000207@ibctech.ca> <20100121222941.GF31732@hezmatt.org> Message-ID: <4B58E575.8020803@cox.net> On 1/21/2010 4:29 PM, Matthew Palmer wrote: > On Wed, Jan 20, 2010 at 10:52:39PM -0500, Erik L wrote: >>> One thing that would take a major load off would be if my MRTG system >>> could simply update its config/index files for itself, instead of me >>> having to do it on each and every port change. >>> >>> Can anyone offer up ideas on how you manage any automation in this >>> regard for their infrastructure gear traffic graphs? >>> (Commercial options >>> welcome, off-list, but we're as small as our budget is). >> >> Not sure how you're doing your graphs currently, but have you considered Cacti? > > If automating MRTG config is hard, automating Cacti config is about as close > to "impossible" as one can get without popping around to the Augean stables. It has been a while, and I have not been following this thread, but once upon a time I had Korn scripts that read (SNMP) devices found and generated MRTG scripts for what it found. Sure enough, I had to go into each one and clean up names and stuff, and occasionally to discard some of what the automaton had created. If I can do that, it seems like anybody can. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From leo.vegoda at icann.org Thu Jan 21 17:36:45 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 21 Jan 2010 15:36:45 -0800 Subject: 1/8 and 27/8 allocated to APNIC Message-ID: Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in January 2010: 1/8 and 27/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 24 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN From Tim_Bulger at polk.com Thu Jan 21 17:47:39 2010 From: Tim_Bulger at polk.com (Bulger, Tim) Date: Thu, 21 Jan 2010 18:47:39 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: Message-ID: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> Having 1/8 allocated cannot be a blessing... There must be thousands of underskilled in the wild with stuff configured for 1/8. It's like a magnet for unwanted noise traffic. -Tim -----Original Message----- From: Leo Vegoda [mailto:leo.vegoda at icann.org] Sent: Thursday, January 21, 2010 6:37 PM To: Leo Vegoda Subject: 1/8 and 27/8 allocated to APNIC Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in January 2010: 1/8 and 27/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xm l http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xm l http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.tx t Please update your filters as appropriate. The IANA free pool contains 24 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN ***************************************************************** This message has originated from R. L. Polk & Co., 26955 Northwestern Highway, Southfield, MI 48033. R. L. Polk & Co. sends various types of email communications. If this email message concerns the potential licensing of a Polk product or service, and you do not wish to receive further emails regarding Polk products, forward this email to Do_Not_Send at polk.com with the word "remove" in the subject line. The email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error, please delete this message and notify the Polk System Administrator at postmaster at polk.com. ***************************************************************** From alain_durand at cable.comcast.com Thu Jan 21 17:58:04 2010 From: alain_durand at cable.comcast.com (Durand, Alain) Date: Thu, 21 Jan 2010 18:58:04 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> Message-ID: Who said the water at the bottom of the barrel of IPv4 addresses will be very pure? We ARE running out and the global pain is increasing. - Alain. On 1/21/10 6:47 PM, "Bulger, Tim" wrote: > Having 1/8 allocated cannot be a blessing... There must be thousands of > underskilled in the wild with stuff configured for 1/8. It's like a > magnet for unwanted noise traffic. > > -Tim > > -----Original Message----- > From: Leo Vegoda [mailto:leo.vegoda at icann.org] > Sent: Thursday, January 21, 2010 6:37 PM > To: Leo Vegoda > Subject: 1/8 and 27/8 allocated to APNIC > > Hi, > > The IANA IPv4 registry has been updated to reflect the allocation > of two /8 IPv4 blocks to APNIC in January 2010: 1/8 and > 27/8. You can find the IANA IPv4 registry at: > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xm > l > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xm > l > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.tx > t > > Please update your filters as appropriate. > > The IANA free pool contains 24 unallocated unicast IPv4 /8s. > > Regards, > > Leo Vegoda > Number Resources Manager, IANA > ICANN > ***************************************************************** > This message has originated from R. L. Polk & Co., > 26955 Northwestern Highway, Southfield, MI 48033. > R. L. Polk & Co. sends various types of email > communications. If this email message concerns the > potential licensing of a Polk product or service, and > you do not wish to receive further emails regarding Polk > products, forward this email to Do_Not_Send at polk.com > with the word "remove" in the subject line. > > The email and any files transmitted with it are confidential > and intended solely for the individual or entity to whom they > are addressed. > > If you have received this email in error, please delete this > message and notify the Polk System Administrator at > postmaster at polk.com. > ***************************************************************** > From jfbeam at gmail.com Thu Jan 21 18:06:46 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 21 Jan 2010 19:06:46 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> Message-ID: On Thu, 21 Jan 2010 18:47:39 -0500, Bulger, Tim wrote: > Having 1/8 allocated cannot be a blessing... There must be thousands of > underskilled in the wild with stuff configured for 1/8. It's like a > magnet for unwanted noise traffic. I was thinking the same thing. I know of many installations where 1/8 has been used internally. Technically, they're mostly all "mainframe" installations that are never supposed to be connected to the internet, but they're accessed by machines that are. (that are already using private IPv4 space.) But it's not all bad. It's assigned to APNIC, so a lot of people will gladly continue blocking it. From cb.list6 at gmail.com Thu Jan 21 18:50:46 2010 From: cb.list6 at gmail.com (Cam Byrne) Date: Thu, 21 Jan 2010 16:50:46 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> Message-ID: <1264121446.5816.6.camel@Nokia-N900-42-11> ----- Original message ----- > Who said the water at the bottom of the barrel of IPv4 addresses will be > very pure? We ARE running out and the global pain is increasing. > +1 - Cameron >? ? - Alain. > > > On 1/21/10 6:47 PM, "Bulger, Tim" wrote: > > > Having 1/8 allocated cannot be a blessing... There must be thousands of > > underskilled in the wild with stuff configured for 1/8.? It's like a > > magnet for unwanted noise traffic. > > > > -Tim > > > > -----Original Message----- > > From: Leo Vegoda [mailto:leo.vegoda at icann.org] > > Sent: Thursday, January 21, 2010 6:37 PM > > To: Leo Vegoda > > Subject: 1/8 and 27/8 allocated to APNIC > > > > Hi, > > > > The IANA IPv4 registry has been updated to reflect the allocation > > of two /8 IPv4 blocks to APNIC in January 2010: 1/8 and > > 27/8. You can find the IANA IPv4 registry at: > > > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xm > > l > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xm > > l > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.tx > > t > > > > Please update your filters as appropriate. > > > > The IANA free pool contains 24 unallocated unicast IPv4 /8s. > > > > Regards, > > > > Leo Vegoda > > Number Resources Manager, IANA > > ICANN > > ***************************************************************** > > This message has originated from R. L. Polk & Co., > > 26955 Northwestern Highway, Southfield, MI 48033. > > R. L. Polk & Co. sends various types of email > > communications.? If this email message concerns the > > potential licensing of a Polk product or service, and > > you do not wish to receive further emails regarding Polk > > products, forward this email to Do_Not_Send at polk.com > > with the word "remove" in the subject line. > > > > The email and any files transmitted with it are confidential > > and intended solely for the individual or entity to whom they > > are addressed. > > > > If you have received this email in error, please delete this > > message and notify the Polk System Administrator at > > postmaster at polk.com. > > ***************************************************************** > > > > From TWright at internode.com.au Thu Jan 21 18:54:06 2010 From: TWright at internode.com.au (Tom Wright) Date: Fri, 22 Jan 2010 11:24:06 +1030 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: Hi Steve, Our MRTG is fully automated. We ditched cfgmaker (too slow) in favour of our own developed Perl using the Net::SNMP module from CPAN. If you use 'non-blocking' SNMP calls, Net::SNMP can be blisteringly fast. In the case of our routers/switches, we query our NMS (assume this is just a table of hostnames and IP addresses) for a list the devices we want to graph, and then re-generate MRTG configurations a few times a day - meaning that we pick up new devices/port changes automatically. Capital expenditure = $0 :) -- Tom On 21/01/2010, at 1:24 PM, Steve Bertrand wrote: Hi all, I'm reaching the point where adding in a new piece of infrastructure hardware, connecting up a new cable, and/or assigning address space to a client is nearly 50% documentation and 50% technical. One thing that would take a major load off would be if my MRTG system could simply update its config/index files for itself, instead of me having to do it on each and every port change. Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). Unless something else is out there that I've missed, I'm seriously considering writing up a module in Perl to put up on the CPAN that can scan my RANCID logs (and perhaps the devices directly for someone who doesn't use RANCID), send an aggregate 'are these changes authorized' email to an engineer, and then proceed to execute the proper commands within the proper MRTG directories if the engineer approves. I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for switches, so it is not as simple as throwing a single command at all configs. All feedback welcome, especially if you are in the same boat. My IP address documentation/DNS is far more important than my traffic stats, but it really hurts when you've forgotten about a port three months ago that you need to know about now. Steve -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From joelja at bogus.com Thu Jan 21 18:11:44 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 Jan 2010 16:11:44 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> Message-ID: <4B58ED40.6060701@bogus.com> Ricky Beam wrote: > But it's not all bad. It's assigned to APNIC, so a lot of people will > gladly continue blocking it. > Yeah cause seriously, who does business in Asia or the Pacifc... From danny at tcb.net Thu Jan 21 19:08:17 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 21 Jan 2010 18:08:17 -0700 Subject: 2009 Worldwide Infrastructure Security Report available for download. In-Reply-To: References: <017a01ca99e5$c4dcddd0$4e969970$@net> Message-ID: On Jan 21, 2010, at 4:34 AM, Pekka Savola wrote: > Thanks to Arbor for collecting the report and your observations. > > One thing I found extremely strange is that almost 50% report they use BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer direction. (Figure 13, p20) Ahh, so, turns out some of the colors in a few of the charts (including Figure 13) were transposed (that's what I get for just looking at the numbers in the draft), making several of the findings seem a bit strange. This has since been corrected and should clarify your cocnern.. Thanks Pekka (and several others) for pointing this out. -danny From danny at tcb.net Thu Jan 21 19:08:34 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 21 Jan 2010 18:08:34 -0700 Subject: 2009 Worldwide Infrastructure Security Report available for download. In-Reply-To: <017a01ca99e5$c4dcddd0$4e969970$@net> References: <017a01ca99e5$c4dcddd0$4e969970$@net> Message-ID: <0F5E464A-2DB6-4F9B-9F26-8D617D7381BA@tcb.net> On Jan 20, 2010, at 8:32 AM, Stefan Fouant wrote: > > > I'm wondering if you can clarify why 'Figure 1' only goes up to 2008 and > states in key findings "This year, providers reported a peak rate of only 49 > Gbps". I happen to personally recall looking at ATLAS sometime last year > and seeing an ongoing attack that was on orders of magnitude larger than > that. That was an error in the chart (which has since been corrected), it should have illustrated that 2009 respondents indicated 49 Gbps was the largest observed attack. FWIW, I've seen empirical evidence supporting much larger attacks (~82 Gbps), and the Akamai folks indicated recently they'd seen attacks on the order of 120Gbps towards a single target. However, these attacks were NOT reflected in survey feedback expressly, and were therefore not included in the report. > An interesting observation was the decrease in the use of flow-based tools, > and the corresponding increase in the use of things like SNMP tools, DPI, > and customer calls for attack detection. Surely this must have been a > factor of a larger respondent pool... I'd really like to think people aren't > opting not to use flow-based tools in favor or receiving customer calls :( Yep, I think this is simply an artifact of a larger respondent pool size, with many smaller respondents being represented. -danny From gbonser at seven.com Thu Jan 21 19:13:39 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Jan 2010 17:13:39 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Durand, Alain [mailto:alain_durand at cable.comcast.com] > Sent: Thursday, January 21, 2010 3:58 PM > To: Bulger, Tim; nanog at nanog.org > Subject: Re: 1/8 and 27/8 allocated to APNIC > > Who said the water at the bottom of the barrel of IPv4 addresses will > be > very pure? We ARE running out and the global pain is increasing. > > - Alain. Some of that water is dirtier than the rest. I wouldn't want to be the person who gets 1.2.3.0/24 From jlewis at lewis.org Thu Jan 21 19:22:57 2010 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 21 Jan 2010 20:22:57 -0500 (EST) Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> Message-ID: On Thu, 21 Jan 2010, George Bonser wrote: > Some of that water is dirtier than the rest. I wouldn't want to be the > person who gets 1.2.3.0/24 The whole /8 should be fun. http://en.wikipedia.org/wiki/AnoNet To avoid addressing conflict with the internet itself, the range 1.0.0.0/8 is used. This is to avoid conflicting with internal networks such as 10/8, 172.16/12 and 192.168/16, as well as assigned Internet ranges. In the event that 1.0.0.0/8 is assigned by IANA, anoNet could move to the next unassigned /8, though such an event is unlikely, as 1.0.0.0/8 has been reserved since September 1981. I thought there was some other group that had been squatting in 1/8, something about radio and peer to peer...but not AnoNet (at least that name was totally unfamiliar)...but this was all I could find with a quick google. ---------------------------------------------------------------------- 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 Thu Jan 21 19:49:58 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 21 Jan 2010 17:49:58 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> Message-ID: <928F7E60-6C79-424A-BF07-455028D6B010@virtualized.org> On Jan 21, 2010, at 5:22 PM, Jon Lewis wrote: > In the event that 1.0.0.0/8 is assigned by IANA, anoNet could > move to the next unassigned /8, though such an event is unlikely, as > 1.0.0.0/8 has been reserved since September 1981. Sounds like a non-winning strategy to me. It's just a (random) matter of time until they get to do the same thing again, see: http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ > I thought there was some other group that had been squatting in 1/8, something about radio and peer to peer...but not AnoNet (at least that name was totally unfamiliar)...but this was all I could find with a quick google. There are other folks who are playing Russian Roulette, e.g. http://en.wikipedia.org/wiki/Hamachi. Lots of "fun" in store for us in the future. Might think about moving to IPv6... :-) Regards, -drc From tkapela at gmail.com Thu Jan 21 19:51:01 2010 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 21 Jan 2010 20:51:01 -0500 Subject: fix the edge (was Re: 1/8 and 27/8 allocated to APNIC) Message-ID: <2e9d8ae51001211751x3fd56384te2322be25a83d99c@mail.gmail.com> On Thu, Jan 21, 2010 at 8:22 PM, Jon Lewis wrote: > I thought there was some other group that had been squatting in 1/8, > something about radio and peer to peer...but not AnoNet (at least that name > was totally unfamiliar)...but this was all I could find with a quick google. http://en.wikipedia.org/wiki/AnoNet#Scaling oh, the irony. good thing privacy costs too much for the majority of internet users. on a serious note, who cares? Resolution to the 1/8 allocation "mess" seems on par with freeing up IP stacks from excluding 240/4, but by the time any of this is resolved, perhaps residential users on att dsl/etc might just have working IP6CP, or will have switched to comcast by then. -Tk From kstjohn at rising-light.net Thu Jan 21 19:51:13 2010 From: kstjohn at rising-light.net (Kevin St John) Date: Thu, 21 Jan 2010 17:51:13 -0800 Subject: Enhancing automation with network growth Message-ID: <015301ca9b05$625e7620$271b6260$@net> I think Cacti (www.cacti.net) can do this pretty simply if that?s any help? ________________________________________ From: Tom Wright [TWright at internode.com.au] Sent: Thursday, January 21, 2010 4:54 PM To: Steve Bertrand Cc: nanog list Subject: Re: Enhancing automation with network growth Hi Steve, Our MRTG is fully automated. We ditched cfgmaker (too slow) in favour of our own developed Perl using the Net::SNMP module from CPAN. If you use 'non-blocking' SNMP calls, Net::SNMP can be blisteringly fast. In the case of our routers/switches, we query our NMS (assume this is just a table of hostnames and IP addresses) for a list the devices we want to graph, and then re-generate MRTG configurations a few times a day - meaning that we pick up new devices/port changes automatically. Capital expenditure = $0 :) -- Tom On 21/01/2010, at 1:24 PM, Steve Bertrand wrote: Hi all, I'm reaching the point where adding in a new piece of infrastructure hardware, connecting up a new cable, and/or assigning address space to a client is nearly 50% documentation and 50% technical. One thing that would take a major load off would be if my MRTG system could simply update its config/index files for itself, instead of me having to do it on each and every port change. Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). Unless something else is out there that I've missed, I'm seriously considering writing up a module in Perl to put up on the CPAN that can scan my RANCID logs (and perhaps the devices directly for someone who doesn't use RANCID), send an aggregate 'are these changes authorized' email to an engineer, and then proceed to execute the proper commands within the proper MRTG directories if the engineer approves. I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for switches, so it is not as simple as throwing a single command at all configs. All feedback welcome, especially if you are in the same boat. My IP address documentation/DNS is far more important than my traffic stats, but it really hurts when you've forgotten about a port three months ago that you need to know about now. Steve -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From neil at tonal.clara.co.uk Thu Jan 21 19:52:45 2010 From: neil at tonal.clara.co.uk (Neil Harris) Date: Fri, 22 Jan 2010 01:52:45 +0000 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> Message-ID: <4B5904ED.9030804@tonal.clara.co.uk> On 22/01/10 01:22, Jon Lewis wrote: > On Thu, 21 Jan 2010, George Bonser wrote: > >> Some of that water is dirtier than the rest. I wouldn't want to be the >> person who gets 1.2.3.0/24 > > The whole /8 should be fun. > > http://en.wikipedia.org/wiki/AnoNet > > To avoid addressing conflict with the internet itself, the range > 1.0.0.0/8 is used. This is to avoid conflicting with internal networks > such as 10/8, 172.16/12 and 192.168/16, as well as assigned Internet > ranges. In the event that 1.0.0.0/8 is assigned by IANA, anoNet could > move to the next unassigned /8, though such an event is unlikely, as > 1.0.0.0/8 has been reserved since September 1981. > > I thought there was some other group that had been squatting in 1/8, > something about radio and peer to peer...but not AnoNet (at least that > name was totally unfamiliar)...but this was all I could find with a > quick google. This? http://lists.arin.net/pipermail/arin-ppml/2003-May/001628.html -- Neil From randy at psg.com Thu Jan 21 19:56:10 2010 From: randy at psg.com (Randy Bush) Date: Fri, 22 Jan 2010 10:56:10 +0900 Subject: Patents, IETF and Network Operators In-Reply-To: References: Message-ID: may be better to ask this question on the ietf list. they deserve it. randy From rdobbins at arbor.net Thu Jan 21 20:06:16 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 22 Jan 2010 02:06:16 +0000 Subject: 2009 Worldwide Infrastructure Security Report available for download. In-Reply-To: <0F5E464A-2DB6-4F9B-9F26-8D617D7381BA@tcb.net> References: <017a01ca99e5$c4dcddd0$4e969970$@net> <0F5E464A-2DB6-4F9B-9F26-8D617D7381BA@tcb.net> Message-ID: <7864A976-8934-42CF-A2BB-9DA7B9EBF438@arbor.net> On Jan 22, 2010, at 8:08 AM, Danny McPherson wrote: > Yep, I think this is simply an artifact of a larger respondent pool > size, with many smaller respondents being represented. Correct, as noted in the text, the change in survey demographics appears to be the cause of this shift. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From mpalmer at hezmatt.org Thu Jan 21 20:10:37 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 22 Jan 2010 13:10:37 +1100 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> Message-ID: <20100122021037.GO31732@hezmatt.org> On Thu, Jan 21, 2010 at 08:22:57PM -0500, Jon Lewis wrote: > On Thu, 21 Jan 2010, George Bonser wrote: > >> Some of that water is dirtier than the rest. I wouldn't want to be the >> person who gets 1.2.3.0/24 > > The whole /8 should be fun. > > http://en.wikipedia.org/wiki/AnoNet > > To avoid addressing conflict with the internet itself, the range > 1.0.0.0/8 is used. This is to avoid conflicting with internal networks > such as 10/8, 172.16/12 and 192.168/16, as well as assigned Internet > ranges. In the event that 1.0.0.0/8 is assigned by IANA, anoNet could > move to the next unassigned /8, though such an event is unlikely, as > 1.0.0.0/8 has been reserved since September 1981. > > I thought there was some other group that had been squatting in 1/8, > something about radio and peer to peer...but not AnoNet (at least that > name was totally unfamiliar)...but this was all I could find with a quick > google. Yeah, they're not the only bunch of idiots who think that "unallocated" means "free for all". I'm reliably informed that Hamachi uses 5/8 (for the same reasons as this AnoNet bunch). There's probably others out there. Fun times ahead for moron-fac^Wcustomer-facing support personnel. - Matt From ike at conwaynetworks.com Thu Jan 21 20:13:03 2010 From: ike at conwaynetworks.com (Isaac Conway) Date: Thu, 21 Jan 2010 19:13:03 -0700 Subject: Network Bandwidth Reporting Tool Message-ID: <1264126383.4965.14.camel@icelaptop> Oh mighty list, I am curious what tools you use to generate monthly usage and billing reports for your execs? I am not really looking for a RRD type solution, rather a page I can pull up and gives me the numbers (95p, cost, overage, etc.) for the past month. Copy and paste into a spreadsheet, job complete.... We are getting to the point where we have multiple datacenters and numerous uplinks and circuits for each, I find I am spending too many hours each month compiling data. I was thinking about writing some quick scripts to poll the router interfaces and put it to database, but I figured I would ask before re-inventing the wheel. Thanks in advance! Isaac From smb at cs.columbia.edu Thu Jan 21 20:06:04 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Jan 2010 21:06:04 -0500 Subject: UC phone system for Haiti (was Katrina Response) In-Reply-To: <15BDDC14871D2A49BFCEEEF409EB29830323771A@exchange.syssrcad.syssrc.com> References: <4B508C67.5000309@nic-naa.net><9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com><4B523F68.6080305@nic-naa.net> <4B53970B.7050600@nic-naa.net><11B064048F34FD4094CBA16FC04BE2198638C676@ex01><4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net><4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net><67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <9ab36b821001191439s8568498ha61ad495341e570d@mail.gmail.com> <15BDDC14871D2A49BFCEEEF409EB29830323771A@exchange.syssrcad.syssrc.com> Message-ID: <648A0A8C-0ACE-4CC6-B937-266DB045E97B@cs.columbia.edu> Per http://www.wired.com/dangerroom/2010/01/texts-tweets-saving-haitians-from-the-rubble/ there seem to be innovative uses of technology in play. From smb at cs.columbia.edu Thu Jan 21 20:16:55 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Jan 2010 21:16:55 -0500 Subject: DIMACS/CCICADA secure routing workshop rescheduled Message-ID: <526BB3F5-CB4C-405E-89F0-D7E1F24D0153@cs.columbia.edu> OK, folks -- we've corrected the scheduling conflict. The secure routing working is now March 10-12. Please come! ------------ ********************************************************************* DIMACS/CCICADA Workshop on Secure Routing March 10-12, 2010 DIMACS Center, CoRE Building, Rutgers University Organizers: Steve Bellovin, Columbia University, smb at cs.columbia.edu Nick Feamster, Georgia Institute of Technology, feamster at cc.gatech.edu Aaron D. Jaggard, Rutgers University, adj at dimacs.rutgers.edu Vijay Ramachandran, Colgate University, vramachandran at colgate.edu Presented under the auspices of the DIMACS Special Focus on Algorithmic Foundations of the Internet and the Command, Control, and Interoperability Center for Advanced Data Analysis (CCICADA). ************************************************ This workshop will bring together experts in networking, algorithms, mechanism design, and other areas to discuss recent progress and future directions in securing network routing, including robustness in the face of misconfiguration or rational behavior and defense against active attacks. ******************************************************************** Participation: We are soliciting short abstract submissions to be considered for a presentation at the workshop. Abstracts should be on recent progress and future directions in secure network routing; this includes (but is not limited to) theory, analysis, design, and experimental work related to robustness in the face of misconfiguration or rational behavior, defense against active attacks, and other problems relevant to secure routing. Because there will be no published proceedings we welcome submissions covering material that was previously presented elsewhere (and referenced as such). Instructions for authors: Submissions should include talk title, speaker name, affiliation, contact information, and a short abstract. Please mail abstracts to Aaron Jaggard (adj at dimacs.rutgers.edu) by Friday, January 22, 2010. ******************************************************************** Registration: (Pre-registration deadline: February 15, 2010) Please see website for complete registration details. ********************************************************************* Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/SecureRouting/ **PLEASE BE SURE TO PRE-REGISTER EARLY** ******************************************************************** From nanog-post at rsuc.gweep.net Thu Jan 21 20:40:21 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 21 Jan 2010 21:40:21 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> Message-ID: <20100122024020.GA61379@gweep.net> On Thu, Jan 21, 2010 at 05:13:39PM -0800, George Bonser wrote: [snip] > Some of that water is dirtier than the rest. I wouldn't want to be the > person who gets 1.2.3.0/24 Yeah, I encountered some lovely wireless hotspots that use "visit http://1.1.1.1/ to log out". Seem some vendors encourage the behavior: http://www.cisco.com/en/US/docs/wireless/controller/4.1/configuration/guide/c41users.html (as propagated by 'amerispot.com', 'vhotspot.com.au', and some vendor I forget who does a lot of marine 802.11<->sat NAT service). -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From randy at psg.com Thu Jan 21 20:50:00 2010 From: randy at psg.com (Randy Bush) Date: Fri, 22 Jan 2010 11:50:00 +0900 Subject: UC phone system for Haiti (was Katrina Response) In-Reply-To: <648A0A8C-0ACE-4CC6-B937-266DB045E97B@cs.columbia.edu> References: <4B508C67.5000309@nic-naa.net> <9ab36b821001160743t12a20027nf72aa6b22da2837@mail.gmail.com> <4B523F68.6080305@nic-naa.net> <4B53970B.7050600@nic-naa.net> <11B064048F34FD4094CBA16FC04BE2198638C676@ex01> <4B53F390.4040007@nic-naa.net> <4B55ED63.3050407@nic-naa.net> <4B55F6AA.9020903@rollernet.us> <4B55FA93.5040408@nic-naa.net> <67FF8F18-1EFE-418E-82B2-AD1FA652DB46@centergate.com> <9ab36b821001191439s8568498ha61ad495341e570d@mail.gmail.com> <15BDDC14871D2A49BFCEEEF409EB29830323771A@exchange.syssrcad.syssrc.com> <648A0A8C-0ACE-4CC6-B937-266DB045E97B@cs.columbia.edu> Message-ID: > http://www.wired.com/dangerroom/2010/01/texts-tweets-saving-haitians-from-the-rubble/ > there seem to be innovative uses of technology in play. the ushahidi folk () seem pretty pro and have turned their katrina experience really well. randy From chaim.rieger at gmail.com Thu Jan 21 20:53:35 2010 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Fri, 22 Jan 2010 02:53:35 +0000 Subject: UC phone system for Haiti (was Katrina Response) Message-ID: <726037536-1264128820-cardhu_decombobulator_blackberry.rim.net-1740310496-@bda123.bisx.prod.on.blackberry> We had a major turnout this past weekend here in southern cal. Shout out to the uc system and people. Sent via BlackBerry from T-Mobile From jlewis at lewis.org Thu Jan 21 20:56:54 2010 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 21 Jan 2010 21:56:54 -0500 (EST) Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B5904ED.9030804@tonal.clara.co.uk> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <4B5904ED.9030804@tonal.clara.co.uk> Message-ID: On Fri, 22 Jan 2010, Neil Harris wrote: >> I thought there was some other group that had been squatting in 1/8, >> something about radio and peer to peer...but not AnoNet (at least that name >> was totally unfamiliar)...but this was all I could find with a quick >> google. > > This? > > http://lists.arin.net/pipermail/arin-ppml/2003-May/001628.html Yeah...that's the one. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ge at linuxbox.org Thu Jan 21 21:52:11 2010 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 22 Jan 2010 05:52:11 +0200 Subject: Anyone see a game changer here? In-Reply-To: <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> Message-ID: <4B5920EB.9070404@linuxbox.org> On 1/15/10 5:52 PM, Steven Bellovin wrote: > The "difference" this week is motive. > > In the 1980s-1990s, we had joy-hacking. > > In the 2000s, we had profit-motivated hacking by criminals. > > We now have (and have had for a few years) what appears to be nation-state hacking. The differences are in targets and resources available to the attacker. Following up -- I just wrote a blog on the subject called "the fog of cyberwar": http://darkreading.com/blog/archives/2010/01/fog_of_cyberwar.html In short: While we are all talking of Google's morals and US/China diplomacy, there are some questions that mostly remain unasked: 1. Did Google hack a Taiwanese server to investigate the breach? If so, good for them. Our ethics need to catch up to our morals, as we usually wake up to a new world others created for us, a few years too late. But, for now, it's still illegal so some details would be nice. As you know, I have been calling for more than "get slapped, write analysis" response to cyber crime for a long time, but we need to be careful not to start an offensive the Internet can't win (criminals willing to play scorched Earth--we're not, and our legal/ethical limitations). 2. Is Microsoft, while usually timely and responsible, completely irresponsible in wanting to patch this only in February? While they patched it sooner (which couldn't have been easy), their over-all policy is very disturbing and in my opinion calls for IE to not be used anymore. 3. Why are people treating targeted attacks as a new threat model? Their threat models are just old. This we discussed here. Oh yeah, and this is espionage, not cyber war. Computers are just new tools/weapons for an old motive. Espionage unlike cyber crime and cyber war is well established in law and diplomacy both. Security experts should not spread fear, and they definitely shouldn't be the ones people look to for answers on this. Thoughts? Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From joelja at bogus.com Thu Jan 21 23:02:37 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 Jan 2010 21:02:37 -0800 Subject: fix the edge (was Re: 1/8 and 27/8 allocated to APNIC) In-Reply-To: <2e9d8ae51001211751x3fd56384te2322be25a83d99c@mail.gmail.com> References: <2e9d8ae51001211751x3fd56384te2322be25a83d99c@mail.gmail.com> Message-ID: <4B59316D.5000806@bogus.com> Anton Kapela wrote: > On Thu, Jan 21, 2010 at 8:22 PM, Jon Lewis wrote: > >> I thought there was some other group that had been squatting in 1/8, >> something about radio and peer to peer...but not AnoNet (at least that name >> was totally unfamiliar)...but this was all I could find with a quick google. > > http://en.wikipedia.org/wiki/AnoNet#Scaling > > oh, the irony. good thing privacy costs too much for the majority of > internet users. > > on a serious note, who cares? Resolution to the 1/8 allocation "mess" > seems on par with freeing up IP stacks from excluding 240/4, but by > the time any of this is resolved, perhaps residential users on att > dsl/etc might just have working IP6CP, or will have switched to > comcast by then. It's way lower than 240/4 one doesn't have to patch the kernel on a billion devices. > -Tk > From jim at reptiles.org Thu Jan 21 23:07:32 2010 From: jim at reptiles.org (Jim Mercer) Date: Fri, 22 Jan 2010 00:07:32 -0500 Subject: policies for 24.0.0.0/8 ? Message-ID: <20100122050732.GO58786@reptiles.org> i'm doing some consulting work for a cable operator in Pakistan. while i'm guessing that realistically we will be approaching RIPE for address space, i'm just wandering what happened to 24.0.0.0/8 and what policies govern who and what can use the address space there. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 mysidia at gmail.com Thu Jan 21 23:19:38 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 21 Jan 2010 23:19:38 -0600 Subject: Anyone see a game changer here? In-Reply-To: <4B5920EB.9070404@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> Message-ID: <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> On Thu, Jan 21, 2010 at 9:52 PM, Gadi Evron wrote: > On 1/15/10 5:52 PM, Steven Bellovin wrote: ..> 2. Is Microsoft, while usually timely and responsible, completely > irresponsible in wanting to patch this only in February? While they patched > it sooner (which couldn't have been easy), their over-all policy is very > disturbing and in my opinion calls for IE to not be used anymore. It is not as if there are a wealth of alternatives. There are still many cases, where IE or MSHTML components are a pre-requisite, to access a certain product that is important to the user. A canonical example, would be: Intranet apps, web-managed routers, switches, firewalls, or other network infrastructure that can only be administered using MSIE version 6 (ActiveX control, or old HTML relying on IE features) -- probably devices with old software. Mail readers such as Outlook with MSHTML components embedded. ..> 3. Why are people treating targeted attacks as a new threat model? Their > threat models are just old. This we discussed here. It's an old model that could have fallen into some measure of disuse. Targeted attacks are possibly riskier to launch than randomly dispersed attacks, and require an insider or more determined attacker who can effect social engineering in the right place; the result is they are rarer. Intuitively, hardly any user thinks they can personally be subject to a complex targetted attack penetrating multiple security layers and requiring obscure enterprise-specific info.... until it happens... because people assume complexity of the required attack, and 'security software' such as Antivirus lead to a high level of safety, without ever having a logical or statistically rigorous basis for arriving at the assumption. Perhaps there were so many non-targetted attacks, that the idea of "targetted attack" was drowned out of the security dialogue and forgotten by some.. or there was a mistaken belief that the targetted attacks automatically get stopped by the firewall and mod_security... -- I believe 3 to 4 weeks is par for the course, with most major software manufacturers, even for a patch to a critical security issue... It is really impossible to make a reasonable assessment on Microsofts' response based on just one event (where in fact, they pulled through). I don't perceive that Microsoft have any solid history of being more timely or more responsible, than other vendors. In most cases, they have released patches soon after a serious advisory was made public, but the date the vulnerability was first discovered and reported to Microsoft, is not disclosed in the advisory or patch too often, that I saw. As I understand: a vulnerability might have first been reported to MS months or years before they released a patch or even acknowledged there was an issue, in some cases. Sometimes they even advise, but say there will be no patch (e.g. Windows XP and MS09-048 ). A "true" zero day like the recent one, where the exploit is in the wild and in use by blackhats prior to the vendor even being aware of a possible vulnerability, is a different animal, than routine security patches (even ones listed as critical or high-priority). Because (no doubt) it requires some strong measure of analysis first to determine what code is being exploited, in addition to the normal steps involved in fixing a hole.... e.g. determining what the actual possible bug(s) are, and how to fix, without probably introducing new ones, or missing some conditions. -- -J From williams.bruce at gmail.com Thu Jan 21 23:26:45 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Thu, 21 Jan 2010 21:26:45 -0800 Subject: Anyone see a game changer here? In-Reply-To: <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> Message-ID: <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> The problem with IE is the same problem as Windows, the basic design is fundementally insecure and "timely updates" can't fix that. Bruce On Thu, Jan 21, 2010 at 9:19 PM, James Hess wrote: > On Thu, Jan 21, 2010 at 9:52 PM, Gadi Evron wrote: >> On 1/15/10 5:52 PM, Steven Bellovin wrote: > ..> 2. Is Microsoft, while usually timely and responsible, completely >> irresponsible in wanting to patch this only in February? While they patched >> it sooner (which couldn't have been easy), their over-all policy is very >> disturbing and in my opinion calls for IE to not be used anymore. > > It is not as if there are a wealth of alternatives. ? There are still > many cases, ?where IE ?or MSHTML components are a pre-requisite, ?to > access a certain product ?that is ?important to the user. ? ?A > canonical example, ?would be: > > Intranet apps, web-managed ?routers, switches, firewalls, or other > network infrastructure that can only be administered using MSIE > version 6 (ActiveX control, or old HTML relying on IE features) -- > probably devices with old software. > Mail readers such as Outlook with ?MSHTML components embedded. > > ..> 3. Why are people treating targeted attacks as a new threat model? Their >> threat models are just old. This we discussed here. > > It's an old model that could have fallen into some measure of disuse. > ? Targeted ?attacks ?are possibly riskier to launch than randomly > dispersed ?attacks, ?and require an insider or more determined > attacker ?who can effect social engineering in the right place; ? the > result is they are rarer. > > Intuitively, ?hardly any user thinks ?they can personally be subject > to a complex targetted attack penetrating multiple security layers and > requiring obscure enterprise-specific info.... until it happens... > because people assume complexity of the required attack, ?and > 'security software' such as Antivirus lead to a high level of safety, > without ever having a logical or statistically rigorous basis for > arriving at the assumption. > > Perhaps there were so many non-targetted attacks, ?that the idea of > "targetted attack" ?was ?drowned out of the security dialogue and > forgotten by some.. ? or there was a mistaken belief ?that ?the > targetted attacks automatically get stopped by the firewall ? and > mod_security... > > -- > I believe 3 to 4 ?weeks ?is par for the course, ?with most ?major > software manufacturers, even for a patch to a critical security > issue... > > > It is really impossible to make a reasonable assessment on > Microsofts' response based on just one event ?(where in fact, they > pulled through). > > I don't perceive that Microsoft have any solid history of being more timely ?or > ?more responsible, than other vendors. ?In most cases, ?they have > released patches soon after a serious advisory was made public, ?but > the date the vulnerability was first discovered and reported to > Microsoft, ?is not disclosed in the advisory or patch too often, that > I saw. ? As I understand: a vulnerability ?might ?have first been > reported to MS ?months or years before they released a patch ?or even > acknowledged there was an issue, in some cases. ? ?Sometimes they even > advise, but say there will be no patch ?(e.g. ?Windows XP and > MS09-048 ). > > > A ?"true" ?zero day ?like the recent one, ?where the exploit is in the > wild and in use by blackhats ?prior to ?the vendor even being aware of > ?a possible vulnerability, ?is a different animal, ?than routine > security patches (even ones listed as critical or high-priority). > > Because (no doubt) ?it requires some strong measure of analysis first > to determine what code is being exploited, ?in addition to the normal > steps involved in fixing a hole.... ? e.g. ?determining ?what the > actual possible bug(s) are, and how to fix, without ?probably > introducing new ones, ? or ?missing some conditions. > > > -- > -J > > -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From rmacharia at gmail.com Fri Jan 22 00:45:37 2010 From: rmacharia at gmail.com (Raymond Macharia) Date: Fri, 22 Jan 2010 09:45:37 +0300 Subject: Network Bandwidth Reporting Tool In-Reply-To: <1264126383.4965.14.camel@icelaptop> References: <1264126383.4965.14.camel@icelaptop> Message-ID: Hi, 1. ETINC - www.etinc.com - Really good with a mysql backend and gives you exactly what you are looking for. You can either buy the software and build it into a FreeBSD box or you can get the already built appliance. The price point is also quite good 2. Allot - www.allot.com -Comes with a lot of features and has a good reporting mechanism. They have boxes of different sizes and add on software for reports etc. higher priced but works very well. Regards Raymond Macharia On Fri, Jan 22, 2010 at 5:13 AM, Isaac Conway wrote: > Oh mighty list, > I am curious what tools you use to generate monthly usage and billing > reports for your execs? I am not really looking for a RRD type > solution, rather a page I can pull up and gives me the numbers (95p, > cost, overage, etc.) for the past month. Copy and paste into a > spreadsheet, job complete.... > > We are getting to the point where we have multiple datacenters and > numerous uplinks and circuits for each, I find I am spending too many > hours each month compiling data. > > I was thinking about writing some quick scripts to poll the router > interfaces and put it to database, but I figured I would ask before > re-inventing the wheel. > > Thanks in advance! > Isaac > > > From gordslater at ieee.org Fri Jan 22 01:19:38 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 22 Jan 2010 07:19:38 +0000 Subject: Anyone see a game changer here? In-Reply-To: <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> Message-ID: <1264144778.17421.149.camel@ub-g-d2> On Thu, 2010-01-21 at 23:19 -0600, James Hess wrote: > On Thu, Jan 21, 2010 at 9:52 PM, Gadi Evron wrote: > > It is not as if there are a wealth of alternatives. There are still > many cases, where IE or MSHTML components are a pre-requisite, to > access a certain product that is important to the user. A > canonical example, would be: > > Intranet apps, web-managed routers, switches, firewalls, or other > network infrastructure that can only be administered using MSIE > version 6 (ActiveX control, or old HTML relying on IE features) -- > probably devices with old software. > Mail readers such as Outlook with MSHTML components embedded. > Luckily, in the last 18 months especially, I've seen several different corporate requirements tender specify __against__ these (huge) problems, at least in non-US contracts. The first-hand argument I've heard for this is that it can actually reduce the tendered proposal bottom line and TCO, quite the reverse of what you would assume (probably by more lateral thinking by the Tenders) Notably, ActiveX was proscribed, followed recently by Silverlight. Certainly, the first firm to do it about 3 years ago has now written it in to EVERY request as standard text. Granted these are only around half-to-1M US$ tenders, but it's a (small) start. If this actually improves the general market/quality/usability of devices it's yet to be seen by me and my circle; maybe they are all just niche companies. They use lots of Sun/EMC/Brocade and similar. Yet, I have to say that the kit they end up installing is much easier to work with for Beasties and Tuxheads; far fewer VMs or Wine just to use IE or some obscure app (to us, that is) so a much faster/more familiar job-flow, and less gotchas/misconfigs. Still, no complaints from MS trained/based engineers that I've heard of that get contracted-in, this isn't super-uber-BOFH stuff. I was truly shocked the first time I read "Standards Compliant" and "BCPs/RFCs" in a corporate acquisition tender pack, for sure. YMV. Gord From nonobvious at gmail.com Fri Jan 22 02:28:23 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 22 Jan 2010 00:28:23 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> Message-ID: <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> On Thu, Jan 21, 2010 at 5:13 PM, George Bonser wrote: > Some of that water is dirtier than the rest. ?I wouldn't want to be the > person who gets 1.2.3.0/24 I'd guess that 1.1.1.1 and 2.2.2.2 are probably much more widely used. At least 1.1.1.0/24 should be reserved by IANA or somebody. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nick at foobar.org Fri Jan 22 04:07:35 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Jan 2010 10:07:35 +0000 Subject: policies for 24.0.0.0/8 ? In-Reply-To: <20100122050732.GO58786@reptiles.org> References: <20100122050732.GO58786@reptiles.org> Message-ID: <4B5978E7.8030300@foobar.org> On 22/01/2010 05:07, Jim Mercer wrote: > i'm doing some consulting work for a cable operator in Pakistan. > > while i'm guessing that realistically we will be approaching RIPE for address > space, i'm just wandering what happened to 24.0.0.0/8 and what policies > govern who and what can use the address space there. Not quite sure why you'd want to use 24/8. It became a "normal" address block a very long time ago . RFC3330 sez: > 24.0.0.0/8 - This block was allocated in early 1996 for use in > provisioning IP service over cable television systems. Although the > IANA initially was involved in making assignments to cable operators, > this responsibility was transferred to American Registry for Internet > Numbers (ARIN) in May 2001. Addresses within this block are assigned > in the normal manner and should be treated as such. So, it's just regular IP address space, available for assignment if you live in ARIN-land. Incidentally, Pakistan is serviced by APNIC, not RIPE: http://www.apnic.net/about-APNIC/organization/apnics-region Nick From bandwidth.user at gmail.com Fri Jan 22 04:09:21 2010 From: bandwidth.user at gmail.com (roy) Date: Fri, 22 Jan 2010 18:09:21 +0800 Subject: AS3549 In-Reply-To: <2982D4EC0F226648BA4B87FD35318C0CD44A155071@is-exch-001.office.is.nl> References: <2982D4EC0F226648BA4B87FD35318C0CD44A155071@is-exch-001.office.is.nl> Message-ID: <4B597951.40401@gmail.com> We had some problems with them too between their NYC and Sunnyvale pops from Jan 21 1000h UTC to 1700h UTC. Edge began dropping packets. No RFO as of yet. On Friday, 22 January, 2010 01:58 AM, Hans Goes wrote: > > Just wondering if other people on this list experience similar problems with > BGP sessions behind AS3549 ? > > It seems our trouble ticket is currently being taken care of and the > GlobalCrossing NOC is investigating. > > If other people experience the same thing please let me know. > > PS: we are located in Amsterdam, Netherlands > > Hans Goes > Senior Network Engineer > > IS Interned Services - PROUD AND CLEAR. > www.is.nl > +31 299 476 185 > Gorslaan 18 > 1441 RG Purmerend > The Netherlands > > > > cr1.ams2#sho ip bgp flap-stat inc 208.50.59.105 > *> 4.23.88.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.23.89.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.23.92.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.23.94.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.38.0.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.38.8.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.43.50.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.43.51.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.67.96.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 4.67.104.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 8.14.0.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 8.14.16.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 > *> 24.49.84.0/23 208.50.59.105 1 00:01:22 3549 3356 7843 > *> 24.49.89.0/24 208.50.59.105 1 00:01:22 3549 3356 7843 > * 38.97.109.0/24 208.50.59.105 2 00:25:18 3549 701 20417 > * 41.0.144.0/20 208.50.59.105 2 00:21:47 3549 5713 36994 From jim at reptiles.org Fri Jan 22 04:27:03 2010 From: jim at reptiles.org (Jim Mercer) Date: Fri, 22 Jan 2010 05:27:03 -0500 Subject: policies for 24.0.0.0/8 ? In-Reply-To: <4B5978E7.8030300@foobar.org> References: <20100122050732.GO58786@reptiles.org> <4B5978E7.8030300@foobar.org> Message-ID: <20100122102702.GA78676@reptiles.org> On Fri, Jan 22, 2010 at 10:07:35AM +0000, Nick Hilliard wrote: > On 22/01/2010 05:07, Jim Mercer wrote: > > i'm just wandering what happened to 24.0.0.0/8 and what policies > > govern who and what can use the address space there. > > Not quite sure why you'd want to use 24/8. It became a "normal" address > block a very long time ago . RFC3330 sez: > > > 24.0.0.0/8 - This block was allocated in early 1996 for use in ... > > Numbers (ARIN) in May 2001. Addresses within this block are assigned > > in the normal manner and should be treated as such. > > So, it's just regular IP address space, available for assignment if you > live in ARIN-land. hrm, somehow i missed that. > Incidentally, Pakistan is serviced by APNIC, not RIPE: > > http://www.apnic.net/about-APNIC/organization/apnics-region wow, musta been sleeping that day. any how, it is what it is. -- Jim Mercer jim at reptiles.org +92 336 520-4504 "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 pstewart at nexicomgroup.net Fri Jan 22 06:21:57 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 22 Jan 2010 07:21:57 -0500 Subject: Network Bandwidth Reporting Tool In-Reply-To: References: <1264126383.4965.14.camel@icelaptop> Message-ID: Arbor boxes (E30/E100) also do this kind of reporting with very granular options - not cheap, but work well... Paul -----Original Message----- From: Raymond Macharia [mailto:rmacharia at gmail.com] Sent: January-22-10 1:46 AM To: Isaac Conway Cc: nanog list Subject: Re: Network Bandwidth Reporting Tool Hi, 1. ETINC - www.etinc.com - Really good with a mysql backend and gives you exactly what you are looking for. You can either buy the software and build it into a FreeBSD box or you can get the already built appliance. The price point is also quite good 2. Allot - www.allot.com -Comes with a lot of features and has a good reporting mechanism. They have boxes of different sizes and add on software for reports etc. higher priced but works very well. Regards Raymond Macharia On Fri, Jan 22, 2010 at 5:13 AM, Isaac Conway wrote: > Oh mighty list, > I am curious what tools you use to generate monthly usage and billing > reports for your execs? I am not really looking for a RRD type > solution, rather a page I can pull up and gives me the numbers (95p, > cost, overage, etc.) for the past month. Copy and paste into a > spreadsheet, job complete.... > > We are getting to the point where we have multiple datacenters and > numerous uplinks and circuits for each, I find I am spending too many > hours each month compiling data. > > I was thinking about writing some quick scripts to poll the router > interfaces and put it to database, but I figured I would ask before > re-inventing the wheel. > > Thanks in advance! > Isaac > > > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From brunner at nic-naa.net Fri Jan 22 06:48:26 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 22 Jan 2010 07:48:26 -0500 Subject: DIMACS/CCICADA secure routing workshop rescheduled In-Reply-To: <526BB3F5-CB4C-405E-89F0-D7E1F24D0153@cs.columbia.edu> References: <526BB3F5-CB4C-405E-89F0-D7E1F24D0153@cs.columbia.edu> Message-ID: <4B599E9A.1090907@nic-naa.net> On 1/21/10 9:16 PM, Steven Bellovin wrote: > OK, folks -- we've corrected the scheduling conflict. The secure routing working is now March 10-12. Please come! But, But, But, That conflicts with ICANN ... Oh. Never mind. According to the Protocol Supporting Organization Depricated decision of 2003 and the Address Supporting Organization Dormant Blessed Practices, there is no "security and stability" rational for secure routing. /rant From Valdis.Kletnieks at vt.edu Fri Jan 22 07:24:05 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 22 Jan 2010 08:24:05 -0500 Subject: Anyone see a game changer here? In-Reply-To: Your message of "Fri, 22 Jan 2010 05:52:11 +0200." <4B5920EB.9070404@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> Message-ID: <18029.1264166645@localhost> On Fri, 22 Jan 2010 05:52:11 +0200, Gadi Evron said: > 1. Did Google hack a Taiwanese server to investigate the breach? If so, > good for them. No, *not* good. If *you* had a server that got compromised, and used to launch attacks on 500 sites, would you want to try to deal with 500 return strikes? Especially if the initial strike happens at 5:47PM on a Friday, and by the time you come in on Monday morning, you've been pwned by 197 different return strikes? Then the fun *really* starts when you call your national CERT and report you've been hit by an organized set of targeted attacks from 198 locations and hilarity ensues because your CERT can't contact 143 of them and verify it was a return strike. Definitely one of the sillier things I've heard Gadi say in a while... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From william.allen.simpson at gmail.com Fri Jan 22 07:54:37 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 22 Jan 2010 08:54:37 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> Message-ID: <4B59AE1D.5080305@gmail.com> Bill Stewart wrote: > On Thu, Jan 21, 2010 at 5:13 PM, George Bonser wrote: >> Some of that water is dirtier than the rest. I wouldn't want to be the >> person who gets 1.2.3.0/24 > > I'd guess that 1.1.1.1 and 2.2.2.2 are probably much more widely used. > At least 1.1.1.0/24 should be reserved by IANA or somebody. > > > I agree that 1/8 was probably about the *last* that should have been allocated. It's particularly frustrating that they made two assignments at the same time, but not to adjacent routing blocks.... Also, 27/8 is clearly in the middle of a group of North American military assignments. So at the very least, these aren't very CIDR'ish. Why not 36 & 37? From r.bhatia at ipax.at Fri Jan 22 08:00:56 2010 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Fri, 22 Jan 2010 15:00:56 +0100 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59AE1D.5080305@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> Message-ID: <4B59AF98.8080507@ipax.at> On 01/22/2010 02:54 PM, William Allen Simpson wrote: > Why not 36 & 37? please refer to http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From bortzmeyer at nic.fr Fri Jan 22 08:01:30 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 22 Jan 2010 15:01:30 +0100 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59AE1D.5080305@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> Message-ID: <20100122140130.GA10898@nic.fr> On Fri, Jan 22, 2010 at 08:54:37AM -0500, William Allen Simpson wrote a message of 20 lines which said: > I agree that 1/8 was probably about the *last* that should have been > allocated. It's particularly frustrating that they made two > assignments at the same time, but not to adjacent routing blocks.... http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ From fweimer at bfk.de Fri Jan 22 08:02:19 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 22 Jan 2010 14:02:19 +0000 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59AE1D.5080305@gmail.com> (William Allen Simpson's message of "Fri\, 22 Jan 2010 08\:54\:37 -0500") References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> Message-ID: <82ockmnspg.fsf@mid.bfk.de> * William Allen Simpson: > Bill Stewart wrote: >> On Thu, Jan 21, 2010 at 5:13 PM, George Bonser wrote: >>> Some of that water is dirtier than the rest. I wouldn't want to be the >>> person who gets 1.2.3.0/24 >> >> I'd guess that 1.1.1.1 and 2.2.2.2 are probably much more widely used. >> At least 1.1.1.0/24 should be reserved by IANA or somebody. >> >> >> > I agree that 1/8 was probably about the *last* that should have been > allocated. It's probably better to decouple the pain of taking 1/8 and 2/8 into production from the general pain of running out in ernest (assuming that we ever enter an age where IP addresses are a scarce resource). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nick at foobar.org Fri Jan 22 08:03:56 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Jan 2010 14:03:56 +0000 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59AE1D.5080305@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> Message-ID: <4B59B04C.7080706@foobar.org> On 22/01/2010 13:54, William Allen Simpson wrote: > Also, 27/8 is clearly in the middle of a group of North American military > assignments. So at the very least, these aren't very CIDR'ish. Is that operationally relevant to the /8 assignment process? > Why not 36 & 37? Random selection to ensure that no RIR can accuse IANA of bias. See David's previous post: http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ Nick From william.allen.simpson at gmail.com Fri Jan 22 09:16:12 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 22 Jan 2010 10:16:12 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59B04C.7080706@foobar.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> Message-ID: <4B59C13C.4090109@gmail.com> Nick Hilliard wrote: > On 22/01/2010 13:54, William Allen Simpson wrote: >> Why not 36 & 37? > > Random selection to ensure that no RIR can accuse IANA of bias. See > David's previous post: > > http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ > Because relying on a blog post for policy really meets everybody's definition of rationality.... :-( If you're assigning 2 at the same time, they should be adjacent. The dribbles here and there policy never was particularly satisfying, because it assumes that this was all temporary until the widespread deployment of IPv6. From bortzmeyer at nic.fr Fri Jan 22 09:23:34 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 22 Jan 2010 16:23:34 +0100 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59C13C.4090109@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> Message-ID: <20100122152334.GA24197@nic.fr> On Fri, Jan 22, 2010 at 10:16:12AM -0500, William Allen Simpson wrote a message of 17 lines which said: >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ >> > Because relying on a blog post for policy I'm fairly certain that it is because the ICANN staff can post on its own blog at will while creating a "real" policy and publishing it on the official Web site requires five years, the (paid) advice of ten lawyers and the signature of five vice-presidents. From richard.barnes at gmail.com Fri Jan 22 09:30:01 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 22 Jan 2010 10:30:01 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59C13C.4090109@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> Message-ID: <88ac5c711001220730q702468c8w7010b638e7a0ddfc@mail.gmail.com> To echo and earlier post, what's the operational importance of assigning adjacent /8s? Are you hoping to aggregate them into a /7? --Richard On Fri, Jan 22, 2010 at 10:16 AM, William Allen Simpson wrote: > Nick Hilliard wrote: >> >> On 22/01/2010 13:54, William Allen Simpson wrote: >>> >>> Why not 36 & 37? >> >> Random selection to ensure that no RIR can accuse IANA of bias. ?See >> David's previous post: >> >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ >> > Because relying on a blog post for policy really meets everybody's > definition of rationality.... :-( > > If you're assigning 2 at the same time, they should be adjacent. > > The dribbles here and there policy never was particularly satisfying, > because it assumes that this was all temporary until the widespread > deployment of IPv6. > > From jcurran at arin.net Fri Jan 22 10:02:16 2010 From: jcurran at arin.net (John Curran) Date: Fri, 22 Jan 2010 11:02:16 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59C13C.4090109@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> Message-ID: In the absence of global policy on this matter, the RIRs and IANA try to work together in the tradition of the Internet in order to keep things running as smoothly as possible. This is a *feature* not a bug. If you want formal policy in this area, it's very easy to submit a proposal for global number policy to each of the RIRs and that will produce the desired result. One should be realistic about the time requirements to produce uniform global policy; it looks to take about 12 to 18 months from policy initiation to global adoption at present. /John On Jan 22, 2010, at 10:16 AM, William Allen Simpson wrote: > Nick Hilliard wrote: >> On 22/01/2010 13:54, William Allen Simpson wrote: >>> Why not 36 & 37? >> Random selection to ensure that no RIR can accuse IANA of bias. See >> David's previous post: >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ > Because relying on a blog post for policy really meets everybody's > definition of rationality.... :-( > > If you're assigning 2 at the same time, they should be adjacent. > > The dribbles here and there policy never was particularly satisfying, > because it assumes that this was all temporary until the widespread > deployment of IPv6. > From nick at foobar.org Fri Jan 22 10:17:44 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Jan 2010 16:17:44 +0000 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59C13C.4090109@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> Message-ID: <4B59CFA8.9000308@foobar.org> On 22/01/2010 15:16, William Allen Simpson wrote: > Because relying on a blog post for policy really meets everybody's > definition of rationality.... :-( What works then? What happened to rough consensus and running code? > If you're assigning 2 at the same time, they should be adjacent. > > The dribbles here and there policy never was particularly satisfying, > because it assumes that this was all temporary until the widespread > deployment of IPv6. I don't get where you're coming from here. I can see that there is a (very minor) aesthetic reason to assign adjacent /8s to a RIR. But operationally, I really can't see any other reason. Someone else mentioned that we are now scraping the bottom of the ipv4 barrel. As of two days ago, there were quantifiable problems associated with 13 out of the 26 remaining /8s. 12 of these are known to be used to one extent or another on internet connected networks, and are seen as source addresses on various end-points around the place. One of them (223/8) has rfc-3330 issues (although later fixed in 5735). So, the issue for IANA is how to allocate these /8s in a way which is demonstrably unbiased towards any particular RIR. The solution which they've agreed on with the RIRs looks unbiassed, unpredictable in advance, calculable in retrospect and best of all, it's not open to abuse. And while Chuck Norris could probably predict the footsie, the djia and the hang-seng weeks in advance, this sort of prognostication appears to be beyond the capabilities of ICANN, IANA and the RIRs. At least if it isn't, no-one's saying anything. Do you have a better suggestion about how to allocate tainted address space in a way that is going to ensure that the organisations at the receiving end aren't going to accuse you of bias? Nick From Brian.Dickson at concertia.com Fri Jan 22 10:32:30 2010 From: Brian.Dickson at concertia.com (Brian Dickson) Date: Fri, 22 Jan 2010 12:32:30 -0400 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59CFA8.9000308@foobar.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> Message-ID: <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> Nick Hilliard wrote: Someone else mentioned that we are now scraping the bottom of the ipv4 barrel. As of two days ago, there were quantifiable problems associated with 13 out of the 26 remaining /8s. 12 of these are known to be used to one extent or another on internet connected networks, and are seen as source addresses on various end-points around the place. One of them (223/8) has rfc-3330 issues (although later fixed in 5735). So, the issue for IANA is how to allocate these /8s in a way which is demonstrably unbiased towards any particular RIR. The solution which they've agreed on with the RIRs looks unbiassed, unpredictable in advance, calculable in retrospect and best of all, it's not open to abuse. And while Chuck Norris could probably predict the footsie, the djia and the hang-seng weeks in advance, this sort of prognostication appears to be beyond the capabilities of ICANN, IANA and the RIRs. At least if it isn't, no-one's saying anything. Do you have a better suggestion about how to allocate tainted address space in a way that is going to ensure that the organisations at the receiving end aren't going to accuse you of bias? My response: The granularity of allocations is arbitrary, and when scraping the bottom of the barrel, where there are known problems, it may time to get more granular. There's really no difference in managing a handful of /N's rather than /8's, if N is not that much bigger than 8. The granularity boundary probably should stay around or above the biggest assignments a given RIR is expected to make, or has made. So, if the tainted *portions* of problem /8's are set aside, you end up with sets of varying sizes of /N. E.g. if there is one /24 that is a problem, you set that aside, and end up with a set that consists of one each of /9 through /24. Even if you set aside a /16, you get a set which is /9, /10, /11, /12, /13, /14, /15, and /16. >From a documentation and allocation perspective, you could even treat that as giving the whole of the /8 to the RIR, and having them give back (assign) the problem chunk to IANA. Do this for the 13 problem /8's, and then group the resulting untainted sets and give them out. Give them out according to the needs of the RIRs, and the larger community will consider it fair. No one will think badly of giving the /9's to one of the big 3 (APNIC, ARIN, or RIPE), and the smaller ones to the other RIRs, I'm sure. As long as there are no tainted portions assigned to the RIRs, I don't see how this could be a problem. Brian From leo.vegoda at icann.org Fri Jan 22 10:56:56 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 22 Jan 2010 08:56:56 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> Message-ID: <30C06702-F4FF-4128-8792-3A9D480085DF@icann.org> On 22 Jan 2010, at 8:32, Brian Dickson wrote: [...] > The granularity of allocations is arbitrary, and when scraping the bottom of the barrel, > where there are known problems, it may time to get more granular. > > There's really no difference in managing a handful of /N's rather than /8's, if N is not > that much bigger than 8. You need to change the global policy to do that. ICANN staff cannot allocate anything more specific than a /8 right now because the policy requires IPv4 allocations to the RIRs be in /8 units. http://www.icann.org/en/general/allocation-IPv4-rirs.html Regards, Leo From leo.vegoda at icann.org Fri Jan 22 10:58:30 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 22 Jan 2010 08:58:30 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59C13C.4090109@gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> Message-ID: <17CF5BAC-CF1E-43DE-A407-DF987E75359F@icann.org> On 22 Jan 2010, at 7:16, William Allen Simpson wrote: [...] >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ >> > Because relying on a blog post for policy really meets everybody's > definition of rationality.... :-( It's not a policy, it's an explanation of the reasoning behind the implementation of the policy. Regards, Leo From bpasdar at batblue.com Fri Jan 22 11:37:11 2010 From: bpasdar at batblue.com (Babak Pasdar) Date: Fri, 22 Jan 2010 12:37:11 -0500 Subject: Comcast Packet Loss Message-ID: <20100122173711.33d2337e@concur.batblue.com> Hello all, For the past few days we have been seeing some massive performance problems for all west coast users who are trying to reach our systems through Comcast. I am wondering if other people are seeing this. Now I am If anyone from Comcast is on the board, we would appreciate some information as to what is happening. Best Regards, Babak Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.255.254.1 0.0% 675 0.5 0.4 0.4 19.5 0.8 2. 208.85.64.254 0.0% 675 1.7 5.0 0.8 21.6 4.3 3. 208.85.64.253 0.0% 675 8.8 6.1 1.4 21.5 4.1 4. gige-g2-9.core1.nyc5.he.net 0.0% 675 9.8 2.5 1.4 19.0 2.7 5. 10gigabitethernet1-4.core1.nyc1.he.net 0.0% 675 3.9 4.0 1.4 25.5 3.8 6. 10gigabitethernet1-1.core1.nyc4.he.net 0.0% 675 1.8 3.2 1.6 16.3 3.2 7. TenGigabitEthernet1-3.ar5.NYC1.gblx.net 0.0% 675 1.7 7.5 1.7 205.3 25.0 8. COMCAST-IP-SERVICES-LLC.TenGigabitEthernet4-4.ar4.NYC1.gblx.net 0.3% 675 2.8 8.0 2.2 1131. 70.6 64.211.195.226 COMCAST-IP-SERVICES-LLC.tengigabitethernet1-4.ar5.NYC1.gblx.net 9. pos-2-10-0-0-cr01.chicago.il.ibone.comcast.net 0.4% 675 33.2 37.3 33.0 1130. 62.7 te3-7.cr0.gl.cph.ngdc.net 10. pos-1-14-0-0-cr01.denver.co.ibone.comcast.net 0.4% 675 60.4 64.7 60.0 1132. 63.5 te4-3.alb2nxc7.dk.ip.tdc.net 11. pos-0-11-0-0-cr01.sanjose.ca.ibone.comcast.net 0.4% 675 94.0 99.4 93.4 1117. 70.9 pe01.111eighthave.ny.ibone.comcast.net 12. pos-0-13-0-0-ar01.sfsutro.ca.sfba.comcast.net 0.4% 675 95.4 100.9 94.7 1118. 71.4 pos-1-8-0-0-cr01.newyork.ny.ibone.comcast.net 13. te-9-4-ur03.pinole.ca.sfba.comcast.net 0.3% 675 99.1 105.8 98.8 1162. 74.5 pos-2-10-0-0-cr01.chicago.il.ibone.comcast.net 14. pos-1-14-0-0-cr01.denver.co.ibone.comcast.net 99.3% 675 1178. 951.8 415.0 1178. 315.1 15. pos-0-11-0-0-cr01.sanjose.ca.ibone.comcast.net 99.3% 675 1213. 1009. 551.0 1213. 272.0 16. pos-0-13-0-0-ar01.sfsutro.ca.sfba.comcast.net 99.1% 675 1217. 889.0 184.7 1217. 408.1 17. te-9-4-ur03.pinole.ca.sfba.comcast.net 99.1% 675 1221. 907.0 202.2 1221. 398.2 18. ??? -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden & Risk - Video | Article From richard.barnes at gmail.com Fri Jan 22 11:52:21 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 22 Jan 2010 12:52:21 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <30C06702-F4FF-4128-8792-3A9D480085DF@icann.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <30C06702-F4FF-4128-8792-3A9D480085DF@icann.org> Message-ID: <88ac5c711001220952w350d2175s9eb484390003b7a1@mail.gmail.com> Would it make sense for the RIRs to just carve out the bad parts of the blocks, instead of IANA? Under current policy, would reserving "bad" bits make it more difficult for an RIR to get additional allocations? --Richard On Fri, Jan 22, 2010 at 11:56 AM, Leo Vegoda wrote: > On 22 Jan 2010, at 8:32, Brian Dickson wrote: > > [...] > >> The granularity of allocations is arbitrary, and when scraping the bottom of the barrel, >> where there are known problems, it may time to get more granular. >> >> There's really no difference in managing a handful of /N's rather than /8's, if N is not >> that much bigger than 8. > > You need to change the global policy to do that. ICANN staff cannot allocate anything more specific than a /8 right now because the policy requires IPv4 allocations to the RIRs be in /8 units. > > http://www.icann.org/en/general/allocation-IPv4-rirs.html > > Regards, > > Leo > From eriks at nationalfastfreight.com Fri Jan 22 12:09:01 2010 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Fri, 22 Jan 2010 13:09:01 -0500 Subject: Computer room construction Message-ID: <0B224A2FE01CC54C860290D42474BF6004112804@exchange.nff.local> Anybody know a contractor that could quote on building out a quality server room in a facility in the Toronto area? Our executive want to know what it would cost to build a room for our expansion as opposed to putting the hardware into a co-lo facility. Off-line response would be fine. Thanks, Erik From bicknell at ufp.org Fri Jan 22 12:27:25 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Jan 2010 10:27:25 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> Message-ID: <20100122182725.GB64998@ussenterprise.ufp.org> In a message written on Fri, Jan 22, 2010 at 12:32:30PM -0400, Brian Dickson wrote: > So, if the tainted *portions* of problem /8's are set aside, you end up with sets of varying > sizes of /N. E.g. if there is one /24 that is a problem, you set that aside, and end up with > a set that consists of one each of /9 through /24. Even if you set aside a /16, you get a set > which is /9, /10, /11, /12, /13, /14, /15, and /16. If the tainted portions were going to be set aside, it makes much more sense to me that they be set aside at the RIR level and simply not be counted against the RIR when they go back to IANA for more. It makes the bookkeeping much simpler. When you go to IANA's web site 1/8 went to an RIR. You can look there to find the few /24's that couldn't be given out. The alternative is to blow up the IANA allocation list by several orders of magnitude, for no good reason. Really though, we need the squatters to feel pain. They are the ones in the wrong. Unfortunately who ever receives the allocations will also feel pain. -- 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: 826 bytes Desc: not available URL: From drc at virtualized.org Fri Jan 22 12:31:55 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Jan 2010 10:31:55 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <88ac5c711001220952w350d2175s9eb484390003b7a1@mail.gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <30C06702-F4FF-4128-8792-3A9D480085DF@icann.org> <88ac5c711001220952w350d2175s9eb484390003b7a1@mail.gmail.com> Message-ID: <884F2FD9-5762-462B-B8C5-98F02E4F7350@virtualized.org> On Jan 22, 2010, at 9:52 AM, Richard Barnes wrote: > Would it make sense for the RIRs to just carve out the bad parts of > the blocks, instead of IANA? Under current policy, would reserving > "bad" bits make it more difficult for an RIR to get additional > allocations? Under existing policies, there is no way for IANA to carve out pieces of address blocks. The /8s with pieces carved out of them by the IETF are/will be allocated to RIRs with an understanding that the RIRs aren't supposed to allocate the IETF-designated reserved chunks (which, presumably, they won't). Regards, -drc From cscora at apnic.net Fri Jan 22 12:50:19 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Jan 2010 04:50:19 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201001221850.o0MIoJVn021963@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 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 309323 Prefixes after maximum aggregation: 143748 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 152029 Total ASes present in the Internet Routing Table: 33159 Prefixes per ASN: 9.33 Origin-only ASes present in the Internet Routing Table: 28791 Origin ASes announcing only one prefix: 14048 Transit ASes present in the Internet Routing Table: 4368 Transit-only ASes present in the Internet Routing Table: 106 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 9503) 21 Prefixes from unregistered ASNs in the Routing Table: 764 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 406 Prefixes from 32-bit ASNs in the Routing Table: 351 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 186 Number of addresses announced to Internet: 2178191808 Equivalent to 129 /8s, 212 /16s and 145 /24s Percentage of available address space announced: 58.8 Percentage of allocated address space announced: 65.9 Percentage of available address space allocated: 89.1 Percentage of address space in use by end-sites: 80.8 Total number of prefixes smaller than registry allocations: 149077 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 74725 Total APNIC prefixes after maximum aggregation: 25834 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 71407 Unique aggregates announced from the APNIC address blocks: 31479 APNIC Region origin ASes present in the Internet Routing Table: 3922 APNIC Prefixes per ASN: 18.21 APNIC Region origin ASes announcing only one prefix: 1070 APNIC Region transit ASes present in the Internet Routing Table: 619 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 489484832 Equivalent to 29 /8s, 44 /16s and 242 /24s Percentage of available APNIC address space announced: 76.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/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, 133/8, 175/8, 180/8, 182/8, 183/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: 129460 Total ARIN prefixes after maximum aggregation: 67652 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103566 Unique aggregates announced from the ARIN address blocks: 39277 ARIN Region origin ASes present in the Internet Routing Table: 13475 ARIN Prefixes per ASN: 7.69 ARIN Region origin ASes announcing only one prefix: 5213 ARIN Region transit ASes present in the Internet Routing Table: 1336 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 735487520 Equivalent to 43 /8s, 214 /16s and 166 /24s Percentage of available ARIN address space announced: 64.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 71135 Total RIPE prefixes after maximum aggregation: 41584 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 64228 Unique aggregates announced from the RIPE address blocks: 42817 RIPE Region origin ASes present in the Internet Routing Table: 14007 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7277 RIPE Region transit ASes present in the Internet Routing Table: 2094 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 414369024 Equivalent to 24 /8s, 178 /16s and 197 /24s Percentage of available RIPE address space announced: 77.2 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27183 Total LACNIC prefixes after maximum aggregation: 6541 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 25544 Unique aggregates announced from the LACNIC address blocks: 13806 LACNIC Region origin ASes present in the Internet Routing Table: 1232 LACNIC Prefixes per ASN: 20.73 LACNIC Region origin ASes announcing only one prefix: 396 LACNIC Region transit ASes present in the Internet Routing Table: 202 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 20 Number of LACNIC addresses announced to Internet: 70307584 Equivalent to 4 /8s, 48 /16s and 207 /24s Percentage of available LACNIC address space announced: 69.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 6246 Total AfriNIC prefixes after maximum aggregation: 1788 AfriNIC Deaggregation factor: 3.49 Prefixes being announced from the AfriNIC address blocks: 4629 Unique aggregates announced from the AfriNIC address blocks: 1565 AfriNIC Region origin ASes present in the Internet Routing Table: 337 AfriNIC Prefixes per ASN: 13.74 AfriNIC Region origin ASes announcing only one prefix: 92 AfriNIC Region transit ASes present in the Internet Routing Table: 75 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 14803712 Equivalent to 0 /8s, 225 /16s and 227 /24s Percentage of available AfriNIC address space announced: 44.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1857 7510 470 Korea Telecom (KIX) 4755 1310 303 137 TATA Communications formerly 17488 1273 131 140 Hathway IP Over Cable Interne 18101 1079 220 37 Reliance Infocom Ltd Internet 4134 1020 19605 398 CHINANET-BACKBONE 9583 986 72 491 Sify Limited 7545 931 198 98 TPG Internet Pty Ltd 17974 880 272 54 PT TELEKOMUNIKASI INDONESIA 9829 839 683 24 BSNL National Internet Backbo 24560 837 299 172 Bharti Airtel Ltd., Telemedia 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 4149 3875 316 bellsouth.net, inc. 4323 3783 1088 395 Time Warner Telecom 1785 1817 699 132 PaeTec Communications, Inc. 7018 1593 5778 1029 AT&T WorldNet Services 20115 1542 1490 671 Charter Communications 2386 1292 616 917 AT&T Data Communications Serv 3356 1203 10929 425 Level 3 Communications, LLC 11492 1128 222 14 Cable One 22773 1125 2600 66 Cox Communications, Inc. 6478 1103 241 262 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 35805 475 40 5 United Telecom of Georgia 3292 451 1904 395 TDC Tele Danmark 30890 439 99 205 Evolva Telecom 702 422 1821 336 UUNET - Commercial IP service 8551 397 353 37 Bezeq International 8866 374 110 24 Bulgarian Telecommunication C 3320 361 7068 308 Deutsche Telekom AG 3215 351 3176 108 France Telecom Transpac 3301 349 1412 310 TeliaNet Sweden 12479 320 576 5 Uni2 Autonomous System 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 1573 2886 240 UniNet S.A. de C.V. 10620 1007 225 131 TVCABLE BOGOTA 28573 840 674 85 NET Servicos de Comunicao S.A 7303 671 356 100 Telecom Argentina Stet-France 22047 548 302 14 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 6503 446 163 185 AVANTEL, S.A. 11172 444 99 69 Servicios Alestra S.A de C.V 14117 438 29 12 Telefonica del Sur S.A. 3816 432 194 70 Empresa Nacional de Telecomun 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 8452 1017 445 9 TEDATA 24863 723 143 53 LINKdotNET AS number 36992 282 75 172 Etisalat MISR 3741 274 857 234 The Internet Solution 2018 190 197 111 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 167 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 117 7 17 Internet Egypt Network 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 4149 3875 316 bellsouth.net, inc. 4323 3783 1088 395 Time Warner Telecom 4766 1857 7510 470 Korea Telecom (KIX) 1785 1817 699 132 PaeTec Communications, Inc. 7018 1593 5778 1029 AT&T WorldNet Services 8151 1573 2886 240 UniNet S.A. de C.V. 20115 1542 1490 671 Charter Communications 4755 1310 303 137 TATA Communications formerly 2386 1292 616 917 AT&T Data Communications Serv 17488 1273 131 140 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 4323 3783 3388 Time Warner Telecom 1785 1817 1685 PaeTec Communications, Inc. 4766 1857 1387 Korea Telecom (KIX) 8151 1573 1333 UniNet S.A. de C.V. 4755 1310 1173 TATA Communications formerly 17488 1273 1133 Hathway IP Over Cable Interne 11492 1128 1114 Cable One 22773 1125 1059 Cox Communications, Inc. 18566 1059 1049 Covad Communications 18101 1079 1042 Reliance Infocom Ltd Internet 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 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 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:21 /9:10 /10:25 /11:66 /12:183 /13:385 /14:660 /15:1243 /16:10875 /17:5102 /18:8646 /19:17799 /20:21717 /21:21723 /22:28019 /23:28196 /24:161741 /25:928 /26:1160 /27:585 /28:215 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2707 4149 bellsouth.net, inc. 4323 2359 3783 Time Warner Telecom 4766 1475 1857 Korea Telecom (KIX) 1785 1285 1817 PaeTec Communications, Inc. 17488 1049 1273 Hathway IP Over Cable Interne 11492 1048 1128 Cable One 18566 1040 1059 Covad Communications 7018 960 1593 AT&T WorldNet Services 18101 958 1079 Reliance Infocom Ltd Internet 8452 913 1017 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:234 12:2012 13:10 15:22 16:3 17:8 20:37 24:1301 32:49 38:642 40:99 41:1910 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:632 59:637 60:390 61:1100 62:977 63:2027 64:3796 65:2360 66:4102 67:1813 68:1052 69:2842 70:690 71:227 72:1874 73:2 74:2073 75:232 76:354 77:827 78:580 79:408 80:968 81:787 82:450 83:438 84:561 85:1003 86:383 87:706 88:418 89:1537 90:67 91:2686 92:413 93:1153 94:1287 95:794 96:208 97:294 98:493 99:23 100:1 109:235 110:265 111:418 112:184 113:225 114:309 115:513 116:1042 117:609 118:373 119:809 120:142 121:839 122:1376 123:834 124:1076 125:1298 128:198 129:203 130:138 131:461 132:82 133:16 134:195 135:41 136:222 137:172 138:235 139:80 140:464 141:123 142:375 143:348 144:391 145:51 146:417 147:179 148:566 149:195 150:146 151:171 152:248 153:165 154:2 155:271 156:178 157:330 158:97 159:355 160:304 161:176 162:272 163:187 164:311 165:470 166:493 167:388 168:759 169:157 170:568 171:48 172:2 173:444 174:530 175:26 180:284 183:212 184:3 186:261 187:211 188:1263 189:613 190:3444 192:5727 193:4410 194:3354 195:2778 196:1187 198:3559 199:3385 200:5295 201:1467 202:8087 203:8315 204:3996 205:2167 206:2420 207:3062 208:3898 209:3407 210:2531 211:1177 212:1648 213:1643 214:256 215:61 216:4441 217:1471 218:495 219:444 220:1129 221:465 222:309 End of report From nick at foobar.org Fri Jan 22 13:09:00 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 22 Jan 2010 19:09:00 +0000 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> Message-ID: <4B59F7CC.2000200@foobar.org> On 22/01/2010 16:32, Brian Dickson wrote: > So, if the tainted *portions* of problem /8's are set aside What portion of 1/8 is untainted? Or any other /8 that the IANA has identified as having problems? How do you measure it? How do you ensure that other /8s which don't _appear_ to have problems really don't have problems due to invisible use? And if you set aside say, the bits that WIANA or some other organisation has delegated to its stakeholders, are you implicitly acknowledging that they are a legitimate ICANN accredited RIR? Or if some large corporation starts reselling CPE gear which uses IANA-unallocated space on one of their popular devices, does their prior use get them some form of "rights" over that address space? IANA only guarantees that no other RIR has been allocated these /8s according to its registry, and it does not guarantee routability or reachability on the public internet (however much the individuals within IANA / ICANN care about this). If some other organisation has decided to use address space which overlaps with IANA's public registry, then they've created a serious problem for themselves and their customers / stakeholders which could have been avoided in the first place. IPv4 address space is handed out on the basis of need, and there was really no reason for these organisations to squat unallocated space in the first place. IANA hands out /8s. We know that some of these are going to cause serious problems, but life sucks and we just have to deal with what happens. Personally, I feel very sorry for APNIC that they've been allocated 1/8, but that's just the way the cookie crumbles. The RIRs agreed a process with IANA and knew what the consequences of that process were. They also appear to have agreed that it was better to use 1/8 than not use it. Their end-users are going to be incensed at the level of problems which this is going to cause. I can only hope that there won't be inter-governmental bun-fights over it. Nick From bicknell at ufp.org Fri Jan 22 13:36:31 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Jan 2010 11:36:31 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59F7CC.2000200@foobar.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> Message-ID: <20100122193630.GA71912@ussenterprise.ufp.org> In a message written on Fri, Jan 22, 2010 at 07:09:00PM +0000, Nick Hilliard wrote: > What portion of 1/8 is untainted? Or any other /8 that the IANA has > identified as having problems? How do you measure it? How do you ensure I, personally, am quite skeptical that any of the /8's are tainted to the point where they are unusable. However, as an example of something I would say rises to the level of tainted. Remember a few years back Netgear hard coded the IP's of the UW time servers, and then shipped a few million boxes, which on by the way had a bug so they asked for time too often? http://pages.cs.wisc.edu/~plonka/netgear-sntp/ The result was a 40,000 packet per second flood. If an RIR was to give out a block with that sort of taint (e.g. UW returned that block, or something out there defaults to contacting 1/8 in a similar manor) then I think it's reasonable for the RIR to mark it as tainted, work with the people to get it fixed, and give folks other address space. Hopefully the RIR could work with the party involved and eventually return the space to service. > IANA hands out /8s. We know that some of these are going to cause serious > problems, but life sucks and we just have to deal with what happens. Pretty much. -- 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: 826 bytes Desc: not available URL: From matthew at eeph.com Fri Jan 22 13:47:09 2010 From: matthew at eeph.com (Matthew Kaufman) Date: Fri, 22 Jan 2010 11:47:09 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <20100122193630.GA71912@ussenterprise.ufp.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> <20100122193630.GA71912@ussenterprise.ufp.org> Message-ID: <4B5A00BD.2080907@eeph.com> From the traffic generated by all the port-scanning and other similarly-useless packets, one could argue that all of unicast v4 space is tainted at this point.* Maybe we should be using that as a reason to switch to v6. Matthew Kaufman *If you don't believe me, point a /16 or larger down a fractional T1 line and try to get useful work done over the remaining bandwidth. From Brian.Dickson at concertia.com Fri Jan 22 13:49:58 2010 From: Brian.Dickson at concertia.com (Brian Dickson) Date: Fri, 22 Jan 2010 15:49:58 -0400 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <4B59F7CC.2000200@foobar.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> Message-ID: <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> I think it would certainly be useful, both diagnostically and operationally, for IANA and the RIR's to *actually announce* the unused space, and run either or both of tar-pits and honey-pots on those, for just such a reason - to gauge problems that might exist on "unused" space, *before* the space is assigned. And, it'd be nice if there were a check-box for "I volunteer for the pain". In the movies, where something bad can happen and they draw straws, it is almost always drawing straws from among volunteers. There are certainly reasons for wanting to identify and not assign space that has "issues", to certain recipients or when certain conditions exist. E.g.: critical infrastructure /24's; initial assignments (where the recipient doesn't gave another block into which to internally interchange addresses); less technically adept recipients (e.g. in the developing nations, where adding "pain" would really be unusually cruel.) Brian -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: January-22-10 3:09 PM To: Brian Dickson Cc: William Allen Simpson; nanog at nanog.org Subject: Re: 1/8 and 27/8 allocated to APNIC On 22/01/2010 16:32, Brian Dickson wrote: > So, if the tainted *portions* of problem /8's are set aside What portion of 1/8 is untainted? Or any other /8 that the IANA has identified as having problems? How do you measure it? How do you ensure that other /8s which don't _appear_ to have problems really don't have problems due to invisible use? IANA hands out /8s. We know that some of these are going to cause serious problems, but life sucks and we just have to deal with what happens. From jabley at hopcount.ca Fri Jan 22 13:52:44 2010 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 22 Jan 2010 14:52:44 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> Message-ID: <0DB5F463-119A-4B6D-A59A-87372A8C8DAD@hopcount.ca> On 2010-01-22, at 14:49, Brian Dickson wrote: > I think it would certainly be useful, both diagnostically and operationally, > for IANA and the RIR's to *actually announce* the unused space, and run either or > both of tar-pits and honey-pots on those, for just such a reason - to gauge problems > that might exist on "unused" space, *before* the space is assigned. I believe the RIRs have already been doing this with each /8 they've received from the IANA for quite some time. Joe From leo.vegoda at icann.org Fri Jan 22 14:06:07 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 22 Jan 2010 12:06:07 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <0DB5F463-119A-4B6D-A59A-87372A8C8DAD@hopcount.ca> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> <0DB5F463-119A-4B6D-A59A-87372A8C8DAD@hopcount.ca> Message-ID: <57CB45EE-EEDF-4B68-88A4-9763C66A3C55@icann.org> On 22 Jan 2010, at 11:52, Joe Abley wrote: >> >> I think it would certainly be useful, both diagnostically and operationally, >> for IANA and the RIR's to *actually announce* the unused space, and run either or >> both of tar-pits and honey-pots on those, for just such a reason - to gauge problems >> that might exist on "unused" space, *before* the space is assigned. > > I believe the RIRs have already been doing this with each /8 they've received from the IANA for quite some time. And indeed the latest APNIC stats file shows that they have made assignments from their new /8s, presumably for this purpose: apnic AP ipv4 1.0.0.0 256 20100122 assigned apnic AP ipv4 1.1.1.0 256 20100122 assigned apnic AP ipv4 1.2.3.0 256 20100122 assigned apnic AP ipv4 1.50.0.0 1024 20100122 allocated apnic AP ipv4 1.255.0.0 65536 20100122 allocated apnic AP ipv4 27.0.0.0 256 20100122 assigned apnic AP ipv4 27.50.0.0 1024 20100122 allocated apnic AP ipv4 27.255.0.0 65536 20100122 allocated Regards, Leo From scott at doc.net.au Fri Jan 22 14:27:59 2010 From: scott at doc.net.au (Scott Howard) Date: Fri, 22 Jan 2010 12:27:59 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> Message-ID: On Fri, Jan 22, 2010 at 11:49 AM, Brian Dickson wrote: > I think it would certainly be useful, both diagnostically and operationally, > for IANA and the RIR's to *actually announce* the unused space, and run either or > both of tar-pits and honey-pots on those, for just such a reason - to gauge problems > that might exist on "unused" space, *before* the space is assigned. $ whois -h whois.apnic.net 1.1.1.1 % [whois.apnic.net node-1] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html inetnum: 1.1.1.0 - 1.1.1.255 netname: Debogon-prefix descr: APNIC Debogon Project descr: APNIC Pty Ltd country: AU admin-c: AP16-AP tech-c: AP16-AP mnt-by: APNIC-HM mnt-routes: MAINT-APNIC-DEBOGON (Similar things exist for 1.1.2.0/24 and several others) I'm not seeing them announced yet, but it's only a matter of time. Scott. From mpetach at netflight.com Fri Jan 22 15:19:28 2010 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 22 Jan 2010 13:19:28 -0800 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> <4B59F7CC.2000200@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C30F@concertiabl02.concertia.com> Message-ID: <63ac96a51001221319p39a9d036m126e5e1e7f01e825@mail.gmail.com> On Fri, Jan 22, 2010 at 11:49 AM, Brian Dickson wrote: > I think it would certainly be useful, both diagnostically and operationally, > for IANA and the RIR's to *actually announce* the unused space, and run either or > both of tar-pits and honey-pots on those, for just such a reason - to gauge problems > that might exist on "unused" space, *before* the space is assigned. > > And, it'd be nice if there were a check-box for "I volunteer for the pain". > In the movies, where something bad can happen and they draw straws, it is almost > always drawing straws from among volunteers. *heh* And there's always going to be a set of normally-outbound-heavy networks that would *love* to get more inbound traffic by hosting honeypots for tainted networks...so there's one set of hands ready and waiting to shoot up the minute you need volunteers for your tar-pits and honey-pots. Matt From cidr-report at potaroo.net Fri Jan 22 16:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Jan 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201001222200.o0MM03BP080050@wattle.apnic.net> BGP Update Report Interval: 14-Jan-10 -to- 21-Jan-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 31498 1.8% 30.7 -- TEDATA TEDATA 2 - AS7643 20956 1.2% 22.6 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 3 - AS2686 18448 1.1% 160.4 -- AT&T Global Network Services - EMEA 4 - AS9829 15740 0.9% 18.8 -- BSNL-NIB National Internet Backbone 5 - AS4323 13846 0.8% 3.1 -- TWTC - tw telecom holdings, inc. 6 - AS7738 12597 0.7% 29.2 -- Telecomunicacoes da Bahia S.A. 7 - AS1790 12342 0.7% 99.5 -- Sprint US 8 - AS37986 12219 0.7% 140.4 -- TULIP Tulip Telecom Ltd. 9 - AS5800 11189 0.6% 50.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 10 - AS9430 10187 0.6% 328.6 -- STPI-NOIDA Software Technology Parks of India,Block-IV 11 - AS4270 9177 0.5% 1835.4 -- Red de Interconexion Universitaria 12 - AS6389 9023 0.5% 2.2 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 13 - AS5668 8813 0.5% 11.1 -- AS-5668 - CenturyTel Internet Holdings, Inc. 14 - AS151 8798 0.5% 549.9 -- IND-NTC-AS - Hewlett-Packard Company 15 - AS14522 7857 0.5% 22.6 -- Satnet 16 - AS23577 7456 0.4% 12.5 -- ATM-MPLS-AS-KR Korea Telecom 17 - AS5803 7384 0.4% 78.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS1785 7183 0.4% 3.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS3255 7136 0.4% 44.9 -- UARNET-AS Ukrainian Academic and Research Network 20 - AS17488 7132 0.4% 4.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS20066 2426 0.1% 2426.0 -- MORRISTECH - Morris Technologies, Inc. 2 - AS48754 2323 0.1% 2323.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS4270 9177 0.5% 1835.4 -- Red de Interconexion Universitaria 4 - AS45408 3300 0.2% 1650.0 -- 5 - AS37020 996 0.1% 996.0 -- CELTEL-DRC 6 - AS22570 550 0.0% 550.0 -- AUTODESK-1 Autodesk, Inc. 7 - AS151 8798 0.5% 549.9 -- IND-NTC-AS - Hewlett-Packard Company 8 - AS43818 546 0.0% 546.0 -- MELLAT-AS bankmellat 9 - AS48309 388 0.0% 388.0 -- AGS-AS Ariana Gostar Spadana Autonomous Number 10 - AS15179 3433 0.2% 381.4 -- RNT-HOSTING-1 - RightNow Technologies, Inc. 11 - AS47262 726 0.0% 363.0 -- HAMARA-AS Hamara System Tabriz Engineering Company 12 - AS48944 687 0.0% 343.5 -- ASKHALIJFARSONLINE Khalij Ettela Resan Jonoub LTD 13 - AS43197 332 0.0% 332.0 -- TT-MOBILE-AS JSC TT Mobile 14 - AS9430 10187 0.6% 328.6 -- STPI-NOIDA Software Technology Parks of India,Block-IV 15 - AS36988 654 0.0% 327.0 -- MILLICOM-SL 16 - AS31303 323 0.0% 323.0 -- NIOC-AS NIOC Network, Iran 17 - AS48359 967 0.1% 322.3 -- HESABGAR-AS Hesabgar Pardaz Gharb Co. Private J.S. 18 - AS49697 318 0.0% 318.0 -- SHABAKIEH-AS Shabakieh Isfahan Co. 19 - AS47806 630 0.0% 315.0 -- TEL4TEL-AS Pishgaman Rayaneh Zaman Co. Ltd. 20 - AS41152 628 0.0% 314.0 -- AFTAB Aftab Internet Service Provider TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 170.210.56.0/22 9155 0.5% AS4270 -- Red de Interconexion Universitaria 2 - 203.162.118.128/ 4921 0.3% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 3 - 110.234.206.0/23 4001 0.2% AS37986 -- TULIP Tulip Telecom Ltd. 4 - 110.234.208.0/23 4001 0.2% AS37986 -- TULIP Tulip Telecom Ltd. 5 - 110.234.204.0/23 4001 0.2% AS37986 -- TULIP Tulip Telecom Ltd. 6 - 74.117.203.0/24 3400 0.2% AS15179 -- RNT-HOSTING-1 - RightNow Technologies, Inc. 7 - 222.255.186.0/25 3125 0.2% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 8 - 16.139.64.0/24 2923 0.2% AS151 -- IND-NTC-AS - Hewlett-Packard Company 9 - 15.219.192.0/20 2915 0.2% AS151 -- IND-NTC-AS - Hewlett-Packard Company 10 - 15.154.208.0/20 2915 0.2% AS151 -- IND-NTC-AS - Hewlett-Packard Company 13 - 192.12.120.0/24 2559 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 14 - 174.47.118.0/24 2426 0.1% AS20066 -- MORRISTECH - Morris Technologies, Inc. 15 - 69.34.220.0/22 2399 0.1% AS1790 -- Sprint US 16 - 69.69.228.0/22 2399 0.1% AS1790 -- Sprint US 17 - 67.77.98.0/23 2399 0.1% AS1790 -- Sprint US 18 - 69.34.252.0/23 2399 0.1% AS1790 -- Sprint US 19 - 204.214.88.0/24 2387 0.1% AS1790 -- Sprint US 20 - 91.212.23.0/24 2323 0.1% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 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 Jan 22 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Jan 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201001222200.o0MM00fx080042@wattle.apnic.net> This report has been generated at Fri Jan 22 21:11:28 2010 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-01-10 314098 192139 16-01-10 314591 192352 17-01-10 314553 192190 18-01-10 314561 191509 19-01-10 314356 191890 20-01-10 314595 192239 21-01-10 314760 190487 22-01-10 311605 190808 AS Summary 33400 Number of ASes in routing system 14227 Number of ASes announcing only one prefix 4377 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93176320 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 22Jan10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 311872 190816 121056 38.8% All ASes AS6389 4147 322 3825 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4377 1701 2676 61.1% TWTC - tw telecom holdings, inc. AS4766 1857 484 1373 73.9% KIXS-AS-KR Korea Telecom AS1785 1817 661 1156 63.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1125 71 1054 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1273 282 991 77.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1059 149 910 85.9% COVAD - Covad Communications Co. AS4755 1310 412 898 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1572 677 895 56.9% Uninet S.A. de C.V. AS10620 1006 181 825 82.0% TV Cable S.A. AS19262 1056 240 816 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 1079 284 795 73.7% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS8452 1017 304 713 70.1% TEDATA TEDATA AS17908 763 58 705 92.4% TCISL Tata Communications AS6478 1104 440 664 60.1% ATT-INTERNET3 - AT&T WorldNet Services AS4808 836 225 611 73.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1593 1030 563 35.3% ATT-INTERNET4 - AT&T WorldNet Services AS4804 634 71 563 88.8% MPX-AS Microplex PTY LTD AS7303 672 109 563 83.8% Telecom Argentina S.A. AS3356 1205 647 558 46.3% LEVEL3 Level 3 Communications AS24560 836 294 542 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4134 1020 488 532 52.2% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 950 438 512 53.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 548 65 483 88.1% VTR BANDA ANCHA S.A. AS855 609 132 477 78.3% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS11492 1128 651 477 42.3% CABLEONE - CABLE ONE, INC. AS9808 483 17 466 96.5% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS9443 540 80 460 85.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS5668 786 330 456 58.0% AS-5668 - CenturyTel Internet Holdings, Inc. AS9299 665 211 454 68.3% IPG-AS-AP Philippine Long Distance Telephone Company Total 37067 11054 26013 70.2% Top 30 total Possible Bogus Routes 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/24 AS36992 ETISALAT-MISR 109.235.24.0/21 AS43761 SVSERV-AS SvyazService Ltd 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet 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.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.113.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.114.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.125.115.0/24 AS9541 CYBERNET-AP Cyber Internet Services (Pvt) Ltd. 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/23 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.192.0/20 AS14697 VDOTNET - VDot.Net 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.243.240.0/20 AS12182 INTERNAP-2BLK - Internap Network Services Corporation 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 mpetach at netflight.com Fri Jan 22 16:14:51 2010 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 22 Jan 2010 14:14:51 -0800 Subject: UC phone system for Haiti (was Katrina Response) In-Reply-To: <726037536-1264128820-cardhu_decombobulator_blackberry.rim.net-1740310496-@bda123.bisx.prod.on.blackberry> References: <726037536-1264128820-cardhu_decombobulator_blackberry.rim.net-1740310496-@bda123.bisx.prod.on.blackberry> Message-ID: <63ac96a51001221414v4cbfbe4fp43526d8e56d00a8e@mail.gmail.com> On Thu, Jan 21, 2010 at 6:53 PM, wrote: > We had a major turnout this past weekend here in southern cal. > > Shout out to the uc system and people. Yahoo is hosting a Crisis Camp to help support the Haiti relief efforts here in silicon valley tomorrow: http://crisiscamphaitisiliconvalley.eventbrite.com/ If you have some spare time, please consider bringing your laptop and coming over to help with supporting relief efforts in Haiti. Thanks! Matt (and for those not in sunnyvale, there's similar efforts going on in other cities around the globe:) http://www.colombiassh.org/site/ CrisisCamp Haiti, Bogota, Colombia http://www.eventbrite.com/event/541831633 CrisisCamp Haiti, Boston http://crisiscampboulderdenver.eventbrite.com/ CrisisCamp Haiti, Boulder/Denver http://crisiscamphaitila2.eventbrite.com/ CrisisCamp Haiti, Los Angeles http://crisiscampmiami.eventbrite.com/ CrisisCamp Haiti, Miami http://crisiscampmontreal.wordpress.com/about/ CrisisCamp Haiti, Montreal http://crisiscampnola.eventbrite.com/ CrisisCamp Haiti, New Orleans http://www.eventbrite.com/event/543649069 CrisisCamp Haiti, New York http://crisiscamphaitipdx.eventbrite.com/ CrisisCamp Haiti, Portland http://www.eventbrite.com/event/542966026/?ref=esdg CrisisCamp Haiti, Seattle http://crisiscamphaitiwdc.eventbrite.com/ CrisisCamp Haiti, Washington, DC From randy at psg.com Fri Jan 22 16:35:50 2010 From: randy at psg.com (Randy Bush) Date: Sat, 23 Jan 2010 07:35:50 +0900 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <4B59CFA8.9000308@foobar.org> <21D41A38B8859B4A97B1AE2313922B8A821FC1C2F8@concertiabl02.concertia.com> Message-ID: > As of two days ago, there were quantifiable problems associated with > 13 out of the 26 remaining /8s. i love quantification! please send detail. otherwise, this thread seems a bit content-free and pontification heavy to me randy From sethm at rollernet.us Fri Jan 22 18:08:28 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 22 Jan 2010 16:08:28 -0800 Subject: Using /31 for router links Message-ID: <4B5A3DFC.4090305@rollernet.us> In the past I've always used /30's for PTP connection subnets out of old habit (i.e. Ethernet that won't take unnumbered) but now I'm considering switching to /31's in order to stretch my IPv4 space further. Has anyone else does this? Good? Bad? Based on the bit of testing I've done this shouldn't be a problem since it's only between routers. ~Seth From jjn at nuge.com Fri Jan 22 18:31:30 2010 From: jjn at nuge.com (Jay Nugent) Date: Fri, 22 Jan 2010 19:31:30 -0500 (EST) Subject: Using /31 for router links In-Reply-To: <4B5A3DFC.4090305@rollernet.us> Message-ID: Greetings, On Fri, 22 Jan 2010, Seth Mattinen wrote: > In the past I've always used /30's for PTP connection subnets out of old > habit (i.e. Ethernet that won't take unnumbered) but now I'm considering > switching to /31's in order to stretch my IPv4 space further. Has anyone > else does this? Good? Bad? Based on the bit of testing I've done this > shouldn't be a problem since it's only between routers. Yes, this *IS* done *ALL* the time. P-t-P means that there are ONLY two devices on the wire - hence point to point. It ONLY uses two IP addresses (one on each end) and there is no reason or need to ARP on this wire. So no need for a broadcast or network addresses - it is just the two end points. --- Jay Nugent Nugent Telecommunications Train how you will Operate, and you will Operate how you were Trained. +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 7:01pm up 43 days, 18:42, 3 users, load average: 1.10, 0.96, 0.63 From nanog-post at rsuc.gweep.net Fri Jan 22 18:41:24 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 22 Jan 2010 19:41:24 -0500 Subject: Using /31 for router links In-Reply-To: <4B5A3DFC.4090305@rollernet.us> References: <4B5A3DFC.4090305@rollernet.us> Message-ID: <20100123004123.GA64506@gweep.net> On Fri, Jan 22, 2010 at 04:08:28PM -0800, Seth Mattinen wrote: > In the past I've always used /30's for PTP connection subnets out of old > habit (i.e. Ethernet that won't take unnumbered) but now I'm considering > switching to /31's in order to stretch my IPv4 space further. Has anyone > else does this? Good? Bad? Based on the bit of testing I've done this > shouldn't be a problem since it's only between routers. rfc3021 is over 9 years old, so should be no suprise that it works well. :-) -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From sethm at rollernet.us Fri Jan 22 18:53:25 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 22 Jan 2010 16:53:25 -0800 Subject: Using /31 for router links In-Reply-To: <20100123004123.GA64506@gweep.net> References: <4B5A3DFC.4090305@rollernet.us> <20100123004123.GA64506@gweep.net> Message-ID: <4B5A4885.6030901@rollernet.us> Joe Provo wrote: > On Fri, Jan 22, 2010 at 04:08:28PM -0800, Seth Mattinen wrote: >> In the past I've always used /30's for PTP connection subnets out of old >> habit (i.e. Ethernet that won't take unnumbered) but now I'm considering >> switching to /31's in order to stretch my IPv4 space further. Has anyone >> else does this? Good? Bad? Based on the bit of testing I've done this >> shouldn't be a problem since it's only between routers. > > rfc3021 is over 9 years old, so should be no suprise that it works > well. :-) > I'm never surprised anymore by something that should work turning out to have some obscure quirk about it, so I figured it was worth asking. ;) ~Seth From ccosta at cenic.org Fri Jan 22 19:00:22 2010 From: ccosta at cenic.org (Chris Costa) Date: Fri, 22 Jan 2010 17:00:22 -0800 Subject: Using /31 for router links In-Reply-To: <4B5A4885.6030901@rollernet.us> References: <4B5A3DFC.4090305@rollernet.us> <20100123004123.GA64506@gweep.net> <4B5A4885.6030901@rollernet.us> Message-ID: <88C6A9EE-897A-4744-A3DA-B54B55D71D3B@cenic.org> We recently did a backbone router upgrade and the vendor surprisingly didn't support /31's. We had to renumber all those interconnects and peering sessions to /30's. That wasn't fun! On Jan 22, 2010, at 4:53 PM, Seth Mattinen wrote: > Joe Provo wrote: >> On Fri, Jan 22, 2010 at 04:08:28PM -0800, Seth Mattinen wrote: >>> In the past I've always used /30's for PTP connection subnets out >>> of old habit (i.e. Ethernet that won't take unnumbered) but now >>> I'm considering switching to /31's in order to stretch my IPv4 >>> space further. Has anyone else does this? Good? Bad? Based on the >>> bit of testing I've done this shouldn't be a problem since it's >>> only between routers. >> rfc3021 is over 9 years old, so should be no suprise that it works >> well. :-) > > > I'm never surprised anymore by something that should work turning > out to have some obscure quirk about it, so I figured it was worth > asking. ;) > > ~Seth > From erik_list at caneris.com Fri Jan 22 19:04:58 2010 From: erik_list at caneris.com (Erik L) Date: Fri, 22 Jan 2010 20:04:58 -0500 Subject: Using /31 for router links In-Reply-To: <4B5A4885.6030901@rollernet.us> References: <4B5A3DFC.4090305@rollernet.us> <20100123004123.GA64506@gweep.net>,<4B5A4885.6030901@rollernet.us> Message-ID: > > rfc3021 is over 9 years old, so should be no suprise that it works > > well. :-) > > > I'm never surprised anymore by something that should work > turning out to > have some obscure quirk about it, so I figured it was worth asking. ;) > It's not a "quirk", it's an "implementation-specific feature" ;) From kris.foster at gmail.com Fri Jan 22 19:15:02 2010 From: kris.foster at gmail.com (kris foster) Date: Fri, 22 Jan 2010 17:15:02 -0800 Subject: Using /31 for router links In-Reply-To: <20100123004123.GA64506@gweep.net> References: <4B5A3DFC.4090305@rollernet.us> <20100123004123.GA64506@gweep.net> Message-ID: <5B94B422-4AC7-422C-9E71-7E7D0E045C95@gmail.com> On Jan 22, 2010, at 4:41 PM, Joe Provo wrote: > On Fri, Jan 22, 2010 at 04:08:28PM -0800, Seth Mattinen wrote: >> In the past I've always used /30's for PTP connection subnets out of old >> habit (i.e. Ethernet that won't take unnumbered) but now I'm considering >> switching to /31's in order to stretch my IPv4 space further. Has anyone >> else does this? Good? Bad? Based on the bit of testing I've done this >> shouldn't be a problem since it's only between routers. > > rfc3021 is over 9 years old, so should be no suprise that it works > well. :-) Works well if supported. Vendor b (nee f) apparently dropped it off their roadmap. -- kris From tvarriale at comcast.net Fri Jan 22 19:23:15 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Fri, 22 Jan 2010 19:23:15 -0600 Subject: Using /31 for router links References: <4B5A3DFC.4090305@rollernet.us> Message-ID: Shouldn't be any issues...it's 2010 :) And, your IP allocation utilization will love you. tv ----- Original Message ----- From: "Seth Mattinen" To: "nanOG list" Sent: Friday, January 22, 2010 6:08 PM Subject: Using /31 for router links > In the past I've always used /30's for PTP connection subnets out of old > habit (i.e. Ethernet that won't take unnumbered) but now I'm considering > switching to /31's in order to stretch my IPv4 space further. Has anyone > else does this? Good? Bad? Based on the bit of testing I've done this > shouldn't be a problem since it's only between routers. > > ~Seth > From ras at e-gerbil.net Fri Jan 22 20:16:15 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 22 Jan 2010 20:16:15 -0600 Subject: Using /31 for router links In-Reply-To: <20100123004123.GA64506@gweep.net> References: <4B5A3DFC.4090305@rollernet.us> <20100123004123.GA64506@gweep.net> Message-ID: <20100123021615.GW75640@gerbil.cluepon.net> On Fri, Jan 22, 2010 at 07:41:24PM -0500, Joe Provo wrote: > rfc3021 is over 9 years old, so should be no suprise that it works > well. :-) Along the same line of logic, it should also be no surprise that Foundry shits all over itself when you so much as learn a /31 via a routing protocol (last I looked at any rate). :) Every other piece of gear seems to handle it fine, though admittedly it breaks my automatic mental calculations of "what is the peer IP" something fierce. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From smb at cs.columbia.edu Fri Jan 22 21:16:03 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 22 Jan 2010 22:16:03 -0500 Subject: Anyone see a game changer here? In-Reply-To: <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> Message-ID: <464D77DC-FEBE-4EB2-ABED-C4D93036EC38@cs.columbia.edu> On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote: > The problem with IE is the same problem as Windows, the basic design > is fundementally insecure and "timely updates" can't fix that. You do realize, of course, that IE is recording less than half the security flaw rate of Firefox? (See http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) --Steve Bellovin, http://www.cs.columbia.edu/~smb From nenolod at systeminplace.net Fri Jan 22 21:37:19 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 22 Jan 2010 21:37:19 -0600 Subject: Anyone see a game changer here? In-Reply-To: <464D77DC-FEBE-4EB2-ABED-C4D93036EC38@cs.columbia.edu> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> <464D77DC-FEBE-4EB2-ABED-C4D93036EC38@cs.columbia.edu> Message-ID: <1264217839.6239.16.camel@petrie> On Fri, 2010-01-22 at 22:16 -0500, Steven Bellovin wrote: > On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote: > > > The problem with IE is the same problem as Windows, the basic design > > is fundementally insecure and "timely updates" can't fix that. > > You do realize, of course, that IE is recording less than half the > security flaw rate of Firefox? (See > http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) Consider for a moment that both Firefox and Safari are built on open-source code where the code can be audited. As a result, it is clear why Firefox and Safari are more "insecure" than IE, it is simply because the code is there to be audited. Frankly, they are all about the same security-wise. William From bruns at 2mbit.com Fri Jan 22 21:42:59 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 22 Jan 2010 20:42:59 -0700 Subject: Anyone see a game changer here? In-Reply-To: <1264217839.6239.16.camel@petrie> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> <464D77DC-FEBE-4EB2-ABED-C4D93036EC38@cs.columbia.edu> <1264217839.6239.16.camel@petrie> Message-ID: <4B5A7043.6010507@2mbit.com> On 1/22/10 8:37 PM, William Pitcock wrote: > On Fri, 2010-01-22 at 22:16 -0500, Steven Bellovin wrote: >> On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote: >> >>> The problem with IE is the same problem as Windows, the basic design >>> is fundementally insecure and "timely updates" can't fix that. >> >> You do realize, of course, that IE is recording less than half the >> security flaw rate of Firefox? (See >> http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) > > Consider for a moment that both Firefox and Safari are built on > open-source code where the code can be audited. As a result, it is > clear why Firefox and Safari are more "insecure" than IE, it is simply > because the code is there to be audited. > > Frankly, they are all about the same security-wise. > > William I have a feeling that most of the 'security' problems with firefox is related to extensions/addons/plugins, rather then the firefox application itself. You can't fault the devs for unsupported addons/extensions/plugins that are made by a third party with questionable levels of programming skills. M$ tried this same thing, comparing Linux to Windows vulns, neglecting to mention that the only reason why there was more Linux exploits was because they were including things other then the kernel and base system. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From charles at thewybles.com Fri Jan 22 21:48:28 2010 From: charles at thewybles.com (charles at thewybles.com) Date: Sat, 23 Jan 2010 03:48:28 +0000 Subject: Anyone see a game changer here? Message-ID: <195538697-1264218515-cardhu_decombobulator_blackberry.rim.net-1921741947-@bda609.bisx.prod.on.blackberry> When did this become slashdot? Sent via BlackBerry from T-Mobile From smb at cs.columbia.edu Fri Jan 22 22:08:55 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 22 Jan 2010 23:08:55 -0500 Subject: Anyone see a game changer here? In-Reply-To: <1264217839.6239.16.camel@petrie> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> <464D77DC-FEBE-4EB2-ABED-C4D93036EC38@cs.columbia.edu> <1264217839.6239.16.camel@petrie> Message-ID: <919B9E37-8615-46CE-AA63-3CD7423231C4@cs.columbia.edu> On Jan 22, 2010, at 10:37 PM, William Pitcock wrote: > On Fri, 2010-01-22 at 22:16 -0500, Steven Bellovin wrote: >> On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote: >> >>> The problem with IE is the same problem as Windows, the basic design >>> is fundementally insecure and "timely updates" can't fix that. >> >> You do realize, of course, that IE is recording less than half the >> security flaw rate of Firefox? (See >> http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-vulnerability-report---firefox-leads-the-pack-at-44.php) > > Consider for a moment that both Firefox and Safari are built on > open-source code where the code can be audited. As a result, it is > clear why Firefox and Safari are more "insecure" than IE, it is simply > because the code is there to be audited. > > Frankly, they are all about the same security-wise. > I think that that's wishful thinking. IE has fewer security problems because Microsoft has put a tremendous amount of effort -- and often fought its own developers -- in a disciplined software development environment with careful, structured security reviews by people who have the power to say "no, you can't ship this". They've also put a lot of effort into building and using security tools. (For earlier comments by me on this subject, see http://www.cs.columbia.edu/~smb/blog/2009-04/2009-04-29.html) I'm not a fan of Windows. I think it's ugly and bloated, and I don't like it as a user environment. I'm typing this on a Mac (which I like for its JFW properties, not its security; I do not think it is more secure than Vista or Windows 7); I'm also a heavy user -- and a developer -- of NetBSD. If the world suddenly switched its OS of choice away from Windows, I wouldn't weep. But I also would and do hope that the other platforms, be they open or closed source, would learn from what Bill Gates has done well. --Steve Bellovin, http://www.cs.columbia.edu/~smb From nanog at daork.net Fri Jan 22 22:11:12 2010 From: nanog at daork.net (Nathan Ward) Date: Sat, 23 Jan 2010 17:11:12 +1300 Subject: Using /31 for router links In-Reply-To: References: Message-ID: <69855A8C-F746-4051-B5BC-41D2B77ADA3A@daork.net> On 23/01/2010, at 1:31 PM, Jay Nugent wrote: > Greetings, > > On Fri, 22 Jan 2010, Seth Mattinen wrote: > >> In the past I've always used /30's for PTP connection subnets out of old >> habit (i.e. Ethernet that won't take unnumbered) but now I'm considering >> switching to /31's in order to stretch my IPv4 space further. Has anyone >> else does this? Good? Bad? Based on the bit of testing I've done this >> shouldn't be a problem since it's only between routers. > > Yes, this *IS* done *ALL* the time. P-t-P means that there are ONLY > two devices on the wire - hence point to point. It ONLY uses two IP > addresses (one on each end) and there is no reason or need to ARP on this > wire. So no need for a broadcast or network addresses - it is just the > two end points. ARP is still required on ethernet links, so that the MAC address can be discovered for use in the ethernet frame header. /31 does not change the behavior of ARP at all. -- Nathan Ward From msokolov at ivan.Harhan.ORG Fri Jan 22 22:22:50 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 23 Jan 2010 04:22:50 GMT Subject: Using /31 for router links Message-ID: <1001230422.AA22191@ivan.Harhan.ORG> Nathan Ward wrote: > ARP is still required on ethernet links, so that the MAC address can be = > discovered for use in the ethernet frame header. /31 does not change the = > behavior of ARP at all. That is why I hate Ethernet with a passion. Ethernet should be for LANs only; using Ethernet for WANs and PTP links is the vilest invention in the entire history of data networking in my opinion. My medium of choice for PTP links (WAN) is HDLC over a synchronous serial bit stream, with a V.35 or EIA-530 interface between the router and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP header follows...). My 4.3BSD router (or I should better say gateway as that's the proper 80s/90s term) then sees a PTP interface which has no netmask at all, hence the near and far end IP addresses don't have to have any numerical relationship between them at all. No netmask, no MAC addresses, no ARP, none of that crap, just a PTP IP link. MS From gbonser at seven.com Fri Jan 22 22:45:03 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 22 Jan 2010 20:45:03 -0800 Subject: Using /31 for router links In-Reply-To: <69855A8C-F746-4051-B5BC-41D2B77ADA3A@daork.net> References: <69855A8C-F746-4051-B5BC-41D2B77ADA3A@daork.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7388@RWC-EX1.corp.seven.com> > ARP is still required on ethernet links, so that the MAC address can be > discovered for use in the ethernet frame header. /31 does not change > the behavior of ARP at all. > > -- > Nathan Ward > I often manually configure the MAC addresses in static fashion on point-to-points to eliminate the ARPing but that is nothing unique to a /31. It does eliminate the need for ARP, though. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 23 00:04:46 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 23 Jan 2010 16:34:46 +1030 Subject: Using /31 for router links In-Reply-To: <1001230422.AA22191@ivan.Harhan.ORG> References: <1001230422.AA22191@ivan.Harhan.ORG> Message-ID: <20100123163446.6d0be95f@opy.nosense.org> On Sat, 23 Jan 2010 04:22:50 GMT msokolov at ivan.Harhan.ORG (Michael Sokolov) wrote: > Nathan Ward wrote: > > > ARP is still required on ethernet links, so that the MAC address can be = > > discovered for use in the ethernet frame header. /31 does not change the = > > behavior of ARP at all. > > > > That is why I hate Ethernet with a passion. Ethernet should be for LANs > only; using Ethernet for WANs and PTP links is the vilest invention in > the entire history of data networking in my opinion. > > My medium of choice for PTP links (WAN) is HDLC over a synchronous > serial bit stream, with a V.35 or EIA-530 interface between the router > and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or > straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP > header follows...). My 4.3BSD router (or I should better say gateway as > that's the proper 80s/90s term) then sees a PTP interface which has no > netmask at all, hence the near and far end IP addresses don't have to > have any numerical relationship between them at all. No netmask, no MAC > addresses, no ARP, none of that crap, just a PTP IP link. > > > That's not a soapbox, that's a soap factory! What about NAT, ATM cell tax, unnecessary addressing fields in PTP protocols (including your beloved HDLC), SSAP, DSAP fields not being big enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far worse sins in my opinion. From ge at linuxbox.org Sat Jan 23 00:32:20 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 23 Jan 2010 08:32:20 +0200 Subject: Anyone see a game changer here? In-Reply-To: <919B9E37-8615-46CE-AA63-3CD7423231C4@cs.columbia.edu> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6eb799ab1001212119m120fc13dt27be7da4c459c4cd@mail.gmail.com> <775e001a1001212126o4c6511aak73b17fc1a450ae02@mail.gmail.com> <464D77DC-FEBE-4EB2-ABED-C4D93036EC38@cs.columbia.edu> <1264217839.6239.16.camel@petrie> <919B9E37-8615-46CE-AA63-3CD7423231C4@cs.columbia.edu> Message-ID: <4B5A97F4.6080901@linuxbox.org> On 1/23/10 6:08 AM, Steven Bellovin wrote: > I think that that's wishful thinking. IE has fewer security problems because Microsoft has put a tremendous amount of effort -- and often fought its own developers -- in a disciplined software development environment with careful, structured security reviews by people who have the power to say "no, you can't ship this". They've also put a lot of effort into building and using security tools. (For earlier comments by me on this subject, see http://www.cs.columbia.edu/~smb/blog/2009-04/2009-04-29.html) > > I'm not a fan of Windows. I think it's ugly and bloated, and I don't like it as a user environment. I'm typing this on a Mac (which I like for its JFW properties, not its security; I do not think it is more secure than Vista or Windows 7); I'm also a heavy user -- and a developer -- of NetBSD. If the world suddenly switched its OS of choice away from Windows, I wouldn't weep. But I also would and do hope that the other platforms, be they open or closed source, would learn from what Bill Gates has done well. Microsoft has put a lot into securing its code, and is very good at doing so. My main argument here is about the policy of handling vulnerabilities for 6 months without patching (such as this one apparently was) and the policy of waiting a whole month before patching an in-the-wild 0day exploit. Microsoft is the main proponent of responsible disclosure, and has shown it is a responsible vendor. Also, patching vulnerabilities is far from easy, and Microsoft has done a tremendous job at getting it done. I simply call on it to stay responsible and amend its faulty and dangerous policies. A whole month as the default response to patching a 0day? Really? With their practical monopoly, and the resulting monoculture, perhaps their policies ought to be examined for regulation as critical infrastructure, if they can't bring themselves to be more responsible on their own. This is the first time in a long while that I find it fit to criticize Microsoft on security. Perhaps they have grown complacent with the PR nightmare of full disclosure a decade behind them, with most vulnerabilities now "sold" to them directly or indirectly by the security industry. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From fw at deneb.enyo.de Sat Jan 23 04:06:34 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 23 Jan 2010 11:06:34 +0100 Subject: Using /31 for router links In-Reply-To: <4B5A3DFC.4090305@rollernet.us> (Seth Mattinen's message of "Fri, 22 Jan 2010 16:08:28 -0800") References: <4B5A3DFC.4090305@rollernet.us> Message-ID: <87636tcez9.fsf@mid.deneb.enyo.de> * Seth Mattinen: > In the past I've always used /30's for PTP connection subnets out of > old habit (i.e. Ethernet that won't take unnumbered) but now I'm > considering switching to /31's in order to stretch my IPv4 space > further. Has anyone else does this? Good? Bad? Bad. For some systems, such tricks work to some degree only due to lack of input validation, and you get failures down the road (ARP ceases to work, packet filters are not applied properly and other fun). And now is not the time to conserve address space. You really should do everything you can to justify additional allocations from your RIR. From mathias.seiler at mironet.ch Sat Jan 23 06:52:21 2010 From: mathias.seiler at mironet.ch (Mathias Seiler) Date: Sat, 23 Jan 2010 13:52:21 +0100 Subject: Using /126 for IPv6 router links Message-ID: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) Cheers Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler at mironet.ch www.mironet.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5021 bytes Desc: not available URL: From swmike at swm.pp.se Sat Jan 23 06:56:23 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 23 Jan 2010 13:56:23 +0100 (CET) Subject: Using /126 for IPv6 router links In-Reply-To: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: On Sat, 23 Jan 2010, Mathias Seiler wrote: > So what do you think? Good? Bad? Ugly? /127 ? ;) This thread: http://www.gossamer-threads.com/lists/nsp/ipv6/20788 had a long discussion regarding this topic. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Sat Jan 23 07:50:00 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 23 Jan 2010 13:50:00 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: > http://www.gossamer-threads.com/lists/nsp/ipv6/20788 A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big. 2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From ilopezlists at sandboxitsolutions.com Sat Jan 23 08:21:57 2010 From: ilopezlists at sandboxitsolutions.com (Israel Lopez-LISTS) Date: Sat, 23 Jan 2010 06:21:57 -0800 Subject: UC phone system for Haiti (was Katrina Response) In-Reply-To: <63ac96a51001221414v4cbfbe4fp43526d8e56d00a8e@mail.gmail.com> References: <726037536-1264128820-cardhu_decombobulator_blackberry.rim.net-1740310496-@bda123.bisx.prod.on.blackberry> <63ac96a51001221414v4cbfbe4fp43526d8e56d00a8e@mail.gmail.com> Message-ID: <4B5B0605.5000208@sandboxitsolutions.com> Hey guys, Just to add to the thread, I am helping run the LA/OC Event. We just started a google group called "CRISISTELECOM" right now its in alpha stage; the more expertise we have the better we can discuss how to help now and for future situations. http://groups.google.com/group/crisistelcom?hl=en http://crisiscamphaitila2.eventbrite.com/ - the LA Event We are hosting this today at UCI we hope to go 10am-10pm, and if we get enough telecom/network guys in one place, we may breakout into a separate room to discuss what we can do. -Israel Matthew Petach wrote: > On Thu, Jan 21, 2010 at 6:53 PM, wrote: > >> We had a major turnout this past weekend here in southern cal. >> >> Shout out to the uc system and people. >> > > Yahoo is hosting a Crisis Camp to help support the Haiti relief > efforts here in silicon valley tomorrow: > > http://crisiscamphaitisiliconvalley.eventbrite.com/ > > If you have some spare time, please consider bringing your laptop > and coming over to help with supporting relief efforts in Haiti. > > Thanks! > > Matt > > > (and for those not in sunnyvale, there's similar efforts going on in other > cities around the globe:) > > http://www.colombiassh.org/site/ CrisisCamp > Haiti, Bogota, Colombia > http://www.eventbrite.com/event/541831633 CrisisCamp Haiti, Boston > http://crisiscampboulderdenver.eventbrite.com/ CrisisCamp Haiti, > Boulder/Denver > http://crisiscamphaitila2.eventbrite.com/ CrisisCamp > Haiti, Los Angeles > http://crisiscampmiami.eventbrite.com/ CrisisCamp Haiti, Miami > http://crisiscampmontreal.wordpress.com/about/ CrisisCamp Haiti, Montreal > http://crisiscampnola.eventbrite.com/ CrisisCamp > Haiti, New Orleans > http://www.eventbrite.com/event/543649069 CrisisCamp Haiti, New York > http://crisiscamphaitipdx.eventbrite.com/ CrisisCamp > Haiti, Portland > http://www.eventbrite.com/event/542966026/?ref=esdg CrisisCamp > Haiti, Seattle > http://crisiscamphaitiwdc.eventbrite.com/ CrisisCamp > Haiti, Washington, DC > > From dhubbard at dino.hostasaurus.com Sat Jan 23 09:51:57 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Sat, 23 Jan 2010 10:51:57 -0500 Subject: Foundry CLI manual? Message-ID: Anyone have the Foundry/Brocade CLI reference PDF they could send me? Brocade feels you should have a support contract to have a list of commands the hardware you purchased offers and I'm having difficulty with a oc12 pos module. Thanks, David From zartash at gmail.com Sat Jan 23 10:16:58 2010 From: zartash at gmail.com (Zartash Uzmi) Date: Sat, 23 Jan 2010 21:16:58 +0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <88ac5c711001220730q702468c8w7010b638e7a0ddfc@mail.gmail.com> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <88ac5c711001220730q702468c8w7010b638e7a0ddfc@mail.gmail.com> Message-ID: <4fff97de1001230816h1ed412b8m6ef4a5070629f76@mail.gmail.com> Just to be technically correct: Even if you could, you wouldn't do that with 1/8 and 2/8: will need to pair up 2/8 with 3/8! On Fri, Jan 22, 2010 at 8:30 PM, Richard Barnes wrote: > To echo and earlier post, what's the operational importance of > assigning adjacent /8s? Are you hoping to aggregate them into a /7? > --Richard > > On Fri, Jan 22, 2010 at 10:16 AM, William Allen Simpson > wrote: > > Nick Hilliard wrote: > >> > >> On 22/01/2010 13:54, William Allen Simpson wrote: > >>> > >>> Why not 36 & 37? > >> > >> Random selection to ensure that no RIR can accuse IANA of bias. See > >> David's previous post: > >> > >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ > >> > > Because relying on a blog post for policy really meets everybody's > > definition of rationality.... :-( > > > > If you're assigning 2 at the same time, they should be adjacent. > > > > The dribbles here and there policy never was particularly satisfying, > > because it assumes that this was all temporary until the widespread > > deployment of IPv6. > > > > > > From ras at e-gerbil.net Sat Jan 23 10:23:46 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 23 Jan 2010 10:23:46 -0600 Subject: Foundry CLI manual? In-Reply-To: References: Message-ID: <20100123162346.GY75640@gerbil.cluepon.net> On Sat, Jan 23, 2010 at 10:51:57AM -0500, David Hubbard wrote: > Anyone have the Foundry/Brocade CLI reference PDF > they could send me? Brocade feels you should have a > support contract to have a list of commands the > hardware you purchased offers and I'm having difficulty > with a oc12 pos module. Ironically enough the manuals themselves are accessable without a login, but the list of manuals is not. You fail to mention which product you're interested in, so I'm going to take a stab and hope that it's something current with a pos card like an MLX/XMR. If you're still rocking an old B2P622, I'd say you're in need of far more help than any manual can provide. :) http://www.foundrynet.com/services/documentation/xmr_user/current/NetIron_04100_ConfigGuide.pdf http://www.foundrynet.com/services/documentation/xmr_diag/current/NetIronXMR-MLX_04100_DiagnosticRef.pdf -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jared at puck.nether.net Sat Jan 23 10:38:34 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 23 Jan 2010 11:38:34 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <20100122024020.GA61379@gweep.net> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <20100122024020.GA61379@gweep.net> Message-ID: On Jan 21, 2010, at 9:40 PM, Joe Provo wrote: > On Thu, Jan 21, 2010 at 05:13:39PM -0800, George Bonser wrote: > [snip] >> Some of that water is dirtier than the rest. I wouldn't want to be the >> person who gets 1.2.3.0/24 > > Yeah, I encountered some lovely wireless hotspots that use "visit > http://1.1.1.1/ to log out". Seem some vendors encourage the behavior: > http://www.cisco.com/en/US/docs/wireless/controller/4.1/configuration/guide/c41users.html > (as propagated by 'amerispot.com', 'vhotspot.com.au', and some vendor > I forget who does a lot of marine 802.11<->sat NAT service). My guess is there may actually be some liability that resides with Cisco in this regard in producing defective equipment on purpose. - Jared From ebw at abenaki.wabanaki.net Sat Jan 23 10:41:28 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Sat, 23 Jan 2010 11:41:28 -0500 Subject: Status as of Friday COB @ Boutillers, Port au Prince, Haiti Message-ID: <4B5B26B8.7030009@abenaki.wabanaki.net> [sent to a smaller distribution yesterday evening, now to NANOG for wider information and coordination purposes, ebw] All I am looking into booking Reynold's wife and children into short-term lodging in Santo Domingo, Dominican Republic or in a nearby island. There has been some progress on an escort ground transport (to Santo Domingo, D.R.), which will allow Reynold to stay on-site and maintain a non-zero critical technical resource at the Boutilliers Data Center. There are some signs of progress on the visa and/or parole paperwork necessary to move Dominique, Nikki and Aurelia to Florida, where one of Reynold's two (US nationals) sisters live. However, "soon" isn't a term with a fixed date. There has been fuel resupply, with sufficient fuel to run through the weekend (sounds familiar, neh?). With respect to the other core staffers at this facility: St?phane Bruno, administrative contact for the .ht Country Code, has left Haiti with his family. They are currently in Washington, D.C. Max Larson Henry, technical contact for the .ht Country Code, has lost one member of his immediate family, and has taken another member of his immediate family to hospital. He is not available to assist in the operation of the telecommunications and datacommunications infrastructure at Boutillers. Reginald Chauvet, the owner of the Data Center in Boutillers, in which the .ht Country Code registry is a tenant, has left Haiti with his family. They are currently in Maimi. All the critical telecom infrastructures are located at the Data Center in Boutillers, which contains the Internet Exchange Point, is hosted in ths Data Center. There are technicians present in the environment, for whom Mr. Guerrier has coordinated their shelter, feeding and basic needs, but no other technical resources capable of operating any of the NAP/IX/relay problems, as they arise. The transport date isn't fixed, but I expect it will be within the next 48 hours. The end-to-end, PaP-to-SD time is 5 hours, road and boarder control included in the time budget. If Reynold has to provide the escort himself he will be off-site for at least twice that period, possibly as long as 48 hours, complications costed in. The nearby island routing is via air, and preferable, but has a paperwork dependency. As Rod Beckstrom will be doing a public availability in the early evening of the 27th in Washington, D.C., and I've a real job to do from time to time (for CORE), I plan to be in Washington on the 27th. If anyone wants to meet at the Beckstrom event venue [1] or near by drop me a line. Eric [1] http://blog.icann.org/2010/01/public-meet-up-with-icann%E2%80%99s-ceo-in-washington-dc-on-27th-january/ Date: 27th January 2010 17:00 to 19:00 local time Place: Buffalo Billiards, Victorian Room, 1330 19th Street, Washington DC 20036 Map: http://tinyurl.com/yakmr9t From tvarriale at comcast.net Sat Jan 23 11:24:49 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Sat, 23 Jan 2010 11:24:49 -0600 Subject: Using /31 for router links References: <4B5A3DFC.4090305@rollernet.us> <87636tcez9.fsf@mid.deneb.enyo.de> Message-ID: <289CD15B0B2541DABF7A0361DCB112E4@flamdt01> That's a vendor specific issue. Maybe you could take it up with them and ask what year they think this is? tv ----- Original Message ----- From: "Florian Weimer" To: "Seth Mattinen" Cc: "nanOG list" Sent: Saturday, January 23, 2010 4:06 AM Subject: Re: Using /31 for router links >* Seth Mattinen: > >> In the past I've always used /30's for PTP connection subnets out of >> old habit (i.e. Ethernet that won't take unnumbered) but now I'm >> considering switching to /31's in order to stretch my IPv4 space >> further. Has anyone else does this? Good? Bad? > > Bad. For some systems, such tricks work to some degree only due to > lack of input validation, and you get failures down the road (ARP > ceases to work, packet filters are not applied properly and other > fun). > > And now is not the time to conserve address space. You really should > do everything you can to justify additional allocations from your RIR. > From eksffa at freebsdbrasil.com.br Sat Jan 23 11:51:23 2010 From: eksffa at freebsdbrasil.com.br (Patrick Tracanelli) Date: Sat, 23 Jan 2010 15:51:23 -0200 Subject: Best Practices - BGP community to signal transit announces. Message-ID: <4B5B371B.3000301@freebsdbrasil.com.br> Hello Nanogers, I am acting as transit for a number of ASNs, and my upstream peers do filter my announces (as they should as I understand). Therefore I am in the way to set up a community agreement with 'em asking 'em to allow my transit announces for a certain community I wil signal 'em up. Therefore, I have two doubts which I would like to share and hear out your opinions. Is there any best practices or RFC which shall suggest how this community should be set up? Say, while I do standardize this community to be MY-ASN:1 or MY-ASN:65501, is there a difference? Which community numbers should be used for this purpose, if there are any best practice for this? Other than that, I remember Randi Bush's thread on signaling the upstream provider with communities, where a "use with caution" warn was issued[1]. Therefore, is my scenario a "dont" in the "dos and donts" list of practices on signaling the upstreams? If for some reason I should avoid setting up a community for that, whats the other better way to solve it, instead of asking for all upstream providers, one-by-one to allow the transit prefix to be announced via me? I have searched for their own existing communities and, while some up peers do have an adequated community already in place for that, they wont allow me to announce prefixes in their communities, and not everyone will have a comm for that purpose. [1]http://mailman.nanog.org/pipermail/nanog/2009-November/014767.html Thanks. From msokolov at ivan.Harhan.ORG Sat Jan 23 12:52:51 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 23 Jan 2010 18:52:51 GMT Subject: Using /31 for router links Message-ID: <1001231852.AA23235@ivan.Harhan.ORG> Mark Smith wrote: > What about NAT, ATM cell tax, unnecessary addressing fields in PTP > protocols (including your beloved HDLC), SSAP, DSAP fields not being big > enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 > through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far > worse sins in my opinion. Hmm. PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP. If all those xDSL users were willing to stick V.35 cards in their PCs and use "modems" that put out V.35 instead of Ethernet, the whole PPPoE kludge with all of its attendant MTU issues would have been completely unnecessary. Want PPP for authentication etc? Just run straight PPP (RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU unlike Ethernet (jogging my memory, all HDLC controllers which I recall working with allowed maximum frame size up to just a little under 2^16 octets or so), and one can thus have the standard MTU of 1500 octets on that PPP link! Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. What everyone else in this fubared world calls an xDSL "modem" (a black box that puts Ethernet out) is not a modem at all (i.e., total misappropriation of the term), it is actually a bastardized router! These boxes forward packets between two network interfaces: the presented Ethernet interface and the internal (often horrendously non-standard and proprietary) HDLC or ATM interface on the actual line. A device that forwards packets between two different network interfaces is by definition a router, hence what everyone calls a "modem" is actually a bastardized router - bastardized because its routing (packet forwarding) function is something incomprehensible. The Ethernet-to-Ethernet NAT boxes that everyone else calls "routers" should be called "NATters" or something like that, anything but a router! A true router is a box with a few AUIs and a few V.35 ports sticking out of it, running some very capable, flexible and totally user-configurable packet forwarding software stack that supports all networking models: IP routing, MAC bridging, VC cross-connect. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? MS From lists at quux.de Sat Jan 23 13:09:45 2010 From: lists at quux.de (Jens Link) Date: Sat, 23 Jan 2010 20:09:45 +0100 Subject: Using /31 for router links In-Reply-To: <87636tcez9.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Sat\, 23 Jan 2010 11\:06\:34 +0100") References: <4B5A3DFC.4090305@rollernet.us> <87636tcez9.fsf@mid.deneb.enyo.de> Message-ID: <87r5pgskna.fsf@laphroiag.quux.de> Florian Weimer writes: > Bad. For some systems, such tricks work to some degree only due to > lack of input validation, and you get failures down the road (ARP > ceases to work, packet filters are not applied properly and other > fun). I never had any problems using Cisco to Cisco, Linux to Linux or Cisco to Linux using /31. Only problem I encountered was when a Linux based router was replaced by a Windows box (please don't ask). cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From lists at quux.de Sat Jan 23 13:11:35 2010 From: lists at quux.de (Jens Link) Date: Sat, 23 Jan 2010 20:11:35 +0100 Subject: Using /31 for router links In-Reply-To: <88C6A9EE-897A-4744-A3DA-B54B55D71D3B@cenic.org> (Chris Costa's message of "Fri\, 22 Jan 2010 17\:00\:22 -0800") References: <4B5A3DFC.4090305@rollernet.us> <20100123004123.GA64506@gweep.net> <4B5A4885.6030901@rollernet.us> <88C6A9EE-897A-4744-A3DA-B54B55D71D3B@cenic.org> Message-ID: <87my04skk8.fsf@laphroiag.quux.de> Chris Costa writes: > We recently did a backbone router upgrade and the vendor surprisingly > didn't support /31's. Mind dropping a name? Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From lists at quux.de Sat Jan 23 13:21:15 2010 From: lists at quux.de (Jens Link) Date: Sat, 23 Jan 2010 20:21:15 +0100 Subject: Foundry CLI manual? In-Reply-To: <20100123162346.GY75640@gerbil.cluepon.net> (Richard A. Steenbergen's message of "Sat\, 23 Jan 2010 10\:23\:46 -0600") References: <20100123162346.GY75640@gerbil.cluepon.net> Message-ID: <87iqassk44.fsf@laphroiag.quux.de> Richard A Steenbergen writes: > Ironically enough the manuals themselves are accessable without a login, > but the list of manuals is not. Outch. Personally I don't like when company's hides documentation or require me to register (or even get a support contract) to read the documentation. On the other hand there are several vendor that are very forthcoming vendors that even send you test equipment for free. Guess which company's I'm recommending to customers. cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From andy at nosignal.org Sat Jan 23 13:23:25 2010 From: andy at nosignal.org (Andy Davidson) Date: Sat, 23 Jan 2010 19:23:25 +0000 Subject: Network Bandwidth Reporting Tool In-Reply-To: <1264126383.4965.14.camel@icelaptop> References: <1264126383.4965.14.camel@icelaptop> Message-ID: <94BE2471-C692-480D-AB55-D031CAB50374@nosignal.org> On 22 Jan 2010, at 02:13, Isaac Conway wrote: > I am curious what tools you use to generate monthly usage and billing > reports This : > I was thinking about writing some quick scripts to poll the router > interfaces and put it to database, Mainly because organisations have different methods for managing the flow of business metrics inside the org, e.g. crm/accounting packages/policies/products, and by writing your own glue between them you can automate the human error prone stages like this : > a page I can pull up and gives me the numbers (95p, > cost, overage, etc.) for the past month. Copy and paste into a > spreadsheet, job complete.... Andy From erik_list at caneris.com Sat Jan 23 13:33:12 2010 From: erik_list at caneris.com (Erik L) Date: Sat, 23 Jan 2010 14:33:12 -0500 Subject: Using /31 for router links In-Reply-To: <1001231852.AA23235@ivan.Harhan.ORG> References: <1001231852.AA23235@ivan.Harhan.ORG> Message-ID: > As for ATM... The part that totally baffles me about the use > of ATM on > xDSL lines is that I have never, ever, ever seen an xDSL line carrying > more than one ATM VC. OK, there may be someone out there who > has set up > a configuration like that just for fun, but 99.999% of all ATM'd xDSL > lines out there carry a single PVC at 0*35 or 0*38. > Multi-PVC is used (in the context of xSLAM<-->CPE), for example, for delivering IPTV+DSL. 0/35 and 0/38 are just arbitrary numbers, there are plenty of other random ones like 0/33 used by major service providers. Arguably your "99.999%" is way off. From robertg at garlic.com Sat Jan 23 13:47:55 2010 From: robertg at garlic.com (Robert Glover) Date: Sat, 23 Jan 2010 19:47:55 +0000 Subject: Using /31 for router links In-Reply-To: <1001231852.AA23235@ivan.Harhan.ORG> References: <1001231852.AA23235@ivan.Harhan.ORG> Message-ID: <1687665288-1264276066-cardhu_decombobulator_blackberry.rim.net-267728454-@bda932.bisx.prod.on.blackberry> [Michael Sokolov said:] *snip* but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! *snip* We've got several ADSL and SDSL circuits that carry two PVC's: 0/35 and 0/36. Covad has a product called "Voice Optimized Access". I won't go into the gory details of the underlying technology, but the second PVC is utilized for voice. Essentially two separate IP networks over one physical network, one with guaranteed bandwidth (by way of vbr-rt) and QoS through Covad's network. Sincerely, Bobby Glover Director of Information Services South Valley Internet -----Original Message----- From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 23 Jan 2010 18:52:51 To: Subject: Re: Using /31 for router links Mark Smith wrote: > What about NAT, ATM cell tax, unnecessary addressing fields in PTP > protocols (including your beloved HDLC), SSAP, DSAP fields not being big > enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 > through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far > worse sins in my opinion. Hmm. PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP. If all those xDSL users were willing to stick V.35 cards in their PCs and use "modems" that put out V.35 instead of Ethernet, the whole PPPoE kludge with all of its attendant MTU issues would have been completely unnecessary. Want PPP for authentication etc? Just run straight PPP (RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU unlike Ethernet (jogging my memory, all HDLC controllers which I recall working with allowed maximum frame size up to just a little under 2^16 octets or so), and one can thus have the standard MTU of 1500 octets on that PPP link! Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. What everyone else in this fubared world calls an xDSL "modem" (a black box that puts Ethernet out) is not a modem at all (i.e., total misappropriation of the term), it is actually a bastardized router! These boxes forward packets between two network interfaces: the presented Ethernet interface and the internal (often horrendously non-standard and proprietary) HDLC or ATM interface on the actual line. A device that forwards packets between two different network interfaces is by definition a router, hence what everyone calls a "modem" is actually a bastardized router - bastardized because its routing (packet forwarding) function is something incomprehensible. The Ethernet-to-Ethernet NAT boxes that everyone else calls "routers" should be called "NATters" or something like that, anything but a router! A true router is a box with a few AUIs and a few V.35 ports sticking out of it, running some very capable, flexible and totally user-configurable packet forwarding software stack that supports all networking models: IP routing, MAC bridging, VC cross-connect. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? MS From fw at deneb.enyo.de Sat Jan 23 13:49:25 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 23 Jan 2010 20:49:25 +0100 Subject: Using /31 for router links In-Reply-To: <289CD15B0B2541DABF7A0361DCB112E4@flamdt01> (Tony Varriale's message of "Sat, 23 Jan 2010 11:24:49 -0600") References: <4B5A3DFC.4090305@rollernet.us> <87636tcez9.fsf@mid.deneb.enyo.de> <289CD15B0B2541DABF7A0361DCB112E4@flamdt01> Message-ID: <87pr50wqii.fsf@mid.deneb.enyo.de> * Tony Varriale: > That's a vendor specific issue. Maybe you could take it up with them > and ask what year they think this is? I think they support it on point-to-point media only, which seems sufficient for RFC 3021 compliance. Ethernet is a different story, unfortunately. From stephen at sprunk.org Sat Jan 23 13:52:54 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 23 Jan 2010 13:52:54 -0600 Subject: Using /31 for router links In-Reply-To: <1001230422.AA22191@ivan.Harhan.ORG> References: <1001230422.AA22191@ivan.Harhan.ORG> Message-ID: <4B5B5396.6080008@sprunk.org> Michael Sokolov wrote: > That is why I hate Ethernet with a passion. Ethernet should be for LANs > only; using Ethernet for WANs and PTP links is the vilest invention in > the entire history of data networking in my opinion. > Ah, but who's to say that all PTP links are WANs? Are you really going to run an OC-48 from one router to another _in the same building_ when you need 1Gb/s between them? Have you looked at how much more that would cost? Ethernet interfaces, particularly copper, are dirt cheap. Even for MANs or WANs, the price of a pipe (plus equipment at each end) will still often be significantly lower for Ethernet than for "real" circuits--especially if you don't plan on using all the bandwidth all of the time. > My medium of choice for PTP links (WAN) is HDLC over a synchronous > serial bit stream, with a V.35 or EIA-530 interface between the router > and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or > straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP > header follows...). My 4.3BSD router (or I should better say gateway as > that's the proper 80s/90s term) then sees a PTP interface which has no > netmask at all, hence the near and far end IP addresses don't have to > have any numerical relationship between them at all. No netmask, no MAC > addresses, no ARP, none of that crap, just a PTP IP link. > Well, it'd certainly be nice if someone would make something even cheaper than Ethernet for that purpose (which would squeeze out a few more bits of payload), but so far nobody has. It's hard to beat Ethernet on volume, and that's the main determinant of cost/price... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From msokolov at ivan.Harhan.ORG Sat Jan 23 14:20:03 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 23 Jan 2010 20:20:03 GMT Subject: Using /31 for router links Message-ID: <1001232020.AA23616@ivan.Harhan.ORG> Stephen Sprunk wrote: > Ah, but who's to say that all PTP links are WANs? Are you really going > to run an OC-48 from one router to another _in the same building_ when > you need 1Gb/s between them? Can't say - I have never needed that much bandwidth. :) I still live in an alternate Universe where 10 Mbps coaxial Ethernet for LANs is near- infinity and 2 Mbps or so makes for a *very* sweet WAN. The facility housing the mail server from which I am sending this message is connected to the outside Inet via a 384 kbps SDSL pipe which I am using basically as ARPANET replacement - I miss the ARPANET. If I wanted a PTP link between two routers in the same building that runs at the same speed as my Ethernet (10 Mbps), I would use EIA-422 (which is rated up to 10 Mbps) and run something HDLC-based over it. > Even for MANs or WANs, the price of a pipe (plus equipment at each end) > will still often be significantly lower for Ethernet than for "real" > circuits Wait a moment here. With a MAN/WAN involving wires/fiber running over public property, what one is paying for is the right to use those wires for your data, right? The wires themselves do NOT run Ethernet at the electrical level, so if you have some "MAN/WAN Ethernet" service, there is a black box of some kind that converts the native electrical signal format to Ethernet. Why not take that black box out of service, use it for baseball practice (Office Space style), and use the exact same wires/fiber (rented at exactly the same monthly recurring price) in its native non-Ethernet form? IOW, if you are renting dry copper / dark fiber, you have a choice to use it either through a stinky "black box" Ethernet converter or in the native non-Ethernet form directly, but the monthly recurring cost remains exactly the same. > Well, it'd certainly be nice if someone would make something even > cheaper than Ethernet for that purpose (which would squeeze out a few > more bits of payload), but so far nobody has. It's hard to beat > Ethernet on volume, and that's the main determinant of cost/price... But that's non-recurring equipment cost only, and at least in my case the little investment in V.35 etc hardware is a much lower cost than the price of pain and suffering with Ethernet for a purist like me. MS From bjorn at mork.no Sat Jan 23 14:25:28 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 23 Jan 2010 21:25:28 +0100 Subject: Foundry CLI manual? In-Reply-To: <87iqassk44.fsf@laphroiag.quux.de> (Jens Link's message of "Sat, 23 Jan 2010 20:21:15 +0100") References: <20100123162346.GY75640@gerbil.cluepon.net> <87iqassk44.fsf@laphroiag.quux.de> Message-ID: <87hbqc4lhj.fsf@nemi.mork.no> Jens Link writes: > Richard A Steenbergen writes: > >> Ironically enough the manuals themselves are accessable without a login, >> but the list of manuals is not. > > Outch. Personally I don't like when company's hides documentation or > require me to register (or even get a support contract) to read the > documentation. Cannot agree more. It's a major drawback even with a support contract. I often use Google to search for particular features, bugs, workarounds or whatever, limiting the scope to site:somevendor.com. This naturally doesn't work with those who hide their docs. And the site internal search engines are usually a bad joke at best. Regarding Foundry, I remember they used to have public docs several years ago. But all of a sudden it was closed. Around 2003 maybe? Nowadays, Huawei is on top of my "oh i hate that web site" list. No useful public content whatsoever. Don't understand why they even bother putting up a web server. I appreciate that there still are serious vendors like Cisco and Juniper who don't mind making their docs public. Thanks guys! Bj?rn From bruns at 2mbit.com Sat Jan 23 14:34:49 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 23 Jan 2010 13:34:49 -0700 Subject: Using /31 for router links In-Reply-To: <1001231852.AA23235@ivan.Harhan.ORG> References: <1001231852.AA23235@ivan.Harhan.ORG> Message-ID: <4B5B5D69.8080209@2mbit.com> On 1/23/10 11:52 AM, Michael Sokolov wrote: > Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 > instead of goddamn Ethernet would be a true modem: a modulator/demodulator > that modulates/demodulates the bits at the electrical level without > caring about what's in those bits. Back in the days of Rhythms and Copper Mountain gear, Netopia had the D series routers which were actually xDSL to DSU units. Used to use them for customers who had T1 equipment (2500s, 2600s, 1600s, etc). Worked quite well. Though, I'm not sure they'd work these days, nor do I think they came in ADSL models either. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From msokolov at ivan.Harhan.ORG Sat Jan 23 14:50:56 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 23 Jan 2010 20:50:56 GMT Subject: Using /31 for router links Message-ID: <1001232050.AA23731@ivan.Harhan.ORG> Brielle Bruns wrote: > Back in the days of Rhythms and Copper Mountain gear, Netopia had the D > series routers which were actually xDSL to DSU units. Yes, I am very familiar with them: http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/netopia/dsu.html As that page explains, they are only pseudo-DSUs though. I much much prefer a true bit-transparent DSU: http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/xsb2000.html I have also designed and built an SDSL to EIA-530 DSU of my very own: http://ifctfvax.Harhan.ORG/OpenSDSL/OSDCU/ On the latter I have the hardware (the page above has a photo of the board), but the operational software (or firmware if you will) remains to be finished. > Though, I'm not sure they'd work these days, Only in the very limited geographic footpring of what used to be DSL.net - they are the last remaining semi-major operator of CM DSLAMs: http://ifctfvax.Harhan.ORG/OpenSDSL/megapath.html My big goal is to make my own DSU which I have just mentioned function as a Layer 2 converter (FRF.8 and friends) from Nokia SDSL/ATM served by Covad to HDLC. > nor do I think > they came in ADSL models either. I don't think anyone have *ever* used V.35 & friends with ADSL - probably because those who would want V.35 (i.e., people like me) would find ADSL morally offensive. :-) MS From sethm at rollernet.us Sat Jan 23 14:53:12 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 23 Jan 2010 12:53:12 -0800 Subject: Using /31 for router links In-Reply-To: <1001232020.AA23616@ivan.Harhan.ORG> References: <1001232020.AA23616@ivan.Harhan.ORG> Message-ID: <4B5B61B8.7070808@rollernet.us> Michael Sokolov wrote: > > Wait a moment here. With a MAN/WAN involving wires/fiber running over > public property, what one is paying for is the right to use those wires > for your data, right? The wires themselves do NOT run Ethernet at the > electrical level, so if you have some "MAN/WAN Ethernet" service, there > is a black box of some kind that converts the native electrical signal > format to Ethernet. Why not take that black box out of service, use it > for baseball practice (Office Space style), and use the exact same > wires/fiber (rented at exactly the same monthly recurring price) in its > native non-Ethernet form? > Well, I have an OC-12 upstairs that has an Overture box attached to it because: Ethernet is not tariffed and the OC-12 is. The price difference between the two was substantial (even though it's the same thing) and I was going for "cheap alternate path". If they were the same price I would have probably just taken it directly. ~Seth From efbatey at gmail.com Sat Jan 23 15:18:17 2010 From: efbatey at gmail.com (Everett Batey) Date: Sat, 23 Jan 2010 13:18:17 -0800 Subject: CRISISTELCOM2 is entry for Helping Message-ID: If you replied to prior post for CRISISTELCOM .. or are new .. Please, sign up at CRISISTELCOM2 our entry point to assist with broad-scope telecommunication needs in disaster as CRISIS HAITI, today, and others in the future. Welcoming engineers, managers, ideas for all electronic communications which are needed and often lost in disasters. Contact signups crisistelcom2 at googlegroups.com for http://groups.google.com/group/crisistelcom2 This is for tech and business volunteers to help, spammers and advertisers will be banned. Ev Batey -- WA6CRE -- efbatey at gmail.com CCHaitiLA a/k/a lioneverett at gmail.com or efbarc at cotdazr.org (805) 616-2471 Twitter.: efbatey - CCHaitiLA: http://bit.ly/6jWfkQ ASC-USC http://bit.ly/5vzKH6 From bonomi at mail.r-bonomi.com Sat Jan 23 15:22:43 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 23 Jan 2010 15:22:43 -0600 (CST) Subject: Anyone see a game changer here? Message-ID: <201001232122.o0NLMh3v010635@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Jan 22 21:16:53 201G > Subject: Re: Anyone see a game changer here? > From: Steven Bellovin > Date: Fri, 22 Jan 2010 22:16:03 -0500 > To: Bruce Williams > Cc: nanog at nanog.org > > > On Jan 22, 2010, at 12:26 AM, Bruce Williams wrote: > > > The problem with IE is the same problem as Windows, the basic design > > is fundementally insecure and "timely updates" can't fix that. > > You do realize, of course, that IE is recording less than half the = > security flaw rate of Firefox? (See = > http://prosecure.netgear.com/community/security-blog/2009/11/web-browser-v= > ulnerability-report---firefox-leads-the-pack-at-44.php) "The number of discovered bugs in any application is finite. The number of _undiscovered_ bugs in that same application, is, by definition, infinite." "Statistics don't lie, but...." *GRIN* From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 23 15:43:31 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 24 Jan 2010 08:13:31 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> Message-ID: <20100124081331.212f82cd@opy.nosense.org> On Sat, 23 Jan 2010 13:50:00 +0000 "Dobbins, Roland" wrote: > > On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: > > > http://www.gossamer-threads.com/lists/nsp/ipv6/20788 > > A couple of points for thought: > > 1. Yes, the IPv6 address space is unimaginably huge. > Even so, when every molecule in every soda can in the world has its own > IPv6 address in years to come, it might not seem so big. We'd better start worrying about conserving Ethernet addresses then, because they're going to run out way before IPv6 ones will. First thing we'll need to do is setup a registry so that when ever somebody throws out an Ethernet card, they write down the MAC address so that somebody else can recycle it. Secondly we'll need to get the IEEE specs changed so that any point-to-point ethernet links don't use addressing - we're wasting two addresses on each one of them. We'll also save bandwidth by not sending an extra 12 addressing bytes in each frame on 10Gbps or 40/100 Gbps links in the future. > > 2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes. > That's a new bit of FUD. References? > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 23 16:42:40 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 24 Jan 2010 09:12:40 +1030 Subject: Foundry CLI manual? In-Reply-To: <87hbqc4lhj.fsf@nemi.mork.no> References: <20100123162346.GY75640@gerbil.cluepon.net> <87iqassk44.fsf@laphroiag.quux.de> <87hbqc4lhj.fsf@nemi.mork.no> Message-ID: <20100124091240.529d91f5@opy.nosense.org> On Sat, 23 Jan 2010 21:25:28 +0100 Bj?rn Mork wrote: > Jens Link writes: > > Richard A Steenbergen writes: > > > >> Ironically enough the manuals themselves are accessable without a login, > >> but the list of manuals is not. > > > > Outch. Personally I don't like when company's hides documentation or > > require me to register (or even get a support contract) to read the > > documentation. > > Cannot agree more. It's a major drawback even with a support contract. > I often use Google to search for particular features, bugs, workarounds > or whatever, limiting the scope to site:somevendor.com. This naturally > doesn't work with those who hide their docs. And the site internal > search engines are usually a bad joke at best. > > Regarding Foundry, I remember they used to have public docs several > years ago. But all of a sudden it was closed. Around 2003 maybe? > > Nowadays, Huawei is on top of my "oh i hate that web site" list. No > useful public content whatsoever. Don't understand why they even bother > putting up a web server. > > I appreciate that there still are serious vendors like Cisco and > Juniper who don't mind making their docs public. Thanks guys! > Agree. The first thing a vendor can do to have a chance of you buying their gear is to make it as easy as possible to transition to it, and that includes becoming familiar with it's CLI, and working out how much effort you'll need to spend on converting to different syntax. What's so proprietary about how to configure OSPF that it needs to be kept a secret? > > > Bj?rn > From rdobbins at arbor.net Sat Jan 23 17:04:26 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 23 Jan 2010 23:04:26 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <20100124081331.212f82cd@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> <20100124081331.212f82cd@opy.nosense.org> Message-ID: <4922EDF2-FE62-419F-9A5E-1CF021D6E16B@arbor.net> On Jan 24, 2010, at 4:43 AM, Mark Smith wrote: > That's a new bit of FUD. References? It isn't 'FUD'. redistribute connected. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From mysidia at gmail.com Sat Jan 23 17:07:05 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 23 Jan 2010 17:07:05 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> Message-ID: <6eb799ab1001231507s1b0804c7p7fe974b45252c02@mail.gmail.com> On Sat, Jan 23, 2010 at 7:50 AM, Dobbins, Roland wrote: > On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" --Donald Knuth > A couple of points for thought: > 1. ? ? ?Yes, the IPv6 address space is unimaginably huge. ?Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big. Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times as many) as the number of additional IPs used by giving a point-to-point link a /64. When comparing the number of molecules in a soda can TO 2^64. It's like in the IPv4 world comparing a /30 to a /31. And arguing it's wasteful to give a point-to-point link a /30 since all it needs (in theory) is a /31. Near the beginning of IPv4 (before exhaustion was an issue). when at the same time standard practice was allocating /13s to users who will use at most a /20 in 10 years. Optimizing this early creates potential issues and reduces flexibility going forward. The designer/operator should not confuse design patterns that use more IP addresses than the minimum technically possible, for a block of addresses, with design selections that are gross wastes of address space -- such as assigning every molecule its own IP. IPv6 is a very large address space, so it's LARGE optimizations that matter, such as not giving every molecule its own IP. Not small optimizations that matter, such as using a /126 for a relatively small number of P-t-P links (in the grand scheme of things) versus a /64. Anyways, I would suggest reserving a /64 to each P-t-P link, and (If you prefer) set static neighbor entry for the peer (in the case of Ethernet) and configuring a /72 (smaller than what you have reserved). For the sole reason of disabling IPv6 autoconfig and neighbor discovery. Technically everything to the right of the /64 boundary is reserved for the HOST portion, and such is the design of IPv6. This allows for greater scalability than assigning a longer prefix. If that specific connection is ever to be replaced one day with a link that's _not_ point-to-point, or to be expanded, then the designer has greater flexibility: an option that does not require re-numbering the changed link. -- -J From rdobbins at arbor.net Sat Jan 23 17:51:33 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 23 Jan 2010 23:51:33 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <6eb799ab1001231507s1b0804c7p7fe974b45252c02@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> <6eb799ab1001231507s1b0804c7p7fe974b45252c02@mail.gmail.com> Message-ID: <191AA587-4C9C-442F-A2AC-4CCF2CC2001A@arbor.net> On Jan 24, 2010, at 6:07 AM, James Hess wrote: > Then obviously, it's giving every molecule in every soda can an IP address that is the waste that matters. There are several orders of magnitude between the number of molecules in a soda can (~65000 times > as many) as the number of additional IPs used by giving a point-to-point link a /64. I'm not too sure of the math behind this - and it was just one example. The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, et. al., argue against needless consumption of IP addresses, IMHO. Not to mention all the smart material molecules continuously communicating with one another via NFC or somesuch in order to dynamically re-shape automobile aerodynamics and so forth. Of course, the sinkhole issue is of far greater immediate concern. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From morrowc.lists at gmail.com Sat Jan 23 19:08:05 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 23 Jan 2010 20:08:05 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler wrote: > Hi > > In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. > > I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > > So what do you think? Good? Bad? Ugly? /127 ? ;) draft-kohno-ipv6-prefixlen-p2p-00.txt () why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris From morrowc.lists at gmail.com Sat Jan 23 19:36:39 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 23 Jan 2010 20:36:39 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> Message-ID: <75cb24521001231736x736ca2m418f733fc2b5bcd4@mail.gmail.com> On Sat, Jan 23, 2010 at 8:08 PM, Christopher Morrow wrote: > On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler > wrote: >> Hi >> >> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >> >> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >> >> So what do you think? Good? Bad? Ugly? /127 ? ;) > > draft-kohno-ipv6-prefixlen-p2p-00.txt > > () > > why not just ping your vendors to support this, and perhaps chime in > on v6ops about wanting to do something sane with ptp link addressing? > :) a kind soul or 2 asked: "How do I sign up for the v6ops mailing list?" (it's actually the ipv6 wg mailing list) should get you there... -Chris From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 23 19:48:07 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 24 Jan 2010 12:18:07 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <4922EDF2-FE62-419F-9A5E-1CF021D6E16B@arbor.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> <20100124081331.212f82cd@opy.nosense.org> <4922EDF2-FE62-419F-9A5E-1CF021D6E16B@arbor.net> Message-ID: <20100124121807.19cea0d1@opy.nosense.org> On Sat, 23 Jan 2010 23:04:26 +0000 "Dobbins, Roland" wrote: > > On Jan 24, 2010, at 4:43 AM, Mark Smith wrote: > > > That's a new bit of FUD. References? > > It isn't 'FUD'. > > redistribute connected. > In my opinion it's better not to do blind redistribution. More control means less things that are unexpected or or can be forgotten. That being said, I don't understand why that's a problem, and why that problem doesn't already exist in IPv4. > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 23 20:03:18 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 24 Jan 2010 12:33:18 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> Message-ID: <20100124123318.7fd8b379@opy.nosense.org> On Sat, 23 Jan 2010 20:08:05 -0500 Christopher Morrow wrote: > On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler > wrote: > > Hi > > > > In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. > > > > I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > > > > So what do you think? Good? Bad? Ugly? /127 ? ;) > > draft-kohno-ipv6-prefixlen-p2p-00.txt > > () > Internet Draft No disrespect to the people who've written it, however it's a draft at this point, not an RFC. The current IP Version 6 Addressing Architecture RFC (RFC4291) says, " 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" If that draft is going to go anywhere, then I would expect there also needs to be a new version of RFC4291. > why not just ping your vendors to support this, and perhaps chime in > on v6ops about wanting to do something sane with ptp link addressing? > :) > > -Chris > From morrowc.lists at gmail.com Sat Jan 23 20:11:30 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 23 Jan 2010 21:11:30 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100124123318.7fd8b379@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> <20100124123318.7fd8b379@opy.nosense.org> Message-ID: <75cb24521001231811r7baa5035rdd97c268e69a6403@mail.gmail.com> On Sat, Jan 23, 2010 at 9:03 PM, Mark Smith wrote: > On Sat, 23 Jan 2010 20:08:05 -0500 > Christopher Morrow wrote: > >> On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler >> wrote: >> > Hi >> > >> > In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >> > >> > I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >> > >> > So what do you think? Good? Bad? Ugly? /127 ? ;) >> >> draft-kohno-ipv6-prefixlen-p2p-00.txt >> >> () >> > > Internet Draft > > No disrespect to the people who've written it, however it's a draft at > this point, not an RFC. absolutely. so... if it's of interest, speak up (on the v6 wg mailing list) or let the authors know. > The current IP Version 6 Addressing Architecture RFC (RFC4291) says, > > " ?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" > > If that draft is going to go anywhere, then I would expect there also > needs to be a new version of RFC4291. I believe the authors know this as well. -Chris > >> why not just ping your vendors to support this, and perhaps chime in >> on v6ops about wanting to do something sane with ptp link addressing? >> :) >> >> -Chris >> > From mysidia at gmail.com Sat Jan 23 20:24:47 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 23 Jan 2010 20:24:47 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <191AA587-4C9C-442F-A2AC-4CCF2CC2001A@arbor.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> <6eb799ab1001231507s1b0804c7p7fe974b45252c02@mail.gmail.com> <191AA587-4C9C-442F-A2AC-4CCF2CC2001A@arbor.net> Message-ID: <6eb799ab1001231824o346e2bdfp4471d2623ea386ae@mail.gmail.com> On Sat, Jan 23, 2010 at 5:51 PM, Dobbins, Roland wrote: > It isn't 'FUD'. > redistribute connected. In that case, the fault would lie just as much with the unconditional redistribution policy, as the addressing scheme, which is error-prone in and of itself. No matter how you address your links or what type of equipment on your network, it's probably possible to find some configuration error that will produce poor router behavior. ... > I'm not too sure of the math behind this - and it was just one example. ? The >gazillions of one-time-use nanomachines used to scrape away plaque in just a >single patient's bloodstream, et. al., argue against needless consumption of IP >addresses, IMHO. ?Not to mention all the smart material molecules continuously The trouble is both of the examples, is they both imply something far greater than mere needless consumption of IP addresses in and of themselves. Assigning global IP addresses to individual nanonites is a massive waste in and of itself. It is easy to logically reject needlessly assigning each nanonite as an IP address, because they are obviously too massive in number to easily achieve a sane addressing scheme. My point is that in the face of such massive waste, the smaller amounts of "needless consumption" become irrelevent. If you are justifying consuming 2*10**25 IP addresses on one-time-use nanonites, you can certainly spend 5% of your IPv6 address space on point-to-point links without the P-t-P links being the issue. 5% would be >100,000 P-t-P links in that case. Either way, one /43 would easily provide more than enough IPs for both nanonites and 100,000 /64 p-t-p links. And with a standard /40 subnet, you'd have 4 additional bits left over to work with, to sanely subnet your nanonites. The issue in scenarios like that one is the things there are a lot of that _consume_ many addresses. Point-to-point addresses are rare, much rarer than hosts, and much less massive in number than nanonites addressed onto a LAN would be, so giving a P-t-P link an an entire /64 should not be a consumption issue in any conceivable (likely) scenario, where a proper amount of IPv6 space has been obtained in the first place. -- -J From owen at delong.com Sat Jan 23 20:24:26 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Jan 2010 18:24:26 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: > Hi > > In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. > > I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > > So what do you think? Good? Bad? Ugly? /127 ? ;) > Use the /64... It's OK... IPv6 was designed with that in mind. 64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the great lakes with M&Ms before you ran out of /64s. Owen > > Cheers > > Mathias Seiler > > MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > T +41 61 201 30 90, F +41 61 201 30 99 > > mathias.seiler at mironet.ch > www.mironet.ch > From LarrySheldon at cox.net Sat Jan 23 20:44:28 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 23 Jan 2010 20:44:28 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: <4B5BB40C.3080206@cox.net> On 1/23/2010 8:24 PM, Owen DeLong wrote: > On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: >> In reference to the discussion about /31 for router links, I d'like >> to know what is your experience with IPv6 in this regard. >> >> I use a /126 if possible but have also configured one /64 just for >> the link between two routers. This works great but when I think >> that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >> >> So what do you think? Good? Bad? Ugly? /127 ? ;) >> > Use the /64... It's OK... IPv6 was designed with that in mind. > > 64 bits is enough networks that if each network was an almond M&M, > you would be able to fill all of the great lakes with M&Ms before you > ran out of /64s. Did somebody once say something like that about Class C addresses? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From brandon.galbraith at gmail.com Sat Jan 23 20:55:52 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Sat, 23 Jan 2010 20:55:52 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5BB40C.3080206@cox.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> Message-ID: <366100671001231855n19d31d50l4953a25be0910546@mail.gmail.com> Sometimes good enough > perfect Never know what is going to come along to turn your addressing plan on its head. -brandon On 1/23/10, Larry Sheldon wrote: > On 1/23/2010 8:24 PM, Owen DeLong wrote: >> On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: >>> In reference to the discussion about /31 for router links, I d'like >>> to know what is your experience with IPv6 in this regard. >>> >>> I use a /126 if possible but have also configured one /64 just for >>> the link between two routers. This works great but when I think >>> that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>> >>> So what do you think? Good? Bad? Ugly? /127 ? ;) >>> >> Use the /64... It's OK... IPv6 was designed with that in mind. >> >> 64 bits is enough networks that if each network was an almond M&M, >> you would be able to fill all of the great lakes with M&Ms before you >> ran out of /64s. > > Did somebody once say something like that about Class C addresses? > > > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jan 23 21:06:50 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 24 Jan 2010 13:36:50 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <366100671001231855n19d31d50l4953a25be0910546@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <366100671001231855n19d31d50l4953a25be0910546@mail.gmail.com> Message-ID: <20100124133650.6575360a@opy.nosense.org> On Sat, 23 Jan 2010 20:55:52 -0600 Brandon Galbraith wrote: > Sometimes good enough > perfect > > Never know what is going to come along to turn your addressing plan on its head. > It seems to me that what this really is about is trying to be in the best position in the future. I think mainly it's about trying to avoid unexpected and future renumbering/change of prefix length costs. Possible positions or situations are : 1. you use a variety of node address lengths across your network, and there are no future consequences - everything works and continues to work 2. you use a single node address length (i.e. /64) across your network, and there are no future consequences - everything works and continues to work 3. you use a variety of node address lengths, and you'll have to renumber to /64s, because you encounter unacceptable issues e.g. device performance issues, inability to use features you'd find useful e.g. SEND. 4. you use a single node address length, and you'll have to move to variable length node addresses, because the IPv6 address space ends up not being as big as it was designed and calculated to be. Ideally, situations one 1. or 2. will occur, as they're the least costly. 1. is both initially and operationally slightly more costly than 2. as you'll also have to also accurately manage prefix lengths, and consider and/or address other non-/64 issues identified in RFC3627, which I think makes 2. the better choice. The question is, which of those two has the least risk of devolving into the corresponding 3. or 4? As the addressing architecture documents for IPv6 currently state that for other than addresses that start with binary 000, the interface ID are required to be 64 bits in length, it seems to me that situation 2. is the least risky and least likely to devolve into situation 4. Vendors/developers using RFCs as authoritative IPV6 documents are going to assume /64s, as are future protocol developers. > -brandon > > On 1/23/10, Larry Sheldon wrote: > > On 1/23/2010 8:24 PM, Owen DeLong wrote: > >> On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: > >>> In reference to the discussion about /31 for router links, I d'like > >>> to know what is your experience with IPv6 in this regard. > >>> > >>> I use a /126 if possible but have also configured one /64 just for > >>> the link between two routers. This works great but when I think > >>> that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > >>> > >>> So what do you think? Good? Bad? Ugly? /127 ? ;) > >>> > >> Use the /64... It's OK... IPv6 was designed with that in mind. > >> > >> 64 bits is enough networks that if each network was an almond M&M, > >> you would be able to fill all of the great lakes with M&Ms before you > >> ran out of /64s. > > > > Did somebody once say something like that about Class C addresses? > > > > > > -- > > "Government big enough to supply everything you need is big enough to > > take everything you have." > > > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > > > Requiescas in pace o email > > Ex turpi causa non oritur actio > > Eppure si rinfresca > > > > ICBM Targeting Information: http://tinyurl.com/4sqczs > > http://tinyurl.com/7tp8ml > > > > > > > > > -- > Brandon Galbraith > Mobile: 630.400.6992 > FNAL: 630.840.2141 > From owen at delong.com Sat Jan 23 21:51:05 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Jan 2010 19:51:05 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <20100124133650.6575360a@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <366100671001231855n19d31d50l4953a25be0910546@mail.gmail.com> <20100124133650.6575360a@opy.nosense.org> Message-ID: That's why we have the safety valve... 2000::/3 is the total address space being issued currently. So, if we discover that there aren't enough /64s like we currently think there are, then, before we start issuing from 4000::/3, we can have a new address plan for that address space while leaving the 2000::/3 in it's current state of 1, or, ideally, 2. Owen On Jan 23, 2010, at 7:06 PM, Mark Smith wrote: > On Sat, 23 Jan 2010 20:55:52 -0600 > Brandon Galbraith wrote: > >> Sometimes good enough > perfect >> >> Never know what is going to come along to turn your addressing plan on its head. >> > > > It seems to me that what this really is about is trying to be in the > best position in the future. I think mainly it's about trying to avoid > unexpected and future renumbering/change of prefix length costs. > > Possible positions or situations are : > > 1. you use a variety of node address lengths across your network, and > there are no future consequences - everything works and continues to > work > > 2. you use a single node address length (i.e. /64) across your network, > and there are no future consequences - everything works and continues > to work > > 3. you use a variety of node address lengths, and you'll have to > renumber to /64s, because you encounter unacceptable issues e.g. > device performance issues, inability to use features you'd find useful > e.g. SEND. > > 4. you use a single node address length, and you'll have to move to > variable length node addresses, because the IPv6 address space ends up > not being as big as it was designed and calculated to be. > > > Ideally, situations one 1. or 2. will occur, as they're the least > costly. 1. is both initially and operationally slightly more costly than > 2. as you'll also have to also accurately manage prefix lengths, and > consider and/or address other non-/64 issues identified in RFC3627, > which I think makes 2. the better choice. > > The question is, which of those two has the least risk of > devolving into the corresponding 3. or 4? As the addressing > architecture documents for IPv6 currently state that for other than > addresses that start with binary 000, the interface ID are required to > be 64 bits in length, it seems to me that situation 2. is the least > risky and least likely to devolve into situation 4. Vendors/developers > using RFCs as authoritative IPV6 documents are going to assume /64s, as > are future protocol developers. > > >> -brandon >> >> On 1/23/10, Larry Sheldon wrote: >>> On 1/23/2010 8:24 PM, Owen DeLong wrote: >>>> On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: >>>>> In reference to the discussion about /31 for router links, I d'like >>>>> to know what is your experience with IPv6 in this regard. >>>>> >>>>> I use a /126 if possible but have also configured one /64 just for >>>>> the link between two routers. This works great but when I think >>>>> that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>>>> >>>>> So what do you think? Good? Bad? Ugly? /127 ? ;) >>>>> >>>> Use the /64... It's OK... IPv6 was designed with that in mind. >>>> >>>> 64 bits is enough networks that if each network was an almond M&M, >>>> you would be able to fill all of the great lakes with M&Ms before you >>>> ran out of /64s. >>> >>> Did somebody once say something like that about Class C addresses? >>> >>> >>> -- >>> "Government big enough to supply everything you need is big enough to >>> take everything you have." >>> >>> Remember: The Ark was built by amateurs, the Titanic by professionals. >>> >>> Requiescas in pace o email >>> Ex turpi causa non oritur actio >>> Eppure si rinfresca >>> >>> ICBM Targeting Information: http://tinyurl.com/4sqczs >>> http://tinyurl.com/7tp8ml >>> >>> >>> >> >> >> -- >> Brandon Galbraith >> Mobile: 630.400.6992 >> FNAL: 630.840.2141 >> From LarrySheldon at cox.net Sat Jan 23 22:04:31 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 23 Jan 2010 22:04:31 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> Message-ID: <4B5BC6CF.8050009@cox.net> On 1/23/2010 9:47 PM, Owen DeLong wrote: >>> 64 bits is enough networks that if each network was an almond M&M, >>> you would be able to fill all of the great lakes with M&Ms before you >>> ran out of /64s. >> >> Did somebody once say something like that about Class C addresses? >> > The number of /24s in all of IPv4 would only cover 70 yards of a football > field (in a single layer of M&Ms). Compared to the filling the > three-dimensional full volume of all 5 great lakes, I am hoping you can > see the vast difference in the comparison. Of course--I was asking about the metaphorical message implying "More than we can imagine ever needing". I remember a day when 18 was the largest number of computers that would ever be needed. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From bicknell at ufp.org Sat Jan 23 22:28:21 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 23 Jan 2010 20:28:21 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: <20100124042821.GA25165@ussenterprise.ufp.org> In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote: > I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > > So what do you think? Good? Bad? Ugly? /127 ? ;) I have used /126's, /127's, and others, based on peers preference. I personally have a fondness for /112's, as it gives you more than 2 addresses, and a DNS bit boundary. For all the pontification about how there are enough /64's to number all the grains of sand, or other nonsense, I think that ignores too much operational information. rDNS is important, and becomes harder in IPv6. Making it easier is importnat. Having a scan of a /64 fill your P2P T1 is poor design, all because you assigned 2^64 addresses to a link that will never have more than 2 functional devices. Most importantly, we should not let any vendor code any of these into software or silicon, in case we need to change later. -- 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: 826 bytes Desc: not available URL: From damian at google.com Sat Jan 23 22:37:22 2010 From: damian at google.com (Damian Menscher) Date: Sat, 23 Jan 2010 20:37:22 -0800 Subject: Anyone see a game changer here? In-Reply-To: <4B5920EB.9070404@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> Message-ID: <6c98f4061001232037hcef6dcfu8126acf09d76118a@mail.gmail.com> On Thu, Jan 21, 2010 at 7:52 PM, Gadi Evron wrote: > I just wrote a blog on the subject called "the fog of cyberwar": > http://darkreading.com/blog/archives/2010/01/fog_of_cyberwar.html > > In short: > While we are all talking of Google's morals and US/China diplomacy, there > are some questions that mostly remain unasked: > > 1. Did Google hack a Taiwanese server to investigate the breach? If so, good > for them. Our ethics need to catch up to our morals, as we usually wake up > to a new world others created for us, a few years too late. But, for now, > it's still illegal so some details would be nice. >From your blog post: "While reporting is vague, Google has supposedly broken into a server in Taiwan (unless information of working through Taiwanese authorities, or that someone else has done this for Google, becomes available)." So... you're taking incomplete information hyped up by "tech" reporters operating based on leaks from people tangential to an investigation as fact, and deciding that if Google doesn't tell you the details of an ongoing criminal investigation that you'll assume they broke the law. Damian -- Damian Menscher :: Security Reliability Engineer :: Google From ge at linuxbox.org Sat Jan 23 23:20:45 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 24 Jan 2010 07:20:45 +0200 Subject: Anyone see a game changer here? In-Reply-To: <6c98f4061001232037hcef6dcfu8126acf09d76118a@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6c98f4061001232037hcef6dcfu8126acf09d76118a@mail.gmail.com> Message-ID: <4B5BD8AD.7060605@linuxbox.org> On 1/24/10 6:37 AM, Damian Menscher wrote: > So... you're taking incomplete information hyped up by "tech" > reporters operating based on leaks from people tangential to an > investigation as fact, and deciding that if Google doesn't tell you > the details of an ongoing criminal investigation that you'll assume > they broke the law. > No. I write there's incomplete information, mention what possibly happened, what alternatives exist, and ask for more data. Yes, if Google did do it, I support the move. Do you have new information to kill speculation, or should these "tech" reporters keep at it? Gadi. From ge at linuxbox.org Sat Jan 23 23:49:18 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 24 Jan 2010 07:49:18 +0200 Subject: Anyone see a game changer here? In-Reply-To: <4B5BD8AD.7060605@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6c98f4061001232037hcef6dcfu8126acf09d76118a@mail.gmail.com> <4B5BD8AD.7060605@linuxbox.org> Message-ID: <4B5BDF5E.2050307@linuxbox.org> On 1/24/10 7:20 AM, Gadi Evron wrote: > On 1/24/10 6:37 AM, Damian Menscher wrote: >> So... you're taking incomplete information hyped up by "tech" >> reporters operating based on leaks from people tangential to an >> investigation as fact, and deciding that if Google doesn't tell you >> the details of an ongoing criminal investigation that you'll assume >> they broke the law. >> > > No. I write there's incomplete information, mention what possibly > happened, what alternatives exist, and ask for more data. To illustrate, you quoted: "While reporting is vague, Google has supposedly broken into a server in Taiwan (unless information of working through Taiwanese authorities, or that someone else has done this for Google, becomes available)." The paragraph continues, with: "If this happened, ..." I hope this solves any misunderstanding. Gadi. From damian at google.com Sat Jan 23 23:48:30 2010 From: damian at google.com (Damian Menscher) Date: Sat, 23 Jan 2010 21:48:30 -0800 Subject: Anyone see a game changer here? In-Reply-To: <4B5BD8AD.7060605@linuxbox.org> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6c98f4061001232037hcef6dcfu8126acf09d76118a@mail.gmail.com> <4B5BD8AD.7060605@linuxbox.org> Message-ID: <6c98f4061001232148k2216bb5ap6693bc0bb997920@mail.gmail.com> On Sat, Jan 23, 2010 at 9:20 PM, Gadi Evron wrote: > On 1/24/10 6:37 AM, Damian Menscher wrote: >> >> So... you're taking incomplete information hyped up by "tech" >> reporters operating based on leaks from people tangential to an >> investigation as fact, and deciding that if Google doesn't tell you >> the details of an ongoing criminal investigation that you'll assume >> they broke the law. > > No. I write there's incomplete information, mention what possibly happened, > what alternatives exist, and ask for more data. > > Yes, if Google did do it, I support the move. > > Do you have new information to kill speculation, or should these "tech" > reporters keep at it? Nobody who knows anything is going to say anything, as this is an ongoing criminal investigation. I'm afraid I'll have to leave you to your speculation. Damian -- Damian Menscher :: Security Reliability Engineer :: Google From jan at whatsapp.com Sun Jan 24 01:40:55 2010 From: jan at whatsapp.com (Jan Koum) Date: Sat, 23 Jan 2010 23:40:55 -0800 Subject: looking for Rogers Wireless DNS contact Message-ID: <7c29a2a41001232340w5fc74a4dt8b7693672ade37c0@mail.gmail.com> hi there, looks like Rogers Wireless is the only mobile carrier in the world that does not want to resolve our server hostname correctly. anybody from Rogers Wireless here who can help or can point me in the right direction? thanks, -- jan From randy at psg.com Sun Jan 24 04:14:51 2010 From: randy at psg.com (Randy Bush) Date: Sun, 24 Jan 2010 19:14:51 +0900 Subject: Anyone see a game changer here? In-Reply-To: <195538697-1264218515-cardhu_decombobulator_blackberry.rim.net-1921741947-@bda609.bisx.prod.on.blackberry> References: <195538697-1264218515-cardhu_decombobulator_blackberry.rim.net-1921741947-@bda609.bisx.prod.on.blackberry> Message-ID: > When did this become slashdot? about 1996 randy From reygue at gmail.com Sun Jan 24 07:47:58 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Sun, 24 Jan 2010 08:47:58 -0500 Subject: Daily Industry and Government call for Commuinications infrastructure (fwd) In-Reply-To: <2106374838.1581485.1264290904146.JavaMail.rim@bda622.bisx.prod.on.blackberry> References: <20100121162814.G22615@psg.com> <9ab36b821001221347u62393fc3h4e141aa5c4a75017@mail.gmail.com> <9ab36b821001221355m7957bf09vc95f94d1788d9e2c@mail.gmail.com> <9ab36b821001221533p7118fa89g5fd7ade08309bf5f@mail.gmail.com> <1172570930.1576787.1264277008849.JavaMail.rim@bda622.bisx.prod.on.blackberry> <9ab36b821001231526o592d1d63r740084ff6c381151@mail.gmail.com> <902514471.1581320.1264290293173.JavaMail.rim@bda622.bisx.prod.on.blackberry> <9ab36b821001231547j1376dbcetb385103b5c5919c5@mail.gmail.com> <2106374838.1581485.1264290904146.JavaMail.rim@bda622.bisx.prod.on.blackberry> Message-ID: <9ab36b821001240547l604e7ff2qebcbc3c06091389a@mail.gmail.com> To all I received yesterday morning from Mr. Montaigne Marcelin, Director of Conatel the aid that has been given by Codetel to help the technicians in the Telecommunications sector: 1. 9 packs of rice 60 Kg 2. 2 packs of beans 60 Kg 3. 2 containers of oil 30 pounds each 4. 4 herring boxes 5. 354 containers of pica pica 6. 2 boxes of plastic spoon 7. 110 packs of water 8. 4 boxes of polystyrene plate 9. 2 packs of maggi 10. 1 pack of salt 11. 4 boxes of tomato pasta 12. 3 rations of bananas 13. 7 packs of spaghetti 14. 4 gallons of hot sauce The distribution of this aid is being coordinated by Napoleon Richard (509-3746-5849) an associates member of the board of AHTIC. This aid is provided to support the needy technicians families while they are making themselves available to work, Thanks to Mr. Edwin San Roman from CODETEL and all of you on the NANOG list that has been pushing for that. Regards Reynold Guerrier Treasurer AHTIC Network Engineer 509-3446-0099 On Sat, Jan 23, 2010 at 6:58 PM, Edwin S. Roman wrote: > Ok > > Enviado desde mi dispositivo BlackBerry? de Claro Dominicana > ------------------------------ > *From: * Reynold Guerrier > *Date: *Sat, 23 Jan 2010 19:47:09 -0400 > *To: *Edwin S. Roman > *Subject: *Re: Daily Industry and Government call for Commuinications > infrastructure (fwd) > > See you in 1 hour. > > Reynold > > On Sat, Jan 23, 2010 at 6:48 PM, Edwin S. Roman wrote: > >> I am in the embassy >> >> Enviado desde mi dispositivo BlackBerry? de Claro Dominicana >> ------------------------------ >> *From: * Reynold Guerrier >> *Date: *Sat, 23 Jan 2010 19:26:32 -0400 >> *To: *Edwin S. Roman >> *Subject: *Re: Daily Industry and Government call for Commuinications >> infrastructure (fwd) >> >> Hi Edwin I just got your message where can we meet? >> >> Reynold >> >> On Sat, Jan 23, 2010 at 3:07 PM, Edwin S. Roman wrote: >> >>> Reynol >>> >>> I am in haiti. Can you contact me >>> >>> Enviado desde mi dispositivo BlackBerry? de Claro Dominicana >>> ------------------------------ >>> *From: * Reynold Guerrier >>> *Date: *Fri, 22 Jan 2010 19:33:46 -0400 >>> *To: *Burton, K Joseph >>> *Cc: *Edwin S. Roman; Steven G. Huter< >>> sghuter at nsrc.org>; Lett, Steven W; Garrity, Wendy SMaj >>> USMC USSOUTHCOM/SC-ES (L); >>> McLaughlin,Anydrew J.; Ferguson, >>> David (ODP/OD); Huang, Zheng (ODP/OD)< >>> zhuang at usaid.gov>; Ross,Alec J; Vint Cerf< >>> vint at google.com>; Jose Dominguez >>> *Subject: *Re: Daily Industry and Government call for Commuinications >>> infrastructure (fwd) >>> >>> I just got Allen on the phone one more time. He let me know that it was a >>> problem with the power supply of this particular OC3. So they just switch to >>> a backup one. >>> >>> Reynold >>> >>> On Fri, Jan 22, 2010 at 5:37 PM, Burton, K Joseph wrote: >>> >>>> Reynold and/or Edwin, could you please advise of what the problem >>>> is? >>>> >>>> Joe Burton, U.S. Department of State, >>>> >>>> ( Detailed to the U.S. Haiti Telecom Task Force) >>>> >>>> >>>> >>>> >>>> >>>> *From:* Reynold Guerrier [mailto:reygue at gmail.com] >>>> *Sent:* Friday, January 22, 2010 4:55 PM >>>> >>>> *To:* Edwin S. Roman >>>> *Cc:* Steven G. Huter; Burton, K Joseph; Lett, Steven W; Garrity, Wendy >>>> S Maj USMC USSOUTHCOM/SC-ES (L); McLaughlin, Anydrew J.; Ferguson, David >>>> (ODP/OD); Huang, Zheng (ODP/OD); Ross, Alec J; Vint Cerf; Jose Dominguez >>>> *Subject:* Re: Daily Industry and Government call for Commuinications >>>> infrastructure (fwd) >>>> >>>> >>>> >>>> Edwin >>>> >>>> I just got Allen Bayard on the phone, he told me he is aware of the >>>> problem. He just arrived in Boutillers Hill he is in touch with Jeremy from >>>> CODETEL. He can be reached at 509-3701-7777. >>>> >>>> Regards >>>> >>>> Reynold >>>> >>>> On Fri, Jan 22, 2010 at 4:47 PM, Reynold Guerrier >>>> wrote: >>>> >>>> Let me call you. >>>> >>>> Reynold >>>> >>>> >>>> >>>> On Fri, Jan 22, 2010 at 4:37 PM, Edwin S. Roman >>>> wrote: >>>> >>>> Reynold : >>>> >>>> >>>> >>>> We need support urgent in Botellier. >>>> >>>> >>>> >>>> I am writing you inmediatelly with the details >>>> >>>> >>>> >>>> Edwin >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From:* Reynold Guerrier [mailto:reygue at gmail.com] >>>> *Sent:* Friday, January 22, 2010 5:35 PM >>>> *To:* Edwin S. Roman >>>> *Cc:* Steven G. Huter; Burton, K Joseph; Lett, Steven W; Garrity, Wendy >>>> S Maj USMC USSOUTHCOM/SC-ES (L); McLaughlin, Anydrew J.; Ferguson, David >>>> (ODP/OD); Huang, Zheng (ODP/OD); Ross, Alec J; Vint Cerf; Jose Dominguez >>>> *Subject:* Re: Daily Industry and Government call for Commuinications >>>> infrastructure (fwd) >>>> >>>> >>>> >>>> HI Edwin >>>> >>>> I just talk to Mr. Montaigne Marcelin, he told me that the aid is being >>>> coordinated and will be distributed on Sunday. He will let me know the exact >>>> hour. >>>> >>>> >>>> Regards >>>> >>>> Reynold >>>> >>>> On Fri, Jan 22, 2010 at 4:07 PM, Edwin S. Roman >>>> wrote: >>>> >>>> Dear Reynold: >>>> >>>> >>>> >>>> I am back tomorrow in Haiti, we keep in touch and coordinate the >>>> delivery of the fuel. >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> Edwin >>>> >>>> >>>> >>>> >>>> >>>> *From:* Reynold Guerrier [mailto:reygue at gmail.com] >>>> *Sent:* Friday, January 22, 2010 3:35 PM >>>> *To:* Edwin S. Roman >>>> *Cc:* Steven G. Huter; Burton, K Joseph; Lett, Steven W; Garrity, Wendy >>>> S Maj USMC USSOUTHCOM/SC-ES (L); McLaughlin, Anydrew J.; Ferguson, David >>>> (ODP/OD); Huang, Zheng (ODP/OD); Ross, Alec J; Vint Cerf; Jose Dominguez >>>> >>>> >>>> *Subject:* Re: Daily Industry and Government call for Commuinications >>>> infrastructure (fwd) >>>> >>>> >>>> >>>> HI Edwin >>>> >>>> I was at the embassy this morning. There was nobody to get me the fuel. >>>> Montaigne is unreachable on the phone. >>>> >>>> Reynold >>>> >>>> On Fri, Jan 22, 2010 at 10:47 AM, Edwin S. Roman >>>> wrote: >>>> >>>> Dear Reynold: >>>> >>>> Have you pick up the fuel from de Dominicanan Embassy? >>>> >>>> Have you contact Marcelin Montagne for the food? >>>> >>>> I am in Dominican republic now. >>>> >>>> Regards >>>> >>>> Edwin >>>> >>>> >>>> -----Original Message----- >>>> From: Reynold Guerrier [mailto:reygue at gmail.com] >>>> >>>> Sent: Thursday, January 21, 2010 2:00 PM >>>> To: Steven G. Huter >>>> Cc: Burton, K Joseph; Lett, Steven W; Garrity, Wendy S Maj USMC >>>> USSOUTHCOM/SC-ES (L); McLaughlin, Anydrew J.; Ferguson, David (ODP/OD); >>>> Huang, Zheng (ODP/OD); Edwin S. Roman; Ross, Alec J; Vint Cerf; Jose >>>> Dominguez >>>> Subject: Re: Daily Industry and Government call for Commuinications >>>> infrastructure (fwd) >>>> >>>> Yes Steve >>>> >>>> Still waiting. >>>> >>>> Reynold >>>> >>>> >>>> On Thu, Jan 21, 2010 at 12:17 PM, Steven G. Huter >>>> wrote: >>>> >>>> >>>> A plea to all copied in this message... >>>> >>>> Reynold has written from Haiti this morning to say that they are >>>> still in need of food and water for the Haitian Internet and communications >>>> technicians, and their families. If they have to spend all of their time >>>> trying to find food, they cannot work on restoring the critical >>>> communications infrastructure so that the rest of the relief and rebuilding >>>> efforts can be more efficient and effective. >>>> >>>> We know there are efforts, but Reynold says it has been to >>>> chaotic for them to do anything other than wait in long lines for one meal >>>> at a time. >>>> >>>> Can someone from State Dept or USAID or Indotel please get in >>>> touch directly with Reynold to coordiante delivering a supply of food to the >>>> Haitian techs ? >>>> >>>> Below Reynold ask for enough food so they can have a supply to >>>> keep and consume for a few days at a time, so they can work and not worry >>>> about finding food each day. >>>> >>>> Thanks to all who are helping in many ways >>>> >>>> Steve Huter, NSRC >>>> http://www.nsrc.org/ >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> Date: Thu, 21 Jan 2010 08:02:09 -0800 >>>> From: Reynold Guerrier >>>> To: Steven G. Huter >>>> Subject: Re: Daily Industry and Government call for >>>> Commuinications >>>> infrastructure >>>> >>>> >>>> Merci Steve >>>> >>>> J'ai vu l'offre de Edwin et j'avais fait chercher de la >>>> nourriture pour les >>>> techniciens hier. Mais la distribution de cette aide est tres >>>> cahotique et >>>> les gens perdent beaucoup de temps pour l'avoir. En plus ils >>>> fournissent de >>>> la nourriture toute cuite au jour le jour. Ce qui demande aux >>>> techniciens de >>>> laisser leur poste et d'aller faire la queue pendant de longues >>>> heures. Ce >>>> qui revient a la meme chose que j'essaie d'eviter. >>>> >>>> Ce serait plus interessant de leur donner des choses qu'ils >>>> peuvent >>>> conserver et consommer en temps et lieu. >>>> >>>> >>>> Sur le terrain, le moral est bon et avec votre aide on gardera le >>>> reseau en >>>> vie. >>>> >>>> Reynold >>>> >>>> >>>> >>>> On Wed, 20 Jan 2010, Reynold Guerrier wrote: >>>> >>>> Good Dave >>>> >>>> >>>> >>>> We'll keep in touch and I will let you. My big >>>> concerns now is to have >>>> food, >>>> water, tents for my technicians and their >>>> families. To keep them on site >>>> and we need to provide them the basic needs for >>>> themselves and their >>>> families. As things are getting worse they might >>>> wanna go to take care of >>>> their families. All you can provide will be good. >>>> >>>> Regards >>>> >>>> Reynold >>>> >>>> On Tue, Jan 19, 2010 at 8:07 PM, Ferguson, David >>>> (ODP/OD) < >>>> dferguson at usaid.gov> wrote: >>>> >>>> Stephane and Reynold, >>>> >>>> >>>> >>>> I expect you are plugged in to these >>>> calls but just in case. There is a >>>> daily call with Government and Industry >>>> that is focused on needs of >>>> service >>>> providers in Haiti that you and others >>>> have. Logistics for transport of >>>> equipment, fuel and other key needs are >>>> covered. If you have anything you >>>> can provide in writing as Andrew requests >>>> below that is great but don't >>>> let >>>> a need go unnoticed if undocumented. Get >>>> it brought up on this call. >>>> >>>> 2pm EDT 800-882-3610, code 8339656# >>>> >>>> >>>> >>>> >>>> Dave Ferguson >>>> Director - Global Development Commons >>>> >>>> office 202-712-4252 >>>> mobile 703-625-6868 >>>> dferguson at usaid.gov >>>> web site: globaldvelopmentcommons.net >>>> >>>> >>>> ------------------------------ >>>> *From:* Andrew McLaughlin [mailto: >>>> andrew.mclaughlin at gmail.com] >>>> *Sent:* Monday, January 18, 2010 11:15 PM >>>> *To:* sbruno at websystems.ht; >>>> reygue at gmail.com; Ferguson, David (ODP/OD) >>>> *Cc:* Steven G. Huter; Jose A. Dominguez; >>>> Andrew McLaughlin >>>> *Subject:* Introduction: USAID >>>> >>>> Stephane and Reynold: >>>> >>>> First, please know that my thoughts are >>>> with you and your families; I >>>> fervently hope that your loved ones are >>>> OK. >>>> >>>> Second, I want to introduce you to Dave >>>> Ferguson from USAID. He is >>>> responsible for matching >>>> Internet/telecom/IT needs with resources and >>>> support from the US. To do that, we need >>>> to know what needs / >>>> requirements >>>> / requests the Haitian ISPs and IXP have. >>>> Please let us know what your >>>> needs are, and we will do whatever we can >>>> to find ways to meet them. >>>> We'd >>>> like to help Multilink, as well as Access >>>> Haiti and the other Haitian >>>> ISPs. >>>> I would assume that there are at least >>>> three needs: (1) additional >>>> backhaul in/out of Haiti, via VSAT or >>>> similar, (2) last-mile wireless >>>> access >>>> points and receivers, and (3) >>>> routing/switching hardware, fuel, etc. >>>> >>>> Third, did the fuel successfully arrive >>>> at Boutillier Hill? >>>> >>>> --andrew >>>> >>>> -- >>>> andrew mclaughlin >>>> andrew.mclaughlin at gmail.com >>>> +1.202.525.6515 >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/22/10 >>>> 03:34:00 >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/22/10 >>>> 03:34:00 >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG - www.avg.com >>>> Version: 9.0.730 / Virus Database: 271.1.1/2638 - Release Date: 01/22/10 >>>> 03:34:00 >>>> >>>> >>>> >>>> -- >>>> >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>>> >>>> >>>> >>>> -- >>>> =================================== >>>> Reynold Guerrier >>>> IT Consultant >>>> 509-3446-0099 >>>> IM: reygue at hotmail.com >>>> Skype: reygji >>>> >>> >>> >>> >>> -- >>> =================================== >>> Reynold Guerrier >>> IT Consultant >>> 509-3446-0099 >>> IM: reygue at hotmail.com >>> Skype: reygji >>> >> >> >> >> -- >> =================================== >> Reynold Guerrier >> IT Consultant >> 509-3446-0099 >> IM: reygue at hotmail.com >> Skype: reygji >> > > > > -- > =================================== > Reynold Guerrier > IT Consultant > 509-3446-0099 > IM: reygue at hotmail.com > Skype: reygji > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From ge at linuxbox.org Sun Jan 24 07:59:25 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 24 Jan 2010 15:59:25 +0200 Subject: Anyone see a game changer here? In-Reply-To: <6c98f4061001232148k2216bb5ap6693bc0bb997920@mail.gmail.com> References: <775e001a1001150607m178c58cdscff8587adccb895f@mail.gmail.com> <878BCDA1-59A7-43C2-A219-E6FC58C62364@puck.nether.net> <13BEC81B-F447-4173-9ED9-A55B2EC25241@cs.columbia.edu> <4B5920EB.9070404@linuxbox.org> <6c98f4061001232037hcef6dcfu8126acf09d76118a@mail.gmail.com> <4B5BD8AD.7060605@linuxbox.org> <6c98f4061001232148k2216bb5ap6693bc0bb997920@mail.gmail.com> Message-ID: <4B5C523D.6050706@linuxbox.org> On 1/24/10 7:48 AM, Damian Menscher wrote: > On Sat, Jan 23, 2010 at 9:20 PM, Gadi Evron wrote: >> On 1/24/10 6:37 AM, Damian Menscher wrote: >>> >>> So... you're taking incomplete information hyped up by "tech" >>> reporters operating based on leaks from people tangential to an >>> investigation as fact, and deciding that if Google doesn't tell you >>> the details of an ongoing criminal investigation that you'll assume >>> they broke the law. >> >> No. I write there's incomplete information, mention what possibly happened, >> what alternatives exist, and ask for more data. >> >> Yes, if Google did do it, I support the move. >> >> Do you have new information to kill speculation, or should these "tech" >> reporters keep at it? > > Nobody who knows anything is going to say anything, as this is an > ongoing criminal investigation. I'm afraid I'll have to leave you to > your speculation. Fair enough. > > Damian -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From Valdis.Kletnieks at vt.edu Sun Jan 24 10:03:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 24 Jan 2010 11:03:56 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: Your message of "Sat, 23 Jan 2010 22:04:31 CST." <4B5BC6CF.8050009@cox.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> Message-ID: <4750.1264349036@localhost> On Sat, 23 Jan 2010 22:04:31 CST, Larry Sheldon said: > I remember a day when 18 was the largest number of computers that would > ever be needed. First off, it was 5, not 18. :) Second, there's not much evidence that TJ Watson actually said it. http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote Third, given that IBM had already been shipping accounting units with limited plugboard programmability (the model 405) for almost a decade at that point, it's reasonable to conclude that TJ was intentionally and specifically talking about high-end "if you have to ask you can't afford it" systems. And if you look at the Top500 list now, 65 years years later, it's still true - there's always 2-5 boxes that are *way* out in front, then a cluster in spots 5-20 or so, and then a *really* long tail on the way down to #500. http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4006.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From LarrySheldon at cox.net Sun Jan 24 10:14:18 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 24 Jan 2010 10:14:18 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <4750.1264349036@localhost> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <4750.1264349036@localhost> Message-ID: <4B5C71DA.9090307@cox.net> On 1/24/2010 10:03 AM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 23 Jan 2010 22:04:31 CST, Larry Sheldon said: > >> I remember a day when 18 was the largest number of computers that would >> ever be needed. > > First off, it was 5, not 18. :) > > Second, there's not much evidence that TJ Watson actually said it. > > http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote I think the 18 was a UNIVAC blunder (don't remember who supposedly said it). Given their corporate history, I can believe it, > Third, given that IBM had already been shipping accounting units with limited > plugboard programmability (the model 405) for almost a decade at that point, > it's reasonable to conclude that TJ was intentionally and specifically talking > about high-end "if you have to ask you can't afford it" systems. And if you > look at the Top500 list now, 65 years years later, it's still true - there's > always 2-5 boxes that are *way* out in front, then a cluster in spots 5-20 or > so, and then a *really* long tail on the way down to #500. > > http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4006.html It may surprise some folks to learn that there were several computer makers--IBM was not the first, not the best, and not the stupidest. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From owen at delong.com Sun Jan 24 10:57:17 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 24 Jan 2010 08:57:17 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5BC6CF.8050009@cox.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> Message-ID: <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> On Jan 23, 2010, at 8:04 PM, Larry Sheldon wrote: > On 1/23/2010 9:47 PM, Owen DeLong wrote: > >>>> 64 bits is enough networks that if each network was an almond M&M, >>>> you would be able to fill all of the great lakes with M&Ms before you >>>> ran out of /64s. >>> >>> Did somebody once say something like that about Class C addresses? >>> >> The number of /24s in all of IPv4 would only cover 70 yards of a football >> field (in a single layer of M&Ms). Compared to the filling the >> three-dimensional full volume of all 5 great lakes, I am hoping you can >> see the vast difference in the comparison. > > Of course--I was asking about the metaphorical message implying "More than we can imagine ever needing". > > I remember a day when 18 was the largest number of computers that would ever be needed. > Do not make the mistake of assuming that just because I support using IPv6 as designed (at least for now) I am too young to remember those things myself. While I wasn't born early enough to remember the demand for 18 computers projection of T.J. Watson in the first person, I am quite familiar with the quote and the environment that fostered it. I am also familiar with the history of the internet and it's 8-bit address precursor. Yes, your point about demand expanding beyond expectation is well taken. However, I believe that the scale of the IP address space will accommodate at least a couple of orders of magnitude expansion beyond any anticipated amount of address space demand. Further, the current IPv6 addressing scheme does come with a safety valve if people like me turn out to be wrong. If we're wrong, it will only affect 1/8th of the address space and we can do something different with the other nearly 7/8ths, possibly setting a 5-10 year horizon for renumbering out of the first 1/8th into more condensed addressing schemes so that the original 1/8th isn't wastefully allocated. Finally, we come to another key difference between IPv4 and IPv6 which is one of its best features and one of the things that has created the greatest controversy among legacy IPv4 holders. There is no IPv6 globally routable unicast space which is not issued by an RIR under contract with the recipient. Unlike in IPv4 where the ability to reclaim addresses (whether abandoned, underutilized, or otherwise) is murky at best, all IPv6 addresses are subject to a nominal annual fee and a contract which allows the RIRs to maintain proper stewardship over them. If I were designing IPv6 today, would I reserve 1/2 the bits for the host address? No, I wouldn't do that. However, I do think there is benefit to a fixed-sized host field. However, the design we have is the design we have. It's too late to make fundamental changes prior to deployment. Stack implementations all have the ability to adapt to non-fixed-size networks if necessary down the road, but, for now, /64s are the best way to avoid surprises and move forward. Owen > -- > "Government big enough to supply everything you need is big enough to take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 24 15:45:19 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 25 Jan 2010 08:15:19 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> Message-ID: <20100125081519.7be21cda@opy.nosense.org> On Sun, 24 Jan 2010 08:57:17 -0800 Owen DeLong wrote: > > On Jan 23, 2010, at 8:04 PM, Larry Sheldon wrote: > > > On 1/23/2010 9:47 PM, Owen DeLong wrote: > > > >>>> 64 bits is enough networks that if each network was an almond M&M, > >>>> you would be able to fill all of the great lakes with M&Ms before you > >>>> ran out of /64s. > >>> > >>> Did somebody once say something like that about Class C addresses? > >>> > >> The number of /24s in all of IPv4 would only cover 70 yards of a football > >> field (in a single layer of M&Ms). Compared to the filling the > >> three-dimensional full volume of all 5 great lakes, I am hoping you can > >> see the vast difference in the comparison. > > > > Of course--I was asking about the metaphorical message implying "More than we can imagine ever needing". > > > > I remember a day when 18 was the largest number of computers that would ever be needed. > > > Do not make the mistake of assuming that just because I support using IPv6 > as designed (at least for now) I am too young to remember those things myself. > > While I wasn't born early enough to remember the demand for 18 computers > projection of T.J. Watson in the first person, I am quite familiar with the quote > and the environment that fostered it. I am also familiar with the history of > the internet and it's 8-bit address precursor. > > Yes, your point about demand expanding beyond expectation is well taken. > However, I believe that the scale of the IP address space will accommodate > at least a couple of orders of magnitude expansion beyond any anticipated > amount of address space demand. Further, the current IPv6 addressing > scheme does come with a safety valve if people like me turn out to be wrong. > If we're wrong, it will only affect 1/8th of the address space and we can do > something different with the other nearly 7/8ths, possibly setting a 5-10 year > horizon for renumbering out of the first 1/8th into more condensed addressing > schemes so that the original 1/8th isn't wastefully allocated. > > Finally, we come to another key difference between IPv4 and IPv6 which > is one of its best features and one of the things that has created the greatest > controversy among legacy IPv4 holders. There is no IPv6 globally routable > unicast space which is not issued by an RIR under contract with the recipient. > Unlike in IPv4 where the ability to reclaim addresses (whether abandoned, > underutilized, or otherwise) is murky at best, all IPv6 addresses are subject > to a nominal annual fee and a contract which allows the RIRs to maintain > proper stewardship over them. > > If I were designing IPv6 today, would I reserve 1/2 the bits for the host > address? No, I wouldn't do that. Actually, from what Christian Huitema says in his "IPv6: The New Internet Protocol" book, the original IPv6 address size was 64 bits, derived from Steve Deering's Simple Internet Protocol proposal. IIRC, they doubled it to 128 bits to specifically have 64 bits as the host portion, to allow for autoconfiguration. > However, I do think there is benefit > to a fixed-sized host field. However, the design we have is the design > we have. It's too late to make fundamental changes prior to deployment. > Stack implementations all have the ability to adapt to non-fixed-size > networks if necessary down the road, but, for now, /64s are the > best way to avoid surprises and move forward. > > Owen > > > -- > > "Government big enough to supply everything you need is big enough to take everything you have." > > > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > > > Requiescas in pace o email > > Ex turpi causa non oritur actio > > Eppure si rinfresca > > > > ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml > > > > From smb at cs.columbia.edu Sun Jan 24 16:01:21 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 24 Jan 2010 17:01:21 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100125081519.7be21cda@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> <20100125081519.7be21cda@opy.nosense.org> Message-ID: <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> On Jan 24, 2010, at 4:45 PM, Mark Smith wrote: > > Actually, from what Christian Huitema says in his "IPv6: The New > Internet Protocol" book, the original IPv6 address size was 64 bits, > derived from Steve Deering's Simple Internet Protocol proposal. > IIRC, they doubled it to 128 bits to specifically have 64 bits as the > host portion, to allow for autoconfiguration. Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128. During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the "Big 10" design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember; SIPP was the heir apparent at that point. Scott and I pushed back, saying that 64 bits was too few to allow for both growth and for innovative uses of the address. We offered 128 bits as a compromise; it was accepted, albeit grudgingly. The stateless autoconfig design came later. --Steve Bellovin, http://www.cs.columbia.edu/~smb From andy at nosignal.org Sun Jan 24 16:04:55 2010 From: andy at nosignal.org (Andy Davidson) Date: Sun, 24 Jan 2010 22:04:55 +0000 Subject: Best Practices - BGP community to signal transit announces. In-Reply-To: <4B5B371B.3000301@freebsdbrasil.com.br> References: <4B5B371B.3000301@freebsdbrasil.com.br> Message-ID: <4B5CC407.9030700@nosignal.org> On 23/01/2010 17:51, Patrick Tracanelli wrote: > I am acting as transit for a number of ASNs, and my upstream peers do > filter my announces (as they should as I understand). Absolutely. > Is there any best practices or RFC which shall suggest how this > community should be set up? Say, while I do standardize this community > to be MY-ASN:1 or MY-ASN:65501, is there a difference? Which community > numbers should be used for this purpose, if there are any best practice > for this? This is a really bad idea, if you tag your customers' prefixes with a 'do transit' community, then the customer leaks, you will tag the extra prefixes, and leak via your transit too. You must filter your customers based on the data that they put into an agreed RPSL database, and then your transit provider should filter you on the same basis. Some people shuffle static prefix lists to negotiate their prefix filters. Life is too short for this though. Let computers and databases do the work for you. Andy Davidson // www.netsumo.com From Valdis.Kletnieks at vt.edu Sun Jan 24 17:26:14 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 24 Jan 2010 18:26:14 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: Your message of "Sun, 24 Jan 2010 17:01:21 EST." <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> <20100125081519.7be21cda@opy.nosense.org> <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> Message-ID: <31219.1264375574@localhost> On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: > Actually, Scott Bradner and I share most of the credit (or blame) for > the change from 64 bits to 128. > > During the days of the IPng directorate, quite a number of different > alternatives were considered. At one point, there was a compromise > proposal known as the "Big 10" design, because it was propounded at the > Big Ten Conference Center near O'Hare. One feature of it was addresses > of length 64, 128, 192, or 256 bits, determined by the high-order two > bits. That deal fell apart for reasons I no longer remember; I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses ("What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17?" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From smb at cs.columbia.edu Sun Jan 24 17:41:18 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 24 Jan 2010 18:41:18 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <31219.1264375574@localhost> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> <20100125081519.7be21cda@opy.nosense.org> <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> <31219.1264375574@localhost> Message-ID: On Jan 24, 2010, at 6:26 PM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: > >> Actually, Scott Bradner and I share most of the credit (or blame) for >> the change from 64 bits to 128. >> >> During the days of the IPng directorate, quite a number of different >> alternatives were considered. At one point, there was a compromise >> proposal known as the "Big 10" design, because it was propounded at the >> Big Ten Conference Center near O'Hare. One feature of it was addresses >> of length 64, 128, 192, or 256 bits, determined by the high-order two >> bits. That deal fell apart for reasons I no longer remember; > > I don't remember the details of Big 10, but I do remember the general objection > to variable-length addresses (cf. some of the OSI-influenced schemes) was the > perceived difficulty of building an ASIC to do hardware handling of the > address fields at line rate. Or was Big 10 itself the compromise to avoid > dealing with variable-length NSAP-style addresses ("What do you mean, the > address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, > and 17?" :) Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes. But my goal is not to revisit the design issues, but rather to clarify the historical record. --Steve Bellovin, http://www.cs.columbia.edu/~smb From woody at pch.net Sun Jan 24 17:53:27 2010 From: woody at pch.net (Bill Woodcock) Date: Sun, 24 Jan 2010 15:53:27 -0800 Subject: Status as of Friday COB @ Boutillers, Port au Prince, Haiti In-Reply-To: <4B5B26B8.7030009@abenaki.wabanaki.net> References: <4B5B26B8.7030009@abenaki.wabanaki.net> Message-ID: <485E1697-1A8A-4443-A9B2-C3D482BD5C56@pch.net> On Jan 23, 2010, at 8:41 AM, Eric Brunner-Williams wrote: > Reginald Chauvet, the owner of the Data Center in Boutillers, in which the .ht Country Code registry is a tenant, has left Haiti with his family. All the critical telecom infrastructures are located at the Data Center in Boutillers. Note that the servers that master the .HT domain are located in Sydney, Australia, in the CoCCA datacenter, and have been (and continue to be) continuously available. The general business operations of the registry are presumably still on hold, but the .HT domain administrators and those of us operating the publicly-visible .HT servers arrived at a process for making any necessary updates to delegations and nameserver records for second-level domains quite some time ago, so there's no operational impact here. The .HT domain has been continuously functional throughout this affair. -Bill -------------- 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 nanog at daork.net Sun Jan 24 18:29:21 2010 From: nanog at daork.net (Nathan Ward) Date: Mon, 25 Jan 2010 13:29:21 +1300 Subject: Using /126 for IPv6 router links In-Reply-To: <20100124042821.GA25165@ussenterprise.ufp.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <20100124042821.GA25165@ussenterprise.ufp.org> Message-ID: On 24/01/2010, at 5:28 PM, Leo Bicknell wrote: > In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote: >> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >> >> So what do you think? Good? Bad? Ugly? /127 ? ;) > > I have used /126's, /127's, and others, based on peers preference. > > I personally have a fondness for /112's, as it gives you more than > 2 addresses, and a DNS bit boundary. > > For all the pontification about how there are enough /64's to number > all the grains of sand, or other nonsense, I think that ignores too > much operational information. > > rDNS is important, and becomes harder in IPv6. Making it easier > is importnat. > > Having a scan of a /64 fill your P2P T1 is poor design, all because > you assigned 2^64 addresses to a link that will never have more > than 2 functional devices. > > Most importantly, we should not let any vendor code any of these > into software or silicon, in case we need to change later. I too prefer /112s. I can take the first /64 in any assignment or allocation and set it aside for networking infrastructure. The first /112 is for loopbacks, the remaining /112s are for linknets. Then I can filter this /64 at my border, and it's easy. You can do the same thing with /64 linknets, but then you have to set aside a block of them, and that might get hard if you have a /48 or something. Maybe not. What if you have a /56? Maybe there is some value in linknets being effectively disposable so you never have to worry about problems coming from re-use. A single /64 full of /112s gives you 281 trillion. For links to customers and other networks, I like /64s, because they are right now the standard so you're not going to run in to compatibility problems. If you've got links to customers you should have a /32, so setting aside a /48 or a /44 or something for those customer links is no huge drama. -- Nathan Ward From gdt at gdt.id.au Sun Jan 24 18:42:04 2010 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 25 Jan 2010 11:12:04 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: <4B5CE8DC.7040308@gdt.id.au> On 24/01/10 12:54, Owen DeLong wrote: > Use the /64... It's OK... IPv6 was designed with that in mind. I'd suggest using a /126. For two reasons. 1) Using EUI-64 addresses on router-router links is an error, the consequences of which you encounter the first time you replace some faulty hardware.[1] I have made this error :-( If you are not using EUI-64 then assigning a non-autoconf /64 is no less or more work than assigning a non-autoconf /126. 2) Having a block of addresses for router-router links (and other blocks for other infrastructure such as loopbacks and unicast) makes ACLs much simpler. Using a /126 means that this block can last for a long, long time, reducing configuration maintenance. Cheers, Glen [1] Basically, interface addresses end up scattered through the router's configuration (some manufacturers are better than others in this regard). Tracking down all the references to an address and changing the config merely as the result of a hardware swap is painful and adds complexity at a time when it is not desired. -- Glen Turner Network Engineer Australia's Academic & Research Network From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 24 19:22:38 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 25 Jan 2010 11:52:38 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> <20100125081519.7be21cda@opy.nosense.org> <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> <31219.1264375574@localhost> Message-ID: <20100125115238.6482c3e1@opy.nosense.org> On Sun, 24 Jan 2010 18:41:18 -0500 Steven Bellovin wrote: > > On Jan 24, 2010, at 6:26 PM, Valdis.Kletnieks at vt.edu wrote: > > > On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said: > > > >> Actually, Scott Bradner and I share most of the credit (or blame) for > >> the change from 64 bits to 128. > >> > >> During the days of the IPng directorate, quite a number of different > >> alternatives were considered. At one point, there was a compromise > >> proposal known as the "Big 10" design, because it was propounded at the > >> Big Ten Conference Center near O'Hare. One feature of it was addresses > >> of length 64, 128, 192, or 256 bits, determined by the high-order two > >> bits. That deal fell apart for reasons I no longer remember; > > > > I don't remember the details of Big 10, but I do remember the general objection > > to variable-length addresses (cf. some of the OSI-influenced schemes) was the > > perceived difficulty of building an ASIC to do hardware handling of the > > address fields at line rate. Or was Big 10 itself the compromise to avoid > > dealing with variable-length NSAP-style addresses ("What do you mean, the > > address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, > > and 17?" :) > > Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes. > > But my goal is not to revisit the design issues, but rather to clarify the historical record. > I think there's a lot of value in knowing why things are the way they are. It's common enough to see things that at face value appear to be overly complicated e.g. classes or subnets in IPv4 compared to IPX's simple, flat network numbers, or appear unrealistic or "ridiculous" like IPv6's 128 bit addresses. However I've found once I know the problem that was trying to be solved, and what options there were to solve it, I then usually understand why the particular solution was chosen, and most of the time agree with it. The value I got out of Christian's book was not the going through the mechanisms of IPv6, but his perspective on what options there were to solve certain options, and why the choices were made. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jan 24 19:54:22 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 25 Jan 2010 12:24:22 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5CE8DC.7040308@gdt.id.au> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5CE8DC.7040308@gdt.id.au> Message-ID: <20100125122422.77cc642c@opy.nosense.org> On Mon, 25 Jan 2010 11:12:04 +1030 Glen Turner wrote: > On 24/01/10 12:54, Owen DeLong wrote: > > Use the /64... It's OK... IPv6 was designed with that in mind. > > I'd suggest using a /126. For two reasons. > > 1) Using EUI-64 addresses on router-router links is an error, the > consequences of which you encounter the first time you replace > some faulty hardware.[1] I have made this error :-( If you > are not using EUI-64 then assigning a non-autoconf /64 is no > less or more work than assigning a non-autoconf /126. > So all that's really saying is that you shouldn't use node addresses derived from link layer addresses, due to the risk of them changing when you swap out an interface, which makes sense. I don't think that argument really supports not using /64s though, as ::1/64 and ::2/64 would achieve that too. > 2) Having a block of addresses for router-router links (and other blocks > for other infrastructure such as loopbacks and unicast) makes ACLs > much simpler. Using a /126 means that this block can last for a long, > long time, reducing configuration maintenance. > With a /48, the recommended size for an end-site, giving you 65 536 subnets, you could reserve the top quarter 16 384 subnets for your point to point links and loopbacks (or split that in half to separate loopbacks and p-to-p links), and then cover them with ACL them with :c000::/50, and still have 49 152 subnets for your edge/services LANs. Regards, Mark. > Cheers, Glen > > [1] Basically, interface addresses end up scattered through the > router's configuration (some manufacturers are better than > others in this regard). Tracking down all the references to > an address and changing the config merely as the result of a > hardware swap is painful and adds complexity at a time when > it is not desired. > > -- > Glen Turner > Network Engineer > Australia's Academic & Research Network > From rubensk at gmail.com Sun Jan 24 20:21:51 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 25 Jan 2010 00:21:51 -0200 Subject: Using /126 for IPv6 router links In-Reply-To: <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <1D684EE0-75B5-41D8-802E-9901CC182D61@delong.com> <4B5BC6CF.8050009@cox.net> <23D486B1-102D-4BCC-91DA-70CF6A39A4F3@delong.com> <20100125081519.7be21cda@opy.nosense.org> <44D9B071-0987-45D2-8373-B8D70B41DF41@cs.columbia.edu> Message-ID: <6bb5f5b11001241821t43696c6at2df06016fe6ab39@mail.gmail.com> > During the days of the IPng directorate, quite a number of different alternatives were considered. ?At one point, there was a compromise proposal known as the "Big 10" design, because it was propounded at the Big Ten Conference Center near O'Hare. ?One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. ?That deal fell apart for reasons I no longer remember; SIPP was the heir apparent at that point. ?Scott and I pushed back, saying that 64 bits was too few to allow for both growth and for innovative uses of the address. ?We offered 128 bits as a compromise; it was accepted, albeit grudgingly. ?The stateless autoconfig design came later. > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb This historical record finally made me understand why we have up to /128 prefixes with /128 addresses instead of what would suit best stateless autoconfig: up to /64 prefixes with /128 addresses. Rubens From danny at tcb.net Sun Jan 24 20:30:17 2010 From: danny at tcb.net (Danny McPherson) Date: Sun, 24 Jan 2010 19:30:17 -0700 Subject: DURZ published in root - you ready? Message-ID: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> Figured I'd drop a note here reminding folks of the signed root zone publication timeline, which calls for L root to begin serving a 'DURZ' the "week of 1/25/2010" -- which is now - depending on what timezone you're in: If you've not evaluated the *systemic effects* of a signed root zone in your operating environment (prepped operations and helpdesk staff, your own resolvers, etc..) I'd strongly suggest you do so ASAP. If you're not concerned because you're not signing anything - do note that 'systemic' is the operative word above, as this will impact you, whether you make any explicit changes in your environment or not. G'luck, -danny From jmamodio at gmail.com Sun Jan 24 20:34:07 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 24 Jan 2010 20:34:07 -0600 Subject: DURZ published in root - you ready? In-Reply-To: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> References: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> Message-ID: <202705b1001241834l5b1911bat97ee2130f632f002@mail.gmail.com> Good point, tomorrow/today we'll start seeing what gets broken and hopefully why. Regards. Jorge On Sun, Jan 24, 2010 at 8:30 PM, Danny McPherson wrote: > > Figured I'd drop a note here reminding folks of the > signed root zone publication timeline, which calls for > L root to begin serving a 'DURZ' the "week of 1/25/2010" > -- which is now - depending on what timezone you're in: > > > > If you've not evaluated the *systemic effects* of a signed > root zone in your operating environment (prepped operations > and helpdesk staff, your own resolvers, etc..) I'd strongly > suggest you do so ASAP. > > If you're not concerned because you're not signing anything - > do note that 'systemic' is the operative word above, as this > will impact you, whether you make any explicit changes in > your environment or not. > > G'luck, > > -danny > > From marka at isc.org Sun Jan 24 20:53:52 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 25 Jan 2010 13:53:52 +1100 Subject: DURZ published in root - you ready? In-Reply-To: Your message of "Sun, 24 Jan 2010 20:34:07 MDT." <202705b1001241834l5b1911bat97ee2130f632f002@mail.gmail.com> References: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> <202705b1001241834l5b1911bat97ee2130f632f002@mail.gmail.com> Message-ID: <201001250253.o0P2rqGf093316@drugs.dv.isc.org> In message <202705b1001241834l5b1911bat97ee2130f632f002 at mail.gmail.com>, Jorge Amodio writes: > Good point, tomorrow/today we'll start seeing what gets broken and > hopefully why. > > Regards. > Jorge I don't expect to see much until the last root server (J) switches over. DNS implemententations are remarkably robust at routing around percieved "damage". Week of 2010-05-03: J starts to serve DURZ Mark > On Sun, Jan 24, 2010 at 8:30 PM, Danny McPherson wrote: > > > > Figured I'd drop a note here reminding folks of the > > signed root zone publication timeline, which calls for > > L root to begin serving a 'DURZ' the "week of 1/25/2010" > > -- which is now - depending on what timezone you're in: > > > > > > > > If you've not evaluated the *systemic effects* of a signed > > root zone in your operating environment (prepped operations > > and helpdesk staff, your own resolvers, etc..) I'd strongly > > suggest you do so ASAP. > > > > If you're not concerned because you're not signing anything - > > do note that 'systemic' is the operative word above, as this > > will impact you, whether you make any explicit changes in > > your environment or not. > > > > G'luck, > > > > -danny > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mehmet at icann.org Sun Jan 24 23:09:51 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Sun, 24 Jan 2010 21:09:51 -0800 Subject: DURZ published in root - you ready? In-Reply-To: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> Message-ID: Danny/NANOG'ers L-Root will start serving DURZ 2010-01-27 2000 UTC. Let me know if you have any questions Mehmet Akcin ICANN/L-ROOT On 1/24/10 6:30 PM, "Danny McPherson" wrote: > > Figured I'd drop a note here reminding folks of the > signed root zone publication timeline, which calls for > L root to begin serving a 'DURZ' the "week of 1/25/2010" > -- which is now - depending on what timezone you're in: > > > > If you've not evaluated the *systemic effects* of a signed > root zone in your operating environment (prepped operations > and helpdesk staff, your own resolvers, etc..) I'd strongly > suggest you do so ASAP. > > If you're not concerned because you're not signing anything - > do note that 'systemic' is the operative word above, as this > will impact you, whether you make any explicit changes in > your environment or not. > > G'luck, > > -danny > From jabley at hopcount.ca Mon Jan 25 00:02:19 2010 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 25 Jan 2010 01:02:19 -0500 Subject: DURZ published in root - you ready? In-Reply-To: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> References: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> Message-ID: <1DDEEF0B-238D-46EE-996B-0AA3AF269636@hopcount.ca> On 2010-01-24, at 21:30, Danny McPherson wrote: > Figured I'd drop a note here reminding folks of the > signed root zone publication timeline, which calls for > L root to begin serving a 'DURZ' the "week of 1/25/2010" > -- which is now - depending on what timezone you're in: > > We published more detailed target maintenance windows that we are aiming for in the deployment document () but we'll try to make it easier to find. Here it is: o Group 1, Week beginning Mon 25 Jan 2010: L L: 2010-01-27 1800 UTC -- 2010-01-27 2000 UTC o Group 2, Week beginning Mon 08 Feb 2010: A A: 2010-02-10 1700 UTC -- 2010-02-10 1900 UTC o Group 3, Week beginning Mon 01 Mar 2010: M, I M: 2010-03-03 0400 UTC -- 2010-03-03 0600 UTC I: 2010-03-03 1500 UTC -- 2010-03-03 1800 UTC o Group 4, Week beginning Mon 22 Mar 2010: D, K, E D: 2010-03-24 1400 UTC -- 2010-03-24 1500 UTC K: 2010-03-24 1500 UTC -- 2010-03-24 1700 UTC E: 2010-03-24 1800 UTC -- 2010-03-24 2000 UTC o Group 5, Week beginning Mon 12 Apr 2010: B, H, C, G, F H: 2010-04-14 1400 UTC -- 2010-04-14 1500 UTC C: 2010-04-14 1500 UTC -- 2010-04-14 1700 UTC G: 2010-04-14 1700 UTC -- 2010-04-14 1900 UTC B: 2010-04-14 1900 UTC -- 2010-04-14 2100 UTC F: 2010-04-14 2100 UTC -- 2010-04-15 0000 UTC o Group 6, Week beginning Mon 03 May 2010: J J: 2010-05-05 1700 UTC -- 2010-05-05 1900 UTC Joe From owen at delong.com Mon Jan 25 00:40:20 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 24 Jan 2010 22:40:20 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <20100124042821.GA25165@ussenterprise.ufp.org> Message-ID: <868C2951-08F1-4DD1-BC5B-A89942533EFF@delong.com> On Jan 24, 2010, at 4:29 PM, Nathan Ward wrote: > > On 24/01/2010, at 5:28 PM, Leo Bicknell wrote: > >> In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote: >>> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>> >>> So what do you think? Good? Bad? Ugly? /127 ? ;) >> >> I have used /126's, /127's, and others, based on peers preference. >> >> I personally have a fondness for /112's, as it gives you more than >> 2 addresses, and a DNS bit boundary. >> >> For all the pontification about how there are enough /64's to number >> all the grains of sand, or other nonsense, I think that ignores too >> much operational information. >> >> rDNS is important, and becomes harder in IPv6. Making it easier >> is importnat. >> >> Having a scan of a /64 fill your P2P T1 is poor design, all because >> you assigned 2^64 addresses to a link that will never have more >> than 2 functional devices. >> >> Most importantly, we should not let any vendor code any of these >> into software or silicon, in case we need to change later. > > I too prefer /112s. I can take the first /64 in any assignment or allocation and set it aside for networking infrastructure. > The first /112 is for loopbacks, the remaining /112s are for linknets. > > Then I can filter this /64 at my border, and it's easy. > > You can do the same thing with /64 linknets, but then you have to set aside a block of them, and that might get hard if you have a /48 or something. Maybe not. What if you have a /56? > If you have link nets, you probably shouldn't have just a /48 and you CERTAINLY shouldn't have just a /56. Owen From joe at via.net Mon Jan 25 02:14:04 2010 From: joe at via.net (joe mcguckin) Date: Mon, 25 Jan 2010 00:14:04 -0800 Subject: Foundry CLI manual? In-Reply-To: <20100123162346.GY75640@gerbil.cluepon.net> References: <20100123162346.GY75640@gerbil.cluepon.net> Message-ID: It would be a good idea to have a bug database that accessible to paying support customers. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Jan 23, 2010, at 8:23 AM, Richard A Steenbergen wrote: > On Sat, Jan 23, 2010 at 10:51:57AM -0500, David Hubbard wrote: >> Anyone have the Foundry/Brocade CLI reference PDF >> they could send me? Brocade feels you should have a >> support contract to have a list of commands the >> hardware you purchased offers and I'm having difficulty >> with a oc12 pos module. > > Ironically enough the manuals themselves are accessable without a login, > but the list of manuals is not. You fail to mention which product you're > interested in, so I'm going to take a stab and hope that it's something > current with a pos card like an MLX/XMR. If you're still rocking an old > B2P622, I'd say you're in need of far more help than any manual can > provide. :) > > http://www.foundrynet.com/services/documentation/xmr_user/current/NetIron_04100_ConfigGuide.pdf > http://www.foundrynet.com/services/documentation/xmr_diag/current/NetIronXMR-MLX_04100_DiagnosticRef.pdf > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From michael at rancid.berkeley.edu Mon Jan 25 02:49:22 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Mon, 25 Jan 2010 00:49:22 -0800 Subject: DURZ published in root - you ready? In-Reply-To: <201001250253.o0P2rqGf093316@drugs.dv.isc.org> References: <9C84DBF4-A2E7-4D08-B6D1-DB6FA10DDCE3@tcb.net> <202705b1001241834l5b1911bat97ee2130f632f002@mail.gmail.com> <201001250253.o0P2rqGf093316@drugs.dv.isc.org> Message-ID: <4B5D5B12.70304@rancid.berkeley.edu> On 01/24/10 18:53, Mark Andrews wrote: > In message<202705b1001241834l5b1911bat97ee2130f632f002 at mail.gmail.com>, Jorge Amodio writes: >> Good point, tomorrow/today we'll start seeing what gets broken and >> hopefully why. >> >> Regards. >> Jorge > > I don't expect to see much until the last root server (J) switches > over. DNS implemententations are remarkably robust at routing around > percieved "damage". > > Week of 2010-05-03: J starts to serve DURZ There's some evidence within the traffic to the authoritative servers for the now-signed berkeley.edu zone that answers from the authoritative servers are not being received by certain queriers. These queriers, who are setting DO (and of course EDNS0) in their queries, are retrying the same queries until they reach the one "sacrificial lamb" server that is set to give out minimal answers and limit EDNS0 responses to 512 bytes (thereby frequently triggering failover to TCP for those minimal answers that still exceed 512 bytes). It will be interesting to see how traffic patterns to the various root servers evolve as more servers get the DURZ. Also, I got my first apparently DNSSEC-related "your server is attacking me" notice. It was little more than a log snippet that indicated that a UCB authoritative server was perpetrating a "big bomb" attack on a system behind this firewall. "Big bomb" is a notification from Netgear firewalls and CPE routers. Not sure how much activity the abuse contacts for the various rootops netblocks get, but you'll probably see more. michael From andy at nosignal.org Mon Jan 25 03:12:49 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 25 Jan 2010 09:12:49 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5BB40C.3080206@cox.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> Message-ID: <4B5D6091.1080602@nosignal.org> On 24/01/2010 02:44, Larry Sheldon wrote: > On 1/23/2010 8:24 PM, Owen DeLong wrote: >> 64 bits is enough networks that if each network was an almond M&M, >> you would be able to fill all of the great lakes with M&Ms before you >> ran out of /64s. > Did somebody once say something like that about Class C addresses? No. There are only 2,097,152 Class C networks. Assuming all M&Ms are spheroids of uniform oblate nature, radius major axis=6mm, minor axis=3mm. Volume is (4/3)Pi (Major^2) Minor (http://en.wikipedia.org/wiki/Spheroid#Volume) They will be poured into a great lake of your choice, and we will assume random close packing (agitation mechanisms are probably best discussed off-list) and a (generous, but the article insists) void fraction of 32%. (http://en.wikipedia.org/wiki/Random_close_pack) Volume of m&m = 0.452cm^3, occupies 0.665cm^3. Lake Erie is 484km^3 http://www.epa.gov/glnpo/factsheet.html 1 km^3 = 1,000,000,000,000,000 cm^3 484,000,000,000,000,000 * 0.665 = 321,860,000,000,000,000 m&ms needed to fill this lake. There are 4,294,967,296 /64s in my own /32 allocation. If we only ever use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 /64s. This is enough to fill over seven Lake Eries. The total amount of ipv6 address space is exponentially larger still - I have just looked at 2000::/3 in these maths. THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. ** Can we please now just go ahead and roll out some ipv6 services ? ** Thanks Andy From mpetach at netflight.com Mon Jan 25 03:14:17 2010 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 25 Jan 2010 01:14:17 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> Message-ID: <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler wrote: > Hi > In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. > > I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > > So what do you think? Good? Bad? Ugly? /127 ? ;) > > Cheers > > Mathias Seiler > MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > T +41 61 201 30 90, F +41 61 201 30 99 > mathias.seiler at mironet.ch > www.mironet.ch As I mentioned in my lightning talk at the last NANOG, we reserved a /64 for each PtP link, but configured it as the first /126 out of the /64. That gives us the most flexibility for expanding to the full /64 later if necessary, but prevents us from being victim of the classic v6 neighbor discovery attack that you're prone to if you configure the entire /64 on the link. All someone out on the 'net needs to do is scan up through your address space on the link as quickly as possible, sending single packets at all the non-existent addresses on the link, and watch as your router CPU starts to churn keeping track of all the neighbor discovery messages, state table updates, and incomplete age-outs. With the link configured as a /126, there's a very small limit to the number of neighbor discovery messages, and the amount of state table that needs to be maintained and updated for each PtP link. It seemed like a reasonable approach for us--but there's more than one way to skin this particular cat. Hope this helps! Matt From ras at e-gerbil.net Mon Jan 25 04:45:01 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 25 Jan 2010 04:45:01 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5D6091.1080602@nosignal.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> Message-ID: <20100125104501.GG75640@gerbil.cluepon.net> On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote: > There are 4,294,967,296 /64s in my own /32 allocation. If we only ever > use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 > /64s. This is enough to fill over seven Lake Eries. The total amount > of ipv6 address space is exponentially larger still - I have just looked > at 2000::/3 in these maths. > > THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. Don't get carried away with all of that "IPv6 is huge" math, it quickly deteriorates when you start digging into it. Auto-configuration reduces it from 340282366920938463463374607431768211456 to 18446744073709551616 (that's 0.000000000000000005% of the original 128 bit space). Now as an end user you might get anything ranging from a /56 to a /64, that's only between 1 - 256 IPs, barely a significant increase at all if you were to actually use a /64 for each routed IP rather than as each routed subnet. As a small network you might get a /48, so that even if you gave out /64s to everyone it would be only 16 bits of space for you (the equivalent of getting a class B back in IPv4 land), something like a 8-16 bit improvement over what a similar sized network would have gotten in IPv4. As a bigger ISP you might get a /32, but it's the same thing, only 16 bits of space when you have to give out /48s. All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space (and a lot of prefix bloat for when we start using more than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we can give every molecule an IPv6 address" math of the popular imagination. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ras at e-gerbil.net Mon Jan 25 04:58:26 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 25 Jan 2010 04:58:26 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: <20100125105826.GH75640@gerbil.cluepon.net> On Mon, Jan 25, 2010 at 01:14:17AM -0800, Matthew Petach wrote: > > As I mentioned in my lightning talk at the last NANOG, we reserved a > /64 for each PtP link, but configured it as the first /126 out of the > /64. That gives us the most flexibility for expanding to the full /64 > later if necessary, but prevents us from being victim of the classic > v6 neighbor discovery attack that you're prone to if you configure the > entire /64 on the link. All someone out on the 'net needs to do is > scan up through your address space on the link as quickly as possible, > sending single packets at all the non-existent addresses on the link, > and watch as your router CPU starts to churn keeping track of all the > neighbor discovery messages, state table updates, and incomplete > age-outs. With the link configured as a /126, there's a very small That's an attack vector you have to worry about even today with IPv4 space. There are quite a few vendors who you can make fall over with CPU trying to do arp resolution and/or cam exhaustion just by doing "ip address x.x.x.x/16" as a directly connected block on an Ethernet interface. One redeeming quality to the whole autoconfig thing is it'll do a great job cutting down on port scanning for vulnerabilities on end hosts (or else make the flood of port scanning traffic 2^64 times worse, it remains to be seen I suppose :P). My personal theory is it will result in a black market of buying and selling people's active IPv6 addresses from various website logs and the like, so hax0rs will have something to scan. In a few years time it will probably be popular with end users to periodicially "rotate the shield frequencies" with their final 64 bits, or maybe even use them on a per-transaction basis for extra security. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From stucchi at briantel.com Mon Jan 25 07:20:45 2010 From: stucchi at briantel.com (Massimiliano Stucchi) Date: Mon, 25 Jan 2010 14:20:45 +0100 Subject: Using /31 for router links In-Reply-To: <1001231852.AA23235@ivan.Harhan.ORG> References: <1001231852.AA23235@ivan.Harhan.ORG> Message-ID: <4B5D9AAD.8040601@briantel.com> On 23/01/10 19:52, Michael Sokolov wrote: > Mark Smith wrote: > > As for ATM... The part that totally baffles me about the use of ATM on > xDSL lines is that I have never, ever, ever seen an xDSL line carrying > more than one ATM VC. OK, there may be someone out there who has set up > a configuration like that just for fun, but 99.999% of all ATM'd xDSL > lines out there carry a single PVC at 0*35 or 0*38. It's common practice down here in Italy to have more than one VC. One is used to carry data and the other one is used for VoIP, so that you don't have to do QoS on the data part. Ciao ! -- Massimiliano Stucchi BrianTel Srl stucchi at briantel.com Tel (+39) 039 9669921 | Fax (+39) 02 44417204 I-23807, Merate (Lecco), via Mameli 6 MS16801-RIPE From trejrco at gmail.com Mon Jan 25 08:10:11 2010 From: trejrco at gmail.com (TJ) Date: Mon, 25 Jan 2010 09:10:11 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100125104501.GG75640@gerbil.cluepon.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> Message-ID: <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> Good Morning! > -----Original Message----- > From: Richard A Steenbergen [mailto:ras at e-gerbil.net] > Sent: Monday, January 25, 2010 05:45 > To: Andy Davidson > Cc: nanog at nanog.org > Subject: Re: Using /126 for IPv6 router links > > On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote: > > There are 4,294,967,296 /64s in my own /32 allocation. If we only ever > > use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 > > /64s. This is enough to fill over seven Lake Eries. The total amount > > of ipv6 address space is exponentially larger still - I have just looked > > at 2000::/3 in these maths. > > > > THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. > > Don't get carried away with all of that "IPv6 is huge" math, it quickly > deteriorates when you start digging into it. Auto-configuration reduces > it from 340282366920938463463374607431768211456 to 18446744073709551616 > (that's 0.000000000000000005% of the original 128 bit space). Now as an > end user you might get anything ranging from a /56 to a /64, that's only > between 1 - 256 IPs, barely a significant increase at all if you were to > actually use a /64 for each routed IP rather than as each routed subnet. > As a small network you might get a /48, so that even if you gave out > /64s to everyone it would be only 16 bits of space for you (the > equivalent of getting a class B back in IPv4 land), something like a > 8-16 bit improvement over what a similar sized network would have gotten > in IPv4. As a bigger ISP you might get a /32, but it's the same thing, > only 16 bits of space when you have to give out /48s. All we've really > done is buy ourselves an 8 to 16 bit improvement at every level of > allocation space (and a lot of prefix bloat for when we start using more > than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we > can give every molecule an IPv6 address" math of the popular > imagination. :) While I agree with parts of what you are saying - that using the "simple 2^128" math can be misleading, let's be clear on a few things: *) 2^61 is still very, very big. That is the number of IPv6 network segments available within 2000::/3. *) An end-user should get something between a /48 and a /56, _maybe_ as low as a /60 ... hopefully never a /64. Really. **) Let's call the /48s enterprise assignments, and the /56s home assignments ... ? **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. **) And, using the expected /48-/56, the numbers are really 256-64k subnets. **) Each segment supporting as many hosts as you want it to. Probably nowhere near 2^64, but that isn't the point :). *) _Any_ ISP gets a /32 by default, a "bigger ISP" can readily get more. So, actually, we have 'bought' ourselves much more space. *) The standard registry allocation is a /12. So within the /3 we have 512 of those. Note: We currently have 5 RIRs. *) A /12 yields 20 bits of /32s. So within any given /12, we have ~1M ISPs. *) The "standard ISP /32" can support 64K Enterprises or 16.7M Homes. **) Oh, and if you need more = just ask. *) Even allowing for inefficiency / room to grow / summarization - I think we are good for quite some time. *) And this is just the first /3. Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at every level of allocation space" *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? **) Remembering that the original address space was 'only' 32bits. **) I guess only supporting 256-64k more registries, each of which can support 256-64k more ISPs, each of which can support 256-64k more customers just isn't that useful to you? *) Additionally - the number of IPs per segment, which is not the same as the number of hosts per segment, is much vaster. The quite common IPv4 /24 being analogous to an IPv6 /64 ... /TJ PS - We also get much more multicast space, Which Is Nice(TM). From david.freedman at uk.clara.net Mon Jan 25 08:47:42 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 25 Jan 2010 14:47:42 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <191AA587-4C9C-442F-A2AC-4CCF2CC2001A@arbor.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <498E719C-243D-493F-B38F-3527A57FE966@arbor.net> <6eb799ab1001231507s1b0804c7p7fe974b45252c02@mail.gmail.com> <191AA587-4C9C-442F-A2AC-4CCF2CC2001A@arbor.net> Message-ID: <4B5DAF0E.2090307@uk.clara.net> > The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, Ah, now if only was hadn't deprecated site-local... :) From mathias.seiler at mironet.ch Mon Jan 25 10:14:06 2010 From: mathias.seiler at mironet.ch (Mathias Seiler) Date: Mon, 25 Jan 2010 17:14:06 +0100 Subject: Using /126 for IPv6 router links In-Reply-To: <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary <> You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) - "Waste" of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks - Not on a bit boundary, so more complicated for ACLs and ? - ? rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts /127 Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. On 25 Jan 2010, at 10:14, Matthew Petach wrote: > On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler > wrote: >> Hi >> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >> >> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >> >> So what do you think? Good? Bad? Ugly? /127 ? ;) >> >> Cheers >> >> Mathias Seiler >> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel >> T +41 61 201 30 90, F +41 61 201 30 99 >> mathias.seiler at mironet.ch >> www.mironet.ch > > As I mentioned in my lightning talk at the last NANOG, we reserved a > /64 for each > PtP link, > but configured it as the first /126 out of the /64. That > gives us the most > flexibility for expanding to the full /64 later if necessary, but > prevents us from being > victim of the classic v6 neighbor discovery attack that you're prone > to if you configure > the entire /64 on the link. I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) ) This way the configuration and addressing plan is simple and understandable to anyone. > All someone out on the 'net needs to do > is scan up through > your address space on the link as quickly as possible, sending single packets at > all the non-existent addresses on the link, and watch as your router CPU starts > to churn keeping track of all the neighbor discovery messages, state table > updates, and incomplete age-outs. Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. > With the link configured as a /126, there's > a very small limit to the number of neighbor discovery messages, and the amount > of state table that needs to be maintained and updated for each PtP link. > > It seemed like a reasonable approach for us--but there's more than one way to > skin this particular cat. > > Hope this helps! > Yes it does. Thanks! Mathias Seiler MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel T +41 61 201 30 90, F +41 61 201 30 99 mathias.seiler at mironet.ch www.mironet.ch -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5021 bytes Desc: not available URL: From maddison at lightbound.net Mon Jan 25 10:33:04 2010 From: maddison at lightbound.net (Matt Addison) Date: Mon, 25 Jan 2010 11:33:04 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: > From: Mathias Seiler [mailto:mathias.seiler at mironet.ch] > Subject: Re: Using /126 for IPv6 router links > > Ok let's summarize: > > /64: > + Sticks to the way IPv6 was designed (64 bits host part) > + Probability of renumbering very low > + simpler for ACLs and the like > + rDNS on a bit boundary > > <> You can give your peers funny names, like 2001:db8::dead:beef ;) > > - Prone to attacks (scans, router CPU load) > - "Waste" of addresses > - Peer address needs to be known, impossible to guess with 2^64 > addresses > > > /126 > + Only 4 addresses possible (memorable, not so error-prone at > configuration-time and while debugging) > + Not prone to scan-like attacks > > - Not on a bit boundary, so more complicated for ACLs and ... > - ... rDNS > - Perhaps need to renumber into /64 some time. > - No 64 bits for hosts You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for each PtP link, but only configure the first /126 (or whatever /126 you need to get an amusing peer address) on the link. + Sticks to the way IPv6 was designed (64 bits host part- even if it isn't all configured) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks + Easy to renumber into a /64 if you need to - "Waste" of addresses Seems to be a fairly good compromise, unless there's something I missed. ~Matt From mehmet at icann.org Mon Jan 25 03:56:56 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Mon, 25 Jan 2010 01:56:56 -0800 Subject: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC Message-ID: Hi As part of staged, incremental deployment of DNSSEC in the root zone L-Root will begin serving a Deliberately Unvalidatable Root Zone (DURZ) after the completion of its scheduled maintenance at 2010-01-27 1800 UTC - 2000 UTC Please contact L-Root NOC via noc at dns.icann.org or T: +1.310.301.5817 if you have any questions. Please contact with rootsign at icann.org if you have any questions regarding DNSSEC Deployment at root zone. Regards Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT From bicknell at ufp.org Mon Jan 25 10:42:39 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Jan 2010 08:42:39 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: <20100125164239.GA21885@ussenterprise.ufp.org> In a message written on Mon, Jan 25, 2010 at 05:14:06PM +0100, Mathias Seiler wrote: > Ok let's summarize: > > /64: > + Sticks to the way IPv6 was designed (64 bits host part) > + Probability of renumbering very low > + simpler for ACLs and the like > + rDNS on a bit boundary > > <> You can give your peers funny names, like 2001:db8::dead:beef ;) > > - Prone to attacks (scans, router CPU load) > - "Waste" of addresses > - Peer address needs to be known, impossible to guess with 2^64 addresses /112: + 65535 possible addresses, can use a standardized subnet for everything from a 2 router point to point, to a six address vrrp to vrrp dual router static setup, and beyond. Becomes the universal "edge interface" when the far end is routers not hosts. + rDNS bit boundary++, since it falls on a :. + Limits the effects of scan-like attacks. + Can set aside 1 /64 of /112's for, well, forever. > > > /126 > + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) > + Not prone to scan-like attacks > > - Not on a bit boundary, so more complicated for ACLs and ? > - ? rDNS > - Perhaps need to renumber into /64 some time. > - No 64 bits for hosts > > > /127 > Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. > > > > On 25 Jan 2010, at 10:14, Matthew Petach wrote: > > > On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler > > wrote: > >> Hi > >> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. > >> > >> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > >> > >> So what do you think? Good? Bad? Ugly? /127 ? ;) > >> > >> Cheers > >> > >> Mathias Seiler > >> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > >> T +41 61 201 30 90, F +41 61 201 30 99 > >> mathias.seiler at mironet.ch > >> www.mironet.ch > > > > As I mentioned in my lightning talk at the last NANOG, we reserved a > > /64 for each > > PtP link, > > but configured it as the first /126 out of the /64. That > > gives us the most > > flexibility for expanding to the full /64 later if necessary, but > > prevents us from being > > victim of the classic v6 neighbor discovery attack that you're prone > > to if you configure > > the entire /64 on the link. > > I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". > If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) ) > > This way the configuration and addressing plan is simple and understandable to anyone. > > > All someone out on the 'net needs to do > > is scan up through > > your address space on the link as quickly as possible, sending single packets at > > all the non-existent addresses on the link, and watch as your router CPU starts > > to churn keeping track of all the neighbor discovery messages, state table > > updates, and incomplete age-outs. > > Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. > > > With the link configured as a /126, there's > > a very small limit to the number of neighbor discovery messages, and the amount > > of state table that needs to be maintained and updated for each PtP link. > > > > It seemed like a reasonable approach for us--but there's more than one way to > > skin this particular cat. > > > > Hope this helps! > > > > Yes it does. Thanks! > > > Mathias Seiler > > MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > T +41 61 201 30 90, F +41 61 201 30 99 > > mathias.seiler at mironet.ch > www.mironet.ch > -- 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: 826 bytes Desc: not available URL: From ras at e-gerbil.net Mon Jan 25 11:07:38 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 25 Jan 2010 11:07:38 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> Message-ID: <20100125170738.GI75640@gerbil.cluepon.net> On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: > While I agree with parts of what you are saying - that using the "simple > 2^128" math can be misleading, let's be clear on a few things: > *) 2^61 is still very, very big. That is the number of IPv6 network > segments available within 2000::/3. > *) An end-user should get something between a /48 and a /56, _maybe_ as low > as a /60 ... hopefully never a /64. Really. > **) Let's call the /48s enterprise assignments, and the /56s home > assignments ... ? > **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. It is if we are to follow the "always use a /64 as a single IP" guidelines. Not that I'm encouraging this, I'm just saying this is what we're told to do with the space. I for one have this little protocol called DHCP that does IP assignments along with a bunch of other things that I need anyways, so I'm more than happy to take a single /64 for house as a single lan segment (well, never minding the fact that my house has a /48). > **) And, using the expected /48-/56, the numbers are really 256-64k subnets. ... > Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at > every level of allocation space" > *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? I'm not saying that 8-16 bits isn't an improvement, but it's a far cry from the bazillions of numbers everyone makes IPv6 out to be. By the time you figure in the overhead of autoconfiguration, restrictive initial deployments, and the "now that the space is much bigger, we should be reallocating bigger blocks" logic at every layer of redistribution, that is what you're left with. So far all we've really done with v6 is created a flashback to the days when every end user could get a /24 just by asking, every enterprise could get a /16 just by asking, and every big network could get a /8 just by asking, just bit shifted a little bit. That's all well and good, but it isn't a bazillion. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From trejrco at gmail.com Mon Jan 25 12:01:13 2010 From: trejrco at gmail.com (TJ) Date: Mon, 25 Jan 2010 13:01:13 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100125170738.GI75640@gerbil.cluepon.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> Message-ID: <009901ca9de8$64fff530$2effdf90$@com> > -----Original Message----- > From: Richard A Steenbergen [mailto:ras at e-gerbil.net] > Sent: Monday, January 25, 2010 12:08 > To: TJ > Cc: nanog at nanog.org > Subject: Re: Using /126 for IPv6 router links > > On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: > > While I agree with parts of what you are saying - that using the "simple > > 2^128" math can be misleading, let's be clear on a few things: > > *) 2^61 is still very, very big. That is the number of IPv6 network > > segments available within 2000::/3. > > *) An end-user should get something between a /48 and a /56, _maybe_ as low > > as a /60 ... hopefully never a /64. Really. > > **) Let's call the /48s enterprise assignments, and the /56s home > > assignments ... ? > > **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. > > It is if we are to follow the "always use a /64 as a single IP" > guidelines. Not that I'm encouraging this, I'm just saying this is what > we're told to do with the space. I for one have this little protocol > called DHCP that does IP assignments along with a bunch of other things > that I need anyways, so I'm more than happy to take a single /64 for > house as a single lan segment (well, never minding the fact that my > house has a /48). Interesting. I have never seen anyone say "always use a /64 as a single IP" ... perhaps you mean as an IP segment or link? You are assigned a /64 if it is "known" that you only need one segment, which yields as many IPs as you want (18BillionBillion or so) - and the reality is that a home user should get a /56 and an enterprise should get a /48, at the very least - some would say a /48 per site. > > **) And, using the expected /48-/56, the numbers are really 256-64k subnets. > ... > > Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at > > every level of allocation space" > > *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? > > I'm not saying that 8-16 bits isn't an improvement, but it's a far cry > from the bazillions of numbers everyone makes IPv6 out to be. By the > time you figure in the overhead of autoconfiguration, restrictive > initial deployments, and the "now that the space is much bigger, we > should be reallocating bigger blocks" logic at every layer of > redistribution, that is what you're left with. So far all we've really > done with v6 is created a flashback to the days when every end user > could get a /24 just by asking, every enterprise could get a /16 just by > asking, and every big network could get a /8 just by asking, just bit > shifted a little bit. That's all well and good, but it isn't a > bazillion. :) There are some similarities between IPv6 and old classful addressing, but the bit-boundaries chosen were intentionally made big and specifically factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). The scale of the difference *is* the difference. I am not quite sure what a bazillion is, but when we get into the Billion Billion range I think that is close enough! :) /TJ From LarrySheldon at cox.net Mon Jan 25 12:50:14 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 25 Jan 2010 12:50:14 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <20100125104501.GG75640@gerbil.cluepon.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> Message-ID: <4B5DE7E6.7000200@cox.net> On 1/25/2010 4:45 AM, Richard A Steenbergen wrote: > On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote: >> There are 4,294,967,296 /64s in my own /32 allocation. If we only ever >> use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 >> /64s. This is enough to fill over seven Lake Eries. The total amount >> of ipv6 address space is exponentially larger still - I have just looked >> at 2000::/3 in these maths. >> >> THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. > > Don't get carried away with all of that "IPv6 is huge" math, it quickly > deteriorates when you start digging into it. Auto-configuration reduces > it from 340282366920938463463374607431768211456 to 18446744073709551616 > (that's 0.000000000000000005% of the original 128 bit space). Now as an > end user you might get anything ranging from a /56 to a /64, that's only > between 1 - 256 IPs, barely a significant increase at all if you were to > actually use a /64 for each routed IP rather than as each routed subnet. > As a small network you might get a /48, so that even if you gave out > /64s to everyone it would be only 16 bits of space for you (the > equivalent of getting a class B back in IPv4 land), something like a > 8-16 bit improvement over what a similar sized network would have gotten > in IPv4. As a bigger ISP you might get a /32, but it's the same thing, > only 16 bits of space when you have to give out /48s. All we've really > done is buy ourselves an 8 to 16 bit improvement at every level of > allocation space (and a lot of prefix bloat for when we start using more > than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we > can give every molecule an IPv6 address" math of the popular > imagination. :) And it does not account for the factor that I was trying to shine a light on--the it-is-infinitely-huge is at risk of failing due to inventions we can not conceive of. Who knew, in the 1940's that every person would be assigned as many as five or more telephone numbers (exaggeration? In this house, occupied by two people there are 4 addressable PSTN devices, only one of which leaves the house if one of us does, and there are 6 devices that share an address but could easily have individual addresses, and would if we were using one of the VOIP services). Who knew in the 1980's that refrigerator's would need IP addresses? (We should not have been surprised, Coke machines did.) And for all the concern about IPv4 exhaustion, what would have happened if the people who fought fiercely against RFC 1918 had won the day? Yes the numbers in IPv6 are huge, no doubt about it. But I say, to say "impossible to exhaust" is a fools errand. Somebody will find a way to exhaust the pool, just to be contrary, if for no currently recognized "legitimate" reason. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tdurack at gmail.com Mon Jan 25 13:02:40 2010 From: tdurack at gmail.com (Tim Durack) Date: Mon, 25 Jan 2010 14:02:40 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <009901ca9de8$64fff530$2effdf90$@com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> Message-ID: <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> On Mon, Jan 25, 2010 at 1:01 PM, TJ wrote: >> -----Original Message----- >> From: Richard A Steenbergen [mailto:ras at e-gerbil.net] >> Sent: Monday, January 25, 2010 12:08 >> To: TJ >> Cc: nanog at nanog.org >> Subject: Re: Using /126 for IPv6 router links >> >> On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: >> > While I agree with parts of what you are saying - that using the "simple >> > 2^128" math can be misleading, let's be clear on a few things: >> > *) 2^61 is still very, very big. ?That is the number of IPv6 network >> > segments available within 2000::/3. >> > *) An end-user should get something between a /48 and a /56, _maybe_ as > low >> > as a /60 ... hopefully never a /64. ?Really. >> > **) Let's call the /48s enterprise assignments, and the /56s home >> > assignments ... ? >> > **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. >> >> It is if we are to follow the "always use a /64 as a single IP" >> guidelines. Not that I'm encouraging this, I'm just saying this is what >> we're told to do with the space. I for one have this little protocol >> called DHCP that does IP assignments along with a bunch of other things >> that I need anyways, so I'm more than happy to take a single /64 for >> house as a single lan segment (well, never minding the fact that my >> house has a /48). > > Interesting. ?I have never seen anyone say "always use a /64 as a single IP" > ... perhaps you mean as an IP segment or link? > You are assigned a /64 if it is "known" that you only need one segment, > which yields as many IPs as you want (18BillionBillion or so) - and the > reality is that a home user should get a /56 and an enterprise should get a > /48, at the very least - some would say a /48 per site. > > >> > **) And, using the expected /48-/56, the numbers are really 256-64k > subnets. >> ... >> > Note: "All we've really done is buy ourselves an 8 to 16 bit improvement > at >> > every level of allocation space" >> > *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? >> >> I'm not saying that 8-16 bits isn't an improvement, but it's a far cry >> from the bazillions of numbers everyone makes IPv6 out to be. By the >> time you figure in the overhead of autoconfiguration, restrictive >> initial deployments, and the "now that the space is much bigger, we >> should be reallocating bigger blocks" logic at every layer of >> redistribution, that is what you're left with. So far all we've really >> done with v6 is created a flashback to the days when every end user >> could get a /24 just by asking, every enterprise could get a /16 just by >> asking, and every big network could get a /8 just by asking, just bit >> shifted a little bit. That's all well and good, but it isn't a >> bazillion. :) > > There are some similarities between IPv6 and old classful addressing, but > the bit-boundaries chosen were intentionally made big and specifically > factoring in the then-ongoing scarcity (Ye olde Class B exhaustion). ?The > scale of the difference *is* the difference. ?I am not quite sure what a > bazillion is, but when we get into the Billion Billion range I think that is > close enough! :) > > > /TJ > > > 2^128 is a "very big number." However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a "very big number." An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... -- Tim:> Sent from Brooklyn, NY, United States From hardenrm at uiuc.edu Mon Jan 25 13:23:42 2010 From: hardenrm at uiuc.edu (Ryan Harden) Date: Mon, 25 Jan 2010 13:23:42 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> Message-ID: <4B5DEFBE.3090506@uiuc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Our numbering plan is this: 1) Autoconfigured hosts possible? /64 2) Autoconfigured hosts not-possible, we control both sides? /126 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 4) Loopback? /128 Within our /48 we've carved it into (4) /50s. * First, Infrastructure. This makes ACLs cake. ** Within this /50 are smaller allocations for /126s and /128s and /64s. * Second, User Subnets (16k /64s available) ** All non-infrastructure subnets are assigned from this pool. * Third, Reserved. * Fourth, Reserved. We believe this plan gives us the most flexibility in the future. We made these choices based upon what works the best for us and our tools and not to conserve addresses. Using a single /64 ACL to permit/deny traffic to all ptp at the border was extremely attractive, etc. - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 217-689-1363 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign - AS38 University of Illinois - ICCN - AS40387 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAktd77sACgkQtuPckBBbXbpI1QCcCHBU8XcxqTAKDy4SbElfpH7L VlYAoMkhFKHPeIAXb3vepXYDLdgVAmFA =H3uZ -----END PGP SIGNATURE----- From tdurack at gmail.com Mon Jan 25 13:50:35 2010 From: tdurack at gmail.com (Tim Durack) Date: Mon, 25 Jan 2010 14:50:35 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5DEFBE.3090506@uiuc.edu> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <4B5DEFBE.3090506@uiuc.edu> Message-ID: <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com> On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Our numbering plan is this: > > 1) Autoconfigured hosts possible? /64 > 2) Autoconfigured hosts not-possible, we control both sides? /126 > 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 > 4) Loopback? /128 > > Within our /48 we've carved it into (4) /50s. > * First, Infrastructure. This makes ACLs cake. > ** Within this /50 are smaller allocations for /126s and /128s and /64s. > * Second, User Subnets (16k /64s available) > ** All non-infrastructure subnets are assigned from this pool. > * Third, Reserved. > * Fourth, Reserved. > > We believe this plan gives us the most flexibility in the future. We > made these choices based upon what works the best for us and our tools > and not to conserve addresses. Using a single /64 ACL to permit/deny > traffic to all ptp at the border was extremely attractive, etc. > > - -- This is what we have planned: 2620:0000:xx00::/41 AS-NETx-2620-0-xx00 2620:0000:xx00::/44 Infrastructure 2620:0000:xx01::/48 Pop1 Infrastructure 2620:0000:xx01:0000::/64 Router Loopback (2^64 x /128) 2620:0000:xx01:0001::/64 Transit net (2^48 x /112) 2620:0000:xx01:0002::/64 Server Switch management 2620:0000:xx01:0003::/64 Access Switch management 2620:0000:xx0f::/48 Pop16 Infrastructure 2620:0000:xx10::/44 Sparse Reservation 2620:0000:xx20::/44 Sparse Reservation 2620:0000:xx30::/44 Pop1 Services 2620:0000:xx30::/48 Cust1 Services 2620:0000:xx30:0001::/64 VLAN_1 2620:0000:xx30:4094::/64 VLAN_4094 2620:0000:xx31::/48 Cust2 Services 2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094 2620:0000:xx32::/48 Cust3 Services 2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094 2620:0000:xx32::/48 Cust4 Services 2620:0000:xx31:0001::/64 VLAN_1 2620:0000:xx31:4094::/64 VLAN_4094 2620:0000:xx32::/48 RES-PD-32 (4096 x /60) 2620:0000:xx3f::/48 RES-PD-3f (4096 x /60) 2620:0000:xx40::/44 Pop2 Services 2620:0000:xx50::/44 Pop3 Services 2620:0000:xx60::/44 Pop4 services 2620:0000:xx70::/44 Pop5 Services This is a multiple campus network, customers are all internal. I have had to squeeze Residential PDs down to /60s to make it fit. One Pop is really 3 sites in one. This has had to be massaged into one Pop also. To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s. I'm reasonably happy with the plan, but it doesn't seem to have that much room to grow. -- Tim:> Sent from Brooklyn, NY, United States From trejrco at gmail.com Mon Jan 25 14:15:55 2010 From: trejrco at gmail.com (TJ) Date: Mon, 25 Jan 2010 15:15:55 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> Message-ID: <000001ca9dfb$3599e270$a0cda750$@com> > -----Original Message----- > From: Tim Durack [mailto:tdurack at gmail.com] > Sent: Monday, January 25, 2010 14:03 > To: TJ > Cc: nanog at nanog.org > Subject: Re: Using /126 for IPv6 router links <> > > 2^128 is a "very big number." However, from a network engineering > perspective, IPv6 is really only 64bits of network address space. 2^64 > is still a "very big number." > > An end-user assignment /48 is really only 2^16 networks. That's not > very big once you start planning a human-friendly repeatable number > plan. > > An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. > > Once you start planning a practical address plan, IPv6 isn't as big as > everybody keeps saying... I didn't realize "human friendly" was even a nominal design consideration, especially as different humans have different tolerances for defining "friendly" :) I (continue to) maintain that: *) 2^16 is still a pretty good size number, even allowing for aggregation / summarization. *) If you are large enough that this isn't true - you should (have) request(ed) more, naturally - each bit doubles your space ... /TJ From oberman at es.net Mon Jan 25 14:53:09 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 25 Jan 2010 12:53:09 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: Your message of "Mon, 25 Jan 2010 15:15:55 EST." <000001ca9dfb$3599e270$a0cda750$@com> Message-ID: <20100125205309.867101CC09@ptavv.es.net> > From: "TJ" > Date: Mon, 25 Jan 2010 15:15:55 -0500 > > > -----Original Message----- > > From: Tim Durack [mailto:tdurack at gmail.com] > > Sent: Monday, January 25, 2010 14:03 > > To: TJ > > Cc: nanog at nanog.org > > Subject: Re: Using /126 for IPv6 router links > > <> > > > > > 2^128 is a "very big number." However, from a network engineering > > perspective, IPv6 is really only 64bits of network address space. 2^64 > > is still a "very big number." > > > > An end-user assignment /48 is really only 2^16 networks. That's not > > very big once you start planning a human-friendly repeatable number > > plan. > > > > An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. > > > > Once you start planning a practical address plan, IPv6 isn't as big as > > everybody keeps saying... > > > I didn't realize "human friendly" was even a nominal design consideration, > especially as different humans have different tolerances for defining > "friendly" :) It was absolutely an issue. The excellent A6 proposal was killed because it was not human friendly. Very computer friendly, but people were not too happy about dealing with it. It was, in most ways, vastly superior to AAAA, but a real pain to try to deal with "by hand". -- 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 From dennis.hayes at distributel.ca Mon Jan 25 17:13:02 2010 From: dennis.hayes at distributel.ca (Dennis Hayes) Date: Mon, 25 Jan 2010 18:13:02 -0500 Subject: Looking for someone from Steadfast Networks Message-ID: Hi, Can someone from Steadfast Networks contact me off list. We're having issues accessing sites within your AS, including steadfast.net. I was routed to a tech in your DC and he wasn't sure where to transfer me to. Our AS is 21677 and our prefixes are 174.138.192.0/19, 206.80.240.0/20 and 216.246.224.0/19. I've tried both our up stream providers; one route fails at PAIX and the other fails in NTT's network in Chicago. Thanks, Dennis Hayes Distributel Communications Limited Tel: 613-237-3143 Email: dennis.hayes at distributel.ca From nanog at daork.net Mon Jan 25 17:20:10 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 26 Jan 2010 12:20:10 +1300 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <4B5DEFBE.3090506@uiuc.edu> <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com> Message-ID: <7F0972C0-03B8-48C4-89D6-2FFAF7A399A9@daork.net> On 26/01/2010, at 8:50 AM, Tim Durack wrote: > This is what we have planned: > > 2620:0000:xx00::/41 AS-NETx-2620-0-xx00 > > 2620:0000:xx00::/44 Infrastructure > > 2620:0000:xx01::/48 Pop1 Infrastructure > > 2620:0000:xx01:0000::/64 Router Loopback (2^64 x /128) > 2620:0000:xx01:0001::/64 Transit net (2^48 x /112) > > 2620:0000:xx01:0002::/64 Server Switch management > 2620:0000:xx01:0003::/64 Access Switch management > > 2620:0000:xx0f::/48 Pop16 Infrastructure Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP. You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s). Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it. % printf "%04x\n" 4095 0fff % printf "%d\n" 0x0fff 4095 -- Nathan Ward From owen at delong.com Mon Jan 25 18:33:15 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jan 2010 16:33:15 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote: > Ok let's summarize: > > /64: > + Sticks to the way IPv6 was designed (64 bits host part) > + Probability of renumbering very low > + simpler for ACLs and the like > + rDNS on a bit boundary > > <> You can give your peers funny names, like 2001:db8::dead:beef ;) > > - Prone to attacks (scans, router CPU load) Unless of course you just block nonexistent addresses in the /64 at each end. > - "Waste" of addresses > - Peer address needs to be known, impossible to guess with 2^64 addresses > Most of us use ::1 for the assigning side and ::2 for the non-assigning side of the connection. On multipoints, such as exchanges, the popular alternative is to use either the BCD of the ASN or the hex of the ASN for your first connection and something like ::1:AS:N for subsequent connections. > > /126 > + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) > + Not prone to scan-like attacks Equally prone to scan like attacks, but, no ACL required to reduce vulnerability. > > - Not on a bit boundary, so more complicated for ACLs and ? > - ? rDNS > - Perhaps need to renumber into /64 some time. > - No 64 bits for hosts > > > /127 > Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. > > > > On 25 Jan 2010, at 10:14, Matthew Petach wrote: > >> On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler >> wrote: >>> Hi >>> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >>> >>> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>> >>> So what do you think? Good? Bad? Ugly? /127 ? ;) >>> >>> Cheers >>> >>> Mathias Seiler >>> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel >>> T +41 61 201 30 90, F +41 61 201 30 99 >>> mathias.seiler at mironet.ch >>> www.mironet.ch >> >> As I mentioned in my lightning talk at the last NANOG, we reserved a >> /64 for each >> PtP link, >> but configured it as the first /126 out of the /64. That >> gives us the most >> flexibility for expanding to the full /64 later if necessary, but >> prevents us from being >> victim of the classic v6 neighbor discovery attack that you're prone >> to if you configure >> the entire /64 on the link. > > I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". > If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) ) > > This way the configuration and addressing plan is simple and understandable to anyone. > >> All someone out on the 'net needs to do >> is scan up through >> your address space on the link as quickly as possible, sending single packets at >> all the non-existent addresses on the link, and watch as your router CPU starts >> to churn keeping track of all the neighbor discovery messages, state table >> updates, and incomplete age-outs. > > Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. > >> With the link configured as a /126, there's >> a very small limit to the number of neighbor discovery messages, and the amount >> of state table that needs to be maintained and updated for each PtP link. >> >> It seemed like a reasonable approach for us--but there's more than one way to >> skin this particular cat. >> >> Hope this helps! >> > > Yes it does. Thanks! > > > Mathias Seiler > > MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > T +41 61 201 30 90, F +41 61 201 30 99 > > mathias.seiler at mironet.ch > www.mironet.ch > From owen at delong.com Mon Jan 25 18:43:34 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jan 2010 16:43:34 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <20100125170738.GI75640@gerbil.cluepon.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> Message-ID: <34B73946-E13D-414D-B5C3-AAB037E8C41A@delong.com> On Jan 25, 2010, at 9:07 AM, Richard A Steenbergen wrote: > On Mon, Jan 25, 2010 at 09:10:11AM -0500, TJ wrote: >> While I agree with parts of what you are saying - that using the "simple >> 2^128" math can be misleading, let's be clear on a few things: >> *) 2^61 is still very, very big. That is the number of IPv6 network >> segments available within 2000::/3. >> *) An end-user should get something between a /48 and a /56, _maybe_ as low >> as a /60 ... hopefully never a /64. Really. >> **) Let's call the /48s enterprise assignments, and the /56s home >> assignments ... ? >> **) And your /56 to /64 is NOT 1-256 IPs, it is 1-256 segments. > > It is if we are to follow the "always use a /64 as a single IP" > guidelines. Not that I'm encouraging this, I'm just saying this is what > we're told to do with the space. I for one have this little protocol > called DHCP that does IP assignments along with a bunch of other things > that I need anyways, so I'm more than happy to take a single /64 for > house as a single lan segment (well, never minding the fact that my > house has a /48). > I'm not sure where you're getting that. I've always heard use a /64 as a single segment, not as a single host. >> **) And, using the expected /48-/56, the numbers are really 256-64k subnets. > ... >> Note: "All we've really done is buy ourselves an 8 to 16 bit improvement at >> every level of allocation space" >> *) And you don't think 8-16 bits _AT EVERY LEVEL_ is a bit deal?? > > I'm not saying that 8-16 bits isn't an improvement, but it's a far cry > from the bazillions of numbers everyone makes IPv6 out to be. By the > time you figure in the overhead of autoconfiguration, restrictive > initial deployments, and the "now that the space is much bigger, we > should be reallocating bigger blocks" logic at every layer of > redistribution, that is what you're left with. So far all we've really > done with v6 is created a flashback to the days when every end user > could get a /24 just by asking, every enterprise could get a /16 just by > asking, and every big network could get a /8 just by asking, just bit > shifted a little bit. That's all well and good, but it isn't a > bazillion. :) > Yeah, but, that wasn't inherently bad, and, in this version of the flashback, we actually have enough addresses to do it and still have 7/8ths of the address space held in reserve. The biggest problems with the "flashback" days were: 1. Not enough addresses to do that on an ongoing basis. 2. No accountability or reclamation ability. Problem 1 is solved by the larger number of bits at each level of the hierarchy (/12 instead of /8 to the RIRs, /32 instead of /[12-20] to ISPs, /48 (or /56) to end users instead of /24, and, no worries about trying to pack 8 hosts into a /28 and dreading the day they become 15 hosts. Problem 2 is solved by the RIR system and their respective RSAs. As much as people grumble about paying RIR fees for their addresses, there is definite value to the community from the RIR system. So, to sum up... In the current /3 IANA is using, there are enough delegations for 512 /12s to be given to RIRs. In each /12, there's 1024k /32s. Even if we figure that 1/4 of all ISPs need a /28, that's support for a lot of ISPs in each RIR. (65536 if ALL ISPs needed a /28). In each /32, an ISP can handle 65,536 customers (so a /28 supports 256k customers all at /48). A residential ISP can probably stretch that /48 quite a bit further by giving each residential customer a /56 unless they specifically ask for a /48. In a /32, there are 16,777,216 /56s. That still gives the household room for 256 separate /64 networks, which, admittedly would be sufficient even for my relatively more intense than average network at home. (yes, I have a /48, but, I could easily live within a /56 if such were available when I requested my space.) Owen From steve at ibctech.ca Mon Jan 25 18:48:26 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 25 Jan 2010 19:48:26 -0500 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: <4B5E3BDA.9060408@ibctech.ca> I want to thank everyone who responded on, and off-list to this thread. I've garnered valuable information that ranges within the technical, business applicability, to 'common-sense' arenas. There is a lot of information that I have to go over now, and a few select pieces of software that I'm going to test immediately. One more question, if I may... My original post was completely concerned on automating the process of spinning traffic throughput graphs. Are there any software packages that stand out that have the ability to differentiate throughput between v4/v6, as opposed to the aggregate of the interface? (I will continue reading docs of all recommendations, but this may expedite the process a bit). Steve From owen at delong.com Mon Jan 25 18:58:29 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jan 2010 16:58:29 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5DE7E6.7000200@cox.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> Message-ID: <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> On Jan 25, 2010, at 10:50 AM, Larry Sheldon wrote: > On 1/25/2010 4:45 AM, Richard A Steenbergen wrote: >> On Mon, Jan 25, 2010 at 09:12:49AM +0000, Andy Davidson wrote: >>> There are 4,294,967,296 /64s in my own /32 allocation. If we only ever >>> use 2000::/3 on the internet, I make that 2,305,843,009,213,693,952 >>> /64s. This is enough to fill over seven Lake Eries. The total amount >>> of ipv6 address space is exponentially larger still - I have just looked >>> at 2000::/3 in these maths. >>> >>> THE IPv6 ADDRESS SPACE IS VERY, VERY, VERY BIG. >> >> Don't get carried away with all of that "IPv6 is huge" math, it quickly >> deteriorates when you start digging into it. Auto-configuration reduces >> it from 340282366920938463463374607431768211456 to 18446744073709551616 >> (that's 0.000000000000000005% of the original 128 bit space). Now as an >> end user you might get anything ranging from a /56 to a /64, that's only >> between 1 - 256 IPs, barely a significant increase at all if you were to >> actually use a /64 for each routed IP rather than as each routed subnet. >> As a small network you might get a /48, so that even if you gave out >> /64s to everyone it would be only 16 bits of space for you (the >> equivalent of getting a class B back in IPv4 land), something like a >> 8-16 bit improvement over what a similar sized network would have gotten >> in IPv4. As a bigger ISP you might get a /32, but it's the same thing, >> only 16 bits of space when you have to give out /48s. All we've really >> done is buy ourselves an 8 to 16 bit improvement at every level of >> allocation space (and a lot of prefix bloat for when we start using more >> than 2000::/3), which is a FAR cry from the 2^128 "omg big number, we >> can give every molecule an IPv6 address" math of the popular >> imagination. :) > > And it does not account for the factor that I was trying to shine a light on--the it-is-infinitely-huge is at risk of failing due to inventions we can not conceive of. > > Who knew, in the 1940's that every person would be assigned as many as five or more telephone numbers (exaggeration? In this house, occupied by two people there are 4 addressable PSTN devices, only one of which leaves the house if one of us does, and there are 6 devices that share an address but could easily have individual addresses, and would if we were using one of the VOIP services). > Sure, but, to put this in perspective, the entire 10-digit NANP could be numbered in a single /64 with several copies of NANP worth of addresses left over... NANP: 1,000,000,000 addresses. /64: 18,446,744,073,709,551,616 addresses An RIR /12 contains enough end-user /48s to hold NANP and then some: NANP: 1,000,000,000 addresses /12: 68,719,476,736 /48s (End User Sites) /12: 1,048,576 /32s (ISPs) (there are currently less than 50,000 registered phone companies) > Who knew in the 1980's that refrigerator's would need IP addresses? (We should not have been surprised, Coke machines did.) > As to refrigerators, probably all the appliances in a house can share a handful of subnets. A /56 per household provides for MANY appliance networks as well as separate networks for just about everything else you can imagine. Worst case, even if all households end up with /48s the address space is still sufficient. > And for all the concern about IPv4 exhaustion, what would have happened if the people who fought fiercely against RFC 1918 had won the day? > IPv6 deployment would be a lot further along and we wouldn't have spent nearly so much money overcoming the pitfalls and problems created by NAT. We wouldn't now have to spend even more money trying to get past the errant NAT=Security thinking. > Yes the numbers in IPv6 are huge, no doubt about it. > > But I say, to say "impossible to exhaust" is a fools errand. Somebody will find a way to exhaust the pool, just to be contrary, if for no currently recognized "legitimate" reason. > No, they're not impossible to exhaust, just pretty difficult. However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). Owen From owen at delong.com Mon Jan 25 19:01:29 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jan 2010 17:01:29 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> Message-ID: > > 2^128 is a "very big number." However, from a network engineering > perspective, IPv6 is really only 64bits of network address space. 2^64 > is still a "very big number." > > An end-user assignment /48 is really only 2^16 networks. That's not > very big once you start planning a human-friendly repeatable number > plan. > An end-user MINIMUM assignment (assignment for a single "site") is a /48. (with the possible exception of /56s for residential customers that don't ask for a /48). I have worked in lots of different enterprises and have yet to see one that had more than 65,536 networks in a single site. I'm not saying they don't exist, but, I will say that they are extremely rare. Multiple sites are a different issue. There are still enough /48s to issue one per site. > An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. > That's just the starting minimum. Many ISPs have already gotten much larger IPv6 allocations. > Once you start planning a practical address plan, IPv6 isn't as big as > everybody keeps saying... It's more than big enough for any deployment I've seen so far with plenty of room to spare. Owen From sikandar.raman at gmail.com Mon Jan 25 19:52:01 2010 From: sikandar.raman at gmail.com (Ramanpreet Singh) Date: Mon, 25 Jan 2010 19:52:01 -0600 Subject: Using /31 for router links In-Reply-To: <4B5D9AAD.8040601@briantel.com> References: <1001231852.AA23235@ivan.Harhan.ORG> <4B5D9AAD.8040601@briantel.com> Message-ID: <347265a11001251752s12fb0621xe7b014659f36ceed@mail.gmail.com> I agree! most of the xDSL providers all over the world follow the same standard of two VC's/ One for Data and One for voice. On Mon, Jan 25, 2010 at 7:20 AM, Massimiliano Stucchi wrote: > On 23/01/10 19:52, Michael Sokolov wrote: >> Mark Smith wrote: >> > >> As for ATM... ?The part that totally baffles me about the use of ATM on >> xDSL lines is that I have never, ever, ever seen an xDSL line carrying >> more than one ATM VC. ?OK, there may be someone out there who has set up >> a configuration like that just for fun, but 99.999% of all ATM'd xDSL >> lines out there carry a single PVC at 0*35 or 0*38. > > It's common practice down here in Italy to have more than one VC. ?One > is used to carry data and the other one is used for VoIP, so that you > don't have to do QoS on the data part. > > Ciao ! > -- > > Massimiliano Stucchi > BrianTel Srl > stucchi at briantel.com > Tel (+39) 039 9669921 | Fax (+39) 02 44417204 > I-23807, Merate (Lecco), via Mameli 6 > MS16801-RIPE > > From tdurack at gmail.com Mon Jan 25 20:26:13 2010 From: tdurack at gmail.com (Tim Durack) Date: Mon, 25 Jan 2010 21:26:13 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> Message-ID: <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong wrote: > > 2^128 is a "very big number." However, from a network engineering > perspective, IPv6 is really only 64bits of network address space. 2^64 > is still a "very big number." > > An end-user assignment /48 is really only 2^16 networks. That's not > very big once you start planning a human-friendly repeatable number > plan. > > An end-user MINIMUM assignment (assignment for a single "site") is > a /48. ?(with the possible exception of /56s for residential customers > that don't ask for a /48). > I have worked in lots of different enterprises and have yet to see one that > had more than 65,536 networks in a single site. ?I'm not saying they don't > exist, but, I will say that they are extremely rare. ?Multiple sites are a > different > issue. ?There are still enough /48s to issue one per site. Networks per site isn't the issue. /48s per organization is my concern. Guidelines on assignment size for end-user sites aren't clear. It comes down to the discretion of ARIN. That's why I like pp 106. It takes some of the guess-work/fudge-factor out of assignments. > An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. > > That's just the starting minimum. ?Many ISPs have already gotten much larger > IPv6 allocations. Understood. Again, the problem for me is medium/large end-user sites that have to justify an assignment to a RIR that doesn't have clear guidelines on multiple /48s. > Once you start planning a practical address plan, IPv6 isn't as big as > everybody keeps saying... > > It's more than big enough for any deployment I've seen so far with plenty > of room to spare. > Owen > -- Tim:> Sent from Brooklyn, NY, United States From morrowc.lists at gmail.com Mon Jan 25 21:34:46 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 25 Jan 2010 22:34:46 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> Message-ID: <75cb24521001251934g4b2aa692m36dfde053e62bf8a@mail.gmail.com> On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong wrote: > > On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote: > >> Ok let's summarize: >> >> /64: >> + ? ? Sticks to the way IPv6 was designed (64 bits host part) >> + ? ? Probability of renumbering very low >> + ? ? simpler for ACLs and the like >> + ? ? rDNS on a bit boundary >> >> <> ? ?You can give your peers funny names, like 2001:db8::dead:beef ;) >> >> - ? ? Prone to attacks (scans, router CPU load) > Unless of course you just block nonexistent addresses in the /64 at each end. uhm, how sensible is this? "Use s^64 address, block all but the first 2" I'm confused by the goal of using a /64 on a ptp link that never will have more than 2 addresses on it? I get that 'years ago' understanding what a /30 or a /31 is was 'hard' for people but seriously, this is 2010... >> - ? ? "Waste" of addresses >> - ? ? Peer address needs to be known, impossible to guess with 2^64 addresses >> > Most of us use ::1 for the assigning side and ::2 for the non-assigning side of > the connection. ?On multipoints, such as exchanges, the popular alternative is > to use either the BCD of the ASN or the hex of the ASN for your first connection > and something like ::1:AS:N for subsequent connections. multipoint exchanges are out of scope of the discission, or so I had counted earlier. >> >> /126 >> + ? ? Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) >> + ? ? Not prone to scan-like attacks > > Equally prone to scan like attacks, but, no ACL required to reduce vulnerability. how so? How do you reduce this without an acl or some sort somewhere that needs to be maintained? (I think I'm asking for some config snippets with explanations, perhaps it's documented somewhere already even? :) ) -Chris >> >> - ? ? Not on a bit boundary, so more complicated for ACLs and ? >> - ? ? ? rDNS >> - ? ? Perhaps need to renumber into /64 some time. >> - ? ? No 64 bits for hosts >> >> >> /127 >> Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. >> >> >> >> On 25 Jan 2010, at 10:14, Matthew Petach wrote: >> >>> On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler >>> wrote: >>>> Hi >>>> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >>>> >>>> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>>> >>>> So what do you think? Good? Bad? Ugly? /127 ? ;) >>>> >>>> Cheers >>>> >>>> Mathias Seiler >>>> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel >>>> T +41 61 201 30 90, F +41 61 201 30 99 >>>> mathias.seiler at mironet.ch >>>> www.mironet.ch >>> >>> As I mentioned in my lightning talk at the last NANOG, we reserved a >>> /64 for each >>> PtP link, >>> but configured it as the first /126 out of the /64. ?That >>> gives us the most >>> flexibility for expanding to the full /64 later if necessary, but >>> prevents us from being >>> victim of the classic v6 neighbor discovery attack that you're prone >>> to if you configure >>> the entire /64 on the link. >> >> I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". >> If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) ) >> >> This way the configuration and addressing plan is simple and understandable to anyone. >> >>> All someone out on the 'net needs to do >>> is scan up through >>> your address space on the link as quickly as possible, sending single packets at >>> all the non-existent addresses on the link, and watch as your router CPU starts >>> to churn keeping track of all the neighbor discovery messages, state table >>> updates, and incomplete age-outs. >> >> Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. >> >>> With the link configured as a /126, there's >>> a very small limit to the number of neighbor discovery messages, and the amount >>> of state table that needs to be maintained and updated for each PtP link. >>> >>> It seemed like a reasonable approach for us--but there's more than one way to >>> skin this particular cat. >>> >>> Hope this helps! >>> >> >> Yes it does. Thanks! >> >> >> Mathias Seiler >> >> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel >> T +41 61 201 30 90, F +41 61 201 30 99 >> >> mathias.seiler at mironet.ch >> www.mironet.ch >> > > > From morrowc.lists at gmail.com Mon Jan 25 21:38:16 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 25 Jan 2010 22:38:16 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> Message-ID: <75cb24521001251938t46410418v79729df534e747f1@mail.gmail.com> On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong wrote: >> Once you start planning a practical address plan, IPv6 isn't as big as >> everybody keeps saying... > > It's more than big enough for any deployment I've seen so far with plenty > of room to spare. Oh good! so the us-DoD's /10 request is getting filled when? -Chris From morrowc.lists at gmail.com Mon Jan 25 21:55:07 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 25 Jan 2010 22:55:07 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> Message-ID: <75cb24521001251955mb692effhf643c141f2378da3@mail.gmail.com> On Mon, Jan 25, 2010 at 9:26 PM, Tim Durack wrote: >> An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. >> >> That's just the starting minimum. ?Many ISPs have already gotten much larger >> IPv6 allocations. > > Understood. Again, the problem for me is medium/large end-user sites > that have to justify an assignment to a RIR that doesn't have clear > guidelines on multiple /48s. some of what you're saying (tim) here is that you could: (one of these) 1) go to all your remote-office ISP's and get a /48 from each 2) go to *RIR's and get / to cover the number of remote sites you have in their region(s) 3) keep on keepin' on until something better comes along? I think for each you have this at least as pitfalls: 1) o no simple way to aggregate internally the 48's or subsets of the 48's o no simple way to define 'internal' vs 'external' at the address level for your remote/main sites o renumbering concerns when/if you decide to change ISP's at remote offices o multihoming concerns with PA space in v6-land 2) o justification in light of 'unclear' policies for an address block of the right size. NOTE:I don't think the policies is unclear, but that could be my misreading of the policies. o will your remote-office's ISP's accept the /48's per site? (vz/vzb is a standout example here) o will your remote-office's have full reachability to the parts of the network they need access to? (remote ISP's filtering at/above the /48 boundary) For the Enterprise still used to v4-land ipv6 isn't a win yet... for an ISP it's relatively[0] simple. -Chris 0: address interfaces, turn up protocols, add 'security' assign customers /48's...(yes fight bugs/problems/'why is there a colon in my ip address?" (what if you do have 200 offices in the US which aren't connected on a private network today?) From frnkblk at iname.com Mon Jan 25 21:56:32 2010 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 25 Jan 2010 21:56:32 -0600 Subject: Using /31 for router links In-Reply-To: <1001231852.AA23235@ivan.Harhan.ORG> References: <1001231852.AA23235@ivan.Harhan.ORG> Message-ID: We use 5 PVCs for the IP video and one for Internet. Not as uncommon as you think. Frank -----Original Message----- From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] Sent: Saturday, January 23, 2010 12:53 PM To: nanog at nanog.org Subject: Re: Using /31 for router links Mark Smith wrote: > What about NAT, ATM cell tax, unnecessary addressing fields in PTP > protocols (including your beloved HDLC), SSAP, DSAP fields not being big > enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 > through AAL4, PPPoE "dumbell" MTUs and MSS hacks? Some of those are far > worse sins in my opinion. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? MS From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Jan 25 22:03:35 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 26 Jan 2010 14:33:35 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <4B5DEFBE.3090506@uiuc.edu> <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com> Message-ID: <20100126143335.3ed9bcb6@opy.nosense.org> On Mon, 25 Jan 2010 14:50:35 -0500 Tim Durack wrote: > On Mon, Jan 25, 2010 at 2:23 PM, Ryan Harden wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Our numbering plan is this: > > > > 1) Autoconfigured hosts possible? /64 > > 2) Autoconfigured hosts not-possible, we control both sides? /126 > > 3) Autoconfigured hosts not-possible, we DON'T control both sides? /64 > > 4) Loopback? /128 > > > > Within our /48 we've carved it into (4) /50s. > > * First, Infrastructure. This makes ACLs cake. > > ** Within this /50 are smaller allocations for /126s and /128s and /64s. > > * Second, User Subnets (16k /64s available) > > ** All non-infrastructure subnets are assigned from this pool. > > * Third, Reserved. > > * Fourth, Reserved. > > > > We believe this plan gives us the most flexibility in the future. We > > made these choices based upon what works the best for us and our tools > > and not to conserve addresses. Using a single /64 ACL to permit/deny > > traffic to all ptp at the border was extremely attractive, etc. > > > > - -- > > This is what we have planned: > > 2620:0000:xx00::/41 AS-NETx-2620-0-xx00 > > 2620:0000:xx00::/44 Infrastructure > > 2620:0000:xx01::/48 Pop1 Infrastructure > > 2620:0000:xx01:0000::/64 Router Loopback (2^64 x /128) > 2620:0000:xx01:0001::/64 Transit net (2^48 x /112) > > 2620:0000:xx01:0002::/64 Server Switch management > 2620:0000:xx01:0003::/64 Access Switch management > > 2620:0000:xx0f::/48 Pop16 Infrastructure > > > 2620:0000:xx10::/44 Sparse Reservation > > 2620:0000:xx20::/44 Sparse Reservation > > 2620:0000:xx30::/44 Pop1 Services > > 2620:0000:xx30::/48 Cust1 Services > > 2620:0000:xx30:0001::/64 VLAN_1 > 2620:0000:xx30:4094::/64 VLAN_4094 > > 2620:0000:xx31::/48 Cust2 Services > > 2620:0000:xx31:0001::/64 VLAN_1 > 2620:0000:xx31:4094::/64 VLAN_4094 > > 2620:0000:xx32::/48 Cust3 Services > > 2620:0000:xx31:0001::/64 VLAN_1 > 2620:0000:xx31:4094::/64 VLAN_4094 > > 2620:0000:xx32::/48 Cust4 Services > > 2620:0000:xx31:0001::/64 VLAN_1 > > 2620:0000:xx31:4094::/64 VLAN_4094 > > 2620:0000:xx32::/48 RES-PD-32 (4096 x /60) > 2620:0000:xx3f::/48 RES-PD-3f (4096 x /60) > > 2620:0000:xx40::/44 Pop2 Services > > 2620:0000:xx50::/44 Pop3 Services > > 2620:0000:xx60::/44 Pop4 services > > 2620:0000:xx70::/44 Pop5 Services > > This is a multiple campus network, customers are all internal. I have > had to squeeze Residential PDs down to /60s to make it fit. One Pop is > really 3 sites in one. This has had to be massaged into one Pop also. > To be safe, I'm thinking of adjusting loopbacks and ptp to be /64s. > > I'm reasonably happy with the plan, but it doesn't seem to have that > much room to grow. > If you haven't already, you may wish to have a read of RFC3531 - "A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block". It suggests a method of subnet assignment such that you're not stuck with your initial boundary estimations. > -- > Tim:> > Sent from Brooklyn, NY, United States > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Jan 25 22:06:57 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 26 Jan 2010 14:36:57 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <000001ca9dfb$3599e270$a0cda750$@com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> Message-ID: <20100126143657.2271062f@opy.nosense.org> On Mon, 25 Jan 2010 15:15:55 -0500 "TJ" wrote: > > -----Original Message----- > > From: Tim Durack [mailto:tdurack at gmail.com] > > Sent: Monday, January 25, 2010 14:03 > > To: TJ > > Cc: nanog at nanog.org > > Subject: Re: Using /126 for IPv6 router links > > <> > > > > > 2^128 is a "very big number." However, from a network engineering > > perspective, IPv6 is really only 64bits of network address space. 2^64 > > is still a "very big number." > > > > An end-user assignment /48 is really only 2^16 networks. That's not > > very big once you start planning a human-friendly repeatable number > > plan. > > > > An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. > > > > Once you start planning a practical address plan, IPv6 isn't as big as > > everybody keeps saying... > > > I didn't realize "human friendly" was even a nominal design consideration, > especially as different humans have different tolerances for defining > "friendly" :) > This from people who can probably do decimal to binary conversion and back again for IPv4 subnetting in their head and are proud of it. Surely IPv6 hex to binary and back again can be the new party trick? :-) > I (continue to) maintain that: > *) 2^16 is still a pretty good size number, even allowing for aggregation / > summarization. > *) If you are large enough that this isn't true - you should (have) > request(ed) more, naturally - each bit doubles your space ... > > > > /TJ > > > From jimb at jsbc.cc Mon Jan 25 23:45:17 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Mon, 25 Jan 2010 21:45:17 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <20100126143657.2271062f@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> Message-ID: <4B5E816D.9090907@jsbc.cc> On 1/25/2010 20:06, Mark Smith wrote: > > This from people who can probably do decimal to binary conversion > and back again for IPv4 subnetting in their head and are proud of > it. Surely IPv6 hex to binary and back again can be the new party > trick? :-) > > > Hehe. Decimal -> binary in your head? I don't even bother except if it's some well known "magic #s". Hex -> binary though is super simple since unlike decimal, each digit translates exactly into a nybble. You just have to know the binary from 0 - 15, 16 simple four-bit patterns, and it's a piece of cake. You can give me hex numbers and and I'll rattle off binary all day, or vica-versa. Octal is similarly easy, but would result in some long IPv6 addresses. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From andy at nosignal.org Tue Jan 26 02:23:15 2010 From: andy at nosignal.org (Andy Davidson) Date: Tue, 26 Jan 2010 08:23:15 +0000 Subject: Enhancing automation with network growth In-Reply-To: <4B5E3BDA.9060408@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> <4B5E3BDA.9060408@ibctech.ca> Message-ID: <4B5EA673.7020606@nosignal.org> On 26/01/2010 00:48, Steve Bertrand wrote: > My original post was completely concerned on automating the process of > spinning traffic throughput graphs. Are there any software packages that > stand out that have the ability to differentiate throughput between > v4/v6, as opposed to the aggregate of the interface? (I will continue > reading docs of all recommendations, but this may expedite the process a > bit). That's a feature of the switch you are probing, not the monitoring suite per se. e.g. I have Cisco CPE that does count the difference : bcliffe-gw#sh int accounting | b Vlan1 Vlan1 Wired network VLAN Protocol Pkts In Chars In Pkts Out Chars Out IP 4587251 1137174268 4757409 3669014365 ARP 12595 755700 52409 3144540 IPv6 188872 20699030 223349 131947020 .... but these numbers can not be polled via SNMP, so the only way to graph this device is with an expect script and telnet access. Nice. :-) There is an ipv6MIB, with some interface stats defined under 1.3.6.1.2.1.55.1.6.1, but I do not know of a family of devices which supports this for sure. If your devices support Netflow9, then this -- whilst an extremely heavy/"kitchen sink" approach -- will give you any degree of granularity that you like. Not long term reliable, but if your v6 is presented via a tunnel, you could graph that tunnel interface ? Yuck, yuck (but we did measure some ipv6 traffic use (more than we expected actually) at a recent operational meeting in the UK) Please let us all know if you find something with good v6 snmp support. Andy From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 26 02:44:34 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 26 Jan 2010 19:14:34 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001251934g4b2aa692m36dfde053e62bf8a@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> <75cb24521001251934g4b2aa692m36dfde053e62bf8a@mail.gmail.com> Message-ID: <20100126191434.79cd11e1@opy.nosense.org> On Mon, 25 Jan 2010 22:34:46 -0500 Christopher Morrow wrote: > On Mon, Jan 25, 2010 at 7:33 PM, Owen DeLong wrote: > > > > On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote: > > > >> Ok let's summarize: > >> > >> /64: > >> + ? ? Sticks to the way IPv6 was designed (64 bits host part) > >> + ? ? Probability of renumbering very low > >> + ? ? simpler for ACLs and the like > >> + ? ? rDNS on a bit boundary > >> > >> <> ? ?You can give your peers funny names, like 2001:db8::dead:beef ;) > >> > >> - ? ? Prone to attacks (scans, router CPU load) > > Unless of course you just block nonexistent addresses in the /64 at each end. > > uhm, how sensible is this? "Use s^64 address, block all but the first > 2" I'm confused by the goal of using a /64 on a ptp link that never > will have more than 2 addresses on it? > > I get that 'years ago' understanding what a /30 or a /31 is was 'hard' > for people but seriously, this is 2010... > And therefore life should be getting easier, not harder. If there is no need for variable length node addresses, why make life harder by using them? This discussion isn't about what's hard or not to understand, it's about whether variable length node addresses are necessary or not. In IPv6 they're not. Why can't IPv6 node addressing be as easy to understand and work with as Ethernet addresses? They were designed in the early 1980s*. 28 years or so years later, it's time for layer 3 addressing to catch up. * "48-bit Absolute Internet and Ethernet Host Numbers" http://ethernethistory.typepad.com/papers/HostNumbers.pdf (well worth a read - did you know that Ethernet addresses were supposed to be per host, not per interface?) > >> - ? ? "Waste" of addresses > >> - ? ? Peer address needs to be known, impossible to guess with 2^64 addresses > >> > > Most of us use ::1 for the assigning side and ::2 for the non-assigning side of > > the connection. ?On multipoints, such as exchanges, the popular alternative is > > to use either the BCD of the ASN or the hex of the ASN for your first connection > > and something like ::1:AS:N for subsequent connections. > > multipoint exchanges are out of scope of the discission, or so I had > counted earlier. > > >> > >> /126 > >> + ? ? Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) > >> + ? ? Not prone to scan-like attacks > > > > Equally prone to scan like attacks, but, no ACL required to reduce vulnerability. > > how so? How do you reduce this without an acl or some sort somewhere > that needs to be maintained? > (I think I'm asking for some config snippets with explanations, > perhaps it's documented somewhere already even? :) ) > > -Chris > > >> > >> - ? ? Not on a bit boundary, so more complicated for ACLs and ? > >> - ? ? ? rDNS > >> - ? ? Perhaps need to renumber into /64 some time. > >> - ? ? No 64 bits for hosts > >> > >> > >> /127 > >> Like /126 but there's an RFC not recommending it and an RFC (draft) which revises that non-recommendation. > >> > >> > >> > >> On 25 Jan 2010, at 10:14, Matthew Petach wrote: > >> > >>> On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler > >>> wrote: > >>>> Hi > >>>> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. > >>>> > >>>> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. > >>>> > >>>> So what do you think? Good? Bad? Ugly? /127 ? ;) > >>>> > >>>> Cheers > >>>> > >>>> Mathias Seiler > >>>> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > >>>> T +41 61 201 30 90, F +41 61 201 30 99 > >>>> mathias.seiler at mironet.ch > >>>> www.mironet.ch > >>> > >>> As I mentioned in my lightning talk at the last NANOG, we reserved a > >>> /64 for each > >>> PtP link, > >>> but configured it as the first /126 out of the /64. ?That > >>> gives us the most > >>> flexibility for expanding to the full /64 later if necessary, but > >>> prevents us from being > >>> victim of the classic v6 neighbor discovery attack that you're prone > >>> to if you configure > >>> the entire /64 on the link. > >> > >> I think I will go this way. Since we've got the usual /32 assignment I have plenty of /64 to "waste". > >> If I continue assigning a /48 to every customer I can set apart a /64 for each PtP link and still have room to grow for a very long time (I'm not taking into account the assignment of IPv6 addresses to high amounts of M&Ms so far ;) ) > >> > >> This way the configuration and addressing plan is simple and understandable to anyone. > >> > >>> All someone out on the 'net needs to do > >>> is scan up through > >>> your address space on the link as quickly as possible, sending single packets at > >>> all the non-existent addresses on the link, and watch as your router CPU starts > >>> to churn keeping track of all the neighbor discovery messages, state table > >>> updates, and incomplete age-outs. > >> > >> Well I could filter that in hardware with an interface ACL but a /126 seems much easier to maintain. > >> > >>> With the link configured as a /126, there's > >>> a very small limit to the number of neighbor discovery messages, and the amount > >>> of state table that needs to be maintained and updated for each PtP link. > >>> > >>> It seemed like a reasonable approach for us--but there's more than one way to > >>> skin this particular cat. > >>> > >>> Hope this helps! > >>> > >> > >> Yes it does. Thanks! > >> > >> > >> Mathias Seiler > >> > >> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel > >> T +41 61 201 30 90, F +41 61 201 30 99 > >> > >> mathias.seiler at mironet.ch > >> www.mironet.ch > >> > > > > > > > From tsands at rackspace.com Tue Jan 26 06:40:35 2010 From: tsands at rackspace.com (Tom Sands) Date: Tue, 26 Jan 2010 06:40:35 -0600 Subject: DDoS mitigation recommendations Message-ID: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> With Guard appliance and 65xx module being EoL'd, and Cisco's desire to exist the DDoS mitigation market, I'd like to get some recommendations of what other products people are having good success with. We are looking for something that can support 3Gbps - 10Gbps, multi-tenancy, seamless integration, and many of the basic features you'd see on the Guard. Thank you, -- -------------------------------------------------------------------------------- Tom Sands Chief Network Engineer Rackspace Hosting -------------------------------------------------------------------------------- Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From pstewart at nexicomgroup.net Tue Jan 26 06:43:08 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 26 Jan 2010 07:43:08 -0500 Subject: DDoS mitigation recommendations Message-ID: Arbor stuff comes to mind and works very well in our experiences.... Paul -------------------------- Paul Stewart Senior Network Administrator Nexicom Inc. http://www.nexicom.net/ ----- Original Message ----- From: Tom Sands To: nanog Sent: Tue Jan 26 07:40:35 2010 Subject: DDoS mitigation recommendations With Guard appliance and 65xx module being EoL'd, and Cisco's desire to exist the DDoS mitigation market, I'd like to get some recommendations of what other products people are having good success with. We are looking for something that can support 3Gbps - 10Gbps, multi-tenancy, seamless integration, and many of the basic features you'd see on the Guard. Thank you, -- -------------------------------------------------------------------------------- Tom Sands Chief Network Engineer Rackspace Hosting -------------------------------------------------------------------------------- Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From khunt at huntbrothers.com Tue Jan 26 06:43:17 2010 From: khunt at huntbrothers.com (Kevin Hunt) Date: Tue, 26 Jan 2010 06:43:17 -0600 Subject: Fusion Splicers Message-ID: Anyone here with any experience with Jilong fusion splicers ? Our old Fujikura has died and I have to at least consider the Jilong. From david.freedman at uk.clara.net Tue Jan 26 07:17:25 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 26 Jan 2010 13:17:25 +0000 Subject: DDoS mitigation recommendations In-Reply-To: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> Message-ID: >Arbor stuff comes to mind and works very well in our experiences.... Arbor++ From trejrco at gmail.com Tue Jan 26 07:35:35 2010 From: trejrco at gmail.com (TJ) Date: Tue, 26 Jan 2010 08:35:35 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001251938t46410418v79729df534e747f1@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <75cb24521001251938t46410418v79729df534e747f1@mail.gmail.com> Message-ID: <002501ca9e8c$7695a890$63c0f9b0$@com> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Monday, January 25, 2010 22:38 > To: Owen DeLong > Cc: nanog at nanog.org > Subject: Re: Using /126 for IPv6 router links > > On Mon, Jan 25, 2010 at 8:01 PM, Owen DeLong wrote: > > >> Once you start planning a practical address plan, IPv6 isn't as big as > >> everybody keeps saying... > > > > It's more than big enough for any deployment I've seen so far with > plenty > > of room to spare. > > Oh good! so the us-DoD's /10 request is getting filled when? The US DoD has the equivalent of a /13 ... what is the question? /TJ From trejrco at gmail.com Tue Jan 26 07:37:44 2010 From: trejrco at gmail.com (TJ) Date: Tue, 26 Jan 2010 08:37:44 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100126143657.2271062f@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> Message-ID: <002601ca9e8c$c356b4d0$4a041e70$@com> > -----Original Message----- > From: Mark Smith > [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] > Sent: Monday, January 25, 2010 23:07 > To: TJ > Cc: nanog at nanog.org > Subject: Re: Using /126 for IPv6 router links <> > > I didn't realize "human friendly" was even a nominal design > consideration, > > especially as different humans have different tolerances for defining > > "friendly" :) > > > > This from people who can probably do decimal to binary conversion > and back again for IPv4 subnetting in their head and are proud of > it. Surely IPv6 hex to binary and back again can be the new party > trick? :-) Hex-Binary-Decimal, and permutations thereof - always a great party trick ... if you hang out at the right parties! /TJ From sean.korten at twcable.com Tue Jan 26 08:16:12 2010 From: sean.korten at twcable.com (Korten, Sean) Date: Tue, 26 Jan 2010 09:16:12 -0500 Subject: DDoS mitigation recommendations In-Reply-To: References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> Message-ID: <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> One more for Arbor. -----Original Message----- From: David Freedman [mailto:david.freedman at uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog at nanog.org Subject: Re: DDoS mitigation recommendations >Arbor stuff comes to mind and works very well in our experiences.... Arbor++ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From nick at foobar.org Tue Jan 26 08:34:30 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Jan 2010 14:34:30 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <002501ca9e8c$7695a890$63c0f9b0$@com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <75cb24521001251938t46410418v79729df534e747f1@mail.gmail.com> <002501ca9e8c$7695a890$63c0f9b0$@com> Message-ID: <4B5EFD76.1080806@foobar.org> On 26/01/2010 13:35, TJ wrote: > The US DoD has the equivalent of a /13 ... what is the question? In fact, they have a little less than a /18. This is still the largest block when aggregated - France Telecom comes second with a single /19. http://www.mail-archive.com/nanog at nanog.org/msg01876.html It may be time to retire this myth. Nick From sfouant at shortestpathfirst.net Tue Jan 26 08:41:18 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 26 Jan 2010 14:41:18 +0000 Subject: DDoS mitigation recommendations Message-ID: <152973129-1264516678-cardhu_decombobulator_blackberry.rim.net-605639686-@bda294.bisx.prod.on.blackberry> There was an interesting thread on this topic a few weeks back. I really liked the Guards, it's too bad Cisco decided to pull this from the marketplace - it was as close to a panacea as it gets. As alternatives, I've worked with the Riorey boxes as well as Arbor gear. They are both very good boxes, but as your requirements state that you require Multi-tenancy that only really leaves the Arbor. Unfortunately, the Riorey boxes only support a one-size fits all approach as they do not allow unique filtering parameters on a per-prefix basis. Arbor on the other hand supports a full range of Managed Objects and Mitigation Templates which can be applied to individual prefixes, etc. Sorry for the top post, I'm on my Blackberry. Stefan Fouant ------Original Message------ From: Korten, Sean To: nanog at nanog.org To: tsands at rackspace.com Subject: RE: DDoS mitigation recommendations Sent: Jan 26, 2010 9:16 AM One more for Arbor. -----Original Message----- From: David Freedman [mailto:david.freedman at uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog at nanog.org Subject: Re: DDoS mitigation recommendations >Arbor stuff comes to mind and works very well in our experiences.... Arbor++ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Sent from my Verizon Wireless BlackBerry From thegameiam at yahoo.com Tue Jan 26 08:38:43 2010 From: thegameiam at yahoo.com (David Barak) Date: Tue, 26 Jan 2010 06:38:43 -0800 (PST) Subject: Using /126 for IPv6 router links In-Reply-To: <20100126191434.79cd11e1@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> <75cb24521001251934g4b2aa692m36dfde053e62bf8a@mail.gmail.com> <20100126191434.79cd11e1@opy.nosense.org> Message-ID: <254494.83717.qm@web31802.mail.mud.yahoo.com> From: Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org >Why can't IPv6 node addressing be as easy to understand and work with >as Ethernet addresses? They were designed in the early 1980s*. 28 years >or so years later, it's time for layer 3 addressing to catch up. Becase Ethernet addresses are only locally significant, are not manually assigned in the vast majority of cases, and changing a MAC by replacing a NIC has no bearing on the configuration of a { server | router ACL | etc }. Layer 3 addressing is globally significant, and the case we're discussing is addresses which are human-assigned rather than automatically configured.? Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty much the way I would want it to.??Global addressing approaches, on the other hand, are highly optimized in directions which make them less flexible or have surprising consequences (hence this thread). David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From jmaimon at ttec.com Tue Jan 26 08:54:59 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 26 Jan 2010 09:54:59 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> Message-ID: <4B5F0243.2040605@ttec.com> Owen DeLong wrote: > > No, they're not impossible to exhaust, just pretty difficult. > > However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative > numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). > > Owen > Owen, We have had this conversation before, but I just wanted to put my two cents out there again. I dont view /3 as a safety valve. I view it as a possible escape pod from a sinking ship. If it needs to be utilized, the entire world has been dealt a large disservice - something great pains should be taken to avoid. I doubt it would be an "oops, ime sorry, no harm done". It should not be a factor to add risk into allocation design. Furthermore, any allocation holder trying the same trick of reserving a greater than half of their block for the safety valve in their numbering scheme might quickly discover that their block is a bit more cramped than they thought it would be. For me, the entire debate boils down to this question. What should the objective be, decades or centuries? Joe From dts at senie.com Tue Jan 26 09:05:29 2010 From: dts at senie.com (Daniel Senie) Date: Tue, 26 Jan 2010 10:05:29 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5F0243.2040605@ttec.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> <4B5F0243.2040605@ttec.com> Message-ID: On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote: > For me, the entire debate boils down to this question. > > What should the objective be, decades or centuries? If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows). From jeffrey.lyon at blacklotus.net Tue Jan 26 09:12:44 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 26 Jan 2010 10:12:44 -0500 Subject: DDoS mitigation recommendations In-Reply-To: <16720fe01001260710m2df887bbsb7c7f7eb19140146@mail.gmail.com> References: <152973129-1264516678-cardhu_decombobulator_blackberry.rim.net-605639686-@bda294.bisx.prod.on.blackberry> <16720fe01001260710m2df887bbsb7c7f7eb19140146@mail.gmail.com> Message-ID: <16720fe01001260712v2d6cd06bn79fb70220bd8b78c@mail.gmail.com> The RioRey per prefix issue is fixed although the patch they released to us had a lot of bugs. Were still waiting on a working appliance with the new code. IntruGuard fits the bill and is probably 1/5th the cost of Arbor pound for pound. We use both RR and IG, each having their pros and cons. Jeff On Jan 26, 2010 9:39 AM, "Stefan Fouant" wrote: There was an interesting thread on this topic a few weeks back. I really liked the Guards, it's too bad Cisco decided to pull this from the marketplace - it was as close to a panacea as it gets. As alternatives, I've worked with the Riorey boxes as well as Arbor gear. They are both very good boxes, but as your requirements state that you require Multi-tenancy that only really leaves the Arbor. Unfortunately, the Riorey boxes only support a one-size fits all approach as they do not allow unique filtering parameters on a per-prefix basis. Arbor on the other hand supports a full range of Managed Objects and Mitigation Templates which can be applied to individual prefixes, etc. Sorry for the top post, I'm on my Blackberry. Stefan Fouant ------Original Message------ From: Korten, Sean To: nanog at nanog.org To: tsands at rackspace.com Subject... Sent from my Verizon Wireless BlackBerry From jmaimon at ttec.com Tue Jan 26 09:27:12 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 26 Jan 2010 10:27:12 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> <4B5F0243.2040605@ttec.com> Message-ID: <4B5F09D0.4040405@ttec.com> Daniel Senie wrote: > > On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote: > >> For me, the entire debate boils down to this question. >> >> What should the objective be, decades or centuries? > > If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows). > > We already have numbering systems that are showing their age as they are hitting their late decades or even older. Now if decades are good enough for you, how many of them? IPv4 is 3 and nearly certain to hit 4 and possibly 5. Wouldnt you like to do at least twice as well? So calling for a system that should work for at least a 100 years is not as laughable as it may seem on the face of it -- in fact thats what the original promise of ipv6 was. You make another excellent point. There may be other needs for the rest of the /3's that will take them out of the escape pod role. Joe From tdurack at gmail.com Tue Jan 26 09:27:35 2010 From: tdurack at gmail.com (Tim Durack) Date: Tue, 26 Jan 2010 10:27:35 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <7F0972C0-03B8-48C4-89D6-2FFAF7A399A9@daork.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <4B5DEFBE.3090506@uiuc.edu> <9e246b4d1001251150p5be0e8bei941b0dfb2485087b@mail.gmail.com> <7F0972C0-03B8-48C4-89D6-2FFAF7A399A9@daork.net> Message-ID: <9e246b4d1001260727h2a879c4aj3d7385212e950898@mail.gmail.com> On Mon, Jan 25, 2010 at 6:20 PM, Nathan Ward wrote: > Why do you force POP infrastructure to be a /48? That allows you only 16 POPs which is pretty restrictive IMO. > Why not simply take say 4 /48s and sparsely allocate /56s to each POP and then grow the /56s if you require more networks at each POP. > > You only have a need for 4 /64s at each POP right now, so the 256 that a /56 gives you sounds like more than enough, and up to 1024 POPs (assuming you don't outgrow any of the /56s). NRPM says: 6.5.4.3. Assignment to operator's infrastructure An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. A separate assignment can be obtained for the in-house operations of the operator. Currently living with mixed infrastructure/customer address space, so I'm quite happy to separate this out. We will also have a /48 per-pop for service we provide, such as DHCP/DNS/Web etc. Essentially we will be a customer of our own infrastructure. I believe the above wording allows for that. > Also I'd strongly recommend not stuffing decimal numbers in to a hexadecimal field. It might seem like a good idea right now to make the learning curve easier, but it's going to make stuff annoying long term. You don't have anything in IPv4 that's big enough to indicate the VLAN number and you've lived just fine for years, so forcing it to be decimal like that isn't really needed. > You're much better off giving your staff the tools to translate between the two, rather than burn networks in order to fudge some kind of human readability out of it and sacrificing your address space to get it. > > % printf "%04x\n" 4095 > 0fff > % printf "%d\n" 0x0fff > 4095 > > -- > Nathan Ward Maybe so. Right now we convert VLAN IDs to IPv4 3rd octet. Every access switch gets a dedicated set of VLANs along these lines: 48, 348, 648, 1048 etc. That leaves space for 128 access switches per POP, without having to think about anything. The not having to think part is significant, as it trades human engineering for address space. That is also one of our goals for IPv6 deployment. -- Tim:> From tdurack at gmail.com Tue Jan 26 09:43:22 2010 From: tdurack at gmail.com (Tim Durack) Date: Tue, 26 Jan 2010 10:43:22 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001251955mb692effhf643c141f2378da3@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> <75cb24521001251955mb692effhf643c141f2378da3@mail.gmail.com> Message-ID: <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow wrote: > some of what you're saying (tim) here is that you could: (one of these) > > 1) go to all your remote-office ISP's and get a /48 from each > 2) go to *RIR's and get / to cover the number of remote > sites you have in their region(s) > 3) keep on keepin' on until something better comes along? This isn't really for remote offices, just our large campus sites. > 2) > ?o justification in light of 'unclear' policies for an address block > of the right size. NOTE:I don't think the policies is unclear, but > that could be my misreading of the policies. For me, this seems unclear: 6.5.4.2. Assignment of multiple /48s to a single end site When a single end site requires an additional /48 address block, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR level. Note: There is no experience at the present time with the assignment of multiple /48s to the same end site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. > ?o will your remote-office's ISP's accept the /48's per site? (vz/vzb > is a standout example here) Not too worried about VZ. Given that large content providers are getting end-site address space, I think they will have to adjust their stance. > ?o will your remote-office's have full reachability to the parts of > the network they need access to? (remote ISP's filtering at/above the > /48 boundary) Remote offices aren't included in this plan. > For the Enterprise still used to v4-land ipv6 isn't a win yet... for > an ISP it's relatively[0] simple. > > -Chris > > 0: address interfaces, turn up protocols, add 'security' assign > customers /48's...(yes fight bugs/problems/'why is there a colon in my > ip address?" > > (what if you do have 200 offices in the US which aren't connected on a > private network today?) > -- Tim:> Sent from Brooklyn, NY, United States From reygue at gmail.com Tue Jan 26 10:08:43 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Tue, 26 Jan 2010 11:08:43 -0500 Subject: unreachable Sites Message-ID: <9ab36b821001260808i46841b2cl2f6d8941dd26225@mail.gmail.com> I have been notified this morning by several people that there is some websites that are unreachable from Haiti: http://www.hostcentric.com, http://www.gama.ht those are examples. It happens with different ISP. When we change th DNS using the google one 8.8.8.8 it's ok for some but some others still remain unreachable. Can some of you from the Nanog list check and advise? Thank you -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From tdurack at gmail.com Tue Jan 26 10:13:22 2010 From: tdurack at gmail.com (Tim Durack) Date: Tue, 26 Jan 2010 11:13:22 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100126143657.2271062f@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> Message-ID: <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> On Mon, Jan 25, 2010 at 11:06 PM, Mark Smith wrote: > On Mon, 25 Jan 2010 15:15:55 -0500 > "TJ" wrote: >> I didn't realize "human friendly" was even a nominal design consideration, >> especially as different humans have different tolerances for defining >> "friendly" ?:) >> > > This from people who can probably do decimal to binary conversion > and back again for IPv4 subnetting in their head and are proud of > it. Surely IPv6 hex to binary and back again can be the new party > trick? :-) Maybe we can all do this stuff in our head, but I have found removing unnecessary thinking from the equation is useful for those "3am" moments. Given that I am assigning a /48 to a site anyway, and 65k /64s is "more than I will ever need", does it really matter if the site-specific numbering plan isn't ruthlessly efficient? -- Tim:> Sent from Brooklyn, NY, United States From nanog at darkpixel.com Tue Jan 26 10:22:50 2010 From: nanog at darkpixel.com (Aaron C. de Bruyn) Date: Tue, 26 Jan 2010 08:22:50 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> <4B5F0243.2040605@ttec.com> Message-ID: <20100126162250.GB4306@chrysalis> On 2010-01-26 at 10:05:29 -0500, Daniel Senie wrote: > If centuries, how many planets and moons will the address space cover? (If we as a species manages to spread beyond this world before we destroy it). Will separate /3's, or subdivisions of subsequent /3's, be the best approach to deploying a large-scale IPv6 network on Mars? (and yes, a bit of work would be required to make the round-trip times fall within TCP's windows). Someone's going to have to update RFC2549 to address 'IP over Ansible'? ;) -A From reygue at gmail.com Tue Jan 26 10:40:35 2010 From: reygue at gmail.com (Reynold Guerrier) Date: Tue, 26 Jan 2010 11:40:35 -0500 Subject: unreachable Sites In-Reply-To: <00ed01ca9ea5$3558e090$a00aa1b0$@net> References: <9ab36b821001260808i46841b2cl2f6d8941dd26225@mail.gmail.com> <00ed01ca9ea5$3558e090$a00aa1b0$@net> Message-ID: <9ab36b821001260840k1c5b05e5m961a67bba0579c4d@mail.gmail.com> It's Ok Now. Thanks for your replies. reynold On Tue, Jan 26, 2010 at 11:32 AM, Scott Berkman wrote: > I was able to reach both of these from where I sit in Atlanta. > > -Scott > > -----Original Message----- > From: Reynold Guerrier [mailto:reygue at gmail.com] > Sent: Tuesday, January 26, 2010 11:09 AM > To: NANOG list > Subject: unreachable Sites > > I have been notified this morning by several people that there is some > websites that are unreachable from Haiti: http://www.hostcentric.com, > http://www.gama.ht those are examples. It happens with different ISP. When > we change th DNS using the google one 8.8.8.8 it's ok for some but some > others still remain unreachable. Can some of you from the Nanog list check > and advise? > > Thank you > > -- > =================================== > Reynold Guerrier > IT Consultant > 509-3446-0099 > IM: reygue at hotmail.com > Skype: reygji > > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From rbonica at juniper.net Tue Jan 26 10:50:22 2010 From: rbonica at juniper.net (Ron Bonica) Date: Tue, 26 Jan 2010 11:50:22 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> Message-ID: <4B5F1D4E.1090603@juniper.net> Chris, Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG mailing list. But please do chime in. Operator input very welcomed. Ron Christopher Morrow wrote: > On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler > wrote: >> Hi >> >> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >> >> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >> >> So what do you think? Good? Bad? Ugly? /127 ? ;) > > draft-kohno-ipv6-prefixlen-p2p-00.txt > > () > > why not just ping your vendors to support this, and perhaps chime in > on v6ops about wanting to do something sane with ptp link addressing? > :) > > -Chris > > From sethm at rollernet.us Tue Jan 26 11:08:51 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 Jan 2010 09:08:51 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> <75cb24521001251955mb692effhf643c141f2378da3@mail.gmail.com> <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> Message-ID: <4B5F21A3.7000705@rollernet.us> On 1/26/10 7:43 AM, Tim Durack wrote: >> o will your remote-office's ISP's accept the /48's per site? (vz/vzb >> > is a standout example here) > Not too worried about VZ. Given that large content providers are > getting end-site address space, I think they will have to adjust their > stance. > However, they are claiming their own size (i.e. we're bigger) as one reason not to allow anything smaller than a /32. ~Seth From morrowc.lists at gmail.com Tue Jan 26 11:16:06 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Jan 2010 12:16:06 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5F1D4E.1090603@juniper.net> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <75cb24521001231708q11d611f2g6cb9005d2a4039f@mail.gmail.com> <4B5F1D4E.1090603@juniper.net> Message-ID: <75cb24521001260916o14504219ke1db15166319b26d@mail.gmail.com> On Tue, Jan 26, 2010 at 11:50 AM, Ron Bonica wrote: > Chris, > > Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG > mailing list. But please do chime in. Operator input very welcomed. oh damned it! almost as many v6 ietf mailing lists as there are v6 addresses :( subscribe info: Thanks! -Chris > Christopher Morrow wrote: >> On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler >> wrote: >>> Hi >>> >>> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. >>> >>> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>> >>> So what do you think? Good? Bad? Ugly? /127 ? ;) >> >> draft-kohno-ipv6-prefixlen-p2p-00.txt >> >> () >> >> why not just ping your vendors to support this, and perhaps chime in >> on v6ops about wanting to do something sane with ptp link addressing? >> :) >> >> -Chris >> >> > From Grzegorz at Janoszka.pl Tue Jan 26 11:22:25 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Tue, 26 Jan 2010 18:22:25 +0100 Subject: Using /126 for IPv6 router links In-Reply-To: <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> Message-ID: <4B5F24D1.3040209@Janoszka.pl> On 26-1-2010 1:33, Owen DeLong wrote: >> - "Waste" of addresses >> - Peer address needs to be known, impossible to guess with 2^64 addresses > Most of us use ::1 for the assigning side and ::2 for the non-assigning side of > the connection. On multipoints, such as exchanges, the popular alternative is > to use either the BCD of the ASN or the hex of the ASN for your first connection > and something like ::1:AS:N for subsequent connections. If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address. -- Grzegorz Janoszka From morrowc.lists at gmail.com Tue Jan 26 11:23:42 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Jan 2010 12:23:42 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> <75cb24521001251955mb692effhf643c141f2378da3@mail.gmail.com> <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> Message-ID: <75cb24521001260923w5b661547n946feabd3851e902@mail.gmail.com> On Tue, Jan 26, 2010 at 10:43 AM, Tim Durack wrote: > On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow > wrote: >> some of what you're saying (tim) here is that you could: (one of these) >> >> 1) go to all your remote-office ISP's and get a /48 from each >> 2) go to *RIR's and get / to cover the number of remote >> sites you have in their region(s) >> 3) keep on keepin' on until something better comes along? > > This isn't really for remote offices, just our large campus sites. ok, cool... but they'll need to connect to remote offices? or is that just not something you all do? > >> 2) >> ?o justification in light of 'unclear' policies for an address block >> of the right size. NOTE:I don't think the policies is unclear, but >> that could be my misreading of the policies. > > For me, this seems unclear: > > 6.5.4.2. Assignment of multiple /48s to a single end site > When a single end site requires an additional /48 address block, it > must request the assignment with documentation or materials that > justify the request. Requests for multiple or additional /48s will be > processed and reviewed (i.e., evaluation of justification) at the RIR > level. > Note: There is no experience at the present time with the assignment > of multiple /48s to the same end site. Having the RIR review all such > assignments is intended to be a temporary measure until some > experience has been gained and some common policies can be developed. > In addition, additional work at defining policies in this space will > likely be carried out in the near future. I always read this as 'end site' == 'street address'. So, if you have an office at 123 any st, elbonia, IN. and that gets large enough that you have 66k subnets and thus need another /48... you'd have to document the reasoning for that. If you have 12 sites though, each at different locations and were applying for PI space, it seems you'd ask for a /44 or something like that... (assuming no growth) >> ?o will your remote-office's ISP's accept the /48's per site? (vz/vzb >> is a standout example here) > > Not too worried about VZ. Given that large content providers are > getting end-site address space, I think they will have to adjust their > stance. most of the large content folks just got +/32 not PI /48's... or 'yahoo and google'. I'm not sure what Akamai's plan is, they often seem, in the v4 world, to use PA space so maybe that model works for them in v6 as well. I agree that eventually vz will most likely change their stance, but until then, and for the sites who don't have an incentive to change... > >> ?o will your remote-office's have full reachability to the parts of >> the network they need access to? (remote ISP's filtering at/above the >> /48 boundary) > > Remote offices aren't included in this plan. ok... don't have them or don't plan on having them? -Chris >> For the Enterprise still used to v4-land ipv6 isn't a win yet... for >> an ISP it's relatively[0] simple. >> >> -Chris >> >> 0: address interfaces, turn up protocols, add 'security' assign >> customers /48's...(yes fight bugs/problems/'why is there a colon in my >> ip address?" >> >> (what if you do have 200 offices in the US which aren't connected on a >> private network today?) >> > > -- > Tim:> > Sent from Brooklyn, NY, United States > From gerald at intelliguardit.net Tue Jan 26 11:56:14 2010 From: gerald at intelliguardit.net (Gerald Wluka) Date: Tue, 26 Jan 2010 09:56:14 -0800 Subject: DDoS mitigation recommendations Message-ID: <27BED7F5903A42048E53C9E5A589E085@dalap> I am new to this mailing list - this should be a response to an already started thread that I cannot see: IntelliguardIT has a new class of network appliance that installs inline (layer 2 appliance). It has no impact on current network capacity and automatically manages flash crowds gracefully. To date the company has over-invested in technology and under-invested in sales and marketing. That is changing now: the company is moving to The Bay Area. As a testament to this over-investment we have a few customers in Asia who had CiscoGuard and/or Arbor Network solutions deployed - they were failing! IntelliGuard's solution solved their DDoS problems. If you would like to learn more please contact me directly (the IntelliGuardIT website is quite dated at this stage. Thanks, ..Gerald From ryan at hack.net Tue Jan 26 11:59:52 2010 From: ryan at hack.net (Ryan Brooks) Date: Tue, 26 Jan 2010 11:59:52 -0600 Subject: DDoS mitigation recommendations In-Reply-To: <27BED7F5903A42048E53C9E5A589E085@dalap> References: <27BED7F5903A42048E53C9E5A589E085@dalap> Message-ID: <4B5F2D98.7060703@hack.net> On 1/26/10 11:56 AM, Gerald Wluka wrote: > > > I am new to this mailing list We can tell. > - this should be a response to an already > started thread that I cannot see: > > > > > From owen at delong.com Tue Jan 26 12:21:02 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jan 2010 10:21:02 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5F0243.2040605@ttec.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> <4B5F0243.2040605@ttec.com> Message-ID: <3CE5FE02-79C6-421C-8469-68CFCCBBB6C1@delong.com> On Jan 26, 2010, at 6:54 AM, Joe Maimon wrote: > > > Owen DeLong wrote: >> > >> No, they're not impossible to exhaust, just pretty difficult. >> >> However, If we see exhaustion coming too soon in this /3, we can always apply a more conservative >> numbering policy to the next /3. (And still have 5 /3s left to innovate and try other alternatives). >> >> Owen >> > > > Owen, > > We have had this conversation before, but I just wanted to put my two cents out there again. > > I dont view /3 as a safety valve. I view it as a possible escape pod from a sinking ship. > > If it needs to be utilized, the entire world has been dealt a large disservice - something great pains should be taken to avoid. I doubt it would be an "oops, ime sorry, no harm done". > > It should not be a factor to add risk into allocation design. > > Furthermore, any allocation holder trying the same trick of reserving a greater than half of their block for the safety valve in their numbering scheme might quickly discover that their block is a bit more cramped than they thought it would be. > > For me, the entire debate boils down to this question. > > What should the objective be, decades or centuries? > > Joe Decades... I think that a combination of other factors will likely conspire within decades to render the current IPv6 protocol obsolete and drive adoption of a replacement protocol. I don't know what those factors are, but, historically, few things in technology have stood the test of decades. Almost nothing has stood the test of centuries. Owen From owen at delong.com Tue Jan 26 12:35:21 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jan 2010 10:35:21 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <9e246b4d1001251826p6a446247oc7bc82fab2dba692@mail.gmail.com> <75cb24521001251955mb692effhf643c141f2378da3@mail.gmail.com> <9e246b4d1001260743r4b7caca8h40e50c58a9bce429@mail.gmail.com> Message-ID: <41E49D43-6BB6-4DEB-B6EE-5507DED6DD71@delong.com> On Jan 26, 2010, at 7:43 AM, Tim Durack wrote: > On Mon, Jan 25, 2010 at 10:55 PM, Christopher Morrow > wrote: >> some of what you're saying (tim) here is that you could: (one of these) >> >> 1) go to all your remote-office ISP's and get a /48 from each >> 2) go to *RIR's and get / to cover the number of remote >> sites you have in their region(s) >> 3) keep on keepin' on until something better comes along? > > This isn't really for remote offices, just our large campus sites. > >> 2) >> o justification in light of 'unclear' policies for an address block >> of the right size. NOTE:I don't think the policies is unclear, but >> that could be my misreading of the policies. > > For me, this seems unclear: > > 6.5.4.2. Assignment of multiple /48s to a single end site > When a single end site requires an additional /48 address block, it > must request the assignment with documentation or materials that > justify the request. Requests for multiple or additional /48s will be > processed and reviewed (i.e., evaluation of justification) at the RIR > level. > Note: There is no experience at the present time with the assignment > of multiple /48s to the same end site. Having the RIR review all such > assignments is intended to be a temporary measure until some > experience has been gained and some common policies can be developed. > In addition, additional work at defining policies in this space will > likely be carried out in the near future. > I think that is one of the things that is likely to get significantly clarified (and largely eliminated) if any of several current policy proposals are adopted. Anyone here who has an opinion on this should probably subscribe to the ARIN PPML and review the policy proposals under discussion. Your comments would be most useful in determining the best course of action. >> o will your remote-office's ISP's accept the /48's per site? (vz/vzb >> is a standout example here) > > Not too worried about VZ. Given that large content providers are > getting end-site address space, I think they will have to adjust their > stance. > :-) >> o will your remote-office's have full reachability to the parts of >> the network they need access to? (remote ISP's filtering at/above the >> /48 boundary) > > Remote offices aren't included in this plan. > If you have them, they should be. > Owen From owen at delong.com Tue Jan 26 12:55:50 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jan 2010 10:55:50 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5F24D1.3040209@Janoszka.pl> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> <4B5F24D1.3040209@Janoszka.pl> Message-ID: On Jan 26, 2010, at 9:22 AM, Grzegorz Janoszka wrote: > On 26-1-2010 1:33, Owen DeLong wrote: >>> - "Waste" of addresses >>> - Peer address needs to be known, impossible to guess with 2^64 addresses >> Most of us use ::1 for the assigning side and ::2 for the non-assigning side of >> the connection. On multipoints, such as exchanges, the popular alternative is >> to use either the BCD of the ASN or the hex of the ASN for your first connection >> and something like ::1:AS:N for subsequent connections. > > If you have shared racks with different customers within, you can use 16 or 32 bits out of 64 as customer ID, allowing the customer to use the rest, so in fact giving him trillions (possible) IP's for one server. > It can be use with autoconfiguration which always has FF:FE in the middle - you just use some other bits here for your customer assignments. Thus you identify a customer just by looking at the IP address. > Even with shared racks, I'd never implement shared network segments between customers. That's just asking for terrible problems. It can't be used with autoconfiguration because the other 48 bits in the autoconf address are the customer's MAC address, and won't be the customer ID. Owen > -- > Grzegorz Janoszka From steve at ibctech.ca Tue Jan 26 13:24:40 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 26 Jan 2010 14:24:40 -0500 Subject: Enhancing automation with network growth In-Reply-To: <4B57C1FA.5000207@ibctech.ca> References: <4B57C1FA.5000207@ibctech.ca> Message-ID: <4B5F4178.8090407@ibctech.ca> Steve Bertrand wrote: > Can anyone offer up ideas on how you manage any automation in this > regard for their infrastructure gear traffic graphs? (Commercial options > welcome, off-list, but we're as small as our budget is). By popular request, a list of the most suggested software packages. Some were more related to network management in general as opposed to traffic graphic, but - netdisco which I've already got up and running. Although I've only added a few of our devices so far, I can see already how this will be an extremely valuable multi-purpose tool - rancid which I've been using for quite some time already for config management - cacti which I'm strongly considering installing/testing - opennms which appears that it will duplicate many functions I already have deployed on the network (and that I'm happy with), but I may give it a try anyway. If I don't use it, I've got a few 'on the side' clients that could benefit from this all-inclusive package - snmpstat which I may install and test, if only to look at a replacement for my custom BGP peering alerting system - MRTG, with a custom cfgmaker. This was my original idea. If those who recommended this could/are allowed to share their code, please let me know - netflow v9 the majority of my devices don't support this (unfortunately) - bandwidthd already in use for protocol based statistics. This doesn't run full-time in our network, I usually only drop it into place on a span port if I see sustained extreme increases of traffic on a link - IPPlan been using it for a few years Some software supports IPv6, others don't (or have limited capability). Polling IPv6 accounting isn't possible via SNMP, so using scripts with SSH/Telnet access is the only way around that problem for a lot of gear. Cheers, and thanks! Steve From jul_bsd at yahoo.fr Tue Jan 26 13:54:23 2010 From: jul_bsd at yahoo.fr (jul) Date: Tue, 26 Jan 2010 20:54:23 +0100 Subject: DDoS mitigation recommendations In-Reply-To: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> Message-ID: <4B5F486F.7030604@yahoo.fr> Sorry but RTFM http://mailman.nanog.org/pipermail/nanog/2010-January/thread.html#16675 Best regards From braaen at zcorum.com Tue Jan 26 14:09:14 2010 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 26 Jan 2010 15:09:14 -0500 Subject: DDoS mitigation recommendations In-Reply-To: <4B5F2D98.7060703@hack.net> References: <27BED7F5903A42048E53C9E5A589E085@dalap> <4B5F2D98.7060703@hack.net> Message-ID: <201001261509.14948.braaen@zcorum.com> On Tuesday 26 January 2010, Ryan Brooks wrote: > On 1/26/10 11:56 AM, Gerald Wluka wrote: > > > > > > I am new to this mailing list > We can tell. > > - this should be a response to an already > > started thread that I cannot see: > > > > > > > > > > > > > > Ha, that's great. When will vendors learn that blatant and subtle ads tick this group of people off and make us want to NOT buy their products. I don't mind vendors hanging out on this list as some of them are useful posters, but cut out all the marketing junk and present "just the facts". It is interesting to see Cisco dropping this product though since all their CCDA materials seem to push a loaded 6500 with these options. -- ---------------------- Brian Raaen Network Engineer braaen at zcorum.com From andrey.gordon at gmail.com Tue Jan 26 14:35:21 2010 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Tue, 26 Jan 2010 15:35:21 -0500 Subject: IOS family naming Message-ID: <90ccfc91001261235j12609079o2f904b63d357d258@mail.gmail.com> Hi List, Anyone recalls ever seeing the IOS naming convention document. In particular I'm interested in differences between families and trains. This is all I found: http://www.cisco.com/warp/public/620/1.html#topic1 But im looking for something a bit more recent maybe? Can figure out differences between say SG, SGA, EW and EWA. A link to the cipher would certainly help. ----- Andrey Gordon [andrey.gordon at gmail.com] From arievayner at gmail.com Tue Jan 26 15:21:27 2010 From: arievayner at gmail.com (Arie Vayner) Date: Tue, 26 Jan 2010 23:21:27 +0200 Subject: IOS family naming In-Reply-To: <90ccfc91001261235j12609079o2f904b63d357d258@mail.gmail.com> References: <90ccfc91001261235j12609079o2f904b63d357d258@mail.gmail.com> Message-ID: <20b13c6b1001261321q486f1117w8973b01e6e642d43@mail.gmail.com> Andrey, I could not find a good link, but let me give you some info on SG, SGA, EW and EWA. All these trains are for the 4500 family (including 4900). They are just different generations. The EW (and then EWA) were the older trains for 4500, which were replaced by the SG trains. If I am not too wrong EW/EWA was new around 2004. SGA was the 1st release for the SG train, but later releases are not called SGB/SGC, but are just marked SG, so you get 12.2(31)SGA as the first release (with 12.2(31)SGA1, 12.2(31)SGA2 etc being maintenance releases, with SGA11 scheduled to be released in a few weeks). The later SG releases are numbered as 12.2(37)SG, 12.2(40)SG, etc - and we have 12.2(53)SG as the latest one. Each such release brings in new features, and has its own maintenance releases (so it would be 12.2(53)SG1, 12.2(53)SG2 etc, with 12.2(53)GS2 being scheduled for the Q2CY10) Hope this gives you a better view. Arie On Tue, Jan 26, 2010 at 10:35 PM, Andrey Gordon wrote: > Hi List, > Anyone recalls ever seeing the IOS naming convention document. In > particular > I'm interested in differences between families and trains. > > This is all I found: > http://www.cisco.com/warp/public/620/1.html#topic1 > > But im looking for something a bit more recent maybe? Can figure out > differences between say SG, SGA, EW and EWA. > > A link to the cipher would certainly help. > > ----- > Andrey Gordon [andrey.gordon at gmail.com] > From pdavis at i2k.com Tue Jan 26 15:27:08 2010 From: pdavis at i2k.com (Philip Davis) Date: Tue, 26 Jan 2010 16:27:08 -0500 Subject: IOS family naming In-Reply-To: <20b13c6b1001261321q486f1117w8973b01e6e642d43@mail.gmail.com> References: <90ccfc91001261235j12609079o2f904b63d357d258@mail.gmail.com> <20b13c6b1001261321q486f1117w8973b01e6e642d43@mail.gmail.com> Message-ID: <4B5F5E2C.9000200@i2k.com> Not sure how relevant this still is, but it explains some of the older ones. http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080101cda.shtml On 1/26/2010 4:21 PM, Arie Vayner wrote: > Andrey, > > I could not find a good link, but let me give you some info on SG, SGA, EW > and EWA. > All these trains are for the 4500 family (including 4900). They are just > different generations. > > The EW (and then EWA) were the older trains for 4500, which were replaced by > the SG trains. > If I am not too wrong EW/EWA was new around 2004. > > SGA was the 1st release for the SG train, but later releases are not called > SGB/SGC, but are just marked SG, so you get 12.2(31)SGA as the first release > (with 12.2(31)SGA1, 12.2(31)SGA2 etc being maintenance releases, with SGA11 > scheduled to be released in a few weeks). > > The later SG releases are numbered as 12.2(37)SG, 12.2(40)SG, etc - and we > have 12.2(53)SG as the latest one. Each such release brings in new features, > and has its own maintenance releases (so it would be 12.2(53)SG1, > 12.2(53)SG2 etc, with 12.2(53)GS2 being scheduled for the Q2CY10) > > Hope this gives you a better view. > > Arie > > On Tue, Jan 26, 2010 at 10:35 PM, Andrey Gordon wrote: > >> Hi List, >> Anyone recalls ever seeing the IOS naming convention document. In >> particular >> I'm interested in differences between families and trains. >> >> This is all I found: >> http://www.cisco.com/warp/public/620/1.html#topic1 >> >> But im looking for something a bit more recent maybe? Can figure out >> differences between say SG, SGA, EW and EWA. >> >> A link to the cipher would certainly help. >> >> ----- >> Andrey Gordon [andrey.gordon at gmail.com] >> -- Philip Davis Systems Administrator I-2000 Inc. (616) 532-8425 888-234-4254 From standalone.sysadmin at gmail.com Tue Jan 26 15:55:17 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Tue, 26 Jan 2010 16:55:17 -0500 Subject: IOS family naming In-Reply-To: <4B5F5E2C.9000200@i2k.com> References: <90ccfc91001261235j12609079o2f904b63d357d258@mail.gmail.com> <20b13c6b1001261321q486f1117w8973b01e6e642d43@mail.gmail.com> <4B5F5E2C.9000200@i2k.com> Message-ID: <5bcb62b61001261355y3f2a501k6defa19601c6544b@mail.gmail.com> Have you checked out the IOS Feature Navigator? http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp On Tue, Jan 26, 2010 at 4:27 PM, Philip Davis wrote: > Not sure how relevant this still is, but it explains some of the older ones. > > http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080101cda.shtml > > On 1/26/2010 4:21 PM, Arie Vayner wrote: >> Andrey, >> >> I could not find a good link, but let me give you some info on SG, SGA, EW >> and EWA. >> All these trains are for the 4500 family (including 4900). They are just >> different generations. >> >> The EW (and then EWA) were the older trains for 4500, which were replaced by >> the SG trains. >> If I am not too wrong EW/EWA was new around 2004. >> >> SGA was the 1st release for the SG train, but later releases are not called >> SGB/SGC, but are just marked SG, so you get 12.2(31)SGA as the first release >> (with 12.2(31)SGA1, 12.2(31)SGA2 etc being maintenance releases, with SGA11 >> scheduled to be released in a few weeks). >> >> The later SG releases are numbered as 12.2(37)SG, 12.2(40)SG, etc - and we >> have 12.2(53)SG as the latest one. Each such release brings in new features, >> and has its own maintenance releases (so it would be 12.2(53)SG1, >> 12.2(53)SG2 etc, with 12.2(53)GS2 being scheduled for the Q2CY10) >> >> Hope this gives you a better view. >> >> Arie >> >> On Tue, Jan 26, 2010 at 10:35 PM, Andrey Gordon wrote: >> >>> Hi List, >>> Anyone recalls ever seeing the IOS naming convention document. In >>> particular >>> I'm interested in differences between families and trains. >>> >>> This is all I found: >>> http://www.cisco.com/warp/public/620/1.html#topic1 >>> >>> But im looking for something a bit more recent maybe? Can figure out >>> differences between say SG, SGA, EW and EWA. >>> >>> A link to the cipher would certainly help. >>> >>> ----- >>> Andrey Gordon [andrey.gordon at gmail.com] >>> > > > -- > > Philip Davis > Systems Administrator > I-2000 Inc. > (616) 532-8425 > 888-234-4254 > > -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. From martin at theicelandguy.com Tue Jan 26 16:03:51 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 26 Jan 2010 17:03:51 -0500 Subject: unreachable Sites In-Reply-To: <9ab36b821001260808i46841b2cl2f6d8941dd26225@mail.gmail.com> References: <9ab36b821001260808i46841b2cl2f6d8941dd26225@mail.gmail.com> Message-ID: On Tue, Jan 26, 2010 at 11:08 AM, Reynold Guerrier wrote: > I have been notified this morning by several people that there is some > websites that are unreachable from Haiti: http://www.hostcentric.com, > http://www.gama.ht those are examples. It happens with different ISP. When > we change th DNS using the google one 8.8.8.8 it's ok for some but some > others still remain unreachable. Can some of you from the Nanog list check > and advise? > > You could always use OpenDNS as an alternative, especially to debug a problem with the service. I don't know their resolver addresses off of the top of my head (sorry David), but I'm sure that it's easy to find them either here, https://store.opendns.com/get/basic or perhaps someone could email them to you offline. Best Regards, -M< -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From igor at gashinsky.net Tue Jan 26 18:33:17 2010 From: igor at gashinsky.net (Igor Gashinsky) Date: Tue, 26 Jan 2010 19:33:17 -0500 (EST) Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: On Mon, 25 Jan 2010, Matt Addison wrote: :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for :: each PtP link, but only configure the first /126 (or whatever /126 you :: need to get an amusing peer address) on the link. Matt meant "reserve/assign a /64 for each PtP link, but only configure the first */127* of the link", as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... -igor From steve at ibctech.ca Tue Jan 26 19:16:45 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 26 Jan 2010 20:16:45 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: <4B5F93FD.6080600@ibctech.ca> Igor Gashinsky wrote: > On Mon, 25 Jan 2010, Matt Addison wrote: > > :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for > :: each PtP link, but only configure the first /126 (or whatever /126 you > :: need to get an amusing peer address) on the link. > > Matt meant "reserve/assign a /64 for each PtP link, but only configure the > first */127* of the link", as that's the only way to fully mitigate the > scanning-type attacks (with a /126, there is still the possibility of > ping-pong on a p-t-p interface) w/o using extensive ACLs.. > > Anyways, that's what worked for us, and, as always, YMMV... As always, I'm looking for better ways to do things. I've been using /64 eui-64 on P-PE PtP Ethernet links (and /64 static on PE-CE) since I first delved into IPv6, as (for me) it makes hardware replacement/link relocation very easy, and documentation simple. ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. I don't think I'm quite grasping the entire security concern here. Actually, I'd like to re-word that... I do grasp the attack vector to a certain degree, but there *must* be a way to use entire /64's on ptp links without having to use manual ACL management. Personally, I am all for using /64s for this purpose, as that's how I understand the intention of the protocol. Whether I use a complete /64 within a ptp (particularly Ethernet), or lob off a /127 (or /126) for the purpose, I'll always keep that entire /64 'specifically reserved for that purpose' either way. Would be interesting to hear ideas on how this particular /64 on ptp attack vector could be nullified by using existing known solutions. I'm thinking blackhole, but can't (at this time) think how that could be done by default with existing configuration within the scope of a ptp link. Steve From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 26 22:44:25 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Jan 2010 15:14:25 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <254494.83717.qm@web31802.mail.mud.yahoo.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <1CC01FF8-A78D-4F5F-B2D4-8369F5B6B639@delong.com> <75cb24521001251934g4b2aa692m36dfde053e62bf8a@mail.gmail.com> <20100126191434.79cd11e1@opy.nosense.org> <254494.83717.qm@web31802.mail.mud.yahoo.com> Message-ID: <20100127151425.5b34698c@opy.nosense.org> On Tue, 26 Jan 2010 06:38:43 -0800 (PST) David Barak wrote: > From: Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org > > >Why can't IPv6 node addressing be as easy to understand and work with > >as Ethernet addresses? They were designed in the early 1980s*. 28 years > >or so years later, it's time for layer 3 addressing to catch up. > > Becase Ethernet addresses are only locally significant, are not manually assigned in the vast majority of cases, That makes them globally significant - and that's what makes them 'plug-and-play'. Ethernet addresses are bigger than they operationally need to be, and the 'plug-and-play' nature of them is what we got for that price. That being said, my comment is not specifically about how Ethernet addressing works, it is about how easy Ethernet addressing is to use. It was a rhetorical question. I think it'd be a tragedy if IPv6 addressing is harder to work with than than Ethernet, Appletalk, IPX and a number of other protocols designed at least 10 years or more before it. I really don't understand why people seem so keen on making IPv6 addressing's model look like IPv4's when the primary reason for IPv4's addressing models was the severe lack of address space. btw, did you read the paper I linked too? > and changing a MAC by replacing a NIC has no bearing on the > configuration of a { server | router ACL | etc }. > > Layer 3 addressing is globally significant, and the case we're discussing is addresses which are human-assigned rather than automatically configured.? Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty much the way I would want it to.??Global addressing approaches, on the other hand, are highly optimized in directions which make them less flexible or have surprising consequences (hence this thread). > David Barak > Need Geek Rock? Try The Franchise: > http://www.listentothefranchise.com > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 26 22:53:38 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Jan 2010 15:23:38 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> Message-ID: <20100127152338.1bbfaf5d@opy.nosense.org> On Tue, 26 Jan 2010 11:13:22 -0500 Tim Durack wrote: > On Mon, Jan 25, 2010 at 11:06 PM, Mark Smith > wrote: > > On Mon, 25 Jan 2010 15:15:55 -0500 > > "TJ" wrote: > > >> I didn't realize "human friendly" was even a nominal design consideration, > >> especially as different humans have different tolerances for defining > >> "friendly" ?:) > >> > > > > This from people who can probably do decimal to binary conversion > > and back again for IPv4 subnetting in their head and are proud of > > it. Surely IPv6 hex to binary and back again can be the new party > > trick? :-) > > Maybe we can all do this stuff in our head, but I have found removing > unnecessary thinking from the equation is useful for those "3am" > moments. > > Given that I am assigning a /48 to a site anyway, and 65k /64s is > "more than I will ever need", does it really matter if the > site-specific numbering plan isn't ruthlessly efficient? > The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. IOW, it's meant to be "nearly one-size-fits-all", to try to ensure almost everybody gets as much address space as they'll ever need at the time of their first request. An addressing plan for anything less than the largest organsation that doesn't fit within a /48 or will exceed it fairly rapidly is probably too inefficent. ps. Remember that I'm one of the ones advocating using /64s everywhere, so what ever you do, don't use "ruthlessly efficient" to describe my position - use that for the /126 or /127 crowd ;-) Regards, Mark. From morrowc.lists at gmail.com Tue Jan 26 23:11:41 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 27 Jan 2010 00:11:41 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <20100127152338.1bbfaf5d@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> Message-ID: <75cb24521001262111o97caa6y76b580e9a24d09e4@mail.gmail.com> On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith wrote: > > The general intent of the /48 allocation is that it is large enough for > nearly everybody, with nearly everybody including all but the largest 'nearly everybody with a single site' sure. I know of more than a few VPN deployments (enterprises with remote offices) that have +1k remote sites. For these you're quickly talking about: 1) get PA (maybe, maybe not a good plan, see renumbering headaches) 2) get a large number of /48's (assume median size is 2048 - 1 /36) I know of one vpn deployment with +12k sites: a /34 I agree that a large majority of 'end sites' (enterprises) will be services with a single /48 from PA space, unless they want to multihome, or have more than 1 site and want some convenience. > of organisations. IOW, it's meant to be "nearly one-size-fits-all", to > try to ensure almost everybody gets as much address space as they'll > ever need at the time of their first request. An addressing plan for > anything less than the largest organsation that doesn't fit within > a /48 or will exceed it fairly rapidly is probably too inefficent. > > ps. Remember that I'm one of the ones advocating using /64s everywhere, > so what ever you do, don't use "ruthlessly efficient" to describe my > position - use that for the /126 or /127 crowd ;-) I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is done today' and 'there be dragons, be aware what you step into'. I think, and I'll start a fresh copy of this thread to articulate it, there have been 4-5 different issue conflated in this discussion, which is making things complicated. -Chris > > > Regards, > Mark. > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Jan 26 23:34:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Jan 2010 16:04:01 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <75cb24521001262111o97caa6y76b580e9a24d09e4@mail.gmail.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <75cb24521001262111o97caa6y76b580e9a24d09e4@mail.gmail.com> Message-ID: <20100127160401.1a963a56@opy.nosense.org> On Wed, 27 Jan 2010 00:11:41 -0500 Christopher Morrow wrote: > On Tue, Jan 26, 2010 at 11:53 PM, Mark Smith > wrote: > > > > > The general intent of the /48 allocation is that it is large enough for > > nearly everybody, with nearly everybody including all but the largest > > 'nearly everybody with a single site' sure. I know of more than a few > VPN deployments (enterprises with remote offices) that have +1k remote > sites. For these you're quickly talking about: > 1) get PA (maybe, maybe not a good plan, see renumbering headaches) > 2) get a large number of /48's (assume median size is 2048 - 1 /36) > > I know of one vpn deployment with +12k sites: a /34 > If it's in the US, I might have worked on the product that was used to build it about 10 years ago - that had 10K sites. > I agree that a large majority of 'end sites' (enterprises) will be > services with a single /48 from PA space, unless they want to > multihome, or have more than 1 site and want some convenience. > A 'site' is intended to not specifically be geographic. In some respects, it's meant to be a more generic version of IPv4's Autonomous System. A geographic location might suit the boundary in some cases, where as a single large organisation, who may have many internal geographic sites in it's WAN, dual homed to a single ISP, would also qualify as a single /48 "site". > > of organisations. IOW, it's meant to be "nearly one-size-fits-all", to > > try to ensure almost everybody gets as much address space as they'll > > ever need at the time of their first request. An addressing plan for > > anything less than the largest organsation that doesn't fit within > > a /48 or will exceed it fairly rapidly is probably too inefficent. > > > > ps. Remember that I'm one of the ones advocating using /64s everywhere, > > so what ever you do, don't use "ruthlessly efficient" to describe my > > position - use that for the /126 or /127 crowd ;-) > > I'd note I'm not a 'ruthless efficiency' guy either, just 'how ops is > done today' and 'there be dragons, be aware what you step into'. Sure. However I think people are treating IPv6 as just IPv4 with larger addresses, yet not even thinking about what capabilities that larger addressing is giving them that don't or haven't existed in IPv4 for a very long time. People seem to be even ignoring the maths of how big a single /48 is, just in terms subnets. I've never worked on an individual network with 65K subnets (with the Internet being a network of networks), and I doubt many people on this list have. Yet people seem to treating a /48 as though all networks will have 65K subnets, and therefore they'd better start of using longer than /64s because they might run out of subnets. I care about this because I don't want to see people have to change their addressing in the future to /64s, because of that will typically involve a lot of out of hours work (which could include me if I inherit a network that has had longer than /64s deployed (there's my bias)). I'd prefer to see people go the other way - deploy /64s everywhere, as per the IPv6 Addressing Architecture, and if that proves to be the wrong case, then go to the effort of deploying longer prefixes. I think going from /64s to longer prefixes is far less likely going to be needed than the other way around. > I > think, and I'll start a fresh copy of this thread to articulate it, > there have been 4-5 different issue conflated in this discussion, > which is making things complicated. > > -Chris > > > > > > > Regards, > > Mark. > > > > From pekkas at netcore.fi Tue Jan 26 23:47:35 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 27 Jan 2010 07:47:35 +0200 (EET) Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: On Tue, 26 Jan 2010, Igor Gashinsky wrote: > Matt meant "reserve/assign a /64 for each PtP link, but only configure the > first */127* of the link", as that's the only way to fully mitigate the > scanning-type attacks (with a /126, there is still the possibility of > ping-pong on a p-t-p interface) w/o using extensive ACLs.. > > Anyways, that's what worked for us, and, as always, YMMV... That's still relying on the fact that your vendor won't implement subnet-router anycast address and turn it on by default. That would mess up the first address of the link. But I suppose those would be pretty big ifs. -- 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 marka at isc.org Tue Jan 26 23:51:05 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Jan 2010 16:51:05 +1100 Subject: Using /126 for IPv6 router links In-Reply-To: Your message of "Wed, 27 Jan 2010 16:04:01 +1030." <20100127160401.1a963a56@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <75cb24521001262111o97caa6y76b580e9a24d09e4@mail.gmail.com> <20100127160401.1a963a56@opy.nosense.org> Message-ID: <201001270551.o0R5p5dM025565@drugs.dv.isc.org> In message <20100127160401.1a963a56 at opy.nosense.org>, Mark Smith writes: > Sure. However I think people are treating IPv6 as just IPv4 with larger > addresses, yet not even thinking about what capabilities that larger > addressing is giving them that don't or haven't existed in IPv4 for a > very long time. People seem to be even ignoring the maths of how big a > single /48 is, just in terms subnets. I've never worked on an > individual network with 65K subnets (with the Internet being a network > of networks), and I doubt many people on this list have. Yet people > seem to treating a /48 as though all networks will have 65K subnets, > and therefore they'd better start of using longer than /64s because > they might run out of subnets. > > I care about this because I don't want to see people have to change > their addressing in the future to /64s, because of that will typically > involve a lot of out of hours work (which could include me if I > inherit a network that has had longer than /64s deployed (there's my > bias)). I'd prefer to see people go the other way - deploy /64s > everywhere, as per the IPv6 Addressing Architecture, and if that proves > to be the wrong case, then go to the effort of deploying longer > prefixes. I think going from /64s to longer prefixes is far less likely > going to be needed than the other way around. And if you have more than 65K networks you have the justification for a second /48 at which time you can decide whether to request a /47 and renumber into it or just use two non-contiguous /48's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bdikici at gmail.com Wed Jan 27 00:18:18 2010 From: bdikici at gmail.com (Burak Dikici) Date: Wed, 27 Jan 2010 08:18:18 +0200 Subject: Ethernet Services cards types & queue values Message-ID: Hello, There is different types for the Cisco 7600 Series Ethernet Services cards. ( More expensive cards with high queue values and less expensive cards with low queue values.) http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-549419.html Hardware queues ES Plus XT 40G line cards ? 128,000 ingress queues ? 256,000 egress queues ES Plus XT 20G line cards *? 64,000 ingress queues* ? 128,000 egress queues Hierarchical QoS (H-QoS) http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-570730.html Hardware queues Cisco 7600 Series ES Plus Transport 40G and 20G Line Cards *Supporting up to 16 level 4 queues per physical port* Hierarchical QoS (H-QoS) Low queue cards have got only 4 queues per physical port. High queue cards have got minimum 64.000 queue. This is very huge difference. In what kind of scenario do we have to use the High queue cards ? Could you give some examples please ? Kind Regards. Burak From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 27 01:32:51 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Jan 2010 18:02:51 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: <20100127180251.7b60c9a9@opy.nosense.org> On Wed, 27 Jan 2010 07:47:35 +0200 (EET) Pekka Savola wrote: > On Tue, 26 Jan 2010, Igor Gashinsky wrote: > > Matt meant "reserve/assign a /64 for each PtP link, but only configure the > > first */127* of the link", as that's the only way to fully mitigate the > > scanning-type attacks (with a /126, there is still the possibility of > > ping-pong on a p-t-p interface) w/o using extensive ACLs.. > > > > Anyways, that's what worked for us, and, as always, YMMV... > > That's still relying on the fact that your vendor won't implement > subnet-router anycast address and turn it on by default. That would > mess up the first address of the link. But I suppose those would be > pretty big ifs. > A minor data point to this, Linux looks to be implementing the subnet-router anycast address when IPv6 forwarding is enabled, as it's specifying Solicited-Node multicast address membership for the all zeros node address in it's MLD announcements when an interface comes up. > -- > 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 arievayner at gmail.com Wed Jan 27 02:10:43 2010 From: arievayner at gmail.com (Arie Vayner) Date: Wed, 27 Jan 2010 10:10:43 +0200 Subject: Ethernet Services cards types & queue values In-Reply-To: References: Message-ID: <20b13c6b1001270010n11873ad6jb299f73d2035911e@mail.gmail.com> Burak, The idea is that you use the high queue cards as UNI ports terminating customers, where you would have many service instances and complex QOS policies such hierarchical shaping and multiple classes per customer. On the core links you would usually need less queues as you would have a generic aggregated QOS policy. Specifically on the 7600 I think you are looking at the "regular" LAN modules (as opposed to the ES20/ES+ modules) which have the lower queue numbers per port. These modules (the LAN modules) also have more limited functionality support as they do not have the ability to support many features supported only on the ES modules. For some services/features you would require the ES modules to be on either UNI or NNI (depending on what you want to achieve). For ASR9000 there are also a few module types following the same model above. More queues for UNI and less queues (and thus cheaper) for NNI, but in this case supporting all the different features. Arie On Wed, Jan 27, 2010 at 8:18 AM, Burak Dikici wrote: > Hello, > > > There is different types for the Cisco 7600 Series Ethernet Services cards. > ( More expensive cards with high queue values and less expensive cards with > low queue values.) > > > > http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-549419.html > Hardware queues > ES Plus XT 40G line cards > ? 128,000 ingress queues > ? 256,000 egress queues > ES Plus XT 20G line cards > *? 64,000 ingress queues* > ? 128,000 egress queues > Hierarchical QoS (H-QoS) > > > > > > http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-570730.html > Hardware queues > Cisco 7600 Series ES Plus Transport 40G and 20G Line Cards > *Supporting up to 16 level 4 queues per physical port* > Hierarchical QoS (H-QoS) > > > > Low queue cards have got only 4 queues per physical port. High queue cards > have got minimum 64.000 queue. This is very huge difference. In what kind > of scenario do we have to use the High queue cards ? Could you give some > examples please ? Kind Regards. > > > Burak > From igor at gashinsky.net Wed Jan 27 03:12:49 2010 From: igor at gashinsky.net (Igor Gashinsky) Date: Wed, 27 Jan 2010 04:12:49 -0500 (EST) Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: On Wed, 27 Jan 2010, Pekka Savola wrote: :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: > Matt meant "reserve/assign a /64 for each PtP link, but only configure the :: > first */127* of the link", as that's the only way to fully mitigate the :: > scanning-type attacks (with a /126, there is still the possibility of :: > ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: > :: > Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs. Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?).. If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining).. -igor From randy at psg.com Wed Jan 27 04:38:14 2010 From: randy at psg.com (Randy Bush) Date: Wed, 27 Jan 2010 10:38:14 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <20100127152338.1bbfaf5d@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> Message-ID: > The general intent of the /48 allocation is that it is large enough for > nearly everybody, with nearly everybody including all but the largest > of organisations. the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hmmmmm randy From owen at delong.com Wed Jan 27 05:09:11 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Jan 2010 03:09:11 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> Message-ID: <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: >> The general intent of the /48 allocation is that it is large enough for >> nearly everybody, with nearly everybody including all but the largest >> of organisations. > > the general intent of a class B allocation is that it is large enough > for nearly everybody, with nearly everybody including all but the > largest of organisations. > > hmmmmm > > randy That would, indeed, work if we weren't short of class B networks to assign. Owen From steve at ibctech.ca Wed Jan 27 05:16:49 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 27 Jan 2010 06:16:49 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> Message-ID: <4B6020A1.3010500@ibctech.ca> Igor Gashinsky wrote: > On Wed, 27 Jan 2010, Pekka Savola wrote: > > :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: > :: > Matt meant "reserve/assign a /64 for each PtP link, but only configure the > :: > first */127* of the link", as that's the only way to fully mitigate the > :: > scanning-type attacks (with a /126, there is still the possibility of > :: > ping-pong on a p-t-p interface) w/o using extensive ACLs.. > :: > > :: > Anyways, that's what worked for us, and, as always, YMMV... > :: > :: That's still relying on the fact that your vendor won't implement > :: subnet-router anycast address and turn it on by default. That would mess up > :: the first address of the link. But I suppose those would be pretty big ifs. > > Or, relying on the fact that (most) vendors are smart enough not to > enable subnet-router anycast on any interface configured as a /127 (and > those that are not, well, why are you buying their gear?).. > > If a worst-case situation arises, and you have to peer with a device that > doesn't properly support /127's, you can always fall back to using /126's > or even /64's on those few links (this is why we reserved a /64 for every > link from the begining).. If this is the case, why not just use /64s from the beginning? Why bother with hacking it up if it's only going to be reserved anyway? I'm trying to understand how reserving-and-hacking a /64 makes administration any easier. Even if all ptp are coming out of a single /64 (as opposed to reserving a /64 for each), what benefits are there to that? It seems as though that this is v4 thinking. As someone pointed out off-list (I hope you don't mind): "one could argue a bunch of sequential /127s makes it apparent what your infrastructure addresses are. You can just as easily ACL a /48 containing infrastructure /64s as you can ACL a /64 containing infrastructure /127s." ...amen to that, if I can't figure out a way to sink/drop the null addresses first. Steve From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 27 06:38:36 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Jan 2010 23:08:36 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> Message-ID: <20100127230836.3ea9bd03@opy.nosense.org> On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong wrote: > > On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: > > >> The general intent of the /48 allocation is that it is large enough for > >> nearly everybody, with nearly everybody including all but the largest > >> of organisations. > > > > the general intent of a class B allocation is that it is large enough > > for nearly everybody, with nearly everybody including all but the > > largest of organisations. > > > > hmmmmm > > > > randy > > That would, indeed, work if we weren't short of class B networks > to assign. > And we shrunk the Internet. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 27 06:41:38 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Jan 2010 23:11:38 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <20100127230836.3ea9bd03@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> <20100127230836.3ea9bd03@opy.nosense.org> Message-ID: <20100127231138.3a0a86ac@opy.nosense.org> On Wed, 27 Jan 2010 23:08:36 +1030 Mark Smith wrote: > On Wed, 27 Jan 2010 03:09:11 -0800 > Owen DeLong wrote: > > > > > On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: > > > > >> The general intent of the /48 allocation is that it is large enough for > > >> nearly everybody, with nearly everybody including all but the largest > > >> of organisations. > > > > > > the general intent of a class B allocation is that it is large enough > > > for nearly everybody, with nearly everybody including all but the > > > largest of organisations. > > > > > > hmmmmm > > > > > > randy > > > > That would, indeed, work if we weren't short of class B networks > > to assign. > > > > And we shrunk the Internet. > > Should have been "Or" From randy at psg.com Wed Jan 27 06:51:52 2010 From: randy at psg.com (Randy Bush) Date: Wed, 27 Jan 2010 12:51:52 +0000 Subject: Using /126 for IPv6 router links In-Reply-To: <4B602169.8020302@ibctech.ca> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> <4B602169.8020302@ibctech.ca> Message-ID: >>> the general intent of a class B allocation is that it is large enough >>> for nearly everybody, with nearly everybody including all but the >>> largest of organisations. >> That would, indeed, work if we weren't short of class B networks >> to assign. > Would you clarify? Seriously? we used to think we were not short of class B networks randy From marka at isc.org Wed Jan 27 07:26:34 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Jan 2010 00:26:34 +1100 Subject: Using /126 for IPv6 router links In-Reply-To: Your message of "Wed, 27 Jan 2010 12:51:52 -0000." References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> <4B602169.8020302@ibctech.ca> Message-ID: <201001271326.o0RDQYPg033256@drugs.dv.isc.org> In message , Randy Bush writes: > >>> the general intent of a class B allocation is that it is large enough > >>> for nearly everybody, with nearly everybody including all but the > >>> largest of organisations. > >> That would, indeed, work if we weren't short of class B networks > >> to assign. > > Would you clarify? Seriously? > > we used to think we were not short of class B networks Really? Do you have a citation? It should have been clear to anyone that thought about it that IPv4 address where not big enough to support every man and his dog having a network. I know when I was getting my first class B address block in '88 that it was obviously not sustainable but I'll get one while I can because that and class C's were all that were available and it could be justified under the rules as they stood then. CIDR when it came along didn't change my opinion, though it did delay the inevitable as did PNAT. I don't see the same thing with /48 as the basic allocation provided RIR's don't do greenfield all the time but instead re-allocate blocks when they are not maintained. Always doing greenfield allocations will exhaust any allocation scheme in time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jan 27 08:41:30 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 28 Jan 2010 01:11:30 +1030 Subject: Using /126 for IPv6 router links In-Reply-To: <201001271326.o0RDQYPg033256@drugs.dv.isc.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> <4B602169.8020302@ibctech.ca> <201001271326.o0RDQYPg033256@drugs.dv.isc.org> Message-ID: <20100128011130.24f70458@opy.nosense.org> On Thu, 28 Jan 2010 00:26:34 +1100 Mark Andrews wrote: > > In message , Randy Bush writes: > > >>> the general intent of a class B allocation is that it is large enough > > >>> for nearly everybody, with nearly everybody including all but the > > >>> largest of organisations. > > >> That would, indeed, work if we weren't short of class B networks > > >> to assign. > > > Would you clarify? Seriously? > > > > we used to think we were not short of class B networks > > Really? Do you have a citation? It should have been clear to > anyone that thought about it that IPv4 address where not big enough > to support every man and his dog having a network. > If you dig into it a bit, you find that the original addressing plan was a single network octet, and 3 node octets. The earliest document I can find that describes 32 bit IP addresses is Internet Engineering Note 5, March 1977 (http://www.isi.edu/in-notes/ien/ien5.pdf), page 68 (69 of the .pdf), and a diagram on page 74 (page 75 .pdf). IEN 91, May 1979 (http://www.isi.edu/in-notes/ien/ien91.txt), also describes the earliest 32 bit IP address format, and how to map link layer addresses, such as ARPANET addresses into the "Local address" portion. RFC760, January 1980, also specifies that format of addressing. RFC791, September 1981, is where it changed to classes. So IP addresses were structured and deployed with a single network octet and 3 node octets for more than 4 years. I think that is evidence that 32 bit IP addresses were never originally designed to support a world wide network that the Internet has become, that fixed network and node portions are the preferred way to do network addressing (and if you look at all the other protocols that have existed, excepting CLNS (a "fixed" copy of IPv4 apparently), they've all done it that way), and that classes, subnets and then classless addressing have all fundamentally been very been neat hacks to make 32 bit addressing support far more devices than was ever expected. > I know when I was getting my first class B address block in '88 > that it was obviously not sustainable but I'll get one while I can > because that and class C's were all that were available and it could > be justified under the rules as they stood then. > > CIDR when it came along didn't change my opinion, though it did > delay the inevitable as did PNAT. > > I don't see the same thing with /48 as the basic allocation provided > RIR's don't do greenfield all the time but instead re-allocate > blocks when they are not maintained. Always doing greenfield > allocations will exhaust any allocation scheme in time. > > Mark > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > From jimb at jsbc.cc Wed Jan 27 09:39:34 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 27 Jan 2010 07:39:34 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: <20100127180251.7b60c9a9@opy.nosense.org> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <20100127180251.7b60c9a9@opy.nosense.org> Message-ID: <4B605E36.20201@jsbc.cc> On 1/26/2010 23:32, Mark Smith wrote: > > A minor data point to this, Linux looks to be implementing the > subnet-router anycast address when IPv6 forwarding is enabled, as it's > specifying Solicited-Node multicast address membership for the > all zeros node address in it's MLD announcements when an interface > comes up. > > Yes, I believe you are correct. It appears to be implemented. When I ping the subnet anycast from a Linux or Windows XP box I get a reply from the IPv6 router on my LAN. The router is a Linux box running Kernel 2.6.31. Interestingly, on a Linux box, the ping6 command shows the router's unicast address answering the pings (same goes for ping6 under Cygwin on a Windows box). But on a Windows box ping shows the anycast address answering. However, in both cases packet captures show it actually is the unicast address of the router answering, which I believe is the expected behavior. Windows ping just shows the wrong address for whatever reason. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From Grzegorz at Janoszka.pl Wed Jan 27 11:10:17 2010 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Wed, 27 Jan 2010 18:10:17 +0100 Subject: Using /126 for IPv6 router links In-Reply-To: <4B5F93FD.6080600@ibctech.ca> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B5F93FD.6080600@ibctech.ca> Message-ID: <4B607379.1040905@Janoszka.pl> On 27-1-2010 2:16, Steve Bertrand wrote: > ip address x.x.x.x 255.255.255.252 > ipv6 address 2607:F118:x:x::/64 eui-64 > ipv6 nd suppress-ra > ipv6 ospf 1 area 0.0.0.0 > I've found that this setup, in conjunction with iBGP peering between > loopback /128's works well. When OSPFv3 goes down and you are trying to debug, what IPv6 will you ping to check if the second side is accessible? -- Grzegorz Janoszka From mehmet at icann.org Wed Jan 27 11:29:57 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Wed, 27 Jan 2010 09:29:57 -0800 Subject: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC Message-ID: Hello, L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC ) Regards Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT >> Hi >> >> As part of staged, incremental deployment of DNSSEC in the root >> zone L-Root will begin serving a Deliberately Unvalidatable >> Root Zone (DURZ) after the completion of its scheduled >> maintenance at 2010-01-27 1800 UTC - 2000 UTC >> >> Please contact L-Root NOC via noc at dns.icann.org or >> T: +1.310.301.5817 if you have any questions. >> >> Please contact with rootsign at icann.org if you have any >> questions regarding DNSSEC Deployment at root zone. From jf at probe-networks.de Wed Jan 27 11:46:28 2010 From: jf at probe-networks.de (Jonas Frey) Date: Wed, 27 Jan 2010 18:46:28 +0100 Subject: Foundry CLI manual? In-Reply-To: References: Message-ID: <1264614388.12786.115.camel@wks02.probe-networks.de> If you have older foundry gear (IronCore, JetCore, MG8) do a google search for "Using Packet Over SONET Modules". Jonas On Sat, 2010-01-23 at 16:51, David Hubbard wrote: > Anyone have the Foundry/Brocade CLI reference PDF > they could send me? Brocade feels you should have a > support contract to have a list of commands the > hardware you purchased offers and I'm having difficulty > with a oc12 pos module. > > Thanks, > > David From LarrySheldon at cox.net Wed Jan 27 11:52:02 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 27 Jan 2010 11:52:02 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> Message-ID: <4B607D42.7010600@cox.net> On 1/27/2010 5:09 AM, Owen DeLong wrote: > > On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: > >>> The general intent of the /48 allocation is that it is large enough for >>> nearly everybody, with nearly everybody including all but the largest >>> of organisations. >> >> the general intent of a class B allocation is that it is large enough >> for nearly everybody, with nearly everybody including all but the >> largest of organisations. >> >> hmmmmm >> >> randy > > That would, indeed, work if we weren't short of class B networks > to assign. > > Owen ITYM --- That would, indeed, work if we weren't so short sighted in our view of how the demand economics term) would expand to exceed the supply. [For the record I do not see any way of foreseeing the unforeseen (and unforeseeable). I ask only that the latest whizbang be marketed as the latest whizbang (which is likely to be be pretty impressive--it always has been), not the answer for all of time.) -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From trejrco at gmail.com Wed Jan 27 12:22:43 2010 From: trejrco at gmail.com (TJ) Date: Wed, 27 Jan 2010 13:22:43 -0500 Subject: Using /126 for IPv6 router links In-Reply-To: <4B607379.1040905@Janoszka.pl> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B5F93FD.6080600@ibctech.ca> <4B607379.1040905@Janoszka.pl> Message-ID: <000001ca9f7d$bb190d30$314b2790$@com> > -----Original Message----- > From: Grzegorz Janoszka [mailto:Grzegorz at Janoszka.pl] > Sent: Wednesday, January 27, 2010 12:10 > To: nanog at nanog.org > Subject: Re: Using /126 for IPv6 router links > > On 27-1-2010 2:16, Steve Bertrand wrote: > > ip address x.x.x.x 255.255.255.252 > > ipv6 address 2607:F118:x:x::/64 eui-64 > > ipv6 nd suppress-ra > > ipv6 ospf 1 area 0.0.0.0 > > I've found that this setup, in conjunction with iBGP peering between > > loopback /128's works well. > > When OSPFv3 goes down and you are trying to debug, what IPv6 will you > ping to check if the second side is accessible? FWIW, I like to use static, meaningfully-assigned Link Locals ... regardless of the link type. /TJ From mehmet at icann.org Wed Jan 27 13:01:52 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Wed, 27 Jan 2010 11:01:52 -0800 Subject: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC In-Reply-To: Message-ID: Hello World, L-Root has completed it's maintenance and now serving DURZ. You can observe L-Root DSC Stats by visiting http://stats.l.root-servers.org Please contact L-Root NOC via email noc at dns.icann.org or T: +1.310.301.5817 if you have any questions Please contact rootsign at icann.org if you have any questions regarding DNSSEC Deployment at root zone. Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT / AS20144 / AS-LROOT Peering info: http://as20144.peeringdb.com On 1/27/10 12:29 PM, "Mehmet Akcin" wrote: > Hello, > > L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC ) > > Regards > > Joe Abley / Mehmet Akcin / Dave Knight > ICANN DNS Ops / L-ROOT > >>> Hi >>> >>> As part of staged, incremental deployment of DNSSEC in the root >>> zone L-Root will begin serving a Deliberately Unvalidatable >>> Root Zone (DURZ) after the completion of its scheduled >>> maintenance at 2010-01-27 1800 UTC - 2000 UTC >>> >>> Please contact L-Root NOC via noc at dns.icann.org or >>> T: +1.310.301.5817 if you have any questions. >>> >>> Please contact with rootsign at icann.org if you have any >>> questions regarding DNSSEC Deployment at root zone. > > From Valdis.Kletnieks at vt.edu Wed Jan 27 13:11:33 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 Jan 2010 14:11:33 -0500 Subject: DDoS mitigation recommendations In-Reply-To: Your message of "Tue, 26 Jan 2010 09:56:14 PST." <27BED7F5903A42048E53C9E5A589E085@dalap> References: <27BED7F5903A42048E53C9E5A589E085@dalap> Message-ID: <10109.1264619493@localhost> On Tue, 26 Jan 2010 09:56:14 PST, Gerald Wluka said: > To date the company has over-invested in technology and under-invested in > sales and marketing. That is changing now: the company is moving to The Bay > Area. Hate to say this, but that change is hardly a selling point to this crowd. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From john_brzozowski at cable.comcast.com Wed Jan 27 13:23:51 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Wed, 27 Jan 2010 14:23:51 -0500 Subject: Comcast IPv6 Trials Message-ID: Folks, I am emailing you today to share some news that we hope you will find interesting. Today we are announcing our 2010 IPv6 trial plans. For more information please visit the following web site: http://www.comcast6.net We have also made available a partial, dual-stack version of our portal which can be found at: http://ipv6.comcast.net Please do not hesitate to contact me via email with any questions, comments, or clarifications. If you feel that others will find this information interesting feel free to forward this message. Regards, John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 ========================================= From lists at billfehring.com Wed Jan 27 14:47:05 2010 From: lists at billfehring.com (Bill Fehring) Date: Wed, 27 Jan 2010 12:47:05 -0800 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: On Wed, Jan 27, 2010 at 11:23, John Jason Brzozowski wrote: > Folks, > > I am emailing you today to share some news that we hope you will find > interesting. > > Today we are announcing our 2010 IPv6 trial plans. ?For more information > please visit the following web site: > > http://www.comcast6.net > > We have also made available a partial, dual-stack version of our portal > which can be found at: > > http://ipv6.comcast.net Incredible news! Very exciting... unfortunately, at least from here (Comcast Business Class in the SF Bay Area), at the moment, both of these links appear to lead to the same portal page without any information visible regarding your IPv6 trial plans. Best, -Bill From john_brzozowski at cable.comcast.com Wed Jan 27 14:52:37 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Wed, 27 Jan 2010 15:52:37 -0500 Subject: Comcast IPv6 Trials In-Reply-To: Message-ID: There was an adjustment that was required on our end. It is in place. Do you have any form of IPv6 connectivity? If yes, this is why you are seeing the same portal. This will clear up shortly. John On 1/27/10 3:47 PM, "Bill Fehring" wrote: > On Wed, Jan 27, 2010 at 11:23, John Jason Brzozowski > wrote: >> Folks, >> >> I am emailing you today to share some news that we hope you will find >> interesting. >> >> Today we are announcing our 2010 IPv6 trial plans. ?For more information >> please visit the following web site: >> >> http://www.comcast6.net >> >> We have also made available a partial, dual-stack version of our portal >> which can be found at: >> >> http://ipv6.comcast.net > > > Incredible news! Very exciting... unfortunately, at least from here > (Comcast Business Class in the SF Bay Area), at the moment, both of > these links appear to lead to the same portal page without any > information visible regarding your IPv6 trial plans. > > Best, > > -Bill ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 ========================================= From nanog at daork.net Wed Jan 27 15:29:03 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 28 Jan 2010 10:29:03 +1300 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <000001ca9dc8$1e8f7aa0$5bae6fe0$@com> <20100125170738.GI75640@gerbil.cluepon.net> <009901ca9de8$64fff530$2effdf90$@com> <9e246b4d1001251102u2b6ca6b1le4b7f259ea2d505b@mail.gmail.com> <000001ca9dfb$3599e270$a0cda750$@com> <20100126143657.2271062f@opy.nosense.org> <9e246b4d1001260813q1898ee9fq82d344d2fac99902@mail.gmail.com> <20100127152338.1bbfaf5d@opy.nosense.org> <74C0E810-5808-4FF1-AFA6-329C35BC896E@delong.com> <4B602169.8020302@ibctech.ca> Message-ID: On 28/01/2010, at 1:51 AM, Randy Bush wrote: >>>> the general intent of a class B allocation is that it is large enough >>>> for nearly everybody, with nearly everybody including all but the >>>> largest of organisations. >>> That would, indeed, work if we weren't short of class B networks >>> to assign. >> Would you clarify? Seriously? > > we used to think we were not short of class B networks We also used to have a protocol with less total addresses than the population of the planet, let alone subnets. In 2000::/3, assuming we can use 1 in every 4 /48s because, well, I'm being nice to your point, we still have 1300 /48s per person. http://www.wolframalpha.com/input/?i=%28%282%5E45%29%2F4%29%2Fearth+population And that's /48s. What if say 50% of the address space is /48s and 50% of the address space is /56s? Then we have 675,000 networks per person. If we botch that up then we've done amazingly badly. Then we'll move on to 4000::/3. -- Nathan Ward From igor at gashinsky.net Wed Jan 27 15:19:23 2010 From: igor at gashinsky.net (Igor Gashinsky) Date: Wed, 27 Jan 2010 16:19:23 -0500 (EST) Subject: Using /126 for IPv6 router links In-Reply-To: <4B6020A1.3010500@ibctech.ca> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch><63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B6020A1.3010500@ibctech.ca> Message-ID: :: > If a worst-case situation arises, and you have to peer with a device that :: > doesn't properly support /127's, you can always fall back to using /126's :: > or even /64's on those few links (this is why we reserved a /64 for every :: > link from the begining).. :: :: If this is the case, why not just use /64s from the beginning? Why :: bother with hacking it up if it's only going to be reserved anyway? :: :: I'm trying to understand how reserving-and-hacking a /64 makes :: administration any easier. :: :: Even if all ptp are coming out of a single /64 (as opposed to reserving :: a /64 for each), what benefits are there to that? It seems as though :: that this is v4 thinking. This really has nothing to do with wanting to use the space more efficiently, it has to do with overcoming potential operational issues. Reserving the whole /64 is what makes administration easier in face of different vendor capabilities, using only /127 is what's operationally safer on PtP links -- you face 2 major issues with not using /127 for PtP-type circuits: 1) ping-ponging of packets on Sonet/SDH links Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for "him" on). 2) ping sweep of death Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn... (and, if an important entry times out, and now can't get re-learned, *really* bad shit happends, trust me on that one) Both of these can be mitigated by either *really* heavy-handed ACLs, or changes to SONET/SDH forwarding semantics, as well as ARP queue prioritization, but very few vendors support those right now. For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV.. -igor From nenolod at systeminplace.net Wed Jan 27 15:39:22 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 27 Jan 2010 15:39:22 -0600 Subject: DDoS mitigation recommendations In-Reply-To: <27BED7F5903A42048E53C9E5A589E085@dalap> References: <27BED7F5903A42048E53C9E5A589E085@dalap> Message-ID: <1264628362.5122.16.camel@petrie> Hi, On Tue, 2010-01-26 at 09:56 -0800, Gerald Wluka wrote: > > I am new to this mailing list - this should be a response to an already > started thread that I cannot see: > Welcome to NANOG! > > > IntelliguardIT has a new class of network appliance that installs inline > (layer 2 appliance). It has no impact on current network capacity and > automatically manages flash crowds gracefully. Prove it. As far as I can tell, DDoS mitigation appliances are mostly smoke and mirrors, and I used to work for an IDS vendor. > > To date the company has over-invested in technology and under-invested in > sales and marketing. That is changing now: the company is moving to The Bay > Area. LOL. > > > > As a testament to this over-investment we have a few customers in Asia who > had CiscoGuard and/or Arbor Network solutions deployed - they were failing! > IntelliGuard's solution solved their DDoS problems. > Can you cite these clients? > > > If you would like to learn more please contact me directly (the > IntelliGuardIT website is quite dated at this stage. William From karad at arin.net Wed Jan 27 15:54:40 2010 From: karad at arin.net (Darren M. Kara) Date: Wed, 27 Jan 2010 16:54:40 -0500 Subject: 1/8 and 27/8 allocated to APNIC In-Reply-To: <17CF5BAC-CF1E-43DE-A407-DF987E75359F@icann.org> References: <550031AE4E25FE40BCD5D6894BC95DD50198F646@DCPWMF303.polk.com> <5A6D953473350C4B9995546AFE9939EE081F7352@RWC-EX1.corp.seven.com> <18a5e7cb1001220028o52cd54f0x7fd0f230f88f7c73@mail.gmail.com> <4B59AE1D.5080305@gmail.com> <4B59B04C.7080706@foobar.org> <4B59C13C.4090109@gmail.com> <17CF5BAC-CF1E-43DE-A407-DF987E75359F@icann.org> Message-ID: <20100127215440.GU12654@arin.net> leo, This is done, you should see it propogating. regards, darren On Fri, Jan 22, 2010 at 08:58:30AM -0800, Leo Vegoda wrote: > On 22 Jan 2010, at 7:16, William Allen Simpson wrote: > > [...] > > >> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ > >> > > Because relying on a blog post for policy really meets everybody's > > definition of rationality.... :-( > > It's not a policy, it's an explanation of the reasoning behind the implementation of the policy. > > Regards, > > Leo From lists at billfehring.com Wed Jan 27 16:00:09 2010 From: lists at billfehring.com (Bill Fehring) Date: Wed, 27 Jan 2010 14:00:09 -0800 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: On Wed, Jan 27, 2010 at 12:52, John Jason Brzozowski wrote: > There was an adjustment that was required on our end. ?It is in place. Great, got it working, thanks! ...partially Safari/OSX's fault, but mostly mine for not realizing what was going on quickly enough. > Do you have any form of IPv6 connectivity? ?If yes, this is why you are > seeing the same portal. ?This will clear up shortly. Yeah... for now that's a Hurricane Electric tunnel, but native v6 over DOCSIS 3 would be way cooler, not to belittle the amazing efforts of HE. -Bill From cb.list6 at gmail.com Wed Jan 27 16:30:20 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 27 Jan 2010 14:30:20 -0800 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: On Wed, Jan 27, 2010 at 11:23 AM, John Jason Brzozowski wrote: > Folks, > > I am emailing you today to share some news that we hope you will find > interesting. > > Today we are announcing our 2010 IPv6 trial plans. ?For more information > please visit the following web site: > > http://www.comcast6.net > > We have also made available a partial, dual-stack version of our portal > which can be found at: Great work! I hope we see a lot more of these types of announcements! I have my own cooking in the oven :) Cameron From llynch at civil-tongue.net Wed Jan 27 16:33:59 2010 From: llynch at civil-tongue.net (Lucy Lynch) Date: Wed, 27 Jan 2010 14:33:59 -0800 (PST) Subject: Next Generation Leaders (NGL) programme Message-ID: All - This program is a nice opportunity for newer entrants to the Internet community. If you know someone who might benefit, please pass this along. Thanks - - Lucy ---------- Forwarded message ---------- Date: Wed, 27 Jan 2010 12:48:31 -0500 From: Connie Kendig To: lynch at isoc.org Subject: Re: NGL Outreach Assistance The Internet Society (ISOC) is happy to announce a new programme beginning in 2010: the ISOC Next Generation Leaders (NGL) programme. The NGL was officially launched 6 October 2009 at a youth forum lunch during the ITU Telecom World week in Geneva. The programme is aimed at emerging talents across the globe, between the ages of 20 and 40, and is a unique blend of coursework and practical experience to help prepare young professionals from around the world to become the next generation of Internet technology, policy, and business leaders. Programme entrants will complete a tailored eLearning course, covering the essential topics required for effective interactions and relationships within the Internet ecosystem, as well as key concepts and emerging issues in Internet governance. They will be encouraged to apply for the Internet Society?s representation programmes, such as ISOC Ambassadorships to the Internet Governance Forum (IGF), the World Bank, and OECD, and the ISOC Fellowship to the Internet Engineering Task Force (IETF). At the end of the programme, all Next Generation Leaders programme graduates will be invited to submit a proposal for a project focused on an Internet development issue within their own communities. Of those, three projects will be chosen and the respective project leaders will be invited to Geneva for a final, one-week course in Internet diplomacy. The three project leaders will be recognized as the Next Generation Leaders programme laureates, rewarded with special opportunities to network with some of the Internet?s most respected leaders and to participate in special leadership events, and they may be encouraged to start new Internet Society Chapters in their communities. More information on the programme can be found at www.InternetSociety.org/Leaders You may sign up to receive periodic information on the NGL but visiting the programme site and clicking on "Candidates: Register for NGL Information." We will be sharing application details for the eLearning component through the sign up information list in the coming months. If you have any questions or comments about the Next Generation Leaders programme, please contact leaders at InternetSociety.org Best wishes, Connie J Kendig Sponsored Programs & Grants Manager Internet Society www.isoc.org Tel: (703) 439-2136 From smb at cs.columbia.edu Wed Jan 27 16:50:22 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 27 Jan 2010 17:50:22 -0500 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: <3F397A5E-716E-4C01-AF8F-BECBC047F755@cs.columbia.edu> Wonderful! In all seriousness, will any attempt be made to select trial applicants based on (apparent) clue level and/or to receive feedback through channels other than the usual Tier 1 support? From smb at cs.columbia.edu Wed Jan 27 17:07:46 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 27 Jan 2010 18:07:46 -0500 Subject: Countries with the most botnets Message-ID: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> A colleague needs to know, along with citable sources if possible. Ideally - number of zombified PCs, percentage of zombified PCs, name of nation, source. Threat reports from symantec and macafee suggest the US leads, with China a very close second. Yes, we realize that answers will be imperfect. --Steve Bellovin, http://www.cs.columbia.edu/~smb From bgreene at senki.org Wed Jan 27 17:28:00 2010 From: bgreene at senki.org (Barry Raveendran Greene) Date: Wed, 27 Jan 2010 15:28:00 -0800 Subject: Countries with the most botnets In-Reply-To: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> References: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> Message-ID: <004b01ca9fa8$698bc450$3ca34cf0$@org> The Conficker data would be one empirical source you can look at. You have a break down by ASN and Country: http://www.shadowserver.org/wiki/pmwiki.php/Stats/Conficker > -----Original Message----- > From: Steven Bellovin [mailto:smb at cs.columbia.edu] > Sent: Wednesday, January 27, 2010 3:08 PM > To: nanog at nanog.org list > Subject: Countries with the most botnets > > A colleague needs to know, along with citable sources if possible. > > Ideally - number of zombified PCs, percentage of zombified PCs, name of > nation, source. > > Threat reports from symantec and macafee suggest the US leads, with > China a very close second. > > Yes, we realize that answers will be imperfect. > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > From nicholas.hatch at gmail.com Wed Jan 27 17:43:32 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Wed, 27 Jan 2010 15:43:32 -0800 Subject: Comcast IPv6 Trials In-Reply-To: <3F397A5E-716E-4C01-AF8F-BECBC047F755@cs.columbia.edu> References: <3F397A5E-716E-4C01-AF8F-BECBC047F755@cs.columbia.edu> Message-ID: On Wed, Jan 27, 2010 at 2:50 PM, Steven Bellovin wrote: > Wonderful! > > In all seriousness, will any attempt be made to select trial applicants > based on (apparent) clue level and/or to receive feedback through channels > other than the usual Tier 1 support? > >From http://www.comcast6.net/faq.php: *How will you select trial areas?* Some of our trials will not be geographically-bound, meaning a customer from anywhere in our network could participate, while other trials will be bound to particular areas. *How will you select customers to participate in these trials?* Customers can volunteer to participate in a trial by completing an online form at the Comcast IPv6 Information Center, at http://www.comcast6.net/volunteer.php. Once we're ready to start a trial, we will search for customers meeting any applicable criteria for participation (geographic area, home computer OS or equipment, etc.) and invite them to participate in a specific trial. I'm excited to be on the same side as the 500lb gorilla for once, -Nick From richard.barnes at gmail.com Wed Jan 27 18:22:30 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 27 Jan 2010 19:22:30 -0500 Subject: Countries with the most botnets In-Reply-To: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> References: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> Message-ID: <88ac5c711001271622m28d219cbm22e047407693439@mail.gmail.com> Team Cymru seems to put out a lot of information in their newsletters about where bots are, e.g. this article about the locations of botnet controllers: On Wed, Jan 27, 2010 at 6:07 PM, Steven Bellovin wrote: > A colleague needs to know, along with citable sources if possible. > > Ideally - number of zombified PCs, percentage of zombified PCs, name of > nation, source. > > Threat reports from symantec and macafee suggest the US leads, with > China a very close second. > > Yes, we realize that answers will be imperfect. > > ? ? ? ? ? ? ? ?--Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > From ops.lists at gmail.com Wed Jan 27 19:39:37 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 28 Jan 2010 07:09:37 +0530 Subject: Countries with the most botnets In-Reply-To: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> References: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> Message-ID: The CBL has stats too - http://cbl.abuseat.org/totalflow.html - total spamtrap flow http://cbl.abuseat.org/country.html - by country (india leads the pack yay?) http://cbl.abuseat.org/domain.html - by ISP On Thu, Jan 28, 2010 at 4:37 AM, Steven Bellovin wrote: > A colleague needs to know, along with citable sources if possible. > > Ideally - number of zombified PCs, percentage of zombified PCs, name of > nation, source. > > Threat reports from symantec and macafee suggest the US leads, with > China a very close second. > > Yes, we realize that answers will be imperfect. -- Suresh Ramasubramanian (ops.lists at gmail.com) From john_brzozowski at cable.comcast.com Wed Jan 27 17:12:35 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Wed, 27 Jan 2010 18:12:35 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <3F397A5E-716E-4C01-AF8F-BECBC047F755@cs.columbia.edu> Message-ID: Thanks. Initially it would be ideal (even preferred) to target trial subscribers with greater IPv6 awareness. The technical team will absolutely remain engaged as part of the support process. HTH, John On 1/27/10 5:50 PM, "Steven Bellovin" wrote: > Wonderful! > > In all seriousness, will any attempt be made to select trial applicants based > on (apparent) clue level and/or to receive feedback through channels other > than the usual Tier 1 support? ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 ========================================= From john_brzozowski at cable.comcast.com Wed Jan 27 17:19:42 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Wed, 27 Jan 2010 18:19:42 -0500 Subject: Comcast IPv6 Trials In-Reply-To: Message-ID: On 1/27/10 5:00 PM, "Bill Fehring" wrote: > On Wed, Jan 27, 2010 at 12:52, John Jason Brzozowski > wrote: >> There was an adjustment that was required on our end. ?It is in place. > Great, got it working, thanks! ...partially Safari/OSX's fault, but > mostly mine for not realizing what was going on quickly enough. > >> Do you have any form of IPv6 connectivity? ?If yes, this is why you are >> seeing the same portal. ?This will clear up shortly. > Yeah... for now that's a Hurricane Electric tunnel, but native v6 over > DOCSIS 3 would be way cooler, not to belittle the amazing efforts of > HE. [jjmb] native, dual-stack is exactly one of the approaches we will be trialing. > > -Bill ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 ========================================= From william.mccall at gmail.com Wed Jan 27 21:51:11 2010 From: william.mccall at gmail.com (William McCall) Date: Wed, 27 Jan 2010 21:51:11 -0600 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: Saw this today too. This is a good step forward for adoption. Without going too far, what was the driving factor/selling point to moving towards this trial? -- William McCall On Wed, Jan 27, 2010 at 1:23 PM, John Jason Brzozowski wrote: > Folks, > > I am emailing you today to share some news that we hope you will find > interesting. > > Today we are announcing our 2010 IPv6 trial plans. ?For more information > please visit the following web site: > > http://www.comcast6.net > > We have also made available a partial, dual-stack version of our portal > which can be found at: > > http://ipv6.comcast.net > > Please do not hesitate to contact me via email with any questions, comments, > or clarifications. > > If you feel that others will find this information interesting feel free to > forward this message. > > Regards, > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > ========================================= > > > > From gbonser at seven.com Wed Jan 27 22:59:16 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 27 Jan 2010 20:59:16 -0800 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> > -----Original Message----- > From: William McCall > Sent: Wednesday, January 27, 2010 7:51 PM > Subject: Re: Comcast IPv6 Trials > > Saw this today too. This is a good step forward for adoption. Without > going too far, what was the driving factor/selling point to moving > towards this trial? SWAG: Comcast is a mobile operator. At some point NAT becomes very expensive for mobile devices and it makes sense to use IPv6 where you don't need to do NAT. Once you deploy v6 on your mobile net, it is to your advantage to have the stuff your mobile devices connect to also be v6. Do do THAT your network needs to transport v6 and once your net is ipv6 enabled, there is no reason not to leverage that capability to the rest of your network. /SWAG My gut instinct says that mobile operators will be a major player in v6 adoption. From tvarriale at comcast.net Wed Jan 27 23:07:16 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 27 Jan 2010 23:07:16 -0600 Subject: Comcast IPv6 Trials References: Message-ID: <03F9DCFCAB174CE8AB2B69D429AFF70B@flamdt01> ----- Original Message ----- From: "John Jason Brzozowski" To: "Steven Bellovin" Cc: Sent: Wednesday, January 27, 2010 5:12 PM Subject: Re: Comcast IPv6 Trials > Thanks. > > Initially it would be ideal (even preferred) to target trial subscribers > with greater IPv6 awareness. The technical team will absolutely remain > engaged as part of the support process. > > HTH, > > John I filled out the form but nowhere on there does it allow to brag up or differentiate yourself from the typical home user (or select which trial(s) you may be interested in). It appears the differentiators are your PC OS, gaming platform and if you have more than 1 IP. tv From sethm at rollernet.us Wed Jan 27 23:11:50 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 27 Jan 2010 21:11:50 -0800 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: <4B611C96.4050901@rollernet.us> On 1/27/2010 15:19, John Jason Brzozowski wrote: > On 1/27/10 5:00 PM, "Bill Fehring" wrote: > >> On Wed, Jan 27, 2010 at 12:52, John Jason Brzozowski >> wrote: >>> There was an adjustment that was required on our end. It is in place. >> Great, got it working, thanks! ...partially Safari/OSX's fault, but >> mostly mine for not realizing what was going on quickly enough. >> >>> Do you have any form of IPv6 connectivity? If yes, this is why you are >>> seeing the same portal. This will clear up shortly. >> Yeah... for now that's a Hurricane Electric tunnel, but native v6 over >> DOCSIS 3 would be way cooler, not to belittle the amazing efforts of >> HE. > [jjmb] native, dual-stack is exactly one of the approaches we will be > trialing. Very awesome. If you served my area I would sign up for an account just to try it out. I have IPv6 access and can't see your site, but I did look at it a bit on my phone and I'm quite impressed to see someone of your size doing what you're doing. ~Seth From dwcarder at wisc.edu Wed Jan 27 23:24:48 2010 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 27 Jan 2010 23:24:48 -0600 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B6020A1.3010500@ibctech.ca> Message-ID: <01EF79E7-9B7D-40D1-934B-A0BD2A929415@wisc.edu> On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: > you face 2 major issues with not using /127 for > PtP-type circuits: > > 1) ping-ponging of packets on Sonet/SDH links > > Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP > interface, and somebody comes along and ping floods 2001:db8::2, > those packets will bounce back and forth between the 2 sides of > the link till TTL expires (since there is no address resolution > mechanism in PtP, so it just forwards packets not destined for > "him" on). Following this, IPv4 /30 would have the same problem vs /31? > 2) ping sweep of death > > Take the same assumption for addressing as above, and now ping > sweep 2001:db8::/64... if the link is ethernet, well, hope you > didn't have any important arp entries that the router actually > needed to learn. Wouldn't this affect *all* /64's configured on a router, not just point to point links? Time for glean rate limiting. If you were really concerned, you could hard code static NDP entries, as I think someone else pointed out. Dale From oberman at es.net Wed Jan 27 23:55:51 2010 From: oberman at es.net (Kevin Oberman) Date: Wed, 27 Jan 2010 21:55:51 -0800 Subject: Comcast IPv6 Trials In-Reply-To: Your message of "Wed, 27 Jan 2010 20:59:16 PST." <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> Message-ID: <20100128055551.0A16E1CC09@ptavv.es.net> > Date: Wed, 27 Jan 2010 20:59:16 -0800 > From: "George Bonser" > > > -----Original Message----- > > From: William McCall > > Sent: Wednesday, January 27, 2010 7:51 PM > > Subject: Re: Comcast IPv6 Trials > > > > Saw this today too. This is a good step forward for adoption. Without > > going too far, what was the driving factor/selling point to moving > > towards this trial? > > > SWAG: Comcast is a mobile operator. At some point NAT becomes very > expensive for mobile devices and it makes sense to use IPv6 where you > don't need to do NAT. Once you deploy v6 on your mobile net, it is to > your advantage to have the stuff your mobile devices connect to also be > v6. Do do THAT your network needs to transport v6 and once your net is > ipv6 enabled, there is no reason not to leverage that capability to the > rest of your network. /SWAG > > My gut instinct says that mobile operators will be a major player in v6 > adoption. SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and Internet provider, but they don't do mobile (so far). -- 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 From gbonser at seven.com Thu Jan 28 00:55:54 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 27 Jan 2010 22:55:54 -0800 Subject: Comcast IPv6 Trials In-Reply-To: <20100128055551.0A16E1CC09@ptavv.es.net> References: Your message of "Wed, 27 Jan 2010 20:59:16 PST." <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F745F@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Kevin Oberman [mailto:oberman at es.net] > Sent: Wednesday, January 27, 2010 9:56 PM > To: George Bonser > Cc: William McCall; nanog at nanog.org > Subject: Re: Comcast IPv6 Trials > SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and > Internet provider, but they don't do mobile (so far). Ahh, ok. I was fooled by this: http://www.comcast.net/mobile/ From david.freedman at uk.clara.net Thu Jan 28 03:48:46 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 28 Jan 2010 09:48:46 +0000 Subject: Comcast IPv6 Trials In-Reply-To: References: Message-ID: John Jason Brzozowski wrote: > Folks, > > I am emailing you today to share some news that we hope you will find > interesting. > > Today we are announcing our 2010 IPv6 trial plans. For more information > please visit the following web site: I was privileged enough to visit the Comcast DOCSIS3/IPv6 implementation demo setup at nanog46 in Philly last year, here are some pics I managed to snap: http://www.convergence.cx/cgi-bin/photview.cgi?collection=comcast6&newformat=yay Apologies for the lack of descriptions, but from what I recall, there was a CMTS setup with DOCSIS3 CMs and Laptops attached, streaming media over IPv6. Dave. From dbelev at gmail.com Thu Jan 28 04:29:11 2010 From: dbelev at gmail.com (Dean Belev) Date: Thu, 28 Jan 2010 12:29:11 +0200 Subject: Strange Cisco 6503 problem Message-ID: <4B6166F7.8080501@gmail.com> Hi all, We experienced a strange problem with one of our Cisco 6503 routers - right after the terminal PC connected to the router via console is rebooted the router reboots itself. Even when there is no Eth connection to the PC the situations is the same - reboot follows. I tried to check the messages the router sends: *: %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 31 seconds [1/0] :: No EOBC input, dump debuginfo, interval 10, times 3 : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 60 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 90 seconds [1/0] : %FIB-3-FIBDISABLE: Fatal error, slot/cpu 1/0: IPC Failure: timeout : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 120 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 150 seconds [1/0]* All the possible reasons according to Cisco that may caused that case will be checked soon because the router is in operational mode although some of them looks strange: /*CPU_MONITOR-3-TIMED_OUT or CPU_MONITOR-6-NOT_HEARD Problem The switch reports these error messages: CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds Description These messages indicate that CPU monitor messages have not been heard for a significant amount of time. A time-out most probably occurs, which resets the system. [dec] is the number of seconds. The problem possibly occurs because of these reasons: * Badly seated line card or module * Bad ASIC or bad backplane * Software bugs * Parity error * High traffic in the Ethernet out of band channel (EOBC) channel The EOBC channel is a half duplex channel that services many other functions, which includes Simple Network Management Protocol (SNMP) traffic and packets that are destined to the switch. If the EOBC channel is full of messages because of a storm of SNMP traffic, then the channel is subjected to collisions. When this happens, EOBC is possibly not able to carry IPC messages. This makes the switch display the error message. Workaround Reseat the line card or module. If a maintenance window can be scheduled, reset the switch in order to clear any transient issues. ######################################### Error Message %ERR_DET-5-ERR_DET_NO_EOBC_INPUT: No EOBC input, dump debuginfo, interval %u, times %u Explanation No Ethernet Out-of-Band Channel (EOBC) input was received. Debugging information will be dumped. Recommended Action No action is required.*/ I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. Here is some brief info about the router: *Supervisor:* Mod Ports Card Type Model --- ----- -------------------------------------- ------------------ ----------- 1 9 Supervisor Engine 32 8GE (Active) WS-SUP32-GE-3B *Processor:* cisco WS-C6503-E (R7000) processor *IOS:* IOS (tm) s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF8, RELEASE SOFTWARE (fc2) Thank you in advance for all your replays. Best~ From tsands at rackspace.com Thu Jan 28 06:01:15 2010 From: tsands at rackspace.com (Tom Sands) Date: Thu, 28 Jan 2010 06:01:15 -0600 Subject: DDoS mitigation recommendations In-Reply-To: <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> Message-ID: <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> > -----Original Message----- > From: David Freedman [mailto:david.freedman at uk.clara.net] > Sent: Tuesday, January 26, 2010 8:17 AM > To: nanog at nanog.org > Subject: Re: DDoS mitigation recommendations > >> Arbor stuff comes to mind and works very well in our experiences.... > > Arbor++ > > We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it. Thank you, Tom Sands Chief Network Engineer Rackspace Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From richard.barnes at gmail.com Thu Jan 28 06:47:02 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 28 Jan 2010 07:47:02 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <20100128055551.0A16E1CC09@ptavv.es.net> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> Message-ID: <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with >1 IP address (e.g., for user data / control of the cable box). On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman wrote: >> Date: Wed, 27 Jan 2010 20:59:16 -0800 >> From: "George Bonser" >> >> > -----Original Message----- >> > From: William McCall >> > Sent: Wednesday, January 27, 2010 7:51 PM >> > Subject: Re: Comcast IPv6 Trials >> > >> > Saw this today too. This is a good step forward for adoption. Without >> > going too far, what was the driving factor/selling point to moving >> > towards this trial? >> >> >> SWAG: Comcast is a mobile operator. ?At some point NAT becomes very >> expensive for mobile devices and it makes sense to use IPv6 where you >> don't need to do NAT. ?Once you deploy v6 on your mobile net, it is to >> your advantage to have the stuff your mobile devices connect to also be >> v6. ?Do do THAT your network needs to transport v6 and once your net is >> ipv6 enabled, there is no reason not to leverage that capability to the >> rest of your network. /SWAG >> >> My gut instinct says that mobile operators will be a major player in v6 >> adoption. > > SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and > Internet provider, but they don't do mobile (so far). > -- > 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 > > From dbelev at gmail.com Thu Jan 28 06:56:19 2010 From: dbelev at gmail.com (Dean Belev) Date: Thu, 28 Jan 2010 14:56:19 +0200 Subject: Strange Cisco 6503 problem Message-ID: <4B618973.8090700@gmail.com> Hi all, I experienced a strange problem with one of our Cisco 6503 routers - right after the terminal PC connected to the router via console is rebooted the router reboots itself. Even when there is no Eth connection to the PC the situations is the same - reboot follows. I tried to check the messages the router sends: *: %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 31 seconds [1/0] :: No EOBC input, dump debuginfo, interval 10, times 3 : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 60 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 90 seconds [1/0] : %FIB-3-FIBDISABLE: Fatal error, slot/cpu 1/0: IPC Failure: timeout : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 120 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 150 seconds [1/0]* All the possible reasons according to Cisco that may caused that case will be checked soon because the router is in operational mode although some of them looks strange: /*CPU_MONITOR-3-TIMED_OUT or CPU_MONITOR-6-NOT_HEARD Problem The switch reports these error messages: CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds Description These messages indicate that CPU monitor messages have not been heard for a significant amount of time. A time-out most probably occurs, which resets the system. [dec] is the number of seconds. The problem possibly occurs because of these reasons: * Badly seated line card or module * Bad ASIC or bad backplane * Software bugs * Parity error * High traffic in the Ethernet out of band channel (EOBC) channel The EOBC channel is a half duplex channel that services many other functions, which includes Simple Network Management Protocol (SNMP) traffic and packets that are destined to the switch. If the EOBC channel is full of messages because of a storm of SNMP traffic, then the channel is subjected to collisions. When this happens, EOBC is possibly not able to carry IPC messages. This makes the switch display the error message. Workaround Reseat the line card or module. If a maintenance window can be scheduled, reset the switch in order to clear any transient issues. ######################################### Error Message %ERR_DET-5-ERR_DET_NO_EOBC_INPUT: No EOBC input, dump debuginfo, interval %u, times %u Explanation No Ethernet Out-of-Band Channel (EOBC) input was received. Debugging information will be dumped. Recommended Action No action is required.*/ I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. Here is some brief info about the router: *Supervisor:* Mod Ports Card Type Model --- ----- -------------------------------------- ------------------ ----------- 1 9 Supervisor Engine 32 8GE (Active) WS-SUP32-GE-3B *Processor:* cisco WS-C6503-E (R7000) processor *IOS:* IOS (tm) s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF8, RELEASE SOFTWARE (fc2) Thank you in advance for all your replays. Best~ From tvest at eyeconomics.com Thu Jan 28 07:11:35 2010 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 28 Jan 2010 08:11:35 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> Message-ID: <30B87542-95CC-4737-AA5C-AE4DA55B7906@eyeconomics.com> On Jan 28, 2010, at 7:47 AM, Richard Barnes wrote: > What I've heard is that the driver is IPv4 exhaustion: Comcast is > starting to have enough subscribers that it can't address them all out > of 10/8 -- ~millions of subscribers, each with >1 IP address (e.g., > for user data / control of the cable box). But then that begs the question of why lots of other very large retail Internet access providers have not indicated that they're committed to the same course of action (?). They're certainly not the only provider that employs a public IP address-intensive access model, so where are the other retail IPv6 trial announcements/pre-announcements? If they start appearing with some frequency real soon now, then maybe it's just a time-until-overflow issue. If not, then maybe there are other/better explanations. TV > On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman wrote: >>> Date: Wed, 27 Jan 2010 20:59:16 -0800 >>> From: "George Bonser" >>> >>>> -----Original Message----- >>>> From: William McCall >>>> Sent: Wednesday, January 27, 2010 7:51 PM >>>> Subject: Re: Comcast IPv6 Trials >>>> >>>> Saw this today too. This is a good step forward for adoption. Without >>>> going too far, what was the driving factor/selling point to moving >>>> towards this trial? >>> >>> >>> SWAG: Comcast is a mobile operator. At some point NAT becomes very >>> expensive for mobile devices and it makes sense to use IPv6 where you >>> don't need to do NAT. Once you deploy v6 on your mobile net, it is to >>> your advantage to have the stuff your mobile devices connect to also be >>> v6. Do do THAT your network needs to transport v6 and once your net is >>> ipv6 enabled, there is no reason not to leverage that capability to the >>> rest of your network. /SWAG >>> >>> My gut instinct says that mobile operators will be a major player in v6 >>> adoption. >> >> SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and >> Internet provider, but they don't do mobile (so far). >> -- >> 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 >> >> > From pstewart at nexicomgroup.net Thu Jan 28 07:15:56 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 28 Jan 2010 08:15:56 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com><20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> Message-ID: That really makes sense - on an incredibly smaller scale (and I mean MUCH smaller scale), we operate cable modem in two small communities - currently we use 3 IP addresses per subscriber. One for the cable modem itself, one for the subscriber (or more depending on their package), and one for voice delivery (packetcable). If we moved even two of three IP assignments to native V6 we'd reclaim a lot of V4 space - I can only imagine someone their size and what this means... Paul -----Original Message----- From: Richard Barnes [mailto:richard.barnes at gmail.com] Sent: Thursday, January 28, 2010 7:47 AM To: Kevin Oberman Cc: nanog at nanog.org Subject: Re: Comcast IPv6 Trials What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with >1 IP address (e.g., for user data / control of the cable box). On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman wrote: >> Date: Wed, 27 Jan 2010 20:59:16 -0800 >> From: "George Bonser" >> >> > -----Original Message----- >> > From: William McCall >> > Sent: Wednesday, January 27, 2010 7:51 PM >> > Subject: Re: Comcast IPv6 Trials >> > >> > Saw this today too. This is a good step forward for adoption. Without >> > going too far, what was the driving factor/selling point to moving >> > towards this trial? >> >> >> SWAG: Comcast is a mobile operator. ?At some point NAT becomes very >> expensive for mobile devices and it makes sense to use IPv6 where you >> don't need to do NAT. ?Once you deploy v6 on your mobile net, it is to >> your advantage to have the stuff your mobile devices connect to also be >> v6. ?Do do THAT your network needs to transport v6 and once your net is >> ipv6 enabled, there is no reason not to leverage that capability to the >> rest of your network. /SWAG >> >> My gut instinct says that mobile operators will be a major player in v6 >> adoption. > > SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and > Internet provider, but they don't do mobile (so far). > -- > 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 > > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From trejrco at gmail.com Thu Jan 28 07:26:06 2010 From: trejrco at gmail.com (TJ) Date: Thu, 28 Jan 2010 08:26:06 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> Message-ID: <000601caa01d$756acdf0$604069d0$@com> > -----Original Message----- > From: Richard Barnes [mailto:richard.barnes at gmail.com] > Sent: Thursday, January 28, 2010 07:47 > To: Kevin Oberman > Cc: nanog at nanog.org > Subject: Re: Comcast IPv6 Trials > > What I've heard is that the driver is IPv4 exhaustion: Comcast is > starting to have enough subscribers that it can't address them all out > of 10/8 -- ~millions of subscribers, each with >1 IP address (e.g., > for user data / control of the cable box). ++1, reference: http://www.apricot.net/apricot2006/slides/conf/wednesday/Alain_Durand-Archit ecture-external.ppt /TJ From scott at sberkman.net Thu Jan 28 07:30:49 2010 From: scott at sberkman.net (Scott Berkman) Date: Thu, 28 Jan 2010 08:30:49 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F745F@RWC-EX1.corp.seven.com> References: Your message of "Wed, 27 Jan 2010 20:59:16 PST." <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <5A6D953473350C4B9995546AFE9939EE081F745F@RWC-EX1.corp.seven.com> Message-ID: <000301caa01e$1b6de390$5249aab0$@net> They'll need to be soon to keep up with others in their space (not that they generally compete directly thanks to franchise laws), although I'm not sure how the data side of things is handled for MVNO's, normally they don't have any network of their own: http://news.cnet.com/8301-1035_3-10215445-94.html http://unbelievablyfair.com/ -Scott -----Original Message----- From: George Bonser [mailto:gbonser at seven.com] Sent: Thursday, January 28, 2010 1:56 AM To: Kevin Oberman Cc: nanog at nanog.org Subject: RE: Comcast IPv6 Trials > -----Original Message----- > From: Kevin Oberman [mailto:oberman at es.net] > Sent: Wednesday, January 27, 2010 9:56 PM > To: George Bonser > Cc: William McCall; nanog at nanog.org > Subject: Re: Comcast IPv6 Trials > SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and > Internet provider, but they don't do mobile (so far). Ahh, ok. I was fooled by this: http://www.comcast.net/mobile/ From joakim at aronius.com Thu Jan 28 07:44:38 2010 From: joakim at aronius.com (Joakim Aronius) Date: Thu, 28 Jan 2010 14:44:38 +0100 Subject: Comcast IPv6 Trials In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> Message-ID: <20100128134438.GA26503@maya.aronius.com> * Paul Stewart (pstewart at nexicomgroup.net) wrote: > That really makes sense - on an incredibly smaller scale (and I mean MUCH smaller scale), we operate cable modem in two small communities - currently we use 3 IP addresses per subscriber. One for the cable modem itself, one for the subscriber (or more depending on their package), and one for voice delivery (packetcable). If we moved even two of three IP assignments to native V6 we'd reclaim a lot of V4 space - I can only imagine someone their size and what this means... > > Paul Excuse the newbie question: Why use public IP space for local CPE management and VoIP? Doesn't DOCSIS support traffic separation? /J From trejrco at gmail.com Thu Jan 28 08:07:11 2010 From: trejrco at gmail.com (TJ) Date: Thu, 28 Jan 2010 09:07:11 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <30B87542-95CC-4737-AA5C-AE4DA55B7906@eyeconomics.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> <30B87542-95CC-4737-AA5C-AE4DA55B7906@eyeconomics.com> Message-ID: <001e01caa023$330b5280$9921f780$@com> > -----Original Message----- > From: tvest at eyeconomics.com [mailto:tvest at eyeconomics.com] > Sent: Thursday, January 28, 2010 08:12 > To: Richard Barnes > Cc: NANOG > Subject: Re: Comcast IPv6 Trials > But then that begs the question of why lots of other very large retail > Internet access providers have not indicated that they're committed to the > same course of action (?). > They're certainly not the only provider that employs a public IP address- > intensive access model, so where are the other retail IPv6 trial > announcements/pre-announcements? Other providers are moving in that direction, atleast a couple are (as a swag) 6-18 months behind Comcast ... /TJ From tvest at eyeconomics.com Thu Jan 28 08:34:52 2010 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Thu, 28 Jan 2010 09:34:52 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <001e01caa023$330b5280$9921f780$@com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> <30B87542-95CC-4737-AA5C-AE4DA55B7906@eyeconomics.com> <001e01caa023$330b5280$9921f780$@com> Message-ID: On Jan 28, 2010, at 9:07 AM, TJ wrote: >> -----Original Message----- >> From: tvest at eyeconomics.com [mailto:tvest at eyeconomics.com] >> Sent: Thursday, January 28, 2010 08:12 >> To: Richard Barnes >> Cc: NANOG >> Subject: Re: Comcast IPv6 Trials > > > >> But then that begs the question of why lots of other very large retail >> Internet access providers have not indicated that they're committed to the >> same course of action (?). >> They're certainly not the only provider that employs a public IP address- >> intensive access model, so where are the other retail IPv6 trial >> announcements/pre-announcements? > > Other providers are moving in that direction, atleast a couple are (as a > swag) 6-18 months behind Comcast ... > > /TJ I have no particular reason to to doubt that claim, and lots of reasons to actively hope that you are right. That said, the appearance of more public commitments like this -- and sooner rather than later -- could make a large difference, e.g., by reducing the general level of uncertainty (and uncertainty-amplifying speculation) during the terminal stages of IPv4 allocation. While no commercial entity would (and none should) willingly make such a public commitment before they're ready, it would be prudent to consider the potential downsides of that looming uncertainty when making judgements about how "ready" (or perhaps "ready enough") should be defined. TV From jeffrey.lyon at blacklotus.net Thu Jan 28 09:00:22 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 28 Jan 2010 10:00:22 -0500 Subject: DDoS mitigation recommendations In-Reply-To: <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> Message-ID: <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> IntruGuard is highly customizable both from the GUI and CLI with the engineer's assistance. Its the highest performance, reasonably priced box that we've tried so far. Jeff On Jan 28, 2010 7:02 AM, "Tom Sands" wrote: > -----Original Message----- > From: David Freedman [mailto:david.freedman at uk.clara.net] Sent: Tues... We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it. Thank you, Tom Sands Chief Network Engineer Rackspace Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intend... From tdurack at gmail.com Thu Jan 28 09:20:44 2010 From: tdurack at gmail.com (Tim Durack) Date: Thu, 28 Jan 2010 10:20:44 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <20100128134438.GA26503@maya.aronius.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> <20100128134438.GA26503@maya.aronius.com> Message-ID: <9e246b4d1001280720ja32ad5cp9bd850c03430bfcf@mail.gmail.com> On Thu, Jan 28, 2010 at 8:44 AM, Joakim Aronius wrote: > Excuse the newbie question: Why use public IP space for local CPE management and VoIP? Doesn't DOCSIS support traffic separation? > > /J > > Probably because rfc1918 is only 2^24+2^20+2^16 = 17,891,328 (assuming I got them all and my math is right.) That makes it tough to manage unique devices across a large deployment. -- Tim:> Sent from Brooklyn, NY, United States From steve at pirk.com Thu Jan 28 09:50:41 2010 From: steve at pirk.com (steve pirk [egrep]) Date: Thu, 28 Jan 2010 07:50:41 -0800 Subject: Comcast IPv6 Trials In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F745F@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <5A6D953473350C4B9995546AFE9939EE081F745F@RWC-EX1.corp.seven.com> Message-ID: <940b2d521001280750n493d2ee8x3cd0a6b690c6f388@mail.gmail.com> On Wed, Jan 27, 2010 at 22:55, George Bonser wrote: > > > > -----Original Message----- > > From: Kevin Oberman [mailto:oberman at es.net] > > Sent: Wednesday, January 27, 2010 9:56 PM > > To: George Bonser > > Cc: William McCall; nanog at nanog.org > > Subject: Re: Comcast IPv6 Trials > > > > SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and > > Internet provider, but they don't do mobile (so far). > > Ahh, ok. I was fooled by this: http://www.comcast.net/mobile/ > > Does G4 count? I have seen fliers from Comcast talking about mobile G4 access in my area apparently. I have Comcast Business class w/5 IPs. Linux and WinXP, own servers/dns and PTR on one IP so far. I also signed up. -- steve steve pirk refiamerica.org "father... the sleeper has awakened..." paul atreides - dune kexp.org member august '09 From thegameiam at yahoo.com Thu Jan 28 09:56:49 2010 From: thegameiam at yahoo.com (David Barak) Date: Thu, 28 Jan 2010 07:56:49 -0800 (PST) Subject: Using /126 for IPv6 router links In-Reply-To: <01EF79E7-9B7D-40D1-934B-A0BD2A929415@wisc.edu> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B6020A1.3010500@ibctech.ca> <01EF79E7-9B7D-40D1-934B-A0BD2A929415@wisc.edu> Message-ID: <873180.9269.qm@web31805.mail.mud.yahoo.com> ----- Original Message ---- From: Dale W. Carder dwcarder at wisc.edu On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: > you face 2 major issues with not using /127 for > PtP-type circuits: > >> 1) ping-ponging of packets on Sonet/SDH links > Following this, IPv4 /30 would have the same problem vs /31? No, because IPv4 has the concept of Broadcast, while IPv6 does not.? Remotely sending packets to an IPv4 broadcast address is a "directed broadcast" and that is generally denied by default on modern kit.? >> 2) ping sweep of death > >> ??? Take the same assumption for addressing as above, and now ping > >??? sweep 2001:db8::/64... if the link is ethernet, well, hope you > >??? didn't have any important arp entries that the router actually > ?>?? needed to learn. >Wouldn't this affect *all* /64's configured on a router, not >just point to point links?? Time for glean rate limiting. This is, of course, one of the reasons why some of us didn't like the ultra-mega-mega ranges used to address handfuls of hosts, but that ship sailed long ago.? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From ken at sizone.org Thu Jan 28 10:46:54 2010 From: ken at sizone.org (Ken Chase) Date: Thu, 28 Jan 2010 11:46:54 -0500 Subject: Rogers wireless outbound mailservers have no reverse (SORBS please help?) Message-ID: <20100128164654.GZ16327@sizone.org> Can I get a rogers engineer who not only cares but has power to crush problems to respond to this please? Opening tickets with RNS seems to just get a null responce, "we'll look at it" with a hint of disbelief a customer ticket could uncover a large network-wide issue. It's an old problem that was temporarily fixed for a while, but is now back. Jan 28 06:46:00 cust1 postfix/smtpd[416]: NOQUEUE: reject: RCPT from unknown[74.198.8.2]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [74.198.8.2]; from= to= proto=ESMTP helo= $ host 74.198.8.2 8.8.8.8 Using domain server: Name: 8.8.8.8 Host 2.8.198.74.in-addr.arpa. not found: 3(NXDOMAIN) Maybe we can get them registered on SORBS. The irony would be very tasty. Maybe then they'll start caring. (Too much to hope for?) Solution right now is to get all of my customers to tell their employees to not trust outgoing rogers mailservers to get their mail out, and find alternates. I'm not the only one who filters by lack of reverse. I'm also trying to figure out the Rogers angle here. Ideas? /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From morrowc.lists at gmail.com Thu Jan 28 10:55:34 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Jan 2010 11:55:34 -0500 Subject: DDoS mitigation recommendations In-Reply-To: <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> Message-ID: <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon wrote: > IntruGuard is highly customizable both from the GUI and CLI with the > engineer's assistance. Its the highest performance, reasonably priced box > that we've tried so far. 'highest performance' == 100mbps on a 1gbps copper interface? or sessions setup/second? or remote-addresses tracked? or ? -chris > > Jeff > > On Jan 28, 2010 7:02 AM, "Tom Sands" wrote: > > >> -----Original Message----- >> From: David Freedman [mailto:david.freedman at uk.clara.net] Sent: Tues... > We've already done an initial trial with the Arbor device, and it does work > well. ?Our biggest sticking point with it is that it lacks the granular > level of visibility and control that we've been used to and often needed to > tweak profiles. ?Basically, it does what it's supposed to well, but you > really can't tell what that is, and if it's not catching all of a DDoS you > have little insight as to what's being missed or control to correct it. > > > > Thank you, > > Tom Sands > Chief Network Engineer > Rackspace > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intend... > From joe at nethead.com Thu Jan 28 11:13:33 2010 From: joe at nethead.com (Joe Hamelin) Date: Thu, 28 Jan 2010 09:13:33 -0800 Subject: Comcast IPv6 Trials In-Reply-To: <940b2d521001280750n493d2ee8x3cd0a6b690c6f388@mail.gmail.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <5A6D953473350C4B9995546AFE9939EE081F745F@RWC-EX1.corp.seven.com> <940b2d521001280750n493d2ee8x3cd0a6b690c6f388@mail.gmail.com> Message-ID: <79db6ae1001280913o6e176c5egd60dac0c8c4ad56c@mail.gmail.com> steve pirk:> Does G4 count? I have seen fliers from Comcast talking about mobile G4 Comcast is using Clearwire for 4G. Seattle 4G rolled-out about 2 weeks ago. Many more markets to be turned-up this spring. No IPv6 in the configs at this time, but most of the core seems capable. Clear is layer-2 up to the major market POPs so it would seem to be mostly a config/firmware change on the network side. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From serge at euro-ix.net Thu Jan 28 12:35:49 2010 From: serge at euro-ix.net (Serge Radovcic) Date: Thu, 28 Jan 2010 19:35:49 +0100 Subject: Keeping up with New European IXP participants Message-ID: The Euro-IX ASN database now has more than 5.100 entries in it of which almost 3.000 are unique ASNs. In an effort to make it a little easier for those peering or looking to peer at European IXPs to keep up the latest IXP participant additions, we have created a page that lists the latest entries to the Euro-IX database. This page also displays all ASNs that peer at more than 9 IXPs across Europe. Hope you find it useful. https://www.euro-ix.net/newasns.php Regards, Serge Oh BTW we also have a RSS feed of this page available From oberman at es.net Thu Jan 28 13:11:41 2010 From: oberman at es.net (Kevin Oberman) Date: Thu, 28 Jan 2010 11:11:41 -0800 Subject: Comcast IPv6 Trials In-Reply-To: Your message of "Thu, 28 Jan 2010 09:34:52 EST." Message-ID: <20100128191141.352C61CC09@ptavv.es.net> > From: tvest at eyeconomics.com > Date: Thu, 28 Jan 2010 09:34:52 -0500 > > On Jan 28, 2010, at 9:07 AM, TJ wrote: > > >> -----Original Message----- > >> From: tvest at eyeconomics.com [mailto:tvest at eyeconomics.com] > >> Sent: Thursday, January 28, 2010 08:12 > >> To: Richard Barnes > >> Cc: NANOG > >> Subject: Re: Comcast IPv6 Trials > > > > > > > >> But then that begs the question of why lots of other very large retail > >> Internet access providers have not indicated that they're committed to the > >> same course of action (?). > >> They're certainly not the only provider that employs a public IP address- > >> intensive access model, so where are the other retail IPv6 trial > >> announcements/pre-announcements? > > > > Other providers are moving in that direction, atleast a couple are (as a > > swag) 6-18 months behind Comcast ... > > > > /TJ > > I have no particular reason to to doubt that claim, and lots of > reasons to actively hope that you are right. > > That said, the appearance of more public commitments like this -- and > sooner rather than later -- could make a large difference, e.g., by > reducing the general level of uncertainty (and uncertainty-amplifying > speculation) during the terminal stages of IPv4 allocation. > > While no commercial entity would (and none should) willingly make such > a public commitment before they're ready, it would be prudent to > consider the potential downsides of that looming uncertainty when > making judgements about how "ready" (or perhaps "ready enough") should > be defined. Might be worth noting that Comcast has been using IPv6 heavily for internal connectivity (including router access) for some time and already had substantial experience with IPv6, so I suspect that they are ahead of others on 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 From igor at gashinsky.net Thu Jan 28 15:19:54 2010 From: igor at gashinsky.net (Igor Gashinsky) Date: Thu, 28 Jan 2010 16:19:54 -0500 (EST) Subject: Using /126 for IPv6 router links In-Reply-To: <01EF79E7-9B7D-40D1-934B-A0BD2A929415@wisc.edu> References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B6020A1.3010500@ibctech.ca> <01EF79E7-9B7D-40D1-934B-A0BD2A929415@wisc.edu> Message-ID: On Wed, 27 Jan 2010, Dale W. Carder wrote: :: :: On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: :: :: > you face 2 major issues with not using /127 for :: > PtP-type circuits: :: > :: > 1) ping-ponging of packets on Sonet/SDH links :: > :: > Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP :: > interface, and somebody comes along and ping floods 2001:db8::2, :: > those packets will bounce back and forth between the 2 sides of :: > the link till TTL expires (since there is no address resolution :: > mechanism in PtP, so it just forwards packets not destined for :: > "him" on). :: :: Following this, IPv4 /30 would have the same problem vs /31? As has been said before, IPv4 has a concept of broadcast, and "no ip directed broadcast" (or simmilar) to prevent it -- IPv6 does not. :: > 2) ping sweep of death :: > :: > Take the same assumption for addressing as above, and now ping :: > sweep 2001:db8::/64... if the link is ethernet, well, hope you :: > didn't have any important arp entries that the router actually :: > needed to learn. :: :: Wouldn't this affect *all* /64's configured on a router, not :: just point to point links? Time for glean rate limiting. While I don't disagree on smarter ARP gleaning, rate limiting by itself is not an answer (rate limiting means that legit requests get limited too), so a better approach is to prioritize arp/NDP refresh for anything already in cache, as opposed to new requests, which we've suggested to our vendors. Also, for a "core" network, you don't really need /64's in most places, and, if you do need them, their numbers are quite small compared to the number of PtP links.. (how many lan/host segments do you have connected to core routers, as compared to number of PtP links, and then, how many of those show up in a traceroute?) :: If you were really concerned, you could hard code static NDP :: entries, as I think someone else pointed out. Or, you can use /127's -- to me, that's operationally easier (especially if you have to replace hardware in the future) :) Like I said before, using /127's is our suggestion of what has worked best for us in both architectural and operational roles, and since my network isn't the same as yours, YMMV, just sharing our experience.. Thanks, -igor From chris at uplogon.com Thu Jan 28 15:42:11 2010 From: chris at uplogon.com (Chris Gotstein) Date: Thu, 28 Jan 2010 15:42:11 -0600 Subject: Comcast IPv6 Trials In-Reply-To: <20100128134438.GA26503@maya.aronius.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> <20100128134438.GA26503@maya.aronius.com> Message-ID: <4B6204B3.2090508@uplogon.com> Typically the CPE address is private, not sure why they would use a public IP. The MTA (VoIP) part of the modem would need a public IP if it was talking to a SIP server that was not on the same network. Most smaller cable system outsource their VoIP to a reseller with a softswitch. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 1/28/2010 7:44 AM, Joakim Aronius wrote: > * Paul Stewart (pstewart at nexicomgroup.net) wrote: >> That really makes sense - on an incredibly smaller scale (and I mean MUCH smaller scale), we operate cable modem in two small communities - currently we use 3 IP addresses per subscriber. One for the cable modem itself, one for the subscriber (or more depending on their package), and one for voice delivery (packetcable). If we moved even two of three IP assignments to native V6 we'd reclaim a lot of V4 space - I can only imagine someone their size and what this means... >> >> Paul > > Excuse the newbie question: Why use public IP space for local CPE management and VoIP? Doesn't DOCSIS support traffic separation? > > /J > From tdurack at gmail.com Thu Jan 28 15:48:54 2010 From: tdurack at gmail.com (Tim Durack) Date: Thu, 28 Jan 2010 16:48:54 -0500 Subject: Comcast IPv6 Trials In-Reply-To: <4B6204B3.2090508@uplogon.com> References: <5A6D953473350C4B9995546AFE9939EE081F7456@RWC-EX1.corp.seven.com> <20100128055551.0A16E1CC09@ptavv.es.net> <88ac5c711001280447m453dd39aqf99e9f3246be9d65@mail.gmail.com> <20100128134438.GA26503@maya.aronius.com> <4B6204B3.2090508@uplogon.com> Message-ID: <9e246b4d1001281348j3b679827xc0edd4f54c655481@mail.gmail.com> On Thu, Jan 28, 2010 at 4:42 PM, Chris Gotstein wrote: > Typically the CPE address is private, not sure why they would use a > public IP. ?The MTA (VoIP) part of the modem would need a public IP if > it was talking to a SIP server that was not on the same network. ?Most > smaller cable system outsource their VoIP to a reseller with a softswitch. It's not necessarily "public", just globally unique. Some companies have more than 17,891,328 devices they want to manage in a centralized fashion. -- Tim:> From jtk at cymru.com Thu Jan 28 16:03:41 2010 From: jtk at cymru.com (John Kristoff) Date: Thu, 28 Jan 2010 16:03:41 -0600 Subject: IPv6 security ops panel and PGP key signing Message-ID: <20100128160341.38652c99@t61p> Hi folks, I'm helping Barry Greene out with the ISP sec BoF this year and at least one of the items planned for that session is an IPv6 security operations panel/audience discussion. If the ISP sec BoF and IPv6 operations, particularly related to security, is of interest to you, I'd be interested in hearing about it off list. I'm also very interested in a couple more people volunteering to join the panel and help lead the discussion. You don't have to have all the answers, questions are OK too. I'll take any of those in advance so your's truly to can better perform the moderator role. Additionally, there is probably going to be at least a small handful of PGP key signing geeks wanting to exchange signatures during the meeting. I believe the PC will have something official scheduled, but you can exchange sigs at anytime. Usually there is a sticker on the badge (usually red if I recall) which marks someone as a PGP geek. If nothing else, for those that have never participated its a decent way to meet some new people face to face and see how well their ID photo came out. Add your "public" key to the keyring here: John From marka at isc.org Thu Jan 28 16:14:37 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Jan 2010 09:14:37 +1100 Subject: Rogers wireless outbound mailservers have no reverse (SORBS please help?) In-Reply-To: Your message of "Thu, 28 Jan 2010 11:46:54 CDT." <20100128164654.GZ16327@sizone.org> References: <20100128164654.GZ16327@sizone.org> Message-ID: <201001282214.o0SMEbK6062818@drugs.dv.isc.org> In message <20100128164654.GZ16327 at sizone.org>, Ken Chase writes: > Can I get a rogers engineer who not only cares but has power to crush problem > s > to respond to this please? > > Opening tickets with RNS seems to just get a null responce, "we'll look at it > " with > a hint of disbelief a customer ticket could uncover a large network-wide issu > e. > > It's an old problem that was temporarily fixed for a while, but is now back. > > Jan 28 06:46:00 cust1 postfix/smtpd[416]: NOQUEUE: reject: RCPT > from unknown[74.198.8.2]: 450 4.7.1 Client host rejected: cannot > find your reverse hostname, [74.198.8.2]; > from= to= > proto=ESMTP helo= > > $ host 74.198.8.2 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > > Host 2.8.198.74.in-addr.arpa. not found: 3(NXDOMAIN) > > Maybe we can get them registered on SORBS. The irony would be very tasty. > Maybe then they'll start caring. (Too much to hope for?) > > Solution right now is to get all of my customers to tell their employees > to not trust outgoing rogers mailservers to get their mail out, and find alte > rnates. > > I'm not the only one who filters by lack of reverse. > > I'm also trying to figure out the Rogers angle here. Ideas? > > /kc > -- > Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA > Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Fron > t St. W. Perhaps you should re-think your filtering policies. They are obviously wrong because they are not allowing through the email you want to be let through. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From peter.hicks at poggs.co.uk Thu Jan 28 17:15:46 2010 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Thu, 28 Jan 2010 23:15:46 +0000 Subject: Strange Cisco 6503 problem In-Reply-To: <4B618973.8090700@gmail.com> References: <4B618973.8090700@gmail.com> Message-ID: <4B621AA2.1060002@poggs.co.uk> Dean Belev wrote: > I'm curious if some of you faced such a problem - reboot of the router > caused by the console connection. I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon> prompt :) I had that down to static somewhere, as it's the only explanation I could find. Peter From thegameiam at yahoo.com Thu Jan 28 17:24:53 2010 From: thegameiam at yahoo.com (David Barak) Date: Thu, 28 Jan 2010 15:24:53 -0800 (PST) Subject: Strange Cisco 6503 problem In-Reply-To: <4B621AA2.1060002@poggs.co.uk> References: <4B618973.8090700@gmail.com> <4B621AA2.1060002@poggs.co.uk> Message-ID: <230891.65265.qm@web31815.mail.mud.yahoo.com> ----- Original Message ---- From: Peter Hicks To: Dean Belev >> I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. >I once managed to send a BREAK signal to a 3640 by plugging in a console cable.? At the time, it was a pretty key router in the? > network and sat at the rommon> prompt :) >I had that down to static somewhere, as it's the only explanation I could find. Certain serial speed mismatches get interpreted as BREAK - I routinely use?"space bar at 1200"?to password crack routers where they are expecting 9600. ? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From smb at cs.columbia.edu Thu Jan 28 17:36:55 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 28 Jan 2010 18:36:55 -0500 Subject: Strange Cisco 6503 problem In-Reply-To: <4B621AA2.1060002@poggs.co.uk> References: <4B618973.8090700@gmail.com> <4B621AA2.1060002@poggs.co.uk> Message-ID: <02200D8E-E17A-4C3B-9AC3-27BD6108372E@cs.columbia.edu> On Jan 28, 2010, at 6:15 PM, Peter Hicks wrote: > Dean Belev wrote: > >> I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. > > I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon> prompt :) > > I had that down to static somewhere, as it's the only explanation I could find. Actually, it's not at all surprising, but it depends on the UART or equivalent. A serial line has two states, "mark" -- a 1-bit -- and "space" (guess). Normally, the line is at "mark", which corresponds to a voltage of -3V:-25V at the receiver. Space is +3V:+25V; -3V:+3V is undefined. (http://www.lammertbies.nl/comm/info/RS-232_specs.html is pretty good, and as far as I remember quite accurate, though it's ~20 years since I used a breakout box.) Now -- a break signal is normally a "long space", a 0 signal that lasts too long, often about .25 seconds. It originally got the name because it looked like a break in the teletype line; teletypes used a current loop standard (don't ask). More precisely -- an asynchronous byte is followed by a "stop bit", which isn't so much a bit as a time interval -- one bit-time -- during which the signal must be in the mark state. If you're sending at the wrong speed or send break -- something that's holding the line at space for long enough that it will run into the stop bits at any speed -- the UART will detect the problem; this is sometimes known as a "framing error". So -- when you disconnect the cable, the voltage at the pin goes to 0. How should that be interpreted? If the board has a pull-up resistor to a +5V line, it will appear as a space signal; if it doesn't, it's up to the UART or equivalent, since it's undefined by the spec. --Steve Bellovin, http://www.cs.columbia.edu/~smb From aegal at cisco.com Thu Jan 28 17:42:13 2010 From: aegal at cisco.com (Abdulkadir Egal (aegal)) Date: Thu, 28 Jan 2010 15:42:13 -0800 Subject: Strange Cisco 6503 problem References: <4B618973.8090700@gmail.com> <4B621AA2.1060002@poggs.co.uk> Message-ID: <5242EDD1B5510544B53208557E6D6925035797CC@xmb-sjc-21d.amer.cisco.com> Please make sure you config register is set to x2102. You shouldn't see any issues if you the correct config register. Regards Abdul -----Original Message----- From: Peter Hicks [mailto:peter.hicks at poggs.co.uk] Sent: Thu 1/28/2010 3:15 PM To: Dean Belev Cc: nanog at nanog.org Subject: Re: Strange Cisco 6503 problem Dean Belev wrote: > I'm curious if some of you faced such a problem - reboot of the router > caused by the console connection. I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon> prompt :) I had that down to static somewhere, as it's the only explanation I could find. Peter From sfouant at shortestpathfirst.net Thu Jan 28 20:22:16 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 28 Jan 2010 21:22:16 -0500 Subject: DDoS mitigation recommendations In-Reply-To: <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> Message-ID: <010201caa089$e1100e50$a3302af0$@net> > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Thursday, January 28, 2010 11:56 AM > To: Jeffrey Lyon > Cc: nanog at nanog.org > Subject: Re: DDoS mitigation recommendations > > On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon > wrote: > > IntruGuard is highly customizable both from the GUI and CLI with the > > engineer's assistance. Its the highest performance, reasonably priced > box > > that we've tried so far. > > 'highest performance' == 100mbps on a 1gbps copper interface? or > sessions setup/second? or remote-addresses tracked? or ? sessions setup/second = ddos mitigation fail ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From morrowc.lists at gmail.com Thu Jan 28 20:23:53 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Jan 2010 21:23:53 -0500 Subject: DDoS mitigation recommendations In-Reply-To: <010201caa089$e1100e50$a3302af0$@net> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> <010201caa089$e1100e50$a3302af0$@net> Message-ID: <75cb24521001281823u79361c36g8b335102d5a3a5b3@mail.gmail.com> On Thu, Jan 28, 2010 at 9:22 PM, Stefan Fouant wrote: >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Thursday, January 28, 2010 11:56 AM >> To: Jeffrey Lyon >> Cc: nanog at nanog.org >> Subject: Re: DDoS mitigation recommendations >> >> On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon >> wrote: >> > IntruGuard is highly customizable both from the GUI and CLI with the >> > engineer's assistance. Its the highest performance, reasonably priced >> box >> > that we've tried so far. >> >> 'highest performance' == 100mbps on a 1gbps copper interface? or >> sessions setup/second? or remote-addresses tracked? or ? > > sessions setup/second = ddos mitigation fail ;) 'unqualified adjectives == fail' ... or 'lies, damned lines and statistics' or 'pls to be qualifying your statement with some useful data' :) -chris From jof at thejof.com Thu Jan 28 21:04:01 2010 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 28 Jan 2010 19:04:01 -0800 Subject: DDoS mitigation recommendations In-Reply-To: <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> Message-ID: <1264732760-sup-399@sfo.thejof.com> Excerpts from Christopher Morrow's message of Thu Jan 28 08:55:34 -0800 2010: > On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon > wrote: > > IntruGuard is highly customizable both from the GUI and CLI with the > > engineer's assistance. Its the highest performance, reasonably priced box > > that we've tried so far. > > 'highest performance' == 100mbps on a 1gbps copper interface? or > sessions setup/second? or remote-addresses tracked? or ? Indeed, the only IntruGuard products I can see on their site appear to be some sort of active inspection device that support 100 and 1000 Mbit/s of traffic. Being able to task a device to inspect the data in every packet is wonderful. It allows a properly-controlled system to be able to create statistics, capture traffic, and deeply-inspect traffic. But then you're putting all that traffic through a CPU-bound chokepoint, no? I suppose one could use some sort of ECMP or link aggregation and split that traffic over several inspection devices, but at some point you're bound by the maximum number of paths (Anyone know if all vendors have a limitation of max. links per group?) If one wanted to increase the breadth of this fanout, they could add layers of routers, all fanning out n*n equal-cost paths. Add n*n inspection devices to the bottom of this tree. At todays traffic levels in larger ISPs, adding all this hardware can become expensive to maintain enough capacity. And this, I think, is the crux of why hardware-based traffic traffic inspection and filtering is, at a certain scale, far more efficient at finding abberant network behavior and squashing it at your edge (or even at your upstream's network edge). It can leverage network routing hardware you already have to measure traffic and to redirect it as necessary. Something utilizing sflow/netflow and flowspec to block or direct traffic into a scrubbing box gets you much better bang for your buck past a certain scale. Cheers, jof From tvarriale at comcast.net Thu Jan 28 22:59:22 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Thu, 28 Jan 2010 22:59:22 -0600 Subject: DDoS mitigation recommendations References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com><49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> Message-ID: <53AD66F52DD340C2A7A1E3DA8C9C7B18@flamdt01> ----- Original Message ----- From: "Tom Sands" Cc: Sent: Thursday, January 28, 2010 6:01 AM Subject: Re: DDoS mitigation recommendations > >> -----Original Message----- >> From: David Freedman [mailto:david.freedman at uk.clara.net] >> Sent: Tuesday, January 26, 2010 8:17 AM >> To: nanog at nanog.org >> Subject: Re: DDoS mitigation recommendations >> >>> Arbor stuff comes to mind and works very well in our experiences.... >> >> Arbor++ >> >> > > We've already done an initial trial with the Arbor device, and it does > work well. Our biggest sticking point with it is that it lacks the > granular level of visibility and control that we've been used to and > often needed to tweak profiles. Basically, it does what it's supposed > to well, but you really can't tell what that is, and if it's not > catching all of a DDoS you have little insight as to what's being missed > or control to correct it. > > Thank you, > > Tom Sands > Chief Network Engineer > Rackspace Out of curiousity, what's your baseline or "that we've been used"? tv From rdobbins at arbor.net Thu Jan 28 23:01:19 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 29 Jan 2010 05:01:19 +0000 Subject: DDoS mitigation recommendations In-Reply-To: <1264732760-sup-399@sfo.thejof.com> References: <13849_1264509646_o0QCefMg016576_4B5EE2C3.6000305@rackspace.com> <49EBDFF3A3469A47BBA7B1B537A4729A17D66FC4F5@PRVPEXVS11.corp.twcable.com> <23745_1264680074_o0SC19IF001732_4B617C8B.30408@rackspace.com> <16720fe01001280659n4aca67c6vd88d1e81dc268b52@mail.gmail.com> <16720fe01001280700x4d4a7379k750653900465941b@mail.gmail.com> <75cb24521001280855i718fbaa5k5230ab92cd251a8a@mail.gmail.com> <1264732760-sup-399@sfo.thejof.com> Message-ID: On Jan 29, 2010, at 10:04 AM, Jonathan Lassoff wrote: > Something utilizing sflow/netflow and flowspec to block or direct traffic into a scrubbing box gets you much better bang for your buck past a certain scale. This is absolutely key for packet-flooding types of attacks, and other attacks in which unadulterated pathological traffic can be detected/classified in detail, with minimal collateral damage. Everyone should implement S/RTBH and/or flow-spec whenever possible, this cannot be emphasized enough. Operators have made significant investments in high-speed, ASIC-powered routers at their edges; there's no reason not to utilize that horsepower, as it's already there and paid for. For situations in which valid and invalid traffic are highly intermixed, and/or layer-4/-7 heuristics are key in validating legitimate traffic and invalidating undesirable traffic, the additional capabilities of an IDMS which can perform such discrimination can be of benefit. As mentioned in a previous thread, it's possible to construct a base-level capability using open-source software, and commercial solutions from various vendors [full disclosure: I'm employed one of said vendors] are available, as well. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From Valdis.Kletnieks at vt.edu Fri Jan 29 11:56:55 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 29 Jan 2010 12:56:55 -0500 Subject: Comcast IPv6 Trials In-Reply-To: Your message of "Wed, 27 Jan 2010 17:50:22 EST." <3F397A5E-716E-4C01-AF8F-BECBC047F755@cs.columbia.edu> References: <3F397A5E-716E-4C01-AF8F-BECBC047F755@cs.columbia.edu> Message-ID: <10488.1264787815@localhost> On Wed, 27 Jan 2010 17:50:22 EST, Steven Bellovin said: > In all seriousness, will any attempt be made to select trial applicants > based on (apparent) clue level and/or to receive feedback through > channels other than the usual Tier 1 support? Two comments: 1) People who manage to find out about the trial and apply probably have already done some self-selection on clue level. Big difference between Joe Sixpack and Joe IPV6-pack. 2) Even if some Joe Sixpacks manage to get into the test, that's good - because Comcast needs to know what the unclued masses need for support, etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gordslater at ieee.org Fri Jan 29 12:06:42 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 29 Jan 2010 18:06:42 +0000 Subject: Strange Cisco 6503 problem In-Reply-To: <02200D8E-E17A-4C3B-9AC3-27BD6108372E@cs.columbia.edu> References: <4B618973.8090700@gmail.com> <4B621AA2.1060002@poggs.co.uk> <02200D8E-E17A-4C3B-9AC3-27BD6108372E@cs.columbia.edu> Message-ID: <1264788402.6329.39.camel@ub-g-d2> On Thu, 2010-01-28 at 18:36 -0500, Steven Bellovin wrote: > Actually, it's not at all surprising, but it depends on the UART or > equivalent. and the dynamic characteristics of the power rails, to a certain extent. Sun kit is quite sensitive to this sort of thing. Zonker has a good guide to what does what and what borks in his conserver pages: http://www.conserver.com/consoles/ as well as a bucketload of pinout info for console ports and console servers in general. The whole site is good reference for younger techies born in the USB age ;) Gord -- I'm giving up the sigs - I'm on patches and gum. From cscora at apnic.net Fri Jan 29 12:45:25 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Jan 2010 04:45:25 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201001291845.o0TIjPfu008033@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 Jan, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 310401 Prefixes after maximum aggregation: 143857 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 152150 Total ASes present in the Internet Routing Table: 33195 Prefixes per ASN: 9.35 Origin-only ASes present in the Internet Routing Table: 28813 Origin ASes announcing only one prefix: 14071 Transit ASes present in the Internet Routing Table: 4382 Transit-only ASes present in the Internet Routing Table: 110 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 23 Max AS path prepend of ASN ( 9503) 21 Prefixes from unregistered ASNs in the Routing Table: 803 Unregistered ASNs in the Routing Table: 130 Number of 32-bit ASNs allocated by the RIRs: 409 Prefixes from 32-bit ASNs in the Routing Table: 367 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 208 Number of addresses announced to Internet: 2182859712 Equivalent to 130 /8s, 27 /16s and 203 /24s Percentage of available address space announced: 58.9 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 89.1 Percentage of address space in use by end-sites: 81.0 Total number of prefixes smaller than registry allocations: 149507 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 74994 Total APNIC prefixes after maximum aggregation: 25835 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 71687 Unique aggregates announced from the APNIC address blocks: 31510 APNIC Region origin ASes present in the Internet Routing Table: 3940 APNIC Prefixes per ASN: 18.19 APNIC Region origin ASes announcing only one prefix: 1084 APNIC Region transit ASes present in the Internet Routing Table: 623 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 23 Number of APNIC addresses announced to Internet: 490424864 Equivalent to 29 /8s, 59 /16s and 74 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/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, 133/8, 175/8, 180/8, 182/8, 183/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: 129648 Total ARIN prefixes after maximum aggregation: 67654 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 103715 Unique aggregates announced from the ARIN address blocks: 39327 ARIN Region origin ASes present in the Internet Routing Table: 13468 ARIN Prefixes per ASN: 7.70 ARIN Region origin ASes announcing only one prefix: 5204 ARIN Region transit ASes present in the Internet Routing Table: 1331 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 738182688 Equivalent to 43 /8s, 255 /16s and 198 /24s Percentage of available ARIN address space announced: 64.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 52/8, 54/8, 55/8, 56/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, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 71527 Total RIPE prefixes after maximum aggregation: 41622 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 64555 Unique aggregates announced from the RIPE address blocks: 42965 RIPE Region origin ASes present in the Internet Routing Table: 14024 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7284 RIPE Region transit ASes present in the Internet Routing Table: 2103 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 415078528 Equivalent to 24 /8s, 189 /16s and 152 /24s Percentage of available RIPE address space announced: 77.3 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-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 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, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27325 Total LACNIC prefixes after maximum aggregation: 6555 LACNIC Deaggregation factor: 4.17 Prefixes being announced from the LACNIC address blocks: 25709 Unique aggregates announced from the LACNIC address blocks: 13809 LACNIC Region origin ASes present in the Internet Routing Table: 1235 LACNIC Prefixes per ASN: 20.82 LACNIC Region origin ASes announcing only one prefix: 404 LACNIC Region transit ASes present in the Internet Routing Table: 206 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 70292480 Equivalent to 4 /8s, 48 /16s and 148 /24s Percentage of available LACNIC address space announced: 69.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 6318 Total AfriNIC prefixes after maximum aggregation: 1829 AfriNIC Deaggregation factor: 3.45 Prefixes being announced from the AfriNIC address blocks: 4703 Unique aggregates announced from the AfriNIC address blocks: 1396 AfriNIC Region origin ASes present in the Internet Routing Table: 338 AfriNIC Prefixes per ASN: 13.91 AfriNIC Region origin ASes announcing only one prefix: 95 AfriNIC Region transit ASes present in the Internet Routing Table: 75 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 14851840 Equivalent to 0 /8s, 226 /16s and 159 /24s Percentage of available AfriNIC address space announced: 44.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1859 7511 472 Korea Telecom (KIX) 4755 1314 305 136 TATA Communications formerly 17488 1273 131 138 Hathway IP Over Cable Interne 18101 1043 220 37 Reliance Infocom Ltd Internet 4134 1018 19609 399 CHINANET-BACKBONE 9583 983 71 489 Sify Limited 7545 924 198 98 TPG Internet Pty Ltd 17974 886 277 43 PT TELEKOMUNIKASI INDONESIA 24560 840 299 173 Bharti Airtel Ltd., Telemedia 4808 835 1583 212 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 4135 3875 317 bellsouth.net, inc. 4323 3794 1088 395 Time Warner Telecom 1785 1851 699 132 PaeTec Communications, Inc. 7018 1584 5777 1026 AT&T WorldNet Services 20115 1542 1490 671 Charter Communications 2386 1294 616 916 AT&T Data Communications Serv 3356 1211 10931 423 Level 3 Communications, LLC 11492 1141 222 14 Cable One 22773 1125 2600 66 Cox Communications, Inc. 6478 1106 240 254 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 35805 562 40 5 United Telecom of Georgia 3292 454 1904 396 TDC Tele Danmark 30890 447 100 207 Evolva Telecom 702 422 1821 336 UUNET - Commercial IP service 8551 397 353 37 Bezeq International 8866 376 110 24 Bulgarian Telecommunication C 3320 360 7069 309 Deutsche Telekom AG 3301 350 1412 311 TeliaNet Sweden 3215 345 3174 102 France Telecom Transpac 12479 321 576 5 Uni2 Autonomous System 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 1565 2885 236 UniNet S.A. de C.V. 10620 1010 226 133 TVCABLE BOGOTA 28573 849 677 100 NET Servicos de Comunicao S.A 7303 672 356 99 Telecom Argentina Stet-France 22047 565 310 15 VTR PUNTO NET S.A. 11830 472 308 59 Instituto Costarricense de El 6503 446 163 185 AVANTEL, S.A. 11172 444 99 69 Servicios Alestra S.A de C.V 14117 439 29 12 Telefonica del Sur S.A. 3816 432 194 70 Empresa Nacional de Telecomun 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 8452 963 445 9 TEDATA 24863 719 144 39 LINKdotNET AS number 36992 475 87 245 Etisalat MISR 3741 274 857 234 The Internet Solution 2018 190 197 109 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 167 19 9 Ci Telecom Autonomous system 29975 134 506 15 Vodacom 33776 123 7 11 Starcomms Nigeria Limited 5536 117 8 3 Internet Egypt Network 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 4135 3875 317 bellsouth.net, inc. 4323 3794 1088 395 Time Warner Telecom 4766 1859 7511 472 Korea Telecom (KIX) 1785 1851 699 132 PaeTec Communications, Inc. 7018 1584 5777 1026 AT&T WorldNet Services 8151 1565 2885 236 UniNet S.A. de C.V. 20115 1542 1490 671 Charter Communications 4755 1314 305 136 TATA Communications formerly 2386 1294 616 916 AT&T Data Communications Serv 17488 1273 131 138 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 4323 3794 3399 Time Warner Telecom 1785 1851 1719 PaeTec Communications, Inc. 4766 1859 1387 Korea Telecom (KIX) 8151 1565 1329 UniNet S.A. de C.V. 4755 1314 1178 TATA Communications formerly 17488 1273 1135 Hathway IP Over Cable Interne 11492 1141 1127 Cable One 22773 1125 1059 Cox Communications, Inc. 18566 1059 1049 Covad Communications 18101 1043 1006 Reliance Infocom Ltd Internet 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 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 46.0.0.0/16 12654 RIPE NCC RIS Project 46.1.0.0/21 12654 RIPE NCC RIS Project 46.1.24.0/24 12654 RIPE NCC RIS Project 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:21 /9:10 /10:25 /11:66 /12:185 /13:385 /14:659 /15:1246 /16:10883 /17:5108 /18:8696 /19:17880 /20:21774 /21:21830 /22:28190 /23:28191 /24:162323 /25:935 /26:1169 /27:586 /28:215 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2693 4135 bellsouth.net, inc. 4323 2362 3794 Time Warner Telecom 4766 1477 1859 Korea Telecom (KIX) 1785 1316 1851 PaeTec Communications, Inc. 11492 1061 1141 Cable One 17488 1052 1273 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 7018 953 1584 AT&T WorldNet Services 18101 922 1043 Reliance Infocom Ltd Internet 10620 915 1010 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:2 2:1 4:13 8:234 12:2002 13:10 15:22 16:3 17:8 20:39 24:1302 27:1 32:49 38:646 40:99 41:1865 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:640 59:639 60:389 61:1099 62:1010 63:2034 64:3789 65:2364 66:4096 67:1800 68:1035 69:2841 70:689 71:236 72:1879 73:2 74:2086 75:242 76:351 77:823 78:577 79:411 80:958 81:782 82:457 83:439 84:636 85:1004 86:381 87:695 88:418 89:1537 90:65 91:2701 92:420 93:1172 94:1376 95:796 96:208 97:296 98:534 99:23 100:1 109:266 110:285 111:423 112:219 113:221 114:348 115:514 116:1036 117:609 118:372 119:805 120:144 121:828 122:1380 123:833 124:1075 125:1284 128:197 129:203 130:138 131:477 132:82 133:16 134:195 135:41 136:224 137:172 138:237 139:90 140:460 141:132 142:377 143:339 144:389 145:51 146:406 147:183 148:563 149:196 150:146 151:171 152:248 153:165 154:2 155:269 156:179 157:331 158:97 159:354 160:305 161:176 162:274 163:187 164:305 165:454 166:502 167:389 168:759 169:157 170:571 171:48 172:2 173:455 174:525 175:31 178:2 180:298 183:215 184:3 186:269 187:231 188:1288 189:634 190:3497 192:5720 193:4440 194:3346 195:2787 196:1170 198:3558 199:3396 200:5306 201:1466 202:8094 203:8324 204:4003 205:2178 206:2416 207:3043 208:3924 209:3421 210:2536 211:1170 212:1658 213:1640 214:253 215:62 216:4438 217:1498 218:483 219:448 220:1129 221:469 222:308 End of report From nanog2 at adns.net Fri Jan 29 13:22:27 2010 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Fri, 29 Jan 2010 13:22:27 -0600 Subject: Level 3 DC issues? Message-ID: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> Anyone see any connectivity issues with Level-3 in the DC area? This issue is causing big latency problems that appeared to have taken out Bank of America's website. From woodsjm at jmu.edu Fri Jan 29 13:26:09 2010 From: woodsjm at jmu.edu (Woods, Jonathan) Date: Fri, 29 Jan 2010 14:26:09 -0500 Subject: Level 3 DC issues? In-Reply-To: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> References: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> Message-ID: <40203B82-CA9C-42D0-A5FF-AAD4203E8526@jmu.edu> I've got low latency TO 'Level3 Washington' - but I time out about three hops later. I'm coming from the Sprintlink. On Jan 29, 2010, at 2:22 PM, John Palmer (NANOG Acct) wrote: > Anyone see any connectivity issues with Level-3 in the DC area? This issue is causing big latency problems > that appeared to have taken out Bank of America's website. > > From robert at ufl.edu Fri Jan 29 13:30:35 2010 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 29 Jan 2010 14:30:35 -0500 Subject: Level 3 DC issues? In-Reply-To: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> References: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> Message-ID: <006d01caa119$87a014b0$96e03e10$@edu> Looks like an internal problem to BoA. The redirect works, and I get an immediate reply. The https redirect page appears boinked. Even with a -k curl took over 30 seconds to get the page, and the browser would have timed out. robert at Robert ~ $ curl -i -G www.bankofamerica.com HTTP/1.1 301 Moved Permanently Server: Sun-ONE-Web-Server/6.1 Date: Fri, 29 Jan 2010 19:25:08 GMT Content-length: 122 Content-type: text/html Location: https://www.bankofamerica.com/index.jsp Connection: close Moved Permanently

Moved Permanently

An error has occurred. robert at Robert ~ $ curl -i -G www.bankofamerica.com HTTP/1.1 301 Moved Permanently Server: Sun-ONE-Web-Server/6.1 Date: Fri, 29 Jan 2010 19:25:28 GMT Content-length: 122 Content-type: text/html Location: https://www.bankofamerica.com/index.jsp Connection: close Moved Permanently

Moved Permanently

An error has occurred. robert at Robert ~ $ curl -i -G https://www.bankofamerica.com/index.jsp curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. robert at Robert ~ $ curl -k -i -G https://www.bankofamerica.com/index.jsp Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree 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: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: Friday, January 29, 2010 2:22 PM To: NANOG list Subject: Level 3 DC issues? Anyone see any connectivity issues with Level-3 in the DC area? This issue is causing big latency problems that appeared to have taken out Bank of America's website. From chaim.rieger at gmail.com Fri Jan 29 13:31:54 2010 From: chaim.rieger at gmail.com (chaim rieger) Date: Fri, 29 Jan 2010 11:31:54 -0800 Subject: Level 3 DC issues? In-Reply-To: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> References: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> Message-ID: <4B6337AA.5070405@gmail.com> John Palmer (NANOG Acct) wrote: > Anyone see any connectivity issues with Level-3 in the DC area? This > issue is causing big latency problems > that appeared to have taken out Bank of America's website. > Los angeles Downtown had a big power outage which affected quite a few dc's dont know if its related though From Robert.E.VanOrmer at frb.gov Fri Jan 29 13:47:31 2010 From: Robert.E.VanOrmer at frb.gov (Robert.E.VanOrmer at frb.gov) Date: Fri, 29 Jan 2010 13:47:31 -0600 Subject: Level 3 DC issues? Message-ID: Looks like it may be a BoA issue. I also see their AS number peering to AS 701 (Verizon Business / UUNet) with a dead traceroute to BoA. On Jan 29, 2010, at 2:22 PM, John Palmer (NANOG Acct) wrote: > Anyone see any connectivity issues with Level-3 in the DC area? This issue is causing big latency problems > that appeared to have taken out Bank of America's website. > > From cidr-report at potaroo.net Fri Jan 29 16:00:05 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Jan 2010 22:00:05 GMT Subject: BGP Update Report Message-ID: <201001292200.o0TM05OX011953@wattle.apnic.net> BGP Update Report Interval: 21-Jan-10 -to- 28-Jan-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2686 21921 2.1% 139.6 -- AT&T Global Network Services - EMEA 2 - AS18170 20829 2.0% 946.8 -- CHANGWON-AS-KR Changwon National University 3 - AS7643 19874 1.9% 32.2 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 4 - AS18106 18698 1.8% 271.0 -- VIEWQWEST-SG-AP Viewqwest Pte Ltd 5 - AS5800 17908 1.7% 88.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS7303 12288 1.2% 18.3 -- Telecom Argentina S.A. 7 - AS45408 11986 1.1% 5993.0 -- 8 - AS14420 11554 1.1% 37.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 9 - AS37986 11383 1.1% 129.4 -- TULIP Tulip Telecom Ltd. 10 - AS4270 9020 0.9% 1804.0 -- Red de Interconexion Universitaria 11 - AS9829 7823 0.7% 20.7 -- BSNL-NIB National Internet Backbone 12 - AS4134 7407 0.7% 7.3 -- CHINANET-BACKBONE No.31,Jin-rong Street 13 - AS23577 7312 0.7% 12.6 -- ATM-MPLS-AS-KR Korea Telecom 14 - AS17964 7008 0.7% 44.1 -- DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd. 15 - AS14522 6725 0.6% 26.8 -- Satnet 16 - AS35805 6686 0.6% 17.3 -- UTG-AS United Telecom AS 17 - AS11139 5639 0.5% 20.1 -- CWRIN CW BARBADOS 18 - AS8151 5587 0.5% 7.8 -- Uninet S.A. de C.V. 19 - AS17974 5362 0.5% 7.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS1237 5350 0.5% 37.4 -- KREONET-AS-KR Korea Institute of Science and Technology Information TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS45408 11986 1.1% 5993.0 -- 2 - AS5691 2436 0.2% 2436.0 -- MITRE-AS-5 - The MITRE Corporation 3 - AS4270 9020 0.9% 1804.0 -- Red de Interconexion Universitaria 4 - AS151 3951 0.4% 987.8 -- IND-NTC-AS - Hewlett-Packard Company 5 - AS18170 20829 2.0% 946.8 -- CHANGWON-AS-KR Changwon National University 6 - AS37020 795 0.1% 795.0 -- CELTEL-DRC 7 - AS31055 2282 0.2% 760.7 -- CONSULTIX-AS Consultix GmbH 8 - AS48672 630 0.1% 630.0 -- OKCIBANK-AS Commercial Bank GALS 9 - AS8668 3981 0.4% 568.7 -- TELONE-AS TelOne Zimbabwe P/L 10 - AS23699 2259 0.2% 564.8 -- EZNET-AS-ID IP Teknologi Komunikasi, PT. 11 - AS6822 2780 0.3% 556.0 -- SUPERONLINE-AS SuperOnline autonomous system 12 - AS48359 1589 0.1% 529.7 -- HESABGAR-AS Hesabgar Pardaz Gharb Co. Private J.S. 13 - AS36451 493 0.1% 493.0 -- FUJI-BEDFORD - Fujifilm Microdisks U.S.A., Inc. 14 - AS43818 484 0.1% 484.0 -- MELLAT-AS bankmellat 15 - AS41492 478 0.1% 478.0 -- EXIMBANK-AS BANCA DE EXPORT IMPORT A ROMANIEI (EXIMBANK) S.A 16 - AS28878 2237 0.2% 447.4 -- SIGNET-AS Signet B.V. 17 - AS3475 385 0.0% 385.0 -- LANT-AFLOAT - Navy Network Information Center (NNIC) 18 - AS10445 2851 0.3% 356.4 -- HTG - Huntleigh Telcom 19 - AS11057 349 0.0% 349.0 -- WTHOMPSONCO - J. Walter Thompson 20 - AS20066 319 0.0% 319.0 -- MORRISTECH - Morris Technologies, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 170.210.56.0/22 8949 0.8% AS4270 -- Red de Interconexion Universitaria 2 - 114.70.96.0/24 5993 0.5% AS45408 -- 3 - 114.70.97.0/24 5993 0.5% AS45408 -- 4 - 203.162.118.128/ 4970 0.4% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 5 - 110.234.206.0/23 3749 0.3% AS37986 -- TULIP Tulip Telecom Ltd. 6 - 110.234.208.0/23 3749 0.3% AS37986 -- TULIP Tulip Telecom Ltd. 7 - 110.234.204.0/23 3749 0.3% AS37986 -- TULIP Tulip Telecom Ltd. 8 - 222.255.186.0/25 3123 0.3% AS7643 -- VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT) 11 - 192.12.120.0/24 2436 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 12 - 62.168.199.0/24 2275 0.2% AS31055 -- CONSULTIX-AS Consultix GmbH 13 - 202.177.223.0/24 2239 0.2% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 14 - 143.138.107.0/24 2144 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 15 - 203.246.0.0/24 1728 0.1% AS18170 -- CHANGWON-AS-KR Changwon National University 16 - 59.22.142.0/24 1728 0.1% AS18170 -- CHANGWON-AS-KR Changwon National University 17 - 203.246.23.0/24 1728 0.1% AS18170 -- CHANGWON-AS-KR Changwon National University 18 - 59.22.138.0/23 1721 0.1% AS18170 -- CHANGWON-AS-KR Changwon National University 19 - 220.68.46.0/23 1721 0.1% AS18170 -- CHANGWON-AS-KR Changwon National University 20 - 203.246.0.0/19 1721 0.1% AS18170 -- CHANGWON-AS-KR Changwon National University 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 Jan 29 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Jan 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201001292200.o0TM00Du011931@wattle.apnic.net> This report has been generated at Fri Jan 29 21:11:29 2010 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-01-10 311605 190854 23-01-10 311842 190996 24-01-10 311898 190878 25-01-10 311978 191133 26-01-10 312175 191220 27-01-10 312280 191780 28-01-10 312419 191939 29-01-10 312562 192141 AS Summary 33460 Number of ASes in routing system 14256 Number of ASes announcing only one prefix 4389 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93061376 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street 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'). --- 29Jan10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 313065 192126 120939 38.6% All ASes AS6389 4135 322 3813 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4389 1744 2645 60.3% TWTC - tw telecom holdings, inc. AS4766 1859 486 1373 73.9% KIXS-AS-KR Korea Telecom AS1785 1851 694 1157 62.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1125 71 1054 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1273 283 990 77.8% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1569 662 907 57.8% Uninet S.A. de C.V. AS4755 1314 410 904 68.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 1010 162 848 84.0% TV Cable S.A. AS18101 1088 261 827 76.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1058 240 818 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18566 1059 380 679 64.1% COVAD - Covad Communications Co. AS6478 1106 428 678 61.3% ATT-INTERNET3 - AT&T WorldNet Services AS8452 963 297 666 69.2% TEDATA TEDATA AS4808 835 224 611 73.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS7303 672 108 564 83.9% Telecom Argentina S.A. AS7018 1587 1026 561 35.3% ATT-INTERNET4 - AT&T WorldNet Services AS3356 1210 657 553 45.7% LEVEL3 Level 3 Communications AS4134 1018 466 552 54.2% CHINANET-BACKBONE No.31,Jin-rong Street AS24560 839 295 544 64.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17908 765 229 536 70.1% TCISL Tata Communications AS7545 944 437 507 53.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 565 70 495 87.6% VTR BANDA ANCHA S.A. AS5668 787 293 494 62.8% AS-5668 - CenturyTel Internet Holdings, Inc. AS11492 1141 666 475 41.6% CABLEONE - CABLE ONE, INC. AS9443 545 80 465 85.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS9299 665 216 449 67.5% IPG-AS-AP Philippine Long Distance Telephone Company AS4780 601 154 447 74.4% SEEDNET Digital United Inc. AS855 610 164 446 73.1% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. Total 37261 11597 25664 68.9% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 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.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/24 AS36992 ETISALAT-MISR 117.103.72.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 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.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.145.251.0/24 AS38091 HELLONET-AS-KR CJ-CABLENET 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 195.110.34.0/23 AS45753 NETSEC-HK Unit 1205-1207 195.110.34.0/24 AS45753 NETSEC-HK Unit 1205-1207 195.110.35.0/24 AS45753 NETSEC-HK Unit 1205-1207 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.82.0/23 AS15290 ALLST-15290 - Allstream Corp. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc. 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc. 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 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.114.128.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.130.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.131.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.132.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.136.0/24 AS27044 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.138.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.144.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.148.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.150.0/24 AS6045 DNIC-ASBLK-05800-06055 - DoD Network Information Center 199.114.152.0/24 AS27033 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.114.153.0/24 AS27034 DNIC-ASBLK-27032-27159 - 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 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet 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.87.102.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 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.143.56.0/21 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 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.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 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/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.189.96.0/20 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/23 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.192.0/20 AS14697 VDOTNET - VDot.Net 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.99.20.0/24 AS3356 LEVEL3 Level 3 Communications 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.243.240.0/20 AS12182 INTERNAP-2BLK - Internap Network Services Corporation 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 222.0.0.0/8 AS9484 MOBINET-AS-MN Mobicom Company. AS Mobinet Internet Service Provider 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 nonobvious at gmail.com Fri Jan 29 16:07:50 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 29 Jan 2010 14:07:50 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <63ac96a51001250114r7a61e3a4pc4be3ad7165a1c41@mail.gmail.com> <4B6020A1.3010500@ibctech.ca> Message-ID: <18a5e7cb1001291407v700e9c7ek8f16841345d895b6@mail.gmail.com> On Wed, Jan 27, 2010 at 1:19 PM, Igor Gashinsky wrote: > 1) ping-ponging of packets on Sonet/SDH links > 2) ping sweep of death ... > For most people, using /127's will be a lot operationaly easier then > maintain those crazy ACLs, but, like I said before, YMMV.. I'm in the /112 camp - it's not going to be much worse for attack 2, and I've been dealing with a lot of IPv4 operational issues where you need subnets with enough addresses for VRRP/HSRP/NSRP/etc, equipment management addresses for devices that aren't the main address, byte-aligned database entries, monitoring boxes of various sorts, extra NATs for applications nobody told you about when you set things up, splitting subnets into smaller contiguous subnets because of equipment limitations or vendor compatibility problems with IPSEC tunnels, etc. And the other interesting address length proposal was 80 bits, typically imagined as 20 BCD digits, proposed by phone company types. 128 is better... -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From leen at consolejunkie.net Fri Jan 29 16:40:36 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Fri, 29 Jan 2010 23:40:36 +0100 Subject: Level 3 DC issues? In-Reply-To: <006d01caa119$87a014b0$96e03e10$@edu> References: <3D719D3666BE44C9A8E7F292B51FCF53@TAKA> <006d01caa119$87a014b0$96e03e10$@edu> Message-ID: <4B6363E4.60808@consolejunkie.net> On 01/29/2010 08:30 PM, Robert D. Scott wrote: > Looks like an internal problem to BoA. The redirect works, and I get an > immediate reply. The https redirect page appears boinked. Even with a -k > curl took over 30 seconds to get the page, and the browser would have timed > out. > > Hi, Just noticed this article, maybe BoA is also a target ?: CIA, PayPal under bizarre SSL assault The "massive" flood of requests is made over the websites' SSL, or secure-sockets layer, port, causing them to consume more resources than normal connections, according to researchers at Shadowserver Foundation, a volunteer security collective. The torrent started about a week ago and appears to be caused by recent changes made to a botnet known as Pushdo . http://www.theregister.co.uk/2010/01/29/strange_ssl_web_attack/ http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100129 Maybe that has something to do with this ? Hope you have a nice weekend. > robert at Robert ~ > $ curl -i -G www.bankofamerica.com > HTTP/1.1 301 Moved Permanently > Server: Sun-ONE-Web-Server/6.1 > Date: Fri, 29 Jan 2010 19:25:08 GMT > Content-length: 122 > Content-type: text/html > Location: https://www.bankofamerica.com/index.jsp > Connection: close > > Moved Permanently >

Moved Permanently

> An error has occurred. > > robert at Robert ~ > $ curl -i -G www.bankofamerica.com > HTTP/1.1 301 Moved Permanently > Server: Sun-ONE-Web-Server/6.1 > Date: Fri, 29 Jan 2010 19:25:28 GMT > Content-length: 122 > Content-type: text/html > Location: https://www.bankofamerica.com/index.jsp > Connection: close > > Moved Permanently >

Moved Permanently

> An error has occurred. > > robert at Robert ~ > $ curl -i -G https://www.bankofamerica.com/index.jsp > curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed > More details here: http://curl.haxx.se/docs/sslcerts.html > > curl performs SSL certificate verification by default, using a "bundle" > of Certificate Authority (CA) public keys (CA certs). If the default > bundle file isn't adequate, you can specify an alternate file > using the --cacert option. > If this HTTPS server uses a certificate signed by a CA represented in > the bundle, the certificate verification probably failed due to a > problem with the certificate (it might be expired, or the name might > not match the domain name in the URL). > If you'd like to turn off curl's verification of the certificate, use > the -k (or --insecure) option. > > robert at Robert ~ > $ curl -k -i -G https://www.bankofamerica.com/index.jsp > > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > 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: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] > Sent: Friday, January 29, 2010 2:22 PM > To: NANOG list > Subject: Level 3 DC issues? > > Anyone see any connectivity issues with Level-3 in the DC area? This issue > is causing big latency problems > that appeared to have taken out Bank of America's website. > > > > > > > From packetgrrl at gmail.com Fri Jan 29 19:21:32 2010 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 29 Jan 2010 18:21:32 -0700 Subject: Apply Now for ARIN Meetings Fellowship to Attend ARIN XXV Message-ID: ARIN is pleased to offer a Meetings Fellowship Program to bring new voices and ideas to public policy discussions. This call is for Fellows to attend ARIN XXV in Toronto, Canada 18-21 April 2010. If you are interested in participating in the program, submit your application by 19 February. The application, submission instructions, and a detailed description of the program can be found at: https://www.arin.net/participate/meetings/fellowship.html One individual from each of the three sectors within ARIN's service region (Canada, the Caribbean and North Atlantic Islands, and the United States and Outlying Areas) will be selected. Fellows receive financial support to attend the Public Policy and Members Meeting, and ARIN Advisory Council representatives will serve as mentors to the fellows to help maximize their meeting experience. Individuals selected for the fellowship receive: * Free meeting registration https://www.arin.net/participate/meetings/ARIN-XXV/ * Round-trip economy class airfare to the meeting, booked directly by ARIN * Hotel accommodations at the venue hotel, booked directly by ARIN * A stipend to cover meals and incidental travel expenses. Please contact info at arin.net if you have any questions concerning the program and the application process. Regards, Cathy Aronson ARIN Advisory Council From bobbyjim at gmail.com Fri Jan 29 22:47:57 2010 From: bobbyjim at gmail.com (Bobby Mac) Date: Fri, 29 Jan 2010 22:47:57 -0600 Subject: SSH brute force China and Linux: best practices Message-ID: Hola Nanog: So after many years of a hiatus from Linux, I recently dropped XP in favour of Fedora. Now that my happy windows blinders are off, I see alarming things. Ugly ssh brute force, DNS server IP spoofing with scans and typical script kiddie tactics. What are the new set of best practices for those running a NIX home computer. Yes I have a firewall and I do peruse my logs on a regular basis. BTW: ever drop a malformed URL to alert an admin to some thing that sucks? w3.hp.com/execs/makes/too/much/money or www.yourbuddiesdomain.com/it/is/all/rfc/space/use/1918/when/referring/to/non/routable Thanks, BobbyMac From joelja at bogus.com Sat Jan 30 00:54:10 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 29 Jan 2010 22:54:10 -0800 Subject: Using /126 for IPv6 router links In-Reply-To: References: <0C4E3B08-C930-411A-8E8E-53B528C039E8@mironet.ch> <4B5BB40C.3080206@cox.net> <4B5D6091.1080602@nosignal.org> <20100125104501.GG75640@gerbil.cluepon.net> <4B5DE7E6.7000200@cox.net> <9F92B780-8364-4F86-AD34-10BD10B99F8F@delong.com> <4B5F0243.2040605@ttec.com> Message-ID: <4B63D792.5090307@bogus.com> Daniel Senie wrote: > On Jan 26, 2010, at 9:54 AM, Joe Maimon wrote: > >> For me, the entire debate boils down to this question. >> >> What should the objective be, decades or centuries? > > If centuries, how many planets and moons will the address space > cover? (If we as a species manages to spread beyond this world before > we destroy it). Will separate /3's, or subdivisions of subsequent > /3's, be the best approach to deploying a large-scale IPv6 network on > Mars? (and yes, a bit of work would be required to make the > round-trip times fall within TCP's windows). If The useful life of ipv6 is as long as ipv4 we've been pretty successful. It's is (or seems that way to me) likely that pressures other than address exhaustion will consign it to the historybooks. From bazy84 at gmail.com Sat Jan 30 04:22:37 2010 From: bazy84 at gmail.com (Bazy) Date: Sat, 30 Jan 2010 12:22:37 +0200 Subject: SSH brute force China and Linux: best practices In-Reply-To: References: Message-ID: <6c2184ab1001300222q37847365g81d6e5f8a9dbac73@mail.gmail.com> On Sat, Jan 30, 2010 at 6:47 AM, Bobby Mac wrote: > Hola Nanog: > > So after many years of a hiatus from Linux, ?I recently dropped XP in favour > of Fedora. ?Now that my happy windows blinders are off, I see alarming > things. ?Ugly ssh brute force, DNS server IP spoofing with scans and typical > script kiddie tactics. > > What are the new set of best practices for those running a NIX home > computer. ?Yes I have a firewall and I do peruse my logs on a regular > basis. > > BTW: ever drop a malformed ?URL to alert an admin to some thing that sucks? > w3.hp.com/execs/makes/too/much/money or > www.yourbuddiesdomain.com/it/is/all/rfc/space/use/1918/when/referring/to/non/routable > > Thanks, > BobbyMac > Hello Bobby, Take a look at http://www.fail2ban.org and http://denyhosts.sourceforge.net. I'm not Chinese but I'm sure that brute-force attacks come from all over the world. Here's a little from my logwatch. Refused incoming connections: 211.234.60.44 (211.234.60.44): 1 Time(s) 218.3.88.114 (218.3.88.114): 1 Time(s) 58.68.119.187 (58.68.119.187): 2 Time(s) 89.149.149.132 (89.149.149.132): 5 Time(s) net137-143.paichai.ac.kr (203.250.137.143): 1 Time(s) Regards, Bazy From deric.kwok2000 at gmail.com Sat Jan 30 08:07:08 2010 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 30 Jan 2010 09:07:08 -0500 Subject: domain registra question Message-ID: <40d8a95a1001300607u2a956153w67755b75ecc36e3e@mail.gmail.com> Hi We are doing hosting and We are interested in doing Domain registra Could you provide more info? Thank you From deric.kwok2000 at gmail.com Sat Jan 30 08:50:29 2010 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 30 Jan 2010 09:50:29 -0500 Subject: domain registra question In-Reply-To: References: <40d8a95a1001300607u2a956153w67755b75ecc36e3e@mail.gmail.com> Message-ID: <40d8a95a1001300650k527acb3dg5ea88c326a3459a0@mail.gmail.com> Hi Thank you so much Do we need to setup any application for processing? I don't understand this whols. ls it serve? Thank you again On Sat, Jan 30, 2010 at 9:22 AM, hutuworm wrote: > You may want to check the Registrar Tasks section at > http://www.icann.org/en/processes/ > > *Registrar Tasks* > > - Registrar Accrediation Process [PDF, > 16K] > - Registrar Accreditation Agreement Renewal Process [PDF, > 16K] > - Assignment Process [PDF, > 16K] > - Adding a gTLD Appendix [PDF, > 12K] > - ICANN Procedure for Handling Conflicts with Privacy Law > - De-Accredited Registrar Transition Procedure [PDF, > 121K] > > > On Sat, Jan 30, 2010 at 10:07 PM, Deric Kwok wrote: > >> Hi >> >> We are doing hosting and >> >> We are interested in doing Domain registra >> >> Could you provide more info? >> >> Thank you >> >> > From cra at WPI.EDU Sat Jan 30 11:16:03 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 30 Jan 2010 12:16:03 -0500 Subject: SSH brute force China and Linux: best practices In-Reply-To: References: Message-ID: <20100130171603.GA7256@angus.ind.WPI.EDU> On Fri, Jan 29, 2010 at 10:47:57PM -0600, Bobby Mac wrote: > What are the new set of best practices for those running a NIX home > computer. Yes I have a firewall and I do peruse my logs on a regular > basis. 1. Don't have services listening unless you need them. 2. If you can, move needed services to nonstandard ports. If the only ports you have open are for services you want/need to access from anywhere, then you don't need a firewall. > BTW: ever drop a malformed URL to alert an admin to some thing that sucks? > w3.hp.com/execs/makes/too/much/money or > www.yourbuddiesdomain.com/it/is/all/rfc/space/use/1918/when/referring/to/non/routable Yes. From joelja at bogus.com Sat Jan 30 11:35:31 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 30 Jan 2010 09:35:31 -0800 Subject: SSH brute force China and Linux: best practices In-Reply-To: References: Message-ID: <4B646DE3.9020203@bogus.com> iptables -A INPUT -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP iptables -A INPUT -m recent --set --name SSH --rsource -j ACCEPT also enforce either strong passwords or require no passwords (e.g. keys only) and everything should be cool. Bobby Mac wrote: > Hola Nanog: > > So after many years of a hiatus from Linux, I recently dropped XP in favour > of Fedora. Now that my happy windows blinders are off, I see alarming > things. Ugly ssh brute force, DNS server IP spoofing with scans and typical > script kiddie tactics. > > What are the new set of best practices for those running a NIX home > computer. Yes I have a firewall and I do peruse my logs on a regular > basis. > > BTW: ever drop a malformed URL to alert an admin to some thing that sucks? > w3.hp.com/execs/makes/too/much/money or > www.yourbuddiesdomain.com/it/is/all/rfc/space/use/1918/when/referring/to/non/routable > > Thanks, > BobbyMac > From john.mason.jr at cox.net Sat Jan 30 12:03:39 2010 From: john.mason.jr at cox.net (John Mason Jr) Date: Sat, 30 Jan 2010 13:03:39 -0500 Subject: SSH brute force China and Linux: best practices In-Reply-To: References: Message-ID: <4B64747B.1070002@cox.net> On 1/29/2010 11:47 PM, Bobby Mac wrote: > Hola Nanog: > > So after many years of a hiatus from Linux, I recently dropped XP in favour > of Fedora. Now that my happy windows blinders are off, I see alarming > things. Ugly ssh brute force, DNS server IP spoofing with scans and typical > script kiddie tactics. > > What are the new set of best practices for those running a NIX home > computer. Yes I have a firewall and I do peruse my logs on a regular > basis. > > BTW: ever drop a malformed URL to alert an admin to some thing that sucks? > w3.hp.com/execs/makes/too/much/money or > www.yourbuddiesdomain.com/it/is/all/rfc/space/use/1918/when/referring/to/non/routable > > Thanks, > BobbyMac > > Might want t to look at Micheal Rash's site http://cipherdyne.org/LinuxFirewalls/ to get some ideas John From brunner at nic-naa.net Sat Jan 30 12:35:34 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 30 Jan 2010 13:35:34 -0500 Subject: domain registra question In-Reply-To: <40d8a95a1001300650k527acb3dg5ea88c326a3459a0@mail.gmail.com> References: <40d8a95a1001300607u2a956153w67755b75ecc36e3e@mail.gmail.com> <40d8a95a1001300650k527acb3dg5ea88c326a3459a0@mail.gmail.com> Message-ID: <4B647BF6.1080207@nic-naa.net> Deric, I run a small registrar, and I'm the CTO (confused, tired and overworked) of a medium sized registrar, which as it happens does offer the "how to become a registrar" as a consultancy product. There are a number of procedural steps to take to obtain "ICANN accreditation". At that point you have two choices, stop and "rent your threads" to a back-order specialist, or continue and build or acquire a registrar "system" capable of passing OT&E at the ICANN accredited registries of your choice. The former "rent your threads" used to pay rather handsomely, but with some 600 shell registrars dividing up the value, the pay out now is slightly more than what ICANN accreditation costs. The later "build or buy and operate" is something you could be doing now, as a reseller of a registrar which has a reseller-model. Not to advertise, but the medium sized registrar for which I'm the CTO has a member model, and its members act as registrars, though in fact it is only the membership association which holds the ICANN accreditation (though in fact several member companies, such as mine, also hold ICANN accreditation in their own right). You have several choices if you "buy". There are "registrar in a can" vendors. You also have several choices if you "build", every registry provides an EPP kit for registrars (it is in their self-interest), and as an added feature (or bug) there are registry-specific "extensions", different versions of the same kit, and so on. I am, at the moment, reviewing the refactoring task for a registrar which supports every ICANN generic and sponsored TLDs, and about a dozen country-code registries. For many, the money is in COM/NET/ORG, though in Asia the ASIA product may be as important. Then there is the market, yours as a hosting provider, and ICANN's as a set of contracts creating 20 registries, some of which are of very limited interest, and 900 registrars, more than 2/3rds of which are shell registrars, exist. You'll be paying $0.20 per domain name year to ICANN, and $6 (approximately) to the registries (COM/NET, ORG/INFO, BIZ), and your margin will be something in excess of that ... or not. Some registrars sell domains at a loss (actually below registry+ICANN cost, and some merely below their cost), making their margin on hosting or other services. Half of all registration is done by five registrars, it is a highly concentrated industry, and credit card fraud (charge backs) are a problem for the registrars who accept credit card data as payment. Good luck! Eric On 1/30/10 9:50 AM, Deric Kwok wrote: > Hi > > Thank you so much > > Do we need to setup any application for processing? > > I don't understand this whols. ls it serve? > > Thank you again > > On Sat, Jan 30, 2010 at 9:22 AM, hutuworm wrote: > >> You may want to check the Registrar Tasks section at >> http://www.icann.org/en/processes/ >> >> *Registrar Tasks* >> >> - Registrar Accrediation Process [PDF, >> 16K] >> - Registrar Accreditation Agreement Renewal Process [PDF, >> 16K] >> - Assignment Process [PDF, >> 16K] >> - Adding a gTLD Appendix [PDF, >> 12K] >> - ICANN Procedure for Handling Conflicts with Privacy Law >> - De-Accredited Registrar Transition Procedure [PDF, >> 121K] >> >> >> On Sat, Jan 30, 2010 at 10:07 PM, Deric Kwokwrote: >> >>> Hi >>> >>> We are doing hosting and >>> >>> We are interested in doing Domain registra >>> >>> Could you provide more info? >>> >>> Thank you >>> >>> >> > > From mysidia at gmail.com Sat Jan 30 13:06:17 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 30 Jan 2010 13:06:17 -0600 Subject: SSH brute force China and Linux: best practices In-Reply-To: <6c2184ab1001300222q37847365g81d6e5f8a9dbac73@mail.gmail.com> References: <6c2184ab1001300222q37847365g81d6e5f8a9dbac73@mail.gmail.com> Message-ID: <6eb799ab1001301106y6f669ba3gb206972417aa6135@mail.gmail.com> When you really want to be safe -- even one illicit access attempt may be enough to gain access. fail2ban or ssh rate limiting do not stop distributed brute force attacks. The best action depends on a tradeoff between OPSEC network operations security considerations VS any legitimate need for quick remote access/admin convenience also Versus simplicity / difficulty to implement : If feasible, BCP38 + use of a destination port 22 ACL on the first/last hop router to discard unexpected SSH traffic to your protected LAN(s) from outside your IP prefixes, and therefore all local NIX servers. For ISPs, ssh blocking ACL should apply to your own device and router subnets, but not downstream end-users. + In case access is desired from unknown remote IPs: dynamic ACL and creative use of a facility such as "access-enable" on router: or port knocking protection [on the ssh server itself]. If security is more important and readily available/quick remote access from offsite is not important: then a secure VPN router + remote access VPN, is a difficult target for an attacker (but susceptible to failure either on client side or hardware failure on remote side). For port knocking http://www.portknocking.org/view/implementations E.g. fwknop / knockd / BSD Doorman / knockdaemon / PortknockO This is in ADDITION to (not a replacement for) additional security measures on individual hosts, such as the below. --------- Forwarded message ---------- From: James Hess Date: Sat, Jan 30, 2010 at 12:23 AM Subject: Re: SSH brute force China and Linux: best practices To: Bobby Mac For home? Turn off the SSH daemon and keep it off, unless you really need it. Or use iptables and /etc/hosts.deny + /etc/hosts.allow to limit access to local IPs. The considerations for a NIX workstation are really no different than with any network device, port 22 is under constant attack, you might want to filter upstream somewhere. Keep network software up-to-date with patches. Set strong passwords. Disable remote login to the admin/root user. Use ssh only: telnet is unsafe. Configure an unofficial alternative port number for ssh (one numbered below 1024 but not port 22). Ban password-based auth in favor of public key, SSL Certificate, or Kerberos/GSSAPI-based authentication (with Kerberos, configure it so a SSH client can only authenticate by first holding a Kerberos ticket, instead of the default of allowing client to enter a password and server to obtain a ticket on client's behalf). It's really hard to guess a valid 2048-bit DSA key by brute force (a lot harder than guessing the average 8-character password). From bclark at spectraaccess.com Sat Jan 30 13:52:48 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Sat, 30 Jan 2010 14:52:48 -0500 Subject: SSH brute force China and Linux: best practices In-Reply-To: <6eb799ab1001301106y6f669ba3gb206972417aa6135@mail.gmail.com> References: <6c2184ab1001300222q37847365g81d6e5f8a9dbac73@mail.gmail.com> <6eb799ab1001301106y6f669ba3gb206972417aa6135@mail.gmail.com> Message-ID: <4B648E10.9050206@spectraaccess.com> denyhost is one of my favorite apps. http://denyhosts.sourceforge.net/ James Hess wrote: > When you really want to be safe -- even one illicit access attempt may > be enough to gain access. fail2ban or ssh rate limiting do not > stop distributed brute force attacks. > > The best action depends on a tradeoff between OPSEC network operations > security considerations VS any legitimate need for quick remote > access/admin convenience also Versus simplicity / difficulty to > implement : If feasible, BCP38 + use of a destination port 22 ACL > on the first/last hop router to discard unexpected SSH traffic to > your protected LAN(s) from outside your IP prefixes, and therefore > all local NIX servers. > > For ISPs, ssh blocking ACL should apply to your own device and router > subnets, but not downstream end-users. > > + In case access is desired from unknown remote IPs: dynamic ACL and > creative use of a facility such as "access-enable" on router: or > port knocking protection [on the ssh server itself]. > > If security is more important and readily available/quick remote > access from offsite is not important: then a secure VPN router + > remote access VPN, is a difficult target for an attacker (but > susceptible to failure either on client side or hardware failure on > remote side). > > For port knocking > http://www.portknocking.org/view/implementations > E.g. fwknop / knockd / BSD Doorman / knockdaemon / PortknockO > > This is in ADDITION to (not a replacement for) additional security > measures on individual hosts, such as the below. > > > --------- Forwarded message ---------- > From: James Hess > Date: Sat, Jan 30, 2010 at 12:23 AM > Subject: Re: SSH brute force China and Linux: best practices > To: Bobby Mac > > For home? Turn off the SSH daemon and keep it off, unless you really need it. > Or use iptables and /etc/hosts.deny + /etc/hosts.allow > to limit access to local IPs. > > The considerations for a NIX workstation are really no different than > with any network device, port 22 is under constant attack, you > might want to filter upstream somewhere. Keep network software > up-to-date with patches. > > Set strong passwords. Disable remote login to the admin/root user. > Use ssh only: telnet is unsafe. Configure an unofficial > alternative port number for ssh (one numbered below 1024 but not port > 22). > > Ban password-based auth in favor of public key, SSL Certificate, or > Kerberos/GSSAPI-based authentication (with Kerberos, configure it so > a SSH client can only authenticate by first holding a Kerberos ticket, > instead of the default of allowing client to enter a password and > server to obtain a ticket on client's behalf). > > It's really hard to guess a valid 2048-bit DSA key by brute force > (a lot harder than guessing the average 8-character password). > > From beckman at angryox.com Sat Jan 30 13:55:19 2010 From: beckman at angryox.com (Peter Beckman) Date: Sat, 30 Jan 2010 14:55:19 -0500 Subject: SSH brute force China and Linux: best practices In-Reply-To: <6c2184ab1001300222q37847365g81d6e5f8a9dbac73@mail.gmail.com> References: <6c2184ab1001300222q37847365g81d6e5f8a9dbac73@mail.gmail.com> Message-ID: On Sat, 30 Jan 2010, Bazy wrote: > On Sat, Jan 30, 2010 at 6:47 AM, Bobby Mac wrote: > >> So after many years of a hiatus from Linux, ?I recently dropped XP in favour >> of Fedora. ?Now that my happy windows blinders are off, I see alarming >> things. ?Ugly ssh brute force, DNS server IP spoofing with scans and typical >> script kiddie tactics. > > Take a look at http://www.fail2ban.org and > http://denyhosts.sourceforge.net. I'm not Chinese but I'm sure that > brute-force attacks come from all over the world. Here's a little from > my logwatch. For securing ssh, better than either of those is sshguard. fail2ban is a Python script, as is denyhosts. Script-based services are fine, but native compiled code is better, lower memory, less overhead. sshguard is better because it's written in C, can read multiple log formats, can block for many popular services (dovecot, ftp daemons, even an imap daemon) and it works with many popular existing firewalls: pf, netfilter, iptables, ipfw, ipfilter, tcpd, even IBM's AIX firewall. http://www.sshguard.net/ I've run it for 3 years now, solid as a rock. Questions are quickly answered in the mailing lists by the lead developer Mij. Additionally, you may want to consider using SSH Key Authorization only, and disable password authentication. This guarantees that brute force attacks will fail, because they only use username + Password (AFAICT), not random private keys. Here is a good article on how to enable Key-based auth (may already be enabled), as well as how to turn Password Auth off in ssh to protect/eliminate ssh brute force successes. http://www.debuntu.org/ssh-key-based-authentication Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From randy at psg.com Sat Jan 30 14:12:07 2010 From: randy at psg.com (Randy Bush) Date: Sat, 30 Jan 2010 15:12:07 -0500 Subject: SSH brute force China and Linux: best practices In-Reply-To: <4B646DE3.9020203@bogus.com> References: <4B646DE3.9020203@bogus.com> Message-ID: > also enforce either strong passwords or require no passwords (e.g. keys > only) and everything should be cool. what is 'password'? randy From jgreco at ns.sol.net Sat Jan 30 14:51:46 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 30 Jan 2010 14:51:46 -0600 (CST) Subject: SSH brute force China and Linux: best practices In-Reply-To: from "Randy Bush" at Jan 30, 2010 03:12:07 PM Message-ID: <201001302051.o0UKplH1028963@aurora.sol.net> > > also enforce either strong passwords or require no passwords (e.g. keys > > only) and everything should be cool. > > what is 'password'? "password" is that thing that you use when you don't want one compromised "passphrase for your DSA key" to give access to every resource under the sun that you have access to. Keys are fantastic when used to access a resource with relatively permissive (or no) IP-based access lists, automated applications, etc. However, where I have a resource that's already heavily restricted for SSH by ACL, I sometimes prefer an actual password that has to be dredged out of memory. ... 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 sean at donelan.com Sat Jan 30 15:58:50 2010 From: sean at donelan.com (Sean Donelan) Date: Sat, 30 Jan 2010 16:58:50 -0500 (EST) Subject: Countries with the most botnets In-Reply-To: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> References: <77ACDBE9-AFF1-4D40-B6B1-247590B4E836@cs.columbia.edu> Message-ID: On Wed, 27 Jan 2010, Steven Bellovin wrote: > A colleague needs to know, along with citable sources if possible. > > Ideally - number of zombified PCs, percentage of zombified PCs, name of > nation, source. > > Threat reports from symantec and macafee suggest the US leads, with > China a very close second. > > Yes, we realize that answers will be imperfect. Data is of course needed as a starting point. But does anyone have anything to explain differences between countries, industries, some other distinction, if any? Although we use terms from biology, i.e. infection, virus, etc; bots aren't naturally occuring phenomena. Or even in small communities, do universities have differences between themselves? Resnets vs faculty? Engineering vs arts & sciences? From andrew.wallace at rocketmail.com Sat Jan 30 16:36:50 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 30 Jan 2010 22:36:50 +0000 Subject: Fwd: [Pauldotcom] Skiddy Interview In-Reply-To: <4b6ee9311001301331p5b77c296ua22c7b9d8b1e9961@mail.gmail.com> References: <4b6ee9311001301331p5b77c296ua22c7b9d8b1e9961@mail.gmail.com> Message-ID: <4b6ee9311001301436u631e27a1r6b66c860b65c83d2@mail.gmail.com> ---------- Forwarded message ---------- From: andrew.wallace Date: Sat, Jan 30, 2010 at 9:31 PM Subject: Re: [Pauldotcom] Skiddy Interview To: Adrian Crenshaw Cc: PaulDotCom Security Weekly Mailing List On Sat, Jan 30, 2010 at 3:10 PM, Adrian Crenshaw wrote: > Kind of interesting Skiddy Interview: > > http://hackerpublicradio.org/eps/hpr0505.mp3 > > Guy seems pretty uneducated, but it gives you an idea of the mentality. No > offence meant to the HPR podcast, it has some good stuff. > Like your comments. > > Adrian > He mentions selling a Bank of America employee account starting around 7 minutes 40 seconds, which just suffered a Denial of Service attack to its website. http://isc.sans.org/diary.html?storyid=8119 Any connection? Of course probably not, but just thought i'd throw it out there anyway. Andrew From johnl at iecc.com Sat Jan 30 19:01:45 2010 From: johnl at iecc.com (John Levine) Date: 31 Jan 2010 01:01:45 -0000 Subject: domain registra question In-Reply-To: <40d8a95a1001300607u2a956153w67755b75ecc36e3e@mail.gmail.com> Message-ID: <20100131010145.21753.qmail@simone.iecc.com> >We are doing hosting and >We are interested in doing Domain registra >Could you provide more info? Although Eric is correct that you can become an ICANN accredited registrar, that's probably not what you want to do. Many registrars have reseller programs which allow you to sell domain registrations that are actually handled by the registrar whose service you are reselling. If you just want to let your customers register the domains they use in their hosted web sites, that's much, much easier. I resell Tucows (www.opensrs.com) and am happy with them, but you should look at several large registrars and choose the one that best meets your needs. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From brunner at nic-naa.net Sat Jan 30 19:41:48 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 30 Jan 2010 20:41:48 -0500 Subject: domain registra question In-Reply-To: <20100131010145.21753.qmail@simone.iecc.com> References: <20100131010145.21753.qmail@simone.iecc.com> Message-ID: <4B64DFDC.1020407@nic-naa.net> On 1/30/10 8:01 PM, John Levine wrote: >> We are doing hosting and >> We are interested in doing Domain registra >> Could you provide more info? > > Although Eric is correct that you can become an ICANN accredited > registrar, that's probably not what you want to do. Agree, but I'm not going to tell him (or anyone) what they should want. For all I know he sees some present value entering the highly concentrated CNO industry, or some future value as a registrar with operational clue in the 20+ inventory market, when the number of inventories increases substantially. > Many registrars have reseller programs which allow you to sell > domain registrations that are actually handled by the registrar > whose service you are reselling. If you just want to let your > customers register the domains they use in their hosted web sites, > that's much, much easier. > > I resell Tucows (www.opensrs.com) and am happy with them, but you > should look at several large registrars and choose the one that > best meets your needs. Distinct from the question of member (of CORE) vs reseller (of any registrar offering a reseller model), members having a voice in the policy and management of the registrar, resellers not, is the issue of shared fate. A reseller shares fate with all other resellers of a particular registrar. Eric