From dave at temk.in Fri Mar 1 17:02:11 2013 From: dave at temk.in (David Temkin) Date: Fri, 1 Mar 2013 12:02:11 -0500 Subject: NANOG 58 - New Orleans - Call For Presentations is open! Message-ID: *Fresh off of a great NANOG 57 in Orlando, your program committee is already working hard to provide a world-class program for NANOG 58 in NOLA - New Orleans, Louisiana - one of my favorite destinations in the world.* * * *As a reminder, we will be following the same Monday-Wednesday program that we started at NANOG 57, with Tutorials beginning Monday morning and closing with the Peering Track (and potentially a social) on Wednesday evening. * * * *We look forward to seeing everyone in The Big Easy!* * -------------------- The North American Network Operators' Group (NANOG) will hold its 58th meeting in New Orleans on June 3rd - 5th, 2013 Verizon Terremark will host NANOG 58. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, keynote materials, and the NOGLab experience for the NANOG 58 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability via the program and as part of the NOGLab. NANOG 58 submissions are welcome at http://pc.nanog.org. About NANOG NANOG is the premier meeting for network operators in North America. Meetings provide a forum for information exchange among network operators, engineers, and researchers. NANOG meets three times each year, and includes panels, presentations, tutorial sessions, tracks, informal BOFs, and a NOGLab which features interoperability demonstrations. NANOG attendees include operators from networks of all sizes, enterprise operators, peering coordinators, transport and switching equipment vendors, and network researchers. NANOG attendees will share ideas and interact with leaders in the field of network operations, discuss current operational events and issues, and learn about state-of-the-art operational techniques. Materials from NANOG 58 will be archived at: http://www.nanog.org/meetings/nanog58/ Key Dates for NANOG 58 ? CFP Opens for NANOG 58: 25-February-2013 ? CFP Deadline #1: Presentation Abstracts Due: 8-April-2013 ? CFP Deadline #2: Presentation Slides Due: 29-April-2013 ? NANOG Highlights Page Posted: 22-April-2013 ? Preliminary Topic List Posted: 26-April-2013 ? Meeting Agenda Published: 13-May-2013 ? Meeting Agenda Final sent to printer: 20-May-2013 ? Lightning Talk Submissions Open (Abstracts Only): 2-June-2013 ? Speaker FINAL presentations to PCTool or speaker-support: 31-May-2013 ? On-Site Registration: 31-May-2013 The NANOG Program Committee seeks proposals for presentations, panels, tutorial sessions, tracks, and BOFs in all areas of network operations, including (but not limited to): - Power and facilities - Topics may include power reliability and engineering, green power, power efficiency, cooling, and facilities management. - Interconnections - Topics may include IXes, intra-building, MMR, metro-wide connections, peering, and transit purchasing tactics and strategies. - Security - Topics may include routing security, route filtering of large peers/customers, and inter-AS security and cooperation. - DNS - Topics may include using DNS data for network metrics, botnet discovery, and geolocation. - IPv6 - Topics may include real-world deployment challenges, Carrier Grade NAT, NAT-PT implementations that work and scale, and allocation strategies. - Content - Topics may include Distribution (p2p, IPTV), content payment models, content distribution technologies and networks, and storage/archiving. - Disaster recovery - Topics may include risk analysis, training, agencies, planning methods, hardware portability, key tools, transport audits, and other lessons learned. In general, presentations are being sought by and for network operators of all sizes. Presentations about difficult problems (and interesting solutions) that you encounter in the course of your job are encouraged. In addition, the Program Committee, through participation with other organizations and vendor?s, will be programming a NOGLab experience. The topic of the NOGLab will be timely and feature real-world experiences faced by operators of today?s Internet. If you think you have an interesting topic but want some feedback or assistance working it into a presentation, please email the Program Committee chair (chair at pc.nanog.org), and a representative on the Program Committee will give you the feedback needed to work it into a presentation. Otherwise, don't delay in submitting your talk, keynote, track, or panel into the NANOG Program Committee tool, located at http://pc.nanog.org. For more information about talk types and format, please see http://nanog.org/presentations/guidelines/talktips.php How to Present The deadline for accepting abstracts and slides is April 8, 2013 . While the majority of speaking slots may be filled by that date, a limited number of slots may be available after that date for topics that are exceptionally timely, important, or critical to the operations of the Internet. Complete Presentation Guidelines can be found at http://nanog.org/presentations/ The primary speaker, moderator, or author should submit presentation information and an abstract online at: http://pc.nanog.org once you have done this, you will receive instructions for submitting your draft slides. - Author's name(s) - Preferred contact email address - A preferred phone number for contact - Submission category (General Session, Panel, Tutorial, or Research Forum) - Presentation title - Abstract - Slides (attachment or URL), in PDF (preferred) or PowerPoint format. We look forward to reviewing your submission. Talks Keynote Presentation: The Program Committee invites speakers to submit materials for up to one-hour keynote presentations. Speakers should indicate that their submission is for a keynote in their abstracts. Speaker must submit slides for a Keynote Presentation. General Session Talk: A General Session presentation should be on a topic of interest to the general NANOG audience, and may be up to 30-minutes long (including time for Q&A). Speakers must submit slides for a General Session presentation. General Session Panel: Panels are 60-90-minute discussion sessions between a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection will be based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. After acceptance the panel leader will be given the option to invite panel authors to submit their presentations to the NANOG program Committee for review. Until then authors should not submit their individual presentations for the panel. Tracks: Tracks are 90-minute informal agenda blocks on topics, which are of interest to a portion of the NANOG community. The 90-minute block can be subdivided into a number of smaller, highly related presentations, panels or open discussion. A moderator coordinates content within the 90-minute block of time, and must submit a detailed outline to the Program Committee, including sub-topics and presenters Peering ISP Security Tools Typically two tracks or three tracks will be run concurrently. Tutorials: Tutorials are 90-minute sessions. A presentation from the introductory through advanced level on all related topics, including: Disaster Recovery Planning Troubleshooting BGP Best Practices for Determining Traffic Matrices Options for Blackhole and Discard Routing BGP/MPLS Layer 3 VPNs Peering business and engineering basics A tutorial submission should include an abstract and slides. BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics, which are of interest to a portion of the NANOG community. BOFs may be held in the hallways, breakout areas or in an unscheduled tutorial room. Requests for scheduled BOFs will be take place on site at the meeting. A typical BOF session may include some structure or presentations, but usually is focused on community discussion and interaction. Frequent BOF topics include: R&D collaboration Hot-topics in the media The less structured nature of BOF sessions allows for the greatest flexibility from a timing perspective. Lightning Talks: A lightning talk is a very short presentation or speech by any attendee on any topic relevant to the NANOG audience. These are limited to ten minutes; this will be strictly enforced. If you have a topic that's timely, interesting, or even a crackpot idea you want to share, we encourage you to consider presenting it. The Program Committee will vote on all Lightning Talk submissions onsite at the meeting, and a submitter will be notified about his or her submission one day prior to the scheduled talk time. Submit your lightning talk proposal at http://pc.nanog.org starting June 2, 2013. Research Forum: Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. The NANOG registration fee is waived for: - For General Session presentations, the registration fee will be waived for a maximum of one speaker. - For General Session panels, fees will be waived for one panel moderator and all panelists. - For Tracks, fees will be waived for one moderator. - For Research Forum presentations, fees will be waived for one speaker. - For Tutorials, fees will be waived for one instructor. * From luan20176 at gmail.com Fri Mar 1 17:40:05 2013 From: luan20176 at gmail.com (Luan Nguyen) Date: Fri, 1 Mar 2013 12:40:05 -0500 Subject: Good transit provider @Hutchison Cavendish Centre In-Reply-To: References: Message-ID: We thought about that. But now are not happy with the service. We are willing to pay for local loop. You would think that every provider should be able to provide a black hole community to their customers, but that's not the case. Lots of places don't do that. Thanks. Regards, -lmn On Thu, Feb 28, 2013 at 1:52 AM, Tom Paseka wrote: > You won't be able to get many choices there. Given its a Hutchison > building, thought about Hutchison? > > You'll need a local loop otherwise, coverage is probably not easy too and > being a hutch building, you wont get much choice. > > Other recommendations (if you forget about local loop issues), Pacnet, > Telstra/Reach, PCCW, TATA, NTT, etc. > > Every provider should be able to meet your DDOS requirements. > > > On Thu, Feb 28, 2013 at 4:42 AM, Luan Nguyen wrote: > >> Hi Folks, >> >> Any recommendation for a 1 Gig Transit provider at Hutchison Cavendish >> Centre? Has to be able to black hole DDOS attack using BGP communities. >> Preferable: Tier 1 provider with US present (IAD would be best) >> HK NSP mailing list doesn't exist anymore? >> >> Thanks. >> >> Regards, >> >> -lmn >> > > From cscora at apnic.net Fri Mar 1 18:33:03 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Mar 2013 04:33:03 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201303011833.r21IX3c0023987@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Mar, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 444878 Prefixes after maximum aggregation: 182918 Deaggregation factor: 2.43 Unique aggregates announced to Internet: 218369 Total ASes present in the Internet Routing Table: 43457 Prefixes per ASN: 10.24 Origin-only ASes present in the Internet Routing Table: 34242 Origin ASes announcing only one prefix: 15961 Transit ASes present in the Internet Routing Table: 5781 Transit-only ASes present in the Internet Routing Table: 138 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 368 Unregistered ASNs in the Routing Table: 135 Number of 32-bit ASNs allocated by the RIRs: 3798 Number of 32-bit ASNs visible in the Routing Table: 3434 Prefixes from 32-bit ASNs in the Routing Table: 9541 Special use prefixes present in the Routing Table: 17 Prefixes being announced from unallocated address space: 189 Number of addresses announced to Internet: 2619399116 Equivalent to 156 /8s, 32 /16s and 219 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.3 Total number of prefixes smaller than registry allocations: 157249 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 106846 Total APNIC prefixes after maximum aggregation: 33105 APNIC Deaggregation factor: 3.23 Prefixes being announced from the APNIC address blocks: 107946 Unique aggregates announced from the APNIC address blocks: 44071 APNIC Region origin ASes present in the Internet Routing Table: 4814 APNIC Prefixes per ASN: 22.42 APNIC Region origin ASes announcing only one prefix: 1233 APNIC Region transit ASes present in the Internet Routing Table: 816 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 444 Number of APNIC addresses announced to Internet: 719060672 Equivalent to 42 /8s, 219 /16s and 254 /24s Percentage of available APNIC address space announced: 84.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 156262 Total ARIN prefixes after maximum aggregation: 79028 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156968 Unique aggregates announced from the ARIN address blocks: 71372 ARIN Region origin ASes present in the Internet Routing Table: 15506 ARIN Prefixes per ASN: 10.12 ARIN Region origin ASes announcing only one prefix: 5863 ARIN Region transit ASes present in the Internet Routing Table: 1616 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1076685952 Equivalent to 64 /8s, 44 /16s and 236 /24s Percentage of available ARIN address space announced: 57.0 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 114097 Total RIPE prefixes after maximum aggregation: 59042 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 117377 Unique aggregates announced from the RIPE address blocks: 75202 RIPE Region origin ASes present in the Internet Routing Table: 17091 RIPE Prefixes per ASN: 6.87 RIPE Region origin ASes announcing only one prefix: 8148 RIPE Region transit ASes present in the Internet Routing Table: 2779 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2221 Number of RIPE addresses announced to Internet: 653859172 Equivalent to 38 /8s, 249 /16s and 25 /24s Percentage of available RIPE address space announced: 95.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47375 Total LACNIC prefixes after maximum aggregation: 9238 LACNIC Deaggregation factor: 5.13 Prefixes being announced from the LACNIC address blocks: 51180 Unique aggregates announced from the LACNIC address blocks: 23762 LACNIC Region origin ASes present in the Internet Routing Table: 1843 LACNIC Prefixes per ASN: 27.77 LACNIC Region origin ASes announcing only one prefix: 537 LACNIC Region transit ASes present in the Internet Routing Table: 349 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 744 Number of LACNIC addresses announced to Internet: 124216104 Equivalent to 7 /8s, 103 /16s and 99 /24s Percentage of available LACNIC address space announced: 74.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10628 Total AfriNIC prefixes after maximum aggregation: 2454 AfriNIC Deaggregation factor: 4.33 Prefixes being announced from the AfriNIC address blocks: 11218 Unique aggregates announced from the AfriNIC address blocks: 3792 AfriNIC Region origin ASes present in the Internet Routing Table: 601 AfriNIC Prefixes per ASN: 18.67 AfriNIC Region origin ASes announcing only one prefix: 180 AfriNIC Region transit ASes present in the Internet Routing Table: 128 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 45241088 Equivalent to 2 /8s, 178 /16s and 83 /24s Percentage of available AfriNIC address space announced: 44.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2930 11558 923 Korea Telecom (KIX) 17974 2500 840 86 PT TELEKOMUNIKASI INDONESIA 7545 1828 301 89 TPG Internet Pty Ltd 4755 1696 382 190 TATA Communications formerly 9829 1426 1140 43 BSNL National Internet Backbo 9583 1215 91 502 Sify Limited 7552 1161 1070 12 Vietel Corporation 4808 1117 2058 322 CNCGROUP IP network: China169 9498 1066 310 75 BHARTI Airtel Ltd. 24560 1047 385 161 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3051 3695 96 bellsouth.net, inc. 7029 2148 1265 210 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1986 2929 124 Cox Communications, Inc. 1785 1957 677 123 PaeTec Communications, Inc. 20115 1695 1611 620 Charter Communications 4323 1611 1140 401 Time Warner Telecom 30036 1343 288 682 Mediacom Communications Corp 7018 1302 10553 854 AT&T WorldNet Services 11492 1208 221 335 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1858 544 16 Corbina telecom 2118 1116 97 13 EUnet/RELCOM Autonomous Syste 34984 1065 232 204 BILISIM TELEKOM 13188 841 99 22 Educational Network 12479 831 783 68 Uni2 Autonomous System 31148 766 39 17 FreeNet ISP 20940 759 257 602 Akamai Technologies European 8551 715 370 43 Bezeq International 6830 713 2313 434 UPC Distribution Services 34744 675 186 28 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2387 1330 84 NET Servicos de Comunicao S.A 10620 2340 402 232 TVCABLE BOGOTA 7303 1681 1147 207 Telecom Argentina Stet-France 6503 1393 435 68 AVANTEL, S.A. 8151 1376 2805 407 UniNet S.A. de C.V. 14754 940 127 75 Telgua S. A. 18881 799 716 18 Global Village Telecom 27947 785 86 101 Telconet S.A 3816 688 306 85 Empresa Nacional de Telecomun 7738 650 1306 35 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 865 274 34 LINKdotNET AS number 6713 535 615 23 Itissalat Al-MAGHRIB 8452 530 958 13 TEDATA 24835 342 80 8 RAYA Telecom - Egypt 3741 262 906 220 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 186 696 90 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3051 3695 96 bellsouth.net, inc. 4766 2930 11558 923 Korea Telecom (KIX) 17974 2500 840 86 PT TELEKOMUNIKASI INDONESIA 28573 2387 1330 84 NET Servicos de Comunicao S.A 10620 2340 402 232 TVCABLE BOGOTA 7029 2148 1265 210 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1986 2929 124 Cox Communications, Inc. 1785 1957 677 123 PaeTec Communications, Inc. 8402 1858 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2500 2414 PT TELEKOMUNIKASI INDONESIA 28573 2387 2303 NET Servicos de Comunicao S.A 10620 2340 2108 TVCABLE BOGOTA 4766 2930 2007 Korea Telecom (KIX) 7029 2148 1938 Windstream Communications Inc 18566 2080 1895 Covad Communications 22773 1986 1862 Cox Communications, Inc. 8402 1858 1842 Corbina telecom 1785 1957 1834 PaeTec Communications, Inc. 7545 1828 1739 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65119 PRIVATE 8.36.67.0/24 6352 E*Trade Group 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.60.0/23 57417 INTERNET TASMANIA SRL 128.0.62.0/23 57417 INTERNET TASMANIA SRL 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:13 /10:29 /11:88 /12:247 /13:483 /14:869 /15:1564 /16:12632 /17:6623 /18:10909 /19:21729 /20:31372 /21:33459 /22:45969 /23:41343 /24:233225 /25:1387 /26:1765 /27:859 /28:183 /29:75 /30:17 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2030 2080 Covad Communications 6389 1752 3051 bellsouth.net, inc. 8402 1587 1858 Corbina telecom 7029 1555 2148 Windstream Communications Inc 22773 1302 1986 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1230 1343 Mediacom Communications Corp 11492 1170 1208 Cable One 1785 1038 1957 PaeTec Communications, Inc. 7011 956 1205 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:716 2:778 3:3 4:13 5:764 6:3 8:504 12:1932 13:3 14:746 15:11 16:3 17:8 20:24 23:241 24:1799 27:1455 31:1141 32:54 33:2 34:5 36:11 37:1306 38:857 39:2 40:153 41:2708 42:177 44:3 46:1767 47:1 49:609 50:663 52:12 54:28 55:10 57:28 58:1079 59:559 60:278 61:1339 62:1036 63:2033 64:4306 65:2168 66:4248 67:2050 68:1126 69:3263 70:861 71:525 72:1902 74:2548 75:413 76:295 77:1089 78:1051 79:572 80:1241 81:974 82:608 83:549 84:560 85:1160 86:478 87:945 88:371 89:1749 90:262 91:5421 92:603 93:1743 94:2088 95:1569 96:499 97:335 98:1035 99:40 100:30 101:308 103:2226 105:517 106:131 107:207 108:511 109:1796 110:851 111:1030 112:492 113:741 114:683 115:921 116:881 117:798 118:981 119:1275 120:376 121:705 122:1740 123:1190 124:1317 125:1315 128:536 129:205 130:318 131:639 132:329 133:143 134:253 135:62 136:221 137:234 138:342 139:168 140:213 141:316 142:523 143:376 144:481 145:88 146:519 147:349 148:712 149:353 150:152 151:409 152:401 153:191 154:29 155:374 156:243 157:391 158:260 159:711 160:336 161:420 162:369 163:208 164:578 165:447 166:416 167:572 168:1008 169:130 170:1025 171:165 172:4 173:1577 174:580 175:424 176:1127 177:1707 178:1743 179:1 180:1370 181:256 182:1192 183:331 184:645 185:266 186:2316 187:1309 188:1924 189:1534 190:6616 192:6373 193:5658 194:4500 195:3492 196:1311 197:925 198:4166 199:5234 200:6064 201:2223 202:8926 203:8755 204:4498 205:2556 206:2790 207:2787 208:4068 209:3523 210:2898 211:1563 212:1977 213:1923 214:906 215:95 216:5212 217:1582 218:606 219:327 220:1266 221:549 222:332 223:470 End of report From cidr-report at potaroo.net Fri Mar 1 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Mar 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201303012200.r21M00pS058841@wattle.apnic.net> This report has been generated at Tue Feb 19 16:13:14 2013 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 12-02-13 445341 254468 13-02-13 444932 254971 14-02-13 445625 254890 15-02-13 445440 255148 16-02-13 445491 255598 17-02-13 445709 255627 18-02-13 445529 256541 19-02-13 445862 256692 AS Summary 43455 Number of ASes in routing system 18036 Number of ASes announcing only one prefix 3063 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116912864 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'). --- 19Feb13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 445961 256729 189232 42.4% All ASes AS6389 3063 104 2959 96.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2387 88 2299 96.3% NET Servicos de Comunicao S.A. AS17974 2486 474 2012 80.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2938 942 1996 67.9% KIXS-AS-KR Korea Telecom AS18566 2080 427 1653 79.5% COVAD - Covad Communications Co. AS10620 2319 670 1649 71.1% Telmex Colombia S.A. AS7303 1681 408 1273 75.7% Telecom Argentina S.A. AS4323 1606 401 1205 75.0% TWTC - tw telecom holdings, inc. AS4755 1688 579 1109 65.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1115 83 1032 92.6% RELCOM-AS OOO "NPO Relcom" AS7552 1161 180 981 84.5% VIETEL-AS-AP Vietel Corporation AS7029 2166 1198 968 44.7% WINDSTREAM - Windstream Communications Inc AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1008 170 838 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS22773 1989 1162 827 41.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7545 1834 1019 815 44.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS1785 1959 1169 790 40.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1513 745 768 50.8% Uninet S.A. de C.V. AS4808 1114 355 759 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18881 773 26 747 96.6% Global Village Telecom AS14754 942 207 735 78.0% Telgua AS13977 838 123 715 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 737 51 686 93.1% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 715 50 665 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS24560 1045 416 629 60.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22561 1067 445 622 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 720 99 621 86.2% GIGAINFRA Softbank BB Corp. AS3356 1103 498 605 54.9% LEVEL3 Level 3 Communications AS3549 1046 444 602 57.6% GBLX Global Crossing Ltd. AS19262 998 404 594 59.5% VZGNI-TRANSIT - Verizon Online LLC Total 45377 13318 32059 70.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.5.152.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC. 103.11.148.0/24 AS58452 103.11.149.0/24 AS58452 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.19.20.0/22 AS42610 NCNET-AS National Cable Networks 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 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.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. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 1 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Mar 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201303012200.r21M012p058871@wattle.apnic.net> BGP Update Report Interval: 11-Feb-13 -to- 18-Feb-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 111602 4.7% 107.9 -- BBIL-AP BHARTI Airtel Ltd. 2 - AS24560 91379 3.8% 88.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - AS8402 49667 2.1% 27.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS18207 45646 1.9% 131.9 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. 5 - AS3909 42966 1.8% 1227.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS7029 36157 1.5% 18.3 -- WINDSTREAM - Windstream Communications Inc 7 - AS8151 30815 1.3% 23.8 -- Uninet S.A. de C.V. 8 - AS9829 28968 1.2% 34.8 -- BSNL-NIB National Internet Backbone 9 - AS45609 27674 1.2% 105.6 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 10 - AS18002 24115 1.0% 114.8 -- WORLDPHONE-IN AS Number for Interdomain Routing 11 - AS32777 23335 1.0% 4667.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 12 - AS36998 21970 0.9% 18.1 -- SDN-MOBITEL 13 - AS2708 21659 0.9% 154.7 -- Universidad de Guanajuato 14 - AS45514 21014 0.9% 69.1 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 15 - AS4 19416 0.8% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 16 - AS45528 17023 0.7% 45.2 -- TDN Tikona Digital Networks Pvt Ltd. 17 - AS17974 16207 0.7% 7.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS31148 15822 0.7% 20.6 -- FREENET-AS Freenet Ltd. 19 - AS17488 14556 0.6% 45.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS57816 11755 0.5% 2938.8 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32777 23335 1.0% 4667.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 2 - AS19406 4126 0.2% 4126.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS40946 6077 0.2% 3038.5 -- PROCON - Sat Track 4 - AS6174 5879 0.2% 2939.5 -- SPRINTLINK8 - Sprint 5 - AS57816 11755 0.5% 2938.8 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 6 - AS14680 5943 0.2% 1981.0 -- REALE-6 - Auction.com 7 - AS36529 2746 0.1% 1373.0 -- AXXA-RACKCO - Rackco.com 8 - AS8657 1323 0.1% 1323.0 -- CPRM CPRM Autonomous System 9 - AS17293 3920 0.2% 1306.7 -- VTXC - VTX Communications 10 - AS3909 42966 1.8% 1227.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 11 - AS22140 5832 0.2% 972.0 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 12 - AS4 19416 0.8% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 13 - AS40931 1660 0.1% 830.0 -- MOBITV - MobiTV, Inc 14 - AS12397 807 0.0% 807.0 -- OPTOCOM Optocom Ltd 15 - AS9950 4666 0.2% 777.7 -- PUBNETPLUS2-AS-KR DACOM 16 - AS37367 709 0.0% 709.0 -- CALLKEY 17 - AS57201 696 0.0% 696.0 -- EDF-AS Estonian Defence Forces 18 - AS4663 2758 0.1% 689.5 -- ELIMNET-AS ELIMNET, INC 19 - AS12413 686 0.0% 686.0 -- HANSHAKE-AS Handshake e.V. 20 - AS6197 686 0.0% 686.0 -- BATI-ATL - BellSouth Network Solutions, Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.255.0/24 14290 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 14290 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 14259 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 37.9.248.0/21 11701 0.5% AS57816 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 5 - 202.41.70.0/24 9362 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 6 - 196.1.167.0/24 8133 0.3% AS11139 -- CWRIN CW BARBADOS 7 - 66.55.234.0/24 7838 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc 8 - 192.58.232.0/24 7645 0.3% AS6629 -- NOAA-AS - NOAA 9 - 208.92.131.0/24 6076 0.2% AS40946 -- PROCON - Sat Track 10 - 208.14.186.0/24 5803 0.2% AS22140 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 11 - 12.139.133.0/24 4793 0.2% AS14680 -- REALE-6 - Auction.com 12 - 194.63.9.0/24 4706 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 8.12.92.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 14 - 66.78.242.0/23 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 15 - 67.110.75.0/24 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 16 - 65.172.212.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 17 - 97.65.228.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 18 - 58.184.229.0/24 4652 0.2% AS9950 -- PUBNETPLUS2-AS-KR DACOM 19 - 69.38.178.0/24 4126 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 20 - 122.161.0.0/16 4028 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From wingcomm at hotmail.com Sat Mar 2 09:17:04 2013 From: wingcomm at hotmail.com (R W) Date: Sat, 2 Mar 2013 04:17:04 -0500 Subject: Comcast NOC Contact Message-ID: Could someone from Comcast's NOC contact me off-list? We're seeing some traffic take a strange route on its way back to some Comcast prefixes from several of our systems. Thank you! -Rob From mureninc at gmail.com Sat Mar 2 21:58:09 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 2 Mar 2013 13:58:09 -0800 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? Message-ID: Dear NANOG@, I've had a Linode in Fremont, CA (within 173.230.144.0/20 and 2600:3c01::/32) for over a year, and, in addition to some development, I sometimes use it as an ssh-based personal SOCKS-proxy when travelling and having to use any kind of public WiFi. Since doing so, I have noticed that most geolocation services think that I'm located in NJ (the state of the corporate headquarters of Linode), instead of Northern California (where my Linode is physically from, and, coincidentally or not, where I also happen to live, hence renting a Linode from a very specific location). Additionally, it seems like both yelp.com and retailmenot.com block the whole 173.230.144.0/20 from their web-sites, returning some graphical "403 Forbidden" pages instead. ... I would like to point out that 173.230.144.0/20 and 2600:3c01::/32, announced out of AS6939, are allocated by Linode from their own ARIN-assigned allocations, 173.230.128.0/19 and 2600:3C00::/30, which Linode, in turn with their other ARIN-assigned space, allocates to 4 of their distinct DCs in the US, in Dallas, Fremont, Atlanta and Newark. However, Linode does not maintain any individual whois records of which DC they announce a given sub-allocation from. They also do not document their IPv6 assignments, either: if one of their customers misbehaves, the offended network would have no clue how to block just one customer, so, potentially, a whole set of customers may end up being blocked, through a wrong prefixlen assumption. I've tried contacting Linode in regards to whois, giving an example of some other smaller providers (e.g. vr.org) that label their own sub-allocations within their ARIN-assigned space to contain an address of the DC where the subnet is coming from, and asked whether Linode could do the same; however, Linode informed me that they don't have any kind of mail service from the DCs they're at, and that their ARIN contact, effectively, said that they're already doing everything right in regards not having any extra whois entries with the addresses of their DC, since that would actually be wrong, as noone will be expecting mail for Linode at those addresses. (In turn, it's unclear whether a much smaller vr.org has mail service at nearly a dozen of the DCs that they have their servers at, and which they provide as the addresses in ARIN's whois, but I would guess that they do not.) This would seem like a possible shortcoming of ARIN's policies and the whois database: with RIPE, every `netname` has a `country` associated with it, seemingly without any requirements of a mailing address where mail could be received; but with ARIN, no state is ever provided, only a mailing address. (I've also just noticed that RIPE whois now has an optional `geoloc` field in addition to the non-optional `country`.) Now, back to ARIN: is Linode doing it right? Is vr.org doing it wrong? Are they both doing it correct, or are they both wrong? And in regards to yelp and retailmenot; why are they blocking Linode customers in 173.230.144.0/20? I've tried contacting both on multiple occasions, and have never received any replies from yelp, but retailmenot has replied several times with a blanket "someone may have tried to scrap, spam or proxy our site from this network". I have repeatedly asked retailmenot if they'd block Verizon or AT&T if someone tries to scrap or spam their web-site from those networks, too, but have never received any replies. I have also tried contacting Linode regarding this issue, and although they were very patient and tried troubleshooting the problem, reporting that it appears that other addresses within 173.230.144.0/20 are likewise blocked, but some of their other address ranges at another DC are not, they have not been able to get in touch with anyone at yelp or retailmenot to isolate the problem. Now, if you were operating yelp or rmn, would you not block an address range with a fishy geoloc like that of Linode? I'm somewhat convinced that 403 Forbidden stems entirely out of some logic that notes that the geoloc data is likely fishy, or which [erroneously] concludes that the address range is used for anonymity purposes. Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp stop returning 403 Forbidden? Cheers, Constantine. From owen at delong.com Sat Mar 2 23:45:53 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Mar 2013 15:45:53 -0800 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: <8DC103E7-AA2A-44F0-B2A3-9C98DF119E2F@delong.com> > Now, back to ARIN: is Linode doing it right? Is vr.org doing it > wrong? Are they both doing it correct, or are they both wrong? > ARIN Policies do require Linode to SWIP their customer allocations, so the fact that they are not doing so is actually a violation of policy. Linode (and VR) probably shouldn't SWIP their datacenter blocks, but this isn't really covered in policy one way or the other. > Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp > stop returning 403 Forbidden? Get Linode to SWIP your blocks for starters. Owen From mureninc at gmail.com Sun Mar 3 00:21:18 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 2 Mar 2013 16:21:18 -0800 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: <8DC103E7-AA2A-44F0-B2A3-9C98DF119E2F@delong.com> References: <8DC103E7-AA2A-44F0-B2A3-9C98DF119E2F@delong.com> Message-ID: On 2 March 2013 15:45, Owen DeLong wrote: >> Now, back to ARIN: is Linode doing it right? Is vr.org doing it >> wrong? Are they both doing it correct, or are they both wrong? >> > > ARIN Policies do require Linode to SWIP their customer allocations, > so the fact that they are not doing so is actually a violation of policy. They have repeatedly disagreed, on two separate occasions, effectively claiming they themselves are the customers: >>>> We now get all of our addresses assigned directly to us which is why our address is listed, however we still have some IP addresses in our pool with ... So, the "new" addresses are all assigned directly to them. > > Linode (and VR) probably shouldn't SWIP their datacenter blocks, > but this isn't really covered in policy one way or the other. > >> Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp >> stop returning 403 Forbidden? > > Get Linode to SWIP your blocks for starters. Could work with IPv6, since I have a /56 from them, but I only have a single IPv4, so, per my understanding, an IPv4 SWIP is not possible. C. From mike at mikejones.in Sun Mar 3 00:24:07 2013 From: mike at mikejones.in (Mike Jones) Date: Sun, 3 Mar 2013 00:24:07 +0000 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: Inline Reply On 2 March 2013 21:58, Constantine A. Murenin wrote: > Dear NANOG@, > > I've had a Linode in Fremont, CA (within 173.230.144.0/20 and > 2600:3c01::/32) for over a year, and, in addition to some development, > I sometimes use it as an ssh-based personal SOCKS-proxy when > travelling and having to use any kind of public WiFi. > > Since doing so, I have noticed that most geolocation services think > that I'm located in NJ (the state of the corporate headquarters of > Linode), instead of Northern California (where my Linode is physically > from, and, coincidentally or not, where I also happen to live, hence > renting a Linode from a very specific location). > > Additionally, it seems like both yelp.com and retailmenot.com block > the whole 173.230.144.0/20 from their web-sites, returning some > graphical "403 Forbidden" pages instead. > > ... > > I would like to point out that 173.230.144.0/20 and 2600:3c01::/32, > announced out of AS6939, are allocated by Linode from their own > ARIN-assigned allocations, 173.230.128.0/19 and 2600:3C00::/30, which > Linode, in turn with their other ARIN-assigned space, allocates to 4 > of their distinct DCs in the US, in Dallas, Fremont, Atlanta and > Newark. > > However, Linode does not maintain any individual whois records of > which DC they announce a given sub-allocation from. They also do not > document their IPv6 assignments, either: if one of their customers > misbehaves, the offended network would have no clue how to block just > one customer, so, potentially, a whole set of customers may end up > being blocked, through a wrong prefixlen assumption. > > > I've tried contacting Linode in regards to whois, giving an example of > some other smaller providers (e.g. vr.org) that label their own > sub-allocations within their ARIN-assigned space to contain an address > of the DC where the subnet is coming from, and asked whether Linode > could do the same; however, Linode informed me that they don't have > any kind of mail service from the DCs they're at, and that their ARIN > contact, effectively, said that they're already doing everything right > in regards not having any extra whois entries with the addresses of > their DC, since that would actually be wrong, as noone will be > expecting mail for Linode at those addresses. (In turn, it's unclear > whether a much smaller vr.org has mail service at nearly a dozen of > the DCs that they have their servers at, and which they provide as the > addresses in ARIN's whois, but I would guess that they do not.) > > This would seem like a possible shortcoming of ARIN's policies and the > whois database: with RIPE, every `netname` has a `country` associated > with it, seemingly without any requirements of a mailing address where > mail could be received; but with ARIN, no state is ever provided, only > a mailing address. (I've also just noticed that RIPE whois now has an > optional `geoloc` field in addition to the non-optional `country`.) > > Now, back to ARIN: is Linode doing it right? Is vr.org doing it > wrong? Are they both doing it correct, or are they both wrong? You need to give me what you need to give me, but if you give me more am I going to complain? What about if you miss something? > > And in regards to yelp and retailmenot; why are they blocking Linode > customers in 173.230.144.0/20? I've tried contacting both on multiple Could be many reasons, I suspect they get little legitimate traffic from there with their target audiences. > occasions, and have never received any replies from yelp, but > retailmenot has replied several times with a blanket "someone may have > tried to scrap, spam or proxy our site from this network". I have Probably likely, many geo-restricted sites also block hosting providers. > repeatedly asked retailmenot if they'd block Verizon or AT&T if > someone tries to scrap or spam their web-site from those networks, > too, but have never received any replies. I have also tried Residential provider: Block millions of users to stop a few scrapers. Hosting provider: Block a couple of users to block 90% of the scrapers, and all the places the scrapers go to when you block them. > contacting Linode regarding this issue, and although they were very > patient and tried troubleshooting the problem, reporting that it > appears that other addresses within 173.230.144.0/20 are likewise > blocked, but some of their other address ranges at another DC are not, > they have not been able to get in touch with anyone at yelp or > retailmenot to isolate the problem. > > > Now, if you were operating yelp or rmn, would you not block an address > range with a fishy geoloc like that of Linode? I'm somewhat convinced > that 403 Forbidden stems entirely out of some logic that notes that > the geoloc data is likely fishy, or which [erroneously] concludes that > the address range is used for anonymity purposes. Have you done a lot of 'looking up IP addresses'? Browse around some of the whois records from hosting providers, and see if you can figure out how much to block. IPv6 makes this even more fun, a /64 shared between customers or a /48 per server? have to read their site, traceroute, etc... > > > Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp > stop returning 403 Forbidden? SWIP? see owen.. If you can't get anyone who can change things to 'fix' it for you - Change provider*? - Mike *I'm sure if you 'can't find a suitable one' you'll get off list replies ;) From bill at herrin.us Sun Mar 3 01:22:51 2013 From: bill at herrin.us (William Herrin) Date: Sat, 2 Mar 2013 20:22:51 -0500 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: On Sat, Mar 2, 2013 at 4:58 PM, Constantine A. Murenin wrote: > I've had a Linode in Fremont, CA (within 173.230.144.0/20 and > 2600:3c01::/32) for over a year, and, in addition to some development, > I sometimes use it as an ssh-based personal SOCKS-proxy when > travelling and having to use any kind of public WiFi. > > Since doing so, I have noticed that most geolocation services think > that I'm located in NJ (the state of the corporate headquarters of > Linode), instead of Northern California (where my Linode is physically > from, and, coincidentally or not, where I also happen to live, hence > renting a Linode from a very specific location). If you care about geolocation of your IP addresses, submit that information to the geolocation services. For the $20/month you're paying Linode (or do you have the expensive account?), why would they care about geolocation? > Additionally, it seems like both yelp.com and retailmenot.com block > the whole 173.230.144.0/20 from their web-sites, returning some > graphical "403 Forbidden" pages instead. At a glance, I'd bet this has more to do with Linode being a VPS provider (not an eyeball network) than anything else. Despite everything VPS service providers do to prevent it, they do get abused by folks attempting every sort of fraud imaginable. As they're not an eyeball network, the fraud to not-fraud ratio of eyeball activities is not ideal. > This would seem like a possible shortcoming of ARIN's policies and the > whois database: with RIPE, every `netname` has a `country` associated > with it, seemingly without any requirements of a mailing address where > mail could be received; but with ARIN, no state is ever provided, only > a mailing address. (I've also just noticed that RIPE whois now has an > optional `geoloc` field in addition to the non-optional `country`.) > > Now, back to ARIN: is Linode doing it right? Is vr.org doing it > wrong? Are they both doing it correct, or are they both wrong? They are both correct. ARIN allows address holders to SWIP down to whatever level they want, but only requires them to SWIP assignments of /29 or more addresses. Some service providers prefer that abuse be immediately the subscriber's problem, so they put the info in the whois system. Others come down on the side of keeping their customer database out of the hands of competitors, so they publish the minimum required information. In both cases, the smaller the account the less willing they are to deviate from the corporate standard. > Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp > stop returning 403 Forbidden? Contact customer support. Tell them you're blocked. Ask them not to block you. Same as you would for any encounter where the service provider has blocked your source address. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scott at doc.net.au Sun Mar 3 08:03:55 2013 From: scott at doc.net.au (Scott Howard) Date: Sun, 3 Mar 2013 10:03:55 +0200 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: On Sat, Mar 2, 2013 at 11:58 PM, Constantine A. Murenin wrote: > Additionally, it seems like both yelp.com and retailmenot.com block > the whole 173.230.144.0/20 from their web-sites, returning some > graphical "403 Forbidden" pages instead. > Although I have knowledge of either of those sites, I'd put money on the fact they they simply got sick of the repeated site scraping or similar activity from Linode and blocked the entire range. I've spoken to many other sites that have done exactly this, with a fairly clear inverse relation between the cost of the hosting provider and the likelihood of such behavioral (with Linode and Hetzner pretty much being at the top of that list) Scott. From owen at delong.com Sun Mar 3 09:35:20 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Mar 2013 01:35:20 -0800 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: <8DC103E7-AA2A-44F0-B2A3-9C98DF119E2F@delong.com> Message-ID: On Mar 2, 2013, at 16:21 , "Constantine A. Murenin" wrote: > On 2 March 2013 15:45, Owen DeLong wrote: >>> Now, back to ARIN: is Linode doing it right? Is vr.org doing it >>> wrong? Are they both doing it correct, or are they both wrong? >>> >> >> ARIN Policies do require Linode to SWIP their customer allocations, >> so the fact that they are not doing so is actually a violation of policy. > > > They have repeatedly disagreed, on two separate occasions, effectively > claiming they themselves are the customers: > >>>>> We now get all of our addresses assigned directly to us which is why our address is listed, however we still have some IP addresses in our pool with ... > > So, the "new" addresses are all assigned directly to them. > Not really... The relevant section of the NRPM is 6.5.4 et. seq. They are, for all practical purposes, acting as an LIR. They receive space from ARIN and then assign it to their customers (such as you). According to 6.5.5.1, if they are assigning you a /64 or more, they must register that with ARIN through SWIP or RWHOIS. If you are getting less than a /64, then, yes, you are out of luck. >> Linode (and VR) probably shouldn't SWIP their datacenter blocks, >> but this isn't really covered in policy one way or the other. >> >>> Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp >>> stop returning 403 Forbidden? >> >> Get Linode to SWIP your blocks for starters. > > Could work with IPv6, since I have a /56 from them, but I only have a > single IPv4, so, per my understanding, an IPv4 SWIP is not possible. Correct... For IPv4, you're kind of hosed. Geolocation of IP addresses has always been an ill-conceived quagmire. This is not news. However, in terms of getting the best you can out of a bad situation, the advice above is about as good as it gets. Owen From vinod408 at hotmail.com Sat Mar 2 18:07:16 2013 From: vinod408 at hotmail.com (Vinod K) Date: Sat, 2 Mar 2013 18:07:16 +0000 Subject: Comcast NOC Contact In-Reply-To: References: Message-ID: Rob: Comcast engineers are on the NANOG list. If you reply with IP and traceroute they can help u. I hear there are networks at capacity b/c of ratios. Everybody wants to send Comcast traffic, but noone wants to send money. V > From: wingcomm at hotmail.com > To: nanog at nanog.org > Subject: Comcast NOC Contact > Date: Sat, 2 Mar 2013 04:17:04 -0500 > > Could someone from Comcast's NOC contact me off-list? We're seeing some traffic take a strange route on its way back to some Comcast prefixes from several of our systems. Thank you! > -Rob From rsk at gsp.org Sun Mar 3 12:25:55 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 3 Mar 2013 07:25:55 -0500 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: <20130303122555.GA19091@gsp.org> I'll leave the rest of your comments/questions to others, but on this: On Sat, Mar 02, 2013 at 01:58:09PM -0800, Constantine A. Murenin wrote: > And in regards to yelp and retailmenot; why are they blocking Linode > customers in 173.230.144.0/20? I've tried contacting both on multiple > occasions, and have never received any replies from yelp, but > retailmenot has replied several times with a blanket "someone may have > tried to scrap, spam or proxy our site from this network". Only yelp and retailmenot can answer that question precisely, but: I've seen MANY instances of Linode-originated spam. Attempts to get Linode to exercise a modicum of professionalism and make it stop on their side have not been successful, therefore I've taken steps to make it stop on my side. If it continues and escalates (both of which seem very likely) then eventually I'll upgrade those steps to "firewall rules". So I suggest that your complaints about yelp and retailmenot blocking you should be directed not to them, but to Linode: you should ask Linode why they made it *necessary* for yelp and retailmenot to defend themselves in that fashion. You should ask them what remedial action they're currently taken to no longer make it necessary. And you should ask them when they will be contacting yelp/retailmenot in order to (a) apologize and (b) request their access privileges back. ---rsk From nick at foobar.org Sun Mar 3 12:40:52 2013 From: nick at foobar.org (Nick Hilliard) Date: Sun, 03 Mar 2013 12:40:52 +0000 Subject: Comcast NOC Contact In-Reply-To: References: Message-ID: <513344D4.20509@foobar.org> On 02/03/2013 18:07, Vinod K wrote: > I hear there are networks at capacity b/c of ratios. Everybody wants to > send Comcast traffic, but noone wants to send money. The flip side of this argument is that as it's mostly an access network with an asymmetric last mile infrastructure, the natural aggregate internet traffic profile of the total sum (bytes-in, bytes-out) counted at the customer hand-off points will tend to be weighted in one direction. For providers who have an overall asymmetric traffic profile towards Comcast, it's a matter of perspective as to whether you view this as the providers sending Comcast traffic or Comcast customers pulling it. So it's hardly surprising that there are disagreements about who gets to pay the other for the interconnection arrangements. Nick From faisal at snappydsl.net Sun Mar 3 14:18:43 2013 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 3 Mar 2013 09:18:43 -0500 Subject: Comcast NOC Contact In-Reply-To: <513344D4.20509@foobar.org> References: <513344D4.20509@foobar.org> Message-ID: <38C548ED-5840-4A28-8F6D-C97EE3A8A689@snappydsl.net> And the sad surprising part of all this is that they don't do public peering, which would go long ways to reduce pressures on their network... Nor do the wish to sell transit to their network at a reasonable rate .. What a shame! Faisal On Mar 3, 2013, at 7:40 AM, Nick Hilliard wrote: > On 02/03/2013 18:07, Vinod K wrote: >> I hear there are networks at capacity b/c of ratios. Everybody wants to >> send Comcast traffic, but noone wants to send money. > > The flip side of this argument is that as it's mostly an access network > with an asymmetric last mile infrastructure, the natural aggregate internet > traffic profile of the total sum (bytes-in, bytes-out) counted at the > customer hand-off points will tend to be weighted in one direction. > > For providers who have an overall asymmetric traffic profile towards > Comcast, it's a matter of perspective as to whether you view this as the > providers sending Comcast traffic or Comcast customers pulling it. So it's > hardly surprising that there are disagreements about who gets to pay the > other for the interconnection arrangements. > > Nick > > > From jra at baylink.com Sun Mar 3 16:03:10 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Mar 2013 11:03:10 -0500 (EST) Subject: Comcast NOC Contact In-Reply-To: <38C548ED-5840-4A28-8F6D-C97EE3A8A689@snappydsl.net> Message-ID: <6212992.8198.1362326590992.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > On Mar 3, 2013, at 7:40 AM, Nick Hilliard wrote: > > For providers who have an overall asymmetric traffic profile towards > > Comcast, it's a matter of perspective as to whether you view this as > > the providers sending Comcast traffic or Comcast customers pulling it. > > So it's hardly surprising that there are disagreements about who gets to pay > > the other for the interconnection arrangements. Saying that it's a matter of perspective is a false dichotomy. If the providers go away, the Comcast customers will pull traffic from other providers. If the *customers* go away... Nope; Comcast is acting as the agent of its customers to pull in traffic they want to see, and if it isn't charging them enough for that, that is *Comcast's* problem. It's really a bright-line answer. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From Valdis.Kletnieks at vt.edu Sun Mar 3 16:44:26 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 03 Mar 2013 11:44:26 -0500 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: Your message of "Sun, 03 Mar 2013 00:24:07 +0000." References: Message-ID: <215377.1362329066@turing-police.cc.vt.edu> On Sun, 03 Mar 2013 00:24:07 +0000, Mike Jones said: > Inline Reply > > On 2 March 2013 21:58, Constantine A. Murenin wrote: > > Dear NANOG@, Have we *really* sunk so low that inline replies need to be flagged as such, because people *expect* top-posting and if they don't see it they assume it's a MUA misfire rather than an inline reply? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From dave.nanog at alfordmedia.com Sun Mar 3 17:08:07 2013 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Sun, 03 Mar 2013 11:08:07 -0600 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: <215377.1362329066@turing-police.cc.vt.edu> Message-ID: >Have we *really* sunk so low that inline replies need to be flagged as >such, because people *expect* top-posting and if they don't see it they >assume it's a MUA misfire rather than an inline reply? SATSQ: Any time the question is "have we *really* sunk so low?" the answer is yes. -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com From asr at latency.net Sun Mar 3 18:31:48 2013 From: asr at latency.net (Adam Rothschild) Date: Sun, 3 Mar 2013 13:31:48 -0500 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: Constantine, I'm afraid you might be confusing the NANOG list with support at linode.com (which, incidentally, I've found to be good at providing timely assistance, more often than not). In any event, I've found that commercial GeoIP services rely on data from RIRs and the global routing table a bit less than you'd expect. I'm not finding any supporting documentation right now, however I remember reading in their FAQ that harvested website user registration data was MaxMind's primary source, which makes life particularly fun when you're a hosting shop with no real "eyeball" customers to speak of. Add to the list of challenges being allocated an aggregate block from ARIN/RIRs, and the advertising regionalized de-aggregates out of various datacenters -- itself a relatively common, and sometimes technically beneficial, practice -- as appears to be happening here with Linode. If accuracy matters, I'd suggest that you and/or your provider start by working individually with MaxMind, Quova (now Neustar?), Google (who purportedly uses Quova, but sometimes needs a kick to refresh things), and Akamai. It would be interesting to see a table of which large websites get their data from which geolocation provider(s), but this should give you a good start. Hope this helps, -a On Sat, Mar 2, 2013 at 4:58 PM, Constantine A. Murenin wrote: > Dear NANOG@, > > I've had a Linode in Fremont, CA (within 173.230.144.0/20 and > 2600:3c01::/32) for over a year, and, in addition to some development, > I sometimes use it as an ssh-based personal SOCKS-proxy when > travelling and having to use any kind of public WiFi. > > Since doing so, I have noticed that most geolocation services think > that I'm located in NJ (the state of the corporate headquarters of > Linode), instead of Northern California (where my Linode is physically > from, and, coincidentally or not, where I also happen to live, hence > renting a Linode from a very specific location). > > Additionally, it seems like both yelp.com and retailmenot.com block > the whole 173.230.144.0/20 from their web-sites, returning some > graphical "403 Forbidden" pages instead. > > ... > > I would like to point out that 173.230.144.0/20 and 2600:3c01::/32, > announced out of AS6939, are allocated by Linode from their own > ARIN-assigned allocations, 173.230.128.0/19 and 2600:3C00::/30, which > Linode, in turn with their other ARIN-assigned space, allocates to 4 > of their distinct DCs in the US, in Dallas, Fremont, Atlanta and > Newark. > > However, Linode does not maintain any individual whois records of > which DC they announce a given sub-allocation from. They also do not > document their IPv6 assignments, either: if one of their customers > misbehaves, the offended network would have no clue how to block just > one customer, so, potentially, a whole set of customers may end up > being blocked, through a wrong prefixlen assumption. > > > I've tried contacting Linode in regards to whois, giving an example of > some other smaller providers (e.g. vr.org) that label their own > sub-allocations within their ARIN-assigned space to contain an address > of the DC where the subnet is coming from, and asked whether Linode > could do the same; however, Linode informed me that they don't have > any kind of mail service from the DCs they're at, and that their ARIN > contact, effectively, said that they're already doing everything right > in regards not having any extra whois entries with the addresses of > their DC, since that would actually be wrong, as noone will be > expecting mail for Linode at those addresses. (In turn, it's unclear > whether a much smaller vr.org has mail service at nearly a dozen of > the DCs that they have their servers at, and which they provide as the > addresses in ARIN's whois, but I would guess that they do not.) > > This would seem like a possible shortcoming of ARIN's policies and the > whois database: with RIPE, every `netname` has a `country` associated > with it, seemingly without any requirements of a mailing address where > mail could be received; but with ARIN, no state is ever provided, only > a mailing address. (I've also just noticed that RIPE whois now has an > optional `geoloc` field in addition to the non-optional `country`.) > > Now, back to ARIN: is Linode doing it right? Is vr.org doing it > wrong? Are they both doing it correct, or are they both wrong? > > > And in regards to yelp and retailmenot; why are they blocking Linode > customers in 173.230.144.0/20? I've tried contacting both on multiple > occasions, and have never received any replies from yelp, but > retailmenot has replied several times with a blanket "someone may have > tried to scrap, spam or proxy our site from this network". I have > repeatedly asked retailmenot if they'd block Verizon or AT&T if > someone tries to scrap or spam their web-site from those networks, > too, but have never received any replies. I have also tried > contacting Linode regarding this issue, and although they were very > patient and tried troubleshooting the problem, reporting that it > appears that other addresses within 173.230.144.0/20 are likewise > blocked, but some of their other address ranges at another DC are not, > they have not been able to get in touch with anyone at yelp or > retailmenot to isolate the problem. > > > Now, if you were operating yelp or rmn, would you not block an address > range with a fishy geoloc like that of Linode? I'm somewhat convinced > that 403 Forbidden stems entirely out of some logic that notes that > the geoloc data is likely fishy, or which [erroneously] concludes that > the address range is used for anonymity purposes. > > > Anyhow. How do I get my geoloc to show Fremont, CA? And to have yelp > stop returning 403 Forbidden? > > Cheers, > Constantine. > From johnl at iecc.com Sun Mar 3 19:23:39 2013 From: johnl at iecc.com (John Levine) Date: 3 Mar 2013 19:23:39 -0000 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: <215377.1362329066@turing-police.cc.vt.edu> Message-ID: <20130303192339.88226.qmail@joyce.lan> Yes. In article <215377.1362329066 at turing-police.cc.vt.edu> you write: >-=-=-=-=-=- > >On Sun, 03 Mar 2013 00:24:07 +0000, Mike Jones said: >> Inline Reply >> >> On 2 March 2013 21:58, Constantine A. Murenin wrote: >> > Dear NANOG@, > >Have we *really* sunk so low that inline replies need to be flagged as >such, because people *expect* top-posting and if they don't see it they >assume it's a MUA misfire rather than an inline reply? > >-=-=-=-=-=- >[Attachment type=application/pgp-signature, name=unknown] >-=-=-=-=-=- From wingcomm at hotmail.com Sun Mar 3 19:35:59 2013 From: wingcomm at hotmail.com (R W) Date: Sun, 3 Mar 2013 14:35:59 -0500 Subject: Comcast NOC Contact In-Reply-To: <6212992.8198.1362326590992.JavaMail.root@benjamin.baylink.com> References: <38C548ED-5840-4A28-8F6D-C97EE3A8A689@snappydsl.net>, <6212992.8198.1362326590992.JavaMail.root@benjamin.baylink.com> Message-ID: Yeah, I've been hitting congested links with several of my customers. This was just a case of one of our customer's prefixes taking an extra long journey from one region to another. Thank you to all who responded! I think we might on our way to remediating this small issue! -Rob > Date: Sun, 3 Mar 2013 11:03:10 -0500 > From: jra at baylink.com > To: nanog at nanog.org > Subject: Re: Comcast NOC Contact > > ----- Original Message ----- > > On Mar 3, 2013, at 7:40 AM, Nick Hilliard wrote: > > > > For providers who have an overall asymmetric traffic profile towards > > > Comcast, it's a matter of perspective as to whether you view this as > > > the providers sending Comcast traffic or Comcast customers pulling it. > > > So it's hardly surprising that there are disagreements about who gets to pay > > > the other for the interconnection arrangements. > > Saying that it's a matter of perspective is a false dichotomy. > > If the providers go away, the Comcast customers will pull traffic from > other providers. > > If the *customers* go away... > > Nope; Comcast is acting as the agent of its customers to pull in traffic > they want to see, and if it isn't charging them enough for that, that is > *Comcast's* problem. > > It's really a bright-line answer. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From arthur.wist at gmail.com Sun Mar 3 10:46:15 2013 From: arthur.wist at gmail.com (Arthur Wist) Date: Sun, 3 Mar 2013 11:46:15 +0100 Subject: Cloudflare is down Message-ID: https://twitter.com/CloudFlare/status/308157556113698816 https://twitter.com/CloudFlare/status/308165820285083648 Apparently due to a routing issue... -AW From jra at baylink.com Sun Mar 3 19:47:37 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Mar 2013 14:47:37 -0500 (EST) Subject: Cloudflare is down In-Reply-To: Message-ID: <12797082.8260.1362340057202.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Arthur Wist" > To: nanog at nanog.org > Sent: Sunday, March 3, 2013 5:46:15 AM > https://twitter.com/CloudFlare/status/308157556113698816 > https://twitter.com/CloudFlare/status/308165820285083648 > > Apparently due to a routing issue... Unless you're in UTC-12 or your clock is wrong, you posted that 7 hours ago and it just hit the list. (Whomever wrote that Sent header, BTW, presumably your MUA, is 5322 non-compliant: no TZ.) Anyroad, their Twitter account now seems to say they're back up. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From nick at foobar.org Sun Mar 3 20:02:05 2013 From: nick at foobar.org (Nick Hilliard) Date: Sun, 03 Mar 2013 20:02:05 +0000 Subject: Cloudflare is down In-Reply-To: References: Message-ID: <5133AC3D.4070105@foobar.org> On 03/03/2013 10:46, Arthur Wist wrote: > Apparently due to a routing issue... back up again: http://blog.cloudflare.com/todays-outage-post-mortem-82515 tl;dr: outage caused by flowspec filter tickling vendor bug. Nick From mureninc at gmail.com Sun Mar 3 20:46:20 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 3 Mar 2013 12:46:20 -0800 Subject: Cloudflare is down In-Reply-To: <5133AC3D.4070105@foobar.org> References: <5133AC3D.4070105@foobar.org> Message-ID: On 3 March 2013 12:02, Nick Hilliard wrote: > On 03/03/2013 10:46, Arthur Wist wrote: >> Apparently due to a routing issue... > > back up again: http://blog.cloudflare.com/todays-outage-post-mortem-82515 > > tl;dr: outage caused by flowspec filter tickling vendor bug. Definitely smart to be delegating your DNS to the web-accelerator company and a single point of failure, especially if you are not just running a web-site, but have some other independent infrastructure, too. >>>>>>CloudFlare's 23 data centers span 14 countries so the response took some time but within about 30 minutes we began to restore CloudFlare's network and services. By 10:49 UTC, all of CloudFlare's services were restored. We continue to investigate some edge cases where people are seeing outages. In nearly all of these cases, the problem is that a bad DNS response has been cached. Typically clearing the DNS cache will resolve the issue. Yet, apparently, CloudFlare doesn't even support using any of their services with your own DNS solutions. And how exactly do they expect end-users "clearing the DNS cache"? Do I call AT&T, and ask them to clear their cache? http://serverfault.com/questions/479367/how-long-a-dns-timeout-is-cached-for C. From vinod408 at hotmail.com Sun Mar 3 20:31:35 2013 From: vinod408 at hotmail.com (Vinod K) Date: Sun, 3 Mar 2013 20:31:35 +0000 Subject: Cloudflare is down In-Reply-To: <5133AC3D.4070105@foobar.org> References: , <5133AC3D.4070105@foobar.org> Message-ID: I am not sure of bug... could be normal behavior for how JunOS CLI handle "extended" packet size. Will wait for Juniper comment on incident. Vinod > Date: Sun, 3 Mar 2013 20:02:05 +0000 > From: nick at foobar.org > To: arthur.wist at gmail.com > Subject: Re: Cloudflare is down > CC: nanog at nanog.org > > On 03/03/2013 10:46, Arthur Wist wrote: > > Apparently due to a routing issue... > > back up again: http://blog.cloudflare.com/todays-outage-post-mortem-82515 > > tl;dr: outage caused by flowspec filter tickling vendor bug. > > Nick > > > From vinod408 at hotmail.com Sun Mar 3 20:35:03 2013 From: vinod408 at hotmail.com (Vinod K) Date: Sun, 3 Mar 2013 20:35:03 +0000 Subject: Comcast NOC Contact In-Reply-To: References: <38C548ED-5840-4A28-8F6D-C97EE3A8A689@snappydsl.net>, , <6212992.8198.1362326590992.JavaMail.root@benjamin.baylink.com>, Message-ID: What congested links r u seeing? When we contacted Comcast for peering, Ren Provo explain that ratios r balanced b/c of their media and cloud products... imbalance is common misunderstanding. Vinod > From: wingcomm at hotmail.com > To: jra at baylink.com; nanog at nanog.org > Subject: RE: Comcast NOC Contact > Date: Sun, 3 Mar 2013 14:35:59 -0500 > > Yeah, I've been hitting congested links with several of my customers. This was just a case of one of our customer's prefixes taking an extra long journey from one region to another. > Thank you to all who responded! I think we might on our way to remediating this small issue! > -Rob > > > Date: Sun, 3 Mar 2013 11:03:10 -0500 > > From: jra at baylink.com > > To: nanog at nanog.org > > Subject: Re: Comcast NOC Contact > > > > ----- Original Message ----- > > > On Mar 3, 2013, at 7:40 AM, Nick Hilliard wrote: > > > > > > For providers who have an overall asymmetric traffic profile towards > > > > Comcast, it's a matter of perspective as to whether you view this as > > > > the providers sending Comcast traffic or Comcast customers pulling it. > > > > So it's hardly surprising that there are disagreements about who gets to pay > > > > the other for the interconnection arrangements. > > > > Saying that it's a matter of perspective is a false dichotomy. > > > > If the providers go away, the Comcast customers will pull traffic from > > other providers. > > > > If the *customers* go away... > > > > Nope; Comcast is acting as the agent of its customers to pull in traffic > > they want to see, and if it isn't charging them enough for that, that is > > *Comcast's* problem. > > > > It's really a bright-line answer. > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink jra at baylink.com > > Designer The Things I Think RFC 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > > St Petersburg FL USA #natog +1 727 647 1274 > > > From fw at deneb.enyo.de Sun Mar 3 21:35:59 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 03 Mar 2013 22:35:59 +0100 Subject: Cloudflare is down In-Reply-To: (Constantine A. Murenin's message of "Sun, 3 Mar 2013 12:46:20 -0800") References: <5133AC3D.4070105@foobar.org> Message-ID: <87mwukjhds.fsf@mid.deneb.enyo.de> * Constantine A. Murenin: > And how exactly do they expect end-users "clearing the DNS cache"? Do > I call AT&T, and ask them to clear their cache? Sure, and also tell them to clear their BGP cache (aka "route flap dampening"). 8-) From dreamwaverfx at yahoo.com Sun Mar 3 21:54:27 2013 From: dreamwaverfx at yahoo.com (Alex) Date: Sun, 03 Mar 2013 23:54:27 +0200 Subject: Cloudflare is down In-Reply-To: <5133AC3D.4070105@foobar.org> References: <5133AC3D.4070105@foobar.org> Message-ID: <5133C693.5040100@yahoo.com> Is there any blog or some sort of site that has a up to date list with the latest network outages? Like, not just Cloudflare, but every major outage that has happen lately. Its really nice to see a post-mortem analysis like in this case. Bugs/hidden "features" are not "documented" in most of the books I've read, so the only way to run into them is to either step on it yourself or learn from other networks going splat before yours does. I've tried to search a few more and I've either found "electrical network outage" or reports from individual businesses as to why their service went down, but I wasn't able to find the "big list". I'd appreciate it a lot if anyone could point me in the right direction. Thanks, Alex. On 03/03/2013 10:02 PM, Nick Hilliard wrote: > On 03/03/2013 10:46, Arthur Wist wrote: >> Apparently due to a routing issue... > back up again: http://blog.cloudflare.com/todays-outage-post-mortem-82515 > > tl;dr: outage caused by flowspec filter tickling vendor bug. > > Nick > > > From frnkblk at iname.com Sun Mar 3 22:06:24 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 3 Mar 2013 16:06:24 -0600 Subject: Cloudflare is down In-Reply-To: <5133C693.5040100@yahoo.com> References: <5133AC3D.4070105@foobar.org> <5133C693.5040100@yahoo.com> Message-ID: <001001ce185b$58ad5c50$0a0814f0$@iname.com> I'd start here: http://www.outages.org/ and the listserv is here: http://wiki.outages.org/index.php/Main_Page#Outages_Mailing_Lists Set aside the idea of "every" outage, and "major" is relative to the eye of the beholder. =) Frank -----Original Message----- From: Alex [mailto:dreamwaverfx at yahoo.com] Sent: Sunday, March 03, 2013 3:54 PM To: Nick Hilliard Cc: nanog at nanog.org Subject: Re: Cloudflare is down Is there any blog or some sort of site that has a up to date list with the latest network outages? Like, not just Cloudflare, but every major outage that has happen lately. Its really nice to see a post-mortem analysis like in this case. Bugs/hidden "features" are not "documented" in most of the books I've read, so the only way to run into them is to either step on it yourself or learn from other networks going splat before yours does. I've tried to search a few more and I've either found "electrical network outage" or reports from individual businesses as to why their service went down, but I wasn't able to find the "big list". I'd appreciate it a lot if anyone could point me in the right direction. Thanks, Alex. On 03/03/2013 10:02 PM, Nick Hilliard wrote: > On 03/03/2013 10:46, Arthur Wist wrote: >> Apparently due to a routing issue... > back up again: http://blog.cloudflare.com/todays-outage-post-mortem-82515 > > tl;dr: outage caused by flowspec filter tickling vendor bug. > > Nick > > > From mysidia at gmail.com Sun Mar 3 23:48:50 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 3 Mar 2013 17:48:50 -0600 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: <8DC103E7-AA2A-44F0-B2A3-9C98DF119E2F@delong.com> Message-ID: On 3/2/13, Constantine A. Murenin wrote: > On 2 March 2013 15:45, Owen DeLong wrote: >>> Now, back to ARIN: is Linode doing it right? Is vr.org doing it >>> wrong? Are they both doing it correct, or are they both wrong? > They have repeatedly disagreed, on two separate occasions, effectively > claiming they themselves are the customers: ... they are assigning IP addresses to their own equipment, which belongs to the provider at all times, and the contact can be the same contact for all their resources, therefore: they are not necessarily required to display a SWIP in WHOIS. They just need to keep certain documentation. Network service providers that allocate or assign IP addresses are required to display allocations/assignments of /29 and larger in WHOIS; they can display any additional divisions in WHOIS that the org deems sensible for their network. However, (1) This isn't very pertinent to gelocation. ARIN resource holders don't have to SWIP their different datacenter networks that are all assigned to the provider, and (2) don't need to provide a street address for their listings that has a bearing on where the network is actually geographically located, WHOIS listings are contacts. Also, a SWIP would probably not stop have stopped Yelp, et al. from blocking the network. If it's in the IP address space of a VPS hosting provider. If the provider is large enough, it is almost certain that someone will have conducted activity, causing large portions of the provider's IP space to be blocked, and this is just part of the risk cost of hosting your site there. (You get a lower upfront dollar price, compared to setting up your own network and obtaining /24 direct assignment from an upstream, because you are sharing a network with other subscribers, but when one of those other subscribers commits some abuse -- your orgs VPS could be on the blocked network too) If you have issues with Linode's WHOIS listing policies, there are plenty of alternative providers; although they may be susceptible to similar blocks by Yelp etc. > Could work with IPv6, since I have a /56 from them, but I only have a > single IPv4, so, per my understanding, an IPv4 SWIP is not possible. It's conceivable to list a /32 on a RWHOIS server. But Linode do not have to do it, and most likely they will not be willing to do it. It is not unusual that a hosting provider would be unwilling to take on the additional cost of maintaining indinvidual WHOis listings for each subscriber. Or to change their WHOIS policy based on the request of one customer; possibly increasing their WHOIS record management costs by a significant amount. > C. -- -JH From angst1974 at yahoo.com Mon Mar 4 02:07:51 2013 From: angst1974 at yahoo.com (Steve) Date: Sun, 3 Mar 2013 21:07:51 -0500 Subject: Cloudflare is down Message-ID: <54CD5770-B668-4567-8BDC-015E4F946862@yahoo.com> Known Juniper security issue . We found it during testing and discovered it is fixed in later code. I don't have the specifics in front of me right now or I'd share. This Email was sent from Steve's iPad Message: 5 Date: Sun, 3 Mar 2013 20:31:35 +0000 From: Vinod K To: Subject: RE: Cloudflare is down Message-ID: Content-Type: text/plain; charset="iso-8859-1" I am not sure of bug... could be normal behavior for how JunOS CLI handle "extended" packet size. Will wait for Juniper comment on incident. Vinod > Date: Sun, 3 Mar 2013 20:02:05 +0000 > From: nick at foobar.org > To: arthur.wist at gmail.com > Subject: Re: Cloudflare is down > CC: nanog at nanog.org > > On 03/03/2013 10:46, Arthur Wist wrote: >> Apparently due to a routing issue... > > back up again: http://blog.cloudflare.com/todays-outage-post-mortem-82515 > > tl;dr: outage caused by flowspec filter tickling vendor bug. > > Nick From owen at delong.com Mon Mar 4 05:48:06 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Mar 2013 21:48:06 -0800 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: <8DC103E7-AA2A-44F0-B2A3-9C98DF119E2F@delong.com> Message-ID: On Mar 3, 2013, at 15:48 , Jimmy Hess wrote: > On 3/2/13, Constantine A. Murenin wrote: >> On 2 March 2013 15:45, Owen DeLong wrote: >>>> Now, back to ARIN: is Linode doing it right? Is vr.org doing it >>>> wrong? Are they both doing it correct, or are they both wrong? >> They have repeatedly disagreed, on two separate occasions, effectively >> claiming they themselves are the customers: > > ... they are assigning IP addresses to their own equipment, which > belongs to the provider at all times, and the contact can be the same > contact for all their resources, therefore: they are not necessarily > required to display a SWIP in WHOIS. They just need to keep certain > documentation. The addresses assigned to their hardware interfaces may fit that argument. The addresses assigned to customer virtuals, OTOH, IMHO do not really meet that test. The virtual and its content are not property of Linode, they belong to the customer. Yes, the customer is using Linode's hardware as an execution environment for their virtual, but the address range is assigned to the customer virtual. At that point, I would argue that the policy for SWIP does, in fact, apply. Owen From ren.provo at gmail.com Mon Mar 4 06:28:32 2013 From: ren.provo at gmail.com (Ren Provo) Date: Mon, 4 Mar 2013 01:28:32 -0500 Subject: Comcast NOC Contact In-Reply-To: References: <38C548ED-5840-4A28-8F6D-C97EE3A8A689@snappydsl.net> <6212992.8198.1362326590992.JavaMail.root@benjamin.baylink.com> Message-ID: Uhm, no I did not. I'd be happy to review your request. Send over your ASN to the proper channels please. -ren_provo at cable.comcast.com On Sun, Mar 3, 2013 at 3:35 PM, Vinod K wrote: > > What congested links r u seeing? > > When we contacted Comcast for peering, Ren Provo explain that ratios r balanced b/c of their media and cloud products... imbalance is common misunderstanding. > > Vinod > >> From: wingcomm at hotmail.com >> To: jra at baylink.com; nanog at nanog.org >> Subject: RE: Comcast NOC Contact >> Date: Sun, 3 Mar 2013 14:35:59 -0500 >> >> Yeah, I've been hitting congested links with several of my customers. This was just a case of one of our customer's prefixes taking an extra long journey from one region to another. >> Thank you to all who responded! I think we might on our way to remediating this small issue! >> -Rob >> >> > Date: Sun, 3 Mar 2013 11:03:10 -0500 >> > From: jra at baylink.com >> > To: nanog at nanog.org >> > Subject: Re: Comcast NOC Contact >> > >> > ----- Original Message ----- >> > > On Mar 3, 2013, at 7:40 AM, Nick Hilliard wrote: >> > >> > > > For providers who have an overall asymmetric traffic profile towards >> > > > Comcast, it's a matter of perspective as to whether you view this as >> > > > the providers sending Comcast traffic or Comcast customers pulling it. >> > > > So it's hardly surprising that there are disagreements about who gets to pay >> > > > the other for the interconnection arrangements. >> > >> > Saying that it's a matter of perspective is a false dichotomy. >> > >> > If the providers go away, the Comcast customers will pull traffic from >> > other providers. >> > >> > If the *customers* go away... >> > >> > Nope; Comcast is acting as the agent of its customers to pull in traffic >> > they want to see, and if it isn't charging them enough for that, that is >> > *Comcast's* problem. >> > >> > It's really a bright-line answer. >> > >> > Cheers, >> > -- jra >> > -- >> > Jay R. Ashworth Baylink jra at baylink.com >> > Designer The Things I Think RFC 2100 >> > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII >> > St Petersburg FL USA #natog +1 727 647 1274 >> > >> > From saku at ytti.fi Mon Mar 4 07:31:13 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2013 09:31:13 +0200 Subject: Cloudflare is down In-Reply-To: References: <5133AC3D.4070105@foobar.org> Message-ID: <20130304073113.GA10384@pob.ytti.fi> On (2013-03-03 12:46 -0800), Constantine A. Murenin wrote: > Definitely smart to be delegating your DNS to the web-accelerator > company and a single point of failure, especially if you are not just > running a web-site, but have some other independent infrastructure, > too. To be fair, most of us probably have harmonized peering edge, running one vendor, with one or two software releases and as as such as susceptible to BGP update taking down whole edge. I'm not comfortable personally to point cloudflare and say this was easily avoidable and should not have happened (Not implying you are either). If fuzzing BGP was easy, vendors would provide us working software and we wouldn't lose good portion of Internet every few years due to mangled UPDATE. I know lot of vendors are fuzzing with 'codenomicon' and they appear not to have flowspec fuzzer. Lot of things had to go wrong for this to cause outage. 1. their traffic analyzer had to have bug which could claim packet size is 90k 2. their noc people had to accept it as legit data (2.5 their internal software where filter is updated, had to accept this data, unsure if it was internal system or junos directly) 3. junos cli had to accept this data 4. flowspec had to accept it and generate nlri carrying it 5. nlri -> ACL abstraction engine had to accept it and try to program to hardware Even if cloudflare had been running out-sourced anycast DNS with many vendor edge, the records had still been pointing out to a network which you couldn't reach. Probably only thing you could have done to plan against this, would have been to have solid dual-vendor strategy, to presume that sooner or later, software defect will take one vendor completely out. And maybe they did plan for it, but decided dual-vendor costs more than the rare outages. -- ++ytti From bicknell at ufp.org Mon Mar 4 14:51:31 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 Mar 2013 06:51:31 -0800 Subject: Cloudflare is down In-Reply-To: <20130304073113.GA10384@pob.ytti.fi> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> Message-ID: <20130304145131.GA5497@ussenterprise.ufp.org> In a message written on Mon, Mar 04, 2013 at 09:31:13AM +0200, Saku Ytti wrote: > Probably only thing you could have done to plan against this, would have > been to have solid dual-vendor strategy, to presume that sooner or later, > software defect will take one vendor completely out. And maybe they did > plan for it, but decided dual-vendor costs more than the rare outages. From what I have heard so far there is something else they could have done, hire higher quality people. Any competent network admin would have stopped and questioned a 90,000+ byte packet and done more investigation. Competent programmers writing their internal tools would have flagged that data as out of rage. I can't tell you how many times I've sat in a post mortem meeting about some issue and the answer from senior management is "why don't you just provide a script to our NOC guys, so the next time they can run it and make it all better." Of course it's easy to say that, the smart people have diagnosed the problem! You can buy these "scripts" for almost any profession. There are manuals on how to fix everything on a car, and treatment plans for almost every disease. Yet most people intuitively understand you take your car to a mechanic and your body to a doctor for the proper diagnosis. The primary thing you're paying for is expertise in what to fix, not how to fix it. That takes experience and training. But somehow it doesn't sink in with networking. I would not at all be surprised to hear that someone over at Cloudflare right now is saying "let's make a script to check the packet size" as if that will fix the problem. It won't. Next time the issue will be different, and the same undertrained person who missed the packet size this time will miss the next issue as well. They should all be sitting around saying, "how can we hire compentent network admins for our NOC", but that would cost real money. -- 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 Jason_Livingood at cable.comcast.com Mon Mar 4 15:05:15 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 4 Mar 2013 15:05:15 +0000 Subject: Comcast NOC Contact In-Reply-To: Message-ID: <10229F86C86EB444898E629583FD4171616A92D5@PACDCEXMB06.cable.comcast.com> On 3/3/13 3:35 PM, "Vinod K" wrote: >When we contacted Comcast for peering, Ren Provo explain that ratios r >balanced b/c of their media and cloud products... imbalance is common >misunderstanding. Exactly? Jason From morrowc.lists at gmail.com Mon Mar 4 15:09:36 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Mar 2013 10:09:36 -0500 Subject: Cloudflare is down In-Reply-To: <20130304073113.GA10384@pob.ytti.fi> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> Message-ID: On Mon, Mar 4, 2013 at 2:31 AM, Saku Ytti wrote: > I know lot of vendors are fuzzing with 'codenomicon' and they appear not to > have flowspec fuzzer. i suspect they fuzz where the money is ... number of users of bgp? number of users of flowspec? From saku at ytti.fi Mon Mar 4 16:17:20 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2013 18:17:20 +0200 Subject: Cloudflare is down In-Reply-To: <20130304145131.GA5497@ussenterprise.ufp.org> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> Message-ID: <20130304161720.GA12588@pob.ytti.fi> On (2013-03-04 06:51 -0800), Leo Bicknell wrote: > From what I have heard so far there is something else they could > have done, hire higher quality people. Your solution to mistakes seem to be not to make them. I can understand the train of thought, but I suspect the practicality of such advice. -- ++ytti From nick at foobar.org Mon Mar 4 16:24:26 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 04 Mar 2013 16:24:26 +0000 Subject: whois.radb.net returning blank results Message-ID: <5134CABA.5010309@foobar.org> Looks like whois.radb.net is returning blank results. > pancake:/home/nick> whois -h whois.radb.net 198.41.0.0 | wc -l > 0 > pancake:/home/nick> Those people who use the RADB IRRDB for generating filters / configuring routers might like to do some runs in their testing environment to ensure that no kittens lose their lives. (thanks to Kevin Loch for pointing this out). Nick From morrowc.lists at gmail.com Mon Mar 4 16:36:34 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Mar 2013 11:36:34 -0500 Subject: whois.radb.net returning blank results In-Reply-To: <5134CABA.5010309@foobar.org> References: <5134CABA.5010309@foobar.org> Message-ID: On Mon, Mar 4, 2013 at 11:24 AM, Nick Hilliard wrote: > whois -h whois.radb.net 198.41.0.0 fgets: Connection reset by peer :( larry blunk has helped in the past to fix this... From patrick at ianai.net Mon Mar 4 16:43:59 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 4 Mar 2013 11:43:59 -0500 Subject: Cloudflare is down In-Reply-To: <20130304145131.GA5497@ussenterprise.ufp.org> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> Message-ID: <2CD383E7-4C0B-47F9-9CE2-4C32A7F63BE3@ianai.net> On Mar 04, 2013, at 09:51 , Leo Bicknell wrote: > Any competent network admin would have stopped and questioned a > 90,000+ byte packet and done more investigation. Competent programmers > writing their internal tools would have flagged that data as out > of rage. The last couple words are the best thing I've read on NANOG in a very long time. :) -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From job.snijders at atrato.com Mon Mar 4 16:55:30 2013 From: job.snijders at atrato.com (Job Snijders) Date: Mon, 4 Mar 2013 17:55:30 +0100 Subject: whois.radb.net returning blank results In-Reply-To: References: <5134CABA.5010309@foobar.org> Message-ID: <615BD0EE-CB03-42F6-8ECE-C22B8B7556AF@atrato.com> Hi, NRTM still works according to my mirrors. So for up 2 date data, you could use irr.ring.nlnog.net: Alice:~ job$ whois -h irr.ring.nlnog.net 198.41.0.0 | wc -l 437 Alice:~ job$ Kind regards, Job On Mar 4, 2013, at 5:36 PM, Christopher Morrow wrote: > On Mon, Mar 4, 2013 at 11:24 AM, Nick Hilliard wrote: >> whois -h whois.radb.net 198.41.0.0 > > > fgets: Connection reset by peer > > > :( larry blunk has helped in the past to fix this... > From wbailey at satelliteintelligencegroup.com Mon Mar 4 16:59:31 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 4 Mar 2013 16:59:31 +0000 Subject: Cloudflare is down In-Reply-To: <2CD383E7-4C0B-47F9-9CE2-4C32A7F63BE3@ianai.net> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org>, <2CD383E7-4C0B-47F9-9CE2-4C32A7F63BE3@ianai.net> Message-ID: <7gjdf4yclhda8v6ofq90c8pk.1362416365517@email.android.com> +1. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: "Patrick W. Gilmore" Date: 03/04/2013 11:46 AM (GMT-05:00) To: NANOG list Subject: Re: Cloudflare is down On Mar 04, 2013, at 09:51 , Leo Bicknell wrote: > Any competent network admin would have stopped and questioned a > 90,000+ byte packet and done more investigation. Competent programmers > writing their internal tools would have flagged that data as out > of rage. The last couple words are the best thing I've read on NANOG in a very long time. :) -- TTFN, patrick From morrowc.lists at gmail.com Mon Mar 4 17:40:03 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 4 Mar 2013 12:40:03 -0500 Subject: whois.radb.net returning blank results In-Reply-To: <615BD0EE-CB03-42F6-8ECE-C22B8B7556AF@atrato.com> References: <5134CABA.5010309@foobar.org> <615BD0EE-CB03-42F6-8ECE-C22B8B7556AF@atrato.com> Message-ID: On Mon, Mar 4, 2013 at 11:55 AM, Job Snijders wrote: > Hi, > > NRTM still works according to my mirrors. So for up 2 date data, you could use irr.ring.nlnog.net: > > Alice:~ job$ whois -h irr.ring.nlnog.net 198.41.0.0 | wc -l > 437 > Alice:~ job$ also, radb seems to have come back from the dead: $ whois -h 198.108.0.18 216.239.32.0 | wc -l 7 huzzah! > Kind regards, > > Job > > > On Mar 4, 2013, at 5:36 PM, Christopher Morrow wrote: > >> On Mon, Mar 4, 2013 at 11:24 AM, Nick Hilliard wrote: >>> whois -h whois.radb.net 198.41.0.0 >> >> >> fgets: Connection reset by peer >> >> >> :( larry blunk has helped in the past to fix this... >> > > From ljb at merit.edu Mon Mar 4 18:22:36 2013 From: ljb at merit.edu (Larry Blunk) Date: Mon, 04 Mar 2013 13:22:36 -0500 Subject: whois.radb.net returning blank results In-Reply-To: References: <5134CABA.5010309@foobar.org> <615BD0EE-CB03-42F6-8ECE-C22B8B7556AF@atrato.com> Message-ID: <5134E66C.8080604@merit.edu> Apologies, issues seem to have been caused by a slowish memory leak in IRRd and the process had begun to swap heavily when a regular maintenance thread ran. Regards, Larry On 03/04/2013 12:40 PM, Christopher Morrow wrote: > On Mon, Mar 4, 2013 at 11:55 AM, Job Snijders wrote: >> Hi, >> >> NRTM still works according to my mirrors. So for up 2 date data, you could use irr.ring.nlnog.net: >> >> Alice:~ job$ whois -h irr.ring.nlnog.net 198.41.0.0 | wc -l >> 437 >> Alice:~ job$ > > also, radb seems to have come back from the dead: > $ whois -h 198.108.0.18 216.239.32.0 | wc -l > 7 > > huzzah! > >> Kind regards, >> >> Job >> >> >> On Mar 4, 2013, at 5:36 PM, Christopher Morrow wrote: >> >>> On Mon, Mar 4, 2013 at 11:24 AM, Nick Hilliard wrote: >>>> whois -h whois.radb.net 198.41.0.0 >>> >>> >>> fgets: Connection reset by peer >>> >>> >>> :( larry blunk has helped in the past to fix this... >>> >> >> From jsw at inconcepts.biz Mon Mar 4 18:23:51 2013 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 4 Mar 2013 13:23:51 -0500 Subject: Cloudflare is down In-Reply-To: <20130304145131.GA5497@ussenterprise.ufp.org> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> Message-ID: On Mon, Mar 4, 2013 at 9:51 AM, Leo Bicknell wrote: > will fix the problem. It won't. Next time the issue will be > different, and the same undertrained person who missed the packet > size this time will miss the next issue as well. They should all be > sitting around saying, "how can we hire compentent network admins for > our NOC", but that would cost real money. I think that is hard because virtually all training / education in our industry is based on procedures, not on concepts. Pick up any book about networking and you'll find examples of how to configure a lab of Cisco 2900s so you can pass an exam. Very few that go into conceptual detail or troubleshooting of any kind. Educational programs suffer from the same flaw. There are exceptions to this rule, but they are very few. I'm sure many NANOG readers are familiar with "Interdomain Multicast Routing," for example. It is an excellent book because it covers concepts and compares two popular vendor platforms on a variety of multicast topics. We have lots of stupid people in our industry because so few understand "The Way Things Work." -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From saku at ytti.fi Mon Mar 4 18:40:58 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2013 20:40:58 +0200 Subject: Cloudflare is down In-Reply-To: References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> Message-ID: <20130304184058.GA12708@pob.ytti.fi> On (2013-03-04 13:23 -0500), Jeff Wheeler wrote: > We have lots of stupid people in our industry because so few > understand "The Way Things Work." We have tendency to view mistakes we do as unavoidable human errors and mistakes other people do as avoidable stupidity. We should actively plan for mistakes/errors, if you actively plan for no 'stupid mistakes', you're gonna have bad time >From my point of view, outages are caused by: 1) operator 2) software defect 3) hardware defect Most people design only against 3), often with design which actually increases likelihood of 2) and 1), reducing overall MTBF on design which strictly theoretically increases it. -- ++ytti From Valdis.Kletnieks at vt.edu Mon Mar 4 18:53:48 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 04 Mar 2013 13:53:48 -0500 Subject: Cloudflare is down In-Reply-To: Your message of "Mon, 04 Mar 2013 20:40:58 +0200." <20130304184058.GA12708@pob.ytti.fi> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> <20130304184058.GA12708@pob.ytti.fi> Message-ID: <5484.1362423228@turing-police.cc.vt.edu> On Mon, 04 Mar 2013 20:40:58 +0200, Saku Ytti said: > Most people design only against 3), often with design which actually > increases likelihood of 2) and 1), reducing overall MTBF on design which > strictly theoretically increases it. I have to admit I've always suspect that MTBWTF would be a more useful metric of real-world performance. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mureninc at gmail.com Mon Mar 4 20:33:42 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Mon, 4 Mar 2013 12:33:42 -0800 Subject: Cloudflare is down In-Reply-To: <20130304073113.GA10384@pob.ytti.fi> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> Message-ID: On 3 March 2013 23:31, Saku Ytti wrote: > On (2013-03-03 12:46 -0800), Constantine A. Murenin wrote: > >> Definitely smart to be delegating your DNS to the web-accelerator >> company and a single point of failure, especially if you are not just >> running a web-site, but have some other independent infrastructure, >> too. > > To be fair, most of us probably have harmonized peering edge, running one > vendor, with one or two software releases and as as such as susceptible to > BGP update taking down whole edge. > > I'm not comfortable personally to point cloudflare and say this was easily > avoidable and should not have happened (Not implying you are either). The issue I have is not with their network. The issue is that they require ALL of their customers to hand over DNS control, and completely disregard any kind of situation as what has just happened. * They don't provide any IP-addresses which you can set your A or AAAA records to. * They don't provide any hostnames which you can set a CNAME to. (Supposedly, they do offer CNAME support to paid customers, but if you look at their help page for CNAME support, it's clearly evident that it's highly discouraged and effectively an unsupported option.) * They don't let you AXFR and mirror the zones, either. So, the issue here, is that a second point of failure is suddenly introduced to your own harmonised network, and introduced in a way as to suggest that it's not a big deal, and will make everything better anyways. In actuality, this doesn't even stop their users from going the unsupported route: I've seen some relatively major and popular hosting provider turn over their web-site to CloudFlare when it was under attack, but they did it with an A record, potentially to not suffer a complete embarrassment of having `whois` show that they don't even use the nameservers that they provide to their own users. [...] > Even if cloudflare had been running out-sourced anycast DNS with many > vendor edge, the records had still been pointing out to a network which you > couldn't reach. This is where you have it wrong. DNS is not only useful for http. Yet CloudFlare only provides http-acceleration. Yet they do require that you delegate your domains to the nameservers on their own single-vendor network, with no option to opt-out. I don't think they should necessarily be running an out-sourced DNS, but I do think that they should not make it a major problem for users to use http-acceleration services without DNS tie-ins. Last I checked, CloudFlare didn't even let you setup just a subdomain for their service, e.g. they do require complete DNS control from the registrar-zone level, all the time, every single time. C. From saku at ytti.fi Mon Mar 4 21:14:37 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Mar 2013 23:14:37 +0200 Subject: Cloudflare is down In-Reply-To: References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> Message-ID: <20130304211437.GA12760@pob.ytti.fi> On (2013-03-04 12:33 -0800), Constantine A. Murenin wrote: > to use http-acceleration services without DNS tie-ins. Last I > checked, CloudFlare didn't even let you setup just a subdomain for > their service, e.g. they do require complete DNS control from the > registrar-zone level, all the time, every single time. I'm not going to justify this behaviour. It would not occur to make to give zone control out to 3rd party unless all the zones point to records hosted by same 3rd party. -- ++ytti From baconzombie at gmail.com Mon Mar 4 21:43:05 2013 From: baconzombie at gmail.com (Bacon Zombie) Date: Mon, 4 Mar 2013 21:43:05 +0000 Subject: "After Being Cut From Norway, The Pirate Bay Returns From North Korea" or is it just BGP Tricks Message-ID: The Pirate Bay have released a press release that they are now hosted out of North Korea: "The Pirate Bay has been hunted in many countries around the world. ....This is truly an ironic situation. We have been fighting for a free world, and our opponents are mostly huge corporations from the United States of America, a place where freedom and freedom of speech is said to be held high...... ...We believe that being offered our virtual asylum in Korea is a first step of this country's changing view of access to information......." http://falkvinge.net/2013/03/04/after-being-cut-from-norway-the-pirate-bay-returns-from-north-korea/ https://thepiratebay.se/blog/229 But there is a lot of debate on Reddit that they are not really in North Korea and just doing some BGP trickery: "Anyone can hijack an AS number and not cause any issues for the real user ? In this case The Pirate Bay set up a Sat dish in Phenom Penh, Cambodia ? Intelsat gives them a BGP session there. The peer net for BGP handoff is 175.45.177.217/30, .216 is Intelsats side and .217 is The Pirate Bay?s. One can use ANY IP they wish for these handoffs, internal, their own, ?hijacked? ? In this case The Pirate Bay ?hijacked? 2 IPs from the North Korean network which does not matter for them as this is only acessible from their side, not from the internet. TBP then injected AS131279 as peer in the upstream table ? so it does not look like this: AS22351 ? AS51040 But instead: AS22351 ? AS131279 ? AS51040 This is possible because either Intelsat does not filter BGP announcements (unlikely) or TBP wrote a fake LOA for this AS (likely). Now as we traceroute the TBP IP we see the /30 subnet used for the handoff in Phenom Penh, which is why TPB says it is in North Korea ? The ICMP (ping) reply from the IP makes it seem legit but does actually come from and entirely different network (aka the real Star-KP network). (Theres some more but i spare you that as it is pretty technological ? for example that AS131279 does not hand over AS51040 routes to AS4737)." http://www.reddit.com/r/technology/comments/19nb00/after_being_cut_from_norway_the_pirate_bay/ Anybody have an input on this and able to confirm or deny the claims of BGP Hijacking? -- BaconZombie LOAD "*",8,1 From houdini+nanog at clanspum.net Mon Mar 4 22:16:08 2013 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Mon, 4 Mar 2013 16:16:08 -0600 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: References: Message-ID: <20130304221608.GL18751@clanspum.net> Constantine A. Murenin(mureninc at gmail.com)@Sat, Mar 02, 2013 at 01:58:09PM -0800: > Dear NANOG@, > Additionally, it seems like both yelp.com and retailmenot.com block > the whole 173.230.144.0/20 from their web-sites, returning some > graphical "403 Forbidden" pages instead. > And in regards to yelp and retailmenot; why are they blocking Linode > customers in 173.230.144.0/20? I've tried contacting both on multiple > occasions, and have never received any replies from yelp, but > retailmenot has replied several times with a blanket "someone may have > tried to scrap, spam or proxy our site from this network". I have > repeatedly asked retailmenot if they'd block Verizon or AT&T if > someone tries to scrap or spam their web-site from those networks, > too, but have never received any replies. I have also tried > contacting Linode regarding this issue, and although they were very > patient and tried troubleshooting the problem, reporting that it > appears that other addresses within 173.230.144.0/20 are likewise > blocked, but some of their other address ranges at another DC are not, > they have not been able to get in touch with anyone at yelp or > retailmenot to isolate the problem. For what it's worth, I've contacted Yelp about this issue a number of times, and they're wholly uninterested in traffic from Linode. They're also unwilling to discuss the issue with someone coming from Linode. So, good luck on that front! -- Bill Weiss From george.herbert at gmail.com Mon Mar 4 23:00:26 2013 From: george.herbert at gmail.com (George Herbert) Date: Mon, 4 Mar 2013 15:00:26 -0800 Subject: Cloudflare is down In-Reply-To: <20130304184058.GA12708@pob.ytti.fi> References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> <20130304184058.GA12708@pob.ytti.fi> Message-ID: On Mon, Mar 4, 2013 at 10:40 AM, Saku Ytti wrote: > On (2013-03-04 13:23 -0500), Jeff Wheeler wrote: > >> We have lots of stupid people in our industry because so few >> understand "The Way Things Work." > > We have tendency to view mistakes we do as unavoidable human errors and > mistakes other people do as avoidable stupidity. > > We should actively plan for mistakes/errors, if you actively plan for no > 'stupid mistakes', you're gonna have bad time > > From my point of view, outages are caused by: > 1) operator > 2) software defect > 3) hardware defect > > Most people design only against 3), often with design which actually > increases likelihood of 2) and 1), reducing overall MTBF on design which > strictly theoretically increases it. ...And a lot of people who know the heirarchy solve 3 and then solve 2 in a way that increases 1 (multiple parallel environments with different vendors' equipment) only to find that 1 increased, due to additional complexity. On the other hand, I've seen people who had horrible explosions of 2 or 3 due to ignoring all but 1. If you ACTUALLY need that many 9s, you need all of redundancy, diversity of vendors, and suitably trained, exercised, process-supported net admins. That's a few multiples of 2 more expense than nearly anyone typically wants to pay for. -- -george william herbert george.herbert at gmail.com From sethm at rollernet.us Tue Mar 5 02:19:23 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 04 Mar 2013 18:19:23 -0800 Subject: cannot access some popular websites from Linode, geolocation is wrong, ARIN is to blame? In-Reply-To: <20130304221608.GL18751@clanspum.net> References: <20130304221608.GL18751@clanspum.net> Message-ID: <5135562B.8080403@rollernet.us> On 3/4/13 2:16 PM, Bill Weiss wrote: > > For what it's worth, I've contacted Yelp about this issue a number of > times, and they're wholly uninterested in traffic from Linode. They're > also unwilling to discuss the issue with someone coming from Linode. So, > good luck on that front! > With all the garbage I've seen from placed with race to the bottom pricing I can't blame them. ~Seth From adam.vitkovsky at swan.sk Tue Mar 5 08:42:36 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Tue, 5 Mar 2013 09:42:36 +0100 Subject: Cloudflare is down In-Reply-To: References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> <20130304145131.GA5497@ussenterprise.ufp.org> <20130304184058.GA12708@pob.ytti.fi> Message-ID: <08e701ce197d$634b78e0$29e26aa0$@swan.sk> > From my point of view, outages are caused by: > 1) operator > 2) software defect > 3) hardware defect >From my experience now days the likelihood of an outage as a result of 3) is magnitude less than 2) and same goes for 2) to 1) ratio. In other words the vast majority of the outages are caused by human error. One way to partially rule out 1) is to have a fully customized stupid proof provisioning system - customized by those who know how stuff works. adam From bortzmeyer at nic.fr Tue Mar 5 15:54:00 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 5 Mar 2013 16:54:00 +0100 Subject: "After Being Cut From Norway, The Pirate Bay Returns From North Korea" or is it just BGP Tricks In-Reply-To: References: Message-ID: <20130305155400.GA12368@nic.fr> On Mon, Mar 04, 2013 at 09:43:05PM +0000, Bacon Zombie wrote a message of 71 lines which said: > But there is a lot of debate on Reddit that they are not really in > North Korea and just doing some BGP trickery: And ICMP trickery, to send false ICMP replies (with a delay) to traceroute requests. I am certain they are not in North Korea. The TCP latency when you connect with HTTP to thepiratebay.se if < 40 ms, something which you cannot have from North Korea. From wbailey at satelliteintelligencegroup.com Tue Mar 5 16:10:01 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 5 Mar 2013 16:10:01 +0000 Subject: "After Being Cut From Norway, The Pirate Bay Returns From North Korea" or is it just BGP Tricks In-Reply-To: <20130305155400.GA12368@nic.fr> References: , <20130305155400.GA12368@nic.fr> Message-ID: <612qirv8teoolhaw1oer40my.1362499797082@email.android.com> Seems easy enough to convince North Korea that they should announce my prefixes... ;) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Stephane Bortzmeyer Date: 03/05/2013 10:55 AM (GMT-05:00) To: Bacon Zombie Cc: nanog at nanog.org Subject: Re: "After Being Cut From Norway, The Pirate Bay Returns From North Korea" or is it just BGP Tricks On Mon, Mar 04, 2013 at 09:43:05PM +0000, Bacon Zombie wrote a message of 71 lines which said: > But there is a lot of debate on Reddit that they are not really in > North Korea and just doing some BGP trickery: And ICMP trickery, to send false ICMP replies (with a delay) to traceroute requests. I am certain they are not in North Korea. The TCP latency when you connect with HTTP to thepiratebay.se if < 40 ms, something which you cannot have from North Korea. From shortdudey123 at gmail.com Tue Mar 5 16:12:27 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 5 Mar 2013 10:12:27 -0600 Subject: "After Being Cut From Norway, The Pirate Bay Returns From North Korea" or is it just BGP Tricks In-Reply-To: <612qirv8teoolhaw1oer40my.1362499797082@email.android.com> References: <20130305155400.GA12368@nic.fr> <612qirv8teoolhaw1oer40my.1362499797082@email.android.com> Message-ID: It was a hoax http://www.pcworld.com/article/2030073/the-pirate-bay-admits-to-north-korean-hosting-hoax.html On Tue, Mar 5, 2013 at 10:10 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Seems easy enough to convince North Korea that they should announce my > prefixes... ;) > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Stephane Bortzmeyer > Date: 03/05/2013 10:55 AM (GMT-05:00) > To: Bacon Zombie > Cc: nanog at nanog.org > Subject: Re: "After Being Cut From Norway, The Pirate Bay Returns From > North Korea" or is it just BGP Tricks > > > On Mon, Mar 04, 2013 at 09:43:05PM +0000, > Bacon Zombie wrote > a message of 71 lines which said: > > > But there is a lot of debate on Reddit that they are not really in > > North Korea and just doing some BGP trickery: > > And ICMP trickery, to send false ICMP replies (with a delay) to > traceroute requests. > > I am certain they are not in North Korea. The TCP latency when you > connect with HTTP to thepiratebay.se if < 40 ms, something which you > cannot have from North Korea. > > > From mukom.tamon at gmail.com Tue Mar 5 17:55:14 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Tue, 5 Mar 2013 21:55:14 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? Message-ID: Dear experts, I've found myself thinking about what ground an engineer needs to cover in order to convince the executives to approve and commit to an IPv6 Deployment project. I think such a presentation (15 slides max in 45 minutes) should cover the following aspects: a) Set the strategic context: how your organisation derives value from IP networks and the Internet. b) Overview of the problem: IPv4 exhaustion c) Implications of IPv4 Exhaustion to your organization?s business model. d) Introduction of IPv6 as a solution to IPv4 exhaustion. e) Understanding the risks involved. f) How much will deploying IPv6 will cost. g) Call to action. I've detailed my thinking into each of these items at > My question and this is where I'd appreciate some input: a) To all you engineers out there who have convinced managers - what else did you have to address? b) To you who are managers, what else do you need your engineers to address in order for you to be convinced? Regards. As always, all opinions expressed are mine and do not necessarily represent the views of my employers, past or present. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From gem at rellim.com Tue Mar 5 18:35:44 2013 From: gem at rellim.com (Gary E. Miller) Date: Tue, 5 Mar 2013 10:35:44 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <20130305103544.77570b12.gem@rellim.com> Yo Mukom! On Tue, 5 Mar 2013 21:55:14 +0400 "Mukom Akong T." wrote: > I think such a presentation (15 slides max in 45 minutes) should > cover the following aspects: You missed the most important one. Many people now include IPv6 as a mandatory RFQ item. If you don't support it your customers will be fewer and fewer. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From cb.list6 at gmail.com Tue Mar 5 18:41:53 2013 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 5 Mar 2013 10:41:53 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: Hi, In-line On Tue, Mar 5, 2013 at 9:55 AM, Mukom Akong T. wrote: > Dear experts, > > I've found myself thinking about what ground an engineer needs to cover in > order to convince the executives to approve and commit to an IPv6 > Deployment project. > > I think such a presentation (15 slides max in 45 minutes) should cover the > following aspects: > > a) Set the strategic context: how your organisation derives value from IP > networks and the Internet. > > b) Overview of the problem: IPv4 exhaustion > > c) Implications of IPv4 Exhaustion to your organization?s business model. > > d) Introduction of IPv6 as a solution to IPv4 exhaustion. > > e) Understanding the risks involved. > > f) How much will deploying IPv6 will cost. > > g) Call to action. > > I've detailed my thinking into each of these items at to Executive Management ? Guidance for > Engineers >> > > My question and this is where I'd appreciate some input: > > a) To all you engineers out there who have convinced managers - what else > did you have to address? > One of the most important things i see not being stressed enough is that IPv6 is frequently free or a low-cost incremental upgrade. So, when calculating ROI / NPV, the hurdle can be very low such that the cash in-flow / cost savings is not a huge factor since the required investment is close to nil. This is not always the case, some legacy stuff won't work on ipv6 without investment. But, as a plug to all you folks who work at companies that use a CDN, please ask your CDN to turn IPv6 on for your website. This is top-of-mind for me since i just pushed my www folks on this issue Here's some relevant pointers for the CDN folks, in many cases its just a matter of clicking a button in the management portal: Akamai http://www.akamai.com/ipv6 Edgecast http://www.edgecast.com/ipv6/ Cloudflare https://www.cloudflare.com/ipv6 Amazon http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-securitygroups/ Softlayer http://www.softlayer.com/about/network/ipv6 > b) To you who are managers, what else do you need your engineers to address > in order for you to be convinced? > > Regards. > > As always, all opinions expressed are mine and do not necessarily represent > the views of my employers, past or present. > > -- > > Mukom Akong T. > > http://about.me/perfexcellence | twitter: @perfexcellent > ------------------------------------------------------------------------------------------------------------------------------------------ > ?When you work, you are the FLUTE through whose lungs the whispering of the > hours turns to MUSIC" - Kahlil Gibran > ------------------------------------------------------------------------------------------------------------------------------------------- > -- > > Mukom Akong T. > > http://about.me/perfexcellence | twitter: @perfexcellent > ------------------------------------------------------------------------------------------------------------------------------------------ > ?When you work, you are the FLUTE through whose lungs the whispering of the > hours turns to MUSIC" - Kahlil Gibran > ------------------------------------------------------------------------------------------------------------------------------------------- From patrick at ianai.net Tue Mar 5 18:47:17 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 5 Mar 2013 13:47:17 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <30F7C2B8-1B7F-4A8E-A99F-8F6185702581@ianai.net> On Mar 05, 2013, at 13:41 , Cameron Byrne wrote: > In-line Isn't every reply? (Well, every reply worth reading.) > On Tue, Mar 5, 2013 at 9:55 AM, Mukom Akong T. wrote: >> Dear experts, >> >> I've found myself thinking about what ground an engineer needs to cover in >> order to convince the executives to approve and commit to an IPv6 >> Deployment project. Why not just have them read their own SEC filings. Nearly every company has something to the effect of this in their 10K: The potential exhaustion of the supply of unallocated IPv4 addresses and the inability of $COMPANY and other Internet users to successfully transition to IPv6 could harm our operations and the functioning of the Internet as a whole. No company would lie to the SEC, would it? -- TTFN, patrick >> I think such a presentation (15 slides max in 45 minutes) should cover the >> following aspects: >> >> a) Set the strategic context: how your organisation derives value from IP >> networks and the Internet. >> >> b) Overview of the problem: IPv4 exhaustion >> >> c) Implications of IPv4 Exhaustion to your organization?s business model. >> >> d) Introduction of IPv6 as a solution to IPv4 exhaustion. >> >> e) Understanding the risks involved. >> >> f) How much will deploying IPv6 will cost. >> >> g) Call to action. >> >> I've detailed my thinking into each of these items at > to Executive Management ? Guidance for >> Engineers >>> >> >> My question and this is where I'd appreciate some input: >> >> a) To all you engineers out there who have convinced managers - what else >> did you have to address? >> > > One of the most important things i see not being stressed enough is > that IPv6 is frequently free or a low-cost incremental upgrade. > > So, when calculating ROI / NPV, the hurdle can be very low such that > the cash in-flow / cost savings is not a huge factor since the > required investment is close to nil. > > This is not always the case, some legacy stuff won't work on ipv6 > without investment. But, as a plug to all you folks who work at > companies that use a CDN, please ask your CDN to turn IPv6 on for your > website. This is top-of-mind for me since i just pushed my www folks > on this issue > > > Here's some relevant pointers for the CDN folks, in many cases its > just a matter of clicking a button in the management portal: > > Akamai http://www.akamai.com/ipv6 > > Edgecast http://www.edgecast.com/ipv6/ > > Cloudflare https://www.cloudflare.com/ipv6 > > Amazon http://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-securitygroups/ > > Softlayer http://www.softlayer.com/about/network/ipv6 > > >> b) To you who are managers, what else do you need your engineers to address >> in order for you to be convinced? >> >> Regards. >> >> As always, all opinions expressed are mine and do not necessarily represent >> the views of my employers, past or present. >> >> -- >> >> Mukom Akong T. >> >> http://about.me/perfexcellence | twitter: @perfexcellent >> ------------------------------------------------------------------------------------------------------------------------------------------ >> ?When you work, you are the FLUTE through whose lungs the whispering of the >> hours turns to MUSIC" - Kahlil Gibran >> ------------------------------------------------------------------------------------------------------------------------------------------- >> -- >> >> Mukom Akong T. >> >> http://about.me/perfexcellence | twitter: @perfexcellent >> ------------------------------------------------------------------------------------------------------------------------------------------ >> ?When you work, you are the FLUTE through whose lungs the whispering of the >> hours turns to MUSIC" - Kahlil Gibran >> ------------------------------------------------------------------------------------------------------------------------------------------- > From mukom.tamon at gmail.com Tue Mar 5 19:19:21 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Tue, 5 Mar 2013 23:19:21 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <20130305103544.77570b12.gem@rellim.com> References: <20130305103544.77570b12.gem@rellim.com> Message-ID: On Tue, Mar 5, 2013 at 10:35 PM, Gary E. Miller wrote: > You missed the most important one. Many people now include IPv6 as > a mandatory RFQ item. If you don't support it your customers will > be fewer and fewer. > I did mention it under the last but one paragraph of section [a]. Even though I only mentioned it for gov't contracts as I think those are the fat juicy ones. But yes, I do agree about the fact that non-compliance could mean you lose some business today. Regards -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From mukom.tamon at gmail.com Tue Mar 5 19:22:54 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Tue, 5 Mar 2013 23:22:54 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Tue, Mar 5, 2013 at 10:41 PM, Cameron Byrne wrote: > One of the most important things i see not being stressed enough is > that IPv6 is frequently free or a low-cost incremental upgrade. > > So, when calculating ROI / NPV, the hurdle can be very low such that > the cash in-flow / cost savings is not a huge factor since the > required investment is close to nil. > The low hurdle advantage remains only if the organisation starts soon and progresses incrementally. I suspect the longer v6 deployment is put off, the more this advantage is eroded. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From trejrco at gmail.com Tue Mar 5 19:31:05 2013 From: trejrco at gmail.com (TJ) Date: Tue, 5 Mar 2013 14:31:05 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: > > > The low hurdle advantage remains only if the organisation starts soon and > progresses incrementally. I suspect the longer v6 deployment is put off, > the more this advantage is eroded. Agreed; IMHO planning and starting sooner "costs less" than pushing it off until it is a firedrill. *Less in terms of money, service impact, PR complications, etc.* And it is "here" now - my home has native IPv6 from Comcast, my phones have native IPv6 from TMobile (and previously, from Verizon Wireless) ... the only missing link in my daily life is my client site, which is: a) why I am here and b) being held up by DISA :(. /TJ From Valdis.Kletnieks at vt.edu Tue Mar 5 19:55:33 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 05 Mar 2013 14:55:33 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: Your message of "Tue, 05 Mar 2013 21:55:14 +0400." References: Message-ID: <60861.1362513333@turing-police.cc.vt.edu> On Tue, 05 Mar 2013 21:55:14 +0400, "Mukom Akong T." said: > I've found myself thinking about what ground an engineer needs to cover in > order to convince the executives to approve and commit to an IPv6 > Deployment project. You forgot step 0 - figuring out why in 2013, you're talking to an executive about this in the first place. You're going to have to deal with the root cause reasons why the discussion was delayed before you have a snowball's chance of succeeding. The presentation you need to give if the execs don't understand what IPv4 exhaustion is will be different from the one they need if they understand that issue full well but don't see an ROI win from doing it this year and they want to push it off. > a) To all you engineers out there who have convinced managers - what else > did you have to address? Finding working code in 1998 was... interesting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Tue Mar 5 20:09:50 2013 From: bill at herrin.us (William Herrin) Date: Tue, 5 Mar 2013 15:09:50 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Tue, Mar 5, 2013 at 12:55 PM, Mukom Akong T. wrote: > I've found myself thinking about what ground an engineer needs to cover in > order to convince the executives to approve and commit to an IPv6 > Deployment project. > > I think such a presentation (15 slides max in 45 minutes) should cover the > following aspects: > > a) Set the strategic context: how your organisation derives value from IP > networks and the Internet. > > b) Overview of the problem: IPv4 exhaustion > > c) Implications of IPv4 Exhaustion to your organization?s business model. > > d) Introduction of IPv6 as a solution to IPv4 exhaustion. > > e) Understanding the risks involved. > > f) How much will deploying IPv6 will cost. > > g) Call to action. My experience has been that this model fail to _sell_ IPv6 to non-technical executives. Non-technical executives have 3 questions you must effectively answer: 1. What is the real dollar cost of doing the project (including both up-front and currently indefinite ongoing costs of dual stack. And don't forget to price out risk!). 2. What is the real dollar cost of not doing the project. (i.e. customers you expect to lose because you didn't do it. Don't suggest that IPv6 will allow you to avoid acquiring more IPv4. That's not yet true and if you say, "It will be in 5 years" the exec will respond, "great, come see me in 5 years.") 3. What is the opportunity cost of doing/not doing the project. Implicitly they'll also be looking for the answer to a fourth question: Do you know WTF you're talking about? If you assure them it's all peaches and cream with tiny costs and no opportunity cost, the answer is, "no." You get maybe 2 slides of summary on the technology and what it's for. If they want to know more, they'll ask. Everything else should focus on answering the above three questions. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From the.lists at mgm51.com Tue Mar 5 20:34:44 2013 From: the.lists at mgm51.com (Mike.) Date: Tue, 05 Mar 2013 15:34:44 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <201303051534440664.01900314@sentry.24cl.com> On 3/5/2013 at 9:55 PM Mukom Akong T. wrote: |Dear experts, | |I've found myself thinking about what ground an engineer needs to cover in |order to convince the executives to approve and commit to an IPv6 |Deployment project. | |I think such a presentation (15 slides max in 45 minutes) should cover the |following aspects: | |a) Set the strategic context: how your organisation derives value from IP |networks and the Internet. | |b) Overview of the problem: IPv4 exhaustion | |c) Implications of IPv4 Exhaustion to your organization???s business model. | |d) Introduction of IPv6 as a solution to IPv4 exhaustion. | |e) Understanding the risks involved. | |f) How much will deploying IPv6 will cost. | |g) Call to action. | |[snip] ============= Instead of f) How much will deploying IPv6 will cost. I would lean towards f) Cost/benefit of deploying IPv6. If you only talk about how much it will cost, then you've created a major uphill battle for yourself. Also talk of how IPv6 will benefit the business. From drais at icantclick.org Tue Mar 5 21:37:30 2013 From: drais at icantclick.org (david raistrick) Date: Tue, 5 Mar 2013 16:37:30 -0500 (EST) Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <30F7C2B8-1B7F-4A8E-A99F-8F6185702581@ianai.net> References: <30F7C2B8-1B7F-4A8E-A99F-8F6185702581@ianai.net> Message-ID: On Tue, 5 Mar 2013, Patrick W. Gilmore wrote: > Why not just have them read their own SEC filings. Nearly every company has something to the effect of this in their 10K: > The potential exhaustion of the supply of unallocated IPv4 addresses > and the inability of $COMPANY and other Internet users to successfully > transition to IPv6 could harm our operations and the functioning of > the Internet as a whole. ours doesn't..... at least not the may '12 AR -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From owen at delong.com Wed Mar 6 01:41:36 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Mar 2013 17:41:36 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> I think it's also important to cover the following topics somewhere in the process: 1. This will affect the entire organization, not just the IT department and will definitely impact all of apps, sysadmin, devops, operations, and networking teams within the IT department. 2. Training will be required for virtually all levels of the organization. End users won't need more than a ~2 hour introduction to what to look for during and after the upcoming changes. The IT department will need substantial training, covering a wide variety of topics (application changes (development, configuration, testing, management), systems administration changes, networking changes, etc.) 3. We've actually been through this before. In some cases more than once. e.g.: Novell -> TCP/IP Windows Networking -> TCP/IP Appletalk -> TCP/IP NCP -> TCP/IP In some ways, this change is less profound than many of those. It's also worth pointing out the ways you can save by starting sooner rather than later. Owen On Mar 5, 2013, at 9:55 AM, Mukom Akong T. wrote: > Dear experts, > > I've found myself thinking about what ground an engineer needs to cover in > order to convince the executives to approve and commit to an IPv6 > Deployment project. > > I think such a presentation (15 slides max in 45 minutes) should cover the > following aspects: > > a) Set the strategic context: how your organisation derives value from IP > networks and the Internet. > > b) Overview of the problem: IPv4 exhaustion > > c) Implications of IPv4 Exhaustion to your organization?s business model. > > d) Introduction of IPv6 as a solution to IPv4 exhaustion. > > e) Understanding the risks involved. > > f) How much will deploying IPv6 will cost. > > g) Call to action. > > I've detailed my thinking into each of these items at to Executive Management ? Guidance for > Engineers >> > > My question and this is where I'd appreciate some input: > > a) To all you engineers out there who have convinced managers - what else > did you have to address? > > b) To you who are managers, what else do you need your engineers to address > in order for you to be convinced? > > Regards. > > As always, all opinions expressed are mine and do not necessarily represent > the views of my employers, past or present. > > -- > > Mukom Akong T. > > http://about.me/perfexcellence | twitter: @perfexcellent > ------------------------------------------------------------------------------------------------------------------------------------------ > ?When you work, you are the FLUTE through whose lungs the whispering of the > hours turns to MUSIC" - Kahlil Gibran > ------------------------------------------------------------------------------------------------------------------------------------------- > -- > > Mukom Akong T. > > http://about.me/perfexcellence | twitter: @perfexcellent > ------------------------------------------------------------------------------------------------------------------------------------------ > ?When you work, you are the FLUTE through whose lungs the whispering of the > hours turns to MUSIC" - Kahlil Gibran > ------------------------------------------------------------------------------------------------------------------------------------------- From mukom.tamon at gmail.com Wed Mar 6 02:46:03 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Wed, 6 Mar 2013 06:46:03 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <201303051534440664.01900314@sentry.24cl.com> References: <201303051534440664.01900314@sentry.24cl.com> Message-ID: On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: > I would lean towards > > f) Cost/benefit of deploying IPv6. > I certainly agree, which is why I propose understanding you organisation's business model and how specifically v4 exhaustion will threaten that. IPv6 is the cast as a solution to that, plus future unknown benefits that may result from e-2-e and NAT elimination. I have no clue how to sell 'benefit' of IPv6 in isolation as right now even for engineers, there's not much of a benefit except more address space. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From cb.list6 at gmail.com Wed Mar 6 02:55:15 2013 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 5 Mar 2013 18:55:15 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> Message-ID: On Tue, Mar 5, 2013 at 6:46 PM, Mukom Akong T. wrote: > On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: > >> I would lean towards >> >> f) Cost/benefit of deploying IPv6. >> > > I certainly agree, which is why I propose understanding you organisation's > business model and how specifically v4 exhaustion will threaten that. IPv6 > is the cast as a solution to that, plus future unknown benefits that may > result from e-2-e and NAT elimination. > > I have no clue how to sell 'benefit' of IPv6 in isolation as right now even > for engineers, there's not much of a benefit except more address space. > > That is really the meat of it, more addresses is the killer IPv6 app. If you have plenty of ipv4, your situation is not very urgent, but one day it will be urgent.... There are folks who don't have much IPv4, and sometimes people on your network may want to communicate with them.. Like the folks in Europe or Asia. Remember, APNIC and RIPE are both out of IPv4 right now. So all meaningful growth (mobile, cloud, internet of things...) must happen on IPv6 ... or relatively expensive IPv4 addresses from the black market and / or NATs CB > -- > > Mukom Akong T. > > http://about.me/perfexcellence | twitter: @perfexcellent > ------------------------------------------------------------------------------------------------------------------------------------------ > ?When you work, you are the FLUTE through whose lungs the whispering of the > hours turns to MUSIC" - Kahlil Gibran > ------------------------------------------------------------------------------------------------------------------------------------------- From v.jones at networkingunlimited.com Wed Mar 6 02:56:03 2013 From: v.jones at networkingunlimited.com (Vincent C Jones) Date: Tue, 05 Mar 2013 21:56:03 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> References: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> Message-ID: <1362538563.5382.36.camel@X61.NetworkingUnlimited.com> On Tue, 2013-03-05 at 17:41 -0800, Owen DeLong wrote: > 3. We've actually been through this before. In some cases more than once. > e.g.: > Novell -> TCP/IP > Windows Networking -> TCP/IP > Appletalk -> TCP/IP > NCP -> TCP/IP > > In some ways, this change is less profound than many of those. Lest we forget one of the more profound ones whose memory could be the source of much resistance. Assuming this industry had any memory... TCP/IP -> MAP/TOP/GOSIP -> TCP/IP Complete with government mandates, dual stacking, and RFP inclusion. Been there, done that, been burnt... Vincent Jones From owen at delong.com Wed Mar 6 03:15:20 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Mar 2013 19:15:20 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> Message-ID: <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. wrote: > On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: > >> I would lean towards >> >> f) Cost/benefit of deploying IPv6. >> > > I certainly agree, which is why I propose understanding you organisation's > business model and how specifically v4 exhaustion will threaten that. IPv6 > is the cast as a solution to that, plus future unknown benefits that may > result from e-2-e and NAT elimination. > > I have no clue how to sell 'benefit' of IPv6 in isolation as right now even > for engineers, there's not much of a benefit except more address space. I'm not so sure about that? Admittedly, most of these are too technical to be suitable for management consumption, but: 1. Decreased application complexity: Because we will be able to get rid of all that NAT traversal code, we get the following benefits: I. Improved security A. Fewer code paths to test B. Lower complexity = less opportunity to introduce flaws II. Lower cost A. Less developer man hours maintaining (or developing) NAT traversal code B. Less QA time spent testing NAT traversal code C. No longer need to keep the lab stocked with every NAT implementation ever invented D. Fewer calls to support for failures in product's NAT traversal code 2. Increased transparency: Because addressing is now end-to-end transparent, we gain a number of benefits: I. Improved Security A. Harder for attackers to hide in anonymous address space. B. Easier to track down spoofing C. Simplified log correlation D. Easier to identify source/target of attacks II. Simplified troubleshooting A. No more need to include state table dumps in troubleshooting B. tcpdump inside and tcpdump outside contain the same packets. Finally? There are 7 billion people on the planet. There are 2 billion currently on the internet. The other 5 billion won't fit in IPv4. If you want to talk to them, you'll need IPv6. It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years. Today, the IPv6 internet is this big: . Today, the IPv4 internet is this big: o In a few years, the IPv4 internet will still be this big: o and the IPv6 internet will be more like this: OOOOO (Size comparison should be relatively accurate at any font size as long as you use the same font and font size for the whole thing.) Owen From mukom.tamon at gmail.com Wed Mar 6 03:23:07 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Wed, 6 Mar 2013 07:23:07 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> References: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> Message-ID: Hello Owen, Would I be accurate in re-phrasing each of these as.... On Wed, Mar 6, 2013 at 5:41 AM, Owen DeLong wrote: > 1. This will affect the entire organization, not just the IT > department and > will definitely impact all of apps, sysadmin, devops, operations, > and > networking teams within the IT department. > "The scope of the IPv6 endeavour is organisation-wide" so as to mitigate any internal disconnects that will result from other units perceiving this as an 'IT department's project?. I would specifically like to at some point later bring in the marketing and sales folks. They can't pitch it correctly if they don't understand it can they? > > 2. Training will be required for virtually all levels of the > organization. End users > won't need more than a ~2 hour introduction to what to look for > during and > after the upcoming changes. The IT department will need > substantial training, > covering a wide variety of topics (application changes > (development, configuration, > testing, management), systems administration changes, networking > changes, etc.) > +1 > > 3. We've actually been through this before. In some cases more than > once. > e.g.: > Novell -> TCP/IP > Windows Networking -> TCP/IP > Appletalk -> TCP/IP > NCP -> TCP/IP > I totally didn't think of this perspective ... this is really assuring. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From matthew at matthew.at Wed Mar 6 03:55:24 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 05 Mar 2013 19:55:24 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> Message-ID: <5136BE2C.3060804@matthew.at> On 3/5/2013 7:15 PM, Owen DeLong wrote: > On Mar 5, 2013, at 6:46 PM, Mukom Akong T. wrote: > >> On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: >> >>> I would lean towards >>> >>> f) Cost/benefit of deploying IPv6. >>> >> I certainly agree, which is why I propose understanding you organisation's >> business model and how specifically v4 exhaustion will threaten that. IPv6 >> is the cast as a solution to that, plus future unknown benefits that may >> result from e-2-e and NAT elimination. >> >> I have no clue how to sell 'benefit' of IPv6 in isolation as right now even >> for engineers, there's not much of a benefit except more address space. > I'm not so sure about that? > > Admittedly, most of these are too technical to be suitable for management consumption, but: > > 1. Decreased application complexity: Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then... > Because we will be able to get rid of all that NAT traversal code, > we get the following benefits: No, we keep the NAT traversal code. > > I. Improved security > A. Fewer code paths to test And now we have to test end-to-end IPv4-IPv4 (with and without NAT), IPv4-IPv6 through relays, IPv4-IPv6 in the presence of NAT64, IPv6-IPv6, at the very least. > B. Lower complexity = less opportunity to introduce flaws See above. > II. Lower cost > A. Less developer man hours maintaining (or developing) NAT traversal code Nope. All the same man-hours plus all the NAT64/DNS64 cases need to be covered, plus any other transition technologies that get popular (DS-Lite, 6RD, etc.) and screw with NAT traversal *plus* all the extra work required to operate in certain CGN environments which may become even more common than IPv6 in some place. > B. Less QA time spent testing NAT traversal code See above about all the interworking cases. > C. No longer need to keep the lab stocked with every NAT implementation ever invented Nope, now you also need to buy all the much more expensive gear to test CGN, NAT64, DS-Lite, 6RD, and any number of other transition/customer deployment models. > D. Fewer calls to support for failures in product's NAT traversal code Doubt it. > 2. Increased transparency: > Because addressing is now end-to-end transparent, we gain a > number of benefits: Assuming NAT66 isn't mandated in some environments for "security"... but even so, none of these benefits apply in the customer NAT, CGN, or NAT64 cases. > > I. Improved Security > A. Harder for attackers to hide in anonymous address space. What?!? It is much easier for attackers to rotate addresses when IPv6 is widely available. > B. Easier to track down spoofing Don't see how. (See below). (Never mind that BCP38 should have prevented this long ago) > C. Simplified log correlation Yes, if only you didn't also have to do it for all the CGN and NAT64 cases. > D. Easier to identify source/target of attacks Again, I doubt it. Identifying the single IP address assigned to a customer who has an on-premise NAT appears to be just as easy/hard as identifying the block of IP addresses assigned to a customer running IPv6. And for privacy reasons, end-user hosts won't have stable addresses within that block any more than port numbers are stable on the outside of a NAT in the IPv4 case. > II. Simplified troubleshooting > A. No more need to include state table dumps in troubleshooting Not true. Lots of failure cases will still involve firewall configuration... tracking down the "my SIP phone registers but RTP doesn't work but only when I receive calls, not when I send calls" is identical in the IPv4 and IPv6 stateful firewall cases. > B. tcpdump inside and tcpdump outside contain the same packets. Unless you have almost any firewall, which will be adjusting all sorts of things for you. > Finally? There are 7 billion people on the planet. There are 2 billion currently on the internet. > > The other 5 billion won't fit in IPv4. If you want to talk to them, you'll need IPv6. Or a very big CGN. > > It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years. This is the actual argument. IPv6 must be supported because as the Internet grows, it will get to the point where some of it MUST be IPv6-only. Unfortunately there will be a long time in the interim where you need to do more than 2x the work you are doing now in the IPv4+end-user-NAT Internet we currently have. Trying to sell this to smart engineers writing code or testing it as "less work" is just going to get you laughed out of the room as the crazy IPv6 zealot. Matthew Kaufman From johnl at iecc.com Wed Mar 6 04:25:44 2013 From: johnl at iecc.com (John Levine) Date: 6 Mar 2013 04:25:44 -0000 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: Message-ID: <20130306042544.7958.qmail@joyce.lan> The benefits, if any, of supporting IPv6 now really depend on what kind of use your organization makes of the Internet. Despite all of the huffing and puffing, it will be a very long time before there are interesting bits of the net not visible over IPv4 for common applications like http and smtp. No matter how much NAT sucks in theory, for most non-technical users it's invisible and they have no reason to care. At this point, I'd say the mail selling point is that there are an increasing number of home users and particularly mobile users with native connections only in v6. If you're running services of interest to those users, you'll get better visibility about who they are over v6. Failing that, from a business point of view it's mostly handwaving and I wouldn't spend a lot of time trying to persuade them that there are practical advantages of adding v6 to an existing working v4 network. R's, John From owen at delong.com Wed Mar 6 04:20:52 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Mar 2013 20:20:52 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <5136BE2C.3060804@matthew.at> References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> Message-ID: On Mar 5, 2013, at 7:55 PM, Matthew Kaufman wrote: > On 3/5/2013 7:15 PM, Owen DeLong wrote: >> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. wrote: >> >>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: >>> >>>> I would lean towards >>>> >>>> f) Cost/benefit of deploying IPv6. >>>> >>> I certainly agree, which is why I propose understanding you organisation's >>> business model and how specifically v4 exhaustion will threaten that. IPv6 >>> is the cast as a solution to that, plus future unknown benefits that may >>> result from e-2-e and NAT elimination. >>> >>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now even >>> for engineers, there's not much of a benefit except more address space. >> I'm not so sure about that? >> >> Admittedly, most of these are too technical to be suitable for management consumption, but: >> >> 1. Decreased application complexity: > > Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then? > I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: 1. IPv6 deployment continues to accelerate and achieves relative ubiquity before IPv4 becomes completely unsustainable. In this case, IPv4 will be gracefully, but rapidly decommissioned because of the extreme costs involved in keeping it running vs. the limited benefit of doing so. Sure, there will be isolated pockets of IPv4 for a very long time, but application developers will stop supporting IPv4 NAT traversal in new products or new product updates fairly soon after this point. In this case, we're probably looking at around 5 years. or 2. IPv6 deployment doesn't reach relative ubiquity before IPv4 becomes utterly unsustainable. We scramble to simultaneously shore up IPv4 as best we can will deploying IPv6 in a complete panic. There is widespread disruption, costs are high, reliability is low for several years, pretty much the worst case scenario. In this case, it's probably about 8 years before we completely splatter against the wall with IPv4 and another 2 years of scrambling to deploy the rest of IPv6. >> Because we will be able to get rid of all that NAT traversal code, >> we get the following benefits: > > No, we keep the NAT traversal code. > Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice. >> >> I. Improved security >> A. Fewer code paths to test > > And now we have to test end-to-end IPv4-IPv4 (with and without NAT), IPv4-IPv6 through relays, IPv4-IPv6 in the presence of NAT64, IPv6-IPv6, at the very least. Only for a couple of years. Once IPv4 disappears from the inter domain world, which will happen fairly quickly, I think you'll see little or no focus on these areas and support for most of them will be mothballed. > >> B. Lower complexity = less opportunity to introduce flaws > > See above. See above debunking of the flawed assumptions. > >> II. Lower cost >> A. Less developer man hours maintaining (or developing) NAT traversal code > > Nope. All the same man-hours plus all the NAT64/DNS64 cases need to be covered, plus any other transition technologies that get popular (DS-Lite, 6RD, etc.) and screw with NAT traversal *plus* all the extra work required to operate in certain CGN environments which may become even more common than IPv6 in some place. Nope? Maybe for a very short period of time, but precisely because IPv4 no longer provides benefit, only cost at this point, it will be rapidly decommissioned at least from the inter-domain world. In the intra-domain world, NAT traversal is mostly not relevant. Almost certainly not relevant enough to garner continuing support from ISVs. > >> B. Less QA time spent testing NAT traversal code > > See above about all the interworking cases. See above about why nobody is actually going to be that dumb. > >> C. No longer need to keep the lab stocked with every NAT implementation ever invented > > Nope, now you also need to buy all the much more expensive gear to test CGN, NAT64, DS-Lite, 6RD, and any number of other transition/customer deployment models. Nope? See above. > >> D. Fewer calls to support for failures in product's NAT traversal code > > Doubt it. Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: C: "Hi, my application isn't working through my NAT." TSR: "Hi? Get IPv6, we don't support NAT any more." TSR: "Is there anything else I can help you with today?" > >> 2. Increased transparency: >> Because addressing is now end-to-end transparent, we gain a >> number of benefits: > > Assuming NAT66 isn't mandated in some environments for "security"... but even so, none of these benefits apply in the customer NAT, CGN, or NAT64 cases. Even if it is, at this point, I doubt it will be a sufficient critical mass of environments to drive ISVs to provide special support for it. As such, those few institutions will probably change fairly quickly. The customer NAT, CGN, and NAT64 cases are not likely to exist by then. See above. > >> >> I. Improved Security >> A. Harder for attackers to hide in anonymous address space. > > What?!? It is much easier for attackers to rotate addresses when IPv6 is widely available. Yes, but their prefix isn't anonymous and they have a hard time getting outside of the prefix. > >> B. Easier to track down spoofing > > Don't see how. (See below). (Never mind that BCP38 should have prevented this long ago) 1. You don't have to compare 701 against 9,000,000 prefixes in the routing table looking for the one that's getting spoofed. 2. RIR records will be more accurate because there is no legacy space. > >> C. Simplified log correlation > > Yes, if only you didn't also have to do it for all the CGN and NAT64 cases. Which won't last long. > >> D. Easier to identify source/target of attacks > > Again, I doubt it. Identifying the single IP address assigned to a customer who has an on-premise NAT appears to be just as easy/hard as identifying the block of IP addresses assigned to a customer running IPv6. And for privacy reasons, end-user hosts won't have stable addresses within that block any more than port numbers are stable on the outside of a NAT in the IPv4 case. NAT will most likely become a thing of the past. I know you prefer to remain in denial about this, but more and more of the ISVs I have talked to are saying that they have no intention of adding NAT traversal to their IPv6 code. > >> II. Simplified troubleshooting >> A. No more need to include state table dumps in troubleshooting > > Not true. Lots of failure cases will still involve firewall configuration... tracking down the "my SIP phone registers but RTP doesn't work but only when I receive calls, not when I send calls" is identical in the IPv4 and IPv6 stateful firewall cases. Sure? I meant that you don't need to dump the state table to identify that the packet from 192.0.2.123:1234 to 204.81.221.6:80 is the same packet as the one on the inside from 192.168.5.6:9321 to 204.81.221.6:80. > >> B. tcpdump inside and tcpdump outside contain the same packets. > > Unless you have almost any firewall, which will be adjusting all sorts of things for you. The firewall shouldn't be adjusting the packet. I'm not sure why you think it would or what adjustments you think it would be making. > >> Finally? There are 7 billion people on the planet. There are 2 billion currently on the internet. >> >> The other 5 billion won't fit in IPv4. If you want to talk to them, you'll need IPv6. > > Or a very big CGN. If you think this will actually scale and provide a user experience that will be considered at all acceptable, then you are delusional. > >> >> It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years. > > This is the actual argument. IPv6 must be supported because as the Internet grows, it will get to the point where some of it MUST be IPv6-only. Unfortunately there will be a long time in the interim where you need to do more than 2x the work you are doing now in the IPv4+end-user-NAT Internet we currently have. I don't think that's actually true. I think that the economic incentives to drop IPv4 support from the inter domain world as soon as possible will apply strong pressure to expedite this process once IPv6 achieves a certain level of critical mass. > Trying to sell this to smart engineers writing code or testing it as "less work" is just going to get you laughed out of the room as the crazy IPv6 zealot. Actually, smart engineers realize that in the long run it's a lot less work. That there's a brief period where it's way more work followed by a much better long-term. I'll leave off the obvious question about how smart can engineers be if they built an application in the 90s that was as strongly tied to unistack as Skype is when it was obvious that unistack IPv4 was a very temporary phenomenon. Owen From mukom.tamon at gmail.com Wed Mar 6 04:49:53 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Wed, 6 Mar 2013 08:49:53 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: Hello William, Thank you for your inputs, see my comments inline. On Wed, Mar 6, 2013 at 12:09 AM, William Herrin wrote: > > > > > a) Set the strategic context: how your organisation derives value from IP > > networks and the Internet. > > > > b) Overview of the problem: IPv4 exhaustion > > > > c) Implications of IPv4 Exhaustion to your organization?s business model. > > > > d) Introduction of IPv6 as a solution to IPv4 exhaustion. > > > > e) Understanding the risks involved. > > > > f) How much will deploying IPv6 will cost. > > > > g) Call to action. > > My experience has been that this model fail to _sell_ IPv6 to > non-technical executives. Non-technical executives have 3 questions > you must effectively answer: > And the model does explicitly address all three concerns (note I only posted an outline ... the post (How to ?Sell? IPv6 to Executive Management ? Guidance for Engineers) gives more detail) > 1. What is the real dollar cost of doing the project (including both > up-front and currently indefinite ongoing costs of dual stack. And > don't forget to price out risk!). > Now in the post, I mention cost elements. At a point when you are still trying to convince execs about v6, is it possible to have an accurate value for this cost. Wouldn't cost elements and ball-park amounts be sufficient? Please could you shed some more light on 'Pricing out Risk'? any tools and techniques to do that would be highly appreciated. > > 2. What is the real dollar cost of not doing the project. (i.e. > customers you expect to lose because you didn't do it. Don't suggest > that IPv6 will allow you to avoid acquiring more IPv4. That's not yet > true and if you say, "It will be in 5 years" the exec will respond, > "great, come see me in 5 years.") > IPv6 has elements of a disruptive technology (right now it really only addresses the needs of a fringe segment of the market and also is perceived as worse with respect to feature set). The inherent problem with such technologies is that no one knows the real dollar cost of NOT taking action (when concrete data becomes available to support that, it would mean it has already seen market success and so if you still don't have it, you'd be too late.) However, in terms of cost (and risk) of inaction - it really will depend on how your organisation derrives value from the Internet and could run from stalled growth in client and revenue base, inability to retain clients and possible unknown adjacent opportunities that will be enabled by IPv6. > 3. What is the opportunity cost of doing/not doing the project. > > Implicitly they'll also be looking for the answer to a fourth > question: Do you know WTF you're talking about? If you assure them > it's all peaches and cream with tiny costs and no opportunity cost, > the answer is, "no." > I believe if anyone who can phrase the "IPv4 Exhaustion Problem + IPv6 Solution" in very specific terms of the business model of the company will implicitly inspire confidence in execs that they know what they are talking about. > > You get maybe 2 slides of summary on the technology and what it's for. > If they want to know more, they'll ask. Everything else should focus > on answering the above three questions. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From mukom.tamon at gmail.com Wed Mar 6 04:52:20 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Wed, 6 Mar 2013 08:52:20 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: Hello all, I forgot to include a link to the post that details the framework I initially suggested. It's at http://techxcellence.net/2013/03/05/v6-business-case-for-engineers/ Regards From matthew at matthew.at Wed Mar 6 06:29:19 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 05 Mar 2013 22:29:19 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> Message-ID: <5136E23F.3060400@matthew.at> On 3/5/2013 8:20 PM, Owen DeLong wrote: > On Mar 5, 2013, at 7:55 PM, Matthew Kaufman wrote: > >> On 3/5/2013 7:15 PM, Owen DeLong wrote: >>> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. wrote: >>> >>>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: >>>> >>>>> I would lean towards >>>>> >>>>> f) Cost/benefit of deploying IPv6. >>>>> >>>> I certainly agree, which is why I propose understanding you organisation's >>>> business model and how specifically v4 exhaustion will threaten that. IPv6 >>>> is the cast as a solution to that, plus future unknown benefits that may >>>> result from e-2-e and NAT elimination. >>>> >>>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now even >>>> for engineers, there's not much of a benefit except more address space. >>> I'm not so sure about that? >>> >>> Admittedly, most of these are too technical to be suitable for management consumption, but: >>> >>> 1. Decreased application complexity: >> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then? >> > I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: Two unsubstantiated suppositions deleted. They suggest that IPv4 support is needed *in conjunction with* IPv6 support for 5-8 years. That's a long time if you're developing software... so, basically, no... no cost or effort saving if you were to do this work today. In fact, >2x the effort if you were to start today. So again, why try to sell it to the engineers that way? Either sell it as 1) If you don't start doing a lot more work now you'll be screwed at the transition or 2) You should just wait until you can single-stack on IPv6. > Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice. Sure. In 5 to 8 years, as you claimed. > > Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: > > C: "Hi, my application isn't working through my NAT." > TSR: "Hi? Get IPv6, we don't support NAT any more." > TSR: "Is there anything else I can help you with today?" C: "Hi, my application isn't working between me and my grandmother" TSR: "Hi... Get IPv6, we don't suppotr NAT any more." C: "Screw you guys... my grandmother isn't served by an ISP that is offering IPv6 and her old operating system barely supports it anyway. Please refund my money." The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away. For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares. > > NAT will most likely become a thing of the past. I know you prefer to remain in denial about this, but more and more of the ISVs I have talked to are saying that they have no intention of adding NAT traversal to their IPv6 code. I'm not in denial about this. I just don't think IPv4 is going away in the next 30-60 days... and so my next one to two releases, which is what I'm engineering for this week, need to support it, and NAT traversal, and all that. It'd be nice if they supported IPv6 as well, but really when you rank on a big list all the things customers are demanding, IPv6 is *way* down that list. > The firewall shouldn't be adjusting the packet. I'm not sure why you think it would or what adjustments you think it would be making. Option stripping, Diffserv scrubbing, all sorts of things that make the packets no longer identical. > >>> Finally? There are 7 billion people on the planet. There are 2 billion currently on the internet. >>> >>> The other 5 billion won't fit in IPv4. If you want to talk to them, you'll need IPv6. >> Or a very big CGN. > If you think this will actually scale and provide a user experience that will be considered at all acceptable, then you are delusional. For most web and web-service based applications, it'll work just fine. In the "long run", sure, it runs out of steam... but I'm already talking about times way sooner than your 5-8 years. > >> > I don't think that's actually true. I think that the economic incentives to drop IPv4 support from the inter domain world as soon as possible will apply strong pressure to expedite this process once IPv6 achieves a certain level of critical mass. Yes... and will that "certain level of critical mass" happen before the end of this June? If not, all it means is extra work, not less. > >> Trying to sell this to smart engineers writing code or testing it as "less work" is just going to get you laughed out of the room as the crazy IPv6 zealot. > Actually, smart engineers realize that in the long run it's a lot less work. Yes. In "the long run"... which is way farther out than the backlog for the current sprint or even release, I'm afraid. > That there's a brief period where it's way more work followed by a much better long-term. That "brief period" lasts longer than most software startups are in existence. Your shortest prediction was 5 years... an eternity, still. So right now, today, when you take the powerpoint deck to the engineers, you are asking them to do >2x the work, starting now, for some unknown future benefit... likely after they are either 1) working somewhere else or 2) the entire operation has been acquired by someone else. > I'll leave off the obvious question about how smart can engineers be if they built an application in the 90s that was as strongly tied to unistack as Skype is when it was obvious that unistack IPv4 was a very temporary phenomenon. Well maybe it wasn't that obvious in Estonia in the early 1990s. When I wrote my P2P stack in the same era, it supported both IPv4 and IPv6, and a version of that is what is in every copy of Flash Player. Working *and tested* to support IPv6. Matthew Kaufman From maz at iij.ad.jp Wed Mar 6 08:59:54 2013 From: maz at iij.ad.jp (Matsuzaki Yoshinobu) Date: Wed, 06 Mar 2013 17:59:54 +0900 (JST) Subject: Dreamhost/AS26347 unauthorized bgp announcement Message-ID: <20130306.175954.55308686.maz@iij.ad.jp> According to RIPE RIS, AS26347 announced a bunch of prefixes again. - http://www.ris.ripe.net/dashboard/26347 First suspicious announcement was started 2013-03-06 07:52:40 UTC, and last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. It seems these unauthorized announcements have the same profile as before - AS26347 shrinks the prefix lenght of their received prefix somehow upto /20, and re-originates the prefix with origin AS26347. Any known bugs? Regards, ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From job.snijders at atrato.com Wed Mar 6 09:03:32 2013 From: job.snijders at atrato.com (Job Snijders) Date: Wed, 6 Mar 2013 10:03:32 +0100 Subject: Dreamhost/AS26347 unauthorized bgp announcement In-Reply-To: <20130306.175954.55308686.maz@iij.ad.jp> References: <20130306.175954.55308686.maz@iij.ad.jp> Message-ID: <9D1C36A1-ACBA-4801-858A-44CFC3184223@atrato.com> Hi Mat, I see the same thing, we learn the prefix from the route-server in LAX: telnet at r1.lax1.us>show ip bgp routes detail 90.201.80.0/20 Number of BGP Routes matching display condition : 1 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH S:SUPPRESSED F:FILTERED s:STALE 1 Prefix: 90.201.80.0/20, Status: BE, Age: 0h22m15s NEXT_HOP: 206.223.143.83, Metric: 0, Learned from Peer: 206.223.143.253 (19996) LOCAL_PREF: 400, MED: none, ORIGIN: incomplete, Weight: 0 AS_PATH: 26347 COMMUNITIES: 5580:12431 Adj_RIB_out count: 18, Admin distance 20 Last update to IP routing table: 0h22m15s, 1 path(s) installed: Kind regards, Job On Mar 6, 2013, at 9:59 AM, Matsuzaki Yoshinobu wrote: > According to RIPE RIS, AS26347 announced a bunch of prefixes again. > - http://www.ris.ripe.net/dashboard/26347 > > First suspicious announcement was started 2013-03-06 07:52:40 UTC, and > last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. > > It seems these unauthorized announcements have the same profile as > before - AS26347 shrinks the prefix lenght of their received prefix > somehow upto /20, and re-originates the prefix with origin AS26347. > > Any known bugs? > > Regards, > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 > -- AS5580 - Atrato IP Networks From jcurran at istaff.org Wed Mar 6 09:24:04 2013 From: jcurran at istaff.org (John Curran) Date: Wed, 6 Mar 2013 04:24:04 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> Message-ID: <171D7F35-9BEC-4F53-A5BD-53DD03A7D19C@istaff.org> On Mar 5, 2013, at 9:55 PM, Cameron Byrne wrote: > So all meaningful growth (mobile, cloud, internet of things...) must happen on IPv6 ... > or relatively expensive IPv4 addresses from the black market and / or NATs Cameron - I agree with the intent, but just for clarity, I'd like to ask what you mean by "the black market"? I see two possibilities, one being that the current IPv4 address transfer regime is viewed as "illegitimate' (which would be the typical use of the term 'black market'); or secondly, that the current IPv4 transfer system is fine but likely won't meet one's requirements for growth and hence may require turning to transfers "outside the system", i.e. truly to an underground black market... I can see reasons to assert either view, but figured other folks might also be wondering which of these two potential points you are making... :-) Thanks! /John From owen at delong.com Wed Mar 6 10:16:03 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Mar 2013 02:16:03 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <5136E23F.3060400@matthew.at> References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> <5136E23F.3060400@matthew.at> Message-ID: <439595BB-8B53-4ACC-A3EE-64E393189CF4@delong.com> >> Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short: >> >> C: "Hi, my application isn't working through my NAT." >> TSR: "Hi? Get IPv6, we don't support NAT any more." >> TSR: "Is there anything else I can help you with today?" > > C: "Hi, my application isn't working between me and my grandmother" > TSR: "Hi... Get IPv6, we don't suppotr NAT any more." > C: "Screw you guys... my grandmother isn't served by an ISP that is offering IPv6 and her old operating system barely supports it anyway. Please refund my money." > Point is that Grandma's ISP will support IPv6 by the time this comes to pass, or, Grandma will be 1/10,000 and the ISV will either cheerfully refund the price of the application in those limited circumstances, or, say "I'm sorry, we don't offer refunds. You're welcome to continue using the old version which includes NAT traversal." In either case, there are some customers that it's just too expensive to maintain vs. what you get from them. Once IPv4 ceases to be the internet lingua franca, the ones clinging to it will rapidly fall into that category. > The point being that for some applications, *both ends* need to be on IPv6 before any of this complexity can go away. Point being that once a sufficient set of end points is on IPv6 that the market share lost by not supporting IPv4 and/or IPv4 NAT traversal will stop getting supported. Just like many developers don't support the 10+% of us that use Macs, the 5% or less that don't have IPv6 in a few years will fall off the supportability list. > For the rest, they're just talking to web services... and until the places those are hosted run out of IPv4 addresses, nobody cares. I don't think this is anywhere near as large a userbase as you think these days. >> NAT will most likely become a thing of the past. I know you prefer to remain in denial about this, but more and more of the ISVs I have talked to are saying that they have no intention of adding NAT traversal to their IPv6 code. > > I'm not in denial about this. I just don't think IPv4 is going away in the next 30-60 days... and so my next one to two releases, which is what I'm engineering for this week, need to support it, and NAT traversal, and all that. > It'd be nice if they supported IPv6 as well, but really when you rank on a big list all the things customers are demanding, IPv6 is *way* down that list. If you're not looking past 60 days, then we're not having the same conversation. What will exist in the next 30-60 days is already determined, so any discussion of positive change to that situation is pretty much irrelevant as it can't possibly come to fruition. >> The firewall shouldn't be adjusting the packet. I'm not sure why you think it would or what adjustments you think it would be making. > > Option stripping, Diffserv scrubbing, all sorts of things that make the packets no longer identical. Perhaps I should have said "identical enough to be readily recognizable using the same tcpdump filter string." As long as they don't change the IP addresses or the port numbers, that's pretty much the case. Mucking with the other things is undesirable, but not fatal. >>>> Finally? There are 7 billion people on the planet. There are 2 billion currently on the internet. >>>> >>>> The other 5 billion won't fit in IPv4. If you want to talk to them, you'll need IPv6. >>> Or a very big CGN. >> If you think this will actually scale and provide a user experience that will be considered at all acceptable, then you are delusional. > > For most web and web-service based applications, it'll work just fine. Which is about 60% of modern internet traffic. The remaining 40%... > In the "long run", sure, it runs out of steam... but I'm already talking about times way sooner than your 5-8 years. I think you will be surprised how fast it runs out of steam even for web services. On any sort of a large customer-base scale, it very quickly becomes a maintenance and support nightmare. >> I don't think that's actually true. I think that the economic incentives to drop IPv4 support from the inter domain world as soon as possible will apply strong pressure to expedite this process once IPv6 achieves a certain level of critical mass. > > Yes... and will that "certain level of critical mass" happen before the end of this June? If not, all it means is extra work, not less. Granted, it's much more work at first and a little work as long as IPv4 maintenance is required. If your application was stupidly designed such that it's unnecessarily difficult to add dual-stack support, then it's even worse. However, you're having a 60 day conversation while I'm talking about considerations applicable to something on an enterprise-roll-out time table (most likely closer to 24 months than 2 and probably 12-18 months of preparation before the roll-out starts in earnest). > >> >>> Trying to sell this to smart engineers writing code or testing it as "less work" is just going to get you laughed out of the room as the crazy IPv6 zealot. >> Actually, smart engineers realize that in the long run it's a lot less work. > > Yes. In "the long run"... which is way farther out than the backlog for the current sprint or even release, I'm afraid. 1. You're talking development, I'm talking enterprise. 2. You're talking immediate action, I'm talking enterprise rollout timescales. >> That there's a brief period where it's way more work followed by a much better long-term. > > That "brief period" lasts longer than most software startups are in existence. Your shortest prediction was 5 years... an eternity, still. So right now, today, when you take the powerpoint deck to the engineers, you are asking them to do >2x the work, starting now, for some unknown future benefit... likely after they are either 1) working somewhere else or 2) the entire operation has been acquired by someone else. 5 years from now. Given the speed with which the average enterprise moves on an undertaking like this, that's probably not much more than 12 months after they deliver IPv6 to the desktop. > >> I'll leave off the obvious question about how smart can engineers be if they built an application in the 90s that was as strongly tied to unistack as Skype is when it was obvious that unistack IPv4 was a very temporary phenomenon. > > Well maybe it wasn't that obvious in Estonia in the early 1990s. When I wrote my P2P stack in the same era, it supported both IPv4 and IPv6, and a version of that is what is in every copy of Flash Player. Working *and tested* to support IPv6. If you were on the internet, it's hard to imagine how you missed the fact that we knew we were going to run out of IPv4 addresses fairly quickly back then. If you learned enough about NAT to know about doing NAT traversal, odds are pretty good that you knew that address exhaustion was driving NAT and that IPv6 was the longer term solution while NAT was a hack to get us by until then, > > Matthew Kaufman From drew.weaver at thenap.com Wed Mar 6 13:43:35 2013 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 6 Mar 2013 08:43:35 -0500 Subject: Dreamhost/AS26347 unauthorized bgp announcement In-Reply-To: <9D1C36A1-ACBA-4801-858A-44CFC3184223@atrato.com> References: <20130306.175954.55308686.maz@iij.ad.jp> <9D1C36A1-ACBA-4801-858A-44CFC3184223@atrato.com> Message-ID: They're doing this to our routes in any2 in LA as well. ... -----Original Message----- From: Job Snijders [mailto:job.snijders at atrato.com] Sent: Wednesday, March 06, 2013 4:04 AM To: Matsuzaki Yoshinobu Cc: nanog at nanog.org Subject: Re: Dreamhost/AS26347 unauthorized bgp announcement Hi Mat, I see the same thing, we learn the prefix from the route-server in LAX: telnet at r1.lax1.us>show ip bgp routes detail 90.201.80.0/20 Number of BGP Routes matching display condition : 1 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH S:SUPPRESSED F:FILTERED s:STALE 1 Prefix: 90.201.80.0/20, Status: BE, Age: 0h22m15s NEXT_HOP: 206.223.143.83, Metric: 0, Learned from Peer: 206.223.143.253 (19996) LOCAL_PREF: 400, MED: none, ORIGIN: incomplete, Weight: 0 AS_PATH: 26347 COMMUNITIES: 5580:12431 Adj_RIB_out count: 18, Admin distance 20 Last update to IP routing table: 0h22m15s, 1 path(s) installed: Kind regards, Job On Mar 6, 2013, at 9:59 AM, Matsuzaki Yoshinobu wrote: > According to RIPE RIS, AS26347 announced a bunch of prefixes again. > - http://www.ris.ripe.net/dashboard/26347 > > First suspicious announcement was started 2013-03-06 07:52:40 UTC, and > last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. > > It seems these unauthorized announcements have the same profile as > before - AS26347 shrinks the prefix lenght of their received prefix > somehow upto /20, and re-originates the prefix with origin AS26347. > > Any known bugs? > > Regards, > ----- > Matsuzaki Yoshinobu > - IIJ/AS2497 INOC-DBA: 2497*629 > -- AS5580 - Atrato IP Networks From job.snijders at atrato.com Wed Mar 6 16:11:32 2013 From: job.snijders at atrato.com (Job Snijders) Date: Wed, 6 Mar 2013 17:11:32 +0100 Subject: Dreamhost/AS26347 unauthorized bgp announcement In-Reply-To: References: <20130306.175954.55308686.maz@iij.ad.jp> <9D1C36A1-ACBA-4801-858A-44CFC3184223@atrato.com> Message-ID: <197CE086-8962-42D8-BFB8-64C5224F3965@atrato.com> Hi all, I tried contacting Coresite/Any2 to have somebody login to the routeserver and doublecheck which peer is actually announcing this NLRI. Because there is a remote possibility that the route-server is being manipulated by a third party and dreamhost is a victim here. After the usual hurdles like "What is your circuit ID?" "Without a workorder I cannot login to the routeserver!" and "5580? that can't be an AS number" I unfortunately got nowhere so I still don't know who exactly announced these prefixes to the route-server. As of now the announcements for the more specifics seem to be gone. Can anybody (preferably from Any2 or Dreamhost) shed more light on this matter? Kind regards, Job On Mar 6, 2013, at 2:43 PM, Drew Weaver wrote: > They're doing this to our routes in any2 in LA as well. > > ... > > > > -----Original Message----- > From: Job Snijders [mailto:job.snijders at atrato.com] > Sent: Wednesday, March 06, 2013 4:04 AM > To: Matsuzaki Yoshinobu > Cc: nanog at nanog.org > Subject: Re: Dreamhost/AS26347 unauthorized bgp announcement > > Hi Mat, > > I see the same thing, we learn the prefix from the route-server in LAX: > > telnet at r1.lax1.us>show ip bgp routes detail 90.201.80.0/20 Number of BGP Routes matching display condition : 1 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED > E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH > S:SUPPRESSED F:FILTERED s:STALE > 1 Prefix: 90.201.80.0/20, Status: BE, Age: 0h22m15s > NEXT_HOP: 206.223.143.83, Metric: 0, Learned from Peer: 206.223.143.253 (19996) > LOCAL_PREF: 400, MED: none, ORIGIN: incomplete, Weight: 0 > AS_PATH: 26347 > COMMUNITIES: 5580:12431 > Adj_RIB_out count: 18, Admin distance 20 > Last update to IP routing table: 0h22m15s, 1 path(s) installed: > > Kind regards, > > Job > > On Mar 6, 2013, at 9:59 AM, Matsuzaki Yoshinobu wrote: > >> According to RIPE RIS, AS26347 announced a bunch of prefixes again. >> - http://www.ris.ripe.net/dashboard/26347 >> >> First suspicious announcement was started 2013-03-06 07:52:40 UTC, and >> last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. >> >> It seems these unauthorized announcements have the same profile as >> before - AS26347 shrinks the prefix lenght of their received prefix >> somehow upto /20, and re-originates the prefix with origin AS26347. >> >> Any known bugs? >> >> Regards, >> ----- >> Matsuzaki Yoshinobu >> - IIJ/AS2497 INOC-DBA: 2497*629 >> > > -- > AS5580 - Atrato IP Networks > > > -- AS5580 - Atrato IP Networks From tony at lavanauts.org Wed Mar 6 16:20:33 2013 From: tony at lavanauts.org (Antonio Querubin) Date: Wed, 6 Mar 2013 06:20:33 -1000 (HST) Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Wed, 6 Mar 2013, Mukom Akong T. wrote: > I believe if anyone who can phrase the "IPv4 Exhaustion Problem + IPv6 > Solution" in very specific terms of the business model of the company will > implicitly inspire confidence in execs that they know what they are talking > about. I don't think the business case is the issue. It is the timeline over which the sense of urgency becomes important enough for most execs to take seriously. That's still a large unknown. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From mukom.tamon at gmail.com Wed Mar 6 16:41:24 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Wed, 6 Mar 2013 20:41:24 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin wrote: > I don't think the business case is the issue. It is the timeline over > which the sense of urgency becomes important enough for most execs to take > seriously. That's still a large unknown. Why should they care about the timeline if they aren't convinced it is even worth doing? -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From danny at tcb.net Wed Mar 6 16:42:58 2013 From: danny at tcb.net (danny at tcb.net) Date: Wed, 06 Mar 2013 09:42:58 -0700 Subject: Cloudflare is down In-Reply-To: References: <5133AC3D.4070105@foobar.org> <20130304073113.GA10384@pob.ytti.fi> Message-ID: On 2013-03-04 08:09, Christopher Morrow wrote: > On Mon, Mar 4, 2013 at 2:31 AM, Saku Ytti wrote: >> I know lot of vendors are fuzzing with 'codenomicon' and they appear >> not to >> have flowspec fuzzer. > > i suspect they fuzz where the money is ... > > number of users of bgp? > number of users of flowspec? While fuzzing of BGP[*] on the wire _may have identified some of this, there were many components involved (e.g., the DDoS attack on a customer's DNS servers that tickled their "attack profiler", their attack profiler was presumably confused about the suspect packet sizes as indicated in the presented "output signature", their operator didn't identify the issue before disseminating the recommended "signatures", JUNOS didn't barf when compiling the configuration (that'd be a big packet), a memory leak / thrashing triggered by the ingested flow_spec UPDATE crashed receiving routers, routers apparently recovered non-deterministically, etc..). Leo's comments remind me of the The President's Commission to Investigate the Accident at Three Mile Island (TMI) findings, where pretty much everyone was blamed, but the operators were identified as ultimately culpable (in this case, presumably, _they also wrote the "attack profiler", although "they" may not have been precisely who deployed the policy). For an interesting perspective of "normal accidents" derived from interactive complexity see [NormalAccidents], it's quite applicable to today's networks systems, methinks. -danny [NormalAccidents] Perrow, Charles, "Normal Accidents: Living with High-Risk Technologies", 1999. From kenneth.mcrae at dreamhost.com Wed Mar 6 17:19:46 2013 From: kenneth.mcrae at dreamhost.com (Kenneth McRae) Date: Wed, 6 Mar 2013 09:19:46 -0800 Subject: Dreamhost/AS26347 unauthorized bgp announcement In-Reply-To: <197CE086-8962-42D8-BFB8-64C5224F3965@atrato.com> References: <20130306.175954.55308686.maz@iij.ad.jp> <9D1C36A1-ACBA-4801-858A-44CFC3184223@atrato.com> <197CE086-8962-42D8-BFB8-64C5224F3965@atrato.com> Message-ID: Hi Guys, Sorry to see this come up again. We are no announcing the prefix in question. I am happy to work with you to investigate. dh_admin at gar-bdr-01> show route advertising-protocol bgp 206.223.143.122 inet.0: 447113 destinations, 1801741 routes (447105 active, 8 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 64.111.96.0/19 Self I * 66.33.192.0/19 Self I * 66.33.197.0/24 Self 6 I * 67.205.0.0/18 Self I * 69.163.128.0/17 Self I * 75.119.192.0/19 Self I * 173.236.128.0/17 Self I * 205.196.208.0/20 Self I * 208.97.128.0/18 Self I * 208.113.128.0/17 Self I * 208.113.200.0/24 Self 6 I Best, Kenneth {master} dh_admin at gar-bdr-01> On Wed, Mar 6, 2013 at 8:11 AM, Job Snijders wrote: > Hi all, > > I tried contacting Coresite/Any2 to have somebody login to the routeserver > and doublecheck > which peer is actually announcing this NLRI. Because there is a remote > possibility that the > route-server is being manipulated by a third party and dreamhost is a > victim here. > > After the usual hurdles like "What is your circuit ID?" "Without a > workorder I cannot login to > the routeserver!" and "5580? that can't be an AS number" I unfortunately > got nowhere so I > still don't know who exactly announced these prefixes to the route-server. > > As of now the announcements for the more specifics seem to be gone. > > Can anybody (preferably from Any2 or Dreamhost) shed more light on this > matter? > > Kind regards, > > Job > > On Mar 6, 2013, at 2:43 PM, Drew Weaver wrote: > > > They're doing this to our routes in any2 in LA as well. > > > > ... > > > > > > > > -----Original Message----- > > From: Job Snijders [mailto:job.snijders at atrato.com] > > Sent: Wednesday, March 06, 2013 4:04 AM > > To: Matsuzaki Yoshinobu > > Cc: nanog at nanog.org > > Subject: Re: Dreamhost/AS26347 unauthorized bgp announcement > > > > Hi Mat, > > > > I see the same thing, we learn the prefix from the route-server in LAX: > > > > telnet at r1.lax1.us>show ip bgp routes detail 90.201.80.0/20 Number of > BGP Routes matching display condition : 1 Status A:AGGREGATE B:BEST > b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED > > E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH > m:NOT-INSTALLED-MULTIPATH > > S:SUPPRESSED F:FILTERED s:STALE > > 1 Prefix: 90.201.80.0/20, Status: BE, Age: 0h22m15s > > NEXT_HOP: 206.223.143.83, Metric: 0, Learned from Peer: > 206.223.143.253 (19996) > > LOCAL_PREF: 400, MED: none, ORIGIN: incomplete, Weight: 0 > > AS_PATH: 26347 > > COMMUNITIES: 5580:12431 > > Adj_RIB_out count: 18, Admin distance 20 > > Last update to IP routing table: 0h22m15s, 1 path(s) installed: > > > > Kind regards, > > > > Job > > > > On Mar 6, 2013, at 9:59 AM, Matsuzaki Yoshinobu wrote: > > > >> According to RIPE RIS, AS26347 announced a bunch of prefixes again. > >> - http://www.ris.ripe.net/dashboard/26347 > >> > >> First suspicious announcement was started 2013-03-06 07:52:40 UTC, and > >> last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. > >> > >> It seems these unauthorized announcements have the same profile as > >> before - AS26347 shrinks the prefix lenght of their received prefix > >> somehow upto /20, and re-originates the prefix with origin AS26347. > >> > >> Any known bugs? > >> > >> Regards, > >> ----- > >> Matsuzaki Yoshinobu > >> - IIJ/AS2497 INOC-DBA: 2497*629 > >> > > > > -- > > AS5580 - Atrato IP Networks > > > > > > > > -- > AS5580 - Atrato IP Networks > > > > From cb.list6 at gmail.com Wed Mar 6 17:20:48 2013 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 6 Mar 2013 09:20:48 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <5136E23F.3060400@matthew.at> References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> <5136E23F.3060400@matthew.at> Message-ID: On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman wrote: > On 3/5/2013 8:20 PM, Owen DeLong wrote: >> >> On Mar 5, 2013, at 7:55 PM, Matthew Kaufman wrote: >> >>> On 3/5/2013 7:15 PM, Owen DeLong wrote: >>>> >>>> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. >>>> wrote: >>>> >>>>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: >>>>> >>>>>> I would lean towards >>>>>> >>>>>> f) Cost/benefit of deploying IPv6. >>>>>> >>>>> I certainly agree, which is why I propose understanding you >>>>> organisation's >>>>> business model and how specifically v4 exhaustion will threaten that. >>>>> IPv6 >>>>> is the cast as a solution to that, plus future unknown benefits that >>>>> may >>>>> result from e-2-e and NAT elimination. >>>>> >>>>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now >>>>> even >>>>> for engineers, there's not much of a benefit except more address space. >>>> >>>> I'm not so sure about that? >>>> >>>> Admittedly, most of these are too technical to be suitable for >>>> management consumption, but: >>>> >>>> 1. Decreased application complexity: >>> >>> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time >>> from now. Until then? >>> >> I don't think so. I think IPv4's demise as a supported internet protocol >> is certainly less than 10 years away and likely less than 5. I say this >> because IPv6 deployment is a bit of a variable here and we're faced with one >> of two outcomes as a result: > > > Two unsubstantiated suppositions deleted. > > They suggest that IPv4 support is needed *in conjunction with* IPv6 support > for 5-8 years. > > That's a long time if you're developing software... so, basically, no... no > cost or effort saving if you were to do this work today. In fact, >2x the > effort if you were to start today. > > So again, why try to sell it to the engineers that way? Either sell it as 1) > If you don't start doing a lot more work now you'll be screwed at the > transition or 2) You should just wait until you can single-stack on IPv6. > > >> Why? I doubt any software vendor will continue to maintain NAT traversal >> code much after IPv4 is no longer the common inter-domain protocol of >> choice. > > > Sure. In 5 to 8 years, as you claimed. > > >> >> Doubt it all you want. Once it's gone, it stops generating support calls, >> or they become very short: >> >> C: "Hi, my application isn't working through my NAT." >> TSR: "Hi? Get IPv6, we don't support NAT any more." >> TSR: "Is there anything else I can help you with today?" > > > C: "Hi, my application isn't working between me and my grandmother" > TSR: "Hi... Get IPv6, we don't suppotr NAT any more." > C: "Screw you guys... my grandmother isn't served by an ISP that is offering > IPv6 and her old operating system barely supports it anyway. Please refund > my money." > > The point being that for some applications, *both ends* need to be on IPv6 > before any of this complexity can go away. > > For the rest, they're just talking to web services... and until the places > those are hosted run out of IPv4 addresses, nobody cares. > So, your position, which is substantiated my Microsoft's / Windows Phone's / Skype's lack of IPv6 support , is that "nobody cares" until we "run out of IPv4". #1. We have run out of IPv4, check APNIC and RIPE, they are done. ARIN and LACNIC both have ~2.5 /8s left. Are you waiting on AfriNic? When are we run out, in your opinion? How are people in Indonesia, India, and the Philippines (and so ...) expected to get online without IPv4 addresses at APNIC? How do a launch a new disruptive wireless service across Europe when RIPE's currently implemented run-out-policy only allows for a /22 max allocation, ever.... #2. Your employer seems to have money to buy IPv4 addresses, what about everyone else? http://www.bbc.co.uk/news/technology-12859585 #3 I believe this position of your's / Microsoft's is also known as the "free rider problem". http://en.wikipedia.org/wiki/Free_rider_problem I personally would expect that Microsoft would not be a "free rider", i am sure they would like to cultivate an imagine of technology leadership. I expect a leadership role from Microsoft given their stature and resources. And, all told, they did step up for world IPv6 launch on www.bing.com, which is a big deal and many of their products work admirably well with IPv6 (notwithstanding this Exchange issue http://labs.apnic.net/blabs/?p=309) But, Matthew, your division of Microsoft is really a bunch of "Free Riders" that is honestly holding back the rest of us. I even had to write an IETF draft, more or less, just to work-around Skype's issues http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-10 Granted, there are other apps that don't work with IPv6, for example Netflix's Android app. But Skype is the big dog. And so is Microsoft. I think we expect technology leadership there, not a "free rider" making the rest of the system work around you at a cost to everyone else. CB > >> >> NAT will most likely become a thing of the past. I know you prefer to >> remain in denial about this, but more and more of the ISVs I have talked to >> are saying that they have no intention of adding NAT traversal to their IPv6 >> code. > > > I'm not in denial about this. I just don't think IPv4 is going away in the > next 30-60 days... and so my next one to two releases, which is what I'm > engineering for this week, need to support it, and NAT traversal, and all > that. > It'd be nice if they supported IPv6 as well, but really when you rank on a > big list all the things customers are demanding, IPv6 is *way* down that > list. > > >> The firewall shouldn't be adjusting the packet. I'm not sure why you think >> it would or what adjustments you think it would be making. > > > Option stripping, Diffserv scrubbing, all sorts of things that make the > packets no longer identical. > > >> >>>> Finally? There are 7 billion people on the planet. There are 2 billion >>>> currently on the internet. >>>> >>>> The other 5 billion won't fit in IPv4. If you want to talk to them, >>>> you'll need IPv6. >>> >>> Or a very big CGN. >> >> If you think this will actually scale and provide a user experience that >> will be considered at all acceptable, then you are delusional. > > > For most web and web-service based applications, it'll work just fine. > > In the "long run", sure, it runs out of steam... but I'm already talking > about times way sooner than your 5-8 years. > > > >> >>> >> I don't think that's actually true. I think that the economic incentives >> to drop IPv4 support from the inter domain world as soon as possible will >> apply strong pressure to expedite this process once IPv6 achieves a certain >> level of critical mass. > > > Yes... and will that "certain level of critical mass" happen before the end > of this June? If not, all it means is extra work, not less. > > >> >>> Trying to sell this to smart engineers writing code or testing it as >>> "less work" is just going to get you laughed out of the room as the crazy >>> IPv6 zealot. >> >> Actually, smart engineers realize that in the long run it's a lot less >> work. > > > Yes. In "the long run"... which is way farther out than the backlog for the > current sprint or even release, I'm afraid. > > >> That there's a brief period where it's way more work followed by a much >> better long-term. > > > That "brief period" lasts longer than most software startups are in > existence. Your shortest prediction was 5 years... an eternity, still. So > right now, today, when you take the powerpoint deck to the engineers, you > are asking them to do >2x the work, starting now, for some unknown future > benefit... likely after they are either 1) working somewhere else or 2) the > entire operation has been acquired by someone else. > > >> I'll leave off the obvious question about how smart can engineers be if >> they built an application in the 90s that was as strongly tied to unistack >> as Skype is when it was obvious that unistack IPv4 was a very temporary >> phenomenon. > > > Well maybe it wasn't that obvious in Estonia in the early 1990s. When I > wrote my P2P stack in the same era, it supported both IPv4 and IPv6, and a > version of that is what is in every copy of Flash Player. Working *and > tested* to support IPv6. > > Matthew Kaufman > From andree+nanog at toonk.nl Wed Mar 6 18:29:01 2013 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 06 Mar 2013 10:29:01 -0800 Subject: Dreamhost/AS26347 unauthorized bgp announcement In-Reply-To: <20130306.175954.55308686.maz@iij.ad.jp> References: <20130306.175954.55308686.maz@iij.ad.jp> Message-ID: <51378AED.7010309@toonk.nl> .-- My secret spy satellite informs me that at 2013-03-06 12:59 AM Matsuzaki Yoshinobu wrote: > According to RIPE RIS, AS26347 announced a bunch of prefixes again. > - http://www.ris.ripe.net/dashboard/26347 > > First suspicious announcement was started 2013-03-06 07:52:40 UTC, and > last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. > > It seems these unauthorized announcements have the same profile as > before - AS26347 shrinks the prefix lenght of their received prefix > somehow upto /20, and re-originates the prefix with origin AS26347. > > Any known bugs? Sounds indeed like an exact copy of the incident on January 11: http://seclists.org/nanog/2013/Jan/243 That time the prefixes seem to also have been learned via a route-server in LA. The strange thing is that the majority of the 'hijacked' prefixes (today and in January) are new more specifics (not seen before). (Using some kind of BGP route optimizer?). This time it affected 203 unique prefixes and 133 ASns. Below a list of some of the affected ASns 20115 Charter Telecom. 4837 China Unicom 8151 UNINET Mexico 11427 Roadrunner 42961 MTC GPRS Kuwait 7303 Telecom Argentina S.A. 25135 Vodafone 7018 AT&T 6389 BellSouth.net 8220 Colt 19262 Verizon 9143 ZIGGO 6830 UPC 5089 Virgin Media Cheers, Andree From brunner at nic-naa.net Wed Mar 6 18:29:59 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 06 Mar 2013 10:29:59 -0800 Subject: GMAIL contact Message-ID: <51378B27.5090304@nic-naa.net> Folks, We'd a user account compromised a couple of weeks ago, spam naturally. We're not getting any response from Gmail's set of contacts, so if anyone has a working Gmail contact, phone or mail, that they're willing to share off-list, I'd appreciate it. Eric Brunner-Williams From jeroen at mompl.net Wed Mar 6 18:50:00 2013 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 06 Mar 2013 10:50:00 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> References: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> Message-ID: <51378FD8.60804@mompl.net> On 03/05/2013 05:41 PM, Owen DeLong wrote: > I think it's also important to cover the following topics somewhere in the process: > > 1. This will affect the entire organization, not just the IT department and > will definitely impact all of apps, sysadmin, devops, operations, and > networking teams within the IT department. > > 2. Training will be required for virtually all levels of the organization. End users > won't need more than a ~2 hour introduction to what to look for during and I've migrated (or enabled) offices (and homes) to IPv6 without them even realising it. If it's just enabling IPv6 connectivity there may be very little to be done with regards to training and informing end users. The beauty of IPv6 in my experience is that it is quite transparent, you don't even notice it is there (or shouldn't, if done properly). Adapting your current software to IPv6, that could be more tricky. Although if you use the right IPv6 aware libraries and functions it could be relatively easy in code. In my own apps it's just a matter of changing the ai_family flag of getaddrinfo() to AF_UNSPEC if not done so yet. Although interestingly that may have complications (sudden loss of connectivity or more subtle issues). So I can relate to the fact it can be tricky. Greetings, Jeroen -- Earthquake Magnitude: 5.0 Date: Wednesday, March 6, 2013 16:49:46 UTC Location: Nepal Latitude: 28.7312; Longitude: 82.2176 Depth: 10.00 km From pmm at igtc.com Wed Mar 6 19:06:05 2013 From: pmm at igtc.com (Paul M. Moriarty) Date: Wed, 6 Mar 2013 11:06:05 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <8CC96CBF-1A17-42EC-B15A-632589D97A3B@igtc.com> On Mar 5, 2013, at 9:55 AM, Mukom Akong T. wrote: > [?] > > b) To you who are managers, what else do you need your engineers to address > in order for you to be convinced? How long will it take to complete the project? From george.herbert at gmail.com Wed Mar 6 20:05:24 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 6 Mar 2013 12:05:24 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> <5136E23F.3060400@matthew.at> Message-ID: On Wed, Mar 6, 2013 at 9:20 AM, Cameron Byrne wrote: > > So, your position, which is substantiated my Microsoft's / Windows > Phone's / Skype's lack of IPv6 support , is that "nobody cares" until > we "run out of IPv4". That is clearly reducto ad absurdum and does not resemble Matthew's detailed and nuanced argument. Please try again. -- -george william herbert george.herbert at gmail.com From rcarpen at network1.net Wed Mar 6 20:11:50 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 6 Mar 2013 15:11:50 -0500 (EST) Subject: Time Warner Cable YouTube throttling In-Reply-To: <1509607164.165919.1362599208811.JavaMail.root@network1.net> Message-ID: <1020036796.166150.1362600710911.JavaMail.root@network1.net> We have recently been having some serious speed issues with YouTube on our home connections, which are all Time Warner Cable. Some searching on forums and such revealed a work around: Block 206.111.0.0/16 at the router. This makes speeds go from ~1 Mb/s to the full connection speed (30 Mb/s in my case). It appears that TWC is forcing traffic to this netblock over a congested link, or otherwise throttling it. Trying to communicate this to tech support results in the typical "Derrr, what?" Does anyone at Time Warner care to comment on WTF? thanks, -Randy From george.herbert at gmail.com Wed Mar 6 20:13:22 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 6 Mar 2013 12:13:22 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> Message-ID: On Tue, Mar 5, 2013 at 8:20 PM, Owen DeLong wrote: >Matthew wrote: >>[...] >>> 1. Decreased application complexity: >> >> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time from now. Until then? >> > I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result: I'm probably biased because I'm a fulltime consultant off in EndUserLand, but I don't believe this argument for a moment. I'm sorry, but a lot of organizations' response to IPv6 has been "Ok, desktops will need an overlay of it for some websites in AP next year, so we'll do that. And we need an IPv6 front end visibility for our website. But we don't REALLY need to change to using it primarily." And a fair number are still "What six?". A very small sliver of end-user networks are truly fully functionally dual-stacking internally now. A fair number of IT admins still don't know anything useful about how to implement it, and are going to pray for translating gateways, and are having pain and suffering getting their heads around what's needed for the minimal IPv6 front end for their corporate web presence. Adoption in big network providers, and in big network services, and in big telco (both broadband and mobile users) are much further along than the average "enterprise". The mindshare shift is happening, but the change won't snowball until IT admins - in bulk - really get it. -- -george william herbert george.herbert at gmail.com From bill at herrin.us Wed Mar 6 20:25:16 2013 From: bill at herrin.us (William Herrin) Date: Wed, 6 Mar 2013 15:25:16 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Tue, Mar 5, 2013 at 11:49 PM, Mukom Akong T. wrote: > On Wed, Mar 6, 2013 at 12:09 AM, William Herrin wrote: >> 1. What is the real dollar cost of doing the project (including both >> up-front and currently indefinite ongoing costs of dual stack. And >> don't forget to price out risk!). > > Now in the post, I mention cost elements. At a point when you are still > trying to convince execs about v6, is it possible to have an accurate value > for this cost. Wouldn't cost elements and ball-park amounts be sufficient? > > Please could you shed some more light on 'Pricing out Risk'? any tools and > techniques to do that would be highly appreciated. Howdy, For that, you need the help of a real cost analyst. That's what they're for; they help organizations figure out a solid idea what something will really cost before they start spending money. If your organization is large, you may even have one on staff somewhere. You can also consider pitching an IPv6 pilot project where you get your IP addresses and bring IPv6 in from your ISPs but then stop just on your side of the border rather than thoroughly deploying it. That strongly bounds the cost, including the cost from risk. One of the elements of such a pilot project would be contracting a cost analyst to help you collect figure out what data to collect during the pilot and then produce a cost model from the data to figure out what it'll really cost for a full deployment. >> 2. What is the real dollar cost of not doing the project. (i.e. >> customers you expect to lose because you didn't do it. Don't suggest >> that IPv6 will allow you to avoid acquiring more IPv4. That's not yet >> true and if you say, "It will be in 5 years" the exec will respond, >> "great, come see me in 5 years.") > > IPv6 has elements of a disruptive technology (right now it really only > addresses the needs of a fringe segment of the market and also is perceived > as worse with respect to feature set). The inherent problem with such > technologies is that no one knows the real dollar cost of NOT taking action > (when concrete data becomes available to support that, it would mean it has > already seen market success and so if you still don't have it, you'd be too > late.) Practically speaking, there's no point in projecting the cost of never taking action. You only have to project the cost of not intiating action *this year*, or within two years or whatever the budgeting cycle is that allows you to get started on the proposed project. >> Implicitly they'll also be looking for the answer to a fourth >> question: Do you know WTF you're talking about? If you assure them >> it's all peaches and cream with tiny costs and no opportunity cost, >> the answer is, "no." > > I believe if anyone who can phrase the "IPv4 Exhaustion Problem + IPv6 > Solution" in very specific terms of the business model of the company will > implicitly inspire confidence in execs that they know what they are talking > about. Your first paragraph loses the argument: the day has past when IPv6 could become a credible solution to the IPv4 exhaustion problem. Like it or lump it, NAT was the solution to the IPv4 exhaustion problem. Which the exec will learn when he chats up his computer literate buddy before making his decision. If IPv6 approaches ubiquity, it'll get another crack at solving that problem. Until then, the business case for IPv6 deployment is about making your products compatible with emerging standards and to what (if any) degree your customers will penalize you if you do not do so during your projection window. If you're an ISP or you make network software, this is a straightforward case to make. There are public sources of IPv6 deployment rate data. You can presume that a similar rate holds among your customers and that the customers who deploy IPv6 will disqualify your product if the product doesn't work with IPv6. If your business isn't networks, you have a much harder case to make. As another poster noted, the end of IPv4 is not on the radar yet. A statistically insignificant number of people will change banks this year over their bank's web site IPv6 reachability. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Wed Mar 6 20:30:45 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 6 Mar 2013 15:30:45 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <1020036796.166150.1362600710911.JavaMail.root@network1.net> References: <1509607164.165919.1362599208811.JavaMail.root@network1.net> <1020036796.166150.1362600710911.JavaMail.root@network1.net> Message-ID: On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter wrote: > > We have recently been having some serious speed issues with YouTube on our home connections, which are all Time Warner Cable. > Some searching on forums and such revealed a work around: > > Block 206.111.0.0/16 at the router. > this was reported elsewhere... it seems odd, since that's XO space, not Google and not TWC space. Would you care to engage in some troubleshooting to help everyone out? :) > This makes speeds go from ~1 Mb/s to the full connection speed (30 Mb/s in my case). It appears that TWC is forcing traffic to this netblock over a congested link, or otherwise throttling it. > > Trying to communicate this to tech support results in the typical "Derrr, what?" > > Does anyone at Time Warner care to comment on WTF? > > > thanks, > -Randy > From drais at icantclick.org Wed Mar 6 20:30:42 2013 From: drais at icantclick.org (david raistrick) Date: Wed, 6 Mar 2013 15:30:42 -0500 (EST) Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> Message-ID: On Wed, 6 Mar 2013, George Herbert wrote: > The mindshare shift is happening, but the change won't snowball until > IT admins - in bulk - really get it. and keeping in mind that the bulk still don't "get" ipv4, either, (how many times a day do I explain to someone what a /xx is, and how you'd fill that out for just a single ip address....sigh), the snowball really won't happen until it Just Works(tm). impe and all that. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From rcarpen at network1.net Wed Mar 6 20:34:46 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 6 Mar 2013 15:34:46 -0500 (EST) Subject: Time Warner Cable YouTube throttling In-Reply-To: Message-ID: <32193289.166228.1362602086426.JavaMail.root@network1.net> ----- Original Message ----- > On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter > wrote: > > > > We have recently been having some serious speed issues with YouTube > > on our home connections, which are all Time Warner Cable. > > Some searching on forums and such revealed a work around: > > > > Block 206.111.0.0/16 at the router. > > > > this was reported elsewhere... it seems odd, since that's XO space, > not Google and not TWC space. Would you care to engage in some > troubleshooting to help everyone out? :) I'll be happy to help troubleshoot in any way I can. -Randy From george.herbert at gmail.com Wed Mar 6 20:42:35 2013 From: george.herbert at gmail.com (George Herbert) Date: Wed, 6 Mar 2013 12:42:35 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> Message-ID: On Wed, Mar 6, 2013 at 12:30 PM, david raistrick wrote: > On Wed, 6 Mar 2013, George Herbert wrote: > >> The mindshare shift is happening, but the change won't snowball until >> IT admins - in bulk - really get it. > > > and keeping in mind that the bulk still don't "get" ipv4, either, (how many > times a day do I explain to someone what a /xx is, and how you'd fill that > out for just a single ip address....sigh), the snowball really won't happen > until it Just Works(tm). impe and all that. I had to check something now, but the current client site is first time my laptop's come up on the client's internal net finding IPv6 addresses in use. 10 clients in the last 4 years, mostly SF Bay Area tech firms of some sort. This client is a subsidiary of a network hardware vendor. Your mileage may vary, but ... -- -george william herbert george.herbert at gmail.com From matthew at matthew.at Wed Mar 6 20:57:15 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 06 Mar 2013 12:57:15 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> <5136E23F.3060400@matthew.at> Message-ID: <5137ADAB.3030809@matthew.at> On 3/6/2013 9:20 AM, Cameron Byrne wrote: > On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman wrote: >> On 3/5/2013 8:20 PM, Owen DeLong wrote: >>> On Mar 5, 2013, at 7:55 PM, Matthew Kaufman wrote: >>> >>>> On 3/5/2013 7:15 PM, Owen DeLong wrote: >>>>> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. >>>>> wrote: >>>>> >>>>>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: >>>>>> >>>>>>> I would lean towards >>>>>>> >>>>>>> f) Cost/benefit of deploying IPv6. >>>>>>> >>>>>> I certainly agree, which is why I propose understanding you >>>>>> organisation's >>>>>> business model and how specifically v4 exhaustion will threaten that. >>>>>> IPv6 >>>>>> is the cast as a solution to that, plus future unknown benefits that >>>>>> may >>>>>> result from e-2-e and NAT elimination. >>>>>> >>>>>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now >>>>>> even >>>>>> for engineers, there's not much of a benefit except more address space. >>>>> I'm not so sure about that? >>>>> >>>>> Admittedly, most of these are too technical to be suitable for >>>>> management consumption, but: >>>>> >>>>> 1. Decreased application complexity: >>>> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time >>>> from now. Until then? >>>> >>> I don't think so. I think IPv4's demise as a supported internet protocol >>> is certainly less than 10 years away and likely less than 5. I say this >>> because IPv6 deployment is a bit of a variable here and we're faced with one >>> of two outcomes as a result: >> >> Two unsubstantiated suppositions deleted. >> >> They suggest that IPv4 support is needed *in conjunction with* IPv6 support >> for 5-8 years. >> >> That's a long time if you're developing software... so, basically, no... no >> cost or effort saving if you were to do this work today. In fact, >2x the >> effort if you were to start today. >> >> So again, why try to sell it to the engineers that way? Either sell it as 1) >> If you don't start doing a lot more work now you'll be screwed at the >> transition or 2) You should just wait until you can single-stack on IPv6. >> >> >>> Why? I doubt any software vendor will continue to maintain NAT traversal >>> code much after IPv4 is no longer the common inter-domain protocol of >>> choice. >> >> Sure. In 5 to 8 years, as you claimed. >> >> >>> Doubt it all you want. Once it's gone, it stops generating support calls, >>> or they become very short: >>> >>> C: "Hi, my application isn't working through my NAT." >>> TSR: "Hi? Get IPv6, we don't support NAT any more." >>> TSR: "Is there anything else I can help you with today?" >> >> C: "Hi, my application isn't working between me and my grandmother" >> TSR: "Hi... Get IPv6, we don't suppotr NAT any more." >> C: "Screw you guys... my grandmother isn't served by an ISP that is offering >> IPv6 and her old operating system barely supports it anyway. Please refund >> my money." >> >> The point being that for some applications, *both ends* need to be on IPv6 >> before any of this complexity can go away. >> >> For the rest, they're just talking to web services... and until the places >> those are hosted run out of IPv4 addresses, nobody cares. >> > So, your position, which is substantiated my Microsoft's / Windows > Phone's / Skype's lack of IPv6 support , is that "nobody cares" until > we "run out of IPv4". No. While you've cleverly quoted something I did say, Skype is an example of an application where, as I mentioned in the paragraph above, until both ends of a call are always guaranteed to be on IPv6, there is *more* complexity involved in supporting both IPv4 and IPv6 than in supporting IPv4 alone. This entire discussion started with "how should I sell IPv6 to executives" and Owen claimed that switching to IPv6 represents less engineering effort. I simply claim that isn't true. In fact the amount of engineering effort required to make an application like Skype work (both development effort and testing required) where the users who might want to call each other are on an unknown mixture of IPv4, IPv4/IPv6 dual-stack, IPv6 w/NAT64 for IPv4, and IPv6 single-stack is *tremendous* compared to the effort required to make it work with IPv4 and end-user NAT devices. > But, Matthew, your division of Microsoft is really a bunch of "Free > Riders" that is honestly holding back the rest of us. My division of Microsoft is currently engaged in a massive amount of engineering... work to add features that customers are demanding, work to make Skype work better on mobile devices, work to make Skype interoperate with Lync, and yes, work to make Skype work in the huge explosion of new network connectivity situations it will find itself in as IPv6 is deployed and especially as those IPv6 users stop getting native IPv4 alongside it. And we're using Agile and Scrum as our engineering methodology, and I can tell you that it is very very hard to get IPv6 work to rise to the top in any organization, including ours, given that the short-term return on that investment is nil and the engineering and testing effort is huge. But again, the only reason I even brought this up here is that there are people like Owen running around trying to tell engineers that when the whole world is IPv6 everything will be so much easier... and while that might be true, there are at least 5 more years and probably more where the necessary engineering effort required to support *both*, especially for applications like Skype, is crazy hard compared to IPv4-only, and so trying to sell the execs on the idea that we'll deploy some IPv6 internally and write some IPv6 code and our QE and Dev budget can go *down* is frankly ridiculous. Matthew Kaufman p.s. As I pointed out privately last night, if doing IPv4+IPv6 was really easier than doing IPv4-only, we wouldn't see other smart collections of engineers with bugs like this one: https://code.google.com/p/webrtc/issues/detail?id=1406 (because *clearly* there's no reason to have taken the "extra effort" to make it IPv4-only, right?) From morrowc.lists at gmail.com Wed Mar 6 21:10:13 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 6 Mar 2013 16:10:13 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <32193289.166228.1362602086426.JavaMail.root@network1.net> References: <32193289.166228.1362602086426.JavaMail.root@network1.net> Message-ID: On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter wrote: > > ----- Original Message ----- >> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >> wrote: >> > >> > We have recently been having some serious speed issues with YouTube >> > on our home connections, which are all Time Warner Cable. >> > Some searching on forums and such revealed a work around: >> > >> > Block 206.111.0.0/16 at the router. >> > >> >> this was reported elsewhere... it seems odd, since that's XO space, >> not Google and not TWC space. Would you care to engage in some >> troubleshooting to help everyone out? :) > > I'll be happy to help troubleshoot in any way I can. excellent.. I'll arrange my ducks, let's chat offlist? From wesley.george at twcable.com Wed Mar 6 21:36:05 2013 From: wesley.george at twcable.com (George, Wes) Date: Wed, 6 Mar 2013 16:36:05 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <5136E23F.3060400@matthew.at> References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> <5136E23F.3060400@matthew.at> Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923041F47A67E@PRVPEXVS15.corp.twcable.com> > From: Matthew Kaufman [mailto:matthew at matthew.at] > They suggest that IPv4 support is needed *in conjunction with* IPv6 > support for 5-8 years. > > That's a long time if you're developing software... so, basically, no... > no cost or effort saving if you were to do this work today. In fact, >2x > the effort if you were to start today. > > So again, why try to sell it to the engineers that way? Either sell it > as 1) If you don't start doing a lot more work now you'll be screwed at > the transition or 2) You should just wait until you can single-stack on > IPv6. [WEG] snip > > The point being that for some applications, *both ends* need to be on > IPv6 before any of this complexity can go away. > > For the rest, they're just talking to web services... and until the > places those are hosted run out of IPv4 addresses, nobody cares. > [WEG] One point to consider is that as an application/content provider, there is a real risk to you that the kinky middlebox (CGN, etc) that an SP puts between you and your customers in order to extend the life of IPv4 in their network will break or otherwise degrade your service in ways that you can't control, may not be able to test for, and may not be able to fix easily. The success of your business becomes dependent on that ALG, or the scale and performance of that box and its effect on latency and jitter. You're basically held hostage by the business drivers of an organization that has little vested interest in ensuring your specific application works, other than to ensure that the majority of their customers stay happy. How much do you trust $ISP not to negatively affect your user experience? Fixing it requires good assumptions about all possible variations of how it might work in each SP and vendor implementation so that your NAT traversal code works across multiple layers of NAT in each direction, and that may not help if the performance is just bad on account of scale. This is incrementally worse than the status quo today, because while CGN/NAT44 is fairly common, especially in the mobile space, it isn't as common in networks where there is already a layer of NAT (eg a home ISP) thus giving you NAT444, so it's maybe not quite as simple as you're making it. I'm not going to argue that this problem will magically go away if you start supporting IPv6 in the next feasible release, but given the IPv6 deployments underway in many ISPs, it seems a worthwhile thing to pursue in order to possibly bypass some permutations of NAT that you're not solving for today and attempt to remove another barrier to moving to IPv6-only and the attendant reductions in complexity single-stacking provides. Wes George 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 coloccia at geneseo.edu Wed Mar 6 22:56:07 2013 From: coloccia at geneseo.edu (Rick Coloccia) Date: Wed, 6 Mar 2013 17:56:07 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> Message-ID: I'd like to help, too, I'm from a TWC business class site with 650 Mbps bandwidth and still regularly poor performance with YouTube. -Rick Sent from my iPhone 4S On Mar 6, 2013, at 4:10 PM, Christopher Morrow wrote: > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter wrote: >> >> ----- Original Message ----- >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >>> wrote: >>>> >>>> We have recently been having some serious speed issues with YouTube >>>> on our home connections, which are all Time Warner Cable. >>>> Some searching on forums and such revealed a work around: >>>> >>>> Block 206.111.0.0/16 at the router. >>> >>> this was reported elsewhere... it seems odd, since that's XO space, >>> not Google and not TWC space. Would you care to engage in some >>> troubleshooting to help everyone out? :) >> >> I'll be happy to help troubleshoot in any way I can. > > excellent.. I'll arrange my ducks, let's chat offlist? > From derek at derekivey.com Thu Mar 7 00:37:46 2013 From: derek at derekivey.com (Derek Ivey) Date: Wed, 6 Mar 2013 19:37:46 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> Message-ID: I don't think it's just Time Warner. Definitely looks like XO. I have Verizon FiOS and it was pretty bad for me as well (not sure if it still is since I'm not home right now). There's also atleast two threads in the Verizon FiOS section on Broadband Reports: http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr Derek On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia wrote: > I'd like to help, too, I'm from a TWC business class site with 650 Mbps > bandwidth and still regularly poor performance with YouTube. > > -Rick > > Sent from my iPhone 4S > > On Mar 6, 2013, at 4:10 PM, Christopher Morrow > wrote: > > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter > wrote: > >> > >> ----- Original Message ----- > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter > >>> wrote: > >>>> > >>>> We have recently been having some serious speed issues with YouTube > >>>> on our home connections, which are all Time Warner Cable. > >>>> Some searching on forums and such revealed a work around: > >>>> > >>>> Block 206.111.0.0/16 at the router. > >>> > >>> this was reported elsewhere... it seems odd, since that's XO space, > >>> not Google and not TWC space. Would you care to engage in some > >>> troubleshooting to help everyone out? :) > >> > >> I'll be happy to help troubleshoot in any way I can. > > > > excellent.. I'll arrange my ducks, let's chat offlist? > > > > From shortdudey123 at gmail.com Thu Mar 7 01:31:14 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 6 Mar 2013 19:31:14 -0600 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> Message-ID: Can any one provide traceroutes to youtube to see if there is any correlation between last mile providers? -Grant On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey wrote: > I don't think it's just Time Warner. Definitely looks like XO. I have > Verizon FiOS and it was pretty bad for me as well (not sure if it still is > since I'm not home right now). There's also atleast two threads in the > Verizon FiOS section on Broadband Reports: > > http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds > > http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr > > Derek > > > On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia > wrote: > > > I'd like to help, too, I'm from a TWC business class site with 650 Mbps > > bandwidth and still regularly poor performance with YouTube. > > > > -Rick > > > > Sent from my iPhone 4S > > > > On Mar 6, 2013, at 4:10 PM, Christopher Morrow > > wrote: > > > > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter > > wrote: > > >> > > >> ----- Original Message ----- > > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter > > >>> wrote: > > >>>> > > >>>> We have recently been having some serious speed issues with YouTube > > >>>> on our home connections, which are all Time Warner Cable. > > >>>> Some searching on forums and such revealed a work around: > > >>>> > > >>>> Block 206.111.0.0/16 at the router. > > >>> > > >>> this was reported elsewhere... it seems odd, since that's XO space, > > >>> not Google and not TWC space. Would you care to engage in some > > >>> troubleshooting to help everyone out? :) > > >> > > >> I'll be happy to help troubleshoot in any way I can. > > > > > > excellent.. I'll arrange my ducks, let's chat offlist? > > > > > > > > From derek at derekivey.com Thu Mar 7 02:07:19 2013 From: derek at derekivey.com (Derek Ivey) Date: Wed, 06 Mar 2013 21:07:19 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> Message-ID: <5137F657.7090500@derekivey.com> I just got home and tested with quite a few 1080p videos. No issues over my Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on my FiOS IPv4 connection. I have a 50 Mbps down connection and don't even come close to maxing it when watching Youtube videos. Here are a few traceroutes: [2.1-BETA0][root at pfsense]/root(1): traceroute r19---sn-p5qlsm7d.c.youtube.com traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops max, 40 byte packets 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms 0.834 ms 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms 2.589 ms 2.443 ms 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms 14.614 ms 14.698 ms 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms 14.696 ms 14.552 ms 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms 15.064 ms 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms 36.033 ms 34.816 ms 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms 29.194 ms 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms [2.1-BETA0][root at pfsense]/root(2): traceroute r15---sn-p5qlsm76.c.youtube.com traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops max, 40 byte packets 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms 0.968 ms 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms 2.265 ms 2.456 ms 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms 14.666 ms 14.643 ms 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms 14.479 ms 16.041 ms 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms 14.975 ms 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms 122.780 ms 121.535 ms 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms [2.1-BETA0][root at pfsense]/root(6): traceroute r10---sn-p5qlsm7l.c.youtube.com traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops max, 40 byte packets 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms 0.806 ms 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms 2.435 ms 2.167 ms 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms 14.767 ms 14.695 ms 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms 15.024 ms 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms 117.698 ms sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms 124.402 ms 125.384 ms 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms Derek On 3/6/2013 8:31 PM, Grant Ridder wrote: > Can any one provide traceroutes to youtube to see if there is any > correlation between last mile providers? > > -Grant > > On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey > wrote: > > I don't think it's just Time Warner. Definitely looks like XO. I have > Verizon FiOS and it was pretty bad for me as well (not sure if it > still is > since I'm not home right now). There's also atleast two threads in the > Verizon FiOS section on Broadband Reports: > > http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds > http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr > > Derek > > > On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia > > wrote: > > > I'd like to help, too, I'm from a TWC business class site with > 650 Mbps > > bandwidth and still regularly poor performance with YouTube. > > > > -Rick > > > > Sent from my iPhone 4S > > > > On Mar 6, 2013, at 4:10 PM, Christopher Morrow > > > > wrote: > > > > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter > > > > wrote: > > >> > > >> ----- Original Message ----- > > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter > > >>> > wrote: > > >>>> > > >>>> We have recently been having some serious speed issues with > YouTube > > >>>> on our home connections, which are all Time Warner Cable. > > >>>> Some searching on forums and such revealed a work around: > > >>>> > > >>>> Block 206.111.0.0/16 at the router. > > >>> > > >>> this was reported elsewhere... it seems odd, since that's XO > space, > > >>> not Google and not TWC space. Would you care to engage in some > > >>> troubleshooting to help everyone out? :) > > >> > > >> I'll be happy to help troubleshoot in any way I can. > > > > > > excellent.. I'll arrange my ducks, let's chat offlist? > > > > > > > > > From qiu.min98 at gmail.com Thu Mar 7 02:25:34 2013 From: qiu.min98 at gmail.com (Min) Date: Wed, 6 Mar 2013 21:25:34 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <5137F657.7090500@derekivey.com> References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> Message-ID: 3 traces all indicated the last hub are 80~100ms faster than the second last hub. Interesting. Min On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: > I just got home and tested with quite a few 1080p videos. No issues over my > Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on my > FiOS IPv4 connection. I have a 50 Mbps down connection and don't even come > close to maxing it when watching Youtube videos. > > Here are a few traceroutes: > > [2.1-BETA0][root at pfsense]/root(1): traceroute > r19---sn-p5qlsm7d.c.youtube.com > traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops max, > 40 byte packets > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms > 0.834 ms > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms > 2.589 ms 2.443 ms > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms 14.614 > ms 14.698 ms > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms > 14.696 ms 14.552 ms > 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms > 15.064 ms > 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms 36.033 > ms 34.816 ms > 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms > 29.194 ms > 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms > 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms > > [2.1-BETA0][root at pfsense]/root(2): traceroute > r15---sn-p5qlsm76.c.youtube.com > traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops max, > 40 byte packets > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms > 0.968 ms > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms > 2.265 ms 2.456 ms > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms 14.666 > ms 14.643 ms > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms > 14.479 ms 16.041 ms > 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms > 14.975 ms > 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms > 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms > sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms > 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms 122.780 > ms 121.535 ms > 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms > > [2.1-BETA0][root at pfsense]/root(6): traceroute > r10---sn-p5qlsm7l.c.youtube.com > traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops max, > 40 byte packets > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms > 0.806 ms > 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms > 2.435 ms 2.167 ms > 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms > 14.767 ms 14.695 ms > 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms > 15.024 ms > 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms > 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms 117.698 > ms > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms > 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms 124.402 > ms 125.384 ms > 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms > > Derek > > On 3/6/2013 8:31 PM, Grant Ridder wrote: >> >> Can any one provide traceroutes to youtube to see if there is any >> correlation between last mile providers? >> >> -Grant >> >> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey > > wrote: >> >> I don't think it's just Time Warner. Definitely looks like XO. I have >> Verizon FiOS and it was pretty bad for me as well (not sure if it >> still is >> since I'm not home right now). There's also atleast two threads in the >> Verizon FiOS section on Broadband Reports: >> >> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds >> >> http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr >> >> Derek >> >> >> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia >> > wrote: >> >> > I'd like to help, too, I'm from a TWC business class site with >> 650 Mbps >> > bandwidth and still regularly poor performance with YouTube. >> > >> > -Rick >> > >> > Sent from my iPhone 4S >> > >> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow >> > >> > wrote: >> > >> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter >> > >> > wrote: >> > >> >> > >> ----- Original Message ----- >> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >> > >>> > wrote: >> > >>>> >> > >>>> We have recently been having some serious speed issues with >> YouTube >> > >>>> on our home connections, which are all Time Warner Cable. >> > >>>> Some searching on forums and such revealed a work around: >> > >>>> >> > >>>> Block 206.111.0.0/16 at the router. >> > >>> >> > >>> this was reported elsewhere... it seems odd, since that's XO >> space, >> > >>> not Google and not TWC space. Would you care to engage in some >> > >>> troubleshooting to help everyone out? :) >> > >> >> > >> I'll be happy to help troubleshoot in any way I can. >> > > >> > > excellent.. I'll arrange my ducks, let's chat offlist? >> > > >> > >> > >> >> > From shortdudey123 at gmail.com Thu Mar 7 02:35:57 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 6 Mar 2013 20:35:57 -0600 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> Message-ID: The 1st one gets slow at XO and the 2nd and 3rd get slow at Sprint. Now the interesting one with XO is that it is routed in a /30 that is assigned to Google by XO. network:Class-Name:network network:ID:NET-XO-NET-d1302a54 network:Auth-Area:209.48.0.0/15 network:Network-Name:XO-NET-d1302a54 network:Organization;I:GOOGLE INC. (328874-1) network:IP-Network:209.48.42.84/30 network:Admin-Contact;I:XCIA-ARIN network:Tech-Contact;I:XCIA-ARIN network:Created:20120917 network:Updated:20121018 network:Updated-By:ipadmin at eng.xo.com -Grant On Wed, Mar 6, 2013 at 8:25 PM, Min wrote: > 3 traces all indicated the last hub are 80~100ms faster than the > second last hub. Interesting. > > Min > > On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: > > I just got home and tested with quite a few 1080p videos. No issues over > my > > Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on > my > > FiOS IPv4 connection. I have a 50 Mbps down connection and don't even > come > > close to maxing it when watching Youtube videos. > > > > Here are a few traceroutes: > > > > [2.1-BETA0][root at pfsense]/root(1): traceroute > > r19---sn-p5qlsm7d.c.youtube.com > > traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops > max, > > 40 byte packets > > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms > > 0.834 ms > > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms > > 2.589 ms 2.443 ms > > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms > 14.614 > > ms 14.698 ms > > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms > > 14.696 ms 14.552 ms > > 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms > > 15.064 ms > > 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms > 36.033 > > ms 34.816 ms > > 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms > > 29.194 ms > > 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms > > 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms > > > > [2.1-BETA0][root at pfsense]/root(2): traceroute > > r15---sn-p5qlsm76.c.youtube.com > > traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops > max, > > 40 byte packets > > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms > > 0.968 ms > > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms > > 2.265 ms 2.456 ms > > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms > 14.666 > > ms 14.643 ms > > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms > > 14.479 ms 16.041 ms > > 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms > > 14.975 ms > > 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms > > 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms > > sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms > > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms > > 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms > 122.780 > > ms 121.535 ms > > 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms > > > > [2.1-BETA0][root at pfsense]/root(6): traceroute > > r10---sn-p5qlsm7l.c.youtube.com > > traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops > max, > > 40 byte packets > > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms > > 0.806 ms > > 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms > > 2.435 ms 2.167 ms > > 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms > > 14.767 ms 14.695 ms > > 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms > > 15.024 ms > > 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms > > 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms > 117.698 > > ms > > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms > > 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms > 124.402 > > ms 125.384 ms > > 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms > > > > Derek > > > > On 3/6/2013 8:31 PM, Grant Ridder wrote: > >> > >> Can any one provide traceroutes to youtube to see if there is any > >> correlation between last mile providers? > >> > >> -Grant > >> > >> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >> > wrote: > >> > >> I don't think it's just Time Warner. Definitely looks like XO. I > have > >> Verizon FiOS and it was pretty bad for me as well (not sure if it > >> still is > >> since I'm not home right now). There's also atleast two threads in > the > >> Verizon FiOS section on Broadband Reports: > >> > >> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds > >> > >> > http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr > >> > >> Derek > >> > >> > >> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia > >> > wrote: > >> > >> > I'd like to help, too, I'm from a TWC business class site with > >> 650 Mbps > >> > bandwidth and still regularly poor performance with YouTube. > >> > > >> > -Rick > >> > > >> > Sent from my iPhone 4S > >> > > >> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow > >> > > >> > wrote: > >> > > >> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter > >> > > >> > wrote: > >> > >> > >> > >> ----- Original Message ----- > >> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter > >> > >>> > wrote: > >> > >>>> > >> > >>>> We have recently been having some serious speed issues with > >> YouTube > >> > >>>> on our home connections, which are all Time Warner Cable. > >> > >>>> Some searching on forums and such revealed a work around: > >> > >>>> > >> > >>>> Block 206.111.0.0/16 at the router. > >> > >>> > >> > >>> this was reported elsewhere... it seems odd, since that's XO > >> space, > >> > >>> not Google and not TWC space. Would you care to engage in some > >> > >>> troubleshooting to help everyone out? :) > >> > >> > >> > >> I'll be happy to help troubleshoot in any way I can. > >> > > > >> > > excellent.. I'll arrange my ducks, let's chat offlist? > >> > > > >> > > >> > > >> > >> > > > From owen at delong.com Thu Mar 7 02:48:10 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Mar 2013 18:48:10 -0800 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <51378FD8.60804@mompl.net> References: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> <51378FD8.60804@mompl.net> Message-ID: <4B8AF397-9E59-4D7F-9536-76EF0FCCA599@delong.com> On Mar 6, 2013, at 10:50 AM, Jeroen van Aart wrote: > On 03/05/2013 05:41 PM, Owen DeLong wrote: >> I think it's also important to cover the following topics somewhere in the process: >> >> 1. This will affect the entire organization, not just the IT department and >> will definitely impact all of apps, sysadmin, devops, operations, and >> networking teams within the IT department. >> >> 2. Training will be required for virtually all levels of the organization. End users >> won't need more than a ~2 hour introduction to what to look for during and > > I've migrated (or enabled) offices (and homes) to IPv6 without them even realising it. If it's just enabling IPv6 connectivity there may be very little to be done with regards to training and informing end users. The beauty of IPv6 in my experience is that it is quite transparent, you don't even notice it is there (or shouldn't, if done properly). You can usually get away with this for the home. In the enterprise, I wouldn't recommend it. If the users get surprised, it's a lot worse than if they know what's coming. Rumors rapidly get way out of hand before corrective action can quell a problem. OTOH, if the user base knows what to expect and that the problems are anticipated and/or being properly worked, you tend to get a greater level of patience and understanding. Further, a little training up front can go a long way to getting better user reports into the help desk to reduce the time consumed in troubleshooting. As I said, a 2 hour introduction is about all that's required, but it really is helpful. As to other things, consider that once you enable stuff on IPv6, you need to be able to monitor it. If you're looking at IPv6 transition from an enterprise perspective, it's not just delivering IPv6 to every desktop, but making sure that all of your internal applications and services are also available on IPv6. That can be a significant development undertaking. I agree just enabling the network to use it is a useful and positive step forward that can be taken fairly easily. However, it's certainly not an end in and of itself and should not be where your efforts stop in any real plan. > Adapting your current software to IPv6, that could be more tricky. Although if you use the right IPv6 aware libraries and functions it could be relatively easy in code. In my own apps it's just a matter of changing the ai_family flag of getaddrinfo() to AF_UNSPEC if not done so yet. Although interestingly that may have complications (sudden loss of connectivity or more subtle issues). So I can relate to the fact it can be tricky. Yep. The important thing is for the enterprise to be aware of what is required and realize that it spans development, systems administration, networking, logistics, and will have end-user impacts worthy of some consideration. Owen From shortdudey123 at gmail.com Thu Mar 7 02:53:18 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 6 Mar 2013 20:53:18 -0600 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> Message-ID: One thing to keep in mind is that youtube may be anycast. Google's distributed file system is pretty amazing and it could be traffic to one specific datacenter that is possibly slow. -Grant On Wed, Mar 6, 2013 at 8:47 PM, Min wrote: > I use FIOS. In my case, I suspected two things. > > 1. congestion (my first hub appeared over subscribed) > 2. packet out of order (high packet drop in alternet-google could be > a symptom of multipath) > > Not sure which has bigger performance impact to youtube. > > Min > > On Wed, Mar 6, 2013 at 9:35 PM, Grant Ridder > wrote: > > The 1st one gets slow at XO and the 2nd and 3rd get slow at Sprint. > > > > Now the interesting one with XO is that it is routed in a /30 that is > > assigned to Google by XO. > > > > network:Class-Name:network > > network:ID:NET-XO-NET-d1302a54 > > network:Auth-Area:209.48.0.0/15 > > network:Network-Name:XO-NET-d1302a54 > > network:Organization;I:GOOGLE INC. (328874-1) > > network:IP-Network:209.48.42.84/30 > > network:Admin-Contact;I:XCIA-ARIN > > network:Tech-Contact;I:XCIA-ARIN > > network:Created:20120917 > > network:Updated:20121018 > > network:Updated-By:ipadmin at eng.xo.com > > > > -Grant > > > > On Wed, Mar 6, 2013 at 8:25 PM, Min wrote: > >> > >> 3 traces all indicated the last hub are 80~100ms faster than the > >> second last hub. Interesting. > >> > >> Min > >> > >> On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: > >> > I just got home and tested with quite a few 1080p videos. No issues > over > >> > my > >> > Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer > on > >> > my > >> > FiOS IPv4 connection. I have a 50 Mbps down connection and don't even > >> > come > >> > close to maxing it when watching Youtube videos. > >> > > >> > Here are a few traceroutes: > >> > > >> > [2.1-BETA0][root at pfsense]/root(1): traceroute > >> > r19---sn-p5qlsm7d.c.youtube.com > >> > traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 > hops > >> > max, > >> > 40 byte packets > >> > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms > 1.348 ms > >> > 0.834 ms > >> > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 > ms > >> > 2.589 ms 2.443 ms > >> > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms > >> > 14.614 > >> > ms 14.698 ms > >> > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms > >> > 14.696 ms 14.552 ms > >> > 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 > ms > >> > 15.064 ms > >> > 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms > >> > 36.033 > >> > ms 34.816 ms > >> > 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms > >> > 29.194 ms > >> > 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms > >> > 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms > >> > > >> > [2.1-BETA0][root at pfsense]/root(2): traceroute > >> > r15---sn-p5qlsm76.c.youtube.com > >> > traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 > hops > >> > max, > >> > 40 byte packets > >> > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms > 0.863 ms > >> > 0.968 ms > >> > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 > ms > >> > 2.265 ms 2.456 ms > >> > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms > >> > 14.666 > >> > ms 14.643 ms > >> > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms > >> > 14.479 ms 16.041 ms > >> > 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 > ms > >> > 14.975 ms > >> > 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms > >> > 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms > >> > sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms > >> > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms > >> > 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms > >> > 122.780 > >> > ms 121.535 ms > >> > 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms > >> > > >> > [2.1-BETA0][root at pfsense]/root(6): traceroute > >> > r10---sn-p5qlsm7l.c.youtube.com > >> > traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops > >> > max, > >> > 40 byte packets > >> > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms > 0.831 ms > >> > 0.806 ms > >> > 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 > ms > >> > 2.435 ms 2.167 ms > >> > 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms > >> > 14.767 ms 14.695 ms > >> > 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 > ms > >> > 15.024 ms > >> > 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms > >> > 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms > >> > 117.698 > >> > ms > >> > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms > >> > 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms > >> > 124.402 > >> > ms 125.384 ms > >> > 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms > >> > > >> > Derek > >> > > >> > On 3/6/2013 8:31 PM, Grant Ridder wrote: > >> >> > >> >> Can any one provide traceroutes to youtube to see if there is any > >> >> correlation between last mile providers? > >> >> > >> >> -Grant > >> >> > >> >> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >> >> > wrote: > >> >> > >> >> I don't think it's just Time Warner. Definitely looks like XO. I > >> >> have > >> >> Verizon FiOS and it was pretty bad for me as well (not sure if it > >> >> still is > >> >> since I'm not home right now). There's also atleast two threads > in > >> >> the > >> >> Verizon FiOS section on Broadband Reports: > >> >> > >> >> > http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds > >> >> > >> >> > >> >> > http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr > >> >> > >> >> Derek > >> >> > >> >> > >> >> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia > >> >> > wrote: > >> >> > >> >> > I'd like to help, too, I'm from a TWC business class site with > >> >> 650 Mbps > >> >> > bandwidth and still regularly poor performance with YouTube. > >> >> > > >> >> > -Rick > >> >> > > >> >> > Sent from my iPhone 4S > >> >> > > >> >> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow > >> >> > > >> >> > wrote: > >> >> > > >> >> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter > >> >> > > >> >> > wrote: > >> >> > >> > >> >> > >> ----- Original Message ----- > >> >> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter > >> >> > >>> > > wrote: > >> >> > >>>> > >> >> > >>>> We have recently been having some serious speed issues > with > >> >> YouTube > >> >> > >>>> on our home connections, which are all Time Warner Cable. > >> >> > >>>> Some searching on forums and such revealed a work around: > >> >> > >>>> > >> >> > >>>> Block 206.111.0.0/16 at the > router. > >> >> > >>> > >> >> > >>> this was reported elsewhere... it seems odd, since that's > XO > >> >> space, > >> >> > >>> not Google and not TWC space. Would you care to engage in > >> >> some > >> >> > >>> troubleshooting to help everyone out? :) > >> >> > >> > >> >> > >> I'll be happy to help troubleshoot in any way I can. > >> >> > > > >> >> > > excellent.. I'll arrange my ducks, let's chat offlist? > >> >> > > > >> >> > > >> >> > > >> >> > >> >> > >> > > > > > > From qiu.min98 at gmail.com Thu Mar 7 02:58:26 2013 From: qiu.min98 at gmail.com (Min) Date: Wed, 6 Mar 2013 21:58:26 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> Message-ID: I use FIOS. Here is my result: Host Loss% Snt Last Avg Best Wrst StDev 1. Wireless_Broadband_Router.home 0.0% 165 285.1 563.9 68.2 2007. 376.1 2. L100.WASHDC-VFTTP-127.verizon-gn 0.0% 165 299.8 560.3 59.1 2021. 384.4 3. G0-9-4-1.WASHDC-LCR-22.verizon-g 0.6% 165 241.3 698.7 64.6 24918 1938. 4. so-14-0-0-0.RES-BB-RTR1.verizon- 0.0% 165 217.2 705.7 100.6 24817 1926. 5. 0.xe-4-1-0.XL4.IAD8.ALTER.NET 0.0% 165 308.0 714.6 109.8 24717 1920. 6. TenGigE0-7-2-0.GW7.IAD8.ALTER.NE 0.0% 165 265.3 722.6 103.5 24617 1911. TenGigE0-7-0-0.GW7.IAD8.ALTER.NET TenGigE0-5-0-1.GW7.IAD8.ALTER.NET TenGigE0-7-1-0.GW7.IAD8.ALTER.NET TenGigE0-7-4-0.GW7.IAD8.ALTER.NET TenGigE0-5-0-0.GW7.IAD8.ALTER.NET 7. google-gw.customer.alter.net 59.4% 165 281.3 982.9 162.3 24516 2940. 8. 216.239.46.248 0.6% 164 247.3 726.7 112.2 24416 1903. 9. 72.14.238.173 0.0% 164 203.1 729.7 85.9 24315 1895. 10. iad23s05-in-f6.1e100.net 0.6% 164 343.2 712.9 35.1 24215 1890. In my case, I suspected two things. 1. congestion (verizon over subscribed) 2. packet out of order (high packet drops in alternet-google could be a symptom of multipath) Not sure which has bigger performance impact to youtube. Min On Wed, Mar 6, 2013 at 9:35 PM, Grant Ridder wrote: > The 1st one gets slow at XO and the 2nd and 3rd get slow at Sprint. > > Now the interesting one with XO is that it is routed in a /30 that is > assigned to Google by XO. > > network:Class-Name:network > network:ID:NET-XO-NET-d1302a54 > network:Auth-Area:209.48.0.0/15 > network:Network-Name:XO-NET-d1302a54 > network:Organization;I:GOOGLE INC. (328874-1) > network:IP-Network:209.48.42.84/30 > network:Admin-Contact;I:XCIA-ARIN > network:Tech-Contact;I:XCIA-ARIN > network:Created:20120917 > network:Updated:20121018 > network:Updated-By:ipadmin at eng.xo.com > > -Grant > > On Wed, Mar 6, 2013 at 8:25 PM, Min wrote: >> >> 3 traces all indicated the last hub are 80~100ms faster than the >> second last hub. Interesting. >> >> Min >> >> On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: >> > I just got home and tested with quite a few 1080p videos. No issues over >> > my >> > Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on >> > my >> > FiOS IPv4 connection. I have a 50 Mbps down connection and don't even >> > come >> > close to maxing it when watching Youtube videos. >> > >> > Here are a few traceroutes: >> > >> > [2.1-BETA0][root at pfsense]/root(1): traceroute >> > r19---sn-p5qlsm7d.c.youtube.com >> > traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops >> > max, >> > 40 byte packets >> > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms >> > 0.834 ms >> > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms >> > 2.589 ms 2.443 ms >> > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms >> > 14.614 >> > ms 14.698 ms >> > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms >> > 14.696 ms 14.552 ms >> > 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms >> > 15.064 ms >> > 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms >> > 36.033 >> > ms 34.816 ms >> > 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms >> > 29.194 ms >> > 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms >> > 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms >> > >> > [2.1-BETA0][root at pfsense]/root(2): traceroute >> > r15---sn-p5qlsm76.c.youtube.com >> > traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops >> > max, >> > 40 byte packets >> > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms >> > 0.968 ms >> > 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms >> > 2.265 ms 2.456 ms >> > 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms >> > 14.666 >> > ms 14.643 ms >> > 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms >> > 14.479 ms 16.041 ms >> > 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms >> > 14.975 ms >> > 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms >> > 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms >> > sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms >> > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms >> > 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms >> > 122.780 >> > ms 121.535 ms >> > 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms >> > >> > [2.1-BETA0][root at pfsense]/root(6): traceroute >> > r10---sn-p5qlsm7l.c.youtube.com >> > traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops >> > max, >> > 40 byte packets >> > 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms >> > 0.806 ms >> > 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms >> > 2.435 ms 2.167 ms >> > 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms >> > 14.767 ms 14.695 ms >> > 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms >> > 15.024 ms >> > 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms >> > 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms >> > 117.698 >> > ms >> > sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms >> > 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms >> > 124.402 >> > ms 125.384 ms >> > 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms >> > >> > Derek >> > >> > On 3/6/2013 8:31 PM, Grant Ridder wrote: >> >> >> >> Can any one provide traceroutes to youtube to see if there is any >> >> correlation between last mile providers? >> >> >> >> -Grant >> >> >> >> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey > >> > wrote: >> >> >> >> I don't think it's just Time Warner. Definitely looks like XO. I >> >> have >> >> Verizon FiOS and it was pretty bad for me as well (not sure if it >> >> still is >> >> since I'm not home right now). There's also atleast two threads in >> >> the >> >> Verizon FiOS section on Broadband Reports: >> >> >> >> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds >> >> >> >> >> >> http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr >> >> >> >> Derek >> >> >> >> >> >> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia >> >> > wrote: >> >> >> >> > I'd like to help, too, I'm from a TWC business class site with >> >> 650 Mbps >> >> > bandwidth and still regularly poor performance with YouTube. >> >> > >> >> > -Rick >> >> > >> >> > Sent from my iPhone 4S >> >> > >> >> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow >> >> > >> >> > wrote: >> >> > >> >> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter >> >> > >> >> > wrote: >> >> > >> >> >> > >> ----- Original Message ----- >> >> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >> >> > >>> > wrote: >> >> > >>>> >> >> > >>>> We have recently been having some serious speed issues with >> >> YouTube >> >> > >>>> on our home connections, which are all Time Warner Cable. >> >> > >>>> Some searching on forums and such revealed a work around: >> >> > >>>> >> >> > >>>> Block 206.111.0.0/16 at the router. >> >> > >>> >> >> > >>> this was reported elsewhere... it seems odd, since that's XO >> >> space, >> >> > >>> not Google and not TWC space. Would you care to engage in >> >> some >> >> > >>> troubleshooting to help everyone out? :) >> >> > >> >> >> > >> I'll be happy to help troubleshoot in any way I can. >> >> > > >> >> > > excellent.. I'll arrange my ducks, let's chat offlist? >> >> > > >> >> > >> >> > >> >> >> >> >> > > > From derek at derekivey.com Thu Mar 7 03:03:36 2013 From: derek at derekivey.com (Derek Ivey) Date: Wed, 06 Mar 2013 22:03:36 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> Message-ID: <51380388.7050502@derekivey.com> Why are your response times so high at your first hop? Are you maxing out your connection or connected to your router over wireless? Derek On 3/6/2013 9:58 PM, Min wrote: > I use FIOS. Here is my result: > > Host Loss% Snt Last Avg Best Wrst StDev > 1. Wireless_Broadband_Router.home 0.0% 165 285.1 563.9 68.2 2007. 376.1 > 2. L100.WASHDC-VFTTP-127.verizon-gn 0.0% 165 299.8 560.3 59.1 2021. 384.4 > 3. G0-9-4-1.WASHDC-LCR-22.verizon-g 0.6% 165 241.3 698.7 64.6 24918 1938. > 4. so-14-0-0-0.RES-BB-RTR1.verizon- 0.0% 165 217.2 705.7 100.6 24817 1926. > 5. 0.xe-4-1-0.XL4.IAD8.ALTER.NET 0.0% 165 308.0 714.6 109.8 24717 1920. > 6. TenGigE0-7-2-0.GW7.IAD8.ALTER.NE 0.0% 165 265.3 722.6 103.5 24617 1911. > TenGigE0-7-0-0.GW7.IAD8.ALTER.NET > TenGigE0-5-0-1.GW7.IAD8.ALTER.NET > TenGigE0-7-1-0.GW7.IAD8.ALTER.NET > TenGigE0-7-4-0.GW7.IAD8.ALTER.NET > TenGigE0-5-0-0.GW7.IAD8.ALTER.NET > 7. google-gw.customer.alter.net 59.4% 165 281.3 982.9 162.3 24516 2940. > 8. 216.239.46.248 0.6% 164 247.3 726.7 112.2 24416 1903. > 9. 72.14.238.173 0.0% 164 203.1 729.7 85.9 24315 1895. > 10. iad23s05-in-f6.1e100.net 0.6% 164 343.2 712.9 35.1 24215 1890. > > In my case, I suspected two things. > > 1. congestion (verizon over subscribed) > 2. packet out of order (high packet drops in alternet-google could be > a symptom of multipath) > > Not sure which has bigger performance impact to youtube. > > Min > > On Wed, Mar 6, 2013 at 9:35 PM, Grant Ridder wrote: >> The 1st one gets slow at XO and the 2nd and 3rd get slow at Sprint. >> >> Now the interesting one with XO is that it is routed in a /30 that is >> assigned to Google by XO. >> >> network:Class-Name:network >> network:ID:NET-XO-NET-d1302a54 >> network:Auth-Area:209.48.0.0/15 >> network:Network-Name:XO-NET-d1302a54 >> network:Organization;I:GOOGLE INC. (328874-1) >> network:IP-Network:209.48.42.84/30 >> network:Admin-Contact;I:XCIA-ARIN >> network:Tech-Contact;I:XCIA-ARIN >> network:Created:20120917 >> network:Updated:20121018 >> network:Updated-By:ipadmin at eng.xo.com >> >> -Grant >> >> On Wed, Mar 6, 2013 at 8:25 PM, Min wrote: >>> 3 traces all indicated the last hub are 80~100ms faster than the >>> second last hub. Interesting. >>> >>> Min >>> >>> On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: >>>> I just got home and tested with quite a few 1080p videos. No issues over >>>> my >>>> Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on >>>> my >>>> FiOS IPv4 connection. I have a 50 Mbps down connection and don't even >>>> come >>>> close to maxing it when watching Youtube videos. >>>> >>>> Here are a few traceroutes: >>>> >>>> [2.1-BETA0][root at pfsense]/root(1): traceroute >>>> r19---sn-p5qlsm7d.c.youtube.com >>>> traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops >>>> max, >>>> 40 byte packets >>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms >>>> 0.834 ms >>>> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms >>>> 2.589 ms 2.443 ms >>>> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms >>>> 14.614 >>>> ms 14.698 ms >>>> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms >>>> 14.696 ms 14.552 ms >>>> 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms >>>> 15.064 ms >>>> 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms >>>> 36.033 >>>> ms 34.816 ms >>>> 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms >>>> 29.194 ms >>>> 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms >>>> 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms >>>> >>>> [2.1-BETA0][root at pfsense]/root(2): traceroute >>>> r15---sn-p5qlsm76.c.youtube.com >>>> traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops >>>> max, >>>> 40 byte packets >>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms >>>> 0.968 ms >>>> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms >>>> 2.265 ms 2.456 ms >>>> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms >>>> 14.666 >>>> ms 14.643 ms >>>> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms >>>> 14.479 ms 16.041 ms >>>> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms >>>> 14.975 ms >>>> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms >>>> 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms >>>> sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms >>>> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms >>>> 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms >>>> 122.780 >>>> ms 121.535 ms >>>> 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms >>>> >>>> [2.1-BETA0][root at pfsense]/root(6): traceroute >>>> r10---sn-p5qlsm7l.c.youtube.com >>>> traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops >>>> max, >>>> 40 byte packets >>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms >>>> 0.806 ms >>>> 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms >>>> 2.435 ms 2.167 ms >>>> 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms >>>> 14.767 ms 14.695 ms >>>> 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms >>>> 15.024 ms >>>> 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms >>>> 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms >>>> 117.698 >>>> ms >>>> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms >>>> 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms >>>> 124.402 >>>> ms 125.384 ms >>>> 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms >>>> >>>> Derek >>>> >>>> On 3/6/2013 8:31 PM, Grant Ridder wrote: >>>>> Can any one provide traceroutes to youtube to see if there is any >>>>> correlation between last mile providers? >>>>> >>>>> -Grant >>>>> >>>>> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >>>> > wrote: >>>>> >>>>> I don't think it's just Time Warner. Definitely looks like XO. I >>>>> have >>>>> Verizon FiOS and it was pretty bad for me as well (not sure if it >>>>> still is >>>>> since I'm not home right now). There's also atleast two threads in >>>>> the >>>>> Verizon FiOS section on Broadband Reports: >>>>> >>>>> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds >>>>> >>>>> >>>>> http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr >>>>> >>>>> Derek >>>>> >>>>> >>>>> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia >>>>> > wrote: >>>>> >>>>> > I'd like to help, too, I'm from a TWC business class site with >>>>> 650 Mbps >>>>> > bandwidth and still regularly poor performance with YouTube. >>>>> > >>>>> > -Rick >>>>> > >>>>> > Sent from my iPhone 4S >>>>> > >>>>> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow >>>>> > >>>>> > wrote: >>>>> > >>>>> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter >>>>> > >>>>> > wrote: >>>>> > >> >>>>> > >> ----- Original Message ----- >>>>> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >>>>> > >>> > wrote: >>>>> > >>>> >>>>> > >>>> We have recently been having some serious speed issues with >>>>> YouTube >>>>> > >>>> on our home connections, which are all Time Warner Cable. >>>>> > >>>> Some searching on forums and such revealed a work around: >>>>> > >>>> >>>>> > >>>> Block 206.111.0.0/16 at the router. >>>>> > >>> >>>>> > >>> this was reported elsewhere... it seems odd, since that's XO >>>>> space, >>>>> > >>> not Google and not TWC space. Would you care to engage in >>>>> some >>>>> > >>> troubleshooting to help everyone out? :) >>>>> > >> >>>>> > >> I'll be happy to help troubleshoot in any way I can. >>>>> > > >>>>> > > excellent.. I'll arrange my ducks, let's chat offlist? >>>>> > > >>>>> > >>>>> > >>>>> >>>>> >> From qiu.min98 at gmail.com Thu Mar 7 03:09:16 2013 From: qiu.min98 at gmail.com (Min) Date: Wed, 6 Mar 2013 22:09:16 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <51380388.7050502@derekivey.com> References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> <51380388.7050502@derekivey.com> Message-ID: yes, i'm use wireless at home. On Wed, Mar 6, 2013 at 10:03 PM, Derek Ivey wrote: > Why are your response times so high at your first hop? Are you maxing out > your connection or connected to your router over wireless? > > Derek > > On 3/6/2013 9:58 PM, Min wrote: >> >> I use FIOS. Here is my result: >> >> Host Loss% Snt Last Avg Best Wrst >> StDev >> 1. Wireless_Broadband_Router.home 0.0% 165 285.1 563.9 68.2 2007. >> 376.1 >> 2. L100.WASHDC-VFTTP-127.verizon-gn 0.0% 165 299.8 560.3 59.1 2021. >> 384.4 >> 3. G0-9-4-1.WASHDC-LCR-22.verizon-g 0.6% 165 241.3 698.7 64.6 24918 >> 1938. >> 4. so-14-0-0-0.RES-BB-RTR1.verizon- 0.0% 165 217.2 705.7 100.6 24817 >> 1926. >> 5. 0.xe-4-1-0.XL4.IAD8.ALTER.NET 0.0% 165 308.0 714.6 109.8 24717 >> 1920. >> 6. TenGigE0-7-2-0.GW7.IAD8.ALTER.NE 0.0% 165 265.3 722.6 103.5 24617 >> 1911. >> TenGigE0-7-0-0.GW7.IAD8.ALTER.NET >> TenGigE0-5-0-1.GW7.IAD8.ALTER.NET >> TenGigE0-7-1-0.GW7.IAD8.ALTER.NET >> TenGigE0-7-4-0.GW7.IAD8.ALTER.NET >> TenGigE0-5-0-0.GW7.IAD8.ALTER.NET >> 7. google-gw.customer.alter.net 59.4% 165 281.3 982.9 162.3 24516 >> 2940. >> 8. 216.239.46.248 0.6% 164 247.3 726.7 112.2 24416 >> 1903. >> 9. 72.14.238.173 0.0% 164 203.1 729.7 85.9 24315 >> 1895. >> 10. iad23s05-in-f6.1e100.net 0.6% 164 343.2 712.9 35.1 24215 >> 1890. >> >> In my case, I suspected two things. >> >> 1. congestion (verizon over subscribed) >> 2. packet out of order (high packet drops in alternet-google could be >> a symptom of multipath) >> >> Not sure which has bigger performance impact to youtube. >> >> Min >> >> On Wed, Mar 6, 2013 at 9:35 PM, Grant Ridder >> wrote: >>> >>> The 1st one gets slow at XO and the 2nd and 3rd get slow at Sprint. >>> >>> Now the interesting one with XO is that it is routed in a /30 that is >>> assigned to Google by XO. >>> >>> network:Class-Name:network >>> network:ID:NET-XO-NET-d1302a54 >>> network:Auth-Area:209.48.0.0/15 >>> network:Network-Name:XO-NET-d1302a54 >>> network:Organization;I:GOOGLE INC. (328874-1) >>> network:IP-Network:209.48.42.84/30 >>> network:Admin-Contact;I:XCIA-ARIN >>> network:Tech-Contact;I:XCIA-ARIN >>> network:Created:20120917 >>> network:Updated:20121018 >>> network:Updated-By:ipadmin at eng.xo.com >>> >>> -Grant >>> >>> On Wed, Mar 6, 2013 at 8:25 PM, Min wrote: >>>> >>>> 3 traces all indicated the last hub are 80~100ms faster than the >>>> second last hub. Interesting. >>>> >>>> Min >>>> >>>> On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: >>>>> >>>>> I just got home and tested with quite a few 1080p videos. No issues >>>>> over >>>>> my >>>>> Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer >>>>> on >>>>> my >>>>> FiOS IPv4 connection. I have a 50 Mbps down connection and don't even >>>>> come >>>>> close to maxing it when watching Youtube videos. >>>>> >>>>> Here are a few traceroutes: >>>>> >>>>> [2.1-BETA0][root at pfsense]/root(1): traceroute >>>>> r19---sn-p5qlsm7d.c.youtube.com >>>>> traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops >>>>> max, >>>>> 40 byte packets >>>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 >>>>> ms >>>>> 0.834 ms >>>>> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 >>>>> ms >>>>> 2.589 ms 2.443 ms >>>>> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms >>>>> 14.614 >>>>> ms 14.698 ms >>>>> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms >>>>> 14.696 ms 14.552 ms >>>>> 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms >>>>> 15.064 ms >>>>> 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms >>>>> 36.033 >>>>> ms 34.816 ms >>>>> 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms >>>>> 29.194 ms >>>>> 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms >>>>> 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms >>>>> >>>>> [2.1-BETA0][root at pfsense]/root(2): traceroute >>>>> r15---sn-p5qlsm76.c.youtube.com >>>>> traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops >>>>> max, >>>>> 40 byte packets >>>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 >>>>> ms >>>>> 0.968 ms >>>>> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 >>>>> ms >>>>> 2.265 ms 2.456 ms >>>>> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms >>>>> 14.666 >>>>> ms 14.643 ms >>>>> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms >>>>> 14.479 ms 16.041 ms >>>>> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 >>>>> ms >>>>> 14.975 ms >>>>> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms >>>>> 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms >>>>> sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms >>>>> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms >>>>> 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms >>>>> 122.780 >>>>> ms 121.535 ms >>>>> 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms >>>>> >>>>> [2.1-BETA0][root at pfsense]/root(6): traceroute >>>>> r10---sn-p5qlsm7l.c.youtube.com >>>>> traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops >>>>> max, >>>>> 40 byte packets >>>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 >>>>> ms >>>>> 0.806 ms >>>>> 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms >>>>> 2.435 ms 2.167 ms >>>>> 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms >>>>> 14.767 ms 14.695 ms >>>>> 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 >>>>> ms >>>>> 15.024 ms >>>>> 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms >>>>> 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms >>>>> 117.698 >>>>> ms >>>>> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms >>>>> 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms >>>>> 124.402 >>>>> ms 125.384 ms >>>>> 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms >>>>> >>>>> Derek >>>>> >>>>> On 3/6/2013 8:31 PM, Grant Ridder wrote: >>>>>> >>>>>> Can any one provide traceroutes to youtube to see if there is any >>>>>> correlation between last mile providers? >>>>>> >>>>>> -Grant >>>>>> >>>>>> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >>>>> > wrote: >>>>>> >>>>>> I don't think it's just Time Warner. Definitely looks like XO. I >>>>>> have >>>>>> Verizon FiOS and it was pretty bad for me as well (not sure if it >>>>>> still is >>>>>> since I'm not home right now). There's also atleast two threads >>>>>> in >>>>>> the >>>>>> Verizon FiOS section on Broadband Reports: >>>>>> >>>>>> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds >>>>>> >>>>>> >>>>>> >>>>>> http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr >>>>>> >>>>>> Derek >>>>>> >>>>>> >>>>>> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia >>>>>> > wrote: >>>>>> >>>>>> > I'd like to help, too, I'm from a TWC business class site with >>>>>> 650 Mbps >>>>>> > bandwidth and still regularly poor performance with YouTube. >>>>>> > >>>>>> > -Rick >>>>>> > >>>>>> > Sent from my iPhone 4S >>>>>> > >>>>>> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow >>>>>> > >>>>>> > wrote: >>>>>> > >>>>>> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter >>>>>> > >>>>>> > wrote: >>>>>> > >> >>>>>> > >> ----- Original Message ----- >>>>>> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >>>>>> > >>> > wrote: >>>>>> > >>>> >>>>>> > >>>> We have recently been having some serious speed issues >>>>>> with >>>>>> YouTube >>>>>> > >>>> on our home connections, which are all Time Warner Cable. >>>>>> > >>>> Some searching on forums and such revealed a work around: >>>>>> > >>>> >>>>>> > >>>> Block 206.111.0.0/16 at the >>>>>> router. >>>>>> > >>> >>>>>> > >>> this was reported elsewhere... it seems odd, since that's >>>>>> XO >>>>>> space, >>>>>> > >>> not Google and not TWC space. Would you care to engage in >>>>>> some >>>>>> > >>> troubleshooting to help everyone out? :) >>>>>> > >> >>>>>> > >> I'll be happy to help troubleshoot in any way I can. >>>>>> > > >>>>>> > > excellent.. I'll arrange my ducks, let's chat offlist? >>>>>> > > >>>>>> > >>>>>> > >>>>>> >>>>>> >>> > From derek at derekivey.com Thu Mar 7 03:08:48 2013 From: derek at derekivey.com (Derek Ivey) Date: Wed, 06 Mar 2013 22:08:48 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> <51380388.7050502@derekivey.com> Message-ID: <513804C0.2010701@derekivey.com> That looks like your problem right there. Have you tried connecting via ethernet instead and seeing how Youtube performs? On 3/6/2013 10:09 PM, Min wrote: > yes, i'm use wireless at home. > > On Wed, Mar 6, 2013 at 10:03 PM, Derek Ivey wrote: >> Why are your response times so high at your first hop? Are you maxing out >> your connection or connected to your router over wireless? >> >> Derek >> >> On 3/6/2013 9:58 PM, Min wrote: >>> I use FIOS. Here is my result: >>> >>> Host Loss% Snt Last Avg Best Wrst >>> StDev >>> 1. Wireless_Broadband_Router.home 0.0% 165 285.1 563.9 68.2 2007. >>> 376.1 >>> 2. L100.WASHDC-VFTTP-127.verizon-gn 0.0% 165 299.8 560.3 59.1 2021. >>> 384.4 >>> 3. G0-9-4-1.WASHDC-LCR-22.verizon-g 0.6% 165 241.3 698.7 64.6 24918 >>> 1938. >>> 4. so-14-0-0-0.RES-BB-RTR1.verizon- 0.0% 165 217.2 705.7 100.6 24817 >>> 1926. >>> 5. 0.xe-4-1-0.XL4.IAD8.ALTER.NET 0.0% 165 308.0 714.6 109.8 24717 >>> 1920. >>> 6. TenGigE0-7-2-0.GW7.IAD8.ALTER.NE 0.0% 165 265.3 722.6 103.5 24617 >>> 1911. >>> TenGigE0-7-0-0.GW7.IAD8.ALTER.NET >>> TenGigE0-5-0-1.GW7.IAD8.ALTER.NET >>> TenGigE0-7-1-0.GW7.IAD8.ALTER.NET >>> TenGigE0-7-4-0.GW7.IAD8.ALTER.NET >>> TenGigE0-5-0-0.GW7.IAD8.ALTER.NET >>> 7. google-gw.customer.alter.net 59.4% 165 281.3 982.9 162.3 24516 >>> 2940. >>> 8. 216.239.46.248 0.6% 164 247.3 726.7 112.2 24416 >>> 1903. >>> 9. 72.14.238.173 0.0% 164 203.1 729.7 85.9 24315 >>> 1895. >>> 10. iad23s05-in-f6.1e100.net 0.6% 164 343.2 712.9 35.1 24215 >>> 1890. >>> >>> In my case, I suspected two things. >>> >>> 1. congestion (verizon over subscribed) >>> 2. packet out of order (high packet drops in alternet-google could be >>> a symptom of multipath) >>> >>> Not sure which has bigger performance impact to youtube. >>> >>> Min >>> >>> On Wed, Mar 6, 2013 at 9:35 PM, Grant Ridder >>> wrote: >>>> The 1st one gets slow at XO and the 2nd and 3rd get slow at Sprint. >>>> >>>> Now the interesting one with XO is that it is routed in a /30 that is >>>> assigned to Google by XO. >>>> >>>> network:Class-Name:network >>>> network:ID:NET-XO-NET-d1302a54 >>>> network:Auth-Area:209.48.0.0/15 >>>> network:Network-Name:XO-NET-d1302a54 >>>> network:Organization;I:GOOGLE INC. (328874-1) >>>> network:IP-Network:209.48.42.84/30 >>>> network:Admin-Contact;I:XCIA-ARIN >>>> network:Tech-Contact;I:XCIA-ARIN >>>> network:Created:20120917 >>>> network:Updated:20121018 >>>> network:Updated-By:ipadmin at eng.xo.com >>>> >>>> -Grant >>>> >>>> On Wed, Mar 6, 2013 at 8:25 PM, Min wrote: >>>>> 3 traces all indicated the last hub are 80~100ms faster than the >>>>> second last hub. Interesting. >>>>> >>>>> Min >>>>> >>>>> On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: >>>>>> I just got home and tested with quite a few 1080p videos. No issues >>>>>> over >>>>>> my >>>>>> Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer >>>>>> on >>>>>> my >>>>>> FiOS IPv4 connection. I have a 50 Mbps down connection and don't even >>>>>> come >>>>>> close to maxing it when watching Youtube videos. >>>>>> >>>>>> Here are a few traceroutes: >>>>>> >>>>>> [2.1-BETA0][root at pfsense]/root(1): traceroute >>>>>> r19---sn-p5qlsm7d.c.youtube.com >>>>>> traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops >>>>>> max, >>>>>> 40 byte packets >>>>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 >>>>>> ms >>>>>> 0.834 ms >>>>>> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 >>>>>> ms >>>>>> 2.589 ms 2.443 ms >>>>>> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms >>>>>> 14.614 >>>>>> ms 14.698 ms >>>>>> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms >>>>>> 14.696 ms 14.552 ms >>>>>> 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms >>>>>> 15.064 ms >>>>>> 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms >>>>>> 36.033 >>>>>> ms 34.816 ms >>>>>> 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms >>>>>> 29.194 ms >>>>>> 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms >>>>>> 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms >>>>>> >>>>>> [2.1-BETA0][root at pfsense]/root(2): traceroute >>>>>> r15---sn-p5qlsm76.c.youtube.com >>>>>> traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops >>>>>> max, >>>>>> 40 byte packets >>>>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 >>>>>> ms >>>>>> 0.968 ms >>>>>> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 >>>>>> ms >>>>>> 2.265 ms 2.456 ms >>>>>> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms >>>>>> 14.666 >>>>>> ms 14.643 ms >>>>>> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms >>>>>> 14.479 ms 16.041 ms >>>>>> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 >>>>>> ms >>>>>> 14.975 ms >>>>>> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms >>>>>> 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms >>>>>> sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms >>>>>> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms >>>>>> 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms >>>>>> 122.780 >>>>>> ms 121.535 ms >>>>>> 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms >>>>>> >>>>>> [2.1-BETA0][root at pfsense]/root(6): traceroute >>>>>> r10---sn-p5qlsm7l.c.youtube.com >>>>>> traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops >>>>>> max, >>>>>> 40 byte packets >>>>>> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 >>>>>> ms >>>>>> 0.806 ms >>>>>> 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms >>>>>> 2.435 ms 2.167 ms >>>>>> 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms >>>>>> 14.767 ms 14.695 ms >>>>>> 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 >>>>>> ms >>>>>> 15.024 ms >>>>>> 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms >>>>>> 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms >>>>>> 117.698 >>>>>> ms >>>>>> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms >>>>>> 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms >>>>>> 124.402 >>>>>> ms 125.384 ms >>>>>> 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms >>>>>> >>>>>> Derek >>>>>> >>>>>> On 3/6/2013 8:31 PM, Grant Ridder wrote: >>>>>>> Can any one provide traceroutes to youtube to see if there is any >>>>>>> correlation between last mile providers? >>>>>>> >>>>>>> -Grant >>>>>>> >>>>>>> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >>>>>> > wrote: >>>>>>> >>>>>>> I don't think it's just Time Warner. Definitely looks like XO. I >>>>>>> have >>>>>>> Verizon FiOS and it was pretty bad for me as well (not sure if it >>>>>>> still is >>>>>>> since I'm not home right now). There's also atleast two threads >>>>>>> in >>>>>>> the >>>>>>> Verizon FiOS section on Broadband Reports: >>>>>>> >>>>>>> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr >>>>>>> >>>>>>> Derek >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia >>>>>>> > wrote: >>>>>>> >>>>>>> > I'd like to help, too, I'm from a TWC business class site with >>>>>>> 650 Mbps >>>>>>> > bandwidth and still regularly poor performance with YouTube. >>>>>>> > >>>>>>> > -Rick >>>>>>> > >>>>>>> > Sent from my iPhone 4S >>>>>>> > >>>>>>> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow >>>>>>> > >>>>>>> > wrote: >>>>>>> > >>>>>>> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter >>>>>>> > >>>>>>> > wrote: >>>>>>> > >> >>>>>>> > >> ----- Original Message ----- >>>>>>> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >>>>>>> > >>> > wrote: >>>>>>> > >>>> >>>>>>> > >>>> We have recently been having some serious speed issues >>>>>>> with >>>>>>> YouTube >>>>>>> > >>>> on our home connections, which are all Time Warner Cable. >>>>>>> > >>>> Some searching on forums and such revealed a work around: >>>>>>> > >>>> >>>>>>> > >>>> Block 206.111.0.0/16 at the >>>>>>> router. >>>>>>> > >>> >>>>>>> > >>> this was reported elsewhere... it seems odd, since that's >>>>>>> XO >>>>>>> space, >>>>>>> > >>> not Google and not TWC space. Would you care to engage in >>>>>>> some >>>>>>> > >>> troubleshooting to help everyone out? :) >>>>>>> > >> >>>>>>> > >> I'll be happy to help troubleshoot in any way I can. >>>>>>> > > >>>>>>> > > excellent.. I'll arrange my ducks, let's chat offlist? >>>>>>> > > >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> From kauer at biplane.com.au Thu Mar 7 03:31:54 2013 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 07 Mar 2013 14:31:54 +1100 Subject: Migrating IPv6 (was Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?) In-Reply-To: <4B8AF397-9E59-4D7F-9536-76EF0FCCA599@delong.com> References: <006572C7-3081-4A73-A7C0-79B6A1DD6326@delong.com> <51378FD8.60804@mompl.net> <4B8AF397-9E59-4D7F-9536-76EF0FCCA599@delong.com> Message-ID: <1362627114.3387.555.camel@karl> On Wed, 2013-03-06 at 18:48 -0800, Owen DeLong wrote: > On Mar 6, 2013, at 10:50 AM, Jeroen van Aart wrote: > > Adapting your current software to IPv6, that could be more tricky. > Although if you use the right IPv6 aware libraries and functions it > could be relatively easy in code. In my own apps it's just a matter of > changing the ai_family flag of getaddrinfo() to AF_UNSPEC if not done > so yet.[...] > > Yep. The important thing is for the enterprise to be aware of what is > required and realize that it spans development, systems > administration, networking, logistics, and will have end-user impacts > worthy of some consideration. People adapting stuff to IPv6 may find this blog entry of mine useful: http://biplane.com.au/blog/?p=179 It says "Java" in the title, but the principles are pretty much the same for anything... Java has a class that encapsulates "IP address", regardless of address family, so if your stuff was written with that it's a lot easier to migrate some stuff. The same will be true of any language with a similar abstraction. But you can't get away from print and display changes, for example, where the physical space required, that is, the real estate on screen or paper, is about three times larger for IPv6 than IPv4. And you can't get away from the end-user impact of the new and unknown; IPv6 is transparent only up to the first support call... In technical forums I find myself saying things like "bee thousand" for "b000", "ay thousand dee zero" for "a0d0" and on one occasion even "ay thousand and deety". It seems very natural and right to me and most people seem to understand it without much effort, but boy, does it get me strange looks sometimes :-) No-one looks askance when you say "one ninety two dot one sixty eight dot one dot one", but that's pretty weird too, really. I guess we (the wider IPv6 using community) will have to develop a human vocabulary for IPv6 as well as a technical one :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From john at razorservers.com Thu Mar 7 03:38:57 2013 From: john at razorservers.com (John Zettlemoyer) Date: Wed, 6 Mar 2013 22:38:57 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: Message-ID: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> I've been seeing the same thing and was thinking it was me. Just to add to some of the results here... Verizon FIOS 1 32 ms 3 ms 5 ms l100.cmdnnj-vfttp-27.verizon-gni.net [98.110.113.1] 2 33 ms 6 ms 7 ms g0-3-3-7.cmdnnj-lcr-22.verizon-gni.net [130.81.183.186] 3 22 ms 22 ms 21 ms xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net [130.81.209.84] 4 22 ms 21 ms 21 ms 0.so-0-0-0.xt2.nyc4.alter.net [152.63.17.21] 5 58 ms 24 ms 24 ms tengige0-5-4-0.gw8.nyc4.alter.net [152.63.18.206] 6 * 76 ms 76 ms google-gw.customer.alter.net [152.179.72.62] 7 25 ms 21 ms 24 ms 209.85.255.68 8 21 ms 34 ms 34 ms 209.85.252.242 9 30 ms 28 ms 31 ms 209.85.249.11 10 31 ms 29 ms 29 ms 72.14.236.149 11 38 ms 36 ms 36 ms 72.14.238.173 12 31 ms 29 ms 31 ms iad23s05-in-f8.1e100.net [74.125.228.8] Comcast 1 33 ms 15 ms 25 ms 68.38.220.1 2 8 ms 10 ms 15 ms xe-11-3-0-0-sur01.burlington.nj.panjde.comcast.net [68.85.128.237] 3 10 ms 9 ms 9 ms xe-13-0-0-0-ar03.audubon.nj.panjde.comcast.net [68.85.62.89] 4 14 ms 15 ms 15 ms pos-3-6-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.92.161] 5 15 ms 13 ms 14 ms pos-0-0-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.26] 6 * 23 ms 25 ms 75.149.231.62 7 17 ms 15 ms 14 ms 209.85.252.46 8 17 ms 16 ms 15 ms 72.14.238.173 9 17 ms 15 ms 16 ms iad23s05-in-f8.1e100.net [74.125.228.8] Our datacenter 1 <1 ms <1 ms <1 ms static.razorinc.net [70.34.208.101] 2 <1 ms <1 ms <1 ms 70.34.251.9 3 <1 ms <1 ms <1 ms xe-0-2-0.phi10.ip4.tinet.net [199.168.63.233] 4 2 ms 3 ms 2 ms xe-7-2-1.was14.ip4.tinet.net [89.149.181.174] 5 3 ms 3 ms 3 ms 72.14.213.61 6 4 ms 4 ms 4 ms 216.239.46.248 7 5 ms 5 ms 5 ms 72.14.238.173 8 5 ms 5 ms 5 ms iad23s05-in-f8.1e100.net [74.125.228.8] It would be nice if the ISPs and content providers could work out something when dealing with this much traffic and clearly needing to add capaicty. It's nice to dream too... ? John From derek at derekivey.com Thu Mar 7 03:43:16 2013 From: derek at derekivey.com (Derek Ivey) Date: Wed, 6 Mar 2013 22:43:16 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <513809EC.6090604@enger.us> References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> <51380388.7050502@derekivey.com> <513809EC.6090604@enger.us> Message-ID: <440833A6-032F-4193-98E5-B97D5ABF8674@derekivey.com> On Mar 6, 2013, at 10:30 PM, "Robert M. Enger" wrote: > > 1) You can use wireshark or other monitor to determine the IP address that your video stream is originating from. I just used the Developer Tools in Google Chrome to figure this out. > > 2) Upstream traceroutes to that address are probably not of that much interest. The downstream path (carrying the video from the server to your house) can follow a different path. Downstream traceroute is what is needed. Good point. > > 3) Before pointing fingers at anyone, you need to get your own house (literally) in order. Get off wifi, that is just muddying the water. Shutdown wifi so there are no other users. Get off MocA. You need to be all hard-wired and totally error free and reliable in your local LAN before you can cast stones at carriers and/or inter-carrier interconnection Agreed. My trace routes were straight from my pfsense firewall, which is connected to my ONT via ethernet (I specifically asked Verizon to turn the ethernet port on instead of MoCA when I had it setup over 2 years ago). Derek From derek at derekivey.com Thu Mar 7 03:47:38 2013 From: derek at derekivey.com (Derek Ivey) Date: Wed, 6 Mar 2013 22:47:38 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> References: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> Message-ID: <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> I think your trace routes are just to their web servers. You need to figure out where the actual videos are being streamed from. I used the Developer Tools (Network tab) in Google Chrome to figure this out. The FQDNs will probably look like the ones in my trace routes. Derek On Mar 6, 2013, at 10:38 PM, John Zettlemoyer wrote: > I've been seeing the same thing and was thinking it was me. > Just to add to some of the results here... > > Verizon FIOS > 1 32 ms 3 ms 5 ms l100.cmdnnj-vfttp-27.verizon-gni.net [98.110.113.1] > 2 33 ms 6 ms 7 ms g0-3-3-7.cmdnnj-lcr-22.verizon-gni.net [130.81.183.186] > 3 22 ms 22 ms 21 ms xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net [130.81.209.84] > 4 22 ms 21 ms 21 ms 0.so-0-0-0.xt2.nyc4.alter.net [152.63.17.21] > 5 58 ms 24 ms 24 ms tengige0-5-4-0.gw8.nyc4.alter.net [152.63.18.206] > 6 * 76 ms 76 ms google-gw.customer.alter.net [152.179.72.62] > 7 25 ms 21 ms 24 ms 209.85.255.68 > 8 21 ms 34 ms 34 ms 209.85.252.242 > 9 30 ms 28 ms 31 ms 209.85.249.11 > 10 31 ms 29 ms 29 ms 72.14.236.149 > 11 38 ms 36 ms 36 ms 72.14.238.173 > 12 31 ms 29 ms 31 ms iad23s05-in-f8.1e100.net [74.125.228.8] > > > Comcast > 1 33 ms 15 ms 25 ms 68.38.220.1 > 2 8 ms 10 ms 15 ms xe-11-3-0-0-sur01.burlington.nj.panjde.comcast.net [68.85.128.237] > 3 10 ms 9 ms 9 ms xe-13-0-0-0-ar03.audubon.nj.panjde.comcast.net [68.85.62.89] > 4 14 ms 15 ms 15 ms pos-3-6-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.92.161] > 5 15 ms 13 ms 14 ms pos-0-0-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.26] > 6 * 23 ms 25 ms 75.149.231.62 > 7 17 ms 15 ms 14 ms 209.85.252.46 > 8 17 ms 16 ms 15 ms 72.14.238.173 > 9 17 ms 15 ms 16 ms iad23s05-in-f8.1e100.net [74.125.228.8] > > > Our datacenter > 1 <1 ms <1 ms <1 ms static.razorinc.net [70.34.208.101] > 2 <1 ms <1 ms <1 ms 70.34.251.9 > 3 <1 ms <1 ms <1 ms xe-0-2-0.phi10.ip4.tinet.net [199.168.63.233] > 4 2 ms 3 ms 2 ms xe-7-2-1.was14.ip4.tinet.net [89.149.181.174] > 5 3 ms 3 ms 3 ms 72.14.213.61 > 6 4 ms 4 ms 4 ms 216.239.46.248 > 7 5 ms 5 ms 5 ms 72.14.238.173 > 8 5 ms 5 ms 5 ms iad23s05-in-f8.1e100.net [74.125.228.8] > > > It would be nice if the ISPs and content providers could work out something when dealing with this much traffic and clearly needing to add capaicty. It's nice to dream too... > > John > > From NANOG at enger.us Thu Mar 7 04:00:12 2013 From: NANOG at enger.us (Robert M. Enger) Date: Wed, 06 Mar 2013 20:00:12 -0800 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> <51380388.7050502@derekivey.com> Message-ID: <513810CC.5000909@enger.us> 1) You can use wireshark or other monitor to determine the IP address that your video stream is originating from. 2) Upstream traceroutes to that address are probably not of that much interest. The downstream path (carrying the video from the server to your house) can follow a different path. Downstream traceroute is what is needed. 3) Before pointing fingers at anyone, you need to get your own house (literally) in order. Get off wifi, that is just muddying the water. Shutdown wifi so there are no other users. Get off MocA. You need to be all hard-wired and totally error free and reliable in your local LAN before you can cast stones at carriers and/or inter-carrier interconnection 4) Run some speed-tests to COMPETENT speed test servers (not just the VZ, Time-warner or other in-house speed-test server, but COMPETENT 3rd-party servers). Run those tests during middle-of the night (idle) as well as evening (peak-use) periods. Compare the results. Make sure your ISP last-mile network isn't collapsing under evening (peak hour) load. After all is said and done, you probably still can't do anything except complain to Google. Without the downstream traceroute, you can't really point fingers at a carrier or interconnect. So far as I am aware, google/youtube does not provide a looking-glass or downstream traceroute from any of its (numerous) server sites. So Google staff would have to run the tests. They would have to be adequately staffed to provide that level of investigation and remediation. Google management would have to get involved. How is the consumer ever going to enjoy OTT video with image fidelity suitable for large-screen, lean-back viewing (HD cable-TV quality, if not Bluray quality), if even moderate-rate data flows cannot be sustained into the home when the flow crosses multiple providers? Cable/Satellite, networks, studios will continue to have monopoly on high fidelity lean-back viewing until such time as we can deliver high rates from a remote source into the home. *Clearly FTTH last-mile is not in itself sufficient to guarantee success.* The carriers have to bury the hatchet and start playing nice with one another. As long as they try to gouge money out of both direct customer (receiver) as well as the content provider (sender), this problem will likely not be resolved. Given the big bucks involved, it seems likely that the issue will persist in perpetuity. Regulators and legislators won't act. Their allegiance is not to the citizen consumer. From jerry.klonaper at gmail.com Thu Mar 7 03:10:35 2013 From: jerry.klonaper at gmail.com (Jerry Klonaper) Date: Wed, 6 Mar 2013 22:10:35 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? Message-ID: Not sure how to avoid the legal entanglements my employer has placed in the IT teams path but I'll try to provide a real-world example without breaking confidentially agreements we all were required to sign for continued employment at a very large US-based bank. Our senior IT team had proposed a multi-year upgrade to v6 for our existing internal network, external services and connectivity to partner companies in 2009. It was fully funded in 2010, with staffing, vendor reqs and milestones set. At the end of 2012 our companies senior finance team reviewed the benefits and progress. They came away with a very simple view but alas one which could not be overcome. They held that our bank did not gain any strategic advantage by rolling out v6 but instead now had two entire security and software profiles to maintain. Hence our company has "mothballed" the project and has reassigned the entire team to other business needs. So, our globally known brand will only keep a nominal amount of ongoing public statements of being in support of v6 when in reality we are no longer going to deploy it until the market demands it. I have been employed here through two mergers and thought very hard about leaving, as did several of us that put a lot of effort into the project. But in the end, the job is secure, it is not my company to tell them they are wrong and I can't fault the logic no matter how much I wish. Upon reading this thread I'm dumbstruck at each of the arguments. None really matter. I had to agree, there was zero gain to be found for my company, today or in the immediate future, to proceed but there is plenty of downside. I read the zealots comments and know that they will claim we are fools. We, as a team, thought so too. But now several months removed, we all actually agree with the business/finance group. So there it is. I cannot give specifics, but a well-known global bank has turned out the lights for now on the v6 deployment. It wasn't due to the lack of selling to executives, as this thread contends can be done, but due to the lack of any business case that could be found. Jerry From john at razorservers.com Thu Mar 7 04:19:07 2013 From: john at razorservers.com (John Zettlemoyer) Date: Wed, 6 Mar 2013 23:19:07 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> References: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> Message-ID: Yup... This might be more helpful. I went to r19.sn-p5qlsm7d.c.youtube.com for better comparison. Verizon FIOS 1 8 ms 4 ms 4 ms l100.cmdnnj-vfttp-27.verizon-gni.net [98.110.113.1] 2 9 ms 6 ms 7 ms g0-3-3-6.cmdnnj-lcr-22.verizon-gni.net [130.81.182.44] 3 10 ms 9 ms 9 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net [130.81.209.144] 4 8 ms 8 ms 9 ms 0.xe-3-1-0.br3.nyc4.alter.net [152.63.26.117] 5 23 ms 24 ms 24 ms 204.255.168.118 6 33 ms 34 ms 34 ms 144.232.4.93 7 22 ms 22 ms 22 ms sl-crs4-nyc-0-3-5-0.sprintlink.net [144.232.7.122] 8 25 ms 22 ms 24 ms sl-crs2-dc-0-4-0-2.sprintlink.net [144.232.8.164] 9 22 ms 21 ms 22 ms sl-st31-ash-0-2-0-0.sprintlink.net [144.232.25.15] 10 50 ms 49 ms 49 ms sl-googl10-584821-0.sprintlink.net [144.228.205.34] 11 20 ms 19 ms 19 ms 208.117.251.184 Comcast 1 27 ms 31 ms 21 ms 68.38.220.1 2 8 ms 9 ms 11 ms xe-11-3-0-0-sur01.burlington.nj.panjde.comcast.net [68.85.128.237] 3 11 ms 9 ms 9 ms xe-13-0-0-0-ar03.audubon.nj.panjde.comcast.net [68.85.62.89] 4 15 ms 16 ms 15 ms pos-4-0-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.93.233] 5 14 ms 14 ms 13 ms be-27-pe06.ashburn.va.ibone.comcast.net [68.86.82.174] 6 15 ms 13 ms 14 ms 144.232.6.97 7 15 ms 14 ms 15 ms sl-st31-ash-0-4-0-3.sprintlink.net [144.232.3.169] 8 34 ms 32 ms 31 ms sl-googl10-584821-0.sprintlink.net [144.228.205.34] 9 30 ms 31 ms 31 ms 208.117.251.184 Our DC 1 <1 ms <1 ms <1 ms static.razorinc.net [70.34.208.101] 2 <1 ms <1 ms <1 ms mx1.razorinc.net [70.34.252.9] 3 <1 ms <1 ms <1 ms xe-0-2-0.phi10.ip4.tinet.net [199.168.63.233] 4 3 ms 8 ms 3 ms xe-7-2-1.was14.ip4.tinet.net [89.149.181.174] 5 3 ms 3 ms 3 ms as2828.ip4.tinet.net [77.67.68.14] 6 3 ms 3 ms 3 ms 216.156.8.189.ptr.us.xo.net [216.156.8.189] 7 4 ms 4 ms 4 ms 209.48.42.86 8 4 ms 4 ms 4 ms 208.117.251.184 ? John From rdobbins at arbor.net Thu Mar 7 04:31:13 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 7 Mar 2013 04:31:13 +0000 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> On Mar 7, 2013, at 10:10 AM, Jerry Klonaper wrote: > It wasn't due to the lack of selling to executives, as this thread contends can be done, but due to the lack of any business case that could be found. Is the deployment in such a state that rollout can be resumed if/when it's deemed a priority? Another possible approach might be to utilize IPv6 for BYOD wireless - it's sort of the ultimate in device segregation. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jared at puck.nether.net Thu Mar 7 04:36:50 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Mar 2013 23:36:50 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> References: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> Message-ID: <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> On Mar 6, 2013, at 11:31 PM, "Dobbins, Roland" wrote: > > On Mar 7, 2013, at 10:10 AM, Jerry Klonaper wrote: > >> It wasn't due to the lack of selling to executives, as this thread contends can be done, but due to the lack of any business case that could be found. > > Is the deployment in such a state that rollout can be resumed if/when it's deemed a priority? > > Another possible approach might be to utilize IPv6 for BYOD wireless - it's sort of the ultimate in device segregation. The big problem I have (and with our own IT group) is that their network doesn't provide IPv6 yet we have offered it as a commercial service for a decade or more. This limits the ability to troubleshoot and dog-food the IPv6 network when using their resources. This means we stand up our own resources because they are unable to meet our needs. This is natural in many businesses, you work around what is broken or missing to get things done. I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. I found banks that would return NXDOMAIN instead of NOERROR when you asked for their domain name. This caused many problems until they corrected it. I actually got in contact with someone there by calling their whois contact. Was amazed that worked, but was a happy surprise. - Jared From rdobbins at arbor.net Thu Mar 7 04:50:41 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 7 Mar 2013 04:50:41 +0000 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> References: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> Message-ID: <2CEB1D36-3963-4C62-A99E-5F303E8B4CAB@arbor.net> On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote: > I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. That's a great point, but my guess is that the suits will say that since none of their customers are using IPv6, there's no urgency (yes, I know, it's better to be prepared ahead of time; but foresight doesn't generally carry much weight in quarterly-driven enterprises). ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From andrew.fried at gmail.com Thu Mar 7 04:57:39 2013 From: andrew.fried at gmail.com (Andrew Fried) Date: Wed, 06 Mar 2013 23:57:39 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <32193289.166228.1362602086426.JavaMail.root@network1.net> <5137F657.7090500@derekivey.com> Message-ID: <51381E43.7030207@gmail.com> I know only too well that Verizon's peering with Cogent in the DC/IAD area is beyond saturated. Looking at the traceroute you have below it would appear to be the same problem: >> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms >> 14.975 ms >> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms A handoff between Verizon and Sprint shouldn't incude a 100ms delay. Andy Andrew Fried andrew.fried at gmail.com On 3/6/13 9:25 PM, Min wrote: > 3 traces all indicated the last hub are 80~100ms faster than the > second last hub. Interesting. > > Min > > On Wed, Mar 6, 2013 at 9:07 PM, Derek Ivey wrote: >> I just got home and tested with quite a few 1080p videos. No issues over my >> Hurricane Electric IPv6 tunnel. I did notice frequent stops to buffer on my >> FiOS IPv4 connection. I have a 50 Mbps down connection and don't even come >> close to maxing it when watching Youtube videos. >> >> Here are a few traceroutes: >> >> [2.1-BETA0][root at pfsense]/root(1): traceroute >> r19---sn-p5qlsm7d.c.youtube.com >> traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 64 hops max, >> 40 byte packets >> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.222 ms 1.348 ms >> 0.834 ms >> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.839 ms >> 2.589 ms 2.443 ms >> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.880 ms 14.614 >> ms 14.698 ms >> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.647 ms >> 14.696 ms 14.552 ms >> 5 0.xe-3-1-1.BR1.IAD8.ALTER.NET (152.63.37.141) 15.027 ms 15.004 ms >> 15.064 ms >> 6 te9-2-0d0.cir1.ashburn-va.us.xo.net (206.111.0.201) 38.517 ms 36.033 >> ms 34.816 ms >> 7 216.156.8.189.ptr.us.xo.net (216.156.8.189) 31.958 ms 30.994 ms >> 29.194 ms >> 8 209.48.42.86 (209.48.42.86) 124.931 ms 126.117 ms 124.303 ms >> 9 208.117.251.184 (208.117.251.184) 26.483 ms 27.792 ms 27.974 ms >> >> [2.1-BETA0][root at pfsense]/root(2): traceroute >> r15---sn-p5qlsm76.c.youtube.com >> traceroute to r15.sn-p5qlsm76.c.youtube.com (208.117.251.148), 64 hops max, >> 40 byte packets >> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.077 ms 0.863 ms >> 0.968 ms >> 2 G10-0-8-112.HRBGPA-LCR-01.verizon-gni.net (130.81.184.148) 2.429 ms >> 2.265 ms 2.456 ms >> 3 P12-0-0.HRBGPA-LCR-02.verizon-gni.net (130.81.27.185) 14.788 ms 14.666 >> ms 14.643 ms >> 4 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.591 ms >> 14.479 ms 16.041 ms >> 5 0.xe-10-0-0.BR2.IAD8.ALTER.NET (152.63.38.165) 15.007 ms 15.109 ms >> 14.975 ms >> 6 144.232.8.209 (144.232.8.209) 187.038 ms 115.363 ms 117.669 ms >> 7 sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.263 ms >> sl-st31-ash-0-8-0-2.sprintlink.net (144.232.1.19) 116.491 ms >> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 116.934 ms >> 8 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 122.521 ms 122.780 >> ms 121.535 ms >> 9 208.117.251.148 (208.117.251.148) 33.669 ms 37.652 ms 38.478 ms >> >> [2.1-BETA0][root at pfsense]/root(6): traceroute >> r10---sn-p5qlsm7l.c.youtube.com >> traceroute to r10.sn-p5qlsm7l.c.youtube.com (208.117.251.47), 64 hops max, >> 40 byte packets >> 1 L100.HRBGPA-VFTTP-12.verizon-gni.net (98.117.0.1) 1.159 ms 0.831 ms >> 0.806 ms >> 2 G9-0-4-212.HRBGPA-LCR-02.verizon-gni.net (130.81.139.126) 2.396 ms >> 2.435 ms 2.167 ms >> 3 so-12-1-0-0.RES-BB-RTR1.verizon-gni.net (130.81.28.254) 14.497 ms >> 14.767 ms 14.695 ms >> 4 0.xe-11-0-0.BR2.IAD8.ALTER.NET (152.63.38.169) 15.001 ms 15.074 ms >> 15.024 ms >> 5 144.232.8.209 (144.232.8.209) 118.582 ms 116.717 ms 113.669 ms >> 6 sl-st31-ash-0-4-0-3.sprintlink.net (144.232.3.169) 114.433 ms 117.698 >> ms >> sl-st31-ash-0-4-0-0.sprintlink.net (144.232.28.6) 115.981 ms >> 7 sl-googl10-584821-0.sprintlink.net (144.228.205.34) 123.912 ms 124.402 >> ms 125.384 ms >> 8 208.117.251.47 (208.117.251.47) 30.591 ms 30.676 ms 29.528 ms >> >> Derek >> >> On 3/6/2013 8:31 PM, Grant Ridder wrote: >>> >>> Can any one provide traceroutes to youtube to see if there is any >>> correlation between last mile providers? >>> >>> -Grant >>> >>> On Wed, Mar 6, 2013 at 6:37 PM, Derek Ivey >> > wrote: >>> >>> I don't think it's just Time Warner. Definitely looks like XO. I have >>> Verizon FiOS and it was pretty bad for me as well (not sure if it >>> still is >>> since I'm not home right now). There's also atleast two threads in the >>> Verizon FiOS section on Broadband Reports: >>> >>> http://www.dslreports.com/forum/r28027601-Horrible-youtube-speeds >>> >>> http://www.dslreports.com/forum/r28071070-How-to-Reddit-YouTube-firewall-rule-with-MI424wr >>> >>> Derek >>> >>> >>> On Wed, Mar 6, 2013 at 5:56 PM, Rick Coloccia >>> > wrote: >>> >>> > I'd like to help, too, I'm from a TWC business class site with >>> 650 Mbps >>> > bandwidth and still regularly poor performance with YouTube. >>> > >>> > -Rick >>> > >>> > Sent from my iPhone 4S >>> > >>> > On Mar 6, 2013, at 4:10 PM, Christopher Morrow >>> > >>> > wrote: >>> > >>> > > On Wed, Mar 6, 2013 at 3:34 PM, Randy Carpenter >>> > >>> > wrote: >>> > >> >>> > >> ----- Original Message ----- >>> > >>> On Wed, Mar 6, 2013 at 3:11 PM, Randy Carpenter >>> > >>> > wrote: >>> > >>>> >>> > >>>> We have recently been having some serious speed issues with >>> YouTube >>> > >>>> on our home connections, which are all Time Warner Cable. >>> > >>>> Some searching on forums and such revealed a work around: >>> > >>>> >>> > >>>> Block 206.111.0.0/16 at the router. >>> > >>> >>> > >>> this was reported elsewhere... it seems odd, since that's XO >>> space, >>> > >>> not Google and not TWC space. Would you care to engage in some >>> > >>> troubleshooting to help everyone out? :) >>> > >> >>> > >> I'll be happy to help troubleshoot in any way I can. >>> > > >>> > > excellent.. I'll arrange my ducks, let's chat offlist? >>> > > >>> > >>> > >>> >>> >> > From mejndp at rit.edu Thu Mar 7 04:46:09 2013 From: mejndp at rit.edu (Mark Jeremy) Date: Wed, 06 Mar 2013 23:46:09 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> Message-ID: <8E071111C7D8154CA69338DDF94ACF99E9F4145C5F@ex02mail01.ad.rit.edu> Jumping into the bandwagon here to help out. Here's the result from RIT to r19.sn-p5qlsm7d.c.youtube.com, going through at least 4 hops through XO territory. traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 30 hops max, 60 byte packets 1 rit-west1-gw-014-vlan453.rit.edu (129.21.153.254) 0.593 ms 0.584 ms 0.576 ms 2 rit-core1-pp-west2-vlan824.rit.edu (129.21.8.93) 1.938 ms 1.941 ms 2.116 ms 3 rit-rit1-pp-core1-vlan2811.rit.edu (129.21.8.42) 0.508 ms 0.497 ms 0.484 ms 4 te-7-2.car2.Buffalo1.Level3.net (4.59.214.21) 2.293 ms 2.294 ms 2.282 ms 5 ae-4-4.ebr2.NewYork1.Level3.net (4.69.140.242) 10.332 ms 10.339 ms 11.022 ms 6 ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38) 15.274 ms 10.212 ms ae-92-92.csw4.NewYork1.Level3.net (4.69.148.46) 10.204 ms 7 ae-1-60.edge2.NewYork1.Level3.net (4.69.155.16) 10.202 ms ae-2-70.edge2.NewYork1.Level3.net (4.69.155.80) 10.174 ms 10.171 ms 8 206.111.13.65.ptr.us.xo.net (206.111.13.65) 10.160 ms 10.345 ms 10.336 ms 9 207.88.14.185.ptr.us.xo.net (207.88.14.185) 18.555 ms 18.541 ms 20.749 ms 10 ae0d1.cir1.ashburn-va.us.xo.net (207.88.13.65) 16.241 ms 16.322 ms 16.261 ms 11 209.48.42.86 (209.48.42.86) 16.673 ms 64.114 ms 64.054 ms 12 208.117.251.184 (208.117.251.184) 16.313 ms 16.306 ms 16.486 ms -MJ -----Original Message----- From: John Zettlemoyer [mailto:john at razorservers.com] Sent: Wednesday, March 06, 2013 11:19 PM To: 'Derek Ivey' Cc: nanog at nanog.org Subject: RE: Time Warner Cable YouTube throttling Yup... This might be more helpful. I went to r19.sn-p5qlsm7d.c.youtube.com for better comparison. Verizon FIOS 1 8 ms 4 ms 4 ms l100.cmdnnj-vfttp-27.verizon-gni.net [98.110.113.1] 2 9 ms 6 ms 7 ms g0-3-3-6.cmdnnj-lcr-22.verizon-gni.net [130.81.182.44] 3 10 ms 9 ms 9 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net [130.81.209.144] 4 8 ms 8 ms 9 ms 0.xe-3-1-0.br3.nyc4.alter.net [152.63.26.117] 5 23 ms 24 ms 24 ms 204.255.168.118 6 33 ms 34 ms 34 ms 144.232.4.93 7 22 ms 22 ms 22 ms sl-crs4-nyc-0-3-5-0.sprintlink.net [144.232.7.122] 8 25 ms 22 ms 24 ms sl-crs2-dc-0-4-0-2.sprintlink.net [144.232.8.164] 9 22 ms 21 ms 22 ms sl-st31-ash-0-2-0-0.sprintlink.net [144.232.25.15] 10 50 ms 49 ms 49 ms sl-googl10-584821-0.sprintlink.net [144.228.205.34] 11 20 ms 19 ms 19 ms 208.117.251.184 Comcast 1 27 ms 31 ms 21 ms 68.38.220.1 2 8 ms 9 ms 11 ms xe-11-3-0-0-sur01.burlington.nj.panjde.comcast.net [68.85.128.237] 3 11 ms 9 ms 9 ms xe-13-0-0-0-ar03.audubon.nj.panjde.comcast.net [68.85.62.89] 4 15 ms 16 ms 15 ms pos-4-0-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.93.233] 5 14 ms 14 ms 13 ms be-27-pe06.ashburn.va.ibone.comcast.net [68.86.82.174] 6 15 ms 13 ms 14 ms 144.232.6.97 7 15 ms 14 ms 15 ms sl-st31-ash-0-4-0-3.sprintlink.net [144.232.3.169] 8 34 ms 32 ms 31 ms sl-googl10-584821-0.sprintlink.net [144.228.205.34] 9 30 ms 31 ms 31 ms 208.117.251.184 Our DC 1 <1 ms <1 ms <1 ms static.razorinc.net [70.34.208.101] 2 <1 ms <1 ms <1 ms mx1.razorinc.net [70.34.252.9] 3 <1 ms <1 ms <1 ms xe-0-2-0.phi10.ip4.tinet.net [199.168.63.233] 4 3 ms 8 ms 3 ms xe-7-2-1.was14.ip4.tinet.net [89.149.181.174] 5 3 ms 3 ms 3 ms as2828.ip4.tinet.net [77.67.68.14] 6 3 ms 3 ms 3 ms 216.156.8.189.ptr.us.xo.net [216.156.8.189] 7 4 ms 4 ms 4 ms 209.48.42.86 8 4 ms 4 ms 4 ms 208.117.251.184 ? John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6065 bytes Desc: not available URL: From shortdudey123 at gmail.com Thu Mar 7 07:20:13 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 7 Mar 2013 01:20:13 -0600 Subject: Time Warner Cable YouTube throttling In-Reply-To: <8E071111C7D8154CA69338DDF94ACF99E9F4145C5F@ex02mail01.ad.rit.edu> References: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> <8E071111C7D8154CA69338DDF94ACF99E9F4145C5F@ex02mail01.ad.rit.edu> Message-ID: RIT is probably on a commercial circuit and from what i have seen on this chain so far, it is only affecting home/consumer users. At MSOE (msoe.edu) i dont show any latency but we are on TWTC. Anyone chime in if that is wrong. -Grant On Wed, Mar 6, 2013 at 10:46 PM, Mark Jeremy wrote: > Jumping into the bandwagon here to help out. > > Here's the result from RIT to r19.sn-p5qlsm7d.c.youtube.com, going through > at least 4 hops through XO territory. > > traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 30 hops > max, > 60 byte packets > 1 rit-west1-gw-014-vlan453.rit.edu (129.21.153.254) 0.593 ms 0.584 ms > 0.576 ms > 2 rit-core1-pp-west2-vlan824.rit.edu (129.21.8.93) 1.938 ms 1.941 ms > 2.116 ms > 3 rit-rit1-pp-core1-vlan2811.rit.edu (129.21.8.42) 0.508 ms 0.497 ms > 0.484 ms > 4 te-7-2.car2.Buffalo1.Level3.net (4.59.214.21) 2.293 ms 2.294 ms > 2.282 > ms > 5 ae-4-4.ebr2.NewYork1.Level3.net (4.69.140.242) 10.332 ms 10.339 ms > 11.022 ms > 6 ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38) 15.274 ms 10.212 ms > ae-92-92.csw4.NewYork1.Level3.net (4.69.148.46) 10.204 ms > 7 ae-1-60.edge2.NewYork1.Level3.net (4.69.155.16) 10.202 ms > ae-2-70.edge2.NewYork1.Level3.net (4.69.155.80) 10.174 ms 10.171 ms > 8 206.111.13.65.ptr.us.xo.net (206.111.13.65) 10.160 ms 10.345 ms > 10.336 ms > 9 207.88.14.185.ptr.us.xo.net (207.88.14.185) 18.555 ms 18.541 ms > 20.749 ms > 10 ae0d1.cir1.ashburn-va.us.xo.net (207.88.13.65) 16.241 ms 16.322 ms > 16.261 ms > 11 209.48.42.86 (209.48.42.86) 16.673 ms 64.114 ms 64.054 ms > 12 208.117.251.184 (208.117.251.184) 16.313 ms 16.306 ms 16.486 ms > > -MJ > > -----Original Message----- > From: John Zettlemoyer [mailto:john at razorservers.com] > Sent: Wednesday, March 06, 2013 11:19 PM > To: 'Derek Ivey' > Cc: nanog at nanog.org > Subject: RE: Time Warner Cable YouTube throttling > > Yup... This might be more helpful. > I went to r19.sn-p5qlsm7d.c.youtube.com for better comparison. > > Verizon FIOS > > 1 8 ms 4 ms 4 ms l100.cmdnnj-vfttp-27.verizon-gni.net > [98.110.113.1] > 2 9 ms 6 ms 7 ms g0-3-3-6.cmdnnj-lcr-22.verizon-gni.net > [130.81.182.44] > 3 10 ms 9 ms 9 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net > [130.81.209.144] > 4 8 ms 8 ms 9 ms 0.xe-3-1-0.br3.nyc4.alter.net > [152.63.26.117] > 5 23 ms 24 ms 24 ms 204.255.168.118 > 6 33 ms 34 ms 34 ms 144.232.4.93 > 7 22 ms 22 ms 22 ms sl-crs4-nyc-0-3-5-0.sprintlink.net > [144.232.7.122] > 8 25 ms 22 ms 24 ms sl-crs2-dc-0-4-0-2.sprintlink.net > [144.232.8.164] > 9 22 ms 21 ms 22 ms sl-st31-ash-0-2-0-0.sprintlink.net > [144.232.25.15] > 10 50 ms 49 ms 49 ms sl-googl10-584821-0.sprintlink.net > [144.228.205.34] > 11 20 ms 19 ms 19 ms 208.117.251.184 > > Comcast > 1 27 ms 31 ms 21 ms 68.38.220.1 > 2 8 ms 9 ms 11 ms > xe-11-3-0-0-sur01.burlington.nj.panjde.comcast.net [68.85.128.237] > 3 11 ms 9 ms 9 ms > xe-13-0-0-0-ar03.audubon.nj.panjde.comcast.net [68.85.62.89] > 4 15 ms 16 ms 15 ms > pos-4-0-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.93.233] > 5 14 ms 14 ms 13 ms be-27-pe06.ashburn.va.ibone.comcast.net > [68.86.82.174] > 6 15 ms 13 ms 14 ms 144.232.6.97 > 7 15 ms 14 ms 15 ms sl-st31-ash-0-4-0-3.sprintlink.net > [144.232.3.169] > 8 34 ms 32 ms 31 ms sl-googl10-584821-0.sprintlink.net > [144.228.205.34] > 9 30 ms 31 ms 31 ms 208.117.251.184 > > Our DC > 1 <1 ms <1 ms <1 ms static.razorinc.net [70.34.208.101] > 2 <1 ms <1 ms <1 ms mx1.razorinc.net [70.34.252.9] > 3 <1 ms <1 ms <1 ms xe-0-2-0.phi10.ip4.tinet.net > [199.168.63.233] > 4 3 ms 8 ms 3 ms xe-7-2-1.was14.ip4.tinet.net > [89.149.181.174] > 5 3 ms 3 ms 3 ms as2828.ip4.tinet.net [77.67.68.14] > 6 3 ms 3 ms 3 ms 216.156.8.189.ptr.us.xo.net[216.156.8.189] > 7 4 ms 4 ms 4 ms 209.48.42.86 > 8 4 ms 4 ms 4 ms 208.117.251.184 > > > > John > > > > From jcurran at istaff.org Thu Mar 7 07:21:55 2013 From: jcurran at istaff.org (John Curran) Date: Thu, 7 Mar 2013 02:21:55 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <201303051534440664.01900314@sentry.24cl.com> <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com> <5136BE2C.3060804@matthew.at> Message-ID: <903FE2B1-C822-4DD0-91C8-9084BDF47A33@istaff.org> On Mar 6, 2013, at 3:13 PM, George Herbert wrote: > ... > I'm sorry, but a lot of organizations' response to IPv6 has been "Ok, > desktops will need an overlay of it for some websites in AP next year, > so we'll do that. And we need an IPv6 front end visibility for our > website. If nothing else, it's worthing giving that last point some priority (i.e. "And we need an IPv6 front end visibility for our website.") While the Internet is greater than the web, the more public facing servers reachable by IPv6, the more functional IPv6 is as an IPv4 substitute for connecting customers to the Internet. /John From yang.yu.list at gmail.com Thu Mar 7 08:46:40 2013 From: yang.yu.list at gmail.com (Yang Yu) Date: Thu, 7 Mar 2013 03:46:40 -0500 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> <8E071111C7D8154CA69338DDF94ACF99E9F4145C5F@ex02mail01.ad.rit.edu> Message-ID: Also if your upstream has Google Global Cache (or whatever it's called), the results can be very different I suppose. Does Google use different naming structure for IPv6 CDN? Maybe this particular cache does not offer IPv6. ;; QUESTION SECTION: ;r3---sn-n2uxaxjvh-j5xe.c.youtube.com. IN A ;; ANSWER SECTION: r3---sn-n2uxaxjvh-j5xe.c.youtube.com. 60 IN CNAME r3.sn-n2uxaxjvh-j5xe.c.youtube.com. r3.sn-n2uxaxjvh-j5xe.c.youtube.com. 1800 IN A 64.53.1.78 ;; QUESTION SECTION: ;r3---sn-n2uxaxjvh-j5xe.c.youtube.com. IN AAAA ;; ANSWER SECTION: r3---sn-n2uxaxjvh-j5xe.c.youtube.com. 60 IN CNAME r3.sn-n2uxaxjvh-j5xe.c.youtube.com. Level3 peers with Google, I am curious why it hand the traffic off to XO. > On Wed, Mar 6, 2013 at 10:46 PM, Mark Jeremy wrote: >> traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 30 hops >> max, >> 60 byte packets >> 3 rit-rit1-pp-core1-vlan2811.rit.edu (129.21.8.42) 0.508 ms 0.497 ms >> 0.484 ms >> 4 te-7-2.car2.Buffalo1.Level3.net (4.59.214.21) 2.293 ms 2.294 ms >> 2.282 >> ms >> 5 ae-4-4.ebr2.NewYork1.Level3.net (4.69.140.242) 10.332 ms 10.339 ms >> 11.022 ms >> 6 ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38) 15.274 ms 10.212 ms >> ae-92-92.csw4.NewYork1.Level3.net (4.69.148.46) 10.204 ms >> 7 ae-1-60.edge2.NewYork1.Level3.net (4.69.155.16) 10.202 ms >> ae-2-70.edge2.NewYork1.Level3.net (4.69.155.80) 10.174 ms 10.171 ms >> 8 206.111.13.65.ptr.us.xo.net (206.111.13.65) 10.160 ms 10.345 ms >> 10.336 ms >> 9 207.88.14.185.ptr.us.xo.net (207.88.14.185) 18.555 ms 18.541 ms >> 20.749 ms >> 10 ae0d1.cir1.ashburn-va.us.xo.net (207.88.13.65) 16.241 ms 16.322 ms >> 16.261 ms >> 11 209.48.42.86 (209.48.42.86) 16.673 ms 64.114 ms 64.054 ms >> 12 208.117.251.184 (208.117.251.184) 16.313 ms 16.306 ms 16.486 ms From mukom.tamon at gmail.com Thu Mar 7 09:50:24 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Thu, 7 Mar 2013 13:50:24 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Thu, Mar 7, 2013 at 12:25 AM, William Herrin wrote: > > For that, you need the help of a real cost analyst. That's what > they're for; they help organizations figure out a solid idea what > something will really cost before they start spending money. If your > organization is large, you may even have one on staff somewhere. > Point taken. Thank you. > > > >> Implicitly they'll also be looking for the answer to a fourth > >> question: Do you know WTF you're talking about? If you assure them > >> it's all peaches and cream with tiny costs and no opportunity cost, > >> the answer is, "no." > > > > I believe if anyone who can phrase the "IPv4 Exhaustion Problem + IPv6 > > Solution" in very specific terms of the business model of the company > will > > implicitly inspire confidence in execs that they know what they are > talking > > about. > > Your first paragraph loses the argument: the day has past when IPv6 > could become a credible solution to the IPv4 exhaustion problem. Like > it or lump it, NAT was the solution to the IPv4 exhaustion problem. > Which the exec will learn when he chats up his computer literate buddy > before making his decision. > I don't think NAT solves the problem in a sustainable way. Sure for managers that are already driven by short-term goals, that's fine however in Africa, we are seeing situations where NAT just doesn't scale. Specifically with the influx of submarine cables, the bottleneck has shifted from 'available bandwidth' to 'NAT' (or strictly speaking NAPT) capacity. > > If you're an ISP or you make network software, this is a > straightforward case to make. There are public sources of IPv6 > deployment rate data. You can presume that a similar rate holds among > your customers and that the customers who deploy IPv6 will disqualify > your product if the product doesn't work with IPv6. > Good point. > > If your business isn't networks, you have a much harder case to make. > As another poster noted, the end of IPv4 is not on the radar yet. A > statistically insignificant number of people will change banks this > year over their bank's web site IPv6 reachability. > Thank you once again. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From aservin at lacnic.net Thu Mar 7 10:42:02 2013 From: aservin at lacnic.net (Arturo Servin) Date: Thu, 7 Mar 2013 08:42:02 -0200 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <2CEB1D36-3963-4C62-A99E-5F303E8B4CAB@arbor.net> References: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> <2CEB1D36-3963-4C62-A99E-5F303E8B4CAB@arbor.net> Message-ID: <173956E9-397B-46EA-B80F-01A3A6440FF2@lacnic.net> On 7 Mar 2013, at 02:50, Dobbins, Roland wrote: > > On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote: > >> I would pitch it as follows: We need to at least have IPv6 access to troubleshoot/understand customers that have dual-stack technology. > > That's a great point, but my guess is that the suits will say that since none of their customers are using IPv6, there's no urgency (yes, I know, it's better to be prepared ahead of time; but foresight doesn't generally carry much weight in quarterly-driven enterprises). > Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. /as From job.snijders at atrato.com Thu Mar 7 11:30:07 2013 From: job.snijders at atrato.com (Job Snijders) Date: Thu, 7 Mar 2013 12:30:07 +0100 Subject: Dreamhost/AS26347 unauthorized bgp announcement In-Reply-To: <51378AED.7010309@toonk.nl> References: <20130306.175954.55308686.maz@iij.ad.jp> <51378AED.7010309@toonk.nl> Message-ID: <0058777D-D40F-4E7C-BE23-6C6061B6CDB9@atrato.com> Hi all, Just a small update. Off-list Andree and me have been working together with Kenneth from dreamhost to try and figure out what exactly happened and which device or party orginated these prefixes. Unfortunately no hard conclusions can be drawn from the data available to us, especially since we lack proper insight into this Any2 routeserver. I also want to emphasize that Kenneth and Dreamhost have been very forth coming in sharing data (configs, stats, networkplans) to find the root cause. We have put additional monitoring in place to try and catch more data if this happens a next time. Thank you all for being on top of incidents like this! Kind regards, Job On Mar 6, 2013, at 7:29 PM, Andree Toonk wrote: > .-- My secret spy satellite informs me that at 2013-03-06 12:59 AM > Matsuzaki Yoshinobu wrote: >> According to RIPE RIS, AS26347 announced a bunch of prefixes again. >> - http://www.ris.ripe.net/dashboard/26347 >> >> First suspicious announcement was started 2013-03-06 07:52:40 UTC, and >> last seen 2013-03-06 08:33:56 UTC. 195 prefixes total. >> >> It seems these unauthorized announcements have the same profile as >> before - AS26347 shrinks the prefix lenght of their received prefix >> somehow upto /20, and re-originates the prefix with origin AS26347. >> >> Any known bugs? > > > Sounds indeed like an exact copy of the incident on January 11: > http://seclists.org/nanog/2013/Jan/243 > > That time the prefixes seem to also have been learned via a route-server > in LA. > > The strange thing is that the majority of the 'hijacked' prefixes (today > and in January) are new more specifics (not seen before). > (Using some kind of BGP route optimizer?). > > This time it affected 203 unique prefixes and 133 ASns. > Below a list of some of the affected ASns > > 20115 Charter Telecom. > 4837 China Unicom > 8151 UNINET Mexico > 11427 Roadrunner > 42961 MTC GPRS Kuwait > 7303 Telecom Argentina S.A. > 25135 Vodafone > 7018 AT&T > 6389 BellSouth.net > 8220 Colt > 19262 Verizon > 9143 ZIGGO > 6830 UPC > 5089 Virgin Media > > > Cheers, > Andree > > > > -- AS5580 - Atrato IP Networks From pingwin at gmail.com Thu Mar 7 13:00:58 2013 From: pingwin at gmail.com (Brian) Date: Thu, 7 Mar 2013 08:00:58 -0500 Subject: Need a Level3 Contact Message-ID: Hi, I have a prefix that isn't being accepted by Level3. Can someone from Level3 could contact. Off list is fine. -brian From wbailey at satelliteintelligencegroup.com Thu Mar 7 13:12:28 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 7 Mar 2013 13:12:28 +0000 Subject: Time Warner Cable YouTube throttling In-Reply-To: References: <869c6328-86d1-4c94-b7b0-d333e0423791@razorservers.com> <42795455-A348-4DFB-9D67-82FCCD46CD52@derekivey.com> <8E071111C7D8154CA69338DDF94ACF99E9F4145C5F@ex02mail01.ad.rit.edu>, Message-ID: I had the opportunity to look at this from a TWC fiber customer in Ohio, and this did not seem to affect them. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Grant Ridder Date: 03/07/2013 2:22 AM (GMT-05:00) To: Mark Jeremy Cc: John Zettlemoyer ,nanog at nanog.org Subject: Re: Time Warner Cable YouTube throttling RIT is probably on a commercial circuit and from what i have seen on this chain so far, it is only affecting home/consumer users. At MSOE (msoe.edu) i dont show any latency but we are on TWTC. Anyone chime in if that is wrong. -Grant On Wed, Mar 6, 2013 at 10:46 PM, Mark Jeremy wrote: > Jumping into the bandwagon here to help out. > > Here's the result from RIT to r19.sn-p5qlsm7d.c.youtube.com, going through > at least 4 hops through XO territory. > > traceroute to r19.sn-p5qlsm7d.c.youtube.com (208.117.251.184), 30 hops > max, > 60 byte packets > 1 rit-west1-gw-014-vlan453.rit.edu (129.21.153.254) 0.593 ms 0.584 ms > 0.576 ms > 2 rit-core1-pp-west2-vlan824.rit.edu (129.21.8.93) 1.938 ms 1.941 ms > 2.116 ms > 3 rit-rit1-pp-core1-vlan2811.rit.edu (129.21.8.42) 0.508 ms 0.497 ms > 0.484 ms > 4 te-7-2.car2.Buffalo1.Level3.net (4.59.214.21) 2.293 ms 2.294 ms > 2.282 > ms > 5 ae-4-4.ebr2.NewYork1.Level3.net (4.69.140.242) 10.332 ms 10.339 ms > 11.022 ms > 6 ae-72-72.csw2.NewYork1.Level3.net (4.69.148.38) 15.274 ms 10.212 ms > ae-92-92.csw4.NewYork1.Level3.net (4.69.148.46) 10.204 ms > 7 ae-1-60.edge2.NewYork1.Level3.net (4.69.155.16) 10.202 ms > ae-2-70.edge2.NewYork1.Level3.net (4.69.155.80) 10.174 ms 10.171 ms > 8 206.111.13.65.ptr.us.xo.net (206.111.13.65) 10.160 ms 10.345 ms > 10.336 ms > 9 207.88.14.185.ptr.us.xo.net (207.88.14.185) 18.555 ms 18.541 ms > 20.749 ms > 10 ae0d1.cir1.ashburn-va.us.xo.net (207.88.13.65) 16.241 ms 16.322 ms > 16.261 ms > 11 209.48.42.86 (209.48.42.86) 16.673 ms 64.114 ms 64.054 ms > 12 208.117.251.184 (208.117.251.184) 16.313 ms 16.306 ms 16.486 ms > > -MJ > > -----Original Message----- > From: John Zettlemoyer [mailto:john at razorservers.com] > Sent: Wednesday, March 06, 2013 11:19 PM > To: 'Derek Ivey' > Cc: nanog at nanog.org > Subject: RE: Time Warner Cable YouTube throttling > > Yup... This might be more helpful. > I went to r19.sn-p5qlsm7d.c.youtube.com for better comparison. > > Verizon FIOS > > 1 8 ms 4 ms 4 ms l100.cmdnnj-vfttp-27.verizon-gni.net > [98.110.113.1] > 2 9 ms 6 ms 7 ms g0-3-3-6.cmdnnj-lcr-22.verizon-gni.net > [130.81.182.44] > 3 10 ms 9 ms 9 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net > [130.81.209.144] > 4 8 ms 8 ms 9 ms 0.xe-3-1-0.br3.nyc4.alter.net > [152.63.26.117] > 5 23 ms 24 ms 24 ms 204.255.168.118 > 6 33 ms 34 ms 34 ms 144.232.4.93 > 7 22 ms 22 ms 22 ms sl-crs4-nyc-0-3-5-0.sprintlink.net > [144.232.7.122] > 8 25 ms 22 ms 24 ms sl-crs2-dc-0-4-0-2.sprintlink.net > [144.232.8.164] > 9 22 ms 21 ms 22 ms sl-st31-ash-0-2-0-0.sprintlink.net > [144.232.25.15] > 10 50 ms 49 ms 49 ms sl-googl10-584821-0.sprintlink.net > [144.228.205.34] > 11 20 ms 19 ms 19 ms 208.117.251.184 > > Comcast > 1 27 ms 31 ms 21 ms 68.38.220.1 > 2 8 ms 9 ms 11 ms > xe-11-3-0-0-sur01.burlington.nj.panjde.comcast.net [68.85.128.237] > 3 11 ms 9 ms 9 ms > xe-13-0-0-0-ar03.audubon.nj.panjde.comcast.net [68.85.62.89] > 4 15 ms 16 ms 15 ms > pos-4-0-0-0-cr01.ashburn.va.ibone.comcast.net [68.86.93.233] > 5 14 ms 14 ms 13 ms be-27-pe06.ashburn.va.ibone.comcast.net > [68.86.82.174] > 6 15 ms 13 ms 14 ms 144.232.6.97 > 7 15 ms 14 ms 15 ms sl-st31-ash-0-4-0-3.sprintlink.net > [144.232.3.169] > 8 34 ms 32 ms 31 ms sl-googl10-584821-0.sprintlink.net > [144.228.205.34] > 9 30 ms 31 ms 31 ms 208.117.251.184 > > Our DC > 1 <1 ms <1 ms <1 ms static.razorinc.net [70.34.208.101] > 2 <1 ms <1 ms <1 ms mx1.razorinc.net [70.34.252.9] > 3 <1 ms <1 ms <1 ms xe-0-2-0.phi10.ip4.tinet.net > [199.168.63.233] > 4 3 ms 8 ms 3 ms xe-7-2-1.was14.ip4.tinet.net > [89.149.181.174] > 5 3 ms 3 ms 3 ms as2828.ip4.tinet.net [77.67.68.14] > 6 3 ms 3 ms 3 ms 216.156.8.189.ptr.us.xo.net[216.156.8.189] > 7 4 ms 4 ms 4 ms 209.48.42.86 > 8 4 ms 4 ms 4 ms 208.117.251.184 > > > > John > > > > From jcurran at istaff.org Thu Mar 7 13:32:37 2013 From: jcurran at istaff.org (John Curran) Date: Thu, 7 Mar 2013 08:32:37 -0500 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <173956E9-397B-46EA-B80F-01A3A6440FF2@lacnic.net> References: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> <2CEB1D36-3963-4C62-A99E-5F303E8B4CAB@arbor.net> <173956E9-397B-46EA-B80F-01A3A6440FF2@lacnic.net> Message-ID: <2695AFD4-A5CA-44C1-8686-B177D807BF2B@istaff.org> On Mar 7, 2013, at 5:42 AM, Arturo Servin wrote: > Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? > In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. Presuming a medium/small service provider, the most typical sequence that I've been hearing runs something like this: 1. Engineers internally experiment with IPv6 on an individual basis (lab, tunnels, virtual servers, etc.) Doesn't always happen, but the ones that don't are making their own gamble regarding their skills and career trajectory. 2. Some formal recognition by the network team of need to gain IPv6 experience; this can be equipment for a "real" lab, formal training, minor investment in external firewalls to bring up to spec, etc. 3. The network folks start arranging for real IPv6 connectivity from the outside, this could be transit or peering, and begin working on plans for the "network backbone" to be fully dual-stack. 4. The "talk" with IT regarding IPv6, and acceptance of the concept that it would be nice if the web site had some minimal support (yes, maybe not the customer ticketing/feedback system, or every page, but at least the major content sections.) This leads to the idea that IT will test new web rollouts with IPv6, and the need therefore to get IPv6 to some of the integration/QA folks. 5. IT/internal network team realization that they have to get IPv6 internally to some of the Internet network team, some of the developers, and that means that the "corporate" network really does need to support IPv6, and that means those firewalls, and management and training for the internal corporate network team. 6. Several meetings with marketing and sales trying to explain that other organizations (i.e. customers are doing the same thing, and a general mismatch in expectations since the vast majority of customers have never uttered "IPv6" to anyone in sales/marketing. 7. Slow but steady internal progress on IPv6 deployment in the company, all while waiting for sales/marketing to recognize the need for IPv6 services for customers. 8. One key event (often a customer RFP requirement, or a sale lost due to lack of IPv6 support) occurs, which then brings the lack of IPv6 into focus as a competitive issue, and subsequent discussions about budget/investment for adding IPv6 support to the service catalog. YMMV, and every organization is a little different, but the common theme is that the more awareness that we can generate in CIO/IT industry about the IPv4 constraints facing the Internet network industry, the faster that IPv6 will happen... /John From arturo.servin at gmail.com Thu Mar 7 13:48:27 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Thu, 07 Mar 2013 11:48:27 -0200 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <2695AFD4-A5CA-44C1-8686-B177D807BF2B@istaff.org> References: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> <2CEB1D36-3963-4C62-A99E-5F303E8B4CAB@arbor.net> <173956E9-397B-46EA-B80F-01A3A6440FF2@lacnic.net> <2695AFD4-A5CA-44C1-8686-B177D807BF2B@istaff.org> Message-ID: <51389AAB.2030305@gmail.com> Pretty much the same process that I have seen in many ISPs and enterprises. Regards. as On 07/03/2013 11:32, John Curran wrote: > On Mar 7, 2013, at 5:42 AM, Arturo Servin wrote: > >> Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? >> In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. > > Presuming a medium/small service provider, the most typical sequence > that I've been hearing runs something like this: > > 1. Engineers internally experiment with IPv6 on an individual basis > (lab, tunnels, virtual servers, etc.) Doesn't always happen, > but the ones that don't are making their own gamble regarding > their skills and career trajectory. > > 2. Some formal recognition by the network team of need to gain IPv6 > experience; this can be equipment for a "real" lab, formal training, > minor investment in external firewalls to bring up to spec, etc. > > 3. The network folks start arranging for real IPv6 connectivity from > the outside, this could be transit or peering, and begin working > on plans for the "network backbone" to be fully dual-stack. > > 4. The "talk" with IT regarding IPv6, and acceptance of the concept > that it would be nice if the web site had some minimal support > (yes, maybe not the customer ticketing/feedback system, or every > page, but at least the major content sections.) This leads to > the idea that IT will test new web rollouts with IPv6, and the > need therefore to get IPv6 to some of the integration/QA folks. > > 5. IT/internal network team realization that they have to get IPv6 > internally to some of the Internet network team, some of the > developers, and that means that the "corporate" network really > does need to support IPv6, and that means those firewalls, and > management and training for the internal corporate network team. > > 6. Several meetings with marketing and sales trying to explain that > other organizations (i.e. customers are doing the same thing, and > a general mismatch in expectations since the vast majority of > customers have never uttered "IPv6" to anyone in sales/marketing. > > 7. Slow but steady internal progress on IPv6 deployment in the company, > all while waiting for sales/marketing to recognize the need for IPv6 > services for customers. > > 8. One key event (often a customer RFP requirement, or a sale lost due > to lack of IPv6 support) occurs, which then brings the lack of IPv6 > into focus as a competitive issue, and subsequent discussions about > budget/investment for adding IPv6 support to the service catalog. > > YMMV, and every organization is a little different, but the common theme > is that the more awareness that we can generate in CIO/IT industry about > the IPv4 constraints facing the Internet network industry, the faster > that IPv6 will happen... > > /John > > > > From eugen at imacandi.net Thu Mar 7 14:02:47 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 7 Mar 2013 16:02:47 +0200 Subject: Comcast NOC Contact In-Reply-To: References: Message-ID: Comcast's customers send money to Comcast in order to receive whatever they want from other networks. With that money, Comcast should invest in infrastructure so that it's network is not saturated anymore. Isn't this how IPSs work ? :) On Sat, Mar 2, 2013 at 8:07 PM, Vinod K wrote: > > Rob: > > Comcast engineers are on the NANOG list. If you reply with IP and > traceroute they can help u. > > I hear there are networks at capacity b/c of ratios. Everybody wants to > send Comcast traffic, but noone wants to send money. > > V > > > From: wingcomm at hotmail.com > > To: nanog at nanog.org > > Subject: Comcast NOC Contact > > Date: Sat, 2 Mar 2013 04:17:04 -0500 > > > > Could someone from Comcast's NOC contact me off-list? We're seeing some > traffic take a strange route on its way back to some Comcast prefixes from > several of our systems. Thank you! > > -Rob > > From jamie at photon.com Thu Mar 7 14:13:56 2013 From: jamie at photon.com (Jamie Bowden) Date: Thu, 7 Mar 2013 14:13:56 +0000 Subject: Comcast NOC Contact In-Reply-To: References: Message-ID: <465966A5F5B867419F604CD3E604C1E53B04CA59@PRA-DCA-MAIL.pra.ray.com> > From: Eugeniu Patrascu [mailto:eugen at imacandi.net] > Comcast's customers send money to Comcast in order to receive whatever > they > want from other networks. With that money, Comcast should invest in > infrastructure so that it's network is not saturated anymore. Isn't this > how IPSs work ? :) In competitive markets, that's the theory. That would require one to test with... Jamie From khelms at zcorum.com Thu Mar 7 14:34:18 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 7 Mar 2013 09:34:18 -0500 Subject: Comcast NOC Contact In-Reply-To: References: Message-ID: Its a bit more complicated than that, especially when you're a large operator that all the content providers need to be able to reach and you have a (largely) converged backbone system. On Thu, Mar 7, 2013 at 9:02 AM, Eugeniu Patrascu wrote: > Comcast's customers send money to Comcast in order to receive whatever they > want from other networks. With that money, Comcast should invest in > infrastructure so that it's network is not saturated anymore. Isn't this > how IPSs work ? :) > > > On Sat, Mar 2, 2013 at 8:07 PM, Vinod K wrote: > > > > > Rob: > > > > Comcast engineers are on the NANOG list. If you reply with IP and > > traceroute they can help u. > > > > I hear there are networks at capacity b/c of ratios. Everybody wants to > > send Comcast traffic, but noone wants to send money. > > > > V > > > > > From: wingcomm at hotmail.com > > > To: nanog at nanog.org > > > Subject: Comcast NOC Contact > > > Date: Sat, 2 Mar 2013 04:17:04 -0500 > > > > > > Could someone from Comcast's NOC contact me off-list? We're seeing some > > traffic take a strange route on its way back to some Comcast prefixes > from > > several of our systems. Thank you! > > > -Rob > > > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From eugen at imacandi.net Thu Mar 7 15:16:47 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 7 Mar 2013 17:16:47 +0200 Subject: Comcast NOC Contact In-Reply-To: <465966A5F5B867419F604CD3E604C1E53B04CA59@PRA-DCA-MAIL.pra.ray.com> References: <465966A5F5B867419F604CD3E604C1E53B04CA59@PRA-DCA-MAIL.pra.ray.com> Message-ID: My comment was more or less directed to the person that said "losts of people want to send traffic to comcast, but no one wants to send money". I find it very dangerous and provocative, and somewhat on the same line with others that believe in the "sender party pays" crap they're trying to force onto the market. On Thu, Mar 7, 2013 at 4:13 PM, Jamie Bowden wrote: > > From: Eugeniu Patrascu [mailto:eugen at imacandi.net] > > > > Comcast's customers send money to Comcast in order to receive whatever > > they > > want from other networks. With that money, Comcast should invest in > > infrastructure so that it's network is not saturated anymore. Isn't this > > how IPSs work ? :) > > In competitive markets, that's the theory. That would require one to test > with... > > Jamie > From esavage at digitalrage.org Thu Mar 7 15:58:26 2013 From: esavage at digitalrage.org (Elijah Savage) Date: Thu, 7 Mar 2013 10:58:26 -0500 (EST) Subject: Time Warner Cable YouTube throttling In-Reply-To: <1020036796.166150.1362600710911.JavaMail.root@network1.net> Message-ID: <11222415.46054.1362671906294.JavaMail.root@digitalrage.org> Jumping on the bandwagon. I have not had the chance to follow the entire thread but have seen this behavior from AT&T Uverse, Time Warner, and Verizon FIOS. I believed initially this was a capacity issue with Google and Youtube. The reason for this thought is fairly simple with no scientific troubleshooting invested at this time. I can replicate slowness on AT&T Uverse and Time Warner at the exact same times, the anomoly is Verizon FIOS does not align with the other two. When there is slowness on Uverse 99% of the time my Time Warner connections to Youtube will be slow as well even if you are streaming different video's. ----- Original Message ----- From: "Randy Carpenter" To: "NANOG" Sent: Wednesday, March 6, 2013 3:11:50 PM Subject: Time Warner Cable YouTube throttling We have recently been having some serious speed issues with YouTube on our home connections, which are all Time Warner Cable. Some searching on forums and such revealed a work around: Block 206.111.0.0/16 at the router. This makes speeds go from ~1 Mb/s to the full connection speed (30 Mb/s in my case). It appears that TWC is forcing traffic to this netblock over a congested link, or otherwise throttling it. Trying to communicate this to tech support results in the typical "Derrr, what?" Does anyone at Time Warner care to comment on WTF? thanks, -Randy From tony at lavanauts.org Thu Mar 7 16:10:34 2013 From: tony at lavanauts.org (Antonio Querubin) Date: Thu, 7 Mar 2013 06:10:34 -1000 (HST) Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Wed, 6 Mar 2013, Mukom Akong T. wrote: > On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin wrote: > >> I don't think the business case is the issue. It is the timeline over >> which the sense of urgency becomes important enough for most execs to take >> seriously. That's still a large unknown. > > > Why should they care about the timeline if they aren't convinced it is even > worth doing? If they're convinced that it's not worth doing ever - then you're wasting your own time. They may think it's not worth a lot of effort over the immediate future but if the effort is spread thinly and integrated into regular infrastructure upgrades over a longer period of time then that's an easier pill to swallow. Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From mukom.tamon at gmail.com Thu Mar 7 18:16:11 2013 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Thu, 7 Mar 2013 22:16:11 +0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: On Thursday, March 7, 2013, Antonio Querubin wrote: > On Wed, 6 Mar 2013, Mukom Akong T. wrote: > > On Wed, Mar 6, 2013 at 8:20 PM, Antonio Querubin >> wrote: >> >> I don't think the business case is the issue. It is the timeline over >>> which the sense of urgency becomes important enough for most execs to >>> take >>> seriously. That's still a large unknown. >>> >> >> >> Why should they care about the timeline if they aren't convinced it is >> even >> worth doing? >> > > If they're convinced that it's not worth doing ever - then you're wasting > your own time. They may think it's not worth a lot of effort over the > immediate future but if the effort is spread thinly and integrated into > regular infrastructure upgrades over a longer period of time then that's an > easier pill to swallow. You are talking about people who have already decided its worth doing and so they need convincing as to how early to start. I am thinking of people who need convincing in the first place. For such people, business case is their language, timeline comes after they are convinced > > Antonio Querubin > e-mail: tony at lavanauts.org > xmpp: antonioquerubin at gmail.com > -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ ?When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran ------------------------------------------------------------------------------------------------------------------------------------------- From jason at lixfeld.ca Thu Mar 7 19:10:43 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 7 Mar 2013 14:10:43 -0500 Subject: AT&T AM Director for New York Message-ID: <4AA9661A-3557-49EF-9A95-30B598C9EA48@lixfeld.ca> To any AT&T sales folks listening, my account manager has not been very good at following up on multiple requests to quote increases in my IP transit commits. If any account manager directors or other tiers who these AMs might report to could contact me, I'd love to give you their name so you can light a fire under their ass. Thanks in advance. From vinod408 at hotmail.com Thu Mar 7 19:52:30 2013 From: vinod408 at hotmail.com (Vinod K) Date: Thu, 7 Mar 2013 19:52:30 +0000 Subject: Comcast NOC Contact In-Reply-To: References: , , , <465966A5F5B867419F604CD3E604C1E53B04CA59@PRA-DCA-MAIL.pra.ray.com>, Message-ID: Eugen and NANOG I'm sorry. My earlier comment was from conversation my last employer had about peering with Comcast where they told us they had balanced ratios. You can see from Ren Provo that is no longer true. This is politics as usual, playing the silly game. I am sorry to offend. I wish they work things out with Google so Youtube will stop buffering. Regards Vinod > Date: Thu, 7 Mar 2013 17:16:47 +0200 > Subject: Re: Comcast NOC Contact > From: eugen at imacandi.net > To: nanog at nanog.org > > My comment was more or less directed to the person that said "losts of > people want to send traffic to comcast, but no one wants to send money". I > find it very dangerous and provocative, and somewhat on the same line with > others that believe in the "sender party pays" crap they're trying to force > onto the market. > > > On Thu, Mar 7, 2013 at 4:13 PM, Jamie Bowden wrote: > > > > From: Eugeniu Patrascu [mailto:eugen at imacandi.net] > > > > > > > Comcast's customers send money to Comcast in order to receive whatever > > > they > > > want from other networks. With that money, Comcast should invest in > > > infrastructure so that it's network is not saturated anymore. Isn't this > > > how IPSs work ? :) > > > > In competitive markets, that's the theory. That would require one to test > > with... > > > > Jamie > > From vinod408 at hotmail.com Thu Mar 7 19:57:11 2013 From: vinod408 at hotmail.com (Vinod K) Date: Thu, 7 Mar 2013 19:57:11 +0000 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <5137ADAB.3030809@matthew.at> References: , <201303051534440664.01900314@sentry.24cl.com>, , <38E99259-E349-4444-85B6-71B1FF6208AF@delong.com>, <5136BE2C.3060804@matthew.at>, , <5136E23F.3060400@matthew.at>, , <5137ADAB.3030809@matthew.at> Message-ID: Matthew, I am sorry to offend, but I don't think the Skype development "agile" when u say IPv6 is not needed or important in 2013. Microsoft hs strong thought leaders like VJ Gill and Najam Ahmad who bring v6 to Bing and GFS. You should follow their example. Regards Vinod > Date: Wed, 6 Mar 2013 12:57:15 -0800 > From: matthew at matthew.at > To: cb.list6 at gmail.com > Subject: Re: What Should an Engineer Address when 'Selling' IPv6 to Executives? > CC: nanog at nanog.org > > On 3/6/2013 9:20 AM, Cameron Byrne wrote: > > On Tue, Mar 5, 2013 at 10:29 PM, Matthew Kaufman wrote: > >> On 3/5/2013 8:20 PM, Owen DeLong wrote: > >>> On Mar 5, 2013, at 7:55 PM, Matthew Kaufman wrote: > >>> > >>>> On 3/5/2013 7:15 PM, Owen DeLong wrote: > >>>>> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. > >>>>> wrote: > >>>>> > >>>>>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. wrote: > >>>>>> > >>>>>>> I would lean towards > >>>>>>> > >>>>>>> f) Cost/benefit of deploying IPv6. > >>>>>>> > >>>>>> I certainly agree, which is why I propose understanding you > >>>>>> organisation's > >>>>>> business model and how specifically v4 exhaustion will threaten that. > >>>>>> IPv6 > >>>>>> is the cast as a solution to that, plus future unknown benefits that > >>>>>> may > >>>>>> result from e-2-e and NAT elimination. > >>>>>> > >>>>>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now > >>>>>> even > >>>>>> for engineers, there's not much of a benefit except more address space. > >>>>> I'm not so sure about that? > >>>>> > >>>>> Admittedly, most of these are too technical to be suitable for > >>>>> management consumption, but: > >>>>> > >>>>> 1. Decreased application complexity: > >>>> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time > >>>> from now. Until then? > >>>> > >>> I don't think so. I think IPv4's demise as a supported internet protocol > >>> is certainly less than 10 years away and likely less than 5. I say this > >>> because IPv6 deployment is a bit of a variable here and we're faced with one > >>> of two outcomes as a result: > >> > >> Two unsubstantiated suppositions deleted. > >> > >> They suggest that IPv4 support is needed *in conjunction with* IPv6 support > >> for 5-8 years. > >> > >> That's a long time if you're developing software... so, basically, no... no > >> cost or effort saving if you were to do this work today. In fact, >2x the > >> effort if you were to start today. > >> > >> So again, why try to sell it to the engineers that way? Either sell it as 1) > >> If you don't start doing a lot more work now you'll be screwed at the > >> transition or 2) You should just wait until you can single-stack on IPv6. > >> > >> > >>> Why? I doubt any software vendor will continue to maintain NAT traversal > >>> code much after IPv4 is no longer the common inter-domain protocol of > >>> choice. > >> > >> Sure. In 5 to 8 years, as you claimed. > >> > >> > >>> Doubt it all you want. Once it's gone, it stops generating support calls, > >>> or they become very short: > >>> > >>> C: "Hi, my application isn't working through my NAT." > >>> TSR: "Hi? Get IPv6, we don't support NAT any more." > >>> TSR: "Is there anything else I can help you with today?" > >> > >> C: "Hi, my application isn't working between me and my grandmother" > >> TSR: "Hi... Get IPv6, we don't suppotr NAT any more." > >> C: "Screw you guys... my grandmother isn't served by an ISP that is offering > >> IPv6 and her old operating system barely supports it anyway. Please refund > >> my money." > >> > >> The point being that for some applications, *both ends* need to be on IPv6 > >> before any of this complexity can go away. > >> > >> For the rest, they're just talking to web services... and until the places > >> those are hosted run out of IPv4 addresses, nobody cares. > >> > > So, your position, which is substantiated my Microsoft's / Windows > > Phone's / Skype's lack of IPv6 support , is that "nobody cares" until > > we "run out of IPv4". > > No. While you've cleverly quoted something I did say, Skype is an > example of an application where, as I mentioned in the paragraph above, > until both ends of a call are always guaranteed to be on IPv6, there is > *more* complexity involved in supporting both IPv4 and IPv6 than in > supporting IPv4 alone. > > This entire discussion started with "how should I sell IPv6 to > executives" and Owen claimed that switching to IPv6 represents less > engineering effort. I simply claim that isn't true. In fact the amount > of engineering effort required to make an application like Skype work > (both development effort and testing required) where the users who might > want to call each other are on an unknown mixture of IPv4, IPv4/IPv6 > dual-stack, IPv6 w/NAT64 for IPv4, and IPv6 single-stack is *tremendous* > compared to the effort required to make it work with IPv4 and end-user > NAT devices. > > > > > But, Matthew, your division of Microsoft is really a bunch of "Free > > Riders" that is honestly holding back the rest of us. > > My division of Microsoft is currently engaged in a massive amount of > engineering... work to add features that customers are demanding, work > to make Skype work better on mobile devices, work to make Skype > interoperate with Lync, and yes, work to make Skype work in the huge > explosion of new network connectivity situations it will find itself in > as IPv6 is deployed and especially as those IPv6 users stop getting > native IPv4 alongside it. > > And we're using Agile and Scrum as our engineering methodology, and I > can tell you that it is very very hard to get IPv6 work to rise to the > top in any organization, including ours, given that the short-term > return on that investment is nil and the engineering and testing effort > is huge. > > But again, the only reason I even brought this up here is that there are > people like Owen running around trying to tell engineers that when the > whole world is IPv6 everything will be so much easier... and while that > might be true, there are at least 5 more years and probably more where > the necessary engineering effort required to support *both*, especially > for applications like Skype, is crazy hard compared to IPv4-only, and so > trying to sell the execs on the idea that we'll deploy some IPv6 > internally and write some IPv6 code and our QE and Dev budget can go > *down* is frankly ridiculous. > > > > Matthew Kaufman > > p.s. As I pointed out privately last night, if doing IPv4+IPv6 was > really easier than doing IPv4-only, we wouldn't see other smart > collections of engineers with bugs like this one: > https://code.google.com/p/webrtc/issues/detail?id=1406 (because > *clearly* there's no reason to have taken the "extra effort" to make it > IPv4-only, right?) > From beavis.daniels at gmail.com Thu Mar 7 20:22:43 2013 From: beavis.daniels at gmail.com (beavis daniels) Date: Thu, 7 Mar 2013 22:22:43 +0200 Subject: internet routing table in a vrf Message-ID: hi I would to enquire about the cons/pros of running a full internet routing table in a vrf and the potential challenges of operating it in a VPN cross a large network that does peering and provide transit. I not a fan to support running it in a vrf. I am looking for a list of operational and technical challenges specifically around 1) control plane (route reflectors ) 2) forward plane (recursive lookup issues) 3) Operational 4) DDOS 5) BCP and RFC that would break eg "BGP-SEC does not support in todays draft to check prefixs within the VPN" 6) Vendor specifics From dwhite at olp.net Thu Mar 7 21:23:26 2013 From: dwhite at olp.net (Dan White) Date: Thu, 7 Mar 2013 15:23:26 -0600 Subject: internet routing table in a vrf In-Reply-To: References: Message-ID: <20130307212326.GC6412@dan.olp.net> On 03/07/13?22:22?+0200, beavis daniels wrote: >hi > >I would to enquire about the cons/pros of running a full internet routing >table in a vrf and the potential challenges of operating it in a VPN cross >a large network that does peering and provide transit. > >I not a fan to support running it in a vrf. > >I am looking for a list of operational and technical challenges > >specifically around >1) control plane (route reflectors ) >2) forward plane (recursive lookup issues) >3) Operational >4) DDOS >5) BCP and RFC that would break eg "BGP-SEC does not support in todays >draft to check prefixs within the VPN" >6) Vendor specifics We decided against deploying our internet routes via vpnvX. Two major holdups for us were: Each route inside a vpnv4 table will consume more cam (96 bits versus 32), which adds up when taking full routes. Brocade XMR does not support distributing routes via vpnv6, or it did not when we were designing our MPLS network. One of the benefits of distributing internet routes inside a VRF is that it logically separates those routes from your IGP routing tables (your P routers don't see internet routes). Keeping internet routes inside your default VRF may lead to unexpectedly leaking IGP routes out to your BGP sessions, so BGP filters are important, as well as using unique (RIR) addresses inside your MPLS mesh. -- Dan White From paul4004 at gmail.com Fri Mar 8 04:50:15 2013 From: paul4004 at gmail.com (PC) Date: Thu, 7 Mar 2013 21:50:15 -0700 Subject: internet routing table in a vrf In-Reply-To: <20130307212326.GC6412@dan.olp.net> References: <20130307212326.GC6412@dan.olp.net> Message-ID: I've done this on multiple vendor platforms, including full routes, and haven't had any issues. Resource consumption varies on vendor and implementation, but I've observed that its not as punitive as I thought it would be due to various optimizations. Granted, in most of my cases, it was in a VRF, but I was not running MPLS. On Thu, Mar 7, 2013 at 2:23 PM, Dan White wrote: > On 03/07/13 22:22 +0200, beavis daniels wrote: > >> hi >> >> I would to enquire about the cons/pros of running a full internet routing >> table in a vrf and the potential challenges of operating it in a VPN cross >> a large network that does peering and provide transit. >> >> I not a fan to support running it in a vrf. >> >> I am looking for a list of operational and technical challenges >> >> specifically around >> 1) control plane (route reflectors ) >> 2) forward plane (recursive lookup issues) >> 3) Operational >> 4) DDOS >> 5) BCP and RFC that would break eg "BGP-SEC does not support in todays >> draft to check prefixs within the VPN" >> 6) Vendor specifics >> > > We decided against deploying our internet routes via vpnvX. Two major > holdups for us were: > > Each route inside a vpnv4 table will consume more cam (96 bits versus > 32), which adds up when taking full routes. > > Brocade XMR does not support distributing routes via vpnv6, or it did not > when we were designing our MPLS network. > > One of the benefits of distributing internet routes inside a VRF is that it > logically separates those routes from your IGP routing tables (your P > routers don't see internet routes). Keeping internet routes inside your > default VRF may lead to unexpectedly leaking IGP routes out to your BGP > sessions, so BGP filters are important, as well as using unique (RIR) > addresses inside your MPLS mesh. > > -- > Dan White > > From maem at maem.org Fri Mar 8 07:48:18 2013 From: maem at maem.org (MAEMURA Akinori) Date: Fri, 08 Mar 2013 16:48:18 +0900 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <51389AAB.2030305@gmail.com> References: <95F2D89E-AF5C-431B-86F5-859EBB53B8AA@arbor.net> <168517A9-F805-468C-922A-307488EBBB70@puck.nether.net> <2CEB1D36-3963-4C62-A99E-5F303E8B4CAB@arbor.net> <173956E9-397B-46EA-B80F-01A3A6440FF2@lacnic.net> <2695AFD4-A5CA-44C1-8686-B177D807BF2B@istaff.org> <51389AAB.2030305@gmail.com> Message-ID: <513997C2.8070305@maem.org> Same here in Japan. Pretty much agree on what John has listed. I observe that recognizing two things is important: * IPv6 will definitely be needed in not-near future, thus the preparation is definitely needed * An immediate justification for big investment is nearly impossible The ISPs and carriers who are successful to deploy IPv6 started from this point and taking steps like 2) and 3) with very small investment and obtain the skills within the engineers which later helped much to have the company light a green signal for official launch. It took years. Cheers, MAEMURA Akinori (2013/03/07 22:48), Arturo Servin wrote: > Pretty much the same process that I have seen in many ISPs and enterprises. > > Regards. > as > > On 07/03/2013 11:32, John Curran wrote: >> On Mar 7, 2013, at 5:42 AM, Arturo Servin wrote: >> >>> Yes, but this is an argument to deploy the whole IPv6 thing, not against a strategy to first deploy in-house and then to customers, isn't it? >>> In my experience, it is always best to try IPv6 in-house (at least a small office, a group, etc.) and then move to customers, YMMV. >> Presuming a medium/small service provider, the most typical sequence >> that I've been hearing runs something like this: >> >> 1. Engineers internally experiment with IPv6 on an individual basis >> (lab, tunnels, virtual servers, etc.) Doesn't always happen, >> but the ones that don't are making their own gamble regarding >> their skills and career trajectory. >> >> 2. Some formal recognition by the network team of need to gain IPv6 >> experience; this can be equipment for a "real" lab, formal training, >> minor investment in external firewalls to bring up to spec, etc. >> >> 3. The network folks start arranging for real IPv6 connectivity from >> the outside, this could be transit or peering, and begin working >> on plans for the "network backbone" to be fully dual-stack. >> >> 4. The "talk" with IT regarding IPv6, and acceptance of the concept >> that it would be nice if the web site had some minimal support >> (yes, maybe not the customer ticketing/feedback system, or every >> page, but at least the major content sections.) This leads to >> the idea that IT will test new web rollouts with IPv6, and the >> need therefore to get IPv6 to some of the integration/QA folks. >> >> 5. IT/internal network team realization that they have to get IPv6 >> internally to some of the Internet network team, some of the >> developers, and that means that the "corporate" network really >> does need to support IPv6, and that means those firewalls, and >> management and training for the internal corporate network team. >> >> 6. Several meetings with marketing and sales trying to explain that >> other organizations (i.e. customers are doing the same thing, and >> a general mismatch in expectations since the vast majority of >> customers have never uttered "IPv6" to anyone in sales/marketing. >> >> 7. Slow but steady internal progress on IPv6 deployment in the company, >> all while waiting for sales/marketing to recognize the need for IPv6 >> services for customers. >> >> 8. One key event (often a customer RFP requirement, or a sale lost due >> to lack of IPv6 support) occurs, which then brings the lack of IPv6 >> into focus as a competitive issue, and subsequent discussions about >> budget/investment for adding IPv6 support to the service catalog. >> >> YMMV, and every organization is a little different, but the common theme >> is that the more awareness that we can generate in CIO/IT industry about >> the IPv4 constraints facing the Internet network industry, the faster >> that IPv6 will happen... >> >> /John >> >> >> >> From adam.vitkovsky at swan.sk Fri Mar 8 08:37:49 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Fri, 8 Mar 2013 09:37:49 +0100 Subject: internet routing table in a vrf In-Reply-To: References: Message-ID: <009701ce1bd8$37472b60$a5d58220$@swan.sk> Hi 1) control plane (route reflectors ) - you can either run a separate control plane infrastructure for inet vrf or you can use common RRs that depends on your hardware capabilities (or you can run a separate BGP process for reflecting inet vrf). - no need to worry about data-plane as VPN routes are not installed into FIB on RRs. - as it was mentioned already porting inet prefixes into VPN table increases control-plane demands. 2) forward plane (recursive lookup issues) - for inet vrf I'd recommend per CE/next-hop labels instead of per prefix labels to save up some label space. - per next-hop label still points directly to outgoing interface so no recursive lookups. - recursive lookups are only needed with per VRF label -but I would not recommend that as it could introduce loops when PIC is used in some scenarios. 3) Operational - I find it operationally complex to keep inet table on the P-Core boxes/vrf-default. 4) DDOS - as I mentioned you can run a separate infrastructure for inet vrf i.e. dedicated box or SDR for inet PEs and inet RRs. - or you can use separate BGP processes so in case some university decides to test some special attribute on their BGP advertisements it will not reload your VPN BGP process. - or you can deploy enhanced BGP error handling on the edges and hope for the best (actually this is what should be implemented as a first thing). adam From uwcableguy at gmail.com Fri Mar 8 16:38:04 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 8 Mar 2013 10:38:04 -0600 Subject: Intermapper vs NetBrain vs some other for NMS Message-ID: Hi all: I'm looking for information anyone might have comparing Intermapper to NetBrain for NMS. Stuff like devices up/down, interface utilization, building maps for documentation, etc. IMO, Intermapper works great, when it works. Tech support has been slow and often cannot fix the problems, not to mention they release updates about once every other week. Anyone familiar with any similar products? We are presently evaluating NetBrain and it seems really nice. We really like the Visio-like aspect of it. Thanks! -Ben From matt.newsom at RACKSPACE.COM Fri Mar 8 16:40:01 2013 From: matt.newsom at RACKSPACE.COM (Matt Newsom) Date: Fri, 8 Mar 2013 16:40:01 +0000 Subject: internet routing table in a vrf In-Reply-To: References: Message-ID: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> Internet in a vrf is doable on most platforms and definitely adds a lot of flexibility. 1) control plane (route reflectors ) This is really dependent on your platform and whether you are doing multiple RD's or not. If you divide your transit into regions and filter based upon RT you can tier your route-reflectors to get plenty of scalability. 2) forward plane (recursive lookup issues) Most platforms program prefix's with associated labels slower so your base convergence will suffer. In addition if you want to run PIC you will likely be left with a bit of custom engineering to make it work. VPN's hide the next hop behind the loopback of the PE so next hop failure awareness of an edge tie will be lost. If you can stomach the double lookup you can run per-vrf labels (per prefix isn't feasible on most platforms) and weight up your edge ties and force a bounce back to another PE, otherwise you will be stuck with bgp control plane based convergence with per-ce labels. 3) Operational It's definitely harder to train operation people on how to look in a vrf. 4) DDOS It's actually much easier to design a DDOS filtering system if everything is in VRF's. If you create separate vrf's for transit and subscription your can have extreme flexibility in DDOS filtering. The import export flexibility allows for injection of /32 or /128's into your transit vrf and you can simply hang your DDOS mitigation seems between the transit and subscription VRF's. 5) BCP and RFC that would break eg "BGP-SEC does not support in todays draft to check prefixs within the VPN" We haven't found any significant functionality we would want to use other than PIC that it would break, and there was a work around with that. 6) Vendor specifics You are probably ok with most vendors but a few still have issues with table carving, and a few don't support 6VPE. -----Original Message----- From: beavis daniels [mailto:beavis.daniels at gmail.com] Sent: Thursday, March 07, 2013 2:23 PM To: nanog at nanog.org Subject: internet routing table in a vrf hi I would to enquire about the cons/pros of running a full internet routing table in a vrf and the potential challenges of operating it in a VPN cross a large network that does peering and provide transit. I not a fan to support running it in a vrf. I am looking for a list of operational and technical challenges specifically around 1) control plane (route reflectors ) 2) forward plane (recursive lookup issues) 3) Operational 4) DDOS 5) BCP and RFC that would break eg "BGP-SEC does not support in todays draft to check prefixs within the VPN" 6) Vendor specifics From source_route at yahoo.com Fri Mar 8 16:48:00 2013 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 8 Mar 2013 08:48:00 -0800 (PST) Subject: is yahoo in trouble? Message-ID: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> I am getting Connection refused on a lot of links From thegameiam at yahoo.com Fri Mar 8 16:49:14 2013 From: thegameiam at yahoo.com (David Barak) Date: Fri, 8 Mar 2013 08:49:14 -0800 Subject: Intermapper vs NetBrain vs some other for NMS In-Reply-To: References: Message-ID: <76B9876F-6121-41D9-86F1-5B43904A6003@yahoo.com> I like intermapper for monitoring: it's been very stable, and exports traps and notifications well. I also like netbrain for troubleshooting and mapmaking, because its visualization is engineer and manager-friendly. David Barak Sent from a mobile device, please forgive autocorrection and top posting. On Mar 8, 2013, at 8:38 AM, Ben Bartsch wrote: > Hi all: > > I'm looking for information anyone might have comparing Intermapper to > NetBrain for NMS. Stuff like devices up/down, interface utilization, > building maps for documentation, etc. IMO, Intermapper works great, when > it works. Tech support has been slow and often cannot fix the problems, > not to mention they release updates about once every other week. > > Anyone familiar with any similar products? We are presently evaluating > NetBrain and it seems really nice. We really like the Visio-like aspect of > it. > > Thanks! > > -Ben From jason at lixfeld.ca Fri Mar 8 16:55:58 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 8 Mar 2013 11:55:58 -0500 Subject: Intermapper vs NetBrain vs some other for NMS In-Reply-To: References: Message-ID: I'd also be very interested in what's out there. I have similar grievances with InterMapper, but at this point, it sucks far less than anything else I've tried. I just poked around NetBrain's site and am immediately deterred by it's reliance on a Windows backend, so that's out for me. I did use OpenNMS for a while before switching to InterMapper, but ONMS's discovery/mapping was very broken at the time, it was a PITA to set up and manage and I don't know if it's gotten much getter in the last couple of years since. I've tried things like ManageEngine, but it's far too bloated and complex for what I need. On 2013-03-08, at 11:38 AM, Ben Bartsch wrote: > Hi all: > > I'm looking for information anyone might have comparing Intermapper to > NetBrain for NMS. Stuff like devices up/down, interface utilization, > building maps for documentation, etc. IMO, Intermapper works great, when > it works. Tech support has been slow and often cannot fix the problems, > not to mention they release updates about once every other week. > > Anyone familiar with any similar products? We are presently evaluating > NetBrain and it seems really nice. We really like the Visio-like aspect of > it. > > Thanks! > > -Ben From dwhite at olp.net Fri Mar 8 16:56:32 2013 From: dwhite at olp.net (Dan White) Date: Fri, 8 Mar 2013 10:56:32 -0600 Subject: is yahoo in trouble? In-Reply-To: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> References: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> Message-ID: <20130308165631.GE5281@dan.olp.net> On 03/08/13?08:48?-0800, Philip Lavine wrote: >I am getting Connection refused on a lot of links I am also seeing errors. Here is a result from a random link on the frontpage: ~$ curl http://news.yahoo.com/half-girls-south-sudan-forced-marry-140334618.html Connection refused Connection refused My path to yahoo: ~$ traceroute news.yahoo.com traceroute to news.yahoo.com (66.94.233.187), 30 hops max, 60 byte packets 1 10.0.2.1 (10.0.2.1) 1.088 ms 1.265 ms 3.917 ms 2 olp-67-217-152-5.olp.net (67.217.152.5) 3.436 ms 3.629 ms 4.125 ms 3 router.olp.net (67.217.151.97) 2.515 ms 2.753 ms 2.991 ms 4 olp-67-217-152-34.olp.net (67.217.152.34) 4.317 ms 4.555 ms 4.788 ms 5 gi1-6.ccr01.tul01.atlas.cogentco.com (38.104.198.73) 39.056 ms 39.280 ms 39.502 ms 6 te0-2-0-7.ccr22.dfw01.atlas.cogentco.com (154.54.5.13) 11.012 ms 7.656 ms 7.913 ms 7 te0-6-0-5.ccr22.dfw03.atlas.cogentco.com (154.54.82.26) 8.359 ms te0-1-0-5.ccr22.dfw03.atlas.cogentco.com (66.28.4.134) 8.541 ms te0-6-0-1.ccr22.dfw03.atlas.cogentco.com (154.54.6.62) 9.064 ms 8 te4-1.mag01.dfw03.atlas.cogentco.com (154.54.81.38) 8.792 ms 9.283 ms 9.588 ms 9 yahoo.dfw03.atlas.cogentco.com (154.54.10.138) 9.813 ms 10.033 ms yahoo.dfw03.atlas.cogentco.com (154.54.10.6) 10.273 ms 10 ae-2-d100.msr1.mud.yahoo.com (216.115.104.105) 10.771 ms ae-2-d111.msr2.mud.yahoo.com (216.115.104.111) 11.129 ms ae-1-d111.msr2.mud.yahoo.com (216.115.104.103) 11.349 ms 11 te-6-2.fab2-a-gdc.mud.yahoo.com (209.191.78.153) 12.060 ms te-6-2.fab1-a-gdc.mud.yahoo.com (209.191.78.145) 11.848 ms te-8-1.fab1-a-gdc.mud.yahoo.com (209.191.78.133) 12.270 ms 12 te-8-1.bas1-1-prd.mud.yahoo.com (66.94.233.225) 8.665 ms 9.011 ms unknown-66-94-233-x.yahoo.com (66.94.233.237) 8.528 ms 13 * * * 14 * * * -- Dan White From bicknell at ufp.org Fri Mar 8 16:58:47 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 8 Mar 2013 08:58:47 -0800 Subject: is yahoo in trouble? In-Reply-To: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> References: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> Message-ID: <20130308165847.GA91129@ussenterprise.ufp.org> In a message written on Fri, Mar 08, 2013 at 08:48:00AM -0800, Philip Lavine wrote: > I am getting Connection refused on a lot of links I think many of their servers were telecommuting from remote data centers, and were told they were no longer needed if they couldn't come into the office... -- 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 jnegro at advance.net Fri Mar 8 16:59:47 2013 From: jnegro at advance.net (Jeffrey Negro) Date: Fri, 8 Mar 2013 16:59:47 +0000 Subject: Intermapper vs NetBrain vs some other for NMS In-Reply-To: References: Message-ID: I've always had a love/hate relationship with Cacti for this type of thing. If you have the Monitor, Threshold, and Weathermap plugins installed, it's very extensible and would probably meet your needs well. Weathermap has a decent in-app designer that has a Visio feel. The hate part comes when dealing with its poller and RRD processing, which are a bit of a pain to troubleshoot when they go on the fritz. Also, it has a bit of a learning curve, mainly due to the extensibility it allows, and initially getting it going takes some work (some Linux CLI skills). I'm not sure how it compares to NetBrain or Intermapper, but Cacti is open source and doesn't have a commercial support option. Not sure if that's something you're looking for, just FYI. -- Jeff -----Original Message----- From: Ben Bartsch [mailto:uwcableguy at gmail.com] Sent: Friday, March 08, 2013 11:38 AM To: NANOG Subject: Intermapper vs NetBrain vs some other for NMS Hi all: I'm looking for information anyone might have comparing Intermapper to NetBrain for NMS. Stuff like devices up/down, interface utilization, building maps for documentation, etc. IMO, Intermapper works great, when it works. Tech support has been slow and often cannot fix the problems, not to mention they release updates about once every other week. Anyone familiar with any similar products? We are presently evaluating NetBrain and it seems really nice. We really like the Visio-like aspect of it. Thanks! -Ben ------------------------------------------------------------------------------------------------ This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. From raysonlogin at gmail.com Fri Mar 8 17:02:33 2013 From: raysonlogin at gmail.com (Rayson Ho) Date: Fri, 8 Mar 2013 12:02:33 -0500 Subject: is yahoo in trouble? In-Reply-To: <20130308165631.GE5281@dan.olp.net> References: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> <20130308165631.GE5281@dan.olp.net> Message-ID: The Yahoo sites must be working fine when accessed from Yahoo's office, but since working from home is banned, the workers are not able to check! :-D Rayson ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ On Fri, Mar 8, 2013 at 11:56 AM, Dan White wrote: > On 03/08/13 08:48 -0800, Philip Lavine wrote: >> >> I am getting Connection refused on a lot of links > > > I am also seeing errors. Here is a result from a random link on the > frontpage: > > ~$ curl > http://news.yahoo.com/half-girls-south-sudan-forced-marry-140334618.html > Connection refused > > > Connection refused > > > > > My path to yahoo: > > ~$ traceroute news.yahoo.com > traceroute to news.yahoo.com (66.94.233.187), 30 hops max, 60 byte packets > 1 10.0.2.1 (10.0.2.1) 1.088 ms 1.265 ms 3.917 ms > 2 olp-67-217-152-5.olp.net (67.217.152.5) 3.436 ms 3.629 ms 4.125 ms > 3 router.olp.net (67.217.151.97) 2.515 ms 2.753 ms 2.991 ms > 4 olp-67-217-152-34.olp.net (67.217.152.34) 4.317 ms 4.555 ms 4.788 ms > 5 gi1-6.ccr01.tul01.atlas.cogentco.com (38.104.198.73) 39.056 ms 39.280 > ms 39.502 ms > 6 te0-2-0-7.ccr22.dfw01.atlas.cogentco.com (154.54.5.13) 11.012 ms > 7.656 ms 7.913 ms > 7 te0-6-0-5.ccr22.dfw03.atlas.cogentco.com (154.54.82.26) 8.359 ms > te0-1-0-5.ccr22.dfw03.atlas.cogentco.com (66.28.4.134) 8.541 ms > te0-6-0-1.ccr22.dfw03.atlas.cogentco.com (154.54.6.62) 9.064 ms > 8 te4-1.mag01.dfw03.atlas.cogentco.com (154.54.81.38) 8.792 ms 9.283 ms > 9.588 ms > 9 yahoo.dfw03.atlas.cogentco.com (154.54.10.138) 9.813 ms 10.033 ms > yahoo.dfw03.atlas.cogentco.com (154.54.10.6) 10.273 ms > 10 ae-2-d100.msr1.mud.yahoo.com (216.115.104.105) 10.771 ms > ae-2-d111.msr2.mud.yahoo.com (216.115.104.111) 11.129 ms > ae-1-d111.msr2.mud.yahoo.com (216.115.104.103) 11.349 ms > 11 te-6-2.fab2-a-gdc.mud.yahoo.com (209.191.78.153) 12.060 ms > te-6-2.fab1-a-gdc.mud.yahoo.com (209.191.78.145) 11.848 ms > te-8-1.fab1-a-gdc.mud.yahoo.com (209.191.78.133) 12.270 ms > 12 te-8-1.bas1-1-prd.mud.yahoo.com (66.94.233.225) 8.665 ms 9.011 ms > unknown-66-94-233-x.yahoo.com (66.94.233.237) 8.528 ms > 13 * * * > 14 * * * > > > -- > Dan White > From jabley at hopcount.ca Fri Mar 8 17:05:29 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 8 Mar 2013 12:05:29 -0500 Subject: public consultation on root zone KSK rollover Message-ID: Hi all, The following ICANN public comment period opened today: http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm The questions relate to DNSSEC rollover in the root zone, and hence are relevant to anybody doing DNSSEC validation. Your responses to the questions presented above would be most welcome. Please feel very free to pass on the link to anybody you think might be interested in this topic. Joe From saku at ytti.fi Fri Mar 8 17:23:24 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 8 Mar 2013 19:23:24 +0200 Subject: internet routing table in a vrf In-Reply-To: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> References: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> Message-ID: <20130308172324.GA18010@pob.ytti.fi> On (2013-03-08 16:40 +0000), Matt Newsom wrote: > 2) forward plane (recursive lookup issues) > Most platforms program prefix's with associated labels slower so your base convergence will suffer. Do you have any reference you could share? What level of penalty per prefix have you observed in each platform tested? >In addition if you want to run PIC you will likely be left with a bit of custom engineering to make it work. VPN's hide the next hop behind the loopback of the PE so next hop failure awareness of an edge tie will be lost. If you can stomach the double lookup you can run per-vrf labels (per prefix isn't feasible on most platforms) and weight up your edge ties and force a bounce back to another PE, otherwise you will be stuck with bgp control plane based convergence with per-ce labels. PIC is about converging each prefix at the same time. It does not make statement where next_hop is pointing, is it loop0 (next-hop-self in INET) or is it edge CE. If your IGP carries all edge links, and you don't run next-hop-self, far end PE can converge faster in INET scenario. But current efforts are not to fix this, current efforts are to make the local PE do hitless repair when arriving frame is pointing to dead edge interface. It seems to be very rare to run INET in this way, majority don't carry edge links in IGP and do run next-hop-self. -- ++ytti From lykinsbd at gmail.com Fri Mar 8 17:33:25 2013 From: lykinsbd at gmail.com (Brett Lykins) Date: Fri, 8 Mar 2013 12:33:25 -0500 Subject: Intermapper vs NetBrain vs some other for NMS In-Reply-To: References: Message-ID: <5088021197456334284@unknownmsgid> I would second Cacti as a great extensible resource, (with Threshold, Monitor, and Weathermap plugins) with the caveat that it almost requires someone on the team to take it on as a hobby if you want to get the most out of it. You really need someone who loves to tinker, (and has the time) but the payoff in the end can be worth it. -Brett Lykins On Mar 8, 2013, at 12:06 PM, Jeffrey Negro wrote: > I've always had a love/hate relationship with Cacti for this type of thing. If you have the Monitor, Threshold, and Weathermap plugins installed, it's very extensible and would probably meet your needs well. Weathermap has a decent in-app designer that has a Visio feel. The hate part comes when dealing with its poller and RRD processing, which are a bit of a pain to troubleshoot when they go on the fritz. Also, it has a bit of a learning curve, mainly due to the extensibility it allows, and initially getting it going takes some work (some Linux CLI skills). I'm not sure how it compares to NetBrain or Intermapper, but Cacti is open source and doesn't have a commercial support option. Not sure if that's something you're looking for, just FYI. > > -- Jeff > > -----Original Message----- > From: Ben Bartsch [mailto:uwcableguy at gmail.com] > Sent: Friday, March 08, 2013 11:38 AM > To: NANOG > Subject: Intermapper vs NetBrain vs some other for NMS > > Hi all: > > I'm looking for information anyone might have comparing Intermapper to NetBrain for NMS. Stuff like devices up/down, interface utilization, building maps for documentation, etc. IMO, Intermapper works great, when it works. Tech support has been slow and often cannot fix the problems, not to mention they release updates about once every other week. > > Anyone familiar with any similar products? We are presently evaluating NetBrain and it seems really nice. We really like the Visio-like aspect of it. > > Thanks! > > -Ben > ------------------------------------------------------------------------------------------------ > This e-mail, including attachments, is intended for the person(s) > or company named and may contain confidential and/or legally > privileged information. Unauthorized disclosure, copying or use of > this information may be unlawful and is prohibited. If you are not > the intended recipient, please delete this message and notify the > sender. > From jeffg at opennms.org Fri Mar 8 18:13:52 2013 From: jeffg at opennms.org (Jeff Gehlbach) Date: Fri, 08 Mar 2013 13:13:52 -0500 Subject: Intermapper vs NetBrain vs some other for NMS In-Reply-To: References: Message-ID: <513A2A60.2060605@opennms.org> On 03/08/2013 11:55 AM, Jason Lixfeld wrote: > I did use OpenNMS for a while before switching to InterMapper, but > ONMS's discovery/mapping was very broken at the time, it was a PITA > to set up and manage and I don't know if it's gotten much getter in > the last couple of years since. Hey Jason :) I believe you and I interacted a few times on the OpenNMS mailing lists. As a quick update addressing only the areas you mention, we added in the 1.8 series a new, massively scalable, policy-driven provisioning subsystem that can replace Capsd. So if by "discovery" you mean "node / interface / service scanning behavior", then yes, great strides there. Mapping is also much improved. The old SVG topo map, which at one point worked only in Internet Explorer with the Adobe SVG plugin (blech), now works in any modern WebKit or Gecko browser. There's also a whole slew of entirely new map options (both topo and geo) in the upcoming 1.12 releases. Well worth a look. Installation, setup, and administration have also seen continued improvements, with better packaging and an ever-dwindling set of configuration changes requiring a restart. As always, the whole OpenNMS platform is still 100% free and open-source software. -jeff From matt.newsom at RACKSPACE.COM Fri Mar 8 18:17:51 2013 From: matt.newsom at RACKSPACE.COM (Matt Newsom) Date: Fri, 8 Mar 2013 18:17:51 +0000 Subject: internet routing table in a vrf In-Reply-To: <20130308172324.GA18010@pob.ytti.fi> References: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> <20130308172324.GA18010@pob.ytti.fi> Message-ID: <93717E08238F7B4392FAD1F82A87FBD3AD88FBA8@ORD1EXD04.RACKSPACE.CORP> If you run PIC and hide the next hop information between a loopback which is what will happen in a vpn environment you will lose awareness of the failure of an edge link on a remote PE. The remote PE will continue to send traffic to the PE with the failed link until it has completely converged both at the control plane, and written to the FIB. If the remote PE has PIC running he can bounce that traffic back to his backup path via another PE. There will be some percentage of your traffic that will then form a transient micro loop though because that remote PE will have his primary path through the failed link due to shortest as path length etc, and he will not have converged yet around the failure on the remote PE and has no awareness of the failure. One possible solution to this is to guarantee that a PE will never use another PE for a primary transit route. This can be accomplished via metrics such as weight etc.. Again one of the downsides of this is you need to run VRF labels so that a local IP lookup can be done on the PE with the failed link and it can execute a local repair when it see's the link drop. -----Original Message----- From: Saku Ytti [mailto:saku at ytti.fi] Sent: Friday, March 08, 2013 11:23 AM To: nanog at nanog.org Subject: Re: internet routing table in a vrf On (2013-03-08 16:40 +0000), Matt Newsom wrote: > 2) forward plane (recursive lookup issues) > Most platforms program prefix's with associated labels slower so your base convergence will suffer. Do you have any reference you could share? What level of penalty per prefix have you observed in each platform tested? >In addition if you want to run PIC you will likely be left with a bit of custom engineering to make it work. VPN's hide the next hop behind the loopback of the PE so next hop failure awareness of an edge tie will be lost. If you can stomach the double lookup you can run per-vrf labels (per prefix isn't feasible on most platforms) and weight up your edge ties and force a bounce back to another PE, otherwise you will be stuck with bgp control plane based convergence with per-ce labels. PIC is about converging each prefix at the same time. It does not make statement where next_hop is pointing, is it loop0 (next-hop-self in INET) or is it edge CE. If your IGP carries all edge links, and you don't run next-hop-self, far end PE can converge faster in INET scenario. But current efforts are not to fix this, current efforts are to make the local PE do hitless repair when arriving frame is pointing to dead edge interface. It seems to be very rare to run INET in this way, majority don't carry edge links in IGP and do run next-hop-self. -- ++ytti From cscora at apnic.net Fri Mar 8 18:32:48 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Mar 2013 04:32:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201303081832.r28IWmu6019205@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Mar, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 444886 Prefixes after maximum aggregation: 183186 Deaggregation factor: 2.43 Unique aggregates announced to Internet: 218707 Total ASes present in the Internet Routing Table: 43533 Prefixes per ASN: 10.22 Origin-only ASes present in the Internet Routing Table: 34285 Origin ASes announcing only one prefix: 15995 Transit ASes present in the Internet Routing Table: 5792 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 367 Unregistered ASNs in the Routing Table: 135 Number of 32-bit ASNs allocated by the RIRs: 4593 Number of 32-bit ASNs visible in the Routing Table: 3456 Prefixes from 32-bit ASNs in the Routing Table: 9661 Special use prefixes present in the Routing Table: 17 Prefixes being announced from unallocated address space: 200 Number of addresses announced to Internet: 2621887244 Equivalent to 156 /8s, 70 /16s and 211 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.3 Total number of prefixes smaller than registry allocations: 156958 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 107004 Total APNIC prefixes after maximum aggregation: 33192 APNIC Deaggregation factor: 3.22 Prefixes being announced from the APNIC address blocks: 108127 Unique aggregates announced from the APNIC address blocks: 44072 APNIC Region origin ASes present in the Internet Routing Table: 4815 APNIC Prefixes per ASN: 22.46 APNIC Region origin ASes announcing only one prefix: 1236 APNIC Region transit ASes present in the Internet Routing Table: 815 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 453 Number of APNIC addresses announced to Internet: 719197984 Equivalent to 42 /8s, 222 /16s and 23 /24s Percentage of available APNIC address space announced: 84.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 156392 Total ARIN prefixes after maximum aggregation: 79156 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 157099 Unique aggregates announced from the ARIN address blocks: 71389 ARIN Region origin ASes present in the Internet Routing Table: 15535 ARIN Prefixes per ASN: 10.11 ARIN Region origin ASes announcing only one prefix: 5885 ARIN Region transit ASes present in the Internet Routing Table: 1615 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1078025856 Equivalent to 64 /8s, 65 /16s and 94 /24s Percentage of available ARIN address space announced: 57.0 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 114048 Total RIPE prefixes after maximum aggregation: 59078 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 117366 Unique aggregates announced from the RIPE address blocks: 75376 RIPE Region origin ASes present in the Internet Routing Table: 17103 RIPE Prefixes per ASN: 6.86 RIPE Region origin ASes announcing only one prefix: 8155 RIPE Region transit ASes present in the Internet Routing Table: 2802 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2231 Number of RIPE addresses announced to Internet: 654268260 Equivalent to 38 /8s, 255 /16s and 87 /24s Percentage of available RIPE address space announced: 95.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47079 Total LACNIC prefixes after maximum aggregation: 9296 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 50942 Unique aggregates announced from the LACNIC address blocks: 23953 LACNIC Region origin ASes present in the Internet Routing Table: 1855 LACNIC Prefixes per ASN: 27.46 LACNIC Region origin ASes announcing only one prefix: 542 LACNIC Region transit ASes present in the Internet Routing Table: 342 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 747 Number of LACNIC addresses announced to Internet: 124659464 Equivalent to 7 /8s, 110 /16s and 39 /24s Percentage of available LACNIC address space announced: 74.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10573 Total AfriNIC prefixes after maximum aggregation: 2413 AfriNIC Deaggregation factor: 4.38 Prefixes being announced from the AfriNIC address blocks: 11152 Unique aggregates announced from the AfriNIC address blocks: 3742 AfriNIC Region origin ASes present in the Internet Routing Table: 606 AfriNIC Prefixes per ASN: 18.40 AfriNIC Region origin ASes announcing only one prefix: 177 AfriNIC Region transit ASes present in the Internet Routing Table: 129 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 45354752 Equivalent to 2 /8s, 180 /16s and 15 /24s Percentage of available AfriNIC address space announced: 45.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2929 11558 922 Korea Telecom (KIX) 17974 2503 840 86 PT TELEKOMUNIKASI INDONESIA 7545 1829 301 89 TPG Internet Pty Ltd 4755 1698 390 189 TATA Communications formerly 9829 1453 1158 43 BSNL National Internet Backbo 9583 1284 98 535 Sify Limited 7552 1161 1070 12 Vietel Corporation 4808 1117 2058 322 CNCGROUP IP network: China169 9498 1067 310 75 BHARTI Airtel Ltd. 24560 1058 385 161 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3049 3695 95 bellsouth.net, inc. 7029 2134 1266 215 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1987 2929 124 Cox Communications, Inc. 1785 1958 677 123 PaeTec Communications, Inc. 20115 1682 1612 621 Charter Communications 4323 1614 1140 402 Time Warner Telecom 30036 1345 292 686 Mediacom Communications Corp 7018 1307 10810 855 AT&T WorldNet Services 11492 1207 221 334 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1789 544 16 Corbina telecom 2118 1116 97 13 EUnet/RELCOM Autonomous Syste 34984 1082 232 205 BILISIM TELEKOM 13188 839 99 30 Educational Network 12479 836 784 69 Uni2 Autonomous System 20940 768 262 610 Akamai Technologies European 31148 767 40 18 FreeNet ISP 6830 714 2313 435 UPC Distribution Services 8551 708 370 43 Bezeq International 58113 632 70 377 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2345 403 227 TVCABLE BOGOTA 28573 2331 1332 85 NET Servicos de Comunicao S.A 7303 1681 1147 207 Telecom Argentina Stet-France 8151 1352 2727 399 UniNet S.A. de C.V. 6503 1261 435 68 AVANTEL, S.A. 14754 944 128 77 Telgua S. A. 18881 810 716 18 Global Village Telecom 27947 785 86 101 Telconet S.A 3816 688 306 85 Empresa Nacional de Telecomun 7738 650 1306 35 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 894 274 34 LINKdotNET AS number 6713 535 615 23 Itissalat Al-MAGHRIB 8452 516 958 13 TEDATA 24835 342 80 8 RAYA Telecom - Egypt 3741 262 906 220 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 187 696 90 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3049 3695 95 bellsouth.net, inc. 4766 2929 11558 922 Korea Telecom (KIX) 17974 2503 840 86 PT TELEKOMUNIKASI INDONESIA 10620 2345 403 227 TVCABLE BOGOTA 28573 2331 1332 85 NET Servicos de Comunicao S.A 7029 2134 1266 215 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1987 2929 124 Cox Communications, Inc. 1785 1958 677 123 PaeTec Communications, Inc. 7545 1829 301 89 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2503 2417 PT TELEKOMUNIKASI INDONESIA 28573 2331 2246 NET Servicos de Comunicao S.A 10620 2345 2118 TVCABLE BOGOTA 4766 2929 2007 Korea Telecom (KIX) 7029 2134 1919 Windstream Communications Inc 18566 2080 1895 Covad Communications 22773 1987 1863 Cox Communications, Inc. 1785 1958 1835 PaeTec Communications, Inc. 8402 1789 1773 Corbina telecom 7545 1829 1740 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65119 PRIVATE 8.36.67.0/24 6352 E*Trade Group 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.60.0/23 57417 INTERNET TASMANIA SRL 128.0.62.0/23 57417 INTERNET TASMANIA SRL 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:13 /10:29 /11:88 /12:248 /13:483 /14:867 /15:1563 /16:12653 /17:6626 /18:10922 /19:21724 /20:31433 /21:33532 /22:45943 /23:41406 /24:233050 /25:1367 /26:1770 /27:860 /28:180 /29:75 /30:17 /31:0 /32:20 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2030 2080 Covad Communications 6389 1751 3049 bellsouth.net, inc. 7029 1558 2134 Windstream Communications Inc 8402 1515 1789 Corbina telecom 22773 1302 1987 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1229 1345 Mediacom Communications Corp 11492 1169 1207 Cable One 1785 1038 1958 PaeTec Communications, Inc. 7011 952 1200 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:717 2:723 3:3 4:13 5:690 6:3 8:502 12:1927 13:3 14:750 15:11 16:3 17:8 20:24 23:245 24:1799 27:1464 31:1149 32:54 33:2 34:5 36:27 37:1332 38:859 39:2 40:159 41:2660 42:177 44:4 46:1763 47:1 49:609 50:664 52:12 54:28 55:11 57:28 58:1088 59:571 60:295 61:1353 62:1033 63:2042 64:4286 65:2178 66:4234 67:2055 68:1104 69:3262 70:862 71:523 72:1899 74:2551 75:407 76:287 77:1083 78:1030 79:567 80:1235 81:972 82:621 83:556 84:558 85:1162 86:474 87:946 88:375 89:1755 90:262 91:5431 92:604 93:1740 94:1871 95:1571 96:497 97:335 98:1037 99:40 100:29 101:300 103:2261 105:517 106:131 107:207 108:512 109:1802 110:854 111:1011 112:494 113:761 114:681 115:925 116:868 117:800 118:1003 119:1268 120:376 121:707 122:1735 123:1194 124:1319 125:1309 128:539 129:207 130:323 131:643 132:325 133:143 134:253 135:62 136:222 137:237 138:342 139:169 140:197 141:313 142:528 143:385 144:491 145:88 146:517 147:354 148:701 149:357 150:156 151:433 152:404 153:196 154:31 155:377 156:249 157:393 158:266 159:713 160:336 161:426 162:375 163:204 164:579 165:453 166:396 167:573 168:1007 169:131 170:1023 171:168 172:4 173:1588 174:582 175:424 176:1176 177:1739 178:1761 179:1 180:1377 181:267 182:1199 183:336 184:659 185:277 186:2330 187:1304 188:1933 189:1448 190:6610 192:6392 193:5666 194:4513 195:3485 196:1300 197:897 198:4199 199:5251 200:6037 201:2205 202:8904 203:8742 204:4488 205:2548 206:2777 207:2775 208:4066 209:3522 210:2903 211:1559 212:1999 213:1965 214:911 215:97 216:5192 217:1577 218:603 219:329 220:1263 221:546 222:316 223:476 End of report From Eric.Sabo at calu.edu Fri Mar 8 19:17:20 2013 From: Eric.Sabo at calu.edu (Sabo, Eric) Date: Fri, 8 Mar 2013 19:17:20 +0000 Subject: enterprise messaging gateway @ sprintpcs.com Message-ID: <66D9E8F23BC4F04699A6156D3C925568CC65C7@MLEXMBX2.CALU.LCL> I am trying to get our email server off their block list, I tried a couple phone number at this point and I haven't be able to locate anyone to help me for this domain. If anyone has any contact information on this domain, please share it. Probably by the time I get in contact our domain will be reset. Thanks in Advanced, Eric From source_route at yahoo.com Fri Mar 8 19:30:03 2013 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 8 Mar 2013 11:30:03 -0800 (PST) Subject: internet in the box Message-ID: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Has anybody set up a Cellular front end (LTE or 3G) access to the Internet and a WiFi backend supporting 150 devices. I need to provide temporary Internet access (7 days)?to a convention center room that is about 2000 square feet. Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. From lists at mtin.net Fri Mar 8 19:34:05 2013 From: lists at mtin.net (Justin Wilson) Date: Fri, 08 Mar 2013 14:34:05 -0500 Subject: internet in the box In-Reply-To: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: My advice have some limits or controls. Whether it be a box running QOS, hotspot, etc. You will have users on there running speed tests, trying to Skype, etc. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter http://www.thebrotherswisp.com ? The Brothers Wisp -----Original Message----- From: Philip Lavine Reply-To: Philip Lavine Date: Friday, March 8, 2013 2:30 PM To: NANOG list Subject: internet in the box >Has anybody set up a Cellular front end (LTE or 3G) access to the >Internet and a WiFi backend supporting 150 devices. >I need to provide temporary Internet access (7 days) to a convention >center room that is about 2000 square feet. >Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > From joelja at bogus.com Fri Mar 8 19:40:54 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 08 Mar 2013 11:40:54 -0800 Subject: internet in the box In-Reply-To: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: <513A3EC6.9050300@bogus.com> cradlepoint, verizon lte wireless usb dongle and a commercial plan with the appropiate bandwidth cap. I would then put a somewhat more powerful wireless-ap/router/nat-box behind it. I have stood up a datacenter behind such a thing while waiting for circuits to arrive. the cradlepoint can leverage more than one dongle if you have them. joel On 3/8/13 11:30 AM, Philip Lavine wrote: > Has anybody set up a Cellular front end (LTE or 3G) access to the Internet and a WiFi backend supporting 150 devices. > I need to provide temporary Internet access (7 days) to a convention center room that is about 2000 square feet. > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > From source_route at yahoo.com Fri Mar 8 20:19:47 2013 From: source_route at yahoo.com (Philip Lavine) Date: Fri, 8 Mar 2013 12:19:47 -0800 (PST) Subject: internet in the box In-Reply-To: <513A3EC6.9050300@bogus.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513A3EC6.9050300@bogus.com> Message-ID: <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> so : Cradlepoint with 3 x USB Modems -> Cisco2900 with integrated WLC and 6 AP's ________________________________ From: joel jaeggli To: Philip Lavine ; NANOG list Sent: Friday, March 8, 2013 11:40 AM Subject: Re: internet in the box cradlepoint, verizon lte wireless usb dongle and a commercial plan with the appropiate bandwidth cap. I would then put a? somewhat more powerful wireless-ap/router/nat-box behind it. I have stood up a datacenter behind such a thing while waiting for circuits to arrive. the cradlepoint can leverage more than one dongle if you have them. joel On 3/8/13 11:30 AM, Philip Lavine wrote: > Has anybody set up a Cellular front end (LTE or 3G) access to the Internet and a WiFi backend supporting 150 devices. > I need to provide temporary Internet access (7 days) to a convention center room that is about 2000 square feet. > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > From EWieling at nyigc.com Fri Mar 8 20:28:45 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 8 Mar 2013 15:28:45 -0500 Subject: internet in the box In-Reply-To: <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513A3EC6.9050300@bogus.com> <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: <616B4ECE1290D441AD56124FEBB03D08153E1F64CB@mailserver2007.nyigc.globe> plus overage fees 8-) -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Friday, March 08, 2013 3:20 PM To: joel jaeggli; NANOG list Subject: Re: internet in the box so : Cradlepoint with 3 x USB Modems -> Cisco2900 with integrated WLC and 6 AP's ________________________________ From: joel jaeggli To: Philip Lavine ; NANOG list Sent: Friday, March 8, 2013 11:40 AM Subject: Re: internet in the box cradlepoint, verizon lte wireless usb dongle and a commercial plan with the appropiate bandwidth cap. I would then put a? somewhat more powerful wireless-ap/router/nat-box behind it. I have stood up a datacenter behind such a thing while waiting for circuits to arrive. the cradlepoint can leverage more than one dongle if you have them. joel On 3/8/13 11:30 AM, Philip Lavine wrote: > Has anybody set up a Cellular front end (LTE or 3G) access to the Internet and a WiFi backend supporting 150 devices. > I need to provide temporary Internet access (7 days) to a convention center room that is about 2000 square feet. > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > From paul4004 at gmail.com Fri Mar 8 20:37:01 2013 From: paul4004 at gmail.com (PC) Date: Fri, 8 Mar 2013 13:37:01 -0700 Subject: internet in the box In-Reply-To: <616B4ECE1290D441AD56124FEBB03D08153E1F64CB@mailserver2007.nyigc.globe> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513A3EC6.9050300@bogus.com> <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> <616B4ECE1290D441AD56124FEBB03D08153E1F64CB@mailserver2007.nyigc.globe> Message-ID: If you have the luxury of running copper, you have some options. In my experience, its often difficult to do so without paying the house's labor at a convention center. This may necessitate a distributed solution with just several individual cradlepoint routers dropped throughout the coverage area wherever you find power. Otherwise, what you say above should work, as long as the required NAT implementation on the cradlepoint to do the 3x load balancing doesn't die under load. I've only tried up to about a bus-load of people on a single unit, which worked fine. (FYI -- with 1x modem per cradlepoint, they have a way to pass the public IP to the Cisco 2900 via DHCP pass-thru and not run NAT on the cradlepoint). Finally, Cisco also sells a 4g LTE expansion card. On Fri, Mar 8, 2013 at 1:28 PM, Eric Wieling wrote: > plus overage fees 8-) > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Friday, March 08, 2013 3:20 PM > To: joel jaeggli; NANOG list > Subject: Re: internet in the box > > so : Cradlepoint with 3 x USB Modems -> Cisco2900 with integrated WLC and > 6 AP's > > > ________________________________ > From: joel jaeggli > To: Philip Lavine ; NANOG list > Sent: Friday, March 8, 2013 11:40 AM > Subject: Re: internet in the box > > cradlepoint, verizon lte wireless usb dongle and a commercial plan with > the appropiate bandwidth cap. > > I would then put a somewhat more powerful wireless-ap/router/nat-box > behind it. > > I have stood up a datacenter behind such a thing while waiting for > circuits to arrive. > > the cradlepoint can leverage more than one dongle if you have them. > > joel > > On 3/8/13 11:30 AM, Philip Lavine wrote: > > Has anybody set up a Cellular front end (LTE or 3G) access to the > Internet and a WiFi backend supporting 150 devices. > > I need to provide temporary Internet access (7 days) to a convention > center room that is about 2000 square feet. > > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > > > > From joelja at bogus.com Fri Mar 8 20:38:01 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 08 Mar 2013 12:38:01 -0800 Subject: internet in the box In-Reply-To: <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513A3EC6.9050300@bogus.com> <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: <513A4C29.6080204@bogus.com> On 3/8/13 12:19 PM, Philip Lavine wrote: > so : Cradlepoint with 3 x USB Modems -> Cisco2900 with integrated WLC > and 6 AP's > sounds like something that I would do yes. would probably extend the modems with a usb cable and or have more than one provider on a different band plan so that the three cellular devices aren't right on top of each other > *From:* joel jaeggli > *To:* Philip Lavine ; NANOG list > > *Sent:* Friday, March 8, 2013 11:40 AM > *Subject:* Re: internet in the box > > cradlepoint, verizon lte wireless usb dongle and a commercial plan > with the appropiate bandwidth cap. > > I would then put a somewhat more powerful wireless-ap/router/nat-box > behind it. > > I have stood up a datacenter behind such a thing while waiting for > circuits to arrive. > > the cradlepoint can leverage more than one dongle if you have them. > > joel > > On 3/8/13 11:30 AM, Philip Lavine wrote: > > Has anybody set up a Cellular front end (LTE or 3G) access to the > Internet and a WiFi backend supporting 150 devices. > > I need to provide temporary Internet access (7 days) to a convention > center room that is about 2000 square feet. > > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > > > > > From joshbaird at gmail.com Fri Mar 8 20:57:41 2013 From: joshbaird at gmail.com (Josh Baird) Date: Fri, 8 Mar 2013 15:57:41 -0500 Subject: internet in the box In-Reply-To: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: Or find a wireless ISP in the area to backhaul you some bandwidth for a week. Then just get a box to do NAT, DHCP, etc. Josh On Fri, Mar 8, 2013 at 2:30 PM, Philip Lavine wrote: > Has anybody set up a Cellular front end (LTE or 3G) access to the Internet > and a WiFi backend supporting 150 devices. > I need to provide temporary Internet access (7 days) to a convention > center room that is about 2000 square feet. > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > From cidr-report at potaroo.net Fri Mar 8 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Mar 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201303082200.r28M00uW029683@wattle.apnic.net> This report has been generated at Tue Feb 19 16:13:14 2013 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 12-02-13 445341 254468 13-02-13 444932 254971 14-02-13 445625 254890 15-02-13 445440 255148 16-02-13 445491 255598 17-02-13 445709 255627 18-02-13 445529 256541 19-02-13 445862 256692 AS Summary 43455 Number of ASes in routing system 18036 Number of ASes announcing only one prefix 3063 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116912864 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'). --- 19Feb13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 445961 256729 189232 42.4% All ASes AS6389 3063 104 2959 96.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2387 88 2299 96.3% NET Servicos de Comunicao S.A. AS17974 2486 474 2012 80.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2938 942 1996 67.9% KIXS-AS-KR Korea Telecom AS18566 2080 427 1653 79.5% COVAD - Covad Communications Co. AS10620 2319 670 1649 71.1% Telmex Colombia S.A. AS7303 1681 408 1273 75.7% Telecom Argentina S.A. AS4323 1606 401 1205 75.0% TWTC - tw telecom holdings, inc. AS4755 1688 579 1109 65.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1115 83 1032 92.6% RELCOM-AS OOO "NPO Relcom" AS7552 1161 180 981 84.5% VIETEL-AS-AP Vietel Corporation AS7029 2166 1198 968 44.7% WINDSTREAM - Windstream Communications Inc AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1008 170 838 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS22773 1989 1162 827 41.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7545 1834 1019 815 44.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS1785 1959 1169 790 40.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1513 745 768 50.8% Uninet S.A. de C.V. AS4808 1114 355 759 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18881 773 26 747 96.6% Global Village Telecom AS14754 942 207 735 78.0% Telgua AS13977 838 123 715 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 737 51 686 93.1% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 715 50 665 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS24560 1045 416 629 60.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22561 1067 445 622 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 720 99 621 86.2% GIGAINFRA Softbank BB Corp. AS3356 1103 498 605 54.9% LEVEL3 Level 3 Communications AS3549 1046 444 602 57.6% GBLX Global Crossing Ltd. AS19262 998 404 594 59.5% VZGNI-TRANSIT - Verizon Online LLC Total 45377 13318 32059 70.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.5.152.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC. 103.11.148.0/24 AS58452 103.11.149.0/24 AS58452 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.19.20.0/22 AS42610 NCNET-AS National Cable Networks 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 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.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. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 8 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Mar 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201303082200.r28M02vk029717@wattle.apnic.net> BGP Update Report Interval: 11-Feb-13 -to- 18-Feb-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 111602 4.7% 107.9 -- BBIL-AP BHARTI Airtel Ltd. 2 - AS24560 91379 3.8% 88.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - AS8402 49667 2.1% 27.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS18207 45646 1.9% 131.9 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. 5 - AS3909 42966 1.8% 1227.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS7029 36157 1.5% 18.3 -- WINDSTREAM - Windstream Communications Inc 7 - AS8151 30815 1.3% 23.8 -- Uninet S.A. de C.V. 8 - AS9829 28968 1.2% 34.8 -- BSNL-NIB National Internet Backbone 9 - AS45609 27674 1.2% 105.6 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 10 - AS18002 24115 1.0% 114.8 -- WORLDPHONE-IN AS Number for Interdomain Routing 11 - AS32777 23335 1.0% 4667.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 12 - AS36998 21970 0.9% 18.1 -- SDN-MOBITEL 13 - AS2708 21659 0.9% 154.7 -- Universidad de Guanajuato 14 - AS45514 21014 0.9% 69.1 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 15 - AS4 19416 0.8% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 16 - AS45528 17023 0.7% 45.2 -- TDN Tikona Digital Networks Pvt Ltd. 17 - AS17974 16207 0.7% 7.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS31148 15822 0.7% 20.6 -- FREENET-AS Freenet Ltd. 19 - AS17488 14556 0.6% 45.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS57816 11755 0.5% 2938.8 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32777 23335 1.0% 4667.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 2 - AS19406 4126 0.2% 4126.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS40946 6077 0.2% 3038.5 -- PROCON - Sat Track 4 - AS6174 5879 0.2% 2939.5 -- SPRINTLINK8 - Sprint 5 - AS57816 11755 0.5% 2938.8 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 6 - AS14680 5943 0.2% 1981.0 -- REALE-6 - Auction.com 7 - AS36529 2746 0.1% 1373.0 -- AXXA-RACKCO - Rackco.com 8 - AS8657 1323 0.1% 1323.0 -- CPRM CPRM Autonomous System 9 - AS17293 3920 0.2% 1306.7 -- VTXC - VTX Communications 10 - AS3909 42966 1.8% 1227.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 11 - AS22140 5832 0.2% 972.0 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 12 - AS4 19416 0.8% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 13 - AS40931 1660 0.1% 830.0 -- MOBITV - MobiTV, Inc 14 - AS12397 807 0.0% 807.0 -- OPTOCOM Optocom Ltd 15 - AS9950 4666 0.2% 777.7 -- PUBNETPLUS2-AS-KR DACOM 16 - AS37367 709 0.0% 709.0 -- CALLKEY 17 - AS57201 696 0.0% 696.0 -- EDF-AS Estonian Defence Forces 18 - AS4663 2758 0.1% 689.5 -- ELIMNET-AS ELIMNET, INC 19 - AS12413 686 0.0% 686.0 -- HANSHAKE-AS Handshake e.V. 20 - AS6197 686 0.0% 686.0 -- BATI-ATL - BellSouth Network Solutions, Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.255.0/24 14290 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 14290 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 14259 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 37.9.248.0/21 11701 0.5% AS57816 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 5 - 202.41.70.0/24 9362 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 6 - 196.1.167.0/24 8133 0.3% AS11139 -- CWRIN CW BARBADOS 7 - 66.55.234.0/24 7838 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc 8 - 192.58.232.0/24 7645 0.3% AS6629 -- NOAA-AS - NOAA 9 - 208.92.131.0/24 6076 0.2% AS40946 -- PROCON - Sat Track 10 - 208.14.186.0/24 5803 0.2% AS22140 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 11 - 12.139.133.0/24 4793 0.2% AS14680 -- REALE-6 - Auction.com 12 - 194.63.9.0/24 4706 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 8.12.92.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 14 - 66.78.242.0/23 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 15 - 67.110.75.0/24 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 16 - 65.172.212.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 17 - 97.65.228.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 18 - 58.184.229.0/24 4652 0.2% AS9950 -- PUBNETPLUS2-AS-KR DACOM 19 - 69.38.178.0/24 4126 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 20 - 122.161.0.0/16 4028 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From saku at ytti.fi Fri Mar 8 22:55:32 2013 From: saku at ytti.fi (Saku Ytti) Date: Sat, 9 Mar 2013 00:55:32 +0200 Subject: internet routing table in a vrf In-Reply-To: <93717E08238F7B4392FAD1F82A87FBD3AD88FBA8@ORD1EXD04.RACKSPACE.CORP> References: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> <20130308172324.GA18010@pob.ytti.fi> <93717E08238F7B4392FAD1F82A87FBD3AD88FBA8@ORD1EXD04.RACKSPACE.CORP> Message-ID: <20130308225532.GA18175@pob.ytti.fi> On (2013-03-08 18:17 +0000), Matt Newsom wrote: > If you run PIC and hide the next hop information between a loopback which is what will happen in a vpn environment Typical SP network has next-hop-self in INET BGP, and does not carry edge-links in IGP. You don't want to have lot of prefixes in IGP. > If the remote PE has PIC running he can bounce that traffic back to his backup path via another PE. PIC merely makes sure that FIB is hierarchical and it guarantees all prefixes sharing next-hop converge at same time. Local-repair can be done with or without PIC, as it just means you have local information how to deliver frame to alternate destination without expectation of convergence. > There will be some percentage of your traffic that will then form a transient micro loop though because that remote PE will have his primary path through the failed link due to shortest as path length etc Only if egress PE does IP lookup, which is typically does not do (per-prefix or per-ce, default config in 7600, JunOS, IOS-XR) as egress PE label adjacency entry has egress rewrite information. The faulted edge PE can local-repair and get frame delivered without having to wait for BGP to converge for the customer. Transient loop can occur if both of the edges have faulted. -- ++ytti From bedard.phil at gmail.com Fri Mar 8 23:09:08 2013 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 8 Mar 2013 18:09:08 -0500 Subject: internet routing table in a vrf In-Reply-To: <20130308225532.GA18175@pob.ytti.fi> References: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> <20130308172324.GA18010@pob.ytti.fi> <93717E08238F7B4392FAD1F82A87FBD3AD88FBA8@ORD1EXD04.RACKSPACE.CORP> <20130308225532.GA18175@pob.ytti.fi> Message-ID: On Mar 8, 2013, at 5:55 PM, Saku Ytti wrote: > On (2013-03-08 18:17 +0000), Matt Newsom wrote: > >> If you run PIC and hide the next hop information between a loopback which is what will happen in a vpn environment > > Typical SP network has next-hop-self in INET BGP, and does not carry > edge-links in IGP. You don't want to have lot of prefixes in IGP. > >> If the remote PE has PIC running he can bounce that traffic back to his backup path via another PE. > > PIC merely makes sure that FIB is hierarchical and it guarantees all > prefixes sharing next-hop converge at same time. > Local-repair can be done with or without PIC, as it just means you have > local information how to deliver frame to alternate destination without > expectation of convergence. Unfortunately Cisco made things confusing by naming their "BGP FRR" feature "BGP PIC Edge." > >> There will be some percentage of your traffic that will then form a transient micro loop though because that remote PE will have his primary path through the failed link due to shortest as path length etc > > Only if egress PE does IP lookup, which is typically does not do > (per-prefix or per-ce, default config in 7600, JunOS, IOS-XR) as egress PE > label adjacency entry has egress rewrite information. > The faulted edge PE can local-repair and get frame delivered without having > to wait for BGP to converge for the customer. Transient loop can occur if > both of the edges have faulted. > > -- > ++ytti > From adam.vitkovsky at swan.sk Fri Mar 8 23:42:07 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Sat, 9 Mar 2013 00:42:07 +0100 Subject: internet routing table in a vrf In-Reply-To: <93717E08238F7B4392FAD1F82A87FBD3AD88FBA8@ORD1EXD04.RACKSPACE.CORP> References: <93717E08238F7B4392FAD1F82A87FBD3AD88F882@ORD1EXD04.RACKSPACE.CORP> <20130308172324.GA18010@pob.ytti.fi> <93717E08238F7B4392FAD1F82A87FBD3AD88FBA8@ORD1EXD04.RACKSPACE.CORP> Message-ID: <010701ce1c56$8b9fe480$a2dfad80$@swan.sk> There's some fundamental misunderstanding here. By default with vpnv4 and vpnv6 address-familie there's next hop self set by the PE. Local-Repair and label-retention was around many years before PIC came along. It worked nicely with eibgp multipath and allowed the primary PE to work around the failed PE-CE link and send traffic to alternate PE that advertised the same prefix. The added value with PIC is you don't have to have equal attributes in order to have an alternate path installed into FIB There are no micro-loops involved on an alternate PE. During normal operation packet incoming on Primary PE would be label-switched based on the per-prefix or per-ce label via PE-CE link as directed by the L2 overwrite in the FIB. In case of the local PE-CE link failure. PIC or Local-Repair will just label switch the incoming label with label advertised by the alternate PE. Once the alternate PE receives the labeled packet it will just label-switch it out the PE-CE link. During normal operation or during failure there is no recursive lookup done just label-switching. As Ytti pointed out already you don't want the PE-CE links to be carried by the IGP as you can fast reroute over their failure and perform a "local-repair" until the BGP converges and the ingress PE starts forwarding traffic to alternate PE/NH. The only case when you experience an excessive loss of connectivity is when the egress PE fails -in that case you need to really on the speed of IGP convergence to inform the ingress PE to switch to a preprogramed backup path/NH (PIC CORE). There are already some RFCs that propose P-core to fast reroute to alternate PE in case the primary PE fails - can't wait :). adam -----Original Message----- From: Matt Newsom [mailto:matt.newsom at RACKSPACE.COM] Sent: Friday, March 08, 2013 7:18 PM To: Saku Ytti; nanog at nanog.org Subject: RE: internet routing table in a vrf If you run PIC and hide the next hop information between a loopback which is what will happen in a vpn environment you will lose awareness of the failure of an edge link on a remote PE. The remote PE will continue to send traffic to the PE with the failed link until it has completely converged both at the control plane, and written to the FIB. If the remote PE has PIC running he can bounce that traffic back to his backup path via another PE. There will be some percentage of your traffic that will then form a transient micro loop though because that remote PE will have his primary path through the failed link due to shortest as path length etc, and he will not have converged yet around the failure on the remote PE and has no awareness of the failure. One possible solution to this is to guarantee that a PE will never use another PE for a primary transit route. This can be accomplished via metrics such as weight etc.. Again one of the downsides of this is you need to run VRF labels so that a local IP lookup can be done on the PE with the failed link and it can execute a local repair when it see's the link drop. -----Original Message----- From: Saku Ytti [mailto:saku at ytti.fi] Sent: Friday, March 08, 2013 11:23 AM To: nanog at nanog.org Subject: Re: internet routing table in a vrf On (2013-03-08 16:40 +0000), Matt Newsom wrote: > 2) forward plane (recursive lookup issues) > Most platforms program prefix's with associated labels slower so your base convergence will suffer. Do you have any reference you could share? What level of penalty per prefix have you observed in each platform tested? >In addition if you want to run PIC you will likely be left with a bit of custom engineering to make it work. VPN's hide the next hop behind the loopback of the PE so next hop failure awareness of an edge tie will be lost. If you can stomach the double lookup you can run per-vrf labels (per prefix isn't feasible on most platforms) and weight up your edge ties and force a bounce back to another PE, otherwise you will be stuck with bgp control plane based convergence with per-ce labels. PIC is about converging each prefix at the same time. It does not make statement where next_hop is pointing, is it loop0 (next-hop-self in INET) or is it edge CE. If your IGP carries all edge links, and you don't run next-hop-self, far end PE can converge faster in INET scenario. But current efforts are not to fix this, current efforts are to make the local PE do hitless repair when arriving frame is pointing to dead edge interface. It seems to be very rare to run INET in this way, majority don't carry edge links in IGP and do run next-hop-self. -- ++ytti From bross at pobox.com Sat Mar 9 00:30:09 2013 From: bross at pobox.com (Brandon Ross) Date: Fri, 8 Mar 2013 19:30:09 -0500 (EST) Subject: internet in the box In-Reply-To: References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: On Fri, 8 Mar 2013, Josh Baird wrote: > Or find a wireless ISP in the area to backhaul you some bandwidth for a > week. Do you think the convention center that wants $50/person/week will just give away the roof rights for free? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From seth.mos at dds.nl Sat Mar 9 09:11:15 2013 From: seth.mos at dds.nl (Seth Mos) Date: Sat, 9 Mar 2013 10:11:15 +0100 Subject: internet in the box In-Reply-To: <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513A3EC6.9050300@bogus.com> <1362773987.43021.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: Hi, > so : Cradlepoint with 3 x USB Modems -> Cisco2900 with integrated WLC and 6 AP's > Alternatively, but I am biased as a pfSense developer, you could setup pfSense with multiple usb 3G or 4G sticks. pfSense has firewalling, some QoS, a traffic shaper and limiters. And the firewall rules can give you granular control over which traffic goes where. The limiters are really useful in my opinion, we use it at work to prevent us from DoS ourselves. https is a bit of a issue since you need to direct that out 1 connection, most https sites seem to have issue with sessions moving across IPs. A local proxy server is often a good idea, or run it on the pfSense box itself if it is beefy enough in transparent mode, although that will complicate load balancing. If you also need IPv6 you need the 2.1 BETA, you can use NPtv6 to load balance traffic over multiple tunnelbroker tunnels (each bound to a 3G stick) using a single LAN prefix. Same as with the https example above, use the 1st real prefix on the LAN and NPTv6 load balanced connections going out the other. I'd say this costs a few hours to setup and test, no idea what your budget is. Your are probably going to spend quite a bit more time and money on getting good wireless coverage on both bands. 2.4Ghz is awful, 5Ghz works amazing for unobstructed view, or per room if you will. Best of luck, Seth Op 8 mrt 2013, om 21:19 heeft Philip Lavine het volgende geschreven: > > ________________________________ > From: joel jaeggli > To: Philip Lavine ; NANOG list > Sent: Friday, March 8, 2013 11:40 AM > Subject: Re: internet in the box > > cradlepoint, verizon lte wireless usb dongle and a commercial plan with the appropiate bandwidth cap. > > I would then put a somewhat more powerful wireless-ap/router/nat-box behind it. > > I have stood up a datacenter behind such a thing while waiting for circuits to arrive. > > the cradlepoint can leverage more than one dongle if you have them. > > joel > > On 3/8/13 11:30 AM, Philip Lavine wrote: >> Has anybody set up a Cellular front end (LTE or 3G) access to the Internet and a WiFi backend supporting 150 devices. >> I need to provide temporary Internet access (7 days) to a convention center room that is about 2000 square feet. >> Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. >> From dgdalton99 at yahoo.com Sat Mar 9 10:34:41 2013 From: dgdalton99 at yahoo.com (David Dalton) Date: Sat, 9 Mar 2013 02:34:41 -0800 (PST) Subject: Fw: message Message-ID: <1362825281.5404.YahooMailNeo@web122201.mail.ne1.yahoo.com> http://carroceriassantamaria.com/fod/vwb.ucghsjbbuiasl David Dalton From randy.robinson at lunarpages.com Sat Mar 9 00:54:20 2013 From: randy.robinson at lunarpages.com (Randy Robinson) Date: Sat, 9 Mar 2013 00:54:20 +0000 Subject: enterprise messaging gateway @ sprintpcs.com In-Reply-To: <66D9E8F23BC4F04699A6156D3C925568CC65C7@MLEXMBX2.CALU.LCL> References: <66D9E8F23BC4F04699A6156D3C925568CC65C7@MLEXMBX2.CALU.LCL> Message-ID: <7262D7E6C7687746A890C93BF3E3895A36E52553@ExMBX1201.lunarexchange.com> With no Sprint circuit ID or NUA you probably will not get very far. Try: 800.877.5045 option 2 (NOC) noc_support at sprint.net -----Original Message----- From: Sabo, Eric [mailto:Eric.Sabo at calu.edu] Sent: Friday, March 08, 2013 11:17 AM To: mailop at mailop.org; nanog at nanog.org Subject: enterprise messaging gateway @ sprintpcs.com I am trying to get our email server off their block list, I tried a couple phone number at this point and I haven't be able to locate anyone to help me for this domain. If anyone has any contact information on this domain, please share it. Probably by the time I get in contact our domain will be reset. Thanks in Advanced, Eric From scott at sberkman.net Sat Mar 9 21:59:07 2013 From: scott at sberkman.net (Scott Berkman) Date: Sat, 9 Mar 2013 16:59:07 -0500 Subject: Intermapper vs NetBrain vs some other for NMS In-Reply-To: References: Message-ID: <050c01ce1d11$5344a420$f9cdec60$@sberkman.net> I'm a big fan of Zenoss and have been using it in production for over 5 years in various environments and across different releases. Very mature open source project with commercial support options and plugins. People I know that came from OpenNMS prefer Zenoss once they get some time with it, and as opposed to Cacti which is strong at MRTG style graphing and has monitoring only as a plugin afterthought, Zenoss is built for both. http://www.zenoss.com/ Good luck, -Scott -----Original Message----- From: Ben Bartsch [mailto:uwcableguy at gmail.com] Sent: Friday, March 08, 2013 11:38 AM To: NANOG Subject: Intermapper vs NetBrain vs some other for NMS Hi all: I'm looking for information anyone might have comparing Intermapper to NetBrain for NMS. Stuff like devices up/down, interface utilization, building maps for documentation, etc. IMO, Intermapper works great, when it works. Tech support has been slow and often cannot fix the problems, not to mention they release updates about once every other week. Anyone familiar with any similar products? We are presently evaluating NetBrain and it seems really nice. We really like the Visio-like aspect of it. Thanks! -Ben From frnkblk at iname.com Sat Mar 9 23:35:30 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 9 Mar 2013 17:35:30 -0600 Subject: is yahoo in trouble? In-Reply-To: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> References: <1362761280.90370.YahooMailNeo@web121703.mail.ne1.yahoo.com> Message-ID: <000e01ce1d1e$c975d490$5c617db0$@iname.com> I had an unusually large number of page load timeouts against some of Yahoo's IPv6 test points between 10:34 am and 11:27 am (Central) on Friday. I suspect that our experiences were related. Frank -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Friday, March 08, 2013 10:48 AM To: NANOG list Subject: is yahoo in trouble? I am getting Connection refused on a lot of links From aaron.glenn at gmail.com Sun Mar 10 09:18:07 2013 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Sun, 10 Mar 2013 12:18:07 +0300 Subject: What do you have in your datacenters' toolbox? Message-ID: Greetings My Ten Thousand Closest Friends, I have a requirement to stock an actual, physical toolbox with power tools, drill bits, and other useful accoutrements one would use in a 'typical' datacenter. Can any one recommend brands/models of (preferably cordless) power tools they've used successfully? Reading Amazon reviews is killing my few brain cells that remain. Any "and you should think about stocking $X, $Y, and a couple of $Zs in your tool chest" you could impart on the list (besides the right kind of cage nuts and enough rj45 jacks)? I have that sinking suspicion my comprehensive list is not comprehensive enough. I get one true shot at this as the datacenter is very, very far from any 1st-world suppliers[1] Very grateful for any cluebats you are able to spare on this (marginally off) topic. Best, aaron.glenn [1] Hargeisa, Somaliland; if you must know. From michaeljwhite at gmail.com Sun Mar 10 10:06:55 2013 From: michaeljwhite at gmail.com (mike white) Date: Sun, 10 Mar 2013 03:06:55 -0700 (PDT) Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: <1362910013883.839898af@Nodemailer> Generically, pack for the worst case. Screw extractor bits are invaluable when you need them. Whatever drill you choose, either make sure you can charge it where you go or bring a transformer. Small screw drivers, kobalt 4" diagonal cutting pliers, and rubber mallets have gotten me out of trouble.? ? Sent from Mailbox for iPhone On Sun, Mar 10, 2013 at 5:19 AM, Aaron Glenn wrote: > Greetings My Ten Thousand Closest Friends, > I have a requirement to stock an actual, physical toolbox with power > tools, drill bits, and other useful accoutrements one would use in a > 'typical' datacenter. Can any one recommend brands/models of > (preferably cordless) power tools they've used successfully? Reading > Amazon reviews is killing my few brain cells that remain. Any "and you > should think about stocking $X, $Y, and a couple of $Zs in your tool > chest" you could impart on the list (besides the right kind of cage > nuts and enough rj45 jacks)? I have that sinking suspicion my > comprehensive list is not comprehensive enough. I get one true shot at > this as the datacenter is very, very far from any 1st-world > suppliers[1] > Very grateful for any cluebats you are able to spare on this > (marginally off) topic. > Best, > aaron.glenn > [1] Hargeisa, Somaliland; if you must know. From xxnog at ledeuns.net Sun Mar 10 10:13:59 2013 From: xxnog at ledeuns.net (Denis Fondras) Date: Sun, 10 Mar 2013 11:13:59 +0100 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <1362910013883.839898af@Nodemailer> References: <1362910013883.839898af@Nodemailer> Message-ID: <513C5CE7.9020006@ledeuns.net> Hello, Le 10/03/2013 11:06, mike white a ?crit : > Generically, pack for the worst case. Screw extractor bits are invaluable when you need them. Whatever drill you choose, either make sure you can charge it where you go or bring a transformer. Small screw drivers, kobalt 4" diagonal cutting pliers, and rubber mallets have gotten me out of trouble. The SysAdvent website had an article on this subject with many clever advices : http://sysadvent.blogspot.fr/2012/12/day-11-data-center-ops-tips.html Denis From rdobbins at arbor.net Sun Mar 10 12:09:03 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 10 Mar 2013 12:09:03 +0000 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: On Mar 10, 2013, at 4:18 PM, Aaron Glenn wrote: > Very grateful for any cluebats you are able to spare on this (marginally off) topic. Flashlights (regular, flexi-mount, & head-mounted). Batteries for flashlights. Small battery-powered dome-lights. Batteries for dome-lights. Floor-tile plunger. Lighted orange triangular cones to highlight removed floor-tiles. Articulated grabber. Both magnetic & non-magnetic manual screwdrivers (clearly marked). Electrical tape. Velcro. Power-strips. Long orange extension cords. Long (i.e., 100-foot/32m) MMF, SMF, Cat6 cables for emergency cross-rack patching. First-aid kit. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mohta at necom830.hpcl.titech.ac.jp Sun Mar 10 12:27:17 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Mar 2013 21:27:17 +0900 Subject: internet in the box In-Reply-To: References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: <513C7C25.109@necom830.hpcl.titech.ac.jp> Brandon Ross wrote: >> Or find a wireless ISP in the area to backhaul you some bandwidth for a >> week. > > Do you think the convention center that wants $50/person/week will just > give away the roof rights for free? There is a legal issue of who owns the right to control radio bandwidth usage in the convention center. For licensed bandwidth, it is obvious that licensees have the right. Though it is not so obvious for ISM bands, it should be reasonable to assume land owners have no right to prohibit visitors to transmit in ISM bands. For example, land owners should have no power to shut down PAN by ZigBee. At least, that is the formal understanding of regulators in Japan. Masataka Ohta From chindy at lwpca.net Sun Mar 10 13:48:38 2013 From: chindy at lwpca.net (Chris Hindy) Date: Sun, 10 Mar 2013 13:48:38 +0000 Subject: internet in the box In-Reply-To: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: Watch out for the terms in the contract. You might be obligated to use the conference facility's service as opposed to bringing your own. An alternative might be to check in with ShowNets (http://www.shownets.net/) who are very good at custom-sized solutions and are often at least tolerated by facility operators. -c On 08-03-2013 14:30 , "Philip Lavine" wrote: >Has anybody set up a Cellular front end (LTE or 3G) access to the >Internet and a WiFi backend supporting 150 devices. >I need to provide temporary Internet access (7 days) to a convention >center room that is about 2000 square feet. >Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. From jra at baylink.com Sun Mar 10 14:33:20 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Mar 2013 10:33:20 -0400 (EDT) Subject: What do you have in your datacenters' toolbox? In-Reply-To: Message-ID: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Aaron Glenn" > I have a requirement to stock an actual, physical toolbox with power > tools, drill bits, and other useful accoutrements one would use in a > 'typical' datacenter. If you look back about a year, Aaron, you'll find a thread I started about stocking a vending machine for a datacenter; you'll probably find everything in there that you need. But really: a power screwdriver, a bag of #2 bits, and a 12" extender are 85% of it. ;-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From lathama at gmail.com Sun Mar 10 17:23:32 2013 From: lathama at gmail.com (Andrew Latham) Date: Sun, 10 Mar 2013 13:23:32 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> Message-ID: > I have a requirement to stock an actual, physical toolbox with power > tools, drill bits, and other useful accoutrements one would use in a > 'typical' datacenter. Aaron I did some work from 2009 to 2012 in 3rd world datacenters and will note some highlights. - Easy to use power plug pinout testers for various outlets. - Lantronix Spider, serial adapters for console server to UPS/Switch/etc and a USB battery supply - Roll around tool chest (you would be surprised where they might keep the tools) hard to find in some places. - 3ft PDU to server power cables. - Detailed instructions in every language possible to not use the rack screws in the box. Or a thread gauge and instructions on its use. - Label maker.... - Step ladder - Extra humidity/temp sensors - Extra universal rack rails/shelf for legacy or new devices missing parts. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From sethm at rollernet.us Sun Mar 10 17:51:10 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 10 Mar 2013 10:51:10 -0700 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> Message-ID: <513CC80E.50607@rollernet.us> On 3/10/13 10:23 AM, Andrew Latham wrote: >> I have a requirement to stock an actual, physical toolbox with power >> tools, drill bits, and other useful accoutrements one would use in a >> 'typical' datacenter. > > Aaron > > I did some work from 2009 to 2012 in 3rd world datacenters and will > note some highlights. > > - Easy to use power plug pinout testers for various outlets. > - Lantronix Spider, serial adapters for console server to > UPS/Switch/etc and a USB battery supply I love my SpiderDuo's. No more KVM carts, ever. ~Seth From lathama at gmail.com Sun Mar 10 18:00:43 2013 From: lathama at gmail.com (Andrew Latham) Date: Sun, 10 Mar 2013 14:00:43 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <513CC80E.50607@rollernet.us> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <513CC80E.50607@rollernet.us> Message-ID: On Sun, Mar 10, 2013 at 1:51 PM, Seth Mattinen wrote: > On 3/10/13 10:23 AM, Andrew Latham wrote: >>> I have a requirement to stock an actual, physical toolbox with power >>> tools, drill bits, and other useful accoutrements one would use in a >>> 'typical' datacenter. >> >> Aaron >> >> I did some work from 2009 to 2012 in 3rd world datacenters and will >> note some highlights. >> >> - Easy to use power plug pinout testers for various outlets. >> - Lantronix Spider, serial adapters for console server to >> UPS/Switch/etc and a USB battery supply > > > I love my SpiderDuo's. No more KVM carts, ever. > > ~Seth Seth, I carry one with my laptop at all times. It also is a great way to get a USB CDROM/Floppy when needed. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From morrowc.lists at gmail.com Sun Mar 10 18:34:47 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 10 Mar 2013 14:34:47 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <513CC80E.50607@rollernet.us> Message-ID: should all of this end up on a wiki/etc perhaps? like cluepon or equivalent? it seems this question set comes up periodically and having a google-able/bing-able/webcrawler-able reference available would be helpful to everyone. On Sun, Mar 10, 2013 at 2:00 PM, Andrew Latham wrote: > On Sun, Mar 10, 2013 at 1:51 PM, Seth Mattinen wrote: >> On 3/10/13 10:23 AM, Andrew Latham wrote: >>>> I have a requirement to stock an actual, physical toolbox with power >>>> tools, drill bits, and other useful accoutrements one would use in a >>>> 'typical' datacenter. >>> >>> Aaron >>> >>> I did some work from 2009 to 2012 in 3rd world datacenters and will >>> note some highlights. >>> >>> - Easy to use power plug pinout testers for various outlets. >>> - Lantronix Spider, serial adapters for console server to >>> UPS/Switch/etc and a USB battery supply >> >> >> I love my SpiderDuo's. No more KVM carts, ever. >> >> ~Seth > > Seth, I carry one with my laptop at all times. It also is a great way > to get a USB CDROM/Floppy when needed. > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > From bross at pobox.com Sun Mar 10 18:35:00 2013 From: bross at pobox.com (bross at pobox.com) Date: Sun, 10 Mar 2013 14:35:00 -0400 (EDT) Subject: internet in the box In-Reply-To: <513C7C25.109@necom830.hpcl.titech.ac.jp> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513C7C25.109@necom830.hpcl.titech.ac.jp> Message-ID: On Sun, 10 Mar 2013, Masataka Ohta wrote: > Brandon Ross wrote: > >>> Or find a wireless ISP in the area to backhaul you some bandwidth for a >>> week. >> >> Do you think the convention center that wants $50/person/week will just >> give away the roof rights for free? > > There is a legal issue of who owns the right to control radio > bandwidth usage in the convention center. I know nothing of the legalities outside of the US, however I never said anything about the convention center restricting irghts to use RF, I said they won't let you on the roof without paying a lot of money. I strongly suspect that is true of all convention centers everywhere. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From jabley at hopcount.ca Sun Mar 10 18:39:18 2013 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 10 Mar 2013 14:39:18 -0400 Subject: internet in the box In-Reply-To: References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513C7C25.109@necom830.hpcl.titech.ac.jp> Message-ID: <80F9C281-6102-4C22-AE43-B7DBD01A92A4@hopcount.ca> On 2013-03-10, at 14:35, bross at pobox.com wrote: > I know nothing of the legalities outside of the US, however I never said anything about the convention center restricting irghts to use RF, I said they won't let you on the roof without paying a lot of money. I strongly suspect that is true of all convention centers everywhere. It's not uncommon for people to circumvent these problems by pointing antennas at windows from the inside. Can require some strategic room booking to get the right line of sight. Joe From wbailey at satelliteintelligencegroup.com Sun Mar 10 19:02:05 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 10 Mar 2013 19:02:05 +0000 Subject: internet in the box In-Reply-To: <80F9C281-6102-4C22-AE43-B7DBD01A92A4@hopcount.ca> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513C7C25.109@necom830.hpcl.titech.ac.jp> , <80F9C281-6102-4C22-AE43-B7DBD01A92A4@hopcount.ca> Message-ID: I suspect the amount of fade glass will provide would make this a last resort solution. Unless you did a 900mhz point to point with some yagis. I can't think of a reason you would have to provide data, most people have 3/4g to begin with. If it's for booth ops, I would think that cellular router would be the best choice. Most of the times our booth rides our private satellite network, so we just deal with the latency. If you could live with 800ms rtt, get a vsat.. :) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Joe Abley Date: 03/10/2013 11:43 AM (GMT-08:00) To: bross at pobox.com Cc: nanog at nanog.org Subject: Re: internet in the box On 2013-03-10, at 14:35, bross at pobox.com wrote: > I know nothing of the legalities outside of the US, however I never said anything about the convention center restricting irghts to use RF, I said they won't let you on the roof without paying a lot of money. I strongly suspect that is true of all convention centers everywhere. It's not uncommon for people to circumvent these problems by pointing antennas at windows from the inside. Can require some strategic room booking to get the right line of sight. Joe From jabley at hopcount.ca Sun Mar 10 19:11:14 2013 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 10 Mar 2013 15:11:14 -0400 Subject: internet in the box In-Reply-To: References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513C7C25.109@necom830.hpcl.titech.ac.jp> , <80F9C281-6102-4C22-AE43-B7DBD01A92A4@hopcount.ca> Message-ID: <4D54FCD2-0760-45BA-B021-EDC040450D15@hopcount.ca> On 2013-03-10, at 15:02, Warren Bailey wrote: > I suspect the amount of fade glass will provide would make this a last resort solution. Unless you did a 900mhz point to point with some yagis. I suspect the general answer is you do whatever you can to make things work. > I can't think of a reason you would have to provide data, most people have 3/4g to begin with. If it's for booth ops, I would think that cellular router would be the best choice. Most of the times our booth rides our private satellite network, so we just deal with the latency. If you could live with 800ms rtt, get a vsat.. :) The original question (IIRC) was how to provide conference-style wifi with no wired back-haul, so given that I presume that the option "don't provide conference-style wifi at all" does not meet the requirements :-) Joe From houdini+nanog at clanspum.net Mon Mar 11 01:06:59 2013 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Sun, 10 Mar 2013 20:06:59 -0500 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: <20130311010659.GY18751@clanspum.net> Aaron Glenn(aaron.glenn at gmail.com)@Sun, Mar 10, 2013 at 12:18:07PM +0300: > Greetings My Ten Thousand Closest Friends, > > I have a requirement to stock an actual, physical toolbox with power > tools, drill bits, and other useful accoutrements one would use in a > 'typical' datacenter. Can any one recommend brands/models of > (preferably cordless) power tools they've used successfully? Reading > Amazon reviews is killing my few brain cells that remain. Any "and you > should think about stocking $X, $Y, and a couple of $Zs in your tool > chest" you could impart on the list (besides the right kind of cage > nuts and enough rj45 jacks)? I have that sinking suspicion my > comprehensive list is not comprehensive enough. I get one true shot at > this as the datacenter is very, very far from any 1st-world > suppliers[1] Some (possibly) interesting answers: http://serverfault.com/questions/2382/server-room-survival-kit/ and http://serverfault.com/questions/202680/what-tools-parts-accessories-do-you-keep-in-your-colo -- Bill Weiss There is hopeful symbolism in the fact that flags do not wave in a vacuum. -- Arthur C. Clarke From Valdis.Kletnieks at vt.edu Mon Mar 11 06:32:50 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 11 Mar 2013 02:32:50 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: Your message of "Sun, 10 Mar 2013 12:18:07 +0300." References: Message-ID: <109928.1362983570@turing-police.cc.vt.edu> On Sun, 10 Mar 2013 12:18:07 +0300, Aaron Glenn said: > Very grateful for any cluebats you are able to spare on this > (marginally off) topic. Haven't seen it mentioned yet, so.... I have found that at my age, if you're trying to read the tiny print on a circuit label on Cat5 in the back of a server rack, a lighted magnifying glass is worth its weight in gold. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From josmon at rigozsaurus.com Mon Mar 11 06:42:56 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 11 Mar 2013 00:42:56 -0600 Subject: internet in the box In-Reply-To: References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> <513C7C25.109@necom830.hpcl.titech.ac.jp> Message-ID: <20130311064256.GA19183@jeeves.rigozsaurus.com> On Sun, Mar 10, 2013 at 02:35:00PM -0400, bross at pobox.com wrote: [...] > I know nothing of the legalities outside of the US, however I never > said anything about the convention center restricting irghts to use > RF, I said they won't let you on the roof without paying a lot of > money. I strongly suspect that is true of all convention centers > everywhere. I managed to get a rooftop link in for free at a convention center when other methods were failing. I was impressed, but I'm sure it'll never happen again. :-) From rsk at gsp.org Mon Mar 11 10:21:56 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 11 Mar 2013 06:21:56 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: <20130311102156.GA25964@gsp.org> On Sun, Mar 10, 2013 at 12:09:03PM +0000, Dobbins, Roland wrote: > First-aid kit. Definitely yes. And let me suggest that while buying an off-the-shelf kit will probably suffice for most uses, there is one a la carte addition that I strongly recommend: Quikclot. It's (relatively) expensive. It's worth every penny and ten times more the first time you need to use it. There are people walking around today alive because Pima County Sherriff's Deputies ALL had it in their first aid kits when they responded to the 2011 Tucson shootings. ---rsk From smb at cs.columbia.edu Mon Mar 11 11:54:54 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 11 Mar 2013 07:54:54 -0400 Subject: internet in the box In-Reply-To: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> References: <1362771003.81984.YahooMailNeo@web121704.mail.ne1.yahoo.com> Message-ID: On Mar 8, 2013, at 2:30 PM, Philip Lavine wrote: > Has anybody set up a Cellular front end (LTE or 3G) access to the Internet and a WiFi backend supporting 150 devices. > I need to provide temporary Internet access (7 days) to a convention center room that is about 2000 square feet. > Stooopid Aria wants to charge $50/user/wk and who knows what the BW is. > For how many people, doing what? I doubt very much that 3G will have close to the bandwidth you require, and I'm not at all sure about LTE. --Steve Bellovin, https://www.cs.columbia.edu/~smb From darkmoon at vt.edu Mon Mar 11 14:30:18 2013 From: darkmoon at vt.edu (Dave Martin) Date: Mon, 11 Mar 2013 10:30:18 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <109928.1362983570@turing-police.cc.vt.edu> References: <109928.1362983570@turing-police.cc.vt.edu> Message-ID: <20130311103018.513a1e78@dahak.cc.vt.edu> On Mon, 11 Mar 2013 02:32:50 -0400 Valdis.Kletnieks at vt.edu wrote: > On Sun, 10 Mar 2013 12:18:07 +0300, Aaron Glenn said: > > > Very grateful for any cluebats you are able to spare on this > > (marginally off) topic. > > Haven't seen it mentioned yet, so.... > > I have found that at my age, if you're trying to read the tiny print > on a circuit label on Cat5 in the back of a server rack, a lighted > magnifying glass is worth its weight in gold. :) > I have a multi-tip screwdriver with built-in light, that I find very useful. -- 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 dmburgess at linktechs.net Mon Mar 11 17:22:54 2013 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 11 Mar 2013 12:22:54 -0500 Subject: GEOip location issue Message-ID: <50710E9A7E64454C974049FC998EB6558F9170@03-exchange.lti.local> Got a new block from ARIN, no location found on it, so yahoo etc defaults to netherlands looks like. Anyone have the proper method to go about fixing things like this one? Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition " Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace From shtsuchi at cisco.com Mon Mar 11 17:35:10 2013 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Mon, 11 Mar 2013 13:35:10 -0400 Subject: GEOip location issue In-Reply-To: <50710E9A7E64454C974049FC998EB6558F9170@03-exchange.lti.local> References: <50710E9A7E64454C974049FC998EB6558F9170@03-exchange.lti.local> Message-ID: <513E15CE.8080806@cisco.com> Dennis How about check of each of GeoIP and request of correction to them? NANOG: http://nanog.cluepon.net/index.php/GeoIP JANOG: http://tools.bgp4.jp/index.php?GeoIP (Japanese but some information added) Regards, -Shishio (2013/03/11 13:22), Dennis Burgess wrote: > Got a new block from ARIN, no location found on it, so yahoo etc > defaults to netherlands looks like. Anyone have the proper method to go > about fixing things like this one? > > > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- > Second Edition " > > Link Technologies, Inc -- Mikrotik & WISP Support Services > > Office: 314-735-0270 Website: > http://www.linktechs.net - Skype: linktechs > > > -- Create Wireless Coverage's with www.towercoverage.com > - 900Mhz - LTE - 3G - 3.65 - TV > Whitespace > > > > From mksmith at mac.com Tue Mar 12 02:44:35 2013 From: mksmith at mac.com (Michael Smith) Date: Mon, 11 Mar 2013 19:44:35 -0700 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: <8BC56482-52CE-4971-A07E-9F6A3B77AB44@mac.com> Everyone else's comments plus, A phone with a camera. You can use it to "look" at singlemode fiber without damaging your eye to know if there is a laser coming your way. Mike On Mar 10, 2013, at 1:18 AM, Aaron Glenn wrote: > Greetings My Ten Thousand Closest Friends, > > I have a requirement to stock an actual, physical toolbox with power > tools, drill bits, and other useful accoutrements one would use in a > 'typical' datacenter. Can any one recommend brands/models of > (preferably cordless) power tools they've used successfully? Reading > Amazon reviews is killing my few brain cells that remain. Any "and you > should think about stocking $X, $Y, and a couple of $Zs in your tool > chest" you could impart on the list (besides the right kind of cage > nuts and enough rj45 jacks)? I have that sinking suspicion my > comprehensive list is not comprehensive enough. I get one true shot at > this as the datacenter is very, very far from any 1st-world > suppliers[1] > > Very grateful for any cluebats you are able to spare on this > (marginally off) topic. > > Best, > aaron.glenn > > [1] Hargeisa, Somaliland; if you must know. > From blakjak at blakjak.net Tue Mar 12 02:58:24 2013 From: blakjak at blakjak.net (Mark Foster) Date: Tue, 12 Mar 2013 15:58:24 +1300 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: <513E99D0.2040806@blakjak.net> I keep a couple of RJ45 line joiners, a short crossover cable (for dealing with older gear that doesn't auto-MDIX, can be extended with a longer eth cable and one of the line joiners) and when I was dealing with fibre a lot, appropriate line joiners for the interfaces I used (SC-SC, LC-LC, ST-ST) or short lengths of patch leads with appropriate adaptors. In an emergency I want to know that I have the ends I need and the length I need to get stuff connected, even if I have to schedule a routine change later on to swap in the 'right' type of cable. I also found that the Nortel gear I used to work with, had the right serial cable pinouts that I could use a pair of Cisco OEM console cables, joined with an RJ45 line joiner, as a serial console cable, so I always carried at least two of those. A Media Converter was also useful in my fibre days, in case I didn't have any spare SFP's or appropriate fibre modules. I also carried an IEC-to-conventional-mains ("3 pin" but it's country specific obviously) to allow me to run up said media converter when the only power outlets were of the IEC sort (where the power brick was inevitably one for 'conventional' mains outlets. I used to keep CDR's (where USB wasn't always permitted) with useful software, including packet capture software, tftp server software and some other basic apps, including plenty of Portable apps. OpenOffice Portable saved me in terms of an ability to get access to documentation (in .xls, typically) when working on the console of a server without Excel installed. But yeah plenty of good sources and I do feel this should indeed be wikified somewhere. I assume http://www.as30950.net/index.php/Main_Page is a useful location? (Just found it, no idea of it's pedigree etc.) Mark. On 10/03/13 22:18, Aaron Glenn wrote: > Greetings My Ten Thousand Closest Friends, > > I have a requirement to stock an actual, physical toolbox with power > tools, drill bits, and other useful accoutrements one would use in a > 'typical' datacenter. Can any one recommend brands/models of > (preferably cordless) power tools they've used successfully? Reading > Amazon reviews is killing my few brain cells that remain. Any "and you > should think about stocking $X, $Y, and a couple of $Zs in your tool > chest" you could impart on the list (besides the right kind of cage > nuts and enough rj45 jacks)? I have that sinking suspicion my > comprehensive list is not comprehensive enough. I get one true shot at > this as the datacenter is very, very far from any 1st-world > suppliers[1] > > Very grateful for any cluebats you are able to spare on this > (marginally off) topic. > > Best, > aaron.glenn > > [1] Hargeisa, Somaliland; if you must know. > From jfmezei_nanog at vaxination.ca Tue Mar 12 04:01:17 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 12 Mar 2013 00:01:17 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <8BC56482-52CE-4971-A07E-9F6A3B77AB44@mac.com> References: <8BC56482-52CE-4971-A07E-9F6A3B77AB44@mac.com> Message-ID: <513EA88D.8090504@vaxination.ca> You need to consider cases where there is an actual power failure. yeah, a real one with dark centre, UPS and mains down, room is silemt except for a few alarms here and there, and you are scrambling to find/fix problem. what will you need ? (obvious things like flashlights, multimetre, screwdrivers, pliers, wire cutters). I would also do a visual inventory of the hardware and all the screws you can find to ensure you have screwdrivers or allen keys for them, adjustable wrenches etc. You may also consider cases where the airconditioning unit is leaking water. Do you have some kit to wrap a leaking pipe to at least temporarily stop the leak ? So you have a shop vac to suck up water on floor or underfloor ? Often, maintenance manuals for equipment will have a list of tools needed. Then you need to consider emergency suplies. 10 gauge wiring to create a glorified extension cord to power some critical equipment. Obviouslty, as somone else mentioned spare ethernet cabling to also provide long patch cord to some switch that is still working. This also depends if this is a commercial data centre or a corporate one. In a corporate one, you need to identify your business critical equipment and run various failure scenarios to see what you need to keep the business critical systems up. While this goes beyond a set of tools, creating that list should implicitly also cause you to create a list of tools you would need in an emergency to get your business critical boxes back up. From mtaylor at mt.au.com Tue Mar 12 04:24:59 2013 From: mtaylor at mt.au.com (Matt Taylor) Date: Tue, 12 Mar 2013 15:24:59 +1100 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <513EA88D.8090504@vaxination.ca> References: <8BC56482-52CE-4971-A07E-9F6A3B77AB44@mac.com> <513EA88D.8090504@vaxination.ca> Message-ID: <513EAE1B.5040300@mt.au.com> There's one thing which no one has really mentioned, but it's "bitten" me a few times personally. * Torx screwdriver set. You'll never know when you run into an "aged" server which has scsi disk's and it requires a torx screwdriver to take out the screws without threading it. Also, a similar thread had come up recently on AusNOG which may help someone: http://lists.ausnog.net/pipermail/ausnog/2011-November/011619.html Also, last year on NANOG - similar (huge) thread: http://mailman.nanog.org/pipermail/nanog/2012-February/046106.html Regards, Matthew Taylor. On 12/03/13 3:01 PM, Jean-Francois Mezei wrote: > You need to consider cases where there is an actual power failure. yeah, > a real one with dark centre, UPS and mains down, room is silemt except > for a few alarms here and there, and you are scrambling to find/fix problem. > > what will you need ? > (obvious things like flashlights, multimetre, screwdrivers, pliers, wire > cutters). > > I would also do a visual inventory of the hardware and all the screws > you can find to ensure you have screwdrivers or allen keys for them, > adjustable wrenches etc. > > You may also consider cases where the airconditioning unit is leaking > water. Do you have some kit to wrap a leaking pipe to at least > temporarily stop the leak ? > > So you have a shop vac to suck up water on floor or underfloor ? > > Often, maintenance manuals for equipment will have a list of tools needed. > > Then you need to consider emergency suplies. 10 gauge wiring to create a > glorified extension cord to power some critical equipment. Obviouslty, > as somone else mentioned spare ethernet cabling to also provide long > patch cord to some switch that is still working. > > This also depends if this is a commercial data centre or a corporate > one. In a corporate one, you need to identify your business critical > equipment and run various failure scenarios to see what you need to keep > the business critical systems up. While this goes beyond a set of tools, > creating that list should implicitly also cause you to create a list of > tools you would need in an emergency to get your business critical boxes > back up. > > > From jra at baylink.com Tue Mar 12 04:30:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 12 Mar 2013 00:30:58 -0400 (EDT) Subject: What do you have in your datacenters' toolbox? In-Reply-To: <513EAE1B.5040300@mt.au.com> Message-ID: <22746350.9422.1363062658376.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matt Taylor" > Also, last year on NANOG - similar (huge) thread: > > http://mailman.nanog.org/pipermail/nanog/2012-February/046106.html Ah, *there's* my thread. The head is here: http://mailman.nanog.org/pipermail/nanog/2012-February/045491.html Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jabley at hopcount.ca Tue Mar 12 13:25:29 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 12 Mar 2013 09:25:29 -0400 Subject: traffic accounting Message-ID: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> Hi all, Imagine you have a number of GE and 10GE interfaces spread across multiple MX-class Juniper routers, and for each interface you want to maintain an accurate count of bytes sent, categorised by destination address. There is no layer-2 aggregation going on beyond the router, so no opportunity to create span ports on which to measure over on the side. Using optical splitters on each and every router interface and listening on the side using dedicated sniffers is an option, although it means tangles of fibre and potentially lots of sniffer boxes with lots of interfaces. I don't necessarily need a free or tremendously cheap solution, although it's always nice not to have to spend money. What are better approaches? Off-list would be fine if people have experience of this kind of thing; I can summarise if there is interest. Joe From rdobbins at arbor.net Tue Mar 12 13:30:03 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 12 Mar 2013 13:30:03 +0000 Subject: traffic accounting In-Reply-To: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> Message-ID: <434F2251-337A-4146-A565-B417602394A6@arbor.net> On Mar 12, 2013, at 8:25 PM, Joe Abley wrote: > What are better approaches? Flow telemetry. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jabley at hopcount.ca Tue Mar 12 13:53:56 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 12 Mar 2013 09:53:56 -0400 Subject: traffic accounting In-Reply-To: <434F2251-337A-4146-A565-B417602394A6@arbor.net> References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <434F2251-337A-4146-A565-B417602394A6@arbor.net> Message-ID: On 2013-03-12, at 09:30, "Dobbins, Roland" wrote: > On Mar 12, 2013, at 8:25 PM, Joe Abley wrote: > >> What are better approaches? > > Flow telemetry. Can you use cflow/jflow/ipfix exports with 1:1 sampling on an MX480 without an MS-DPC? Joe From ahebert at pubnix.net Tue Mar 12 13:55:20 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 12 Mar 2013 09:55:20 -0400 Subject: Odd announcement from AS27048 Message-ID: <513F33C8.3060900@pubnix.net> Hi, On the 5th we notice that 27048 was announcing 2 of ours /24 812 3549 209 721 27064 27047 27047 27047 27048 It lasted about 9h but didn't impact anything due to its prepend and such... My inquiry is: . False positive? . Broken 16b <=> 32b ASN's? . Human Error? . I should remove my Echelon triggering keywords from my personal .sig? ( 27048 is part of a US DoD ASN range =D ). I check around and it happened a few times in the past. ( I saw a CIDR report in 2008 where 27048 was announcing 8m+ IP's ) Let me know. -- ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From kpospisek at bigpond.com Tue Mar 12 09:45:10 2013 From: kpospisek at bigpond.com (kpospisek at bigpond.com) Date: Tue, 12 Mar 2013 20:45:10 +1100 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: I would be concerned in strongly spruiking advantages of IPv6 to executives if an IPv6 dual stack solution is actually being deployed. (ie. some given IPv6 SS advantages below do not apply to IPv6 DS) > 1. Decreased application complexity: > Because we will be able to get rid of all that NAT traversal code, > we get the following benefits: > > I. Improved security > A. Fewer code paths to test > B. Lower complexity = less opportunity to introduce flaws > II. Lower cost > A. Less developer man hours maintaining (or developing) NAT > traversal code > B. Less QA time spent testing NAT traversal code > C. No longer need to keep the lab stocked with every NAT > implementation ever invented > D. Fewer calls to support for failures in product's NAT traversal > code > 2. Increased transparency: > Because addressing is now end-to-end transparent, we gain a > number of benefits: > > I. Improved Security > A. Harder for attackers to hide in anonymous address space. > B. Easier to track down spoofing > C. Simplified log correlation > D. Easier to identify source/target of attacks > II. Simplified troubleshooting > A. No more need to include state table dumps in troubleshooting > B. tcpdump inside and tcpdump outside contain the same packets. > There are two well documented advantages to IPv6 dual stack: - responding to customers requesting IPv6 dual stack connectivity - excellent access to the IPv4 network IPv6 is a *different* network to IPv4 even if both networks happen to be carried on the same platforms (thank you Cisco, F5, Juniper etc - without this, our execs would be seriously baulking at having to replace fairly modern hardware). I have also noticed examples given of historic protocol changes. Not all of these are relevant as some of them only involved "middle" OSI layers, so do not apply very well to the IPv6->IPv6 transition. Greets Engineer Karl Pospisek (alias kpospisek at telstra.com) From morrowc.lists at gmail.com Tue Mar 12 14:18:39 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 12 Mar 2013 10:18:39 -0400 Subject: traffic accounting In-Reply-To: References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <434F2251-337A-4146-A565-B417602394A6@arbor.net> Message-ID: On Tue, Mar 12, 2013 at 9:53 AM, Joe Abley wrote: > > On 2013-03-12, at 09:30, "Dobbins, Roland" wrote: > >> On Mar 12, 2013, at 8:25 PM, Joe Abley wrote: >> >>> What are better approaches? >> >> Flow telemetry. > > Can you use cflow/jflow/ipfix exports with 1:1 sampling on an MX480 without an MS-DPC? probably.. depending on how much traffic you actually get the DPC/FPC -> RE path is limited. From morrowc.lists at gmail.com Tue Mar 12 14:23:24 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 12 Mar 2013 10:23:24 -0400 Subject: Odd announcement from AS27048 In-Reply-To: <513F33C8.3060900@pubnix.net> References: <513F33C8.3060900@pubnix.net> Message-ID: On Tue, Mar 12, 2013 at 9:55 AM, Alain Hebert wrote: > Hi, > > On the 5th we notice that 27048 was announcing 2 of ours /24 > > 812 3549 209 721 27064 27047 27047 27047 27048 > maybe 721 doesn't have prefix AND as-path filters? (or 209 maybe?) or intentional filtering gone wrong :( > It lasted about 9h but didn't impact anything due to its prepend and > such... > > My inquiry is: > > . False positive? > . Broken 16b <=> 32b ASN's? > . Human Error? > . I should remove my Echelon triggering keywords from my > personal .sig? > ( 27048 is part of a US DoD ASN range =D ). > > I check around and it happened a few times in the past. > ( I saw a CIDR report in 2008 where 27048 was announcing 8m+ IP's ) > > Let me know. > > -- > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > From Valdis.Kletnieks at vt.edu Tue Mar 12 14:32:22 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Mar 2013 10:32:22 -0400 Subject: traffic accounting In-Reply-To: Your message of "Tue, 12 Mar 2013 09:25:29 -0400." <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> Message-ID: <43100.1363098742@turing-police.cc.vt.edu> On Tue, 12 Mar 2013 09:25:29 -0400, Joe Abley said: > Imagine you have a number of GE and 10GE interfaces spread across multiple > MX-class Juniper routers, and for each interface you want to maintain an > accurate count of bytes sent, categorised by destination address. An important question that may impact possible solutions - exactly how accurate does it have to be? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jabley at hopcount.ca Tue Mar 12 14:38:31 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 12 Mar 2013 10:38:31 -0400 Subject: traffic accounting In-Reply-To: <43100.1363098742@turing-police.cc.vt.edu> References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <43100.1363098742@turing-police.cc.vt.edu> Message-ID: <87D06CC7-5B7C-4394-A8C8-1CC30C5E7610@hopcount.ca> On 2013-03-12, at 10:32, Valdis.Kletnieks at vt.edu wrote: > On Tue, 12 Mar 2013 09:25:29 -0400, Joe Abley said: > >> Imagine you have a number of GE and 10GE interfaces spread across multiple >> MX-class Juniper routers, and for each interface you want to maintain an >> accurate count of bytes sent, categorised by destination address. > > An important question that may impact possible solutions - exactly how > accurate does it have to be? Ideally I'd count every byte, and any deficiencies in the data would be due to unplanned outage rather than systematic short-cutting. Sampling 1 in 10 packets and multiplying the observed byte count by 10 might be better than nothing, though. Off-list, someone suggested DCU ("destination class accounting"), but that's limited to 126 classes of counters; another parameter I forgot to mention at the beginning is that there are thousands of destination addresses reached through each of these interfaces, and I'm looking for accounting by destination address, so 126 isn't going to cut it. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joelja at bogus.com Tue Mar 12 15:10:45 2013 From: joelja at bogus.com (joel jaeggli) Date: Tue, 12 Mar 2013 11:10:45 -0400 Subject: traffic accounting In-Reply-To: References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <434F2251-337A-4146-A565-B417602394A6@arbor.net> Message-ID: <513F4575.4030906@bogus.com> On 3/12/13 10:18 AM, Christopher Morrow wrote: > On Tue, Mar 12, 2013 at 9:53 AM, Joe Abley wrote: >> On 2013-03-12, at 09:30, "Dobbins, Roland" wrote: >> >>> On Mar 12, 2013, at 8:25 PM, Joe Abley wrote: >>> >>>> What are better approaches? >>> Flow telemetry. >> Can you use cflow/jflow/ipfix exports with 1:1 sampling on an MX480 without an MS-DPC? > probably.. depending on how much traffic you actually get the DPC/FPC > -> RE path is limited. > "Specify the threshold traffic value by using themax-packets-per-secondstatement. The value is the maximum number of packets to be sampled, beyond which the sampling mechanism begins dropping packets. The range is 0 through 65,535. A value of 0 instructs the Packet Forwarding Engine not to sample any packets. The default value is 1000." From jbates at brightok.net Tue Mar 12 15:13:23 2013 From: jbates at brightok.net (Jack Bates) Date: Tue, 12 Mar 2013 10:13:23 -0500 Subject: traffic accounting In-Reply-To: References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <434F2251-337A-4146-A565-B417602394A6@arbor.net> Message-ID: <513F4613.5090503@brightok.net> On 3/12/2013 8:53 AM, Joe Abley wrote: > Can you use cflow/jflow/ipfix exports with 1:1 sampling on an MX480 > without an MS-DPC? Joe If you use MPC/trio with appropriate licensing, you might be able to hit 1:1 with ipfix. They were still working on IPv6 and other features when I looked a year ago, but the trio ipfix maximums outclassed the MS-DPC by a lot. Jack From rdobbins at arbor.net Tue Mar 12 15:18:48 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 12 Mar 2013 15:18:48 +0000 Subject: traffic accounting In-Reply-To: References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <434F2251-337A-4146-A565-B417602394A6@arbor.net> Message-ID: <85238DCF-A0EB-45BF-B7C0-3E93E85729D2@arbor.net> On Mar 12, 2013, at 8:53 PM, Joe Abley wrote: > Can you use cflow/jflow/ipfix exports with 1:1 sampling on an MX480 without an MS-DPC? I'm not a Juniper person, so I'm not sure; note however that a) MS-DPC is necessary for NetFlow v9 (which is required for IPv6, for example), and b) sampled NetFlow (i.e., not 1:1, but higher ratios) is widely used and accepted in the industry. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From blair.trosper at gmail.com Tue Mar 12 15:57:58 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 12 Mar 2013 10:57:58 -0500 Subject: Bing/MSN/Microsoft contact Message-ID: If possible, I need someone from Microsoft/Bing (a la the MSN and Bing crawler bots) to contact me off list. Several IPs going back to AS8075 (with the user agent MSN and "bingbot") are basically attacking several IPs on my network with hundreds of requests per second. Thanks, Blair From jared at puck.nether.net Tue Mar 12 16:10:18 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 12 Mar 2013 12:10:18 -0400 Subject: Odd announcement from AS27048 In-Reply-To: References: <513F33C8.3060900@pubnix.net> Message-ID: On Mar 12, 2013, at 10:23 AM, Christopher Morrow wrote: > On Tue, Mar 12, 2013 at 9:55 AM, Alain Hebert wrote: >> Hi, >> >> On the 5th we notice that 27048 was announcing 2 of ours /24 >> >> 812 3549 209 721 27064 27047 27047 27047 27048 >> > > maybe 721 doesn't have prefix AND as-path filters? (or 209 maybe?) > or intentional filtering gone wrong :( http://puck.nether.net/bgp/leakinfo.cgi?search=do&search_prefix=&search_aspath=&search_asn=&recent=1000&source=nanog20130312 I know I see lots of these cases of intentional filtering gone wrong. eg: XO(2828) routes being leaked via a customer to Cogent(174) I didn't see anything related to 27048 in the past few years history at all, but there is bad filtering all over the place. Please combine as-path filtering with your traditional prefix-list filtering as well to block these as-paths. - Jared From aaron.glenn at gmail.com Tue Mar 12 16:23:54 2013 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Tue, 12 Mar 2013 20:23:54 +0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <22746350.9422.1363062658376.JavaMail.root@benjamin.baylink.com> References: <513EAE1B.5040300@mt.au.com> <22746350.9422.1363062658376.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 12, 2013 at 8:30 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Matt Taylor" > >> Also, last year on NANOG - similar (huge) thread: >> >> http://mailman.nanog.org/pipermail/nanog/2012-February/046106.html > > Ah, *there's* my thread. > > The head is here: > > http://mailman.nanog.org/pipermail/nanog/2012-February/045491.html d'oh. I tried to find relevant previous threads. I really did. Obviously not hard enough. Thanks! From owen at delong.com Tue Mar 12 17:05:34 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Mar 2013 10:05:34 -0700 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: Dual stack is a (very) temporary solution while waiting for some others to catch up and deploy IPv6. Contemplating dual-stack as a permanent or long-term solution ignores the extent to which IPv4 is utterly unsustainable at this point. Owen On Mar 12, 2013, at 02:45 , kpospisek at bigpond.com wrote: > > I would be concerned in strongly spruiking advantages of IPv6 to > executives if an IPv6 dual stack solution is actually being deployed. > (ie. some given IPv6 SS advantages below do not apply to IPv6 DS) > >> 1. Decreased application complexity: >> Because we will be able to get rid of all that NAT traversal code, >> we get the following benefits: >> >> I. Improved security >> A. Fewer code paths to test >> B. Lower complexity = less opportunity to introduce flaws >> II. Lower cost >> A. Less developer man hours maintaining (or developing) NAT traversal code >> B. Less QA time spent testing NAT traversal code >> C. No longer need to keep the lab stocked with every NAT implementation ever invented >> D. Fewer calls to support for failures in product's NAT traversal code >> 2. Increased transparency: >> Because addressing is now end-to-end transparent, we gain a >> number of benefits: >> >> I. Improved Security >> A. Harder for attackers to hide in anonymous address space. >> B. Easier to track down spoofing >> C. Simplified log correlation >> D. Easier to identify source/target of attacks >> II. Simplified troubleshooting >> A. No more need to include state table dumps in troubleshooting >> B. tcpdump inside and tcpdump outside contain the same packets. >> > > > There are two well documented advantages to IPv6 dual stack: > > - responding to customers requesting IPv6 dual stack connectivity > - excellent access to the IPv4 network > > IPv6 is a *different* network to IPv4 even if both networks happen to be > carried on the same platforms (thank you Cisco, F5, Juniper etc - > without this, our execs would be seriously baulking at having to replace fairly > modern hardware). > > I have also noticed examples given of historic protocol changes. Not all of > these are relevant as some of them only involved "middle" OSI layers, so > do not apply very well to the IPv6->IPv6 transition. > > > Greets > Engineer Karl Pospisek (alias kpospisek at telstra.com) From jayfar at jayfar.com Tue Mar 12 17:29:40 2013 From: jayfar at jayfar.com (Jay Farrell) Date: Tue, 12 Mar 2013 13:29:40 -0400 Subject: Bing/MSN/Microsoft contact In-Reply-To: References: Message-ID: This might help: http://www.bing.com/webmaster/help/how-to-report-an-issue-with-bingbot-25c19802 How do I Report an Issue With Bingbot? Bingbot is the name of the crawler used by Bing to crawl or ?spider? the web. It is Bingbot's job to find new and updated pages on websites across the Internet, so that they can be processed for indexation. When crawling a website, Bingbot looks at robots.txt for special instructions from the website owner. Bingbot honors robots.txt directives, including the * crawl-delay:* setting, and, in the absence of a crawl-delay, respects the input from Webmasters in the Crawl Control Feature. Generally, Bingbot does a good job at determining how frequent it should visit pages on your site, taking robots.txt and Crawl Control rules and hints into consideration. We call this ?Crawl Politeness?. However, there still may be cases were you feel Bingbot is not polite enough and is visiting your pages more than works for you (overcrawling). REPORTING OVERCRAWLING Here?s the steps you can follow if you think Bingbot is overcrawling your site or not observing robots.txt rules: 1. Verify that the bot traffic you are seeing is in fact from a valid Bingbot server. You can do this by not only looking at the User-Agent string (which can be easily spoofed by anyone) but also at the IP address and using the *Verify Bingbot tool * to get a verdict 2. Once you have verified that this involves genuine Bingbot traffic, you can reduce crawler traffic as follows (if you haven?t done so already): 3. Lower the speed of crawl during busy hours using the Crawl Control feature 4. If that?s not sufficient, add a crawl-delay: directive to your robots.txt: Bing supports whole number values ranging from 1 ? 30. Each number maps to the number of seconds we need to wait between requests, so 1 means a maximum of 1 request per 1 second ? which is slow, but still adequate for smaller sites. 30 is extremely slow and means we are allowed only 1 request per 30 seconds. 5. If you have followed step 1 and 2 and the issue is still present, you can contact *Bing Webmaster Support *. Fill out the required fields and in the ?*What type of problem do you have?? *dropdown, select ?*Under-Crawling or Over-Crawling inquiry*? and describe the problem you are seeing. You can expect a reply within 24-48 hours. When you report over-crawling issues, the support team will ask you to provide server log samples that show the Bingbot activity over a certain period of time in a next step, so make sure to have those ready. On Tue, Mar 12, 2013 at 11:57 AM, Blair Trosper wrote: > If possible, I need someone from Microsoft/Bing (a la the MSN and Bing > crawler bots) to contact me off list. > > Several IPs going back to AS8075 (with the user agent MSN and "bingbot") > are basically attacking several IPs on my network with hundreds of requests > per second. > > Thanks, > Blair > From thegameiam at yahoo.com Tue Mar 12 17:32:37 2013 From: thegameiam at yahoo.com (David Barak) Date: Tue, 12 Mar 2013 10:32:37 -0700 (PDT) Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: Message-ID: <1363109557.69828.YahooMailNeo@web31801.mail.mud.yahoo.com> From: Owen DeLong >Dual stack is a (very) temporary solution while waiting for some others to catch >up and deploy IPv6. Contemplating dual-stack as a permanent or long-term >solution ignores the extent to which IPv4 is utterly unsustainable at this point. >Owen ? Owen, when do you think IPv4 is going to go away to the point that it will no longer be necessary to carry it?? We may be using "long-term" to mean different things, so I'm curious to see what you mean by that. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ________________________________ From owen at delong.com Tue Mar 12 17:45:27 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Mar 2013 10:45:27 -0700 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <1363109557.69828.YahooMailNeo@web31801.mail.mud.yahoo.com> References: <1363109557.69828.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <88D17156-6750-4833-BFB3-86E88486A679@delong.com> Once IPv6 is sufficiently ubiquitous (rough estimate, but say 900+ of the Alexa 1000 sites have IPv6 and ~95% of eyeball networks), you'll see a rapidly declining desire to pay the increased cost of supporting IPv4. Combine that with the fact that as the internet continues to try and grow, the longer IPv4 remains relevant, the more cobbled, hacked, layered, NATted it will become. All of these additional heroic measures to keep IPv4 running will have a huge and multiplying cost. The network will be increasingly complex and harder to troubleshoot while also becoming increasingly fragile. The end user experience will be degraded by the additional layering while the service providers costs to provide that service are increasing because of the need to provide additional equipment and man-hours to manage the growing complexity. As the costs of supporting IPv4 go up, ISPs will have no choice but to pass that cost along to customers. Eventually, some IPv6 ready customers will not want to continue subsidizing the IPv4 costs and will insist that the cost increases related to IPv4 be billed to the IPv4 customers. Once IPv4 becomes a separate and increasing charge on people's internet bills, the economics will further drive the transition away from IPv4. Will we have isolated pockets of IPv4 within organizations for years to come? Sure. How long will IPv4 remain the lingua franca of the internet? I'm pretty sure that will be less than a decade and likely ~5 years at this point. Owen On Mar 12, 2013, at 10:32 , David Barak wrote: > > From: Owen DeLong > > >Dual stack is a (very) temporary solution while waiting for some others to catch > >up and deploy IPv6. Contemplating dual-stack as a permanent or long-term > >solution ignores the extent to which IPv4 is utterly unsustainable at this point. > >Owen > > Owen, when do you think IPv4 is going to go away to the point that it will no longer be necessary to carry it? We may be using "long-term" to mean different things, so I'm curious to see what you mean by that. > > David Barak > Need Geek Rock? Try The Franchise: > http://www.listentothefranchise.com > From chip at 2bithacker.net Tue Mar 12 17:58:14 2013 From: chip at 2bithacker.net (Chip Marshall) Date: Tue, 12 Mar 2013 13:58:14 -0400 Subject: Network Configuration Management Message-ID: <20130312175813.GA27817@2bithacker.net> Just curious what people are using for network configuration manangement systems. I'm guessing most places have something built in-house, but before starting down that road I figured it would be a good idea to see if people have any off-the-shelf systems they like. Some features I'd like to have: * Interface configs * Firewall filter configs * BGP session configs * User management * Support for multiple router and switch vendors (at least Juniper and Cisco) -- Chip Marshall http://2bithacker.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From chip.gwyn at gmail.com Tue Mar 12 18:07:11 2013 From: chip.gwyn at gmail.com (chip) Date: Tue, 12 Mar 2013 14:07:11 -0400 Subject: Network Configuration Management In-Reply-To: <20130312175813.GA27817@2bithacker.net> References: <20130312175813.GA27817@2bithacker.net> Message-ID: I've never found anything that hits all of my needs. The closest off the shelf thing I've ever found is the Network Control System from Tail-F ( http://www.tail-f.com/network-control-system/). We're using a custom built app that's been refined over the last decade and does a really nice job. It uses a very similar model of configuration management as Tail-F does but now quite the application. Just generating config isn't all that difficult. The hard part is pushing to the devices and working out what to do when on-box and off-box doesn't match. Good luck in your search, and if you find something really cool, be sure to post back! --chip On Tue, Mar 12, 2013 at 1:58 PM, Chip Marshall wrote: > Just curious what people are using for network configuration > manangement systems. I'm guessing most places have something > built in-house, but before starting down that road I figured it > would be a good idea to see if people have any off-the-shelf > systems they like. > > Some features I'd like to have: > * Interface configs > * Firewall filter configs > * BGP session configs > * User management > * Support for multiple router and switch vendors (at least > Juniper and Cisco) > > -- > Chip Marshall > http://2bithacker.net/ > -- Just my $.02, your mileage may vary, batteries not included, etc.... From wbailey at satelliteintelligencegroup.com Tue Mar 12 18:15:24 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Mar 2013 18:15:24 +0000 Subject: Network Configuration Management In-Reply-To: References: <20130312175813.GA27817@2bithacker.net>, Message-ID: Solar winds ncm is great if you can tolerate their sales borg. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: chip Date: 03/12/2013 11:09 AM (GMT-08:00) To: chip at 2bithacker.net Cc: North American Network Operators Group Subject: Re: Network Configuration Management I've never found anything that hits all of my needs. The closest off the shelf thing I've ever found is the Network Control System from Tail-F ( http://www.tail-f.com/network-control-system/). We're using a custom built app that's been refined over the last decade and does a really nice job. It uses a very similar model of configuration management as Tail-F does but now quite the application. Just generating config isn't all that difficult. The hard part is pushing to the devices and working out what to do when on-box and off-box doesn't match. Good luck in your search, and if you find something really cool, be sure to post back! --chip On Tue, Mar 12, 2013 at 1:58 PM, Chip Marshall wrote: > Just curious what people are using for network configuration > manangement systems. I'm guessing most places have something > built in-house, but before starting down that road I figured it > would be a good idea to see if people have any off-the-shelf > systems they like. > > Some features I'd like to have: > * Interface configs > * Firewall filter configs > * BGP session configs > * User management > * Support for multiple router and switch vendors (at least > Juniper and Cisco) > > -- > Chip Marshall > http://2bithacker.net/ > -- Just my $.02, your mileage may vary, batteries not included, etc.... From job.snijders at atrato.com Tue Mar 12 18:26:22 2013 From: job.snijders at atrato.com (Job Snijders) Date: Tue, 12 Mar 2013 19:26:22 +0100 Subject: Network Configuration Management In-Reply-To: <20130312175813.GA27817@2bithacker.net> References: <20130312175813.GA27817@2bithacker.net> Message-ID: <1C1A69A3-D466-4D49-981D-95DF180858F1@atrato.com> Hi Chip, AOL published some good looking open source software, it does not handle BGP at this moment, but it does other tasks like ACLs quite well. It's designed to be tightly integrated with your existing CMDB/RANCID, and it even takes timezones into account for pushing new configurations. Trigger: https://github.com/aol/trigger I plan on spending some cycles later this year on adding BGP functionality to Trigger Kind regards, Job On Mar 12, 2013, at 6:58 PM, Chip Marshall wrote: > Just curious what people are using for network configuration > manangement systems. I'm guessing most places have something > built in-house, but before starting down that road I figured it > would be a good idea to see if people have any off-the-shelf > systems they like. > > Some features I'd like to have: > * Interface configs > * Firewall filter configs > * BGP session configs > * User management > * Support for multiple router and switch vendors (at least > Juniper and Cisco) > > -- > Chip Marshall > http://2bithacker.net/ -- AS5580 - Atrato IP Networks From Petter.Bruland at allegiantair.com Tue Mar 12 18:31:03 2013 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Tue, 12 Mar 2013 18:31:03 +0000 Subject: Network Configuration Management In-Reply-To: References: <20130312175813.GA27817@2bithacker.net>, Message-ID: Just an FYI on "if you can tolerate their sales borg". If you request a quote and do not purchase, get ready for a borg attack of emails and calls. On topic: We're trying to survive with RANCID, which is great for pushing changes without any feedback... Last job we used Solarwinds NCM, and that's a fairly nice tool. We also had HP on site with their "Configuration Management System", which looked good until we started looking into support for Enterasys and Brocade. There were some short comings and expectation for custom written code to support 3rd party hardware. -P -----Original Message----- From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] Sent: Tuesday, March 12, 2013 11:15 AM To: chip; chip at 2bithacker.net Cc: North American Network Operators Group Subject: Re: Network Configuration Management Solar winds ncm is great if you can tolerate their sales borg. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: chip Date: 03/12/2013 11:09 AM (GMT-08:00) To: chip at 2bithacker.net Cc: North American Network Operators Group Subject: Re: Network Configuration Management I've never found anything that hits all of my needs. The closest off the shelf thing I've ever found is the Network Control System from Tail-F ( http://www.tail-f.com/network-control-system/). We're using a custom built app that's been refined over the last decade and does a really nice job. It uses a very similar model of configuration management as Tail-F does but now quite the application. Just generating config isn't all that difficult. The hard part is pushing to the devices and working out what to do when on-box and off-box doesn't match. Good luck in your search, and if you find something really cool, be sure to post back! --chip On Tue, Mar 12, 2013 at 1:58 PM, Chip Marshall wrote: > Just curious what people are using for network configuration > manangement systems. I'm guessing most places have something built > in-house, but before starting down that road I figured it would be a > good idea to see if people have any off-the-shelf systems they like. > > Some features I'd like to have: > * Interface configs > * Firewall filter configs > * BGP session configs > * User management > * Support for multiple router and switch vendors (at least > Juniper and Cisco) > > -- > Chip Marshall > http://2bithacker.net/ > -- Just my $.02, your mileage may vary, batteries not included, etc.... From jnegro at advance.net Tue Mar 12 18:35:47 2013 From: jnegro at advance.net (Jeffrey Negro) Date: Tue, 12 Mar 2013 18:35:47 +0000 Subject: Network Configuration Management In-Reply-To: <20130312175813.GA27817@2bithacker.net> References: <20130312175813.GA27817@2bithacker.net> Message-ID: We use Rancid and have it run every hour against Juniper and Cisco gear. If there's a change, we get an email, and all the revisions are automatically saved in SVN. Attach WebSVN and you have a nice web viewer. You administer the devices as you normally would, but you'll have automatic version control and change monitoring. It's simple to set up, and free. -----Original Message----- From: Chip Marshall [mailto:chip at 2bithacker.net] Sent: Tuesday, March 12, 2013 1:58 PM To: nanog at nanog.org Subject: Network Configuration Management Just curious what people are using for network configuration manangement systems. I'm guessing most places have something built in-house, but before starting down that road I figured it would be a good idea to see if people have any off-the-shelf systems they like. Some features I'd like to have: * Interface configs * Firewall filter configs * BGP session configs * User management * Support for multiple router and switch vendors (at least Juniper and Cisco) -- Chip Marshall http://2bithacker.net/ ------------------------------------------------------------------------------------------------ This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. From jabley at hopcount.ca Tue Mar 12 18:37:17 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 12 Mar 2013 14:37:17 -0400 Subject: Network Configuration Management In-Reply-To: References: <20130312175813.GA27817@2bithacker.net> Message-ID: <3569F347-AB85-42DE-AD81-18E7810A35F0@hopcount.ca> On 2013-03-12, at 14:35, Jeffrey Negro wrote: > We use Rancid and have it run every hour against Juniper and Cisco gear. If there's a change, we get an email, and all the revisions are automatically saved in SVN. Attach WebSVN and you have a nice web viewer. You administer the devices as you normally would, but you'll have automatic version control and change monitoring. It's simple to set up, and free. And it's extensible, kind of. :-) http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf Joe From garrett at skjelstad.org Tue Mar 12 19:16:02 2013 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Tue, 12 Mar 2013 12:16:02 -0700 Subject: Network mapping software Message-ID: I have seen NetBrain mentioned a few times here on this mailing list. Does anyone have any experience with it, and could they tell me some of the pros & cons that they had of their installations? Any limitations or pain points? Feel free to hit me off list. -Garrett From jason at lixfeld.ca Tue Mar 12 19:20:34 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 12 Mar 2013 15:20:34 -0400 Subject: Network mapping software In-Reply-To: References: Message-ID: <3C775FE4-E94C-4D06-A3A8-E294210AC036@lixfeld.ca> On 2013-03-12, at 3:16 PM, Garrett Skjelstad wrote: > I have seen NetBrain mentioned a few times here on this mailing list. Does > anyone have any experience with it, and could they tell me some of the pros > & cons that they had of their installations? > > Any limitations or pain points? Feel free to hit me off list. > > -Garrett Mr. Abley just posted a link (thanks Joe, I've been subconsciously looking for that link for months ;)) that, ironically, includes FOSS tools to do network mapping. Perhaps that might be useful if NetBrain's Windows requirements aren't congruent with your shop's policies on management systems' OS. http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf From bill at herrin.us Tue Mar 12 19:27:31 2013 From: bill at herrin.us (William Herrin) Date: Tue, 12 Mar 2013 15:27:31 -0400 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: <88D17156-6750-4833-BFB3-86E88486A679@delong.com> References: <1363109557.69828.YahooMailNeo@web31801.mail.mud.yahoo.com> <88D17156-6750-4833-BFB3-86E88486A679@delong.com> Message-ID: On Tue, Mar 12, 2013 at 1:45 PM, Owen DeLong wrote: > Once IPv6 is sufficiently ubiquitous (rough estimate, > but say 900+ of the Alexa 1000 sites have IPv6 and ~95% > of eyeball networks), you'll see a rapidly declining desire to > pay the increased cost of supporting IPv4. While that is surely true, it's not on a trajectory to happen this year. Or next year. Or the year after that. Call dual-stack an "intermediate" solution. Treat is as "temporary" or "very temporary" at your peril. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Tue Mar 12 19:32:49 2013 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Mar 2013 12:32:49 -0700 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <1363109557.69828.YahooMailNeo@web31801.mail.mud.yahoo.com> <88D17156-6750-4833-BFB3-86E88486A679@delong.com> Message-ID: <513F82E1.8000005@mtcc.com> On 03/12/2013 12:27 PM, William Herrin wrote: > On Tue, Mar 12, 2013 at 1:45 PM, Owen DeLong wrote: >> Once IPv6 is sufficiently ubiquitous (rough estimate, >> but say 900+ of the Alexa 1000 sites have IPv6 and ~95% >> of eyeball networks), you'll see a rapidly declining desire to >> pay the increased cost of supporting IPv4. > While that is surely true, it's not on a trajectory to happen this > year. Or next year. Or the year after that. Call dual-stack an > "intermediate" solution. Treat is as "temporary" or "very temporary" > at your peril. > Will dual stack cease to be before we all cease to be? Barring an immortality breakthrough, I'll bet on me first. Mike From owen at delong.com Tue Mar 12 20:46:38 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Mar 2013 13:46:38 -0700 Subject: What Should an Engineer Address when 'Selling' IPv6 to Executives? In-Reply-To: References: <1363109557.69828.YahooMailNeo@web31801.mail.mud.yahoo.com> <88D17156-6750-4833-BFB3-86E88486A679@delong.com> Message-ID: On Mar 12, 2013, at 12:27 PM, William Herrin wrote: > On Tue, Mar 12, 2013 at 1:45 PM, Owen DeLong wrote: >> Once IPv6 is sufficiently ubiquitous (rough estimate, >> but say 900+ of the Alexa 1000 sites have IPv6 and ~95% >> of eyeball networks), you'll see a rapidly declining desire to >> pay the increased cost of supporting IPv4. > > While that is surely true, it's not on a trajectory to happen this > year. Or next year. Or the year after that. Call dual-stack an > "intermediate" solution. Treat is as "temporary" or "very temporary" > at your peril. That really depends on how you view the trajectory. If you treat it as linear, you're absolutely right. OTOH, if you curve fit it, it depends on which curve-fitting algorithm you use, but it still looks like you might be right. If you look at industry trends, however, it's been growth spurts due to events that have created most of the growth. I suspect that most of the Alexa 1,000 will be doing something around IPv6 in the next 2 years and that anyone not doing IPv6 in 3 years will have a real hard time staying in the top 1000. Owen From marktees at gmail.com Tue Mar 12 21:14:23 2013 From: marktees at gmail.com (Mark Tees) Date: Wed, 13 Mar 2013 08:14:23 +1100 Subject: traffic accounting In-Reply-To: <85238DCF-A0EB-45BF-B7C0-3E93E85729D2@arbor.net> References: <7B1CA142-748B-48C1-8530-69154DA89ED3@hopcount.ca> <434F2251-337A-4146-A565-B417602394A6@arbor.net> <85238DCF-A0EB-45BF-B7C0-3E93E85729D2@arbor.net> Message-ID: <29998DD3-8550-4C7F-B0BC-7000FE1EB8E2@gmail.com> I guess if you are only counting bytes is possible to use firewall filters with counters? I guess it depends on how many match conditions vs lookup time are acceptable? Sent from some sort of iDevice. On 13/03/2013, at 2:18 AM, "Dobbins, Roland" wrote: > > On Mar 12, 2013, at 8:53 PM, Joe Abley wrote: > >> Can you use cflow/jflow/ipfix exports with 1:1 sampling on an MX480 without an MS-DPC? > > I'm not a Juniper person, so I'm not sure; note however that a) MS-DPC is necessary for NetFlow v9 (which is required for IPv6, for example), and b) sampled NetFlow (i.e., not 1:1, but higher ratios) is widely used and accepted in the industry. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From rali+nanog at tifosi.com Tue Mar 12 21:57:48 2013 From: rali+nanog at tifosi.com (R A Lichtensteiger) Date: Tue, 12 Mar 2013 17:57:48 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: References: Message-ID: <20130312215748.GA19169@mta.tifosi.com> Aaron Glenn wrote: <> I have a requirement to stock an actual, physical toolbox with power <> tools, drill bits, and other useful accoutrements one would use in a <> 'typical' datacenter. Can any one recommend brands/models of <> (preferably cordless) power tools they've used successfully? I'm partial to the Bosch 18VDC Li-ion but the brand is less important than the Li-ion part. I'd add: o A box of disposable foam earplugs o Cordless telephone with over the ear headset and noise suppression microphone Probably not for simultaneous use, though and the latter assumes a POTS line or VOIP adapter in the data center. Reto -- R A Lichtensteiger rali at tifosi.com "The Hitchhiker's Guide to the Galaxy has this to say on the subject of flying. There is an art, it says, or, rather, a knack to flying. The knack lies in learning how to throw yourself at the ground and miss. Pick a nice day, it suggests, and try it." From mikea at mikea.ath.cx Tue Mar 12 22:01:55 2013 From: mikea at mikea.ath.cx (Mike A) Date: Tue, 12 Mar 2013 17:01:55 -0500 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: References: Message-ID: <20130312220155.GA81374@mikea.ath.cx> On Thu, Feb 21, 2013 at 04:41:42PM +0000, Warren Bailey wrote: > Not to mention, the KG units are dot government only.. For obvious reasons. Erm ... yesandno. Lots of defense contractors have one end of a secured circuit. Been there, installed-and-maintained them. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From surfer at mauigateway.com Tue Mar 12 22:40:50 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 12 Mar 2013 15:40:50 -0700 Subject: site that shows overview of current cyber attacks Message-ID: <20130312154050.FAF563D0@resin03.mta.everyone.net> I saw this over on the Vanuatu Internet Users Group and thought it might be interesting for some: http://www.sicherheitstacho.eu scott From wbailey at satelliteintelligencegroup.com Tue Mar 12 23:16:26 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Mar 2013 23:16:26 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <20130312220155.GA81374@mikea.ath.cx> References: , <20130312220155.GA81374@mikea.ath.cx> Message-ID: <1rrlb69gl50jhagy8ios7gbe.1363130181410@email.android.com> Contractors with facility clearances? I would find it hard to believe dot gov would run secure circuits to a non secure facility. ;) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Mike A Date: 03/12/2013 3:04 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: Network security on multiple levels (was Re: NYT covers China cyberthreat) On Thu, Feb 21, 2013 at 04:41:42PM +0000, Warren Bailey wrote: > Not to mention, the KG units are dot government only.. For obvious reasons. Erm ... yesandno. Lots of defense contractors have one end of a secured circuit. Been there, installed-and-maintained them. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From shrdlu at deaddrop.org Tue Mar 12 23:33:25 2013 From: shrdlu at deaddrop.org (Shrdlu) Date: Tue, 12 Mar 2013 16:33:25 -0700 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <1rrlb69gl50jhagy8ios7gbe.1363130181410@email.android.com> References: , <20130312220155.GA81374@mikea.ath.cx> <1rrlb69gl50jhagy8ios7gbe.1363130181410@email.android.com> Message-ID: <513FBB45.4060207@deaddrop.org> On 3/12/2013 4:16 PM, Warren Bailey wrote: > Contractors with facility clearances? I would find it hard to believe > dot gov would run secure circuits to a non secure facility. ;) The word "Contractor" is usually used to refer to anyone that has a contract to do work with the government. Having spent nearly my entire working life in those situations, I can absolutely and completely guarantee that this type of circuit is common, that the types of phones referred to are commonplace in such an environment, and that I have used such phones in the course of a normal day. The world is filled with more things, Horatio, than are met with in your philosophy (with apologies to W.S.). -- The right to buy weapons is the right to be free. The Weapon Shops of Isher, by A. E. van Vogt From tvhawaii at shaka.com Wed Mar 13 01:33:56 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 12 Mar 2013 15:33:56 -1000 Subject: site that shows overview of current cyber attacks References: <20130312154050.FAF563D0@resin03.mta.everyone.net> Message-ID: <3867738394F248FDA003BD00A0ED4E72@owner59e1f1502> Scott Weeks wrote: > I saw this over on the Vanuatu Internet Users Group > and thought it might be interesting for some: > > http://www.sicherheitstacho.eu > > scott And I still question the wisdom of connecting an air traffic control system or nuclear reactor to that mess. --Michael From hank at efes.iucc.ac.il Wed Mar 13 05:46:48 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 13 Mar 2013 07:46:48 +0200 Subject: Network mapping software In-Reply-To: Message-ID: <5.1.1.6.2.20130313074107.0203a100@efes.iucc.ac.il> At 12:16 12/03/2013 -0700, Garrett Skjelstad wrote: >I have seen NetBrain mentioned a few times here on this mailing list. Does >anyone have any experience with it, and could they tell me some of the pros >& cons that they had of their installations? > >Any limitations or pain points? Feel free to hit me off list. This is a very nice piece of software for building automated maps of your network. You can do it online or feed it all your saved config files from a directory and it will auto-build OSPF and BGP or EIGRP maps of your network. It helped me spot one place where we forgot to turn on PIM. The map is dynamic and you can move your routers around and the links move with the shift on the map. It also flags routers that are missing a connection from the other end. -Hank >-Garrett From chaim.rieger at gmail.com Wed Mar 13 06:06:27 2013 From: chaim.rieger at gmail.com (chaim.rieger at gmail.com) Date: Tue, 12 Mar 2013 23:06:27 -0700 Subject: site that shows overview of current cyber attacks In-Reply-To: <20130312154050.FAF563D0@resin03.mta.everyone.net> References: <20130312154050.FAF563D0@resin03.mta.everyone.net> Message-ID: <51401763.9030902@gmail.com> On 3/12/2013 3:40 PM, Scott Weeks wrote: > > I saw this over on the Vanuatu Internet Users Group > and thought it might be interesting for some: > > http://www.sicherheitstacho.eu > > scott > http://map.honeycloud.net/ as well From loncek at energomail.sk Wed Mar 13 07:20:30 2013 From: loncek at energomail.sk (Michal Loncek) Date: Wed, 13 Mar 2013 08:20:30 +0100 Subject: Network Configuration Management In-Reply-To: <20130312175813.GA27817@2bithacker.net> References: <20130312175813.GA27817@2bithacker.net> Message-ID: <514028BE.10403@energomail.sk> Cisco Template Manager - http://www.gelogic.net/ M. On 03/12/2013 06:58 PM, Chip Marshall wrote: > Just curious what people are using for network configuration > manangement systems. I'm guessing most places have something > built in-house, but before starting down that road I figured it > would be a good idea to see if people have any off-the-shelf > systems they like. > > Some features I'd like to have: > * Interface configs > * Firewall filter configs > * BGP session configs > * User management > * Support for multiple router and switch vendors (at least > Juniper and Cisco) > From jamie at photon.com Wed Mar 13 12:11:49 2013 From: jamie at photon.com (Jamie Bowden) Date: Wed, 13 Mar 2013 12:11:49 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <20130312220155.GA81374@mikea.ath.cx> References: <20130312220155.GA81374@mikea.ath.cx> Message-ID: <465966A5F5B867419F604CD3E604C1E53B04FB92@PRA-DCA-MAIL.pra.ray.com> > From: Mike A [mailto:mikea at mikea.ath.cx] > On Thu, Feb 21, 2013 at 04:41:42PM +0000, Warren Bailey wrote: > > Not to mention, the KG units are dot government only.. For obvious > reasons. > Erm ... yesandno. Lots of defense contractors have one end of a secured > circuit. Been there, installed-and-maintained them. They don't belong to us, they're in a secured area inside a secured area (yes, I typed that twice on purpose), and they are regularly inspected by whichever bit of the fed loaned them to us. It's in our facility only as long as the circuit it's servicing exists. Jamie From jamie at photon.com Wed Mar 13 12:14:39 2013 From: jamie at photon.com (Jamie Bowden) Date: Wed, 13 Mar 2013 12:14:39 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <513FBB45.4060207@deaddrop.org> References: , <20130312220155.GA81374@mikea.ath.cx> <1rrlb69gl50jhagy8ios7gbe.1363130181410@email.android.com> <513FBB45.4060207@deaddrop.org> Message-ID: <465966A5F5B867419F604CD3E604C1E53B04FBB6@PRA-DCA-MAIL.pra.ray.com> > From: Shrdlu [mailto:shrdlu at deaddrop.org] > On 3/12/2013 4:16 PM, Warren Bailey wrote: > > > Contractors with facility clearances? I would find it hard to believe > > dot gov would run secure circuits to a non secure facility. ;) > > The word "Contractor" is usually used to refer to anyone that has a > contract to do work with the government. Having spent nearly my entire > working life in those situations, I can absolutely and completely > guarantee that this type of circuit is common, that the types of phones > referred to are commonplace in such an environment, and that I have used > such phones in the course of a normal day. STU / STE units are not KGs. Different type of equipment. Far less functional and single purpose. Jamie From eric at atlantech.net Wed Mar 13 14:30:21 2013 From: eric at atlantech.net (Eric Van Tol) Date: Wed, 13 Mar 2013 10:30:21 -0400 Subject: Network Configuration Management In-Reply-To: <20130312175813.GA27817@2bithacker.net> References: <20130312175813.GA27817@2bithacker.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B8642CA35F342@exchange.aoihq.local> > -----Original Message----- > From: Chip Marshall [mailto:chip at 2bithacker.net] > Sent: Tuesday, March 12, 2013 1:58 PM > To: nanog at nanog.org > Subject: Network Configuration Management > > Just curious what people are using for network configuration > manangement systems. I'm guessing most places have something > built in-house, but before starting down that road I figured it > would be a good idea to see if people have any off-the-shelf > systems they like. > Solarwinds NCM is what we use. It's multivendor and even handles menu-driven configurations and can easily be used to run commands on devices such as Linux servers for iptables firewall rules. It can perform inventory management and do things like search for MAC addresses on your network. Moreover, it can do policy reporting to ensure that your devices meet your configuration standards, both custom-made and for regulatory compliance like HIPAA/SOX/PCI/etc. We used to use RANCID, which worked great, but we outgrew it when we needed something to backup multiple vendors and didn't have the resources to modify the code to do what we needed. As other posters mentioned, their sales force is unrelentless, even after you purchase. It took a lot of complaining to finally get off whatever internal sales list we were on. Cost is also a concern, as it increases with the more devices you need to manage, plus there's a yearly maintenance fee. That said, I feel the cost is somewhat justified, as they have a pretty good development team that is quite active on their support forums and they listen to customer feedback for features. -evt From netfortius at gmail.com Wed Mar 13 14:51:27 2013 From: netfortius at gmail.com (Stefan) Date: Wed, 13 Mar 2013 09:51:27 -0500 Subject: Network Configuration Management In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B8642CA35F342@exchange.aoihq.local> References: <20130312175813.GA27817@2bithacker.net> <2C05E949E19A9146AF7BDF9D44085B8642CA35F342@exchange.aoihq.local> Message-ID: On Mar 13, 2013 9:31 AM, "Eric Van Tol" wrote: > > > -----Original Message----- > > From: Chip Marshall [mailto:chip at 2bithacker.net] > > Sent: Tuesday, March 12, 2013 1:58 PM > > To: nanog at nanog.org > > Subject: Network Configuration Management > > > > Just curious what people are using for network configuration > > manangement systems. I'm guessing most places have something > > built in-house, but before starting down that road I figured it > > would be a good idea to see if people have any off-the-shelf > > systems they like. > > > > Solarwinds NCM is what we use. It's multivendor and even handles menu-driven configurations and can easily be used to run commands on devices such as Linux servers for iptables firewall rules. It can perform inventory management and do things like search for MAC addresses on your network. Moreover, it can do policy reporting to ensure that your devices meet your configuration standards, both custom-made and for regulatory compliance like HIPAA/SOX/PCI/etc. > > We used to use RANCID, which worked great, but we outgrew it when we needed something to backup multiple vendors and didn't have the resources to modify the code to do what we needed. > > As other posters mentioned, their sales force is unrelentless, even after you purchase. It took a lot of complaining to finally get off whatever internal sales list we were on. Cost is also a concern, as it increases with the more devices you need to manage, plus there's a yearly maintenance fee. That said, I feel the cost is somewhat justified, as they have a pretty good development team that is quite active on their support forums and they listen to customer feedback for features. > > -evt > To those of you using Solarwinds: what about scalability? How many devices do you presently support with this solution, and under which hardware or VM and storage configuration, if you don't mind sharing that? Stefan From w3yni1 at gmail.com Wed Mar 13 14:55:36 2013 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 13 Mar 2013 10:55:36 -0400 Subject: Network Configuration Management In-Reply-To: References: <20130312175813.GA27817@2bithacker.net> <2C05E949E19A9146AF7BDF9D44085B8642CA35F342@exchange.aoihq.local> Message-ID: I've used Kiwi Cattools as well as some homegrown perl and shell script stuff for versioning / audit trails. Cattools works OK and scales. Unsure of pricing structure though. I never liked Ciscoworks for doing it even though it will manage your devices that way. On Wed, Mar 13, 2013 at 10:51 AM, Stefan wrote: > On Mar 13, 2013 9:31 AM, "Eric Van Tol" wrote: > > > > > -----Original Message----- > > > From: Chip Marshall [mailto:chip at 2bithacker.net] > > > Sent: Tuesday, March 12, 2013 1:58 PM > > > To: nanog at nanog.org > > > Subject: Network Configuration Management > > > > > > Just curious what people are using for network configuration > > > manangement systems. I'm guessing most places have something > > > built in-house, but before starting down that road I figured it > > > would be a good idea to see if people have any off-the-shelf > > > systems they like. > > > > > > > Solarwinds NCM is what we use. It's multivendor and even handles > menu-driven configurations and can easily be used to run commands on > devices such as Linux servers for iptables firewall rules. It can perform > inventory management and do things like search for MAC addresses on your > network. Moreover, it can do policy reporting to ensure that your devices > meet your configuration standards, both custom-made and for regulatory > compliance like HIPAA/SOX/PCI/etc. > > > > We used to use RANCID, which worked great, but we outgrew it when we > needed something to backup multiple vendors and didn't have the resources > to modify the code to do what we needed. > > > > As other posters mentioned, their sales force is unrelentless, even after > you purchase. It took a lot of complaining to finally get off whatever > internal sales list we were on. Cost is also a concern, as it increases > with the more devices you need to manage, plus there's a yearly maintenance > fee. That said, I feel the cost is somewhat justified, as they have a > pretty good development team that is quite active on their support forums > and they listen to customer feedback for features. > > > > -evt > > > > To those of you using Solarwinds: what about scalability? How many devices > do you presently support with this solution, and under which hardware or VM > and storage configuration, if you don't mind sharing that? > > Stefan > From wbailey at satelliteintelligencegroup.com Wed Mar 13 15:33:42 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 13 Mar 2013 15:33:42 +0000 Subject: Network Configuration Management In-Reply-To: References: <20130312175813.GA27817@2bithacker.net> <2C05E949E19A9146AF7BDF9D44085B8642CA35F342@exchange.aoihq.local>, Message-ID: You will grow tired of their sales people long before you approach a brick wall of scalability. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Stefan Date: 03/13/2013 7:53 AM (GMT-08:00) To: Eric Van Tol Cc: nanog at nanog.org Subject: RE: Network Configuration Management On Mar 13, 2013 9:31 AM, "Eric Van Tol" wrote: > > > -----Original Message----- > > From: Chip Marshall [mailto:chip at 2bithacker.net] > > Sent: Tuesday, March 12, 2013 1:58 PM > > To: nanog at nanog.org > > Subject: Network Configuration Management > > > > Just curious what people are using for network configuration > > manangement systems. I'm guessing most places have something > > built in-house, but before starting down that road I figured it > > would be a good idea to see if people have any off-the-shelf > > systems they like. > > > > Solarwinds NCM is what we use. It's multivendor and even handles menu-driven configurations and can easily be used to run commands on devices such as Linux servers for iptables firewall rules. It can perform inventory management and do things like search for MAC addresses on your network. Moreover, it can do policy reporting to ensure that your devices meet your configuration standards, both custom-made and for regulatory compliance like HIPAA/SOX/PCI/etc. > > We used to use RANCID, which worked great, but we outgrew it when we needed something to backup multiple vendors and didn't have the resources to modify the code to do what we needed. > > As other posters mentioned, their sales force is unrelentless, even after you purchase. It took a lot of complaining to finally get off whatever internal sales list we were on. Cost is also a concern, as it increases with the more devices you need to manage, plus there's a yearly maintenance fee. That said, I feel the cost is somewhat justified, as they have a pretty good development team that is quite active on their support forums and they listen to customer feedback for features. > > -evt > To those of you using Solarwinds: what about scalability? How many devices do you presently support with this solution, and under which hardware or VM and storage configuration, if you don't mind sharing that? Stefan From jra at baylink.com Wed Mar 13 15:48:53 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 13 Mar 2013 11:48:53 -0400 (EDT) Subject: [outages] comcast/sprint oddities In-Reply-To: <20130313033353.GA24920@icarus.home.lan> Message-ID: <20917234.9650.1363189733409.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeremy Chadwick" > If you really wanted to bring this up with Sprint, you would need to > have a relationship with them, and you would *need* to provide source > and destination IPs. And there's the point that makes fixing this stuff such a bitch: you almost never have a relationship with anyone except the carrier you connect through (and sometimes not even them :-). This is, incidentally, why my professional recommendation to people setting up "nailed up" links over the Internet is to move heaven and earth to get every point on the same carrier, or to make sure, at the very least that there is only one exchange point in the middle, and you're a customer of the carrier on both sides of it. Having to escalate through 3 or 4 carriers to get something fixed isn't just time consuming, it's often impossible. Social engineering NOC hotlines (as much as I hate to advocate it) is often the only solution; bring your Geek License. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Mar 13 15:50:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 13 Mar 2013 11:50:31 -0400 (EDT) Subject: [outages] comcast/sprint oddities In-Reply-To: <20917234.9650.1363189733409.JavaMail.root@benjamin.baylink.com> Message-ID: <5048563.9652.1363189831331.JavaMail.root@benjamin.baylink.com> Apologies. NANOG is doing the right thing (in not munging reply-to), and Zimbra is doing the wrong thing (in not having a reply-to-list button, even though I filed the RFC 5 years and 3 major revisions ago); sometimes (usually Before Coffee, like now), I hand-fill the wrong address. Cheers, -- jra ----- Original Message ----- > From: "Jay Ashworth" > To: "NANOG" > Sent: Wednesday, March 13, 2013 11:48:53 AM > Subject: Re: [outages] comcast/sprint oddities > ----- Original Message ----- > > From: "Jeremy Chadwick" > > > If you really wanted to bring this up with Sprint, you would need to > > have a relationship with them, and you would *need* to provide > > source > > and destination IPs. > > And there's the point that makes fixing this stuff such a bitch: you > almost > never have a relationship with anyone except the carrier you connect > through > (and sometimes not even them :-). > > This is, incidentally, why my professional recommendation to people > setting > up "nailed up" links over the Internet is to move heaven and earth to > get every point on the same carrier, or to make sure, at the very > least > that there is only one exchange point in the middle, and you're a > customer > of the carrier on both sides of it. > > Having to escalate through 3 or 4 carriers to get something fixed > isn't > just time consuming, it's often impossible. > > Social engineering NOC hotlines (as much as I hate to advocate it) is > often the only solution; bring your Geek License. :-) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Wed Mar 13 15:55:14 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 13 Mar 2013 15:55:14 +0000 Subject: [outages] comcast/sprint oddities In-Reply-To: <20917234.9650.1363189733409.JavaMail.root@benjamin.baylink.com> References: <20130313033353.GA24920@icarus.home.lan>, <20917234.9650.1363189733409.JavaMail.root@benjamin.baylink.com> Message-ID: I once dropped over 1500 bucks on drinks for an entire TAC. Paid for itself instantly.. 5 years later I still go straight to Tier III. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Jay Ashworth Date: 03/13/2013 8:50 AM (GMT-08:00) To: NANOG Subject: Re: [outages] comcast/sprint oddities ----- Original Message ----- > From: "Jeremy Chadwick" > If you really wanted to bring this up with Sprint, you would need to > have a relationship with them, and you would *need* to provide source > and destination IPs. And there's the point that makes fixing this stuff such a bitch: you almost never have a relationship with anyone except the carrier you connect through (and sometimes not even them :-). This is, incidentally, why my professional recommendation to people setting up "nailed up" links over the Internet is to move heaven and earth to get every point on the same carrier, or to make sure, at the very least that there is only one exchange point in the middle, and you're a customer of the carrier on both sides of it. Having to escalate through 3 or 4 carriers to get something fixed isn't just time consuming, it's often impossible. Social engineering NOC hotlines (as much as I hate to advocate it) is often the only solution; bring your Geek License. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Mar 13 15:56:18 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 13 Mar 2013 11:56:18 -0400 (EDT) Subject: [outages] comcast/sprint oddities In-Reply-To: Message-ID: <17322724.9662.1363190178697.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Warren Bailey" > I once dropped over 1500 bucks on drinks for an entire TAC. Paid for > itself instantly.. 5 years later I still go straight to Tier III. Yes, but, like Jon, that doesn't scale. :-} Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From oscar.vives at gmail.com Wed Mar 13 16:21:51 2013 From: oscar.vives at gmail.com ( .) Date: Wed, 13 Mar 2013 17:21:51 +0100 Subject: NYT covers China cyberthreat In-Reply-To: References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> <368EBC27-77B2-447A-A1F6-49CA9729C6B1@zaidali.com> Message-ID: On 20 February 2013 08:04, Warren Bailey wrote: > An Internet kill switch is a nightmare. We can't even figure out how to run a relay radio system for national emergencies.. Now we are going to assume the people who were owned can somehow shut off communications? > > We as Americans have plenty of things we have done halfass.. I hope an Internet kill switch doesn't end up being one of them. Build your own private networks, you can't get rooted if someone can't knock. Simple as that. > He!, we share the internet with america. If you guys decide to build and use a internet kill switch, just nuke your part of the internet. People outside USA are happy with the internet, and we need it :D just don't use code 666 on the keypad :D http://www.youtube.com/watch?v=Ed6Yr81jZ6g I know theres a lot of it, and If suddenly tomorrow a enormeous solar flare kill every electronic in the america continent, we will have problems here in europe. I just want to make sure you guys know that we want our part of the internet to continue, even if you guys decide to pull the plug. -- -- ?in del ?ensaje. From calin.chiorean at secdisk.net Wed Mar 13 18:45:43 2013 From: calin.chiorean at secdisk.net (Calin Chiorean) Date: Wed, 13 Mar 2013 19:45:43 +0100 Subject: Network mapping software In-Reply-To: Message-ID: Hello Garrett, They have a Personal version which is free: http://www.netbraintech.com/products/personal-edition/ It's very limited, but to get a feeling about work with NetBrain, this may be a good start. Also there is a 30 days trial. I know that a lot of people may tell you their personal experience, which is OK, but in the end you have to be comfortable with the software you want to use. HTH, Calin On 3/12/13 8:16 PM, "Garrett Skjelstad" wrote: >I have seen NetBrain mentioned a few times here on this mailing list. Does >anyone have any experience with it, and could they tell me some of the >pros >& cons that they had of their installations? > >Any limitations or pain points? Feel free to hit me off list. > >-Garrett From jra at baylink.com Thu Mar 14 17:56:22 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 14 Mar 2013 13:56:22 -0400 (EDT) Subject: WW: Bruce Schneier on why security can't work Message-ID: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ Three words: "desktop gene sequencing", "ebola", "script kiddies". I dunno how to fix it either. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mfidelman at meetinghouse.net Thu Mar 14 23:56:51 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 14 Mar 2013 19:56:51 -0400 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: <514263C3.9030602@meetinghouse.net> Jay Ashworth wrote: > http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ > > Three words: "desktop gene sequencing", "ebola", "script kiddies". > > I dunno how to fix it either. > I think that's six words - twice as scary. I dunno how to fix it either ("when in trouble, when in doubt, run in circles, scream and shout?") -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From djahandarie at gmail.com Fri Mar 15 00:31:48 2013 From: djahandarie at gmail.com (Darius Jahandarie) Date: Thu, 14 Mar 2013 20:31:48 -0400 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Mar 14, 2013 at 1:56 PM, Jay Ashworth wrote: > http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ Although I don't disagree with Bruce, this sort of "scare article" doesn't seem to be very in character for him. -- Darius Jahandarie From Valdis.Kletnieks at vt.edu Fri Mar 15 00:39:20 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 14 Mar 2013 20:39:20 -0400 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: Your message of "Thu, 14 Mar 2013 19:56:51 -0400." <514263C3.9030602@meetinghouse.net> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <514263C3.9030602@meetinghouse.net> Message-ID: <3665.1363307960@turing-police.cc.vt.edu> On Thu, 14 Mar 2013 19:56:51 -0400, Miles Fidelman said: > I think that's six words - twice as scary. I dunno how to fix it either > ("when in trouble, when in doubt, run in circles, scream and shout?") I don't think script kiddies with gene sequencers will manage to kill us with Ebola, for the same reason that script kiddies haven't managed to kill the Internet - by the time they figure out how to not kill themselves with the Ebola, they usually figure out that it's a losing proposition (consider the number of nation states that *could* deploy biological weapons compared to the number that actually have). Anybody seriously thing the RBN couldn't kill the Internet if they really wanted to? Why don't they? Because they can't monetize a dead Internet. Having said that, we probably *will* see a number of incidents where the biohazard cleanup crews have to clean up a local mess... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From owen at delong.com Fri Mar 15 00:53:56 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Mar 2013 17:53:56 -0700 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <3665.1363307960@turing-police.cc.vt.edu> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <514263C3.9030602@meetinghouse.net> <3665.1363307960@turing-police.cc.vt.edu> Message-ID: <53F4125A-2C5C-4AD5-9F1D-4DA72C3023FD@delong.com> Not really anything all that new from a conceptual perspective: http://www.youtube.com/watch?v=3hZo5k0V9M0 Owen On Mar 14, 2013, at 5:39 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 14 Mar 2013 19:56:51 -0400, Miles Fidelman said: > >> I think that's six words - twice as scary. I dunno how to fix it either >> ("when in trouble, when in doubt, run in circles, scream and shout?") > > I don't think script kiddies with gene sequencers will manage to kill us > with Ebola, for the same reason that script kiddies haven't managed to > kill the Internet - by the time they figure out how to not kill themselves > with the Ebola, they usually figure out that it's a losing proposition > (consider the number of nation states that *could* deploy biological weapons > compared to the number that actually have). > > Anybody seriously thing the RBN couldn't kill the Internet if they really > wanted to? Why don't they? Because they can't monetize a dead Internet. > > Having said that, we probably *will* see a number of incidents where the > biohazard cleanup crews have to clean up a local mess... From jra at baylink.com Fri Mar 15 01:08:37 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 14 Mar 2013 21:08:37 -0400 (EDT) Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <53F4125A-2C5C-4AD5-9F1D-4DA72C3023FD@delong.com> Message-ID: <15808262.9930.1363309717377.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Owen DeLong" > Not really anything all that new from a conceptual perspective: > > http://www.youtube.com/watch?v=3hZo5k0V9M0 Maybe, but bio is a bigger spread hazard than nuke, and harder to test for -- which is probably why, by policy, DOD/NCA treats it as a WMD. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fjblas at arcos.inf.uc3m.es Thu Mar 14 20:26:37 2013 From: fjblas at arcos.inf.uc3m.es (Javier Garcia Blas) Date: Thu, 14 Mar 2013 21:26:37 +0100 Subject: Call For Papers: EuroMPI 2013 Paper. Last days for submissions. Deadline: March 29th, 2013 Message-ID: <20130314202637.GA637@piojito.arcos.inf.uc3m.es> Dear Sir or Madam, (We apologize if you receive multiple copies of this message) ============================================================ Recent Advances in Message Passing Interface. 20th European MPI Users' Group Meeting (EuroMPI 2013) EuroMPI 2013 is being held in cooperation with SIGHPC Madrid, Spain, September 15-18, 2013 www.eurompi2013.org BACKGROUND AND TOPICS ------------------------------- EuroMPI is the preeminent meeting for users, developers and researchers to interact and discuss new developments and applications of message-passing parallel computing, in particular in and related to the Message Passing Interface (MPI). The annual meeting has a long, rich tradition, and the 20th European MPI Users' Group Meeting will again be a lively forum for discussion of everything related to usage and implementation of MPI and other parallel programming interfaces. Traditionally, the meeting has focused on the efficient implementation of aspects of MPI, typically on high-performance computing platforms, benchmarking and tools for MPI, short-comings and extensions of MPI, parallel I/O and fault tolerance, as well as parallel applications using MPI. The meeting is open towards other topics, in particular application experience and alternative interfaces for high-performance heterogeneous, hybrid, distributed memory systems. Topics of interest include, but are not limited to: - MPI implementation issues and improvements - Extensions to and shortcomings of MPI - Tools and environments for MPI - Hybrid and heterogeneous programming with MPI and other interfaces - Relation of MPI to alternative interfaces for hybrid/heterogeneous distributed memory systems - Interaction between message-passing software and hardware, in particular new high performance architectures - Fault tolerance in message-passing implementations and systems - Performance evaluation for MPI and MPI based applications- - Automatic performance tuning of MPI applications and implementations - Verification of message passing applications and protocols - Applications using message-passing, in particular in Computational Science and Scientific Computing - Non-standard message-passing applications - Parallel algorithms in the message-passing paradigm - Algorithms using the message-passing paradigm The meeting will feature contributed talks on the selected, peer-reviewed papers, invited expert talks covering upcoming and future issues, a vendor session where selected vendors will present their new developments in hybrid and heterogeneous cluster and high-performance architectures, a poster session, and a tutorial day. The scientific part of the conference is organized in cooperation with ACM SIGHPC. Conference proceedings will be published in the ACM Digital Library, which includes short and long papers, workshop papers, and posters. Selected high quality papers will be published in an international journals. There will also be a reward for the overall best paper from the academic conference. WORKSHOPS ------------------------------- IMUDI SPECIAL SESSION ON IMPROVING MPI USER AND DEVELOPER INTERACTION The IMUDI special session, to be held as a full-day meeting at the EuroMPI 2013 conference in Madrid, Spain, focuses on bringing together the MPI end-user and MPI implementor communities through discussions on MPI usage experiences, techniques, and optimizations. This meeting will focus on evaluating the MPI standard from the perspective of the MPI end-user (application and library developers) and address concerns and insights of MPI implementors and vendors. Unlike workshops associated with other conferences, the IMUDI session is still considered to be a part of the Euro MPI conference. Submissions will be reviewed separately to facilitate bringing together research publications falling into these "special focus" areas. More info at: http://press.mcs.anl.gov/imudi/ ENERGY-EFFICIENT HIGH PERFORMANCE COMPUTING & COMMUNICATION WORKSHOP (E2HPC2) 2013 The first Energy-Efficient High Performance Computing & Communication workshop will be co-located with EuroMPI 2013 in Madrid. Energy-awareness is now a main topic for HPC systems. The goal of this workshop is to discuss latest researches on the impact and possibles leverages of communications for such systems. E2HPC2 solicits original and non-published or under-review articles on the field of energy-aware communication in HPC environment. This workshop is co-located with EuroMPI as MPI is the main communication interface in those environments. More info at: http://www.irit.fr/~Georges.Da-Costa/e2hpc2.html PBIO 2013: INTERNATIONAL WORKSHOP ON PARALLELISM IN BIOINFORMATICS In Bioinformatics, we can find a variety of problems which are affected by huge processing times and memory consumption, due to the large size of biological data sets and the inherent complexity of biological problems. In fact, Bioinformatics is one of the most exciting research areas in which Parallelism finds application. Successful examples are mpiBLAST or ClustalW-MPI, among many others. In conclusion, Bioinformatics allows and encourages the application of many different parallelism-based technologies. The focus of this workshop is on MPI-based approaches, but we welcome any technique based on: multicore and cluster computing, supercomputing, grid computing, cloud computing, hardware accelerators as GPUs, FPGAs, or Cell processors, etc. More info at: http://arco.unex.es/mavega/pbio2013/ SUBMISSION INFORMATION ------------------------------- Contributors are invited to submit a full paper as a PDF document not exceeding 6 pages in English. The title page should contain an abstract of at most 100 words and five specific, topical keywords. The paper must be formatted according to double-column ACM ICPS proceedings style. The usage of LaTeX for preparation of the contribution as well as the submission in camera ready format is strongly recommended. Style files can be found at http://www.acm.org/publications/icps-instructions/. New work that is not yet mature for a full paper, short observations, and similar brief announcements are invited for the poster session. Contributions to the poster session should be submitted in the form of a two page abstract. All contributions will be fully peer reviewed by the program committee. Papers shall be submitted electronically via Easychair, see http://www.easychair.org/conferences/?conf=eurompi2013. NVIDIA BEST PAPER AWARD ------------------------------- The Program Committee of EuroMPI 2013 will give a best paper awards. Best Paper Awards will be given to the author(s) of a full paper presented at the conference, selected by the Organizing Committee. The Best Paper Award is a Tesla K20 computing processor, sponsored by NVIDIA, valued in $3,200. SCHEDULE, IMPORTANT DATES ------------------------------- - Submission of full papers and poster: March 29th, 2013 - Author notification: May 11th, 2013 - Camera Ready papers due: June 15th, 2013 - Tutorial(s): September 15th, 2012 - Conference: September 16th-18th, 2013 CONFERENCE SPONSORS ------------------------------- Platinum: CISCO Gold: Bull NVidia COMMITTEE ------------------------------- GENERAL CHAIR Jack Dongarra, University of Tennessee, Knoxville, USA ORGANIZERS, PC CHAIRS Javier Garcia Blas, Carlos III University (fjblas at inf.uc3m.es) Jesus Carretero, Carlos III University (jesus.carretero at uc3m.es) PROGRAM COMMITTEE Pavan Balaji, Argonne National Laboratory Siegfried Benkner, University of Vienna George Bosilca, Innovative Computing Laboratory - University of Tennessee Gil Bloch, Mellanox Technologies Ron Brightwell, Sandia National Laboratories Darius Buntinas, Argonne National Laboratory Franck Cappello, INRIA and University of Illinois at Urbana-Champaign Yiannis Cotronis, National and Kapodistrian University of Athens Chi-Yin Chow, Department of Computer Science, City University of Hong Kong Anthony Danalis, University of Tennessee Luiz Derose, Cray Christian Engelmann, Oak Ridge National Laboratory Edgar Gabriel, University of Houston Brice Goglin, INRIA Ganesh Gopalakrishnan, University of Utah David Goodell, Argonne National Laboratory Richard Graham, Oak Ridge National Laboratory William Gropp, University of Illinois at Urbana-Champaign Rainer Keller, HFT Stuttgart, University of Applied Science Julian Kunkel, Universitat Hamburg Thomas Herault, University of Tennessee Bronis De Supinski, Lawrence Livermore National Laboratory Thomas Ludwig, German Climate Computing Center and University of Hamburg David E. Singh, University Carlos III of Madrid Torsten Hoefler, ETH Zurich Atsushi Hori, RIKEN AICS Florin Isaila, University Carlos III of Madrid Akihiro Inokuchi, Osaka University Yutaka Ishikawa, Graduate School of Information Science and Technology / Information Technology Center, The University of Tokyo Emmanuel Jeannot, INRIA Dries Kimpe, Argonne National Laboratory Jesper Larsson Traf, Vienna University of Technology Alexey Lastovetsky, UCD School of Computer Science & Informatics Laurent Lefevre, INRIA Dong Li, Oak Rdige National Lab Ewing Lusk, Argonne National Laboratory Teng Ma, NetApp Inc Guillaume Mercier, ENSEIRB/INRIA Bernd Mohr, Juelich Supercomputing Center Raffaele Montella, Department of Applied Science - University of Naples Parthenope Julian David Morillo Pozo, Barcelona Supercomputing Center Matthias Mueller, ZIH, TU Dresden Jose Nelson Amaral, University of Alberta Jaechun No, Sejong University Maria S. Perez, Technical University of Madrid Rolf Rabenseifner, HLRS, University of Stuttgart Rolf Riesen, IBM Gudula Runge, Chemnitz University of Technology Mitsuhisa Sato, University of Tsukuba Christian Siebert, RWTH Aachen University Anna Sikora, DACSO - UAB Shinji Sumimoto, Fujitsu Laboratories Frederic Suter, IN2P3 Computing Center Jeff Squyres, Cisco Alexander Supalov, Intel GmbH Domenico Talia, Universita della Calabria Vinod Tipparaju, AMD Rajeev Thakur, Argonne National Laboratory Carsten Trinitis, University of Bedfordshire Yuichi Tsujita, Kinki University Denis Trystram, Grenoble university Keith Underwood, Intel Mateo Valero, Barcelona Supercomputing Center Alan Wagner, University of British Columbia Roland Wismulle, University of Siegen Roman Wyrzykowski, Czestochowa University of Technology Xin Yuan, Florida State University CONFERENCE FEES ------------------------------- The conference will hopefully be well supported by sponsors, which will help directly towards keeping the fees low. As far as possible, special student fees will be offered. From nanog at haller.ws Fri Mar 15 00:05:31 2013 From: nanog at haller.ws (Patrick) Date: Fri, 15 Mar 2013 08:05:31 +0800 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: <20130315000530.GE7580@haller.ws> On 2013-03-14 13:56, Jay Ashworth wrote: > http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ > > Three words: "desktop gene sequencing", "ebola", "script kiddies". When the costs of offense fall, a pretty good response is to drive the costs of defense through the floor. E.g. how do we drive the costs of mitigating DDoSs down further? A second best response would be ubiquitous surveillance.... From jeroen at mompl.net Fri Mar 15 01:39:14 2013 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 14 Mar 2013 18:39:14 -0700 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> Message-ID: <51427BC2.50904@mompl.net> On 03/10/2013 07:33 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Aaron Glenn" > >> I have a requirement to stock an actual, physical toolbox with power >> tools, drill bits, and other useful accoutrements one would use in a >> 'typical' datacenter. > > If you look back about a year, Aaron, you'll find a thread I started about > stocking a vending machine for a datacenter; you'll probably find everything > in there that you need. > > But really: a power screwdriver, a bag of #2 bits, and a 12" extender are > 85% of it. ;-) I mostly get by with just a screwdriver. Powered screwdrivers annoy the hell out of me in almost all cases. Admitted, that's just for the occasional racking and removing of servers, repairs, adding disks etc. Greetings, Jeroen -- Earthquake Magnitude: 4.3 Date: Friday, March 15, 2013 00:46:55 UTC Location: Queen Charlotte Islands, Canada region Latitude: 52.5000; Longitude: -132.5000 Depth: 19.00 km From ops.lists at gmail.com Fri Mar 15 01:50:34 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 15 Mar 2013 07:20:34 +0530 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: There's nothing much new in the article other than that the usual headline grabbing soundbite and tortured big bang analogy --srs (htc one x) On 15-Mar-2013 6:04 AM, "Darius Jahandarie" wrote: > On Thu, Mar 14, 2013 at 1:56 PM, Jay Ashworth wrote: > > > http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ > > Although I don't disagree with Bruce, this sort of "scare article" > doesn't seem to be very in character for him. > > > -- > Darius Jahandarie > > From rdobbins at arbor.net Fri Mar 15 01:50:44 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 15 Mar 2013 01:50:44 +0000 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <20130312215748.GA19169@mta.tifosi.com> References: <20130312215748.GA19169@mta.tifosi.com> Message-ID: <74476D23-0FE4-4C66-AD67-CC34937F5635@arbor.net> On Mar 13, 2013, at 4:57 AM, R A Lichtensteiger wrote: > Probably not for simultaneous use, though and the latter assumes a POTS line or VOIP adapter in the data center. Handie-talkies on unregulated 30MHz or whatever (i.e., the ones you can buy at Radio Shack) are certainly useful, as are phones - good catch! ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From eugen at leitl.org Fri Mar 15 10:02:29 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 15 Mar 2013 11:02:29 +0100 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <3665.1363307960@turing-police.cc.vt.edu> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <514263C3.9030602@meetinghouse.net> <3665.1363307960@turing-police.cc.vt.edu> Message-ID: <20130315100229.GR6172@leitl.org> On Thu, Mar 14, 2013 at 08:39:20PM -0400, Valdis.Kletnieks at vt.edu wrote: > Having said that, we probably *will* see a number of incidents where the > biohazard cleanup crews have to clean up a local mess... The DIYbio community is perfectly harmless so far. The feds are already breathing down their necks, so there's no really no point in adding gratuitious gasoline to the fire. From oscar.vives at gmail.com Fri Mar 15 11:33:12 2013 From: oscar.vives at gmail.com ( .) Date: Fri, 15 Mar 2013 12:33:12 +0100 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: On 14 March 2013 18:56, Jay Ashworth wrote: > http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ > > Three words: "desktop gene sequencing", "ebola", "script kiddies". > > I dunno how to fix it either. > > Cheers, > -- jra This is a problem for the future to solve. Not us. In bioweapons, I think we are still on the "happy hackers era", where people in a biochemical laboratory in Liverpool have access to some fungus that can wipe half the city, but don't do, because have a lot of fun studying the fungus to learn new antibiotics, or maybe to cure baldness. Scientist are, of course, hackers. Fun people that make this question: Exploitability. Can this fungus be used to cure baldness? Can this fungus be exploited to remove plastic from our oceans?. Exploitablity is a fun good word, and I never see a person like Bruce Schneier talk about it (how fucking awesome is exploitability). So reading people like Bruce Schneier you only get half the picture. We exist only because the carbon based chemistry is exploitable to the x900000. If carbon where less exploitable, like silice, maybe life will not exist. Similary, maybe you need exploitability to have a internet. -- -- ?in del ?ensaje. From nanog at haller.ws Fri Mar 15 12:16:24 2013 From: nanog at haller.ws (Patrick) Date: Fri, 15 Mar 2013 20:16:24 +0800 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: <20130315121623.GG7580@haller.ws> On 2013-03-15 12:33, . wrote: > Similary, maybe you need exploitability to have a internet. Exploitability = usability from a different perspective. Postel said "be conservative in what you do, be liberal in what you accept", which seems like usability restated, and would QED this. Granted, we think we've made something fairly usable: it's always someone else's filter fail or multi-hour/day DDoS that ends up in the news... until we get unlucky. ;) From mysidia at gmail.com Fri Mar 15 12:19:11 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 15 Mar 2013 07:19:11 -0500 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: On 3/14/13, Jay Ashworth wrote: > http://www.wired.com/opinion/2013/03/security-when-the-bad-guys-have-technology-too-how-do-we-survive/ So what I gather from that: "Calling terrorism an existential threat is ridiculous in a country where more people die each month in car crashes than died in the 9/11 terrorist attacks." And there you have it :) Security obviously works thus far, in the sense, that so far, government has been preserved -- there is not total chaos, in at least most of the world, and people do not doubt if their life or property will still exist the next day. There have been incidents, even serious ones, and times when security failed -- it just means that security is not perfect, but hardly anything humans do is perfect; devices we make fail, accidents happen. I never saw an article yet about why engineering can't work, or why driver safety can't work (driver licensure/speed limits/seatbelts/traffic signs). Accidents are inevitable, and maybe the miscreants are able to take advantage of new faster engine technology before the police can, but it's not the point :) Abusing new technology faster doesn't trump the extreme smallness of the numbers of truly bad actors, who have irrational thinking, would like to end civilization, and the intersection between those and those who have a viable method that would work + the right resources/skill available, and a reasonable chance of success.... astronomically small If in a few decades, there is a 0.1% chance per decade of a script kiddie ending civilization, I think we've got few reasonable alternatives but to accept that risk and hope for the best :) > Three words: "desktop gene sequencing", "ebola", "script kiddies". Good thing genetic manipulation is highly non-trivial, and obtaining ebola samples would require significant legwork while script kiddies lack motivation, and there are much lazier, less risky/dangerous, more profitable ways for them to steal. At least for the forseeable future until financial account theft becomes a solved problem. Then they might move to ransomware that threatens to shut down power grids, if they dpn't get paid, I suppose... but For the forseeable future; there's no mechanism for using a computer to modify a virus to insert spam or email-cc-details commands directly into people's brains, or to infect people's brains with malware to create a human botnet. At that point, perhaps in a couple hundred years, one begins to become concerned that one of the human botnet operators, could end civilization by accident. > -- jra -- -JH From Valdis.Kletnieks at vt.edu Fri Mar 15 12:29:07 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 15 Mar 2013 08:29:07 -0400 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: Your message of "Fri, 15 Mar 2013 11:02:29 +0100." <20130315100229.GR6172@leitl.org> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <514263C3.9030602@meetinghouse.net> <3665.1363307960@turing-police.cc.vt.edu> <20130315100229.GR6172@leitl.org> Message-ID: <33442.1363350547@turing-police.cc.vt.edu> On Fri, 15 Mar 2013 11:02:29 +0100, you said: > The DIYbio community is perfectly harmless so far. The feds are > already breathing down their necks, so there's no really no point > in adding gratuitious gasoline to the fire. "The Feds" have jurisdiction in Yemen, North Korea, Iran, and other places like that? That's a relief, I'm glad to see we've actually got a way to stop those places that engage in constant sabre-rattling.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wesley.george at twcable.com Fri Mar 15 12:46:59 2013 From: wesley.george at twcable.com (George, Wes) Date: Fri, 15 Mar 2013 08:46:59 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <51427BC2.50904@mompl.net> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <51427BC2.50904@mompl.net> Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> > > > > But really: a power screwdriver, a bag of #2 bits, and a 12" extender > > are 85% of it. ;-) > > I mostly get by with just a screwdriver. Powered screwdrivers annoy the > hell out of me in almost all cases. [WEG] The rule of thumb for most places I've worked has been that power screwdrivers are only acceptable for *removing* screws, at least where the electronic contents of a datacenter are concerned. Using a power screwdriver to install/tighten machine screws carries a nasty risk of cross-threading, or stripping, or snapping the heads off of the screws on something important, leading to unrecoverable problems with expensive modules that you can no longer easily remove to replace when the need arises. And Mr. Murphy says that the one with the damaged screw will be the first to fail. But then, most decent power screwdrivers have a torque clutch with settings to prevent such things, and everyone always uses them properly, right? ;-) Wes George 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 adrian at olddog.co.uk Fri Mar 15 13:26:39 2013 From: adrian at olddog.co.uk (Adrian Farrel) Date: Fri, 15 Mar 2013 13:26:39 +0000 Subject: What do you have in your datacenters' toolbox? Message-ID: <60291.1363353999@olddog.co.uk> > > > But really: a power screwdriver, a bag of > > > #2 bits, and a 12" extender> > are 85% of it. ;-) > > > > I mostly get by with just a screwdriver. Powered > screwdrivers annoy the> hell out of me in almost all cases. > > [WEG] The rule of thumb for most places I've worked has been that power > screwdrivers are only acceptable for *removing* screws, at least where the > electronic contents of a datacenter are concerned. Using a power > screwdriver to install/tighten machine screws carries a nasty risk of > cross-threading, or stripping, or snapping the heads off of the screws on > something important, leading to unrecoverable problems with expensive > modules that you can no longer easily remove to replace when the need > arises. So you would recommend using a virtual screwdriver in the datacenter? Adrian From alter3d at alter3d.ca Fri Mar 15 13:30:14 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 15 Mar 2013 09:30:14 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <60291.1363353999@olddog.co.uk> References: <60291.1363353999@olddog.co.uk> Message-ID: <51432266.7030003@alter3d.ca> On 3/15/2013 9:26 AM, Adrian Farrel wrote: >>>> But really: a power screwdriver, a bag of >>>> #2 bits, and a 12" extender> > are 85% of it. ;-) >>> I mostly get by with just a screwdriver. Powered >> screwdrivers annoy the> hell out of me in almost all cases. >> >> [WEG] The rule of thumb for most places I've worked has been that power >> screwdrivers are only acceptable for *removing* screws, at least where the >> electronic contents of a datacenter are concerned. Using a power >> screwdriver to install/tighten machine screws carries a nasty risk of >> cross-threading, or stripping, or snapping the heads off of the screws on >> something important, leading to unrecoverable problems with expensive >> modules that you can no longer easily remove to replace when the need >> arises. > So you would recommend using a virtual screwdriver in the datacenter? > > Adrian No, obviously you take the government approach and just outsource all screw-related activities (including screwing up) to "the experts" (i.e. outside contractors). ;) - Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4431 bytes Desc: S/MIME Cryptographic Signature URL: From cfillekes at gmail.com Fri Mar 15 13:38:12 2013 From: cfillekes at gmail.com (C. A. Fillekes) Date: Fri, 15 Mar 2013 08:38:12 -0500 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <51427BC2.50904@mompl.net> <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> Message-ID: Given that you are stocking exactly one toolchest in a 3rd world country, and you only get one shot at it... Depending on your budget and how many people will have access to these tools, you might consider getting 2 or 3 of everything, and keeping the second and possibly third set under lock and key, and not telling anyone about its existence. Then, if something does go walkabout, and you have to get the 2nd set of something out, you have time to order a replacement for the first, and will still have a backup if the 2nd set goes walkabout before it arrives. This is not because people are dishonest. It is because people are forgetful. She says, having worked in 3rd world countries like...Texas and New Zealand. :( Oh, and one of those BIG lighted magnifying glasses that are bolted to your bench are very useful for reading the codes on boards and chips when it comes time to repair things, or check parts coming in the door. A soldering set. A nice Fluke voltmeter/ammeter. From uwcableguy at gmail.com Fri Mar 15 13:38:52 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 15 Mar 2013 08:38:52 -0500 Subject: What are y'all doing for CALEA compliance? Message-ID: What are you RENs out there doing for CALEA compliance? Is there actually any teeth to the law? Our systems guys have tried a product called 'Open CALEA' but the router and the server simply can't keep up with mirroring from a 10Gbps connection into a 1Gbps link. I'm no legal expert either....any lawyers on this list? Thanks for all the great advice. This is a great community! -ben From owen at delong.com Fri Mar 15 13:44:50 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Mar 2013 06:44:50 -0700 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <20130315121623.GG7580@haller.ws> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <20130315121623.GG7580@haller.ws> Message-ID: On Mar 15, 2013, at 5:16 AM, Patrick wrote: > On 2013-03-15 12:33, . wrote: >> Similary, maybe you need exploitability to have a internet. > > Exploitability = usability from a different perspective. > > Postel said "be conservative in what you do, be liberal in what you > accept", which seems like usability restated, and would QED this. Actually, it was "be conservative in what you send, liberal in what you accept." Small nit, but does change the meaning a bit in this context. Owen From nanog at haller.ws Fri Mar 15 13:53:22 2013 From: nanog at haller.ws (Patrick) Date: Fri, 15 Mar 2013 21:53:22 +0800 Subject: WW: Bruce Schneier on why security can't work Reply-To: In-Reply-To: References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <20130315121623.GG7580@haller.ws> Message-ID: <20130315135321.GH7580@haller.ws> On 2013-03-15 06:44, Owen DeLong wrote: > Actually, it was "be conservative in what you send, liberal in what you accept." Maybe you're thinking of another time/place, I was referring to: http://tools.ietf.org/html/rfc761 From owen at delong.com Fri Mar 15 13:53:24 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Mar 2013 06:53:24 -0700 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> Message-ID: <8119F951-BB12-4A54-8D8B-01AABFB47E5F@delong.com> > And there you have it :) > > Security obviously works thus far, in the sense, that so far, > government has been preserved -- there is not total chaos, in at least > most of the world, and people do not doubt if their life or property > will still exist the next day. > I'm not sure I would even put "government has been preserved" on the list of considerations for the success or failure of security. I would put "law and order", "governance and/or the process of governance" on the list, but especially in a post-911 world, the US Government has departed from those ideals to varying degrees. Do not get me wrong, I am not advocating radical revolution or saying that we should tear down the existing institutions. Merely that we should be careful in our default use of terminology and focus on what we really want to preserve. Ideally, we can restore the US government to its proper (and limited) function. (That does not mean eliminating government services and making it small enough to fit in our bedrooms, either.) I'm not supporting any of the current Washington agendas and parties. I'm fed up with all of them at this point and unless they start working on solving problems instead of posturing all the time, I won't be supporting ANY incumbents. > Abusing new technology faster doesn't trump the extreme smallness of > the numbers of truly bad actors, who have irrational thinking, would > like to end civilization, and the intersection between those and > those who have a viable method that would work + the right > resources/skill available, and a reasonable chance of success.... > astronomically small The bottom line is that any system of laws and/or governance depends entirely on voluntary compliance by the majority of the actors. > If in a few decades, there is a 0.1% chance per decade of a > script kiddie ending civilization, I think we've got few reasonable > alternatives but to accept that risk and hope for the best :) On the other hand, I will hold up the U.S.A.P.A.T.R.I.O.T. act and the T.S.A. as proof that we are rather adept at exploring and sometimes acting on the unreasonable alternatives. Owen From jgreco at ns.sol.net Fri Mar 15 13:58:17 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 15 Mar 2013 08:58:17 -0500 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <51427BC2.50904@mompl.net> <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> Message-ID: <20130315135817.GA45034@aurora.sol.net> On Fri, Mar 15, 2013 at 08:46:59AM -0400, George, Wes wrote: > > > > > > But really: a power screwdriver, a bag of #2 bits, and a 12" extender > > > are 85% of it. ;-) > > > > I mostly get by with just a screwdriver. Powered screwdrivers annoy the > > hell out of me in almost all cases. > > [WEG] The rule of thumb for most places I've worked has been that power screwdrivers are only acceptable for *removing* screws, at least where the electronic contents of a datacenter are concerned. Using a power screwdriver to install/tighten machine screws carries a nasty risk of cross-threading, or stripping, or snapping the heads off of the screws on something important, leading to unrecoverable problems with expensive modules that you can no longer easily remove to replace when the need arises. And Mr. Murphy says that the one with the damaged screw will be the first to fail. > > But then, most decent power screwdrivers have a torque clutch with settings to prevent such things, and everyone always uses them properly, right? ;-) Maybe it is just me, but a lot of the time when I hear people say "power screwdriver", they mean "cordless 18V drill in screwdriver mode" (often in the hands of someone not old enough to drink alcohol), which is a recipe for screw tightening disaster, and I certainly understand the resulting reluctance. We have a bunch of Milwaukee 6547-22's around here, they're a 2.4V two speed screwdriver with a torque clutch that's designed to be an assembly line worker's or electrician's screwdriver. While it is possible to generate damaging forces with this unit, generally the torque on high speed is fairly low, and it takes just a little training to show someone how to use a medium clutch setting and high speed (and a flick of the wrist at the end for just a little extra tightness if needed) as a way to handle most data center screw tasks. Once you replace all the drives in a 24-drive chassis (96 screws) you come to appreciate the perfect screw job every time. Once you multiply that times 9 servers per rack times however many racks, you'll never want to do it any other way. We combine the Milwaukee with a Senco Phillips #2 bit. The 9 inch long bit seems awkward until you've used it a few hours, when you suddenly figure out that you can actually SEE what you're working on and/or reach into ridiculously tight spots. Lightly magnetizing the tip creates an even more useful tool. ... 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 bryan at serverstack.com Fri Mar 15 14:28:40 2013 From: bryan at serverstack.com (Bryan Socha) Date: Fri, 15 Mar 2013 10:28:40 -0400 Subject: contact at tedata.net? Message-ID: Does anyone have a networking contact at tedata.net? It's come to my attention they are blocking some of the reserved addresses that are no longer reserved. Thanks, Bryan From morrowc.lists at gmail.com Fri Mar 15 15:06:22 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 15 Mar 2013 11:06:22 -0400 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: Message-ID: On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch wrote: > What are you RENs out there doing for CALEA compliance? Is there actually being happy we solved it 6 yrs ago? > any teeth to the law? Our systems guys have tried a product called 'Open teeth as in the 100k/day fine? > CALEA' but the router and the server simply can't keep up with mirroring > from a 10Gbps connection into a 1Gbps link. I'm no legal expert that seems like a suboptimal design ... why would you mirror 10lbs of poo into a 1lb bag? that seems like it's bound to fail from the get-go. > either....any lawyers on this list? you should find a lawyer... srsly. > Thanks for all the great advice. This is a great community! -chris From jfmezei_nanog at vaxination.ca Fri Mar 15 15:20:13 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 15 Mar 2013 11:20:13 -0400 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <51427BC2.50904@mompl.net> <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> Message-ID: <51433C2D.7010103@vaxination.ca> On 13-03-15 08:46, George, Wes wrote: > [WEG] The rule of thumb for most places I've worked has been that power screwdrivers > are only acceptable for *removing* screws, at least where the electronic contents of a > datacenter are concerned. I can see the need for speed & efficiency when actually building a data centre of the scope Google builds with thousands of servers, racks everywhere etc. During the assembly stage, you probably want expensive power screwdrivers to not only save time, but also achieve the right torque/tightness. And you would need many of them since you'd have many people assembling racks and mounting equipment on them. However, in a day-to-day operation at an established data centre, do you really need a power screwdriver ? You need to worry about mounting it on a wall near a plug so it is always available/charged. However, having a powered drill somwehere in the building is, of course, a good thing. From j at 2600hz.com Fri Mar 15 15:21:25 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Fri, 15 Mar 2013 15:21:25 +0000 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: , Message-ID: I am not a lawyer, this is not legal advice. If you make decisions about what you should be doing in your business based solely on emails from strangers you won't do well. Get a second opinion from a lawyer. This comes up about once every 6 months on the voice ops mailing list. If you are a CLEC and you are not CALEA compliant, you are in for a world of hurt. If you're a non-facilities based reseller this is open for interpretation, but many folks believe that if you don't have gear inside the carrier pops, you aren't subject to CALEA. In practice, who is and who isn't effected by CALEA is directly proportional to the number of CALEA requests to your network (ergo, if you don't have any CALEA requests no one cares if you're out of compliance). That being said, there are further problems underfoot. CALEA does not specify what technologies should be used when presenting the data to law enforcement, I forget the exact wording but its something like "a reasonable format". CDRs are not sufficient as CALEA requires the ability to tap sessions, but in the past we've seen most legal requests placated with an excel sheet. As far as monitoring your connection, if your 10gig is coming in over fiber you should just buy a vampire tap and be done with it. I hope this helps, but CALEA is inherently messy. Cheers, Joshua Sent from my iPad On Mar 15, 2013, at 8:07 AM, "Christopher Morrow" wrote: > On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch wrote: >> What are you RENs out there doing for CALEA compliance? Is there actually > > being happy we solved it 6 yrs ago? > >> any teeth to the law? Our systems guys have tried a product called 'Open > > teeth as in the 100k/day fine? > >> CALEA' but the router and the server simply can't keep up with mirroring >> from a 10Gbps connection into a 1Gbps link. I'm no legal expert > > that seems like a suboptimal design ... why would you mirror 10lbs of > poo into a 1lb bag? that seems like it's bound to fail from the > get-go. > >> either....any lawyers on this list? > > you should find a lawyer... srsly. > >> Thanks for all the great advice. This is a great community! > > -chris > From wbailey at satelliteintelligencegroup.com Fri Mar 15 15:29:35 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 15 Mar 2013 15:29:35 +0000 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: , , Message-ID: We used 7206vxr with the lawful intercept mib, and some DPI jazz from Palo Alto. Worked okay, never did have to execute a warrant or anything. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Joshua Goldbard Date: 03/15/2013 8:25 AM (GMT-08:00) To: Christopher Morrow Cc: NANOG Subject: Re: What are y'all doing for CALEA compliance? I am not a lawyer, this is not legal advice. If you make decisions about what you should be doing in your business based solely on emails from strangers you won't do well. Get a second opinion from a lawyer. This comes up about once every 6 months on the voice ops mailing list. If you are a CLEC and you are not CALEA compliant, you are in for a world of hurt. If you're a non-facilities based reseller this is open for interpretation, but many folks believe that if you don't have gear inside the carrier pops, you aren't subject to CALEA. In practice, who is and who isn't effected by CALEA is directly proportional to the number of CALEA requests to your network (ergo, if you don't have any CALEA requests no one cares if you're out of compliance). That being said, there are further problems underfoot. CALEA does not specify what technologies should be used when presenting the data to law enforcement, I forget the exact wording but its something like "a reasonable format". CDRs are not sufficient as CALEA requires the ability to tap sessions, but in the past we've seen most legal requests placated with an excel sheet. As far as monitoring your connection, if your 10gig is coming in over fiber you should just buy a vampire tap and be done with it. I hope this helps, but CALEA is inherently messy. Cheers, Joshua Sent from my iPad On Mar 15, 2013, at 8:07 AM, "Christopher Morrow" wrote: > On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch wrote: >> What are you RENs out there doing for CALEA compliance? Is there actually > > being happy we solved it 6 yrs ago? > >> any teeth to the law? Our systems guys have tried a product called 'Open > > teeth as in the 100k/day fine? > >> CALEA' but the router and the server simply can't keep up with mirroring >> from a 10Gbps connection into a 1Gbps link. I'm no legal expert > > that seems like a suboptimal design ... why would you mirror 10lbs of > poo into a 1lb bag? that seems like it's bound to fail from the > get-go. > >> either....any lawyers on this list? > > you should find a lawyer... srsly. > >> Thanks for all the great advice. This is a great community! > > -chris > From j at 2600hz.com Fri Mar 15 15:32:26 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Fri, 15 Mar 2013 15:32:26 +0000 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: , , , Message-ID: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> God I want one of those PA firewalls just to play with in the lab. I can't justify the expense, but as far as firewalls go they're gorgeous. From the chassis to the UI, PA is just doing it right. If anyone has a different experience, I'd love to hear it. Sent from my iPad On Mar 15, 2013, at 8:29 AM, "Warren Bailey" > wrote: We used 7206vxr with the lawful intercept mib, and some DPI jazz from Palo Alto. Worked okay, never did have to execute a warrant or anything. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Joshua Goldbard > Date: 03/15/2013 8:25 AM (GMT-08:00) To: Christopher Morrow > Cc: NANOG > Subject: Re: What are y'all doing for CALEA compliance? I am not a lawyer, this is not legal advice. If you make decisions about what you should be doing in your business based solely on emails from strangers you won't do well. Get a second opinion from a lawyer. This comes up about once every 6 months on the voice ops mailing list. If you are a CLEC and you are not CALEA compliant, you are in for a world of hurt. If you're a non-facilities based reseller this is open for interpretation, but many folks believe that if you don't have gear inside the carrier pops, you aren't subject to CALEA. In practice, who is and who isn't effected by CALEA is directly proportional to the number of CALEA requests to your network (ergo, if you don't have any CALEA requests no one cares if you're out of compliance). That being said, there are further problems underfoot. CALEA does not specify what technologies should be used when presenting the data to law enforcement, I forget the exact wording but its something like "a reasonable format". CDRs are not sufficient as CALEA requires the ability to tap sessions, but in the past we've seen most legal requests placated with an excel sheet. As far as monitoring your connection, if your 10gig is coming in over fiber you should just buy a vampire tap and be done with it. I hope this helps, but CALEA is inherently messy. Cheers, Joshua Sent from my iPad On Mar 15, 2013, at 8:07 AM, "Christopher Morrow" > wrote: > On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch > wrote: >> What are you RENs out there doing for CALEA compliance? Is there actually > > being happy we solved it 6 yrs ago? > >> any teeth to the law? Our systems guys have tried a product called 'Open > > teeth as in the 100k/day fine? > >> CALEA' but the router and the server simply can't keep up with mirroring >> from a 10Gbps connection into a 1Gbps link. I'm no legal expert > > that seems like a suboptimal design ... why would you mirror 10lbs of > poo into a 1lb bag? that seems like it's bound to fail from the > get-go. > >> either....any lawyers on this list? > > you should find a lawyer... srsly. > >> Thanks for all the great advice. This is a great community! > > -chris > From morrowc.lists at gmail.com Fri Mar 15 15:35:18 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 15 Mar 2013 11:35:18 -0400 Subject: What are y'all doing for CALEA compliance? In-Reply-To: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> References: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> Message-ID: On Fri, Mar 15, 2013 at 11:32 AM, Joshua Goldbard wrote: > God I want one of those PA firewalls just to play with in the lab. I can't > justify the expense, but as far as firewalls go they're gorgeous. From the > chassis to the UI, PA is just doing it right. > > If anyone has a different experience, I'd love to hear it. for any firewall/appliance .. ask this: "How can I manage 200 of these things remotely" UI is pretty and nice and cool.. but utterly useless if you have more than 1 of the things. also, a firewall is a firewall is a firewall... they all do the basics (nat/filter/'proxy') nothing else in that category really matters... management matters. > > Sent from my iPad > > On Mar 15, 2013, at 8:29 AM, "Warren Bailey" > wrote: > > We used 7206vxr with the lawful intercept mib, and some DPI jazz from Palo > Alto. Worked okay, never did have to execute a warrant or anything. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Joshua Goldbard > Date: 03/15/2013 8:25 AM (GMT-08:00) > To: Christopher Morrow > Cc: NANOG > Subject: Re: What are y'all doing for CALEA compliance? > > > I am not a lawyer, this is not legal advice. If you make decisions about > what you should be doing in your business based solely on emails from > strangers you won't do well. Get a second opinion from a lawyer. > > This comes up about once every 6 months on the voice ops mailing list. If > you are a CLEC and you are not CALEA compliant, you are in for a world of > hurt. > > If you're a non-facilities based reseller this is open for interpretation, > but many folks believe that if you don't have gear inside the carrier pops, > you aren't subject to CALEA. In practice, who is and who isn't effected by > CALEA is directly proportional to the number of CALEA requests to your > network (ergo, if you don't have any CALEA requests no one cares if you're > out of compliance). > > That being said, there are further problems underfoot. CALEA does not > specify what technologies should be used when presenting the data to law > enforcement, I forget the exact wording but its something like "a reasonable > format". CDRs are not sufficient as CALEA requires the ability to tap > sessions, but in the past we've seen most legal requests placated with an > excel sheet. > > As far as monitoring your connection, if your 10gig is coming in over fiber > you should just buy a vampire tap and be done with it. > > I hope this helps, but CALEA is inherently messy. > > Cheers, > Joshua > > Sent from my iPad > > On Mar 15, 2013, at 8:07 AM, "Christopher Morrow" > wrote: > >> On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch wrote: >>> What are you RENs out there doing for CALEA compliance? Is there >>> actually >> >> being happy we solved it 6 yrs ago? >> >>> any teeth to the law? Our systems guys have tried a product called 'Open >> >> teeth as in the 100k/day fine? >> >>> CALEA' but the router and the server simply can't keep up with mirroring >>> from a 10Gbps connection into a 1Gbps link. I'm no legal expert >> >> that seems like a suboptimal design ... why would you mirror 10lbs of >> poo into a 1lb bag? that seems like it's bound to fail from the >> get-go. >> >>> either....any lawyers on this list? >> >> you should find a lawyer... srsly. >> >>> Thanks for all the great advice. This is a great community! >> >> -chris >> > > From wbailey at satelliteintelligencegroup.com Fri Mar 15 15:36:00 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 15 Mar 2013 15:36:00 +0000 Subject: What are y'all doing for CALEA compliance? In-Reply-To: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> References: , , , , <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> Message-ID: Seemed legit to me. I'm a satellite guy, so the Palo Alto gear was really for me to look at the traffic profiles. They did a killer job classifying traffic though, and I guess they update the rules every couple days? >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Joshua Goldbard Date: 03/15/2013 8:33 AM (GMT-08:00) To: Warren Bailey Cc: Christopher Morrow ,NANOG Subject: Re: What are y'all doing for CALEA compliance? God I want one of those PA firewalls just to play with in the lab. I can't justify the expense, but as far as firewalls go they're gorgeous. From the chassis to the UI, PA is just doing it right. If anyone has a different experience, I'd love to hear it. Sent from my iPad On Mar 15, 2013, at 8:29 AM, "Warren Bailey" > wrote: We used 7206vxr with the lawful intercept mib, and some DPI jazz from Palo Alto. Worked okay, never did have to execute a warrant or anything. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Joshua Goldbard > Date: 03/15/2013 8:25 AM (GMT-08:00) To: Christopher Morrow > Cc: NANOG > Subject: Re: What are y'all doing for CALEA compliance? I am not a lawyer, this is not legal advice. If you make decisions about what you should be doing in your business based solely on emails from strangers you won't do well. Get a second opinion from a lawyer. This comes up about once every 6 months on the voice ops mailing list. If you are a CLEC and you are not CALEA compliant, you are in for a world of hurt. If you're a non-facilities based reseller this is open for interpretation, but many folks believe that if you don't have gear inside the carrier pops, you aren't subject to CALEA. In practice, who is and who isn't effected by CALEA is directly proportional to the number of CALEA requests to your network (ergo, if you don't have any CALEA requests no one cares if you're out of compliance). That being said, there are further problems underfoot. CALEA does not specify what technologies should be used when presenting the data to law enforcement, I forget the exact wording but its something like "a reasonable format". CDRs are not sufficient as CALEA requires the ability to tap sessions, but in the past we've seen most legal requests placated with an excel sheet. As far as monitoring your connection, if your 10gig is coming in over fiber you should just buy a vampire tap and be done with it. I hope this helps, but CALEA is inherently messy. Cheers, Joshua Sent from my iPad On Mar 15, 2013, at 8:07 AM, "Christopher Morrow" > wrote: > On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch > wrote: >> What are you RENs out there doing for CALEA compliance? Is there actually > > being happy we solved it 6 yrs ago? > >> any teeth to the law? Our systems guys have tried a product called 'Open > > teeth as in the 100k/day fine? > >> CALEA' but the router and the server simply can't keep up with mirroring >> from a 10Gbps connection into a 1Gbps link. I'm no legal expert > > that seems like a suboptimal design ... why would you mirror 10lbs of > poo into a 1lb bag? that seems like it's bound to fail from the > get-go. > >> either....any lawyers on this list? > > you should find a lawyer... srsly. > >> Thanks for all the great advice. This is a great community! > > -chris > From eesslinger at fpu-tn.com Fri Mar 15 15:44:18 2013 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Fri, 15 Mar 2013 10:44:18 -0500 Subject: What do you have in your datacenters' toolbox? In-Reply-To: <51433C2D.7010103@vaxination.ca> References: <6063075.9210.1362926000931.JavaMail.root@benjamin.baylink.com> <51427BC2.50904@mompl.net> <2671C6CDFBB59E47B64C10B3E0BD5923041F865DE7@PRVPEXVS15.corp.twcable.com> <51433C2D.7010103@vaxination.ca> Message-ID: <489EAE655F69A246A2CBF4197BFD2511178480BA@exchange.corp.fpu-tn.com> > -----Original Message----- > From: Jean-Francois Mezei [mailto:jfmezei_nanog at vaxination.ca] > Sent: Friday, March 15, 2013 10:20 AM > To: nanog at nanog.org > Subject: Re: What do you have in your datacenters' toolbox? > > On 13-03-15 08:46, George, Wes wrote: > > > [WEG] The rule of thumb for most places I've worked has been that > > power screwdrivers are only acceptable for *removing* screws, at least > > where the electronic contents of a datacenter are concerned. > > I can see the need for speed & efficiency when actually building a data centre > of the scope Google builds with thousands of servers, racks everywhere etc. > During the assembly stage, you probably want expensive power > screwdrivers to not only save time, but also achieve the right > torque/tightness. And you would need many of them since you'd have many > people assembling racks and mounting equipment on them. > > However, in a day-to-day operation at an established data centre, do you > really need a power screwdriver ? You need to worry about mounting it on a > wall near a plug so it is always available/charged. > > However, having a powered drill somwehere in the building is, of course, a > good thing. > I have a power screwdriver I use for both in and out. Otoh for screwing things in I always have it on the lowest torque-clutch setting. If that won't get it how I like it I use the manual screwdriver. ------------------------------------- Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpunet.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From cscora at apnic.net Fri Mar 15 18:33:34 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Mar 2013 04:33:34 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201303151833.r2FIXYXB024695@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Mar, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 446141 Prefixes after maximum aggregation: 183411 Deaggregation factor: 2.43 Unique aggregates announced to Internet: 219000 Total ASes present in the Internet Routing Table: 43592 Prefixes per ASN: 10.23 Origin-only ASes present in the Internet Routing Table: 34340 Origin ASes announcing only one prefix: 16000 Transit ASes present in the Internet Routing Table: 5778 Transit-only ASes present in the Internet Routing Table: 138 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 365 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 4617 Number of 32-bit ASNs visible in the Routing Table: 3474 Prefixes from 32-bit ASNs in the Routing Table: 9765 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 193 Number of addresses announced to Internet: 2622922540 Equivalent to 156 /8s, 86 /16s and 159 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.3 Total number of prefixes smaller than registry allocations: 157616 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 107214 Total APNIC prefixes after maximum aggregation: 33202 APNIC Deaggregation factor: 3.23 Prefixes being announced from the APNIC address blocks: 108369 Unique aggregates announced from the APNIC address blocks: 44091 APNIC Region origin ASes present in the Internet Routing Table: 4822 APNIC Prefixes per ASN: 22.47 APNIC Region origin ASes announcing only one prefix: 1236 APNIC Region transit ASes present in the Internet Routing Table: 813 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 463 Number of APNIC addresses announced to Internet: 719165984 Equivalent to 42 /8s, 221 /16s and 154 /24s Percentage of available APNIC address space announced: 84.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 156902 Total ARIN prefixes after maximum aggregation: 79295 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 157573 Unique aggregates announced from the ARIN address blocks: 71631 ARIN Region origin ASes present in the Internet Routing Table: 15548 ARIN Prefixes per ASN: 10.13 ARIN Region origin ASes announcing only one prefix: 5877 ARIN Region transit ASes present in the Internet Routing Table: 1605 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1078444672 Equivalent to 64 /8s, 71 /16s and 194 /24s Percentage of available ARIN address space announced: 57.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 114320 Total RIPE prefixes after maximum aggregation: 59078 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 117687 Unique aggregates announced from the RIPE address blocks: 75598 RIPE Region origin ASes present in the Internet Routing Table: 17108 RIPE Prefixes per ASN: 6.88 RIPE Region origin ASes announcing only one prefix: 8160 RIPE Region transit ASes present in the Internet Routing Table: 2797 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2235 Number of RIPE addresses announced to Internet: 654497124 Equivalent to 39 /8s, 2 /16s and 213 /24s Percentage of available RIPE address space announced: 95.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47191 Total LACNIC prefixes after maximum aggregation: 9353 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 51088 Unique aggregates announced from the LACNIC address blocks: 23778 LACNIC Region origin ASes present in the Internet Routing Table: 1867 LACNIC Prefixes per ASN: 27.36 LACNIC Region origin ASes announcing only one prefix: 546 LACNIC Region transit ASes present in the Internet Routing Table: 346 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 751 Number of LACNIC addresses announced to Internet: 124810280 Equivalent to 7 /8s, 112 /16s and 116 /24s Percentage of available LACNIC address space announced: 74.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10622 Total AfriNIC prefixes after maximum aggregation: 2433 AfriNIC Deaggregation factor: 4.37 Prefixes being announced from the AfriNIC address blocks: 11231 Unique aggregates announced from the AfriNIC address blocks: 3727 AfriNIC Region origin ASes present in the Internet Routing Table: 606 AfriNIC Prefixes per ASN: 18.53 AfriNIC Region origin ASes announcing only one prefix: 181 AfriNIC Region transit ASes present in the Internet Routing Table: 130 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 45651456 Equivalent to 2 /8s, 184 /16s and 150 /24s Percentage of available AfriNIC address space announced: 45.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2925 11558 922 Korea Telecom (KIX) 17974 2504 840 86 PT TELEKOMUNIKASI INDONESIA 7545 1833 301 89 TPG Internet Pty Ltd 4755 1719 392 196 TATA Communications formerly 9829 1450 1157 42 BSNL National Internet Backbo 9583 1287 98 535 Sify Limited 7552 1161 1070 12 Vietel Corporation 4808 1116 2054 321 CNCGROUP IP network: China169 9498 1067 310 75 BHARTI Airtel Ltd. 24560 1058 385 161 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3042 3695 94 bellsouth.net, inc. 7029 2229 1266 215 Windstream Communications Inc 18566 2081 382 185 Covad Communications 22773 1995 2929 125 Cox Communications, Inc. 1785 1959 677 123 PaeTec Communications, Inc. 20115 1681 1611 623 Charter Communications 4323 1613 1139 401 Time Warner Telecom 30036 1334 293 690 Mediacom Communications Corp 7018 1306 10809 852 AT&T WorldNet Services 11492 1210 222 329 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1869 544 16 Corbina telecom 2118 1116 97 13 EUnet/RELCOM Autonomous Syste 34984 1105 233 204 BILISIM TELEKOM 12479 840 786 66 Uni2 Autonomous System 13188 839 99 30 Educational Network 20940 791 275 627 Akamai Technologies European 31148 776 40 20 FreeNet ISP 6830 715 2314 436 UPC Distribution Services 8551 714 370 43 Bezeq International 58113 664 73 386 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2421 1335 88 NET Servicos de Comunicao S.A 10620 2352 405 232 TVCABLE BOGOTA 7303 1672 1148 208 Telecom Argentina Stet-France 8151 1344 2722 393 UniNet S.A. de C.V. 6503 1155 434 66 AVANTEL, S.A. 14754 944 128 86 Telgua S. A. 18881 829 716 18 Global Village Telecom 27947 790 87 99 Telconet S.A 3816 690 306 85 Empresa Nacional de Telecomun 7738 650 1306 35 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 894 274 34 LINKdotNET AS number 6713 535 615 23 Itissalat Al-MAGHRIB 8452 510 958 13 TEDATA 24835 342 80 8 RAYA Telecom - Egypt 3741 262 906 220 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 190 698 88 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3042 3695 94 bellsouth.net, inc. 4766 2925 11558 922 Korea Telecom (KIX) 17974 2504 840 86 PT TELEKOMUNIKASI INDONESIA 28573 2421 1335 88 NET Servicos de Comunicao S.A 10620 2352 405 232 TVCABLE BOGOTA 7029 2229 1266 215 Windstream Communications Inc 18566 2081 382 185 Covad Communications 22773 1995 2929 125 Cox Communications, Inc. 1785 1959 677 123 PaeTec Communications, Inc. 8402 1869 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2504 2418 PT TELEKOMUNIKASI INDONESIA 28573 2421 2333 NET Servicos de Comunicao S.A 10620 2352 2120 TVCABLE BOGOTA 7029 2229 2014 Windstream Communications Inc 4766 2925 2003 Korea Telecom (KIX) 18566 2081 1896 Covad Communications 22773 1995 1870 Cox Communications, Inc. 8402 1869 1853 Corbina telecom 1785 1959 1836 PaeTec Communications, Inc. 7545 1833 1744 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 mywire Datentechnik GmbH Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:13 /10:29 /11:88 /12:248 /13:483 /14:872 /15:1563 /16:12651 /17:6623 /18:10871 /19:21727 /20:31631 /21:33541 /22:46032 /23:41585 /24:233871 /25:1382 /26:1765 /27:858 /28:181 /29:73 /30:17 /31:0 /32:20 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2031 2081 Covad Communications 6389 1745 3042 bellsouth.net, inc. 7029 1609 2229 Windstream Communications Inc 8402 1591 1869 Corbina telecom 22773 1306 1995 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1217 1334 Mediacom Communications Corp 11492 1172 1210 Cable One 1785 1039 1959 PaeTec Communications, Inc. 7011 950 1198 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:722 2:789 3:3 4:13 5:704 6:3 8:509 12:1932 13:3 14:757 15:11 16:3 17:8 20:24 23:239 24:1799 27:1415 31:1178 32:44 33:2 34:5 36:27 37:1434 38:860 39:2 40:159 41:2725 42:177 44:4 46:1746 47:2 49:610 50:664 52:12 54:28 55:10 57:28 58:1091 59:579 60:297 61:1386 62:1001 63:2042 64:4297 65:2175 66:4271 67:2055 68:1110 69:3266 70:881 71:523 72:1898 74:2558 75:400 76:288 77:1087 78:1027 79:575 80:1236 81:976 82:644 83:558 84:559 85:1165 86:473 87:948 88:381 89:1771 90:262 91:5427 92:614 93:1714 94:1865 95:1549 96:497 97:336 98:1050 99:41 100:29 101:307 103:2284 105:517 106:131 107:207 108:515 109:1810 110:846 111:1037 112:496 113:766 114:690 115:973 116:877 117:806 118:997 119:1268 120:377 121:781 122:1734 123:1189 124:1324 125:1315 128:544 129:221 130:323 131:648 132:333 133:143 134:256 135:60 136:221 137:241 138:343 139:179 140:199 141:312 142:532 143:371 144:489 145:89 146:522 147:356 148:703 149:357 150:157 151:449 152:411 153:196 154:32 155:379 156:250 157:392 158:266 159:714 160:335 161:425 162:376 163:206 164:580 165:454 166:394 167:573 168:1017 169:130 170:1023 171:168 172:4 173:1588 174:574 175:434 176:1182 177:1814 178:1772 179:1 180:1380 181:280 182:1200 183:341 184:661 185:294 186:2351 187:1263 188:1921 189:1419 190:6616 192:6407 193:5675 194:4519 195:3470 196:1305 197:890 198:4203 199:5238 200:6017 201:2241 202:8918 203:8711 204:4499 205:2579 206:2785 207:2803 208:4072 209:3546 210:2913 211:1552 212:1999 213:1938 214:917 215:96 216:5190 217:1587 218:605 219:337 220:1263 221:538 222:312 223:482 End of report From uwcableguy at gmail.com Fri Mar 15 19:21:03 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Fri, 15 Mar 2013 14:21:03 -0500 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: <334894CC-2A43-4287-AE24-48412F28BA9E@2600hz.com> Message-ID: Thanks to everyone who replied on and off list today. I found a wide range of opinions on CALEA. I did have one person give me a very specific example of a vendor that can ensure compliance, which is really what I was after. See y'all on Bourbon Street in June! -ben On Fri, Mar 15, 2013 at 10:36 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Seemed legit to me. I'm a satellite guy, so the Palo Alto gear was really > for me to look at the traffic profiles. They did a killer job classifying > traffic though, and I guess they update the rules every couple days? > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Joshua Goldbard > Date: 03/15/2013 8:33 AM (GMT-08:00) > To: Warren Bailey > Cc: Christopher Morrow ,NANOG > Subject: Re: What are y'all doing for CALEA compliance? > > > God I want one of those PA firewalls just to play with in the lab. I can't > justify the expense, but as far as firewalls go they're gorgeous. From the > chassis to the UI, PA is just doing it right. > > If anyone has a different experience, I'd love to hear it. > > Sent from my iPad > > On Mar 15, 2013, at 8:29 AM, "Warren Bailey" < > wbailey at satelliteintelligencegroup.com wbailey at satelliteintelligencegroup.com>> wrote: > > We used 7206vxr with the lawful intercept mib, and some DPI jazz from Palo > Alto. Worked okay, never did have to execute a warrant or anything. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Joshua Goldbard > > Date: 03/15/2013 8:25 AM (GMT-08:00) > To: Christopher Morrow morrowc.lists at gmail.com>> > Cc: NANOG > > Subject: Re: What are y'all doing for CALEA compliance? > > > I am not a lawyer, this is not legal advice. If you make decisions about > what you should be doing in your business based solely on emails from > strangers you won't do well. Get a second opinion from a lawyer. > > This comes up about once every 6 months on the voice ops mailing list. If > you are a CLEC and you are not CALEA compliant, you are in for a world of > hurt. > > If you're a non-facilities based reseller this is open for interpretation, > but many folks believe that if you don't have gear inside the carrier pops, > you aren't subject to CALEA. In practice, who is and who isn't effected by > CALEA is directly proportional to the number of CALEA requests to your > network (ergo, if you don't have any CALEA requests no one cares if you're > out of compliance). > > That being said, there are further problems underfoot. CALEA does not > specify what technologies should be used when presenting the data to law > enforcement, I forget the exact wording but its something like "a > reasonable format". CDRs are not sufficient as CALEA requires the ability > to tap sessions, but in the past we've seen most legal requests placated > with an excel sheet. > > As far as monitoring your connection, if your 10gig is coming in over > fiber you should just buy a vampire tap and be done with it. > > I hope this helps, but CALEA is inherently messy. > > Cheers, > Joshua > > Sent from my iPad > > On Mar 15, 2013, at 8:07 AM, "Christopher Morrow" > wrote: > > > On Fri, Mar 15, 2013 at 9:38 AM, Ben Bartsch > wrote: > >> What are you RENs out there doing for CALEA compliance? Is there > actually > > > > being happy we solved it 6 yrs ago? > > > >> any teeth to the law? Our systems guys have tried a product called > 'Open > > > > teeth as in the 100k/day fine? > > > >> CALEA' but the router and the server simply can't keep up with mirroring > >> from a 10Gbps connection into a 1Gbps link. I'm no legal expert > > > > that seems like a suboptimal design ... why would you mirror 10lbs of > > poo into a 1lb bag? that seems like it's bound to fail from the > > get-go. > > > >> either....any lawyers on this list? > > > > you should find a lawyer... srsly. > > > >> Thanks for all the great advice. This is a great community! > > > > -chris > > > > > From cidr-report at potaroo.net Fri Mar 15 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Mar 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201303152200.r2FM00s3068952@wattle.apnic.net> This report has been generated at Fri Mar 15 21:13:27 2013 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-03-13 445961 255148 09-03-13 445720 255598 10-03-13 445720 255627 11-03-13 445720 256541 12-03-13 445720 256729 13-03-13 445720 256018 14-03-13 448180 256847 15-03-13 448211 257312 AS Summary 43687 Number of ASes in routing system 18100 Number of ASes announcing only one prefix 3041 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116945632 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'). --- 15Mar13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 448690 257292 191398 42.7% All ASes AS6389 3041 97 2944 96.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS17974 2504 499 2005 80.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2925 939 1986 67.9% KIXS-AS-KR Korea Telecom AS28573 2421 556 1865 77.0% NET Servi?os de Comunica??o S.A. AS10620 2352 691 1661 70.6% Telmex Colombia S.A. AS18566 2081 427 1654 79.5% COVAD - Covad Communications Co. AS4755 1719 235 1484 86.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1672 412 1260 75.4% Telecom Argentina S.A. AS4323 1616 405 1211 74.9% TWTC - tw telecom holdings, inc. AS2118 1116 83 1033 92.6% RELCOM-AS OOO "NPO Relcom" AS7029 2229 1270 959 43.0% WINDSTREAM - Windstream Communications Inc AS7552 1161 210 951 81.9% VIETEL-AS-AP Vietel Corporation AS7545 1841 911 930 50.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1009 172 837 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS22773 1995 1166 829 41.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18881 829 20 809 97.6% Global Village Telecom AS1785 1959 1188 771 39.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1116 357 759 68.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS14754 945 210 735 77.8% Telgua AS13977 835 126 709 84.9% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 712 50 662 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1358 698 660 48.6% Uninet S.A. de C.V. AS24560 1058 415 643 60.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22561 1077 450 627 58.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 724 101 623 86.0% GIGAINFRA Softbank BB Corp. AS3549 1045 444 601 57.5% GBLX Global Crossing Ltd. AS3356 1097 499 598 54.5% LEVEL3 Level 3 Communications AS19262 991 402 589 59.4% VZGNI-TRANSIT - Verizon Online LLC AS20115 1681 1109 572 34.0% CHARTER-NET-HKY-NC - Charter Communications Total 46395 14523 31872 68.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.124.252.0/22 AS7303 Telecom Argentina S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 UOL DIVEO S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 QLINK TELECOMUNICACOES E INTERNET LTDA 201.77.96.0/20 AS28639 Econocell do Brasil Ltda 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 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.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. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 15 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Mar 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201303152200.r2FM026p068979@wattle.apnic.net> BGP Update Report Interval: 13-Mar-13 -to- 14-Mar-13 (1 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 19915 11.7% 41.5 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS35567 6856 4.0% 342.8 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 3 - AS2708 5161 3.0% 67.0 -- Universidad de Guanajuato 4 - AS23947 4998 2.9% 125.0 -- MORATELINDONAP-AS-ID PT.Mora Telematika Indonesia 5 - AS8402 4190 2.5% 14.1 -- CORBINA-AS OJSC "Vimpelcom" 6 - AS11992 3705 2.2% 21.2 -- CENTENNIAL-PR - Centennial de Puerto Rico 7 - AS3909 3555 2.1% 888.8 -- QWEST-AS-3908 - Qwest Communications Company, LLC 8 - AS13897 2722 1.6% 1361.0 -- CDC1 - Internet Brands Inc. 9 - AS14420 2086 1.2% 37.9 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 10 - AS58113 2074 1.2% 3.1 -- LIR-AS LIR DATACENTER TELECOM SRL 11 - AS14754 2008 1.2% 5.2 -- Telgua 12 - AS9198 1923 1.1% 17.6 -- KAZTELECOM-AS JSC Kazakhtelecom 13 - AS647 1912 1.1% 21.7 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 14 - AS37004 1666 1.0% 79.3 -- SUBURBAN-AS 15 - AS34533 1642 1.0% 15.6 -- ESAMARA-AS CJSC "ER-Telecom Holding" 16 - AS25620 1566 0.9% 38.2 -- COTAS LTDA. 17 - AS15964 1529 0.9% 63.7 -- CAMNET-AS 18 - AS45769 1521 0.9% 23.4 -- DVOIS-IN D-Vois Broadband Pvt Ltd 19 - AS19361 1481 0.9% 43.6 -- A.Telecom S.A. 20 - AS18004 1340 0.8% 21.3 -- WIRELESSNET-ID-AP WIRELESSNET AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13897 2722 1.6% 1361.0 -- CDC1 - Internet Brands Inc. 2 - AS6629 1129 0.7% 1129.0 -- NOAA-AS - NOAA 3 - AS9854 968 0.6% 968.0 -- KTO-AS-KR KTO 4 - AS3909 3555 2.1% 888.8 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - AS14680 727 0.4% 727.0 -- REALE-6 - Auction.com 6 - AS1273 685 0.4% 685.0 -- CW Cable and Wireless Worldwide plc 7 - AS9950 622 0.4% 622.0 -- PUBNETPLUS2-AS-KR DACOM 8 - AS19406 613 0.4% 613.0 -- TWRS-MA - Towerstream I, Inc. 9 - AS1880 951 0.6% 475.5 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 10 - AS6174 836 0.5% 418.0 -- SPRINTLINK8 - Sprint 11 - AS37367 413 0.2% 413.0 -- CALLKEY 12 - AS5074 699 0.4% 349.5 -- ASN-ATTELS - AT&T BMGS 13 - AS35567 6856 4.0% 342.8 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 14 - AS4467 339 0.2% 339.0 -- EASYLINK3 - AT&T Services, Inc. 15 - AS22140 238 0.1% 238.0 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 16 - AS36529 398 0.2% 199.0 -- AXXA-RACKCO - Rackco.com 17 - AS45298 194 0.1% 194.0 -- INTERLINK-TECH-AS-ID INTERLINK TECHNOLOGY, PT 18 - AS41023 194 0.1% 194.0 -- ARREKS-AS Agencja Rozwoju Regionalnego ARREKS S.A. 19 - AS46032 379 0.2% 189.5 -- GLOBENET-AS-ID Fastel Sarana Indonesia PT 20 - AS45770 188 0.1% 188.0 -- SBY-EPROC-AS-ID Bagian Bina Program - Pemerintah Kota Surabaya TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 98.158.204.0/23 1361 0.7% AS13897 -- CDC1 - Internet Brands Inc. 2 - 98.158.200.0/24 1361 0.7% AS13897 -- CDC1 - Internet Brands Inc. 3 - 151.118.255.0/24 1185 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 151.118.254.0/24 1185 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - 151.118.18.0/24 1176 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - 192.58.232.0/24 1129 0.6% AS6629 -- NOAA-AS - NOAA 7 - 211.178.9.64/26 968 0.5% AS9854 -- KTO-AS-KR KTO 8 - 192.108.213.0/24 916 0.5% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 9 - 12.139.133.0/24 727 0.4% AS14680 -- REALE-6 - Auction.com 10 - 194.63.9.0/24 685 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 11 - 58.184.229.0/24 622 0.3% AS9950 -- PUBNETPLUS2-AS-KR DACOM 12 - 69.38.178.0/24 613 0.3% AS19406 -- TWRS-MA - Towerstream I, Inc. 13 - 84.205.66.0/24 485 0.2% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC) 14 - 208.16.110.0/24 418 0.2% AS6174 -- SPRINTLINK8 - Sprint 15 - 206.105.75.0/24 418 0.2% AS6174 -- SPRINTLINK8 - Sprint 16 - 41.75.40.0/21 413 0.2% AS37367 -- CALLKEY 17 - 115.170.128.0/17 393 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 18 - 91.191.27.0/24 381 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 19 - 213.196.102.0/24 380 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. 20 - 91.191.47.0/24 379 0.2% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From hhoffman at ip-solutions.net Sat Mar 16 19:35:34 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sat, 16 Mar 2013 15:35:34 -0400 Subject: Verizon FIOS filtering? Message-ID: <5144C986.4000704@ip-solutions.net> Hi All, Does anyone know if Verizon automatically performs network filtering in response to scanning behavior? I'm having some weird connectivity issues to a host and trying to figure out why. Cheers, Harry From smb at cs.columbia.edu Sat Mar 16 22:09:50 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 16 Mar 2013 18:09:50 -0400 Subject: What are y'all doing for CALEA compliance? In-Reply-To: References: Message-ID: <1DF4C8BE-11E0-48F5-99CB-0C91E0DEC83D@cs.columbia.edu> On Mar 15, 2013, at 9:38 AM, Ben Bartsch wrote: > Is there actually any teeth to the law? Find a real lawyer and show her/him http://www.law.cornell.edu/uscode/text/18/2522 --Steve Bellovin, https://www.cs.columbia.edu/~smb From jlewis at lewis.org Sat Mar 16 22:24:00 2013 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 16 Mar 2013 18:24:00 -0400 (EDT) Subject: [c-nsp] DNS amplification In-Reply-To: <20130316212156.GA8034@ismet.erje.net> References: <20130316212156.GA8034@ismet.erje.net> Message-ID: On Sat, 16 Mar 2013, Robert Joosten wrote: > Hi, > >>> Can anyone provide insight into how to defeat DNS amplification attacks? >> Restrict resolvers to your customer networks. > > And deploy RPF uRPF / BCP38 is really the only solution. Even if we did close all the open recursion DNS servers (which is a good idea), the attackers would just shift to another protocol/service that provides amplification of traffic and can be aimed via spoofed source address packets. Going after DNS is playing whack-a-mole. DNS is the hip one right now. It's not the only one available. Many networks will say "but our gear doesn't do uRPF, and maintaining an ACL on every customer port is too hard / doesn't scale." Consider an alternative solution. On a typical small ISP / small service provider network, if you were to ACL every customer (because your gear won't do uRPF), you might need hundreds or even thousands of ACLs. However, if you were to put output filters on your transit connections, allowing traffic sourced from all IP networks "valid" inside your network, you might find that all you need is a single ACL of a handful to several dozen entries. Having one ACL to maintain that only needs changing if you get a new IP allocation or add/remove a customer who has their own IPs really isn't all that difficult. As far at the rest of the internet is concerned, this solves the issue of spoofed IP packets leaving your network. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sfischer1967 at gmail.com Sat Mar 16 23:40:16 2013 From: sfischer1967 at gmail.com (Steven Fischer) Date: Sat, 16 Mar 2013 19:40:16 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> Message-ID: yes - and it presumes your DNS servers are based on Linux and use IPTables. http://www.cryptonizer.com/dnsamp.html http://serverfault.com/questions/418810/public-facing-recursive-dns-servers-iptables-rules http://sf-alpha.bjgang.org/wordpress/2013/01/iptables-for-common-dns-amplification-attack-on-recursive-dns-inside-your-network/ these should give you a good idea of how to get started... On Sat, Mar 16, 2013 at 6:24 PM, Jon Lewis wrote: > On Sat, 16 Mar 2013, Robert Joosten wrote: > > Hi, >> >> Can anyone provide insight into how to defeat DNS amplification attacks? >>>> >>> Restrict resolvers to your customer networks. >>> >> >> And deploy RPF >> > > uRPF / BCP38 is really the only solution. Even if we did close all the > open recursion DNS servers (which is a good idea), the attackers would just > shift to another protocol/service that provides amplification of traffic > and can be aimed via spoofed source address packets. Going after DNS is > playing whack-a-mole. DNS is the hip one right now. It's not the only one > available. > > Many networks will say "but our gear doesn't do uRPF, and maintaining an > ACL on every customer port is too hard / doesn't scale." > > Consider an alternative solution. On a typical small ISP / small service > provider network, if you were to ACL every customer (because your gear > won't do uRPF), you might need hundreds or even thousands of ACLs. However, > if you were to put output filters on your transit connections, allowing > traffic sourced from all IP networks "valid" inside your network, you might > find that all you need is a single ACL of a handful to several dozen > entries. Having one ACL to maintain that only needs changing if you get a > new IP allocation or add/remove a customer who has their own IPs really > isn't all that difficult. As far at the rest of the internet is concerned, > this solves the issue of spoofed IP packets leaving your network. > > ------------------------------**------------------------------**---------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/**pgpfor PGP public key_________ > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From eugen at imacandi.net Sun Mar 17 15:04:12 2013 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 17 Mar 2013 17:04:12 +0200 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <8119F951-BB12-4A54-8D8B-01AABFB47E5F@delong.com> References: <9051372.9866.1363283782699.JavaMail.root@benjamin.baylink.com> <8119F951-BB12-4A54-8D8B-01AABFB47E5F@delong.com> Message-ID: The US law enforcement is getting closer and closer at being able to be DDoS-ed very effectively because of all of their advisories about "see something, say something" and all other scare tactics crap they come up with. I mean it's bad some guy shot up a lot of people in a theater or in a school, but now it's sufficient to call 911 and say you saw a guy with what looks like an assault riffle in a theater or school campus and the just grab a bucket of popcorn and see everyone panic and SWAT teams with guns blazing canvasing the objective. Do it in a coordinated fashion on a daily basis and bam: DDoS at it's finest. No one would take a chance to treat the calls as pranks because if they get it wrong only once, they will be in a very big s***storm. Not to talk about economic losses because once a day a mall gets evacuated for a few hours. The cost of pulling it off: none. 911 calls are free :)) Today, tomorrow, someone else will shoot up a mall. What are you going to do ? Install TSA scanners at mall entrances ? No problem, you can shoot people in a subway station ? What, TSA at every subway station entrance in the country ? At every bus station ? Blackwater security with metal detectors every conference held in a hotel ? Or just play it cool and live normally with the chance that the next disgruntled person with a gun will not choose the same place you happen to be at at any particular time. The "disgruntled person with a gun" can be replaced with your favorite type of bad guy (bio-terrorist, suicide bomber etc). It's not a secret that people do stupid things when they're scared and all of the world's governments know this and never loose the chance to pass more restrictive laws whenever a tragedy happens and people would support anything that they believe would stop another incident. What people need is more common sense and not be get scared and panicked by whatever scare the media throws at at them. They would twist stories to get ratings in unimaginable ways. Statistically speaking, everyone of us has a chance everyday to die in an accident (get hit by a car, bus, metro, train whatever). This does not mean that everyone should stay home and do nothing. Even at home you can cat yourself very bad with a knife making dinner :)) Minimize the big threats using intelligence services effectively, and smaller ones if you can in a non-intrusive way. Perfect security will never be something that can be attained. Even from North Korea people escape from time to time, and they are surveilled like crazy. On Fri, Mar 15, 2013 at 3:53 PM, Owen DeLong wrote: >> And there you have it :) >> >> Security obviously works thus far, in the sense, that so far, >> government has been preserved -- there is not total chaos, in at least >> most of the world, and people do not doubt if their life or property >> will still exist the next day. >> > > I'm not sure I would even put "government has been preserved" on the list of considerations for the success or failure of security. > > I would put "law and order", "governance and/or the process of governance" on the list, but especially in a post-911 world, the US Government has departed from those ideals to varying degrees. > > Do not get me wrong, I am not advocating radical revolution or saying that we should tear down the existing institutions. Merely that we should be careful in our default use of terminology and focus on what we really want to preserve. Ideally, we can restore the US government to its proper (and limited) function. (That does not mean eliminating government services and making it small enough to fit in our bedrooms, either.) > > I'm not supporting any of the current Washington agendas and parties. I'm fed up with all of them at this point and unless they start working on solving problems instead of posturing all the time, I won't be supporting ANY incumbents. > >> Abusing new technology faster doesn't trump the extreme smallness of >> the numbers of truly bad actors, who have irrational thinking, would >> like to end civilization, and the intersection between those and >> those who have a viable method that would work + the right >> resources/skill available, and a reasonable chance of success.... >> astronomically small > > The bottom line is that any system of laws and/or governance depends entirely on voluntary compliance by the majority of the actors. > >> If in a few decades, there is a 0.1% chance per decade of a >> script kiddie ending civilization, I think we've got few reasonable >> alternatives but to accept that risk and hope for the best :) > > On the other hand, I will hold up the U.S.A.P.A.T.R.I.O.T. act and the T.S.A. as proof that we are rather adept at exploring and sometimes acting on the unreasonable alternatives. > > Owen > > > From arturo.servin at gmail.com Sun Mar 17 15:33:01 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 17 Mar 2013 12:33:01 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> Message-ID: <5145E22D.20305@gmail.com> Yes, BCP38 is the solution. Now, how widely is deployed? Someone said in the IEPG session during the IETF86 that 80% of the service providers had done it? This raises two questions for me. One, is it really 80%, how to measure it? Second, if it were 80%, how come the 20% makes so much trouble and how to encourage it to deploy BCP38? (well, actually 4 questions :) Regards, as On 3/16/13 7:24 PM, Jon Lewis wrote: > On Sat, 16 Mar 2013, Robert Joosten wrote: > >> Hi, >> >>>> Can anyone provide insight into how to defeat DNS amplification >>>> attacks? >>> Restrict resolvers to your customer networks. >> >> And deploy RPF > > uRPF / BCP38 is really the only solution. Even if we did close all the > open recursion DNS servers (which is a good idea), the attackers would > just shift to another protocol/service that provides amplification of > traffic and can be aimed via spoofed source address packets. Going > after DNS is playing whack-a-mole. DNS is the hip one right now. It's > not the only one available. From morrowc.lists at gmail.com Sun Mar 17 16:35:17 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 17 Mar 2013 12:35:17 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <5145E22D.20305@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: On Sun, Mar 17, 2013 at 11:33 AM, Arturo Servin wrote: > > Yes, BCP38 is the solution. > > Now, how widely is deployed? > > Someone said in the IEPG session during the IETF86 that 80% of the > service providers had done it? right... sure. > This raises two questions for me. One, is it really 80%, how to measure it? > csail had a project for a while... spoofer project? I think the last I looked they reported ONLY 35% or so coverage of proper filtering. Looking at: though they report 86% non-spoofable, that seems very high to me. > Second, if it were 80%, how come the 20% makes so much trouble and how > to encourage it to deploy BCP38? some of the 20% seems to be very highspeed connected end hosts and at a 70:1 amplification ratio you don't need much bandwidth to fill a 1g pipe, eh? -chris > (well, actually 4 questions :) > > Regards, > as > > On 3/16/13 7:24 PM, Jon Lewis wrote: >> On Sat, 16 Mar 2013, Robert Joosten wrote: >> >>> Hi, >>> >>>>> Can anyone provide insight into how to defeat DNS amplification >>>>> attacks? >>>> Restrict resolvers to your customer networks. >>> >>> And deploy RPF >> >> uRPF / BCP38 is really the only solution. Even if we did close all the >> open recursion DNS servers (which is a good idea), the attackers would >> just shift to another protocol/service that provides amplification of >> traffic and can be aimed via spoofed source address packets. Going >> after DNS is playing whack-a-mole. DNS is the hip one right now. It's >> not the only one available. > From david at davidcoulson.net Sun Mar 17 17:53:02 2013 From: david at davidcoulson.net (David Coulson) Date: Sun, 17 Mar 2013 13:53:02 -0400 Subject: Long ARP reply Message-ID: <514602FE.6020609@davidcoulson.net> From jlewis at lewis.org Sun Mar 17 18:22:39 2013 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 17 Mar 2013 14:22:39 -0400 (EDT) Subject: [c-nsp] DNS amplification In-Reply-To: <5145E22D.20305@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: On Sun, 17 Mar 2013, Arturo Servin wrote: > Now, how widely is deployed? > > Someone said in the IEPG session during the IETF86 that 80% of the > service providers had done it? > > This raises two questions for me. One, is it really 80%, how to measure it? > > Second, if it were 80%, how come the 20% makes so much trouble and how > to encourage it to deploy BCP38? You'd have to get access (cloud VM, dedicated server, etc.) on each network and see if you can successfully get spoofed packets out to another network. I seriously doubt those numbers though. I'd bet it's more like 80% of service providers are too embarrassed to admit they're not doing BCP38 filtering (or don't know what it is), and 20% are doing it on at least some parts of their network. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From babydr at baby-dragons.com Sun Mar 17 22:34:08 2013 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Sun, 17 Mar 2013 14:34:08 -0800 (AKDT) Subject: Why would a Facebook device be sending Spi packets at home user ? Message-ID: Hello All , Maybe I am missing (or have missed) something . Here is the log entry & dig & whois info . Just kinda interested in info on this phenomenon . I've received many SPI assoc. requests at my poor ol' router over the few years it's been online , Most of them are from S.E. Asia & few from Africa others from EU , But by & far most of them are USA based Webservers by their dig & whois info . A very small few are from org's such as FB . I usually just ignore these as some fluke or if I know a contact at the site I send them the info . 1 ) Is there an orginazation that is mapping unsecured ipsec boxen ? 2 ) Has or is anyone else receiving attempts at establishing association ? 3 ) Is anyone recording these or interested in keeping records ? 4 ) Anything elso I would be interested in along the lines of assoc. attempts & why they are being attempted ? Tia , JimL Mar 17 21:48:47.637: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=xx.yy.zz.aa, prot=50, spi=0xE3488400(3813180416), srcaddr=69.171.255.12 $ dig -x 69.171.255.12 ; <<>> DiG 9.9.1-P3 <<>> -x 69.171.255.12 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36105 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;12.255.171.69.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 255.171.69.in-addr.arpa. 3600 IN SOA a.ns.facebook.com. dns.facebook.com. 1363497425 7200 1800 604800 3600 ;; Query time: 528 msec ;; SERVER: 199.33.245.55#53(199.33.245.55) ;; WHEN: Sun Mar 17 14:14:40 2013 ;; MSG SIZE rcvd: 112 $ whois 69.171.255.12 # # Query terms are ambiguous. The query is assumed to be: # "n 69.171.255.12" # # Use "?" to get help. # # # The following results may also be obtained via: # http://whois.arin.net/rest/nets;q=69.171.255.12?showDetails=true&showARIN=false&ext=netref2 # NetRange: 69.171.224.0 - 69.171.255.255 CIDR: 69.171.224.0/19 OriginAS: AS32934 NetName: TFBNET3 NetHandle: NET-69-171-224-0-1 Parent: NET-69-0-0-0-0 NetType: Direct Assignment RegDate: 2010-08-05 Updated: 2012-02-24 Ref: http://whois.arin.net/rest/net/NET-69-171-224-0-1 OrgName: Facebook, Inc. OrgId: THEFA-3 Address: 1601 Willow Rd. City: Menlo Park StateProv: CA PostalCode: 94025 Country: US RegDate: 2004-08-11 Updated: 2012-04-17 Ref: http://whois.arin.net/rest/org/THEFA-3 OrgTechHandle: OPERA82-ARIN OrgTechName: Operations OrgTechPhone: +1-650-543-4800 OrgTechEmail: noc at fb.com OrgTechRef: http://whois.arin.net/rest/poc/OPERA82-ARIN OrgAbuseHandle: OPERA82-ARIN OrgAbuseName: Operations OrgAbusePhone: +1-650-543-4800 OrgAbuseEmail: noc at fb.com OrgAbuseRef: http://whois.arin.net/rest/poc/OPERA82-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # -- +------------------------------------------------------------------+ | 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 arturo.servin at gmail.com Sun Mar 17 22:36:30 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 17 Mar 2013 19:36:30 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: <5146456E.2000406@gmail.com> They should publish the spoofable AS. Not for public shame but at least to show the netadmins that they are doing something wrong, or if they are trying to do the good think is not working. Or at least a tool to check for your ASN or netblock. /as On 3/17/13 1:35 PM, Christopher Morrow wrote: > On Sun, Mar 17, 2013 at 11:33 AM, Arturo Servin wrote: >> >> Yes, BCP38 is the solution. >> >> Now, how widely is deployed? >> >> Someone said in the IEPG session during the IETF86 that 80% of the >> service providers had done it? > > right... sure. > >> This raises two questions for me. One, is it really 80%, how to measure it? >> > > csail had a project for a while... spoofer project? > > > I think the last I looked they reported ONLY 35% or so coverage of > proper filtering. Looking at: > > > though they report 86% non-spoofable, that seems very high to me. > >> Second, if it were 80%, how come the 20% makes so much trouble and how >> to encourage it to deploy BCP38? > > some of the 20% seems to be very highspeed connected end hosts and at > a 70:1 amplification ratio you don't need much bandwidth to fill a 1g > pipe, eh? > > -chris > >> (well, actually 4 questions :) >> >> Regards, >> as >> >> On 3/16/13 7:24 PM, Jon Lewis wrote: >>> On Sat, 16 Mar 2013, Robert Joosten wrote: >>> >>>> Hi, >>>> >>>>>> Can anyone provide insight into how to defeat DNS amplification >>>>>> attacks? >>>>> Restrict resolvers to your customer networks. >>>> >>>> And deploy RPF >>> >>> uRPF / BCP38 is really the only solution. Even if we did close all the >>> open recursion DNS servers (which is a good idea), the attackers would >>> just shift to another protocol/service that provides amplification of >>> traffic and can be aimed via spoofed source address packets. Going >>> after DNS is playing whack-a-mole. DNS is the hip one right now. It's >>> not the only one available. >> From morrowc.lists at gmail.com Mon Mar 18 00:55:02 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 17 Mar 2013 20:55:02 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <5146456E.2000406@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <5146456E.2000406@gmail.com> Message-ID: On Sun, Mar 17, 2013 at 6:36 PM, Arturo Servin wrote: > > They should publish the spoofable AS. Not for public shame but at least > to show the netadmins that they are doing something wrong, or if they > are trying to do the good think is not working. > > Or at least a tool to check for your ASN or netblock. I don't disagree, but I'd point out that there are likely easier places to do bcp38 than others in everyone's network(s)... So, 'I do bcp38' unqualified is not as helpful, especially when almost all consumer grade links are bcp38 by default, which is likely where a bunch of this measurement originates. (well, I suspect a bunch of it is from consumer-grade links anyway) From mysidia at gmail.com Mon Mar 18 02:04:26 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 17 Mar 2013 21:04:26 -0500 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: On 3/17/13, Jon Lewis wrote: > On Sun, 17 Mar 2013, Arturo Servin wrote: > You'd have to get access (cloud VM, dedicated server, etc.) on each > network and see if you can successfully get spoofed packets out to > another network. If you have packet data about a sufficient number of different kinds of attacks per source network over a long period of time, at a specific attack/normal traffic sensor; you might be able to infer some information about which networks prevent spoofing, through a difference in the kind of attacks shown to be originating from all the networks. If spoofing is preferred, or used by other nodes involved in a particular attack, the networks that are concentrated sources of non-spoofing attack packets most likely, are places where spoofing prevention could be present -- and have altered attacker behavior. Possibly the presence of spoofed packets may be suggested by a sudden drastic difference in the average TTL versus legitimate traffic for a particular source network for packets with a particular source IP, correlated with the attack VS the remaining packet TTLs normally observed for legitimate traffic from that network. If you have a sufficiently massive number of traffic sensors, and massive data gathering infrastructure, close enough to the attacks, it may be possible to analyze the microsecond-level timing of packets, and the time sequence/order they arrive at various sensors (milliseconds delay/propagation rate of attacker nodes initiating), in order to provide a probability that spoofed packets came from certain networks. Then at that point, you might make some guesses about which networks implement BCP38 -- -JH From damian at google.com Mon Mar 18 04:18:47 2013 From: damian at google.com (Damian Menscher) Date: Sun, 17 Mar 2013 21:18:47 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: On Sun, Mar 17, 2013 at 7:04 PM, Jimmy Hess wrote: > If you have a sufficiently massive number of traffic sensors, and > massive data gathering infrastructure, close enough to the attacks, > it may be possible to analyze the microsecond-level timing of packets, > and the time sequence/order they arrive at various sensors > (milliseconds delay/propagation rate of attacker nodes initiating), > in order to provide a probability that spoofed packets came from > certain networks. > To get microsecond-level timing, you have to be so close that you're basically just peering with everyone. And at that point you can just look to see which fibers carry spoofed packets. Once you know an ISP hasn't implemented BCP38, what'st the next step? De-peering just reduces your own visibility into the problem. What if it's a transit provider, who can be legitimately expected to route for 0/0? Damian From mohta at necom830.hpcl.titech.ac.jp Mon Mar 18 05:01:34 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 18 Mar 2013 14:01:34 +0900 Subject: [c-nsp] DNS amplification In-Reply-To: <5145E22D.20305@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: <51469FAE.7030102@necom830.hpcl.titech.ac.jp> Arturo Servin wrote: > Yes, BCP38 is the solution. It is not a solution at all, because it, instead, will promote multihomed sites bloats the global routing table. To really solve the problem in an end to end fashion, it is necessary to require IGPs carry information for the proper source address corresponding to each routing table entry in a *FULL* routing table, which must be delivered to almost, if not all, all the end systems. Masataka Ohta From marka at isc.org Mon Mar 18 05:22:36 2013 From: marka at isc.org (Mark Andrews) Date: Mon, 18 Mar 2013 16:22:36 +1100 Subject: [c-nsp] DNS amplification In-Reply-To: Your message of "Mon, 18 Mar 2013 14:01:34 +0900." <51469FAE.7030102@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> Message-ID: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> In message <51469FAE.7030102 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Arturo Servin wrote: > > > Yes, BCP38 is the solution. > > It is not a solution at all, because it, instead, will promote > multihomed sites bloats the global routing table. How does enforcing that source address entering your net from customers sites match thoses that have been allocated to them bloat the routing table? Now if you only accept address you have allocated to them by you then that could bloat the routing table but BCP 38 does NOT say to do that. Simlarly URP checking is not BCP 38. With SIDR each multi-homed customer could provide CERTs which proves they have been allocated a address range which could be feed into the acl generators as exceptions to the default rules. This is in theory automatible. > To really solve the problem in an end to end fashion, it is > necessary to require IGPs carry information for the proper > source address corresponding to each routing table entry in a > *FULL* routing table, which must be delivered to almost, if > not all, all the end systems. How does that solve the problem? > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mohta at necom830.hpcl.titech.ac.jp Mon Mar 18 05:47:14 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 18 Mar 2013 14:47:14 +0900 Subject: [c-nsp] DNS amplification In-Reply-To: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> Message-ID: <5146AA62.40205@necom830.hpcl.titech.ac.jp> Mark Andrews wrote: >>> Yes, BCP38 is the solution. >> >> It is not a solution at all, because it, instead, will promote >> multihomed sites bloats the global routing table. > > How does enforcing that source address entering your net from > customers sites match thoses that have been allocated to them > bloat the routing table? First of all, multihomed sites with its own global routing table entries bloats the global routing table, which is the major cause of global routing table bloat and is not acceptable. Then, the only solution is to let the multihomed sites have multiple prefixes, each of which is aggregated by each provider. But, then, all the end systems are required to choose the proper source addresses corresponding to destination addresses, which requires IGPs carry such information. See draft-ohta-e2e-multihoming-05 for details. > Now if you only accept address you have allocated to them by you > then that could bloat the routing table but BCP 38 does NOT say to > do that. Simlarly URP checking is not BCP 38. That BCP 38 is narrowly scoped is not my problem. > With SIDR each multi-homed customer could provide CERTs which proves > they have been allocated a address range which could be feed into > the acl generators as exceptions to the default rules. This is in > theory automatible. The problem is not in individual ISPs but in the global routing table size. > How does that solve the problem? In the end to end fashion. See draft-ohta-e2e-multihoming-05 for details. Masataka Ohta From rdobbins at arbor.net Mon Mar 18 06:16:03 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 18 Mar 2013 06:16:03 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: <5146AA62.40205@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> Message-ID: <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> On Mar 18, 2013, at 12:47 PM, Masataka Ohta wrote: > See draft-ohta-e2e-multihoming-05 for details. See for an actual solution to the problem of routing-table bloat, which has nothing to do with BCP38/84. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mysidia at gmail.com Mon Mar 18 06:23:57 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 18 Mar 2013 01:23:57 -0500 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> Message-ID: On 3/17/13, Damian Menscher wrote: > Once you know an ISP hasn't implemented BCP38, what'st the next step? > De-peering just reduces your own visibility into the problem. What if In general, a hard problem, not directly solvable in any obvious way. It's similar to the question of what's the next step, after you identified a probable connectivity issue. Detection does not always grant you a way of preventing something. Ultimately, to improve matters with regards to BCP38, I believe you have to secure cooperation; cooperation can sometimes be achieved through persuasion (discussing/requesting/bargaining/begging), or coercing (bribing, threatening, seeking intervention from sponsors, regulators, other networks, or other authorities, public shaming). The recommended next-step would be the ones with the least harmful ramifications for all involved and the network that do have a chance of being effective, and more aggressive options reserved as possible backup plans. In some cases, extreme methods such as inserting offending network's AS into the middle of the AS path of outgoing announcements, possibly, so the spoofed source's upstream network omits reachability to the prefix under attack.... or maintaining peering, but blackholing traffic from that peer, to the local prefix under attack > it's a transit provider, who can be legitimately expected to route for 0/0? Restricted peering can reduce the impact of the problem; in other words: maintain the peering, but strictly controlling the packets per second and octets per second volumes; traffic going over the peer link is sacrificed during attack, to protect the target. This may still be mutually beneficial for the peers. If the peer is such a transit provider, the problem is indeed hard, possibly not able to be mitigated. > Damian -- -JH From sander at steffann.nl Mon Mar 18 09:26:24 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Mar 2013 10:26:24 +0100 Subject: [c-nsp] DNS amplification In-Reply-To: <5146AA62.40205@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> Message-ID: <455C2CF4-8FFC-4C49-BA82-127C8CD17D47@steffann.nl> Hi, > First of all, multihomed sites with its own global routing > table entries bloats the global routing table, which is the > major cause of global routing table bloat and is not acceptable. Sorry, but that is false. Looking at the CIDR report (http://www.cidr-report.org/as2.0/#Gains) the routing table could shrink from 449k to 258k just by aggregating announcements. That's a reduction of 42.5%. I can't see how multihomed end-site announcements can be worst than that... There would almost be no routing table left ;-) Anyway... Drifting off-topic for this thread. Sander From joseph.snyder at gmail.com Mon Mar 18 12:50:25 2013 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Mon, 18 Mar 2013 08:50:25 -0400 Subject: Verizon FIOS filtering? In-Reply-To: <5144C986.4000704@ip-solutions.net> References: <5144C986.4000704@ip-solutions.net> Message-ID: <30e3f0d4-6271-44bd-8799-f982ff3caad5@email.android.com> Did you ever resolve this? Harry Hoffman wrote: >Hi All, > >Does anyone know if Verizon automatically performs network filtering in >response to scanning behavior? > >I'm having some weird connectivity issues to a host and trying to >figure >out why. > >Cheers, >Harry -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From arturo.servin at gmail.com Mon Mar 18 12:53:51 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 18 Mar 2013 09:53:51 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: <5146AA62.40205@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> Message-ID: <51470E5F.4070804@gmail.com> I think BCP it is a solution. Perhaps not complete but hardy any single solution would be suitable for a complex problem as this one. If you are the end-user organization with a multihomed topology you apply BCP38 within your own scope. This will help to have less spoofed traffic. Not solving all the problems but it would help not seeing your spoofed packets all over the Internet. And about the routing table size, it is not multihomed sites the offenders, it is large ISPs fragmenting because of traffic engineering or because lack of BGP knowledge. .as On 3/18/13 2:47 AM, Masataka Ohta wrote: > Mark Andrews wrote: > >>>> Yes, BCP38 is the solution. >>> >>> It is not a solution at all, because it, instead, will promote >>> multihomed sites bloats the global routing table. >> >> How does enforcing that source address entering your net from >> customers sites match thoses that have been allocated to them >> bloat the routing table? > > First of all, multihomed sites with its own global routing > table entries bloats the global routing table, which is the > major cause of global routing table bloat and is not acceptable. > > Then, the only solution is to let the multihomed sites have > multiple prefixes, each of which is aggregated by each > provider. > > But, then, all the end systems are required to choose the proper > source addresses corresponding to destination addresses, which > requires IGPs carry such information. > > See draft-ohta-e2e-multihoming-05 for details. > >> Now if you only accept address you have allocated to them by you >> then that could bloat the routing table but BCP 38 does NOT say to >> do that. Simlarly URP checking is not BCP 38. > > That BCP 38 is narrowly scoped is not my problem. > >> With SIDR each multi-homed customer could provide CERTs which proves >> they have been allocated a address range which could be feed into >> the acl generators as exceptions to the default rules. This is in >> theory automatible. > > The problem is not in individual ISPs but in the global routing > table size. > >> How does that solve the problem? > > In the end to end fashion. > > See draft-ohta-e2e-multihoming-05 for details. > > Masataka Ohta > > From hhoffman at ip-solutions.net Mon Mar 18 12:57:49 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Mon, 18 Mar 2013 08:57:49 -0400 Subject: Verizon FIOS filtering? In-Reply-To: <30e3f0d4-6271-44bd-8799-f982ff3caad5@email.android.com> References: <5144C986.4000704@ip-solutions.net> <30e3f0d4-6271-44bd-8799-f982ff3caad5@email.android.com> Message-ID: <51470F4D.2010600@ip-solutions.net> Hi All, Sorry, got pulled away on other projects. No, still trying to figure out what's going on. This is traffic originating from FIOS's network. I have a host located in a .edu that is configured to send back icmp host prohibited replies for connections that aren't specifically allowed in the host based firewall. The .edu border routers filter very little (standard MS ports 135,137,139,445 udp/tcp). I can ssh from my verizon fios router (a linux box) to my .edu host (also a linux box). If I run nmap -sT -Pn <.edu host> I'll get back different results of what ports are filtered. I assume that this is a result of what nmap decides to cache when it receives the ICMP messages. Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:53 EDT Nmap scan report for some.host.edu (123.45.67.89) Host is up (0.028s latency). Not shown: 999 closed ports PORT STATE SERVICE 23/tcp filtered telnet Nmap done: 1 IP address (1 host up) scanned in 3.78 seconds [hhoffman at firefly ~]$ nmap -Pn -sT some.host.edu Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:53 EDT Nmap scan report for some.host.edu (123.45.67.89) Host is up (0.034s latency). Not shown: 998 closed ports PORT STATE SERVICE 21/tcp filtered ftp 199/tcp filtered smux Nmap done: 1 IP address (1 host up) scanned in 20.43 seconds [harryh at firefly ~]$ nmap -Pn -sT some.host.edu Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:56 EDT Nmap scan report for some.host.edu (123.45.67.89) Host is up (0.078s latency). Not shown: 996 closed ports PORT STATE SERVICE 21/tcp filtered ftp 111/tcp filtered rpcbind 256/tcp filtered fw1-secureremote 3389/tcp filtered ms-wbt-server Nmap done: 1 IP address (1 host up) scanned in 2.52 seconds [hhoffman at firefly ~]$ nmap -Pn -sT some.host.edu Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:56 EDT Nmap scan report for some.host.edu (123.45.67.89) Host is up (0.030s latency). All 1000 scanned ports on some.host.edu (123.45.67.89) are closed For a short period of time after the scans commence I'm not able to connect from my FIOS host to my .edu host on tcp/22, a port that is specifically allowed in the .edu host's firewall rules. There is no software on either end that would perform any tarpit-like functionality. Cheers, Harry On 03/18/2013 08:50 AM, joseph.snyder at gmail.com wrote: > Did you ever resolve this? > > Harry Hoffman wrote: > >> Hi All, >> >> Does anyone know if Verizon automatically performs network filtering in >> response to scanning behavior? >> >> I'm having some weird connectivity issues to a host and trying to >> figure >> out why. >> >> Cheers, >> Harry > From jared at puck.nether.net Mon Mar 18 13:25:53 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Mar 2013 09:25:53 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <5146456E.2000406@gmail.com> Message-ID: <2A14DD33-3CDB-44CF-8F51-7BDC45D157A7@puck.nether.net> On Mar 17, 2013, at 8:55 PM, Christopher Morrow wrote: > On Sun, Mar 17, 2013 at 6:36 PM, Arturo Servin wrote: >> >> They should publish the spoofable AS. Not for public shame but at least >> to show the netadmins that they are doing something wrong, or if they >> are trying to do the good think is not working. >> >> Or at least a tool to check for your ASN or netblock. > > I don't disagree, but I'd point out that there are likely easier > places to do bcp38 than others in everyone's network(s)... So, 'I do > bcp38' unqualified is not as helpful, especially when almost all > consumer grade links are bcp38 by default, which is likely where a > bunch of this measurement originates. (well, I suspect a bunch of it > is from consumer-grade links anyway) (Not sure how this made it from c-nsp to nanog, but ...) uRPF/BCP38 is an important part of a global solution. Similar to open-relays, smurf amplifiers, and other "badness" on the network, one must assist the global network by deploying it where it makes sense. Deploying it at your customer ports may make sense depending on your network. Deploying it on peers may also make sense. I think having a simple set of locations where people actually deploy it is critical, eg: Colocation Network Server Lans VPS Lans Static Routed Customer Edge This should be the default, and something I've pushed at my employer for years. If you do nothing, you can expect nothing as the result. If you attempt do so something, you can at least get an idea of where it's not coming from. At least target these easy edges of the network where there is some value. - Jared From mohta at necom830.hpcl.titech.ac.jp Mon Mar 18 14:45:41 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 18 Mar 2013 23:45:41 +0900 Subject: [c-nsp] DNS amplification In-Reply-To: <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> Message-ID: <51472895.8000008@necom830.hpcl.titech.ac.jp> Dobbins, Roland wrote: >> See draft-ohta-e2e-multihoming-05 for details. > > See for an actual solution > to the problem of routing-table bloat, It is, by no means, a solution. > which has nothing to do with BCP38/84. Locator ID separation has nothing to do with routing table bloat. Masataka Ohta From jabley at hopcount.ca Mon Mar 18 14:54:37 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 18 Mar 2013 10:54:37 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <51470E5F.4070804@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <51470E5F.4070804@gmail.com> Message-ID: <4942DF96-C54A-4470-8C59-555C9BBC0117@hopcount.ca> On 2013-03-18, at 08:53, Arturo Servin wrote: > And about the routing table size, it is not multihomed sites the > offenders, it is large ISPs fragmenting because of traffic engineering > or because lack of BGP knowledge. The usual concern with multi-homed end sites is that end sites with IPv4 PA addresses assigned from provider X who wish to multi-home with provider Y wind up adding at least two entries to the global table, a more specific route to each of X and Y (which X will need to leak beneath the covering supernet if it wants to deliver the customer any traffic). I don't know of any recent analysis which differentiates between this multi-homing pressure on the global table vs. inter-domain traffic engineering or gratuitous deaggregation, but it's fair to say I have not been looking. Joe From mohta at necom830.hpcl.titech.ac.jp Mon Mar 18 15:02:09 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 19 Mar 2013 00:02:09 +0900 Subject: [c-nsp] DNS amplification In-Reply-To: <455C2CF4-8FFC-4C49-BA82-127C8CD17D47@steffann.nl> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <455C2CF4-8FFC-4C49-BA82-127C8CD17D47@steffann.nl> Message-ID: <51472C71.3020708@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: > Sorry, but that is false. Looking at the CIDR report > (http://www.cidr-report.org/as2.0/#Gains) the routing table > could shrink from 449k to 258k just by aggregating > announcements. What if, NLIs are aggregated? > That's a reduction of 42.5%. I can't see how multihomed end-site > announcements can be worst than that... See "5.2. Limiting the Number of TLAs" of my draft. > Anyway... Drifting off-topic for this thread. Current poor support for multihomed sites is a reason why BCP38 is not operational. Masataka Ohta From arturo.servin at gmail.com Mon Mar 18 15:09:39 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 18 Mar 2013 12:09:39 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: <51472C71.3020708@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <455C2CF4-8FFC-4C49-BA82-127C8CD17D47@steffann.nl> <51472C71.3020708@necom830.hpcl.titech.ac.jp> Message-ID: <51472E33.2030509@gmail.com> Masataka, Do you have data to support your claim? I would said that poor BCP38 deployment it is because a lack of economical incentive. I have only empirical data to support my claim though (which is private conversations with ISPs not doing it and saying that they do not see a cost effective advantage). Regards, as On 3/18/13 12:02 PM, Masataka Ohta wrote: > Current poor support for multihomed sites is a reason why > BCP38 is not operational. From mohta at necom830.hpcl.titech.ac.jp Mon Mar 18 15:10:12 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 19 Mar 2013 00:10:12 +0900 Subject: [c-nsp] DNS amplification In-Reply-To: <51470E5F.4070804@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <51470E5F.4070804@gmail.com> Message-ID: <51472E54.3050900@necom830.hpcl.titech.ac.jp> Arturo Servin wrote: > If you are the end-user organization with a multihomed topology you > apply BCP38 within your own scope. This will help to have less spoofed > traffic. Not solving all the problems but it would help not seeing your > spoofed packets all over the Internet. It does not help not seeing a spoofed packets with source addresses of yours. > And about the routing table size, it is not multihomed sites the > offenders, it is large ISPs fragmenting because of traffic engineering > or because lack of BGP knowledge. As the number of *LARGE* ISPs is limited, it is not a problem. Masataka Ohta From joseph.snyder at gmail.com Mon Mar 18 15:13:12 2013 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Mon, 18 Mar 2013 11:13:12 -0400 Subject: Verizon FIOS filtering? In-Reply-To: <51470F4D.2010600@ip-solutions.net> References: <5144C986.4000704@ip-solutions.net> <30e3f0d4-6271-44bd-8799-f982ff3caad5@email.android.com> <51470F4D.2010600@ip-solutions.net> Message-ID: Are you sure the edu isn't triggering any sort of filtering on host that do scanning? Harry Hoffman wrote: >Hi All, > >Sorry, got pulled away on other projects. No, still trying to figure >out >what's going on. This is traffic originating from FIOS's network. > >I have a host located in a .edu that is configured to send back icmp >host prohibited replies for connections that aren't specifically >allowed >in the host based firewall. > >The .edu border routers filter very little (standard MS ports >135,137,139,445 udp/tcp). > >I can ssh from my verizon fios router (a linux box) to my .edu host >(also a linux box). > >If I run nmap -sT -Pn <.edu host> I'll get back different results of >what ports are filtered. I assume that this is a result of what nmap >decides to cache when it receives the ICMP messages. > >Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:53 EDT >Nmap scan report for some.host.edu (123.45.67.89) >Host is up (0.028s latency). >Not shown: 999 closed ports >PORT STATE SERVICE >23/tcp filtered telnet > >Nmap done: 1 IP address (1 host up) scanned in 3.78 seconds >[hhoffman at firefly ~]$ nmap -Pn -sT some.host.edu > >Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:53 EDT >Nmap scan report for some.host.edu (123.45.67.89) >Host is up (0.034s latency). >Not shown: 998 closed ports >PORT STATE SERVICE >21/tcp filtered ftp >199/tcp filtered smux > >Nmap done: 1 IP address (1 host up) scanned in 20.43 seconds >[harryh at firefly ~]$ nmap -Pn -sT some.host.edu > >Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:56 EDT >Nmap scan report for some.host.edu (123.45.67.89) >Host is up (0.078s latency). >Not shown: 996 closed ports >PORT STATE SERVICE >21/tcp filtered ftp >111/tcp filtered rpcbind >256/tcp filtered fw1-secureremote >3389/tcp filtered ms-wbt-server > >Nmap done: 1 IP address (1 host up) scanned in 2.52 seconds >[hhoffman at firefly ~]$ nmap -Pn -sT some.host.edu > >Starting Nmap 6.01 ( http://nmap.org ) at 2013-03-16 14:56 EDT >Nmap scan report for some.host.edu (123.45.67.89) >Host is up (0.030s latency). >All 1000 scanned ports on some.host.edu (123.45.67.89) are closed > >For a short period of time after the scans commence I'm not able to >connect from my FIOS host to my .edu host on tcp/22, a port that is >specifically allowed in the .edu host's firewall rules. > >There is no software on either end that would perform any tarpit-like >functionality. > >Cheers, >Harry > > > >On 03/18/2013 08:50 AM, joseph.snyder at gmail.com wrote: >> Did you ever resolve this? >> >> Harry Hoffman wrote: >> >>> Hi All, >>> >>> Does anyone know if Verizon automatically performs network filtering >in >>> response to scanning behavior? >>> >>> I'm having some weird connectivity issues to a host and trying to >>> figure >>> out why. >>> >>> Cheers, >>> Harry >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From arturo.servin at gmail.com Mon Mar 18 15:48:54 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 18 Mar 2013 12:48:54 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: <51472E54.3050900@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <51470E5F.4070804@gmail.com> <51472E54.3050900@necom830.hpcl.titech.ac.jp> Message-ID: <51473766.8060305@gmail.com> It does if I am not the sender. .as On 3/18/13 12:10 PM, Masataka Ohta wrote: > Arturo Servin wrote: > >> > If you are the end-user organization with a multihomed topology you >> > apply BCP38 within your own scope. This will help to have less spoofed >> > traffic. Not solving all the problems but it would help not seeing your >> > spoofed packets all over the Internet. > It does not help not seeing a spoofed packets with source addresses > of yours. > From psirt at cisco.com Mon Mar 18 16:14:07 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Mon, 18 Mar 2013 12:14:07 -0400 Subject: Cisco Security Response: Cisco IOS and Cisco IOS XE Type 4 Passwords Issue Message-ID: <201303181214018.cisco-sr-20130318-type4@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS and Cisco IOS XE Type 4 Passwords Issue Document ID: 33464 Revision 1.0 For Public Release 2013 March 18 16:00 UTC (GMT) +--------------------------------------------------------------------- Cisco Response Summary ====================== This is the Cisco response to research performed by Mr. Philipp Schmidt and Mr. Jens Steube from the Hashcat Project on the weakness of Type 4 passwords on Cisco IOS and Cisco IOS XE devices. Mr. Schmidt and Mr. Steube reported this issue to the Cisco PSIRT on March 12, 2013. A limited number of Cisco IOS and Cisco IOS XE releases based on the Cisco IOS 15 code base include support for a new algorithm to hash user-provided plaintext passwords. This algorithm is called Type 4, and a password hashed using this algorithm is referred to as a Type 4 password. The Type 4 algorithm was designed to be a stronger alternative to the existing Type 5 and Type 7 algorithms to increase the resiliency of passwords used for the 'enable secret password' and 'username username secret password' commands against brute-force attacks. For additional information please see the full Cisco Security Response at the link below. Cisco would like to thank Mr. Schmidt and Mr. Steube for sharing their research with Cisco and working toward a coordinated disclosure of this issue. This Cisco Security Response is available at: http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20130318-type4 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFHFKYACgkQUddfH3/BbTpPQAD/S/gS0O+btwWu5rI7rugYeRzD m38z8zGANgZ9IlEz/OoA/RZVrhrJJ1eRTlHo0/IHuYK3AYUtT5cA8PprIJoUX1Qg =R0TE -----END PGP SIGNATURE----- From jra at baylink.com Mon Mar 18 17:07:14 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 18 Mar 2013 13:07:14 -0400 (EDT) Subject: WW: Bruce Schneier on why security can't work In-Reply-To: Message-ID: <30560570.10208.1363626434502.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "." > This is a problem for the future to solve. Not us. Seriously? > In bioweapons, I think we are still on the "happy hackers era", where > people in a biochemical laboratory in Liverpool have access to some > fungus that can wipe half the city, but don't do, because have a lot > of fun studying the fungus to learn new antibiotics, or maybe to cure > baldness. Scientist are, of course, hackers. Fun people that make > this question: Exploitability. Can this fungus be used to cure > baldness? Can this fungus be exploited to remove plastic from our > oceans?. > > Exploitablity is a fun good word, and I never see a person like Bruce > Schneier talk about it (how fucking awesome is exploitability). So > reading people like Bruce Schneier you only get half the picture. > We exist only because the carbon based chemistry is exploitable to the > x900000. If carbon where less exploitable, like silice, maybe life > will not exist. Similary, maybe you need exploitability to have a > internet. You very well might. But never before have the stakes been this high. As Spenser is so fond of quoting Clausewitz: you plan not for your enemy's intentions, but for his capabilities. In the next 3 years, it will become possible to build an autonomously navigating aircraft that can a) cross the Atlantic and b) carry a nuclear weapon. The surveillance someone advocates in another posting won't help you there; your first warning will be "Manhattan goes boom". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rdobbins at arbor.net Mon Mar 18 17:54:52 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 18 Mar 2013 17:54:52 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: <51472895.8000008@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 18, 2013, at 9:45 PM, Masataka Ohta wrote: > Locator ID separation has nothing to do with routing table bloat. You obviously haven't read through the materials. I'm done feeding trolls for the day. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From Andy.Litzinger at theplatform.com Mon Mar 18 22:41:47 2013 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Mon, 18 Mar 2013 22:41:47 +0000 Subject: using ARIN IP space outside of ARIN region Message-ID: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> We're looking at building into a DC in Europe this year and I wanted to run a few questions by the community and make sure I'm not too far off course. We currently have v4 space from ARIN and operate a multihomed datacenter in the US. This thread from September 2012, though the reverse of my situation, makes it seem like I should be able to work with ARIN to satisfy all of our v4 and v6 needs regardless of where in the world I plan to advertise the space. Obviously this would be really convenient for us since we already have a relationship with ARIN. http://mailman.nanog.org/pipermail/nanog/2012-September/052137.html So my questions are: * Is it ok/recommended to advertise v4 ARIN space (say a /23) to my upstream ISPs in Europe? * Is it ok/recommended to advertise v6 ARIN space to my upstream ISPs in Europe? (I suspect we'll get a /44 block to carve up since we fit in the "more than one but less than 12 sites" category) * Should I use a single AS for both North America and European data centers? It will be the same small team managing them today but it's not like the sites are linked together to form any kind of transit network. Also, is there a European version of RADB with which I should plan to register my prefixes? thanks! - andy From woody at pch.net Mon Mar 18 22:49:37 2013 From: woody at pch.net (Bill Woodcock) Date: Mon, 18 Mar 2013 15:49:37 -0700 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> Message-ID: <9D2644DD-00D0-4A34-B87B-B8375EAD0B6B@pch.net> On Mar 18, 2013, at 3:41 PM, Andy Litzinger wrote: > We're looking at building into a DC in Europe this year and I wanted to run a few questions by the community and make sure I'm not too far off course. > We currently have v4 space from ARIN and operate a multihomed datacenter in the US. This thread from September 2012, though the reverse of my situation, makes it seem like I should be able to work with ARIN to satisfy all of our v4 and v6 needs regardless of where in the world I plan to advertise the space. Obviously this would be really convenient for us since we already have a relationship with ARIN. http://mailman.nanog.org/pipermail/nanog/2012-September/052137.html Note that I am speaking here as an ARIN member and resource-recipient (PCH), AND NOT as an ARIN board member. I have no inside track on the interpretation of ARIN rules, and don't pretend to. > So my questions are: > * Is it ok/recommended to advertise v4 ARIN space (say a /23) to my upstream ISPs in Europe? We do so, without any problems. > * Is it ok/recommended to advertise v6 ARIN space to my upstream ISPs in Europe? We do so, without any problems. > * Should I use a single AS for both North America and European data centers? We do so, without any problems. HOWEVER, we've been told in the past that space received from ARIN and used outside the ARIN region did not qualify as "utilization" for the purposes of justifying new allocations, nor were locations outside the ARIN region entitled to new allocations. We were told to get space for POPs outside of ARIN's region from the other respective RIRs. And indeed, those other RIRs have, by and large, been quite cooperative with giving us space for use within their regions, even in the cases when we had no business incorporated entity within their region. This experience is two or three years old, now, so interpretation and policy changes may have had some effect since then. -Bill From jared at puck.nether.net Mon Mar 18 22:50:25 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Mar 2013 18:50:25 -0400 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> Message-ID: <15057D99-1FCE-4CE4-8618-EDA997E566F2@puck.nether.net> On Mar 18, 2013, at 6:41 PM, Andy Litzinger wrote: > We're looking at building into a DC in Europe this year and I wanted to run a few questions by the community and make sure I'm not too far off course. > > We currently have v4 space from ARIN and operate a multihomed datacenter in the US. This thread from September 2012, though the reverse of my situation, makes it seem like I should be able to work with ARIN to satisfy all of our v4 and v6 needs regardless of where in the world I plan to advertise the space. Obviously this would be really convenient for us since we already have a relationship with ARIN. http://mailman.nanog.org/pipermail/nanog/2012-September/052137.html > > So my questions are: > * Is it ok/recommended to advertise v4 ARIN space (say a /23) to my upstream ISPs in Europe? Yes, expect there to possibly be geolocation issues. > * Is it ok/recommended to advertise v6 ARIN space to my upstream ISPs in Europe? (I suspect we'll get a /44 block to carve up since we fit in the "more than one but less than 12 sites" category) I would recommend looking at RIPE membership depending on the nature of your business. It may make sense to do this. > * Should I use a single AS for both North America and European data centers? It will be the same small team managing them today but it's not like the sites are linked together to form any kind of transit network. I see no issues with a single-AS. What you want to look at is if it makes sense. If you have just one link connecting your EU-North America sites, it may make sense to use a different ASN in the event of that circuit going down. If you use diverse cable systems, you are likely "OK". Make sure you track what system you are on, when there is an outage, it can take weeks to recover. > Also, is there a European version of RADB with which I should plan to register my prefixes? This would be the RIPE database, but most of the routing registries mirror each other, so you likely are fine using just one. (the daily sync issues aren't there anymore, it's realtime in every case i've observed in modern history). - Jared From mysidia at gmail.com Mon Mar 18 23:31:03 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 18 Mar 2013 18:31:03 -0500 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <30560570.10208.1363626434502.JavaMail.root@benjamin.baylink.com> References: <30560570.10208.1363626434502.JavaMail.root@benjamin.baylink.com> Message-ID: On 3/18/13, Jay Ashworth wrote: [snip] > In the next 3 years, it will become possible to build an autonomously > navigating aircraft that can a) cross the Atlantic and b) carry a > nuclear weapon. Not only is it already possible to build a human manually navigated aircraft that can do both (a), and (b), they already exist, and computer autonomy isn't necessary or useful, to hit a single big target; now computer autonomous aircraft that can do only (a) could be just as useful as decoys. Nuclear weapons are rare, expensive, and the existing ones are (hopefully) well-secured, due to their extremely high value. I would be more concerned about the possibility of a large swarm -- of half a million solar powered drones of the approximate size of a large eagle capable of crossing the oceans and releasing a spray of bio agents over very large distances. > -- jra -- -JH From web at typo.org Mon Mar 18 23:55:04 2013 From: web at typo.org (Wayne E Bouchard) Date: Mon, 18 Mar 2013 16:55:04 -0700 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <15057D99-1FCE-4CE4-8618-EDA997E566F2@puck.nether.net> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> <15057D99-1FCE-4CE4-8618-EDA997E566F2@puck.nether.net> Message-ID: <20130318235504.GA58441@wakko.typo.org> On Mon, Mar 18, 2013 at 06:50:25PM -0400, Jared Mauch wrote: > > On Mar 18, 2013, at 6:41 PM, Andy Litzinger wrote> > * Should I use a single AS for both North America and European data centers? It will be the same small team managing them today but it's not like the sites are linked together to form any kind of transit network. > > I see no issues with a single-AS. What you want to look at is if it makes sense. If you have just one link connecting your EU-North America sites, it may make sense to use a different ASN in the event of that circuit going down. > > If you use diverse cable systems, you are likely "OK". Make sure you track what system you are on, when there is an outage, it can take weeks to recover. > In the past, certain peers have required a unified ASN in order to exchange traffic. If you're using separate ASNs, they want the regions treated as separate organizations with regards to routing. (IE, they want you to effectively run them as separate business units.) I do not know how much of that is an issue today but it could be a real PITA in days past. Still, a single ASN in my view is the best choice anyway. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jra at baylink.com Tue Mar 19 00:11:24 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 18 Mar 2013 20:11:24 -0400 (EDT) Subject: WW: Bruce Schneier on why security can't work In-Reply-To: Message-ID: <7781754.10256.1363651884582.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > On 3/18/13, Jay Ashworth wrote: > [snip] > > In the next 3 years, it will become possible to build an > > autonomously > > navigating aircraft that can a) cross the Atlantic and b) carry a > > nuclear weapon. > > Not only is it already possible to build a human manually navigated > aircraft that can do both (a), and (b), they already exist, and computer > autonomy isn't necessary or useful, to hit a single big target; now > computer autonomous aircraft that can do only (a) could be just as > useful as decoys. Sure it is. An autonomous UPV *is small enough to bust the ADIZ without returning a skin paint*. > Nuclear weapons are rare, expensive, and the existing ones are > (hopefully) well-secured, due to their extremely high value. I > would be more concerned about the possibility of a large swarm -- of > half a million solar powered drones of the approximate size of a > large eagle capable of crossing the oceans and releasing a spray of > bio agents over very large distances. Whichever weapon is chosen, the point remains that the battlefield is asymmetric, and it's asymmetric *against us*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Tue Mar 19 00:22:23 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 18 Mar 2013 20:22:23 -0400 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <20130318235504.GA58441@wakko.typo.org> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> <15057D99-1FCE-4CE4-8618-EDA997E566F2@puck.nether.net> <20130318235504.GA58441@wakko.typo.org> Message-ID: <5147AFBF.6030403@vaxination.ca> This is not authoritative, but a friend in Australia used to routinely be given IP addresses by his residential ISP which geolocated in the USA and a whois revealed they were owned by a US network. Turns out that US network owned the ISP operating in Australia. I do not recall if the AS was specific to that ISP's operations in Australia. (It's been a few years) npr if traceroutes from canada would pass by the owning network's router's before hopping over to australia. From davidianwalker at gmail.com Tue Mar 19 00:37:39 2013 From: davidianwalker at gmail.com (David Walker) Date: Tue, 19 Mar 2013 11:07:39 +1030 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: References: <30560570.10208.1363626434502.JavaMail.root@benjamin.baylink.com> Message-ID: In history, people get taken unawares, by their neighbours. We don't implement systems to protect against that - no matter how much betrayal stares us in the face. The price of peace is eternal diligence and no-one writes that cheque. >From Troy to Chamberlain - it's not an issue of finding new regimes of trust. We look to trust whether or not it's warranted. That's a failure point. Therefore somebody's going to get screwed at some point. Anything less and we're already dead - only the dead have seen the end of war ... The difference here is the battleground and maybe the scale. Otherwise there's nothing special about information systems. Some time later the black plague/spanish flu comes along and teaches us about fragility and brittleness. I'm a fan of Bruce but looking to trust is not a prophylactic. Yes we trust ... and scheme about destroying our neighbours or defending ourselves or whatever. Engineering against nature/mathematics is a much loftier pursuit. Turn off the internet tomorrow for a day ... or a week or a year and carry on. That's the only kind of resilience worth worrying about. Everything else is a side show. Crazy talk sure, the internet's JAM - Just Another Machine - but worrying about bad people as the only stressor is setting the bar pretty low. We're much better off asking our hospitals "what will you do when the network is broken for a year" than asking our network people how they'll cope with bad guys and bad packets. That's the difference between a real scenario and a faux pas and there's a big mix of the two in the linked article ... From mohta at necom830.hpcl.titech.ac.jp Tue Mar 19 01:06:52 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 19 Mar 2013 10:06:52 +0900 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> Message-ID: <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> Dobbins, Roland wrote: >> Locator ID separation has nothing to do with routing table bloat. > > You obviously haven't read through the materials. LISP merely attempts to replace BGP routing table bloat with something a lot worse than that, that is, a lot more serious routing table bloat of its mapping system. Masataka Ohta From mpalmer at hezmatt.org Tue Mar 19 04:41:35 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Tue, 19 Mar 2013 15:41:35 +1100 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <9D2644DD-00D0-4A34-B87B-B8375EAD0B6B@pch.net> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> <9D2644DD-00D0-4A34-B87B-B8375EAD0B6B@pch.net> Message-ID: <20130319044135.GH5389@hezmatt.org> On Mon, Mar 18, 2013 at 03:49:37PM -0700, Bill Woodcock wrote: > HOWEVER, we've been told in the past that space received from ARIN and > used outside the ARIN region did not qualify as "utilization" for the > purposes of justifying new allocations, nor were locations outside the > ARIN region entitled to new allocations. We were told to get space for > POPs outside of ARIN's region from the other respective RIRs. And indeed, > those other RIRs have, by and large, been quite cooperative with giving us > space for use within their regions, even in the cases when we had no > business incorporated entity within their region. Which is ironic, because when we recently applied to ARIN for number resources to support our US operations, we were told to use our APNIC space instead. - Matt From drc at virtualized.org Tue Mar 19 05:13:36 2013 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Mar 2013 22:13:36 -0700 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <20130319044135.GH5389@hezmatt.org> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> <9D2644DD-00D0-4A34-B87B-B8375EAD0B6B@pch.net> <20130319044135.GH5389@hezmatt.org> Message-ID: <55FB8E7C-F49B-4A93-9C9D-4E77295FA534@virtualized.org> On Mar 18, 2013, at 9:41 PM, Matt Palmer wrote: > Which is ironic, because when we recently applied to ARIN for number > resources to support our US operations, we were told to use our APNIC space > instead. That's just the RIRs protecting you from yourself -- after all, everyone knows IP addresses (both v4 and v6) only makes sense if they are defined within geo-political monopolies. Sort of like RFC 3514 except with regions instead of moral states. (obligatory :) for the sarcasm impaired) Regards, -drc From eugen at leitl.org Tue Mar 19 08:07:30 2013 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 19 Mar 2013 09:07:30 +0100 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: References: <30560570.10208.1363626434502.JavaMail.root@benjamin.baylink.com> Message-ID: <20130319080729.GP6172@leitl.org> On Mon, Mar 18, 2013 at 06:31:03PM -0500, Jimmy Hess wrote: > On 3/18/13, Jay Ashworth wrote: > [snip] > > In the next 3 years, it will become possible to build an autonomously > > navigating aircraft that can a) cross the Atlantic and b) carry a > > nuclear weapon. > > Not only is it already possible to build a human manually navigated aircraft > that can do both (a), and (b), they already exist, and computer Or you could use a shipping container, or just bring in the parts in hand luggage, and assemble on site. > autonomy isn't necessary or useful, to hit a single big target; now > computer autonomous aircraft that can do only (a) could be just as > useful as decoys. > > Nuclear weapons are rare, expensive, and the existing ones are Far from expensive, a bargain-basement version would only cost you 100 kUSD in materials. Even at MUSD level, the kill costs at about 1 USD/kill is extremely cost-effective. > (hopefully) well-secured, due to their extremely high value. I > would be more concerned about the possibility of a large swarm -- of > half a million solar powered drones of the approximate size of a > large eagle capable of crossing the oceans and releasing a spray of > bio agents over very large distances. From rdobbins at arbor.net Tue Mar 19 08:38:31 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 19 Mar 2013 08:38:31 +0000 Subject: WW: Bruce Schneier on why security can't work In-Reply-To: <20130319080729.GP6172@leitl.org> References: <30560570.10208.1363626434502.JavaMail.root@benjamin.baylink.com> <20130319080729.GP6172@leitl.org> Message-ID: <0475A91B-9F50-41AB-8EB5-0B73B777BE24@arbor.net> On Mar 19, 2013, at 3:07 PM, Eugen Leitl wrote: > Or you could use a shipping container, or just bring in the parts in hand luggage, and assemble on site. Folks, this topic is far, far off-topic for this list. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From aledm at qix.co.uk Tue Mar 19 11:15:47 2013 From: aledm at qix.co.uk (Aled Morris) Date: Tue, 19 Mar 2013 11:15:47 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> Message-ID: On 19 March 2013 01:06, Masataka Ohta wrote: > LISP merely attempts to replace BGP routing table bloat with > something a lot worse than that, that is, a lot more serious > routing table bloat of its mapping system. > I'm guessing you're not a fan of LISP, but in it's defense I'd say the mapping system is akin to DNS - a scalable, distributed, reliable database mapping services to locations. BGP certainly can't cope with unconstrained growth, we will need something better. Aled From morrowc.lists at gmail.com Tue Mar 19 17:12:34 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 13:12:34 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> Message-ID: On Tue, Mar 19, 2013 at 7:15 AM, Aled Morris wrote: > On 19 March 2013 01:06, Masataka Ohta wrote: > >> LISP merely attempts to replace BGP routing table bloat with >> something a lot worse than that, that is, a lot more serious >> routing table bloat of its mapping system. >> > > I'm guessing you're not a fan of LISP, but in it's defense I'd say the > mapping system is akin to DNS - a scalable, distributed, reliable database > mapping services to locations. > > BGP certainly can't cope with unconstrained growth, we will need something > better. and by 'bgp' you mean 'the implementation(s) of BGP on platforms today' There's nothing inherent in BGP that would not work with an unconstrained growth of the routing table, right? You just need enough bandwidth and interrupts to deal with updates. From drc at virtualized.org Tue Mar 19 17:45:11 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Mar 2013 10:45:11 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> Message-ID: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: > There's nothing inherent in BGP that would not work with an > unconstrained growth of the routing table, right? You just need enough > bandwidth and interrupts to deal with updates. With enough thrust, pigs fly quite well. Landing can get messy though... Regards, -drc From morrowc.lists at gmail.com Tue Mar 19 17:50:43 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 13:50:43 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: On Tue, Mar 19, 2013 at 1:45 PM, David Conrad wrote: > On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: >> There's nothing inherent in BGP that would not work with an >> unconstrained growth of the routing table, right? You just need enough >> bandwidth and interrupts to deal with updates. > > With enough thrust, pigs fly quite well. Landing can get messy though... I was being serious... the current 'bgp unconstrained dies' problem isn't such a problem if you have (today): 4-8 cores 16 gb ram ssd gigabit ethernet or as you'd call this, your desktop computer... trying to do this on a 600mhz mips with 512mb ram is, clearly, a problem. put modern hardware to work and it gets simpler. Yes, the above addresses getting/sending 'rib' data, it doesn't address programming a FIB, but rethinking the programming of the fib a bit could, I bet, even get us to a palatable point for a longer while, in a relatively short period of time. -chris From jared at puck.nether.net Tue Mar 19 17:57:35 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Mar 2013 13:57:35 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net> On Mar 19, 2013, at 1:50 PM, Christopher Morrow wrote: > On Tue, Mar 19, 2013 at 1:45 PM, David Conrad wrote: >> On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: >>> There's nothing inherent in BGP that would not work with an >>> unconstrained growth of the routing table, right? You just need enough >>> bandwidth and interrupts to deal with updates. >> >> With enough thrust, pigs fly quite well. Landing can get messy though... > > I was being serious... the current 'bgp unconstrained dies' problem > isn't such a problem if you have (today): > 4-8 cores > 16 gb ram > ssd > gigabit ethernet > > or as you'd call this, your desktop computer... trying to do this on a > 600mhz mips with 512mb ram is, clearly, a problem. put modern > hardware to work and it gets simpler. Yes, the above addresses > getting/sending 'rib' data, it doesn't address programming a FIB, but > rethinking the programming of the fib a bit could, I bet, even get us > to a palatable point for a longer while, in a relatively short period > of time. Try telling this to a vendor that uses these common components (eg: Juniper) We have had numerous performance issues that have been attributed to software defects they haven't observed on their 'modern' hardware, but is visible in the prior generation or few back of routing engines. There's also the problem of fitting the data in the appropriate SRAM on a linecard which is very expensive on a per-bit basis to purchase and on a per-watt basis to operate. This is why some folks have TCAM based platforms, which have their own tradeoffs. We all can't just forward with N*10GE interfaces in a x86_64 platform. That may work if your scale is small, but when you're quite large the dynamics change considerably. Also, a "modern router" might look like this: cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of memory. Intel 686 F6M14S4 processor at 2134MHz, Revision 2.174 vs Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes of memory. Processor board ID 23671962 SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache Those that are confusing the two need to be sent to reeducation camp :) - Jared From patrick at ianai.net Tue Mar 19 18:11:54 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 19 Mar 2013 14:11:54 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> Composed on a virtual keyboard, please forgive typos. On Mar 19, 2013, at 13:45, David Conrad wrote: > On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: >> There's nothing inherent in BGP that would not work with an >> unconstrained growth of the routing table, right? You just need enough >> bandwidth and interrupts to deal with updates. > > With enough thrust, pigs fly quite well. Landing can get messy though... The demise of BGP from unrestrained table growth has been predicted for decades. Part of this is because my million dollar router has a slower central proc and less RAM than my $2k laptop. So yeah, pigs can fly with sufficient thrust, but we are currently using hamsters on a wheel level thrust. There is a middle ground. Before we claim BGP is dead again, let's take a moment and ensure we didn't cripple it first. The protocol, as Chris said, has no inherent problems scaling for the a while at least. It may not be "optimal", but there is something to be said for a protocol with a 100% installed base that works, and works well. -- TTFN, patrick From jabley at hopcount.ca Tue Mar 19 18:12:14 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 19 Mar 2013 14:12:14 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> On 2013-03-19, at 13:50, Christopher Morrow wrote: > On Tue, Mar 19, 2013 at 1:45 PM, David Conrad wrote: >> On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: >>> There's nothing inherent in BGP that would not work with an >>> unconstrained growth of the routing table, right? You just need enough >>> bandwidth and interrupts to deal with updates. >> >> With enough thrust, pigs fly quite well. Landing can get messy though... > > I was being serious... the current 'bgp unconstrained dies' problem > isn't such a problem if you have (today): We've been watching unconstrained growth of the routing table for quite some time, and the result is an Internet that still keeps the unwashed masses Harlem shaking. It doesn't *look* like a picture of dramatic, world-ending instability. There's no obvious indicator in the story so far to confirm the prediction "unconstrained growth of the routing table will kill the Internet". Which is not to say that the prediction is wrong, but at some point you've got to look at the guy wearing the sign with the crazed expression and wonder whether he's a couple of sandwiches short of a picnic. You could say that growth in the routing system to date *has* been constrained, by economics or regulation or RIR policies or uptake of 32-bit AS numbers or something else, and express concern that those constraints are changing and that change is dangerous. But after a while your hands get tired and you have to stop waving them. We've been saying "unconstrained growth bad" for BGP for years. Presumably we're not all insane. Where is the science? Joe From morrowc.lists at gmail.com Tue Mar 19 18:12:39 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 14:12:39 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net> Message-ID: On Tue, Mar 19, 2013 at 1:57 PM, Jared Mauch wrote: > > On Mar 19, 2013, at 1:50 PM, Christopher Morrow wrote: > >> On Tue, Mar 19, 2013 at 1:45 PM, David Conrad wrote: >>> On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: >>>> There's nothing inherent in BGP that would not work with an >>>> unconstrained growth of the routing table, right? You just need enough >>>> bandwidth and interrupts to deal with updates. >>> >>> With enough thrust, pigs fly quite well. Landing can get messy though... >> >> I was being serious... the current 'bgp unconstrained dies' problem >> isn't such a problem if you have (today): >> 4-8 cores >> 16 gb ram >> ssd >> gigabit ethernet >> >> or as you'd call this, your desktop computer... trying to do this on a >> 600mhz mips with 512mb ram is, clearly, a problem. put modern >> hardware to work and it gets simpler. Yes, the above addresses >> getting/sending 'rib' data, it doesn't address programming a FIB, but >> rethinking the programming of the fib a bit could, I bet, even get us >> to a palatable point for a longer while, in a relatively short period >> of time. > > Try telling this to a vendor that uses these common components (eg: Juniper) you mean a vendor embeded in their current design? ok. > We have had numerous performance issues that have been attributed to software defects they haven't observed on their 'modern' hardware, but is visible in the prior generation or few back of routing engines. > > There's also the problem of fitting the data in the appropriate SRAM on a linecard which is very expensive on a per-bit basis to purchase and on a per-watt basis to operate. This is why some folks have TCAM based platforms, which have their own tradeoffs. > right, these are design choices they made ~10 years ago and didn't upgrade along with the problem space. I'm really saying that we almost have to take a fresh slate look at the problem... 'if you could do things again, without the constraints of what we have today' > We all can't just forward with N*10GE interfaces in a x86_64 platform. That may work if your scale is small, but when you're quite large the dynamics change considerably. > sure thing. > Also, a "modern router" might look like this: > > cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of memory. > Intel 686 F6M14S4 processor at 2134MHz, Revision 2.174 > > vs > > Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes of memory. > Processor board ID 23671962 > SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache > > > Those that are confusing the two need to be sent to reeducation camp :) yes, still all single threaded and single core and ... :( 32bit, woot :( so constrained to some extent on max-memory and address space. also, I don't think this is 'just that simple'... but the tools exist. From drc at virtualized.org Tue Mar 19 18:12:46 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Mar 2013 11:12:46 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: <317CC7DB-D66B-4FE0-A22C-390041E1B509@virtualized.org> Chris, On Mar 19, 2013, at 10:50 AM, Christopher Morrow wrote: >> With enough thrust, pigs fly quite well. Landing can get messy though... > I was being serious... As was I. > put modern hardware to work and it gets simpler. Yes, applying more thrust makes things simpler: all you need is money, bandwidth capacity, rackspace, power, cooling, time (to replace old equipment), etc. Moore's Law will probably save us. Probably. But I know you know all of this. Where I think things get a bit more interesting is if you assume smaller and smaller businesses start seeing "always on" Internet sufficiently important as to justify multihoming with PI. In the US alone there are 6M SMEs with payrolls (21M without). Perhaps router vendors should adopt Doritos motto: "crunch all you want, we'll make more"... Regards, -drc From patrick at ianai.net Tue Mar 19 18:15:37 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 19 Mar 2013 14:15:37 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net> Message-ID: Composed on a virtual keyboard, please forgive typos. On Mar 19, 2013, at 13:57, Jared Mauch wrote: > > On Mar 19, 2013, at 1:50 PM, Christopher Morrow wrote: > >> On Tue, Mar 19, 2013 at 1:45 PM, David Conrad wrote: >>> On Mar 19, 2013, at 10:12 AM, Christopher Morrow wrote: >>>> There's nothing inherent in BGP that would not work with an >>>> unconstrained growth of the routing table, right? You just need enough >>>> bandwidth and interrupts to deal with updates. >>> >>> With enough thrust, pigs fly quite well. Landing can get messy though... >> >> I was being serious... the current 'bgp unconstrained dies' problem >> isn't such a problem if you have (today): >> 4-8 cores >> 16 gb ram >> ssd >> gigabit ethernet >> >> or as you'd call this, your desktop computer... trying to do this on a >> 600mhz mips with 512mb ram is, clearly, a problem. put modern >> hardware to work and it gets simpler. Yes, the above addresses >> getting/sending 'rib' data, it doesn't address programming a FIB, but >> rethinking the programming of the fib a bit could, I bet, even get us >> to a palatable point for a longer while, in a relatively short period >> of time. > > Try telling this to a vendor that uses these common components (eg: Juniper) > > We have had numerous performance issues that have been attributed to software defects they haven't observed on their 'modern' hardware, but is visible in the prior generation or few back of routing engines. > > There's also the problem of fitting the data in the appropriate SRAM on a linecard which is very expensive on a per-bit basis to purchase and on a per-watt basis to operate. This is why some folks have TCAM based platforms, which have their own tradeoffs. Has anyone implemented (properly) FIB compression? Will LISP get is an order of magnitude gain over proper FIB compression? (Honest question, don't know enough about LISP to say.) > We all can't just forward with N*10GE interfaces in a x86_64 platform. That may work if your scale is small, but when you're quite large the dynamics change considerably. > > Also, a "modern router" might look like this: > > cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of memory. > Intel 686 F6M14S4 processor at 2134MHz, Revision 2.174 > > vs > > Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes of memory. > Processor board ID 23671962 > SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache > > > Those that are confusing the two need to be sent to reeducation camp :) And do you have the slightest problem with BGP churn / convergence / filtering / etc. on the former? -- TTFN, patrick From morrowc.lists at gmail.com Tue Mar 19 18:22:49 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 14:22:49 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> Message-ID: On Tue, Mar 19, 2013 at 2:12 PM, Joe Abley wrote: > Which is not to say that the prediction is wrong, but at some point you've got to look at the guy wearing the sign with the crazed expression and wonder whether he's a couple of sandwiches short of a picnic. i also brought wine to the picnic, want to come with me now? From jared at puck.nether.net Tue Mar 19 18:26:29 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Mar 2013 14:26:29 -0400 Subject: routing table go boom (was: Re: [c-nsp] DNS amplification) In-Reply-To: <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> Message-ID: <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> On Mar 19, 2013, at 2:12 PM, Joe Abley wrote: > We've been saying "unconstrained growth bad" for BGP for years. Presumably we're not all insane. Where is the science? I think there is a lot of fear around this topic. I'm waiting to see the great meltdown at 512k fib entries in networks. We saw the same at 128k and 256k with some platforms. The impact on 512k will be just as great if not larger, but also very transient. I've observed a great deal of asymmetrical BGP participants in recent years. They send a set of routes, sometimes small for their own global good, but take only on-net or default routes from their providers. There is also the fact that many traffic-engineering techniques are quite coarse due to the protocol design. The days of using prepending and aggregation/deaggregation are still with us, even when more sophisticated methods (communities, etc..) exist. I'm starting to decide that the real issue is that most people just can't route (including some major networks). The system works because the broken part gets greased, but there are a lot of cosmetic and non-cosmetic defects that linger because people don't realize they are there or are a problem. If you want data on that, including my minimalistic "faux" science, there is plenty to be had. - Jared From morrowc.lists at gmail.com Tue Mar 19 18:27:47 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 14:27:47 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <317CC7DB-D66B-4FE0-A22C-390041E1B509@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <317CC7DB-D66B-4FE0-A22C-390041E1B509@virtualized.org> Message-ID: On Tue, Mar 19, 2013 at 2:12 PM, David Conrad wrote: > Chris, > > On Mar 19, 2013, at 10:50 AM, Christopher Morrow wrote: >>> With enough thrust, pigs fly quite well. Landing can get messy though... >> I was being serious... > > As was I. :) >> put modern hardware to work and it gets simpler. > > Yes, applying more thrust makes things simpler: all you need is money, bandwidth capacity, rackspace, power, cooling, time (to replace old equipment), etc. Moore's Law will probably save us. Probably. > > But I know you know all of this. > tli says moore's law doesn't apply to routing gear (in the large-hardware world)... he's been wrong once or twice, but his slides seemed convincing (to me). I take your point though, there's a cost to getting out of the hole (if there is a hole,ie: @jabley) I also think we don't have to do this 'today', but getting the right plans in place to migrate in the right direction seems like an ok plan too. > Where I think things get a bit more interesting is if you assume smaller and smaller businesses start seeing "always on" Internet sufficiently important as to justify multihoming with PI. In the US alone there are 6M SMEs with payrolls (21M without). Perhaps router vendors should adopt Doritos motto: "crunch all you want, we'll make more"... > no doubt, this is marshall's numbers (or a form of them) from ~7+ yrs ago now? which ted and I used ~6 yrs ago to (un)successfully argue that we (the intertubes) need something more than multihoming as we have it today in ipv4/ipv6... sharing that state across the globe is expensive in today's hardware (or yesteryear's hardware). I totally think that as the intertubes become more and more 'critical' to people's business(es) we'll see more and more regulation that, as a side effect, leads to more reliable connectivity being demanded. That'll be nice, in a way :) anyway, we seem to mostly agree, which again makes me realize I'm not crazy... but I stil have wine and sandwiches, come along with jabley and I? -chris From drc at virtualized.org Tue Mar 19 18:33:33 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Mar 2013 11:33:33 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> Message-ID: <153E118A-70F0-484D-AEBE-F744C372ABC3@virtualized.org> On Mar 19, 2013, at 11:11 AM, Patrick W. Gilmore wrote: > The demise of BGP from unrestrained table growth has been predicted for decades. The exhaustion of IPv4 has been predicted for decades. > Part of this is because my million dollar router has a slower central proc and less RAM than my $2k laptop. So yeah, pigs can fly with sufficient thrust, but we are currently using hamsters on a wheel level thrust. There is a middle ground. Sure. However, oddly, vendors haven't been rushing to do this. I suspect (but do not know for sure) this might be because the market for non-hamster driven routers is pretty small and the requirements that market has can be quite hard to meet ("you want packets switched how fast? with how many millions of knobs?"). Maybe the market will change or a new entrant will come along and upset the applecart (and not be acquired to be killed). > Before we claim BGP is dead again, let's take a moment and ensure we didn't cripple it first. The protocol, as Chris said, has no inherent problems scaling for the a while at least. DId someone claim BGP was dead? > It may not be "optimal", but there is something to be said for a protocol with a 100% installed base that works, and works well. LISP doesn't replace BGP. It merely adds a layer of indirection so you don't have to propagate identity information along with routing topology, allowing much greater aggregation. Regards, -drc From jared at puck.nether.net Tue Mar 19 18:32:36 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Mar 2013 14:32:36 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net> Message-ID: <67C9BBD0-ED6C-4184-A0FA-93A34757F2AF@puck.nether.net> On Mar 19, 2013, at 2:15 PM, "Patrick W. Gilmore" wrote: > Has anyone implemented (properly) FIB compression? Since you say FIB, yes. If all RIB prefixes and their sub-prefixes go the same next-hop, then you don't need to install additional entries in the FIB. Some platforms only can install ~8k/second. Reducing duplicate entries is always helpful. One can't do RIB compression due to the nature of the protocol. - Jared From drc at virtualized.org Tue Mar 19 18:44:12 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Mar 2013 11:44:12 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <317CC7DB-D66B-4FE0-A22C-390041E1B509@virtualized.org> Message-ID: <8D8B5172-2EAD-410D-B743-95275AA90A9C@virtualized.org> Chris, On Mar 19, 2013, at 11:27 AM, Christopher Morrow wrote: > I also think we don't have to do this 'today', but getting the right > plans in place to migrate in the right direction seems like an ok plan > too. +1 For that plan I personally like the idea of the layer of indirection separating identification from location as I see it having lots of benefits like scalability, site multi-homing without BGP-fu, provider independence, etc. albeit at a complexity/performance cost. The advantage I see in LISP(-like) approaches is that it pushes that cost out to the edge where all you need to do is give your hamsters vitamins, leaving the core untouched. >> In the US alone there are 6M SMEs with payrolls (21M without). Perhaps router vendors should adopt Doritos motto: "crunch all you want, we'll make more"... > > no doubt, this is marshall's numbers (or a form of them) from ~7+ yrs ago now? I suppose from the same source (http://www.census.gov/econ/smallbus.html) > anyway, we seem to mostly agree, which again makes me realize I'm not crazy... The more likely alternative is that we both are. > but I stil have wine and sandwiches, come along with jabley and I? I'll bring the deep fried hamster. Regards, -drc From bicknell at ufp.org Tue Mar 19 18:50:33 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Mar 2013 11:50:33 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> References: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> Message-ID: <20130319185033.GA58609@ussenterprise.ufp.org> In a message written on Tue, Mar 19, 2013 at 02:11:54PM -0400, Patrick W. Gilmore wrote: > The demise of BGP from unrestrained table growth has been predicted for decades. Part of this is because my million dollar router has a slower central proc and less RAM than my $2k laptop. So yeah, pigs can fly with sufficient thrust, but we are currently using hamsters on a wheel level thrust. There is a middle ground. Many of the people arguing over the demise of BGP fail to realize this is a plot over time, and that individual points may be interesting but also misleading. The computational complexity of BGP grows over time. The drivers are well known, more routes, and more paths to those routes. This can be calculated as a theoretical (like Big-O notation style), or plotted as a historical CPU-Ops/Route type metric. This plot has some interesting step functions up and down, like the introduction of CIDR, or IPv6. On the other side is the computational power of CPU's and the size of RAM. These also grows over time, although sometimes not in the ways predicted. For instance single CPU cores hit a bit of a wall so the world went to a multi-core solution. When a router vendor choses a box their goal is to use the cheapest CPU and least memory that will stay ahead of the complexity curve over the expected life of the box. Most of the posts about the death of BGP center around a popular box at the time (AGS+, Cisco 7500, Cisco 6500-Sup720) where the vendor "got it wrong". Perhaps they picked too small of a CPU. Perhaps one of the interesting step functions happened in the world, or, much of the time, perhaps ISP's are using devices well past their original intended service life! Sometimes it's not even the router vendor's direct fault, Intel may have had problems delivering CPU's on time forcing a compromise, or the RAM market may have fallen apart due to a earthquake. Backing up to a long-ball view of the world, there's no reason to expect BGP computational load to exceed the capabilities of the CPU's likely to be in routers in the next 10-15 years. Sure, a platform or two here or there will have issues, but life will move on as it always did in the past. What I find interesting is that there hasn't been a stronger move to decouple control-plane from forwarding plane. When you look at most Juniper hardware, or even modern Cisco designs like an ASR1k/9k, they are virtually 100% separated internally. All that is lacking is a standardized interface across platforms. Juniper is actually closer given their internal ethernet connection model. Basically the question is why is an RE/RP specific to a particular chassis, or even vendor? Why aren't they modular and swappable? If I'm using an ASR9k for 10GE for a supercomputer and need only statics, why can't I put in a $2k "slow" RP? If my MX80 is doing duty for route-views why can't I put in the $25k quad-quad-core RP with 64G of RAM? Indeed, in many cases, why aren't these things an external, separately rack mountable box with simply an interconnect to speak to the control plane? I'm guessing the answer is profits. :( -- 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 morrowc.lists at gmail.com Tue Mar 19 18:57:00 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 14:57:00 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <8D8B5172-2EAD-410D-B743-95275AA90A9C@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <317CC7DB-D66B-4FE0-A22C-390041E1B509@virtualized.org> <8D8B5172-2EAD-410D-B743-95275AA90A9C@virtualized.org> Message-ID: On Tue, Mar 19, 2013 at 2:44 PM, David Conrad wrote: >> anyway, we seem to mostly agree, which again makes me realize I'm not crazy... > > The more likely alternative is that we both are. doh! the unexpected third option! >> but I stil have wine and sandwiches, come along with jabley and I? > > I'll bring the deep fried hamster. hurray! protein! From bicknell at ufp.org Tue Mar 19 18:57:06 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Mar 2013 11:57:06 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: <153E118A-70F0-484D-AEBE-F744C372ABC3@virtualized.org> References: <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <153E118A-70F0-484D-AEBE-F744C372ABC3@virtualized.org> Message-ID: <20130319185706.GB58609@ussenterprise.ufp.org> In a message written on Tue, Mar 19, 2013 at 11:33:33AM -0700, David Conrad wrote: > LISP doesn't replace BGP. It merely adds a layer of indirection so you don't have to propagate identity information along with routing topology, allowing much greater aggregation. The problem with LISP is that when the complexity of the entire system is taken into account it is not signficantly more efficient than the current system. Even if it works perfectly, it makes no economic sense to spend the time and money to swap out the current system for something with approximately the same scaling properties and costs going forward. Any replacement would probably have to be an order of magnitude better at least to justify the pain of switching. LISP also has some potential downsides at Internet scale. Those who remember the 7500 platform when caching was the rage know what happens when you have to flush the cache for example. A LISP network is a similar model, with LISP nodes caching rather than linecards. There is potential for distributed uglyness. However, the LISP folks made a rather smart course correction in my opinion, and one I never would have thought to make. The LISP testbed network proved that LISP was a nice way to overlay an arbitrary topoligy on top of the existing Internet. Compared to many other "VPN" solutions it has a lot of nice properties. Some folks are now using LISP to network a collection of sites using commodity internet access making very resiliant topologies quickly and easily. I suspect LISP may find a very productive niche. -- 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 morrowc.lists at gmail.com Tue Mar 19 18:59:42 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Mar 2013 14:59:42 -0400 Subject: [c-nsp] DNS amplification In-Reply-To: <20130319185033.GA58609@ussenterprise.ufp.org> References: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <20130319185033.GA58609@ussenterprise.ufp.org> Message-ID: On Tue, Mar 19, 2013 at 2:50 PM, Leo Bicknell wrote: > Juniper is actually closer > given their internal ethernet connection model. Basically the question > is why is an RE/RP specific to a particular chassis, or even vendor? openflow/sdn/pce ... congrats! you predicted correctly! From rdobbins at arbor.net Tue Mar 19 19:03:03 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 19 Mar 2013 19:03:03 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: <20130319185033.GA58609@ussenterprise.ufp.org> References: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <20130319185033.GA58609@ussenterprise.ufp.org> Message-ID: <0668FFB9-74B5-4BEA-8824-2E4AC45FF902@arbor.net> On Mar 20, 2013, at 1:50 AM, Leo Bicknell wrote: > What I find interesting is that there hasn't been a stronger move to decouple control-plane from forwarding plane. Given the design of TCP/IP and the routing protocols, we can't really achieve true separation at the protocol level. They simply aren't intended to work with fully de-coupled, separated signal and bearer, in old-style terminology. loud As for RP interchangeability in terms of hardware, there's no economic incentive for vendors to do this, as you say. And the designs of RP/backplane/linecard are highly interdependent. Here's some of the initial thinking which led to the promulgation of LISP: As others have noted, there are a lot of other advantages to separating locator from EID; with a system like LISP, one gains potentially very useful mechanisms for protocol transitions (i.e., IPv4 to IPv6), network mobility, 'cloud'-type applications, etc. But the thoughts contained in that preso comprise a great deal of the original motivation. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Mar 19 19:06:11 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 19 Mar 2013 19:06:11 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: <20130319185706.GB58609@ussenterprise.ufp.org> References: <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <153E118A-70F0-484D-AEBE-F744C372ABC3@virtualized.org> <20130319185706.GB58609@ussenterprise.ufp.org> Message-ID: <43730FD9-3014-4165-8F53-C2FC4EA153BF@arbor.net> On Mar 20, 2013, at 1:57 AM, Leo Bicknell wrote: > However, the LISP folks made a rather smart course correction in my opinion, and one I never would have thought to make. The LISP testbed network proved that LISP was a nice way to overlay an arbitrary topoligy on top of the existing Internet. FYI, this wasn't a 'course-correction'. It is the result of deliberate design choices and was identified as a key benefit of LISP during the initial discussions around what became known as LISP. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Tue Mar 19 19:07:14 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 19 Mar 2013 19:07:14 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <20130319185033.GA58609@ussenterprise.ufp.org> Message-ID: On Mar 20, 2013, at 1:59 AM, Christopher Morrow wrote: > openflow/sdn/pce ... congrats! you predicted correctly! The whole point of these things is to obviate the RP, et. al. - which is why the network infrastructure vendors loathe them. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From patrick at ianai.net Tue Mar 19 19:07:44 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 19 Mar 2013 15:07:44 -0400 Subject: routing table go boom (was: Re: [c-nsp] DNS amplification) In-Reply-To: <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> Message-ID: [Thanx for changing subject - should have done it myself a couple posts ago.] Composed on a virtual keyboard, please forgive typos. On Mar 19, 2013, at 14:26, Jared Mauch wrote: > On Mar 19, 2013, at 2:12 PM, Joe Abley wrote: > >> We've been saying "unconstrained growth bad" for BGP for years. Presumably we're not all insane. Where is the science? > > I think there is a lot of fear around this topic. I'm waiting to see the great meltdown at 512k fib entries in networks. We saw the same at 128k and 256k with some platforms. The impact on 512k will be just as great if not larger, but also very transient. No way we transition to LISP (or anything else) before hitting that wall. So sit back & enjoy the fireworks. My guess is they will be I impressive and short-lived. But I've been wrong before. > I've observed a great deal of asymmetrical BGP participants in recent years. They send a set of routes, sometimes small for their own global good, but take only on-net or default routes from their providers. > > There is also the fact that many traffic-engineering techniques are quite coarse due to the protocol design. The days of using prepending and aggregation/deaggregation are still with us, even when more sophisticated methods (communities, etc..) exist. I'm starting to decide that the real issue is that most people just can't route (including some major networks). The system works because the broken part gets greased, but there are a lot of cosmetic and non-cosmetic defects that linger because people don't realize they are there or are a problem. If you want data on that, including my minimalistic "faux" science, there is plenty to be had. I'm wondering why that will be any better if we swap out the underlying protocol. It's not like trying something new will -increase- the average clue level of the monkeys banging on keyboards trying to accidentally compose a routing sonnet. And up-ending the installed base is almost certainly going to decrease the d(clue)/dt, as well as the second derivative. "Never underestimate the power of human stupidity." Which is all just a fancy way of saying you can't fix people being idiots by changing a protocol, or hardware, or ... well, anything. -- TTFN, patrick From drc at virtualized.org Tue Mar 19 19:24:34 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Mar 2013 12:24:34 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: <20130319185706.GB58609@ussenterprise.ufp.org> References: <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <153E118A-70F0-484D-AEBE-F744C372ABC3@virtualized.org> <20130319185706.GB58609@ussenterprise.ufp.org> Message-ID: Leo, On Mar 19, 2013, at 11:57 AM, Leo Bicknell wrote: > In a message written on Tue, Mar 19, 2013 at 11:33:33AM -0700, David Conrad wrote: >> LISP doesn't replace BGP. It merely adds a layer of indirection so you don't have to propagate identity information along with routing topology, allowing much greater aggregation. > The problem with LISP is that when the complexity of the entire > system is taken into account it is not signficantly more efficient > than the current system. When was the last time you (as a network operator) cared about the efficiency of the entire system? LISP (and similar) system are inherently more complex because they're adding a new element to the network -- TANSTAAFL. The point is that the complexity is added at the edge where it is easy/cheap (per node or site). Yes, entire system complexity goes up. However from the perspective of the core where life is fast/expensive, complexity goes down since identity is separated from location. > A LISP network is a similar model, with LISP nodes caching rather than linecards. You're comparing the equivalent of a DNS lookup with a FIB lookup. Yes, there is a performance hit when you do the mapping of identity to location (TANSTAAFL), however this is at the edge in the millisecond DRAM-stored connection initiation world, not in the core in the nanosecond SRAM-stored packet forwarding world. Regards, -drc From dougb at dougbarton.us Tue Mar 19 20:09:26 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Mar 2013 13:09:26 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: References: <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <317CC7DB-D66B-4FE0-A22C-390041E1B509@virtualized.org> <8D8B5172-2EAD-410D-B743-95275AA90A9C@virtualized.org> Message-ID: <5148C5F6.7070703@dougbarton.us> On 03/19/2013 11:57 AM, Christopher Morrow wrote: > doh! the unexpected third option! NOOOOOBODY expects the ...oh, wait, wrong sketch. From dougb at dougbarton.us Tue Mar 19 20:16:30 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Mar 2013 13:16:30 -0700 Subject: routing table go boom In-Reply-To: <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> Message-ID: <5148C79E.9030700@dougbarton.us> With all due respect to the emperors involved, the complete "zomg, don't grow the routing table!" argument includes the seldom-stated tagline, "....faster than I want to replace my existing hardware." IOW, it's never been about the tech, or "the good of the network," it's about the capex. I'm not saying that isn't a noble, useful goal, especially when you consider the SMBs who are going to be entering the multihoming market soon as David pointed out, and also (and perhaps more importantly) the folks in the emerging economies that are still ramping up their Internet access. But focusing on the technological problems is a waste of time since they all have technological solutions. Doug From jcurran at arin.net Tue Mar 19 20:23:33 2013 From: jcurran at arin.net (John Curran) Date: Tue, 19 Mar 2013 20:23:33 +0000 Subject: using ARIN IP space outside of ARIN region In-Reply-To: <9D2644DD-00D0-4A34-B87B-B8375EAD0B6B@pch.net> References: <9F4D4FC766780045A8E7ECEA533A1A8D0354F527@CORPTPMAIL03.corp.theplatform.com> <9D2644DD-00D0-4A34-B87B-B8375EAD0B6B@pch.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748F9F26A7@CHAXCH01.corp.arin.net> On Mar 18, 2013, at 4:49 PM, Bill Woodcock wrote: > HOWEVER, we've been told in the past that space received from ARIN and used outside the ARIN region did not qualify as "utilization" for the purposes of justifying new allocations, nor were locations outside the ARIN region entitled to new allocations. We were told to get space for POPs outside of ARIN's region from the other respective RIRs. And indeed, those other RIRs have, by and large, been quite cooperative with giving us space for use within their regions, even in the cases when we had no business incorporated entity within their region. Bill - You are correct, with respect to ARIN's handling of requests which span regions: - If an organization requests resources for use outside of the ARIN region, we would deny the request and refer them to the appropriate RIR. - If an organization requests space for both in region and out of region use, we will generally only allow them to obtain the space for the portion of request that will be used in the region, based on utilization of existing blocks in the region. - We will not count space issued by another RIR as justification for an initial allocation request from ARIN. Clearly, issuance of address space across regions is an issue which is becoming more interesting in recent years. We have noted this in past Policy Experience Reports, and hope to discuss it more at the upcoming ARIN 31 meeting, so that the community can see if any policy changes are appropriate or would simplify processing of these requests. Thanks! /John John Curran President and CEO ARIN From jwininger at ifncom.net Tue Mar 19 20:47:08 2013 From: jwininger at ifncom.net (James Wininger) Date: Tue, 19 Mar 2013 20:47:08 +0000 Subject: Metasolv / Business Objects Message-ID: Anyone on the list have experience with Metasolv and or Business Objects (SAP)? We have Metasolv and are using it today, but its reporting mechanism seems to be an afterthought. To that end Business Objects (from SAP) seems the be "the solution", but from what I have seen so far I am less than impressed. Can anyone offer some insight? -- Jim Wininger jwininger at ifncom.net From drc at virtualized.org Tue Mar 19 20:48:24 2013 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Mar 2013 13:48:24 -0700 Subject: routing table go boom (was: Re: [c-nsp] DNS amplification) In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> Message-ID: <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> Patrick, On Mar 19, 2013, at 12:07 PM, Patrick W. Gilmore wrote: > Which is all just a fancy way of saying you can't fix people being idiots by changing a protocol, or hardware, or ... well, anything. One of the advantages I see in LISP(-like) solutions is that it allows multi-homing without having to do BGP... Regards, -drc From bill at herrin.us Tue Mar 19 22:24:33 2013 From: bill at herrin.us (William Herrin) Date: Tue, 19 Mar 2013 18:24:33 -0400 Subject: routing table go boom In-Reply-To: <5148C79E.9030700@dougbarton.us> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <5148C79E.9030700@dougbarton.us> Message-ID: On Tue, Mar 19, 2013 at 4:16 PM, Doug Barton wrote: > With all due respect to the emperors involved, the complete "zomg, don't > grow the routing table!" argument includes the seldom-stated tagline, > "....faster than I want to replace my existing hardware." Hi Doug, Sure, it's about the bucks. Each additional route is a collective loss of around $8,000 per year, and all of it overhead for which we can't bill specific customers. We'd prefer less of that than more. http://bill.herrin.us/network/bgpcost.html > IOW, it's never > been about the tech, or "the good of the network," it's about the capex. Actually, that's not true. There was a point in the '90s where the route count very nearly outstripped our ability to build routers which could handle it. That's when we first hit the brakes. Since then our ability to build routers has improved faster than the routing table has grown, but a material change in the rate of growth could quickly wipe out that lead. Routine full-bore multihoming for SMBs and SOHOs will have to wait for a less consumptive technology than BGP. (And if you've got the cash, call me 'cause I have a plan.) Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mohta at necom830.hpcl.titech.ac.jp Tue Mar 19 23:23:35 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 20 Mar 2013 08:23:35 +0900 Subject: routing table go boom In-Reply-To: <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> References: <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> Message-ID: <5148F377.90704@necom830.hpcl.titech.ac.jp> David Conrad wrote: > One of the advantages I see in LISP(-like) solutions is that it > allows multi-homing without having to do BGP... By having a lot larger table than BGP. http://datatracker.ietf.org/doc/draft-ietf-lisp-architecture/?include_text=1 It should be noted that the caching spoken of here is likely not classic caching, where there is a fixed/limited size cache, and entries have to be discarded to make room for newly needed entries. The economics of memory being what they are, there is no reason to discard mappings once they have been loaded (although of course implementations are free to chose to do so, if they wish to). Worse, the table is updated so frequently. http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/?include_text=1 A node may have more than one RLOC, or its RLOC may change over time (e.g. if the node is mobile), but it keeps the same EID. Assuming that there are 4G mobile devices in the world, the mapping table has more than 4G entries each updated every minute or second. The problem of LISP is that it breaks the end to end principle to introduce intelligent intermediate entities of ITR and ETR. Mobility can best be handled end to end by end systems of MN, HA and, optionally, CN. Masataka Ohta PS Considering that the Internet is connectionless because all the routers have routing tables covering all the IP addresses in realtime, LISP won't be operational unless most of routers in DFZ have full mapping table in realtime. From rdobbins at arbor.net Tue Mar 19 23:48:46 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 19 Mar 2013 23:48:46 +0000 Subject: routing table go boom In-Reply-To: <5148F377.90704@necom830.hpcl.titech.ac.jp> References: <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 20, 2013, at 6:23 AM, Masataka Ohta wrote: > The problem of LISP is that it breaks the end to end principle to introduce intelligent intermediate entities of ITR and ETR. It is always amusing to see people allude to the end-to-end principle to support their arguments, when in fact the end-to-end principle is either inapplicable to the topic at hand, or actually lends support to the opposite of their arguments. > Considering that the Internet is connectionless because all the routers have routing tables covering all the IP addresses in realtime, LISP won't be operational unless most of routers in DFZ have full mapping table in realtime. LISP gains value as more of the edge is incorporated into the system. This doesn't mean it has no value during intermediate stages of deployment. There are cogent arguments to be made against LISP and LISP-like systems. But none of those arguments have been raised in this thread, so far. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mohta at necom830.hpcl.titech.ac.jp Wed Mar 20 00:05:50 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 20 Mar 2013 09:05:50 +0900 Subject: routing table go boom In-Reply-To: References: <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> Message-ID: <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> Dobbins, Roland wrote: > It is always amusing to see people allude to the end-to-end > principle to support their arguments, when in fact the > end-to-end principle is either inapplicable to the topic > at hand, or actually lends support to the opposite of their > arguments. Abstract nonsense. > There are cogent arguments to be made against LISP and > LISP-like systems. But none of those arguments have > been raised in this thread, so far. Never ignore the following problem: Assuming that there are 4G mobile devices in the world, the mapping table has more than 4G entries each updated every minute or second. Masataka Ohta From cb.list6 at gmail.com Wed Mar 20 00:20:10 2013 From: cb.list6 at gmail.com (cb.list6) Date: Tue, 19 Mar 2013 17:20:10 -0700 Subject: ILNP FTW ... Was Re: [c-nsp] DNS amplification Message-ID: On Mar 19, 2013 8:26 PM, "David Conrad" wrote: > > Leo, > > On Mar 19, 2013, at 11:57 AM, Leo Bicknell wrote: > > In a message written on Tue, Mar 19, 2013 at 11:33:33AM -0700, David Conrad wrote: > >> LISP doesn't replace BGP. It merely adds a layer of indirection so you don't have to propagate identity information along with routing topology, allowing much greater aggregation. > > The problem with LISP is that when the complexity of the entire > > system is taken into account it is not signficantly more efficient > > than the current system. > > When was the last time you (as a network operator) cared about the efficiency of the entire system? > > LISP (and similar) system are inherently more complex because they're adding a new element to the network -- TANSTAAFL. The point is that the complexity is added at the edge where it is easy/cheap (per node or site). Yes, entire system complexity goes up. However from the perspective of the core where life is fast/expensive, complexity goes down since identity is separated from location. > As I see it, that is the fundamental problem with LISP. It wants edge investment to solve a core problem. I don't carry full routes in my core, but LISP wants me to do something to solve a problem I don't have. And, that something looks a lot like an ATM SVC (dynamic tunnels ?) That said, IMHO, ILNP is a lot more interesting in the locator / id split space.... As well as general evolution of internet architecture. LISP just has had better marketing and simpler code. Ya know, this problem would also largely be solved if everyone just switched to ipv6 and stopped using those disjointed tiny v4 blocks. Oh, but that would break Skype. Nevermind. CB > > A LISP network is a similar model, with LISP nodes caching rather than linecards. > > You're comparing the equivalent of a DNS lookup with a FIB lookup. Yes, there is a performance hit when you do the mapping of identity to location (TANSTAAFL), however this is at the edge in the millisecond DRAM-stored connection initiation world, not in the core in the nanosecond SRAM-stored packet forwarding world. > > Regards, > -drc > > From rdobbins at arbor.net Wed Mar 20 01:21:14 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 20 Mar 2013 01:21:14 +0000 Subject: routing table go boom In-Reply-To: <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> References: <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 20, 2013, at 7:05 AM, Masataka Ohta wrote: > Abstract nonsense. No, it isn't. The *actual* end-to-end principle states that whenever possible and whenever it makes sense, application-specific functionality ought to be incorporated into end-nodes rather than into intermediary systems. In the case of LISP, it can be noted that either a) the end-to-end principle has no relevance, or b) LISP is closer to adherence to the end-to-end principle than the current routing system. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mohta at necom830.hpcl.titech.ac.jp Wed Mar 20 01:39:12 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 20 Mar 2013 10:39:12 +0900 Subject: routing table go boom In-Reply-To: References: <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> Message-ID: <51491340.70203@necom830.hpcl.titech.ac.jp> Dobbins, Roland wrote: > The *actual* end-to-end principle states that whenever > possible and whenever it makes sense, application-specific > functionality ought to be incorporated into end-nodes > rather than into intermediary systems. Wrong. See below how it is stated. > b) LISP is closer to adherence to the end-to-end principle > than the current routing system. W.r.t. multihoming, neither follows the end to end principle of: http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) Masataka Ohta From rdobbins at arbor.net Wed Mar 20 02:40:42 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 20 Mar 2013 02:40:42 +0000 Subject: routing table go boom In-Reply-To: <51491340.70203@necom830.hpcl.titech.ac.jp> References: <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 20, 2013, at 8:39 AM, Masataka Ohta wrote: > Wrong. No, it isn't wrong. That's how it's interpreted: 'The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.' and 'The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)' > W.r.t. multihoming, neither follows the end to end principle of: Yes, which is why I said that it doesn't really apply in the first place. But if one insists on viewing it through the prism of the end-to-end principle, LISP adheres to it more than does the current routing system. Anyway, I'm done feeding this particular troll for good. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mohta at necom830.hpcl.titech.ac.jp Wed Mar 20 05:40:11 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 20 Mar 2013 14:40:11 +0900 Subject: routing table go boom In-Reply-To: References: <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> Message-ID: <51494BBB.50906@necom830.hpcl.titech.ac.jp> Dobbins, Roland wrote: > But if one insists on viewing it through the prism of the > end-to-end principle, LISP adheres to it more than does > the current routing system. It merely means you are using a wrong prism. Let's consider a very basic multihoming with two locators, one of which is blackholed. Then, how can an ITR, which initially choose a blackholed locator, know that the locator is not working and fall back to another locator? In general, we should assume protocol used is something unknown to the ITR (not TCP, of course) and/or not assume the ITR is on return path so that the ITR can't have any "knowledge" that an end system receiving any reply. In this case, The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. means only the higher stack of the end system have "the knowledge" that sent packets are not replied. But, the end system can't "help" the ITR, because it does not even know the ITR exist. Therefore, Therefore, providing that questioned function as a feature of the communication system itself is not possible. providing that questioned function of destination locator selection for multihoming as a feature of ITR is not possible. > Anyway, I'm done feeding this particular troll for good. Use a looking glass to see a troll. Always check the original paper to avoid wrong interpretations of yours. Masataka Ohta PS Is it time to shutdown LISP WG? From randy at psg.com Wed Mar 20 05:53:36 2013 From: randy at psg.com (Randy Bush) Date: Wed, 20 Mar 2013 07:53:36 +0200 Subject: [c-nsp] DNS amplification In-Reply-To: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: i am not saying bgp and forwarding can deal with growth forever, but o over my career, the death of spinning oxide has always been two years away. yet the hardwhere jocks have continued to pull the rabbit out of the hat. perhaps, many decades later, ssds have finally caught up and physical limits are finally approaching. o a dozen or so years ago, i shared an nsf grant with lixia, dan, and others called "better bgp," based on the assumption that bgp was not gonna scale. i took the contrary position, we actually had no clear measurement showing it was not going to scale. out of this came beacons, 'happy packets', etc. so i think we need some measurements of the sky before we can judge the rate of its descent. randy From bill at herrin.us Wed Mar 20 06:16:42 2013 From: bill at herrin.us (William Herrin) Date: Wed, 20 Mar 2013 02:16:42 -0400 Subject: routing table go boom In-Reply-To: <51494BBB.50906@necom830.hpcl.titech.ac.jp> References: <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Mar 20, 2013 at 1:40 AM, Masataka Ohta wrote: > Then, how can an ITR, which initially choose a blackholed > locator, know that the locator is not working and fall > back to another locator? > > In general, we should assume protocol used is something > unknown to the ITR (not TCP, of course) and/or not assume > the ITR is on return path so that the ITR can't have any > "knowledge" that an end system receiving any reply. I can't speak for LISP per se, but the general solution for map-encap systems like LISP is that the ITR tags the first packet to the ETR and some percentage of subsequent packets to the ETR with an ack request. If it doesn't get an ack from the ETR (not the final destination), then the ETR or the path to it is depreferenced. The ack-request tagged tunnel packets and the acks sent in response are protocol-agnostic with respect to the inner packets between the source and destination. If the ETR is unavailable, those carried packets will be dropped. The ITR cares only about promptly discovering that the ETR is unavailable so that it can select an alternate ETR which works. The error correction mechanisms in the carried protocols then take over and resolve the lost packets. The path from the ETR to the destination, and by extension the full path from the ITR to the destination, is not the ITR's responsibility. Some local system is responsible for detecting connectivity between the ETR and destination and updating the destination-to-ETR map accordingly. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From adam.vitkovsky at swan.sk Wed Mar 20 09:41:17 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Wed, 20 Mar 2013 10:41:17 +0100 Subject: [c-nsp] DNS amplification In-Reply-To: <20130319185033.GA58609@ussenterprise.ufp.org> References: <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <7C24B73C-13FA-4DF4-99AF-C78C41C5820A@ianai.net> <20130319185033.GA58609@ussenterprise.ufp.org> Message-ID: <036901ce254f$122b8850$368298f0$@swan.sk> >Indeed, in many cases, why aren't these things an external, separately rack mountable box with simply an interconnect to speak to the control plane? You mean like CRS multi-chassis systems? adam From ggx at gigix.net Wed Mar 20 11:42:26 2013 From: ggx at gigix.net (Luigi Iannone) Date: Wed, 20 Mar 2013 12:42:26 +0100 Subject: routing table go boom In-Reply-To: <5148F377.90704@necom830.hpcl.titech.ac.jp> References: <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> Message-ID: <580864AC-A0E8-4E0B-84AE-F5A5DEE43D3F@gigix.net> Hi Masataka, On 20 Mar. 2013, at 00:23 , Masataka Ohta wrote: > David Conrad wrote: > >> One of the advantages I see in LISP(-like) solutions is that it >> allows multi-homing without having to do BGP... > > By having a lot larger table than BGP. > > http://datatracker.ietf.org/doc/draft-ietf-lisp-architecture/?include_text=1 > > It should be noted that the caching spoken of here is likely not > classic caching, where there is a fixed/limited size cache, and > entries have to be discarded to make room for newly needed entries. > The economics of memory being what they are, there is no reason to > discard mappings once they have been loaded (although of course > implementations are free to chose to do so, if they wish to). LISP will not have huge caches: (1) http://www.ietf.org/proceedings/69/slides/RRG-4.pdf and more recently: (2) https://www.net.t-labs.tu-berlin.de/papers/KIF-ADDITLCAWISKAI-11.pdf > > Worse, the table is updated so frequently. > FIrst of all the table a cache is filled on-demand, so you update only what you need, secondly (1) shows that this refresh traffic is in the same order of magnitude of DNS requests. If you are able to support DNS you are able to deal with LISP cache update traffic. > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/?include_text=1 > > A node may have more than one > RLOC, or its RLOC may change over time (e.g. if the node is mobile), > but it keeps the same EID. > > Assuming that there are 4G mobile devices in the world, the > mapping table has more than 4G entries each updated every > minute or second. This is true in a push model like BGP not in LISP, which is a pull model (on-demand). > > The problem of LISP is that it breaks the end to end principle > to introduce intelligent intermediate entities of ITR and ETR. true > > Mobility can best be handled end to end by end systems of MN, > HA and, optionally, CN. > which rely on intelligent anchor nodes spread in the network, where is the difference? Luigi > Masataka Ohta > > PS > > Considering that the Internet is connectionless because all the > routers have routing tables covering all the IP addresses in > realtime, LISP won't be operational unless most of routers > in DFZ have full mapping table in realtime. > From arturo.servin at gmail.com Wed Mar 20 11:44:10 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 20 Mar 2013 08:44:10 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: <5149A10A.1010503@gmail.com> The last presentations that I saw about it said that we are going to be fine: http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf http://www.iepg.org/2011-11-ietf82/iepg-201111.pdf Regards, as On 20/03/2013 02:53, Randy Bush wrote: > i am not saying bgp and forwarding can deal with growth forever, but > > o over my career, the death of spinning oxide has always been two > years away. yet the hardwhere jocks have continued to pull the > rabbit out of the hat. perhaps, many decades later, ssds have > finally caught up and physical limits are finally approaching. > > o a dozen or so years ago, i shared an nsf grant with lixia, dan, and > others called "better bgp," based on the assumption that bgp was not > gonna scale. i took the contrary position, we actually had no clear > measurement showing it was not going to scale. out of this came > beacons, 'happy packets', etc. > > so i think we need some measurements of the sky before we can judge the > rate of its descent. > > randy > From ggx at gigix.net Wed Mar 20 11:44:27 2013 From: ggx at gigix.net (Luigi Iannone) Date: Wed, 20 Mar 2013 12:44:27 +0100 Subject: routing table go boom In-Reply-To: <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> References: <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> Message-ID: On 20 Mar. 2013, at 01:05 , Masataka Ohta wrote: > Dobbins, Roland wrote: > >> It is always amusing to see people allude to the end-to-end >> principle to support their arguments, when in fact the >> end-to-end principle is either inapplicable to the topic >> at hand, or actually lends support to the opposite of their >> arguments. > > Abstract nonsense. > >> There are cogent arguments to be made against LISP and >> LISP-like systems. But none of those arguments have >> been raised in this thread, so far. > > Never ignore the following problem: > > Assuming that there are 4G mobile devices in the world, the > mapping table has more than 4G entries each updated every > minute or second. > Masataka that's simply not true. See my proviso email. ciao Luigi > Masataka Ohta > > > From ggx at gigix.net Wed Mar 20 11:49:23 2013 From: ggx at gigix.net (Luigi Iannone) Date: Wed, 20 Mar 2013 12:49:23 +0100 Subject: routing table go boom In-Reply-To: <51494BBB.50906@necom830.hpcl.titech.ac.jp> References: <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> Message-ID: <914495A0-9C3A-4A9B-8B17-6CFFA70BAE72@gigix.net> Hi, On 20 Mar. 2013, at 06:40 , Masataka Ohta wrote: [snip] > > Then, how can an ITR, which initially choose a blackholed > locator, know that the locator is not working and fall > back to another locator? In LISP you can check reachability with the echo-nonce function. [snip] > > PS > > Is it time to shutdown LISP WG? > I do not think this is the right mailing list to discuss something like this. ciao Luigi From aledm at qix.co.uk Wed Mar 20 12:07:47 2013 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 20 Mar 2013 12:07:47 +0000 Subject: [c-nsp] DNS amplification In-Reply-To: <5149A10A.1010503@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> Message-ID: On 20 March 2013 11:44, Arturo Servin wrote: > > The last presentations that I saw about it said that we are going > to be > fine: > > http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf > http://www.iepg.org/2011-11-ietf82/iepg-201111.pdf > > > It isn't just about "imminient death of the net predicted" though - our reliance on the current BGP model for route adverisement is restricting the deployment of better connectivity paradigms. For example I know there are enterprises that would like to multihome but they find the current mechanism a barrier to this - for a start they can't justify the size of PI space that would guarantee them entry to the global routing table. ISPs differentiate between "regular" and "BGP-capable" connections - is this desirable for the evolution of the Internet? or is it the reason that BGP appears to be able to cope, because ISPs are throttling the potential growth? LISP is about seperating the role of the ISP (as routing provider) from the end user or content provider/consumer. Aled From arturo.servin at gmail.com Wed Mar 20 12:32:55 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 20 Mar 2013 09:32:55 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> Message-ID: <5149AC77.8030809@gmail.com> On 20/03/2013 09:07, Aled Morris wrote: > On 20 March 2013 11:44, Arturo Servin > wrote: > > > The last presentations that I saw about it said that we are > going to be > fine: > > http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf > http://www.iepg.org/2011-11-ietf82/iepg-201111.pdf > > > > It isn't just about "imminient death of the net predicted" though - our > reliance on the current BGP model for route adverisement is restricting > the deployment of better connectivity paradigms. Agree with that. But as today I do not think LISP would be the solution. > > For example I know there are enterprises that would like to multihome > but they find the current mechanism a barrier to this - for a start they > can't justify the size of PI space that would guarantee them entry to > the global routing table. Which is good. If they cannot justify PI space may be they should not get into the global routing table. It is a problem for them, yes. Do we have a solution? Not yet. > > ISPs differentiate between "regular" and "BGP-capable" connections - is > this desirable for the evolution of the Internet? or is it the reason > that BGP appears to be able to cope, because ISPs are throttling the > potential growth? It is an operational practice. Maintaining BGP sessions have a cost. Also, at least in the cases that I know those connections also have different SLAs which is the real cost, not just the BGP. > > LISP is about seperating the role of the ISP (as routing provider) from > the end user or content provider/consumer. Yes, but as mentioned before the cost is in the edge, the benefit in the core. The economic equation is all wrong. There is not economic incentive for the edge to deploy LISP. We are facing the same problem that we have with IPv6. Now, if with LISP as an edge site I can have multihome, high availability, not to renumber my network, or any other combination of benefits and it does cost less than PI+BGP or PA+ then it may work. > > Aled > Regards, as From patrick at ianai.net Wed Mar 20 12:40:15 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 20 Mar 2013 08:40:15 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> Message-ID: <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> Composed on a virtual keyboard, please forgive typos. On Mar 20, 2013, at 8:07, Aled Morris wrote: > On 20 March 2013 11:44, Arturo Servin wrote: > >> The last presentations that I saw about it said that we are going >> to be >> fine: >> >> http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf >> http://www.iepg.org/2011-11-ietf82/iepg-201111.pdf >> > It isn't just about "imminient death of the net predicted" though - our > reliance on the current BGP model for route adverisement is restricting the > deployment of better connectivity paradigms. > > For example I know there are enterprises that would like to multihome but > they find the current mechanism a barrier to this - for a start they can't > justify the size of PI space that would guarantee them entry to the global > routing table. Then they are not well educated. Which is not surprising, and unlikely to change of we change the underlying protocol. The barrier to entry for multihoming has never been lower. Moreover, not sure it is the protocol's job to lower it further. > ISPs differentiate between "regular" and "BGP-capable" connections - is > this desirable for the evolution of the Internet? or is it the reason that > BGP appears to be able to cope, because ISPs are throttling the potential > growth? I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs....) And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. > LISP is about seperating the role of the ISP (as routing provider) from the > end user or content provider/consumer. I am unconvinced that is a good idea. At least using the definition of "end use" or "consumer" I frequently hear. -- TTFN, patrick From owen at delong.com Wed Mar 20 13:25:11 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Mar 2013 08:25:11 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> Message-ID: <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> > I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) Comcast Verizon AT&T Time Warner Cable Cox CenturyLink to name a few. Not one of them will run BGP with a residential subscriber. > And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. Sure they are. If they weren't, it would be relatively straight forward to add the necessary options to DHCP for a minimal (accept default, advertise local) BGP configuration and it would be quite simple for CPE router manufacturers to incorporate those capabilities. The problem is BGP doesn't scale to that level and everyone knows it, so, we limit growth by not allowing it to be a possibility. You are right, however, LISP won't change that. >> LISP is about seperating the role of the ISP (as routing provider) from the >> end user or content provider/consumer. > > I am unconvinced that is a good idea. At least using the definition of "end use" or "consumer" I frequently hear. +1 However, a locator/id separation without map/encap is a desirable thing that could allow the routing system to scale better. Unfortunately, we failed to address this issue when designing IPv6. It will not get correctly solved without a revision to the header design. There is no will to change the packet header in the near future. We're having too much "fun" rolling out the current one. Owen From ml at kenweb.org Wed Mar 20 14:31:01 2013 From: ml at kenweb.org (ML) Date: Wed, 20 Mar 2013 10:31:01 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> Message-ID: <5149C825.8090604@kenweb.org> On 3/20/2013 9:25 AM, Owen DeLong wrote: >> I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) > Comcast > Verizon > AT&T > Time Warner Cable > Cox > CenturyLink > > to name a few. > > Not one of them will run BGP with a residential subscriber. > >> And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. > Sure they are. If they weren't, it would be relatively straight forward to add the necessary options to DHCP for a minimal (accept default, advertise local) BGP configuration and it would be quite simple for CPE router manufacturers to incorporate those capabilities. > > The problem is BGP doesn't scale to that level and everyone knows it, so, we limit growth by not allowing it to be a possibility. > Is someone working on 8-byte ASNs yet? From sethm at rollernet.us Wed Mar 20 14:55:31 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 20 Mar 2013 07:55:31 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> Message-ID: <5149CDE3.2020507@rollernet.us> On 3/20/13 6:25 AM, Owen DeLong wrote: >> I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) > > Comcast > Verizon > AT&T > Time Warner Cable > Cox > CenturyLink > > to name a few. > > Not one of them will run BGP with a residential subscriber. > Based on the average clue of your average residential subscriber (anyone here need not apply) I'd say that's a good thing. ~Seth From patrick at ianai.net Wed Mar 20 15:18:38 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 20 Mar 2013 11:18:38 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.c om> Message-ID: <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF@ianai.net> On Mar 20, 2013, at 09:25 , Owen DeLong wrote: >> I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) > > Comcast > Verizon > AT&T > Time Warner Cable > Cox > CenturyLink > > to name a few. > > Not one of them will run BGP with a residential subscriber. Who cares? [See below.] >> And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. > > Sure they are. If they weren't, it would be relatively straight forward to add the necessary options to DHCP for a minimal (accept default, advertise local) BGP configuration and it would be quite simple for CPE router manufacturers to incorporate those capabilities. > > The problem is BGP doesn't scale to that level and everyone knows it, so, we limit growth by not allowing it to be a possibility. This is patently false. No network has a decision matrix that is "BGP doesn't scale, so let's refuse money from customers". Every single one of the companies you listed will run BGP with customers. You limited this to "residential subscriber". Companies do not have only "residential customers". Pay more, get more. Pay $40, get less. Shocker. "Not if you don't pay for it" is not a valid argument against "every $COMPANY has $FEATURE". I said the barrier to entry for multihoming was lower than it has ever been. I didn't say it was zero. You are a pretty smart guy, so I'm going to give you the benefit of the doubt and assume you just kinda-sortta forgot or did not consider the whole "money" thing, despite the fact the only reason nearly every Internet entity exists. (Now I wonder how many people are going to tell me about the N% which are non-profits, despite the fact I said "nearly"?) -- TTFN, patrick > You are right, however, LISP won't change that. > >>> LISP is about seperating the role of the ISP (as routing provider) from the >>> end user or content provider/consumer. >> >> I am unconvinced that is a good idea. At least using the definition of "end use" or "consumer" I frequently hear. > > +1 > > However, a locator/id separation without map/encap is a desirable thing that could allow the routing system to scale better. Unfortunately, we failed to address this issue when designing IPv6. It will not get correctly solved without a revision to the header design. There is no will to change the packet header in the near future. We're having too much "fun" rolling out the current one. > > Owen > From jcurran at istaff.org Wed Mar 20 15:25:59 2013 From: jcurran at istaff.org (John Curran) Date: Wed, 20 Mar 2013 09:25:59 -0600 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> Message-ID: <53CF2D6C-EB9A-4AE5-9AAC-922A6972B140@istaff.org> On Mar 20, 2013, at 7:25 AM, Owen DeLong wrote: >> And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. > > Sure they are. If they weren't, it would be relatively straight forward to add the necessary options to DHCP for a minimal (accept default, advertise local) BGP configuration and it would be quite simple for CPE router manufacturers to incorporate those capabilities. > > The problem is BGP doesn't scale to that level and everyone knows it, so, we limit growth by not allowing it to be a possibility. I suspect it has nothing to do with the scaling properties of routing tables and everything to do with customer support costs. The metrics associated with broadband services are quite daunting; i.e. costs from a single technical customer support call can exceed the entire expected profit over the typical customer contract period... In such circumstances, you really don't want any quantity of residential customers running BGP, as it increases the probability of customer care calls. It's only at a different revenue point (i.e. "small-business service") that it becomes viable. FYI, /John From drc at virtualized.org Wed Mar 20 15:26:53 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 20 Mar 2013 08:26:53 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: <5149AC77.8030809@gmail.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <5149AC77.8030809@gmail.com> Message-ID: <5549A641-4F3B-4E9E-9D90-F127E313A5B4@virtualized.org> Arturo, On Mar 20, 2013, at 5:32 AM, Arturo Servin wrote: >> For example I know there are enterprises that would like to multihome >> but they find the current mechanism a barrier to this - for a start they >> can't justify the size of PI space that would guarantee them entry to >> the global routing table. > > Which is good. If they cannot justify PI space may be they should not > get into the global routing table. The implication of this statement is that if you cannot afford the RIR fees, the routers, the technical expertise to run those routers, the additional opex associated with "BGP-capable" Internet connectivity, etc., the services/content you provide don't deserve resiliency/redundancy/etc. I have trouble seeing how this can be called "good". A "necessary evil given broken technology" perhaps, but not "good". >> LISP is about seperating the role of the ISP (as routing provider) from >> the end user or content provider/consumer. > > Yes, but as mentioned before the cost is in the edge, the benefit in > the core. Being able to effectively multi-home without BGP, removing the need to ever renumber, etc., all sound like benefits to the edge to me. > The economic equation is all wrong. People keep saying this. For core providers, the equation doesn't change. Well, OK, they may lose the additional fees they get for "BGP-capable" connections and they won't have the 'benefit' of the cost of renumbering to reduce customer thrash, however they continue to get paid for providing connectivity services. They might even save some money in the long run as they won't need to replace their hamsters with guinea pigs quite as frequently. For edges, the addition of a network element gives them freedom and resiliency at the cost of additional complexity and a bit of additional latency/reduced bandwidth. However, it is the edges that would pay the cost to get the benefit. I have trouble seeing how this economic equation is wrong. > There is not economic incentive for the edge to deploy LISP. We are facing the same problem > that we have with IPv6. Not really. For example, you (or somebody) have to edit/recompile code to use IPv6. You do not have to recompile code to use LISP. Regards, -drc From drc at virtualized.org Wed Mar 20 15:34:10 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 20 Mar 2013 08:34:10 -0700 Subject: [c-nsp] DNS amplification In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> Message-ID: <05A55837-E210-458B-8CCF-669F64EC67D9@virtualized.org> Randy, On Mar 19, 2013, at 10:53 PM, Randy Bush wrote: > i am not saying bgp and forwarding can deal with growth forever, As I said when I started tilting at this particular windmill, with enough thrust pigs can fly quite well. However, perhaps instead of attaching bigger/hotter/more expensive rocket engines to the pig, moving to a more suitable lifting body might both reduce the need for the engine upgrades as well as provide some benefits to the folks wanting to buy airfare. Regards, -drc From jabley at hopcount.ca Wed Mar 20 15:39:38 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 20 Mar 2013 11:39:38 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <5149CDE3.2020507@rollernet.us> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> Message-ID: <70C736A0-38E8-41C1-B228-6BFB8B23C215@hopcount.ca> On 2013-03-20, at 10:55, Seth Mattinen wrote: > On 3/20/13 6:25 AM, Owen DeLong wrote: >>> I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) >> >> Comcast >> Verizon >> AT&T >> Time Warner Cable >> Cox >> CenturyLink >> >> to name a few. >> >> Not one of them will run BGP with a residential subscriber. > > Based on the average clue of your average residential subscriber (anyone > here need not apply) I'd say that's a good thing. In practice, it seems to me that the way people multi-home these days for client-filled networks is: 1. Number everything internally using private-use addresses 2. Use one NAT per upstream 3. Send your outbound flows through whichever NAT seems appropriate There seem to be no shortage of SMB appliances that will take care of this for you without you having to understand anything. The phrase that seems to be used when describing these routers is "dual WAN". https://www.mushroomnetworks.com http://www.peplink.com/balance/ http://www.tp-link.com/ http://www.draytek.com/ It's trivial to configure this kind of thing on more general-purpose gear too, obviously, but that requires Actual Knowledge of How Things Work whereas these products aim to get things running without any of that. This style of multi-homing is invisible from the perspective of the routing system. Obviously this doesn't work nicely for inbound connections, but the fact that people do it anyway suggests that isn't a deal-killer (presumably every server that needs to accept an inbound connection these days lives elsewhere, in someone's cloud). I'm not suggesting this is good architecture, but it happens. Even if BGP on res-grade internet access products was trivially available, I can see this kind of NAT hack being more popular. I think it's incorrect to insist that the Network doesn't support pervasive end-site multi-homing when it's clear that people are doing it anyway. Joe From mohta at necom830.hpcl.titech.ac.jp Wed Mar 20 15:42:05 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 00:42:05 +0900 Subject: routing table go boom In-Reply-To: References: <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> Message-ID: <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> William Herrin wrote: > I can't speak for LISP per se, but the general solution for map-encap > systems like LISP is that the ITR tags the first packet to the ETR and > some percentage of subsequent packets to the ETR with an ack request. > If it doesn't get an ack from the ETR (not the final destination), > then the ETR or the path to it is depreferenced. As the ETR is not the final destination, it is subject to blackholing after ETR, which means: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Granted that it is no worse than multihoming by routing protocols. But, it merely means that neither BGP nor LISP works "completely and correctly". > The path from the ETR to the destination, and by extension the full > path from the ITR to the destination, is not the ITR's responsibility. It merely means that LISP is not end to end, because of not ITRs but ETRs. In addition, that the ITR, which may be located near the destination rather than source, can not receive ACKs does not mean the end system can not receive ACKs, which is ITR related lack of "completely and correctly" property. > Some local system is responsible for detecting connectivity between > the ETR and destination and updating the destination-to-ETR map > accordingly. Some local system? Such a local system must, according to the end to end argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. needs "knowledge and help of the application standing at the endpoints of the communication system" involving LISP++ specific protocol changes of the end systems. If you require all the end systems local to ETRs compliant to some new protocol, do it locally only on the end systems, from the beginning, without involving intelligent intermediate entities of *TRs only to make it work not "completely and correctly" Masataka Ohta From sander at steffann.nl Wed Mar 20 16:33:09 2013 From: sander at steffann.nl (Sander Steffann) Date: Wed, 20 Mar 2013 17:33:09 +0100 Subject: routing table go boom In-Reply-To: <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> References: <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> Message-ID: Hi, > As the ETR is not the final destination, it is subject to blackholing > after ETR, which means: > > The function in question can completely and correctly be > implemented only with the knowledge and help of the > application standing at the endpoints of the communication > system. > > Granted that it is no worse than multihoming by routing protocols. > > But, it merely means that neither BGP nor LISP works "completely > and correctly". Well, yeah, if your internal routing (behind the ETR) breaks then your network is broken... Met vriendelijke groet, Sander Steffann From bruns at 2mbit.com Wed Mar 20 16:36:13 2013 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 Mar 2013 10:36:13 -0600 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> Message-ID: <5149E57D.3080504@2mbit.com> On 3/20/13 6:40 AM, Patrick W. Gilmore wrote: > I don't know a single ISP that wants to throttle growth by not > accepting additional customers, BGP speaking or not. (I do know > several that want to throttle growth through not upgrading their > links because they have a captive audience they are trying to ransom. > But that is neither relevant to this discussion, not controversial - > unless you are paid by one of those ISPs....) Ran across more then one in the Idaho/Oregon/Washington State area that told me it was "too hard" for them to do BGP with customers, or my favorite, that it would cost over 1k USD for setup, and 500 USD a month to do a BGP session with them from our rack in their data center. Some are either just lazy or incompetent. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mike-nanog at tiedyenetworks.com Wed Mar 20 17:30:36 2013 From: mike-nanog at tiedyenetworks.com (Mike) Date: Wed, 20 Mar 2013 10:30:36 -0700 Subject: routing table go boom In-Reply-To: References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> Message-ID: <5149F23C.20804@tiedyenetworks.com> I appreciate everyones comments on this issue but I think you nay-sayers are going to lose. I think the future of the internet is distributed routing where the end points ultimately decide how their packets flow. I think joe 6-pack should in fact be able to be connected to as many providers as he wants, should be able to specify any mixture of connections from consumer dsl to carrier ethernet or beyond, and have the same level of service as multi-homed bgp speaking networks do today in terms of route diversity, fail-over and 'portability' (in terms of bringing your netblocks to another provider). Not a troll, just looking at the future here. Mike- From matthew at walster.org Wed Mar 20 17:43:02 2013 From: matthew at walster.org (Matthew Walster) Date: Wed, 20 Mar 2013 17:43:02 +0000 Subject: routing table go boom In-Reply-To: <5149F23C.20804@tiedyenetworks.com> References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> <5149F23C.20804@tiedyenetworks.com> Message-ID: On 20 March 2013 17:30, Mike wrote: > > I appreciate everyones comments on this issue but I think you > nay-sayers are going to lose. I think the future of the internet is > distributed routing where the end points ultimately decide how their > packets flow. > You have actually *heard* of BGP version 4, right? We've only been using it for 20 years, you'd have thought people would switch to it in their masses... M From jared at puck.nether.net Wed Mar 20 17:44:25 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Mar 2013 13:44:25 -0400 Subject: routing table go boom In-Reply-To: <5149F23C.20804@tiedyenetworks.com> References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> <5149F23C.208! 04@tiedyenetworks.com> Message-ID: <21F2F092-F7D5-4EC4-8BCE-B9240E61A7BF@puck.nether.net> On Mar 20, 2013, at 1:30 PM, Mike wrote: > > > I appreciate everyones comments on this issue but I think you > nay-sayers are going to lose. I think the future of the internet is > distributed routing where the end points ultimately decide how their > packets flow. I think joe 6-pack should in fact be able to be connected > to as many providers as he wants, should be able to specify any mixture > of connections from consumer dsl to carrier ethernet or beyond, and have > the same level of service as multi-homed bgp speaking networks do today > in terms of route diversity, fail-over and 'portability' (in terms of > bringing your netblocks to another provider). Not a troll, just looking > at the future here. I certainly think there's a lot that can be done at middle-layers, eg: tunnels to a few different providers. I can be on a Comcast CM and ATT DSL link and establish a link to a tunnel destination in Chicago that is low-latency for me and the bits will all flow that way. The last mile loop problem though? As of today, neither of those two providers reaches my home with their service. I doubt I'm going to see a lot of choice unless the market changes considerably. The last-mile costs are all in the contractors, permits and engineering studies for weight on the poles. (Or directional boring/conduit costs underground). Locally the permit is $200/road crossed, either above or under, this starts to contribute to the build cost in unexpected ways. If you looked at the google fiber proposal, they wanted space on both poles and otherwise to minimize permitting and other costs. Last time I talked to someone about outside plant construction the answer was the cost was functionally strand-agnostic. That tells me the cost isn't in the cabling. - Jared From jared at puck.nether.net Wed Mar 20 17:50:50 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Mar 2013 13:50:50 -0400 Subject: routing table go boom In-Reply-To: References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> <5149F23C.20804@tiedyenetworks.com> Message-ID: On Mar 20, 2013, at 1:43 PM, Matthew Walster wrote: > On 20 March 2013 17:30, Mike wrote: >> >> I appreciate everyones comments on this issue but I think you >> nay-sayers are going to lose. I think the future of the internet is >> distributed routing where the end points ultimately decide how their >> packets flow. >> > > You have actually *heard* of BGP version 4, right? We've only been using it > for 20 years, you'd have thought people would switch to it in their > masses... What's interesting is I see more people (eg: datacenter operators) pushing for BGP in their devices, and scale in them because it is well fed and maintained vs trusting/using OSPF/CLNS/ISIS and getting the performance limits there fixed. They would rather use the TCP timeouts vs OSPF timeouts for link discovery and routing performance. This tells me there is perhaps a gap in capabilities or performance that isn't well documented and being worked around. - Jared From bruns at 2mbit.com Wed Mar 20 18:04:34 2013 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 Mar 2013 12:04:34 -0600 Subject: routing table go boom In-Reply-To: <5149F23C.20804@tiedyenetworks.com> References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> <5149F23C.20804@tiedyenetworks.com> Message-ID: <5149FA32.3090500@2mbit.com> On 3/20/13 11:30 AM, Mike wrote: > > > I appreciate everyones comments on this issue but I think you > nay-sayers are going to lose. I think the future of the internet is > distributed routing where the end points ultimately decide how their > packets flow. I think joe 6-pack should in fact be able to be connected > to as many providers as he wants, should be able to specify any mixture > of connections from consumer dsl to carrier ethernet or beyond, and have > the same level of service as multi-homed bgp speaking networks do today > in terms of route diversity, fail-over and 'portability' (in terms of > bringing your netblocks to another provider). Not a troll, just looking > at the future here. > Why did I just suddenly have a flashback to this? https://www.nanog.org/mailinglist/mailarchives/old_archive/2003-10/msg01440.html -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bill at herrin.us Wed Mar 20 18:51:22 2013 From: bill at herrin.us (William Herrin) Date: Wed, 20 Mar 2013 14:51:22 -0400 Subject: routing table go boom In-Reply-To: <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> References: <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Mar 20, 2013 at 11:42 AM, Masataka Ohta wrote: > William Herrin wrote: >> I can't speak for LISP per se, but the general solution for map-encap >> systems like LISP is that the ITR tags the first packet to the ETR and >> some percentage of subsequent packets to the ETR with an ack request. >> If it doesn't get an ack from the ETR (not the final destination), >> then the ETR or the path to it is depreferenced. > > As the ETR is not the final destination, it is subject to blackholing > after ETR, which means: >> The path from the ETR to the destination, and by extension the full >> path from the ITR to the destination, is not the ITR's responsibility. Already had the correct answer in there; you didn't need to restate it. > It merely means that LISP is not end to end Yeah. LISP provides virtual packet-switched data circuits. Like a metro-ethernet from here to my ISP. The protocols transiting LISP are what's end to end. And no aspect of LISP that I'm aware of compels changed behavior by those protocols. >> Some local system is responsible for detecting connectivity between >> the ETR and destination and updating the destination-to-ETR map >> accordingly. > > Some local system? Yeah, you know, like OSPF or EIGRP. Just like exporting a route from the IGP to the EGP except that you're exporting a route from the IGP to the LISP map instead. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From arturo.servin at gmail.com Wed Mar 20 18:53:41 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 20 Mar 2013 15:53:41 -0300 Subject: [c-nsp] DNS amplification In-Reply-To: <5549A641-4F3B-4E9E-9D90-F127E313A5B4@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <5149AC77.8030809@gmail.com> <5549A641-4F3B-4E9E-9D90-F127E313A5B4@virtualized.org> Message-ID: <514A05B5.3060502@gmail.com> On 3/20/13 12:26 PM, David Conrad wrote: > Arturo, > > On Mar 20, 2013, at 5:32 AM, Arturo Servin wrote: >>> For example I know there are enterprises that would like to multihome >>> but they find the current mechanism a barrier to this - for a start they >>> can't justify the size of PI space that would guarantee them entry to >>> the global routing table. >> >> Which is good. If they cannot justify PI space may be they should not >> get into the global routing table. > > The implication of this statement is that if you cannot afford the RIR fees, the routers, the technical expertise to run those routers, the additional opex associated with "BGP-capable" Internet connectivity, etc., the services/content you provide don't deserve resiliency/redundancy/etc. > You deserve it, but can you afford it? (at least with the technology that we have today). > I have trouble seeing how this can be called "good". A "necessary evil given broken technology" perhaps, but not "good". > May be not my best choice of words. What I meant was that if you cannot justify PI, probably you do not have the means to run multihome today. It is not really good, in fact it sucks but this is the reality. >>> LISP is about seperating the role of the ISP (as routing provider) from >>> the end user or content provider/consumer. >> >> Yes, but as mentioned before the cost is in the edge, the benefit in >> the core. > > Being able to effectively multi-home without BGP, removing the need to ever renumber, etc., all sound like benefits to the edge to me. > >> The economic equation is all wrong. Is LISP able to provide all those benefits? > > People keep saying this. > > For core providers, the equation doesn't change. Well, OK, they may lose the additional fees they get for "BGP-capable" connections and they won't have the 'benefit' of the cost of renumbering to reduce customer thrash, however they continue to get paid for providing connectivity services. They might even save some money in the long run as they won't need to replace their hamsters with guinea pigs quite as frequently. > > For edges, the addition of a network element gives them freedom and resiliency at the cost of additional complexity and a bit of additional latency/reduced bandwidth. However, it is the edges that would pay the cost to get the benefit. I have trouble seeing how this economic equation is wrong. > >> There is not economic incentive for the edge to deploy LISP. We are facing the same problem >> that we have with IPv6. > > Not really. Not in the details, but in the macro it is. A technology that has to be lead by somebody that may not have the incentive to do it. >For example, you (or somebody) have to edit/recompile code to use IPv6. >You do not have to recompile code to use LISP. > But as edge site I have to have a capable router, have engineers to deploy LISP (or pay for it), etc. Without a clear benefit I do not seeing any one doing it. But I've already said it in my previous emal: "Now, if with LISP as an edge site I can have multihome, high availability, not to renumber my network, or any other combination of benefits and it does cost less than PI+BGP or PA+ then it may work." > Regards, > -drc > Regards, as From jason at lixfeld.ca Wed Mar 20 19:08:20 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 20 Mar 2013 15:08:20 -0400 Subject: NYC sales contacts for AS209 and AS2914 Message-ID: The contacts I have seem to all bounce. If anyone from NTT or CenturyLink is lurking who can quote on wholesale IPT out of 60 Hudson, please ping me. Thanks. From trelane at trelane.net Wed Mar 20 19:28:22 2013 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 20 Mar 2013 15:28:22 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <5149E57D.3080504@2mbit.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <5149E57D.3080504@2mbit.com> Message-ID: <514A0DD6.1000603@trelane.net> On 3/20/2013 12:36 PM, Brielle Bruns wrote: > On 3/20/13 6:40 AM, Patrick W. Gilmore wrote: >> I don't know a single ISP that wants to throttle growth by not >> accepting additional customers, BGP speaking or not. (I do know >> several that want to throttle growth through not upgrading their >> links because they have a captive audience they are trying to ransom. >> But that is neither relevant to this discussion, not controversial - >> unless you are paid by one of those ISPs....) > > Ran across more then one in the Idaho/Oregon/Washington State area that > told me it was "too hard" for them to do BGP with customers, or my > favorite, that it would cost over 1k USD for setup, and 500 USD a month > to do a BGP session with them from our rack in their data center. > > Some are either just lazy or incompetent. > > Some just want to justify HUGE blocks of IP space to the RIR too. Andrew From jared at puck.nether.net Wed Mar 20 19:39:53 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Mar 2013 15:39:53 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <70C736A0-38E8-41C1-B228-6BFB8B23C215@hopcount.ca> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <70C736A0-! 38E8-41C1-B228-6BFB8B23C215@hopcount.ca> Message-ID: <2E015285-A9C8-4137-BE49-F6148926F0B4@puck.nether.net> On Mar 20, 2013, at 11:39 AM, Joe Abley wrote: > I think it's incorrect to insist that the Network doesn't support pervasive end-site multi-homing when it's clear that people are doing it anyway. I know some small WISPs that balance multiple business DSL links using some of these things. Their boxes are interesting when it comes to the amount of state they hold and how they route those load balanced links. They auto-failover when a link stops working which is nice. If you have one of the static IPs you are obviously bound to that line. I'm surprised nobody here is posting how they use their 3G/LTE USB modem in a SRX or Cisco router and run BGP over that. (I'm sure someone on-list has done it). - Jared From owen at delong.com Wed Mar 20 20:16:57 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Mar 2013 15:16:57 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <5149CDE3.2020507@rollernet.us> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> Message-ID: <8C04311D-EF95-4C49-97A9-09FE9680F78E@delong.com> Sent from my iPad On Mar 20, 2013, at 9:55 AM, Seth Mattinen wrote: > On 3/20/13 6:25 AM, Owen DeLong wrote: >>> I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) >> >> Comcast >> Verizon >> AT&T >> Time Warner Cable >> Cox >> CenturyLink >> >> to name a few. >> >> Not one of them will run BGP with a residential subscriber. >> > > Based on the average clue of your average residential subscriber (anyone > here need not apply) I'd say that's a good thing. > > ~Seth Why? If BGP were plug-and-play automated with settings specified by the provider, what would the user's clue level have to do with it? Owen From owen at delong.com Wed Mar 20 20:20:23 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Mar 2013 15:20:23 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF@ianai.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC! @delong.c om> <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF@ianai.net> Message-ID: Sent from my iPad On Mar 20, 2013, at 10:18 AM, "Patrick W. Gilmore" wrote: > On Mar 20, 2013, at 09:25 , Owen DeLong wrote: > >>> I don't know a single ISP that wants to throttle growth by not accepting additional customers, BGP speaking or not. (I do know several that want to throttle growth through not upgrading their links because they have a captive audience they are trying to ransom. But that is neither relevant to this discussion, not controversial - unless you are paid by one of those ISPs?.) >> >> Comcast >> Verizon >> AT&T >> Time Warner Cable >> Cox >> CenturyLink >> >> to name a few. >> >> Not one of them will run BGP with a residential subscriber. > > Who cares? [See below.] > Not one of them will run BGP with a commercial subscriber using a cost-effective edge technology. > >>> And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. >> >> Sure they are. If they weren't, it would be relatively straight forward to add the necessary options to DHCP for a minimal (accept default, advertise local) BGP configuration and it would be quite simple for CPE router manufacturers to incorporate those capabilities. >> >> The problem is BGP doesn't scale to that level and everyone knows it, so, we limit growth by not allowing it to be a possibility. > > This is patently false. No network has a decision matrix that is "BGP doesn't scale, so let's refuse money from customers". > In so many words, no, but it is the net effect when you distill down the other contents of the matrix. > Every single one of the companies you listed will run BGP with customers. You limited this to "residential subscriber". Companies do not have only "residential customers". Pay more, get more. Pay $40, get less. Shocker. I pay $99/month to Comcast and they won't even give me a static address. That's a "business class" service from them. OTOH, I have two ISPs that do BGP with me for free. > "Not if you don't pay for it" is not a valid argument against "every $COMPANY has $FEATURE". > > I said the barrier to entry for multihoming was lower than it has ever been. I didn't say it was zero. The barrier is lower, but it's still higher than it should be. > You are a pretty smart guy, so I'm going to give you the benefit of the doubt and assume you just kinda-sortta forgot or did not consider the whole "money" thing, despite the fact the only reason nearly every Internet entity exists. (Now I wonder how many people are going to tell me about the N% which are non-profits, despite the fact I said "nearly"?) I'm paying way more per month to the providers that refuse to do BGP with/for me than I am paying to the providers that ARE doing BGP with/for me. Clearly money is not the issue. Owen From owen at delong.com Wed Mar 20 20:25:10 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Mar 2013 15:25:10 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <53CF2D6C-EB9A-4AE5-9AAC-922A6972B140@istaff.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC! @delong.com> <53CF2D6C-EB9A-4AE5-9AAC-922A6972B140@istaff.org> Message-ID: <6B67CB99-CF60-4F9D-A9B9-337B18764F3F@delong.com> Sent from my iPad On Mar 20, 2013, at 10:25 AM, John Curran wrote: > On Mar 20, 2013, at 7:25 AM, Owen DeLong wrote: > >>> And please don't reply with "then why can't I run BGP on my [cable|DSL|etc.] link?" Broadband providers are not trying to throttle growth by not allowing grandma to do BGP, and swapping to LISP or anything else won't change that. >> >> Sure they are. If they weren't, it would be relatively straight forward to add the necessary options to DHCP for a minimal (accept default, advertise local) BGP configuration and it would be quite simple for CPE router manufacturers to incorporate those capabilities. >> >> The problem is BGP doesn't scale to that level and everyone knows it, so, we limit growth by not allowing it to be a possibility. > > I suspect it has nothing to do with the scaling properties of > routing tables and everything to do with customer support costs. > > The metrics associated with broadband services are quite daunting; > i.e. costs from a single technical customer support call can exceed > the entire expected profit over the typical customer contract period... > An interesting idea. In my case, I average about 3 calls per month to Comcast. I suspect this more than consumes the $99/month I pay them for internet service. Further, I often get service credits out of those calls that further reduce their income. If they provided native dual-stack with BGP and their service didn't go down on a regular basis, it would result in fewer calls, at least from me. > In such circumstances, you really don't want any quantity of residential > customers running BGP, as it increases the probability of customer care > calls. It's only at a different revenue point (i.e. "small-business > service") that it becomes viable. I don't want the residential customers themselves running BGP at all. However, if there were motivation on the provider side, automated BGP configuration could enable consumers to attach to multiple providers and actually reduce support calls significantly. Owen From owen at delong.com Wed Mar 20 20:28:23 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Mar 2013 15:28:23 -0500 Subject: [c-nsp] DNS amplification In-Reply-To: <5549A641-4F3B-4E9E-9D90-F127E313A5B4@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <5149AC77.8030809@gmail.com> <5549A641-4F3B-4E9E-9D90-F127E313A5B4@virtualized.org> Message-ID: Sent from my iPad On Mar 20, 2013, at 10:26 AM, David Conrad wrote: > Arturo, > > On Mar 20, 2013, at 5:32 AM, Arturo Servin wrote: >>> For example I know there are enterprises that would like to multihome >>> but they find the current mechanism a barrier to this - for a start they >>> can't justify the size of PI space that would guarantee them entry to >>> the global routing table. >> >> Which is good. If they cannot justify PI space may be they should not >> get into the global routing table. > Any organization can easily justify a /48 if they can show two LOIs or contracts for peering or transit from independent ASNs. > The implication of this statement is that if you cannot afford the RIR fees, the routers, the technical expertise to run those routers, the additional opex associated with "BGP-capable" Internet connectivity, etc., the services/content you provide don't deserve resiliency/redundancy/etc. > > I have trouble seeing how this can be called "good". A "necessary evil given broken technology" perhaps, but not "good". +1 >>> LISP is about seperating the role of the ISP (as routing provider) from >>> the end user or content provider/consumer. >> >> Yes, but as mentioned before the cost is in the edge, the benefit in >> the core. > > Being able to effectively multi-home without BGP, removing the need to ever renumber, etc., all sound like benefits to the edge to me. What part of "without BGP" benefits the edge? Multihoming with BGP is much simpler at the edge than implementing LISP. Owen From marka at isc.org Wed Mar 20 20:44:06 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Mar 2013 07:44:06 +1100 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: Your message of "Wed, 20 Mar 2013 11:18:38 EDT." <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF@ianai.net> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@ delong.c om> <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF@ianai.net> Message-ID: <20130320204406.D825D313FAD2@drugs.dv.isc.org> In message <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF at ianai.net>, "Patrick W. Gilmor e" writes: > On Mar 20, 2013, at 09:25 , Owen DeLong wrote: > > >> I don't know a single ISP that wants to throttle growth by not = > accepting additional customers, BGP speaking or not. (I do know several = > that want to throttle growth through not upgrading their links because = > they have a captive audience they are trying to ransom. But that is = > neither relevant to this discussion, not controversial - unless you are = > paid by one of those ISPs=85.) > >=20 > > Comcast > > Verizon > > AT&T > > Time Warner Cable > > Cox > > CenturyLink > >=20 > > to name a few. > >=20 > > Not one of them will run BGP with a residential subscriber. > > Who cares? [See below.] > > > >> And please don't reply with "then why can't I run BGP on my = > [cable|DSL|etc.] link?" Broadband providers are not trying to throttle = > growth by not allowing grandma to do BGP, and swapping to LISP or = > anything else won't change that. > >=20 > > Sure they are. If they weren't, it would be relatively straight = > forward to add the necessary options to DHCP for a minimal (accept = > default, advertise local) BGP configuration and it would be quite simple = > for CPE router manufacturers to incorporate those capabilities. > >=20 > > The problem is BGP doesn't scale to that level and everyone knows it, = > so, we limit growth by not allowing it to be a possibility. > > This is patently false. No network has a decision matrix that is "BGP = > doesn't scale, so let's refuse money from customers". > > Every single one of the companies you listed will run BGP with = > customers. You limited this to "residential subscriber". Companies do = > not have only "residential customers". Pay more, get more. Pay $40, get = > less. Shocker. > > "Not if you don't pay for it" is not a valid argument against "every = > $COMPANY has $FEATURE". > > I said the barrier to entry for multihoming was lower than it has ever = > been. I didn't say it was zero. > > > You are a pretty smart guy, so I'm going to give you the benefit of the = > doubt and assume you just kinda-sortta forgot or did not consider the = > whole "money" thing, despite the fact the only reason nearly every = > Internet entity exists. (Now I wonder how many people are going to tell = > me about the N% which are non-profits, despite the fact I said = > "nearly"?) > > --=20 > TTFN, > patrick And homenet at the IETF demonstrated multi-homed residential connections with IPv6 without NAT using multiple PA addresses. If a upsteam goes down the connections over that upstream break. New connection use the working upstream. It's not quite the same as using PI but it is a 99.9% solution. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Wed Mar 20 21:26:09 2013 From: bill at herrin.us (William Herrin) Date: Wed, 20 Mar 2013 17:26:09 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> Message-ID: On Wed, Mar 20, 2013 at 9:25 AM, Owen DeLong wrote: > However, a locator/id separation without map/encap is a > desirable thing that could allow the routing system to > scale better. Unfortunately, we failed to address this > issue when designing IPv6. It will not get correctly solved > without a revision to the header design. There is no will > to change the packet header in the near future. We're > having too much "fun" rolling out the current one. Hi Owen, Right problem, wrong part of the problem. As is, the IPv6 layer 3 headers have plenty of bits to do a dandy job in a loc/id separation scheme: merely strip the ID function from the IP address and push it up the stack to layer 4. The crux of the problem, then, is that ID should be maintained by the layer 4 protocol with a dynamic and changeable mapping to the layer 3 locator. We don't need a new IP. We need a new TCP. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Wed Mar 20 21:29:46 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Mar 2013 17:29:46 -0400 Subject: routing table go boom (was: Re: [c-nsp] DNS amplification) In-Reply-To: <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> Message-ID: On Mar 19, 2013, at 4:48 PM, David Conrad wrote: > Patrick, > > On Mar 19, 2013, at 12:07 PM, Patrick W. Gilmore wrote: >> Which is all just a fancy way of saying you can't fix people being idiots by changing a protocol, or hardware, or ... well, anything. > > One of the advantages I see in LISP(-like) solutions is that it allows multi-homing without having to do BGP... What i've observed over the years is many of the reasons people use BGP and PI space is to make it easier to change internet providers. Much of this originally was due to everything being hardcoded, long dns caches and TTLs, etc.. With the exception of a few devices (eg: site-to-site VPN, etc..) these are a lot easier to handle than they were 15 years ago. I recall renumbering two different dns servers at one point, and we would always get something weird happening where the old domain/IP would come up with someones new registration. The process is mature, and I suspect many of the issues could be mitigated. Large datacenters now trust and are renumbered with DHCP. Installation of hosts happens quickly. moving of services happens quickly. The challenge is the people who are not there yet. - jared From patrick at ianai.net Wed Mar 20 22:27:48 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 20 Mar 2013 18:27:48 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC! @delong .c om> <59415DCC-2D4E-4DD9-87C9-0B56BF24FCCF@ianai.net> Message-ID: <9AF216A0-5254-4E7B-A1ED-7F1C35D2FB01@ianai.net> On Mar 20, 2013, at 16:20 , Owen DeLong wrote: > On Mar 20, 2013, at 10:18 AM, "Patrick W. Gilmore" wrote: >> On Mar 20, 2013, at 09:25 , Owen DeLong wrote: >>> Not one of them will run BGP with a residential subscriber. >> >> Who cares? [See below.] >> > Not one of them will run BGP with a commercial subscriber using a cost-effective edge technology. [snip] I'm literally at a loss how to respond. This whole post is either a contradiction ("ISPs do free BGP", "the barrier to entry for BGP is higher than it should be"), or non-sequitors ("Comcast charges me $99 and doesn't give me a static IP address", uh... so?), or simply wrong statements ("BGP doesn't scale so we limit growth", "no we don't", "not in so many words, but yes we do"). What exactly are you trying to say? Because I apparently am too stupid to understand. >> You are a pretty smart guy, so I'm going to give you the benefit of the doubt and assume you just kinda-sortta forgot or did not consider the whole "money" thing, despite the fact the only reason nearly every Internet entity exists. (Now I wonder how many people are going to tell me about the N% which are non-profits, despite the fact I said "nearly"?) > > I'm paying way more per month to the providers that refuse to do BGP with/for me than I am paying to the providers that ARE doing BGP with/for me. Clearly money is not the issue. You are confused. Money is (to a first approximation) ALWAYS the problem. Just because two companies sell things at different prices does not mean money is not at the heart of each company's pricing strategy. OF COURSE it is. They.... Oh, never mind. I'm going to take away the benefit of the doubt I gave you. And I think I'm going to stop feeding the ridiculously obvious troll. -- TTFN, patrick From jcurran at istaff.org Thu Mar 21 01:11:58 2013 From: jcurran at istaff.org (John Curran) Date: Wed, 20 Mar 2013 19:11:58 -0600 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <6B67CB99-CF60-4F9D-A9B9-337B18764F3F@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC!@delong.com> <53CF2D6C-EB9A-4AE5-9AAC-922A6972B140@istaff.org> <6B67CB99-CF60-4F9D-A9B9-337B18764F3F@delong.com> Message-ID: <3612B8CA-A571-4B79-8A1C-C150CA8416B6@istaff.org> On Mar 20, 2013, at 2:25 PM, Owen DeLong wrote: > > I don't want the residential customers themselves running BGP at all. However, if there were motivation on the provider side, automated BGP configuration could enable consumers to attach to multiple providers and actually reduce support calls significantly. Okay, I'll agree, but "if there were motivation" is a very large "if"... The only motivation would be money, as represented by customers leaving to competitors as a result of a service provider not offering your proposed service bundle. If you can figure out a way to persuade service providers of this belief, I would ask that you also persuade them that they have to offer dual-stack for all of their customers (which may have already resulted in them losing a small number of customers who expected IPv6 by now... :-) Thanks! /John From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 03:07:06 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 12:07:06 +0900 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <70C736A0-38E8-41C1-B228-6BFB8B23C215@hopcount.ca> References: <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <70C736A0-38E8-41C1-B228-6BFB8B23C215@hopcount.ca> Message-ID: <514A795A.70406@necom830.hpcl.titech.ac.jp> Joe Abley wrote: > In practice, it seems to me that the way people multi-home > these days for client-filled networks is: > > 1. Number everything internally using private-use addresses > 2. Use one NAT per upstream > 3. Send your outbound flows through whichever NAT seems appropriate Very reasonable approach. But, how to choose the proper NAT is still a problem. If there were standard home/site IGP supported by NAT boxes, to which ISPs tell ASPATHLEN as metric, it could help a lot. However, because packets are hot potatoes, ISPs are motivated to tell something larger than ASPATHLEN as the metric, unless they are legally ("MUST" phrase in IETF standards could be) forced not to do so. > There seem to be no shortage of SMB appliances that will take > care of this for you without you having to understand anything. > The phrase that seems to be used when describing these routers is > "dual WAN". > > https://www.mushroomnetworks.com > http://www.peplink.com/balance/ > http://www.tp-link.com/ > http://www.draytek.com/ > > It's trivial to configure this kind of thing on more general-purpose > gear too, obviously, but that requires Actual Knowledge of How > Things Work whereas these products aim to get things running > without any of that. > > This style of multi-homing is invisible from the perspective of > the routing system. That is the correct thing to do. > Obviously this doesn't work nicely for > inbound connections, but the fact that people do it anyway > suggests that isn't a deal-killer That is a problem MUST be solved by transport (or, at least application) layer of end systems to be able to handle multiple public addresses. It's not very difficult to modify TCP to accept packets with multiple source addresses and send to multiple destination addresses, if the addresses are carried with TCP optional header of SYN and SYNACK packets. Moreover, you can run SMTP and DNS servers with multiple public addresses, because clients are, though at the application layer, implemented to try all the public addresses of servers, even though they are tried only after transport layer time outs. > (presumably every server > that needs to accept an inbound connection these days lives > elsewhere, in someone's cloud). It partially because of the current difficulty to have multihoming. But, unless having an entry in DFZ is somehow appropriately taxed, the number of data centers to offer such cloud will increase. The fundamental economical problem of routing table bloat today is that one can multihome with its own DFZ routing table entry without paying anything to all the ISPs and other entities who must pay for enough resources to support the bloating DFZ routing table. Masataka Ohta > I'm not suggesting this is good architecture, Yes, it is. > I think it's incorrect to insist that the Network doesn't > support pervasive end-site multi-homing when it's clear > that people are doing it anyway. Fully agreed. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 03:07:14 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 12:07:14 +0900 Subject: routing table go boom In-Reply-To: References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> Message-ID: <514A7962.4030400@necom830.hpcl.titech.ac.jp> Sander Steffann wrote: >> As the ETR is not the final destination, it is subject to blackholing >> after ETR, which means: >> >> The function in question can completely and correctly be >> implemented only with the knowledge and help of the >> application standing at the endpoints of the communication >> system. >> >> Granted that it is no worse than multihoming by routing protocols. >> >> But, it merely means that neither BGP nor LISP works "completely >> and correctly". > > Well, yeah, if your internal routing (behind the ETR) breaks > then your network is broken... No, what can break is internal routing of one of your ISP, which is why you, an end user, want multihoming. William Herrin wrote: Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 03:07:25 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 12:07:25 +0900 Subject: routing table go boom In-Reply-To: References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> <5149D8CD.6040401@necom830.hpcl.titech.ac.jp> Message-ID: <514A796D.5040109@necom830.hpcl.titech.ac.jp> William Herrin wrote: >>> Some local system is responsible for detecting connectivity between >>> the ETR and destination and updating the destination-to-ETR map >>> accordingly. >> >> Some local system? > > Yeah, you know, like OSPF or EIGRP. Just like exporting a route from > the IGP to the EGP except that you're exporting a route from the IGP > to the LISP map instead. You assume an end user's network exchange route with its ISP. Though it causes a lot of problems, OK. Even then, that a route from an ETR of an ISP to an end system in end user's network is blackholed means that a routing protocol tells the ETR that there is a route to the end system. Masataka Ohta From mureninc at gmail.com Thu Mar 21 03:28:23 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 20 Mar 2013 20:28:23 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? Message-ID: Dear NANOG@, Not every operator has the ability to setup their own anycast. Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!) Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others? I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes? Any plans to make DNS itself GeoDNS-friendly? When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest? Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this? Cheers, Constantine. From asullivan at dyn.com Thu Mar 21 03:43:50 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 20 Mar 2013 23:43:50 -0400 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: Message-ID: <20130321034350.GB1143@dyn.com> On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote: > Any plans to make DNS itself GeoDNS-friendly? No. And I say this as someone working for a vendor that provides that service. Any sort of "Geo" DNS is what protocol people would call a "stupid DNS trick". It works in particular, narrowly-scoped ways because of the loose coherence of the DNS. But as a matter of protocol, you can't really standardize it, because it's actually taking advantage of certain flexibilities in the DNS and its interaction with the routing system. Turning that operational fact into a protocol feature would be a bad idea. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From rocca at start.ca Thu Mar 21 03:44:58 2013 From: rocca at start.ca (Peter Rocca) Date: Wed, 20 Mar 2013 23:44:58 -0400 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: Message-ID: The first hit on Google for "dns geolocation" results in http://backreference.org/2010/02/01/geolocation-aware-dns-with-bind/, or the first hit for "dns geolocation patch" leads you to http://www.caraytech.com/geodns/ -----Original Message----- From: Constantine A. Murenin [mailto:mureninc at gmail.com] Sent: March-20-13 11:28 PM To: North American Network Operators' Group Subject: Why are there no GeoDNS solutions anywhere in sight? Dear NANOG@, Not every operator has the ability to setup their own anycast. Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!) Why so many years after the concept has been introduced and has been found useful, can one not setup GeoDNS in under 5 minutes on one's own infrastructure, or use GeoDNS from any of the plentiful free or complementary DNS solutions that are offered by providers like he.net, xname.org, linode.com and others? I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the easiest (and only) solution I see right now is, on both servers, running two copies of `nsd` on distinct sockets, and redirecting incoming DNS traffic through a firewall based on IPv4 /8 address allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the rest of /8 allocations -- an `A` record for NA), with zone replication managed through git. Yeap, it's rough, and quite ugly, and unmaintainable, and will give optimal results only in 80 to 95 per cent of actual cases, and will not benefit from the extra webapp redundancy one otherwise might have had, but what other alternatives could be configured in 5 or 15 minutes? Any plans to make DNS itself GeoDNS-friendly? When editing a zone file in `emacs`, why can one not say that one has 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure and/or the web-browser figure out the rest? Why even stop there: all modern browsers usually know the exact location of the user, often with street-level accuracy. It should be possible to say that you have a server in Fremont, CA and Toronto, ON or Beauharnois, QC, and automatically have all East Coast users go to Toronto, and West Coast to Fremont. Why is there no way to do any of this? Cheers, Constantine. From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 03:44:46 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 12:44:46 +0900 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: Message-ID: <514A822E.7040406@necom830.hpcl.titech.ac.jp> Constantine A. Murenin wrote: > Why so many years after the concept has been introduced and has been > found useful, can one not setup GeoDNS in under 5 minutes on one's own > infrastructure, or use GeoDNS from any of the plentiful free or > complementary DNS solutions that are offered by providers like he.net, > xname.org, linode.com and others? Because we are mobile and want to use our IP addresses and domain names regardless of our current locations. Masataka Ohta From sethm at rollernet.us Thu Mar 21 03:57:46 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 20 Mar 2013 20:57:46 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: Message-ID: <514A853A.4030909@rollernet.us> On 3/20/13 8:28 PM, Constantine A. Murenin wrote: > > Why even stop there: all modern browsers usually know the exact > location of the user, often with street-level accuracy. It should be > possible to say that you have a server in Fremont, CA and Toronto, ON > or Beauharnois, QC, and automatically have all East Coast users go to > Toronto, and West Coast to Fremont. Why is there no way to do any of > this? > I guess there could be with LOC records. ~Seth From lists at shthead.com Thu Mar 21 04:17:16 2013 From: lists at shthead.com (shthead) Date: Thu, 21 Mar 2013 12:17:16 +0800 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: Message-ID: <514A89CC.6000202@shthead.com> You can set up GeoDNS without anycast with PowerDNS and Bind easily enough (I found PowerDNS easier to setup). If you are using Bind you can use the geoip patch or use views which is a quick hacky way. http://doc.powerdns.com/html/geo.html I can't comment on either solution if it supports getting the real remote IP address (PowerDNS does for the PipeBackend if its enabled so I assume it may be available) rather than the address of the resolver. For management I would lean towards PowerDNS of the two, you can stick on any of the available web interfaces if you want and use the SQL backend (replication can be used here to update records on slaves). The country management would still need to be done out of files though the records themselves would be edited/served out of the database. I don't run Bind any more but if you want a copy of the configs for PowerDNS or other details email me offlist and I am happy to help. On 21/03/2013 11:28 AM, Constantine A. Murenin wrote: > Dear NANOG@, > > Not every operator has the ability to setup their own anycast. > > Not every operator is big enough to be paying 25 USD/month for a > managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for > 25$/mo, I might as well have an extra POP or two!) > > Why so many years after the concept has been introduced and has been > found useful, can one not setup GeoDNS in under 5 minutes on one's own > infrastructure, or use GeoDNS from any of the plentiful free or > complementary DNS solutions that are offered by providers like he.net, > xname.org, linode.com and others? > > I'm an NSD3 user and have a POP in Europe and NA, and, frankly, the > easiest (and only) solution I see right now is, on both servers, > running two copies of `nsd` on distinct sockets, and redirecting > incoming DNS traffic through a firewall based on IPv4 /8 address > allocation (RIPE and AfriNIC -- to an `nsd` instance with zone files > with an `A` record of a POP in Europe; ARIN, APNIC, LACNIC and the > rest of /8 allocations -- an `A` record for NA), with zone replication > managed through git. Yeap, it's rough, and quite ugly, and > unmaintainable, and will give optimal results only in 80 to 95 per > cent of actual cases, and will not benefit from the extra webapp > redundancy one otherwise might have had, but what other alternatives > could be configured in 5 or 15 minutes? > > Any plans to make DNS itself GeoDNS-friendly? > > When editing a zone file in `emacs`, why can one not say that one has > 3 web servers -- Europe, NA, Asia -- and have the dns infrastructure > and/or the web-browser figure out the rest? > > Why even stop there: all modern browsers usually know the exact > location of the user, often with street-level accuracy. It should be > possible to say that you have a server in Fremont, CA and Toronto, ON > or Beauharnois, QC, and automatically have all East Coast users go to > Toronto, and West Coast to Fremont. Why is there no way to do any of > this? > > Cheers, > Constantine. > From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 04:29:34 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 13:29:34 +0900 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: Message-ID: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Constantine A. Murenin wrote: > Why even stop there: all modern browsers usually know the exact > location of the user, often with street-level accuracy. If you think mobile, they don't, especially because "often" is not at all "enough times". > Why is there no way to do any of this? Because it is impractical to assume an IP address can be mapped uniquely to a geolocation. Masataka Ohta From owen at delong.com Thu Mar 21 04:44:32 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Mar 2013 23:44:32 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <3612B8CA-A571-4B79-8A1C-C150CA8416B6@istaff.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC! !@delong.com> <53CF2D6C-EB9A-4AE5-9AAC-922A6972B140@istaff.org> <6B67CB99-CF60-4F9D-A9B9-337B18764F3F@delong.com> <3612B8CA-A571-4B79-8A1C-C150CA8416B6@istaff.org> Message-ID: <671229B1-F961-4EC2-9A9B-B0BA1536D9F2@delong.com> On Mar 20, 2013, at 8:11 PM, John Curran wrote: > On Mar 20, 2013, at 2:25 PM, Owen DeLong wrote: >> >> I don't want the residential customers themselves running BGP at all. However, if there were motivation on the provider side, automated BGP configuration could enable consumers to attach to multiple providers and actually reduce support calls significantly. > > Okay, I'll agree, but "if there were motivation" is a very large "if"... > > The only motivation would be money, as represented by customers leaving > to competitors as a result of a service provider not offering your proposed > service bundle. > > If you can figure out a way to persuade service providers of this belief, > I would ask that you also persuade them that they have to offer dual-stack > for all of their customers (which may have already resulted in them losing > a small number of customers who expected IPv6 by now... :-) You, of all people, John, are very aware of my efforts on this basis. I agree it's a very large if. In fact, the very real probability that dissatisfied customers will use their ability to multi home and run BGP as a reduction of the pain point of changing subscribers is probably the largest reason that it is not available. The providers have exact opposite motivation. This is a fine example of how the efficiency of the invisible hand fails when it comes to technical products where the masses fail to actually realize that they are being shafted and artificially constrained by the limitations placed on them by their vendors. However, that's getting a bit far afield for NANOG, so I tried to stick to the technical aspects of the argument. Owen From mureninc at gmail.com Thu Mar 21 06:55:41 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 20 Mar 2013 23:55:41 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <20130321034350.GB1143@dyn.com> References: <20130321034350.GB1143@dyn.com> Message-ID: On 20 March 2013 20:43, Andrew Sullivan wrote: > On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote: >> Any plans to make DNS itself GeoDNS-friendly? > > No. And I say this as someone working for a vendor that provides that > service. > > Any sort of "Geo" DNS is what protocol people would call a "stupid DNS > trick". It works in particular, narrowly-scoped ways because of the > loose coherence of the DNS. But as a matter of protocol, you can't > really standardize it, because it's actually taking advantage of > certain flexibilities in the DNS and its interaction with the routing > system. Turning that operational fact into a protocol feature would > be a bad idea. You are coming to this from the perspective of the existing conventions, and the current way that GeoDNS is done through a Split-Horizon DNS hack. But this is not what I want. What I want is an ability to specify multiple A and AAAA records, and their locations, and make it possible for the web-browser to automatically select the best location based on the presumed location of the user. Browsers might have a couple of rules, e.g. that Europe and parts of Asia are currently not directly connected to Asia, but NA is, and such rules would influence browser's decision to choose a Quebec server for a user in Japan, since it'll likely be much closer than the one in Moscow. Does it sound too complicated and pointy? Yes, it's not exactly trivial, and not as good as BGP, but better than having 300ms latency from a simple round-robin. C. From bmanning at vacation.karoshi.com Thu Mar 21 07:03:01 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 21 Mar 2013 07:03:01 +0000 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <20130321034350.GB1143@dyn.com> Message-ID: <20130321070301.GB31867@vacation.karoshi.com.> On Wed, Mar 20, 2013 at 11:55:41PM -0700, Constantine A. Murenin wrote: > On 20 March 2013 20:43, Andrew Sullivan wrote: > > On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote: > >> Any plans to make DNS itself GeoDNS-friendly? > > > > No. And I say this as someone working for a vendor that provides that > > service. > > > > Any sort of "Geo" DNS is what protocol people would call a "stupid DNS > > trick". It works in particular, narrowly-scoped ways because of the > > loose coherence of the DNS. But as a matter of protocol, you can't > > really standardize it, because it's actually taking advantage of > > certain flexibilities in the DNS and its interaction with the routing > > system. Turning that operational fact into a protocol feature would > > be a bad idea. > > You are coming to this from the perspective of the existing > conventions, and the current way that GeoDNS is done through a > Split-Horizon DNS hack. > > But this is not what I want. > > What I want is an ability to specify multiple A and AAAA records, and > their locations, and make it possible for the web-browser to > automatically select the best location based on the presumed location > of the user. Browsers might have a couple of rules, e.g. that Europe > and parts of Asia are currently not directly connected to Asia, but NA > is, and such rules would influence browser's decision to choose a > Quebec server for a user in Japan, since it'll likely be much closer > than the one in Moscow. > > Does it sound too complicated and pointy? Yes, it's not exactly > trivial, and not as good as BGP, but better than having 300ms latency > from a simple round-robin. > > C. peice of cake. add loc records to your rrset. /bill From mureninc at gmail.com Thu Mar 21 07:16:23 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 21 Mar 2013 00:16:23 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <514A853A.4030909@rollernet.us> References: <514A853A.4030909@rollernet.us> Message-ID: On 20 March 2013 20:57, Seth Mattinen wrote: > On 3/20/13 8:28 PM, Constantine A. Murenin wrote: >> >> Why even stop there: all modern browsers usually know the exact >> location of the user, often with street-level accuracy. It should be >> possible to say that you have a server in Fremont, CA and Toronto, ON >> or Beauharnois, QC, and automatically have all East Coast users go to >> Toronto, and West Coast to Fremont. Why is there no way to do any of >> this? >> > > I guess there could be with LOC records. > > ~Seth Apart from not being supported by anyone, it's also broken by design in regards to the "Searching by Network or Subnet" section (e.g. the party who controls 0.0.0.88.in-addr.arpa is not at all related to the party that has 88.198.0.0/16), and also has no IPv6 support: http://tools.ietf.org/html/rfc1876#section-5.2.2 C. From mureninc at gmail.com Thu Mar 21 07:23:02 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 21 Mar 2013 00:23:02 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: On 20 March 2013 21:29, Masataka Ohta wrote: > Constantine A. Murenin wrote: > >> Why even stop there: all modern browsers usually know the exact >> location of the user, often with street-level accuracy. > > If you think mobile, they don't, especially because "often" is > not at all "enough times". Are you suggesting that geolocation is inaccurate enough to misplace Europe with Asia? >> Why is there no way to do any of this? > > Because it is impractical to assume an IP address can be mapped > uniquely to a geolocation. Why is it impractical? If I have a server in Germany and in Quebec, why would it be impractical to have the logic in place such that European visitors would be contacting the server in Germany, and visitors from US/Canada -- the one in Quebec? C. From randy at psg.com Thu Mar 21 07:23:08 2013 From: randy at psg.com (Randy Bush) Date: Thu, 21 Mar 2013 09:23:08 +0200 Subject: routing table go boom In-Reply-To: <21F2F092-F7D5-4EC4-8BCE-B9240E61A7BF@puck.nether.net> References: <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <61691C54-2DF8-4AF1-B823-1C4EE746654B@hopcount.ca> <1B9DEBDC-D513-43EB-9700-B1125BA43879@puck.nether.net> <45CD4D24-9E95-4ED4-821F-CE94D71304FE@virtualized.org> <5148F377.90704@necom830.hpcl.titech.ac.jp> <5148FD5E.6010106@necom830.hpcl.titech.ac.jp> <51491340.70203@necom830.hpcl.titech.ac.jp> <51494BBB.50906@necom830.hpcl.titech.ac.jp> Message-ID: > I certainly think there's a lot that can be done at middle-layers, eg: tunnels > to a few different providers. I can be on a Comcast CM and ATT DSL link and > establish a link to a tunnel destination in Chicago that is low-latency for me > and the bits will all flow that way. > > The last mile loop problem though? sweden and japan, among others, have some experiences (good and mediocre) in this area randy From randy at psg.com Thu Mar 21 08:24:51 2013 From: randy at psg.com (Randy Bush) Date: Thu, 21 Mar 2013 10:24:51 +0200 Subject: 2012 internet census Message-ID: nice piece of work http://internetcensus2012.bitbucket.org/paper.html as cristel says, better coverage than atlas and no need for user credits! :) randy From simon at darkmere.gen.nz Thu Mar 21 08:26:46 2013 From: simon at darkmere.gen.nz (Simon Lyall) Date: Thu, 21 Mar 2013 21:26:46 +1300 (NZDT) Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: On Thu, 21 Mar 2013, Constantine A. Murenin wrote: > Why is it impractical? If I have a server in Germany and in Quebec, > why would it be impractical to have the logic in place such that > European visitors would be contacting the server in Germany, and > visitors from US/Canada -- the one in Quebec? But what if the server in Quebec is a little VPS on a 10Mb/s link while the one in Germany is a rack of servers on a 10Gb/s link? What if I just want the server in Quebec to serve people from Canada and the one in Germany serves the rest of the world? What if it is 4am in Quebec but 9am in Germany? (it is right now) What if I have half a dozen pops worldwide? What if I have 20? 200? 2000? What is closer to a user in New Zealand, A Pop in Japan, Singapore or LA? The main thing with GSLB is: The little guys don't need it, The medium sized sites outsource, The big guys roll their own. Personally I outsource and it works very well. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From bmanning at vacation.karoshi.com Thu Mar 21 08:41:40 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 21 Mar 2013 08:41:40 +0000 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: <20130321084140.GB432@vacation.karoshi.com.> On Thu, Mar 21, 2013 at 12:23:02AM -0700, Constantine A. Murenin wrote: > On 20 March 2013 21:29, Masataka Ohta wrote: > > Constantine A. Murenin wrote: > > > >> Why even stop there: all modern browsers usually know the exact > >> location of the user, often with street-level accuracy. > > > > If you think mobile, they don't, especially because "often" is > > not at all "enough times". > > Are you suggesting that geolocation is inaccurate enough to misplace > Europe with Asia? last month, while in western australia, geoloc pegged me in utah. this morning, geoloc pegged me in Kansas, while resident in Maryland. > >> Why is there no way to do any of this? > > > > Because it is impractical to assume an IP address can be mapped > > uniquely to a geolocation. > > Why is it impractical? If I have a server in Germany and in Quebec, > why would it be impractical to have the logic in place such that > European visitors would be contacting the server in Germany, and > visitors from US/Canada -- the one in Quebec? > > C. secure dynamic update works. waht is TWC's incentive to allow clients to update tjheir reverse DNS delegations, esp when clients are leaving them for T-Mobile? your sugesting the cretion and deployment of something that already exists in the LOC RR. Your rational is that LOC isn't used. If thats the case, why would your proposal be any more successful? /bill From j at arpa.com Thu Mar 21 10:10:36 2013 From: j at arpa.com (jamie rishaw) Date: Thu, 21 Mar 2013 05:10:36 -0500 Subject: Cisco password implementation trubs: weakened strength? In-Reply-To: References: Message-ID: warning: I'm tired and this email is terse. warning: for huge nerds only. disclaimer: although I've worked with actual rocket scientists(hi Roger), I'm. not one myself..nor am I a crypto mathnerd apparently, Cisco is changing its password schemas. old: pbkdf2 by 1k, salted vs New: (type 4) unsalted sha256 .. discuss.? there is a cert and Cisco sa on this.. but I'm wondering if anyone has any opinions, yea or nay.? -j. From nick at foobar.org Thu Mar 21 10:57:02 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 21 Mar 2013 10:57:02 +0000 Subject: Cisco password implementation trubs: weakened strength? In-Reply-To: References: Message-ID: <514AE77E.10705@foobar.org> On 21/03/2013 10:10, jamie rishaw wrote: > apparently, Cisco is changing its password schemas. > > old: pbkdf2 by 1k, salted > vs > New: (type 4) unsalted sha256 > .. > discuss.? security advisory: > http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20130318-type4 which states: > Because of the issues discussed in this Security Response, Cisco is > taking the following actions for future Cisco IOS and Cisco IOS XE > releases: > > Type 4 passwords will be deprecated: Future Cisco IOS and Cisco IOS XE > releases will not generate Type 4 passwords. However, to maintain > backward compatibility, existing Type 4 passwords will be parsed and > accepted. Customers will need to manually remove the existing Type 4 > passwords from their configuration. Kudos to Cisco - this was the right thing to do. Nick From mysidia at gmail.com Thu Mar 21 11:22:52 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 21 Mar 2013 06:22:52 -0500 Subject: Cisco password implementation trubs: weakened strength? In-Reply-To: References: Message-ID: On 3/21/13, jamie rishaw wrote: > New: (type 4) unsalted sha256 Good for them; DES Crypt and MD5 crypt are dead... however, I hope they have misspoken then... because that move would make no sense... moving to simple unsalted SHA256 as the new hash type would definitely increase the performance of potential password cracking attempts against passwords stored at rest, instead of addressing the massive increase in cheap computing power (which will necessitate all software vendors who are concerned about stored password security, stop using older crypt algorithms yesterday). In other words; they would be moving to a weaker hashing algorithm if selecting unsalted SHA -- more hashes per second of SHA256 could be computed per second on equivalent GPU than hashes per second of MD5 Crypt. PBKDF2 at 10k rounds is stronger than MD5 crypt (more time required for a password cracker); Bcrypt stronger than PBKDF2 with appropriate work factor selected (more time _and_ larger amounts of memory space required thwarting GPUs); etc. Also, on what platform have they already used anything stronger than Unix crypt? As far as I knew, Cisco were always using; 'type 7' password blobs vigenere based symmetric encryption with a factory-defined key, type 6 symmetric encrypted storage (with des/aes key obscured from view), or type 5 basic unix crypt or Poul-Henning Kamp's MD5 crypt algorithm used in FreeBSD. > I'm. not one myself..nor am I a crypto mathnerd > apparently, Cisco is changing its password schemas. > old: pbkdf2 by 1k, salted > vs > New: (type 4) unsalted sha256 > .. > discuss.? > > there is a cert and Cisco sa on this.. but I'm wondering if anyone has any > opinions, yea or nay.? -- -JH From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 11:36:36 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 20:36:36 +0900 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: <514AF0C4.7000200@necom830.hpcl.titech.ac.jp> Constantine A. Murenin wrote: > Are you suggesting that geolocation is inaccurate enough to misplace > Europe with Asia? Yes, of course. Think mobile. Masataka Ohta From graham at apolix.co.za Thu Mar 21 12:23:16 2013 From: graham at apolix.co.za (Graham Beneke) Date: Thu, 21 Mar 2013 14:23:16 +0200 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: <514AFBB4.2060407@apolix.co.za> On 21/03/2013 09:23, Constantine A. Murenin wrote: > On 20 March 2013 21:29, Masataka Ohta wrote: >> Constantine A. Murenin wrote: >> >>> Why even stop there: all modern browsers usually know the exact >>> location of the user, often with street-level accuracy. >> >> If you think mobile, they don't, especially because "often" is >> not at all "enough times". > > Are you suggesting that geolocation is inaccurate enough to misplace > Europe with Asia? I don't think that it is even a suggestion. It is trivially achievable: I have a transit provider which is a US based company. They route a small slice of their IP space to us over the transit link... at their PoP in London... where I pick it up and route it to Johannesburg. All the while - geolocation is convinced those IPs reside in the hometown of my transit provider. I also know of many people who use VPNs to intentionally goelocate themselves somewhere other than their real location in order to get around certain content filtering. -- Graham Beneke From arturo.servin at gmail.com Thu Mar 21 12:27:53 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Thu, 21 Mar 2013 09:27:53 -0300 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: <514AFCC9.1080508@gmail.com> On 21/03/2013 04:23, Constantine A. Murenin wrote: > Are you suggesting that geolocation is inaccurate enough to misplace > Europe with Asia? Yes, sometimes very inaccurate. Just go to an IETF meeting and you will be placed all around the globe. It is a corner case, but it shows some deficiencies in the current approach. .as From jabley at hopcount.ca Thu Mar 21 12:28:49 2013 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 21 Mar 2013 08:28:49 -0400 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <20130321034350.GB1143@dyn.com> Message-ID: <3F0D68CD-D88B-4E23-87F3-8FBEFCF95F2D@hopcount.ca> On 2013-03-21, at 02:55, Constantine A. Murenin wrote: > What I want is an ability to specify multiple A and AAAA records, and > their locations, and make it possible for the web-browser to > automatically select the best location based on the presumed location > of the user. I understand that you want a packaged solution in your authoritative DNS software, but with a little work you can get close without any knowledge of global topology or address distribution (i.e. no need for a geo-IP database). You need some unused address space to burn on anycast advertisements, though. Here's an approach using anycast DNS: $ORIGIN example.com. ... www CNAME www.geo.example.com. ... ; number any1 and any2 using addresses that ; are anycast between our service locations any1 A ... AAAA .... any2 A ... AAAA ... ... geo NS any1 NS any2 ; serve this version of geo.example.com ; in Asia on any1/any2, make www ; something sensible for Asian clients $ORIGIN geo.example.com. ... www A .... AAAA ... ; serve this version of geo.example.com ; in Europe on any1/any2, make www ; something sensible for European clients $ORIGIN geo.example.com. ...0 www A .... AAAA .... ; etc No reason that all the variants of the geo.example.com. zone can't be signed with the same keypair, and a suitable DS RRSet installed in example.com; this doesn't break DNSSEC. Two nameservers in the example above; this gives no site diversity for the geo.example.com zone but perhaps it's useful to incorporate server diversity within the site (if not, use one). You need to be able to advertise an anycast route to the world from each location, and you need spare numbers to be able to make those advertisements. For v4 that means an unpolluted /24; for v6 that probably means an unpolluted /56 or /48. Anycast of a single service is not a friend of efficient address utilisation. As with any other use of anycast, "European client" means "client whose path to any1/any2 lands in the European service location" and doesn't actually say anything about the location of the user. But if the selected exits along the path for some client land in Europe for resolving names in geo.example.com, maybe that's a good way to send the HTTP traffic. Another approach is to anycast the HTTP server serving www.example.com, and have that server return a 3xx redirect to www.asia.example.com or www.europe.example.com, which preserves the ability for the user of making a manual choice for one or the other at the expense of making your web people all flappy about the longer URL and the potential for particular content to be bookmarked with no future potential for geo-distribution. People get animated when you suggest you anycast a TCP service, but there is no shortage of examples of this working (and the redirect transaction is brief, which is generally nerve-settling). Lots of ways to skin this cat. Joe From dot at dotat.at Thu Mar 21 13:29:56 2013 From: dot at dotat.at (Tony Finch) Date: Thu, 21 Mar 2013 13:29:56 +0000 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <20130321070301.GB31867@vacation.karoshi.com.> References: <20130321034350.GB1143@dyn.com> <20130321070301.GB31867@vacation.karoshi.com.> Message-ID: bmanning at vacation.karoshi.com wrote: > > peice of cake. add loc records to your rrset. You need something more sophisticated than that because for a single domain name you can't say which LOC records correspond to which address records. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From chip.gwyn at gmail.com Thu Mar 21 13:30:33 2013 From: chip.gwyn at gmail.com (chip) Date: Thu, 21 Mar 2013 09:30:33 -0400 Subject: Cisco password implementation trubs: weakened strength? In-Reply-To: References: Message-ID: According to the releases, they moved to a PBKDF2 solution, but due to implementation error...it ran only once; without salt. Ars has a pretty good write up on it. So.. Good for them for updating to better encryption. Bad on them for horking up the code to actually implement it and making it much worse. Apply the upcoming patches, whipe hands on pants. http://arstechnica.com/security/2013/03/cisco-switches-to-weaker-hashing-scheme-passwords-cracked-wide-open/ --chip On Thu, Mar 21, 2013 at 7:22 AM, Jimmy Hess wrote: > On 3/21/13, jamie rishaw wrote: > > New: (type 4) unsalted sha256 > > Good for them; DES Crypt and MD5 crypt are dead... however, I hope > they have misspoken then... because that move would make no > sense... moving to simple unsalted SHA256 as the new hash type would > definitely increase the performance of potential password cracking > attempts against passwords stored at rest, instead of addressing the > massive increase in cheap computing power (which will necessitate all > software vendors who are concerned about stored password security, > stop using older crypt algorithms yesterday). > > In other words; they would be moving to a weaker hashing algorithm if > selecting unsalted SHA -- more hashes per second of SHA256 could be > computed per second on equivalent GPU than hashes per second of MD5 > Crypt. > > PBKDF2 at 10k rounds is stronger than MD5 crypt (more time required > for a password cracker); Bcrypt stronger than PBKDF2 with appropriate > work factor selected (more time _and_ larger amounts of memory space > required thwarting GPUs); etc. > > > Also, on what platform have they already used anything stronger than Unix > crypt? > > As far as I knew, Cisco were always using; 'type 7' password blobs > vigenere based symmetric encryption with a factory-defined key, type > 6 symmetric encrypted storage (with des/aes key obscured from view), > or type 5 basic unix crypt or Poul-Henning Kamp's MD5 crypt algorithm > used in FreeBSD. > > > > I'm. not one myself..nor am I a crypto mathnerd > > apparently, Cisco is changing its password schemas. > > old: pbkdf2 by 1k, salted > > vs > > New: (type 4) unsalted sha256 > > .. > > discuss.? > > > > there is a cert and Cisco sa on this.. but I'm wondering if anyone has > any > > opinions, yea or nay.? > > -- > -JH > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From mohta at necom830.hpcl.titech.ac.jp Thu Mar 21 13:51:53 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Mar 2013 22:51:53 +0900 Subject: Fwd: Re: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <514B1043.4070408@necom830.hpcl.titech.ac.jp> References: <514B1043.4070408@necom830.hpcl.titech.ac.jp> Message-ID: <514B1079.9010809@necom830.hpcl.titech.ac.jp> Arturo Servin wrote: > Just go to an IETF meeting and you will be placed all around the globe. > It is a corner case, but it shows some deficiencies in the current approach. It should also be noted that network addresses for NANOG meetings may also be located somewhere in , though not world wide, USA or CANADA. Masataka Ohta From lathama at gmail.com Thu Mar 21 14:14:17 2013 From: lathama at gmail.com (Andrew Latham) Date: Thu, 21 Mar 2013 10:14:17 -0400 Subject: 2012 internet census In-Reply-To: References: Message-ID: This was duplicated on multiple sites. Example: http://census2012.sourceforge.net/paper.html On Thu, Mar 21, 2013 at 4:24 AM, Randy Bush wrote: > nice piece of work > > http://internetcensus2012.bitbucket.org/paper.html > > as cristel says, better coverage than atlas and no need for user > credits! :) > > randy > -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From kg9020 at gmail.com Thu Mar 21 14:48:46 2013 From: kg9020 at gmail.com (kg9020) Date: Thu, 21 Mar 2013 09:48:46 -0500 Subject: GeoDNS In-Reply-To: References: Message-ID: <8014D4C1-268B-4457-B27B-E4CFDAA15A01@gmail.com> Hello Have you tried https://github.com/blblack/gdnsd you can view usage at http://www.youtube.com/watch?v=WF75IGx9svM art On Mar 21, 2013, at 7:00 AM, nanog-request at nanog.org wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Why are there no GeoDNS solutions anywhere in sight? > (Constantine A. Murenin) > 2. Re: routing table go boom (Randy Bush) > 3. 2012 internet census (Randy Bush) > 4. Re: Why are there no GeoDNS solutions anywhere in sight? > (Simon Lyall) > 5. Re: Why are there no GeoDNS solutions anywhere in sight? > (bmanning at vacation.karoshi.com) > 6. Cisco password implementation trubs: weakened strength? > (jamie rishaw) > 7. Re: Cisco password implementation trubs: weakened strength? > (Nick Hilliard) > 8. Re: Cisco password implementation trubs: weakened strength? > (Jimmy Hess) > 9. Re: Why are there no GeoDNS solutions anywhere in sight? > (Masataka Ohta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Mar 2013 00:23:02 -0700 > From: "Constantine A. Murenin" > To: Masataka Ohta > Cc: nanog at nanog.org > Subject: Re: Why are there no GeoDNS solutions anywhere in sight? > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 20 March 2013 21:29, Masataka Ohta wrote: >> Constantine A. Murenin wrote: >> >>> Why even stop there: all modern browsers usually know the exact >>> location of the user, often with street-level accuracy. >> >> If you think mobile, they don't, especially because "often" is >> not at all "enough times". > > Are you suggesting that geolocation is inaccurate enough to misplace > Europe with Asia? > >>> Why is there no way to do any of this? >> >> Because it is impractical to assume an IP address can be mapped >> uniquely to a geolocation. > > Why is it impractical? If I have a server in Germany and in Quebec, > why would it be impractical to have the logic in place such that > European visitors would be contacting the server in Germany, and > visitors from US/Canada -- the one in Quebec? > > C. > > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Mar 2013 09:23:08 +0200 > From: Randy Bush > To: Jared Mauch > Cc: nanog at nanog.org > Subject: Re: routing table go boom > Message-ID: > Content-Type: text/plain; charset=US-ASCII > >> I certainly think there's a lot that can be done at middle-layers, eg: tunnels >> to a few different providers. I can be on a Comcast CM and ATT DSL link and >> establish a link to a tunnel destination in Chicago that is low-latency for me >> and the bits will all flow that way. >> >> The last mile loop problem though? > > sweden and japan, among others, have some experiences (good and > mediocre) in this area > > randy > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Mar 2013 10:24:51 +0200 > From: Randy Bush > To: North American Network Operators' Group > Subject: 2012 internet census > Message-ID: > Content-Type: text/plain; charset=US-ASCII > > nice piece of work > > http://internetcensus2012.bitbucket.org/paper.html > > as cristel says, better coverage than atlas and no need for user > credits! :) > > randy > > > > ------------------------------ > > Message: 4 > Date: Thu, 21 Mar 2013 21:26:46 +1300 (NZDT) > From: Simon Lyall > To: nanog at nanog.org > Subject: Re: Why are there no GeoDNS solutions anywhere in sight? > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Thu, 21 Mar 2013, Constantine A. Murenin wrote: >> Why is it impractical? If I have a server in Germany and in Quebec, >> why would it be impractical to have the logic in place such that >> European visitors would be contacting the server in Germany, and >> visitors from US/Canada -- the one in Quebec? > > But what if the server in Quebec is a little VPS on a 10Mb/s link while > the one in Germany is a rack of servers on a 10Gb/s link? > > What if I just want the server in Quebec to serve people from Canada and > the one in Germany serves the rest of the world? > > What if it is 4am in Quebec but 9am in Germany? (it is right now) > > What if I have half a dozen pops worldwide? > > What if I have 20? 200? 2000? > > What is closer to a user in New Zealand, A Pop in Japan, Singapore or LA? > > The main thing with GSLB is: > > The little guys don't need it, > The medium sized sites outsource, > The big guys roll their own. > > Personally I outsource and it works very well. > > -- > Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ > "To stay awake all night adds a day to your life" - Stilgar | eMT. > > > > > ------------------------------ > > Message: 5 > Date: Thu, 21 Mar 2013 08:41:40 +0000 > From: bmanning at vacation.karoshi.com > To: "Constantine A. Murenin" > Cc: nanog at nanog.org > Subject: Re: Why are there no GeoDNS solutions anywhere in sight? > Message-ID: <20130321084140.GB432 at vacation.karoshi.com.> > Content-Type: text/plain; charset=us-ascii > > On Thu, Mar 21, 2013 at 12:23:02AM -0700, Constantine A. Murenin wrote: >> On 20 March 2013 21:29, Masataka Ohta wrote: >>> Constantine A. Murenin wrote: >>> >>>> Why even stop there: all modern browsers usually know the exact >>>> location of the user, often with street-level accuracy. >>> >>> If you think mobile, they don't, especially because "often" is >>> not at all "enough times". >> >> Are you suggesting that geolocation is inaccurate enough to misplace >> Europe with Asia? > > > last month, while in western australia, geoloc pegged me in utah. > this morning, geoloc pegged me in Kansas, while resident in Maryland. > > >>>> Why is there no way to do any of this? >>> >>> Because it is impractical to assume an IP address can be mapped >>> uniquely to a geolocation. >> >> Why is it impractical? If I have a server in Germany and in Quebec, >> why would it be impractical to have the logic in place such that >> European visitors would be contacting the server in Germany, and >> visitors from US/Canada -- the one in Quebec? >> >> C. > > secure dynamic update works. waht is TWC's incentive to allow clients to update > tjheir reverse DNS delegations, esp when clients are leaving them for T-Mobile? > > > your sugesting the cretion and deployment of something that already exists > in the LOC RR. Your rational is that LOC isn't used. If thats the case, > why would your proposal be any more successful? > > /bill > > > > ------------------------------ > > Message: 6 > Date: Thu, 21 Mar 2013 05:10:36 -0500 > From: jamie rishaw > To: NANOG > Subject: Cisco password implementation trubs: weakened strength? > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > warning: I'm tired and this email is terse. > warning: for huge nerds only. > disclaimer: although I've worked with actual rocket scientists(hi Roger), > I'm. not one myself..nor am I a crypto mathnerd > > apparently, Cisco is changing its password schemas. > > old: pbkdf2 by 1k, salted > vs > New: (type 4) unsalted sha256 > .. > discuss.? > > there is a cert and Cisco sa on this.. but I'm wondering if anyone has any > opinions, yea or nay.? > > -j. > > > ------------------------------ > > Message: 7 > Date: Thu, 21 Mar 2013 10:57:02 +0000 > From: Nick Hilliard > To: nanog at nanog.org > Subject: Re: Cisco password implementation trubs: weakened strength? > Message-ID: <514AE77E.10705 at foobar.org> > Content-Type: text/plain; charset=ISO-8859-1 > > On 21/03/2013 10:10, jamie rishaw wrote: >> apparently, Cisco is changing its password schemas. >> >> old: pbkdf2 by 1k, salted >> vs >> New: (type 4) unsalted sha256 >> .. >> discuss.? > > security advisory: > >> http://tools.cisco.com/security/center/content/CiscoSecurityResponse/cisco-sr-20130318-type4 > > which states: > >> Because of the issues discussed in this Security Response, Cisco is >> taking the following actions for future Cisco IOS and Cisco IOS XE >> releases: >> >> Type 4 passwords will be deprecated: Future Cisco IOS and Cisco IOS XE >> releases will not generate Type 4 passwords. However, to maintain >> backward compatibility, existing Type 4 passwords will be parsed and >> accepted. Customers will need to manually remove the existing Type 4 >> passwords from their configuration. > > Kudos to Cisco - this was the right thing to do. > > Nick > > > > > ------------------------------ > > Message: 8 > Date: Thu, 21 Mar 2013 06:22:52 -0500 > From: Jimmy Hess > To: jamie rishaw > Cc: NANOG > Subject: Re: Cisco password implementation trubs: weakened strength? > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 3/21/13, jamie rishaw wrote: >> New: (type 4) unsalted sha256 > > Good for them; DES Crypt and MD5 crypt are dead... however, I hope > they have misspoken then... because that move would make no > sense... moving to simple unsalted SHA256 as the new hash type would > definitely increase the performance of potential password cracking > attempts against passwords stored at rest, instead of addressing the > massive increase in cheap computing power (which will necessitate all > software vendors who are concerned about stored password security, > stop using older crypt algorithms yesterday). > > In other words; they would be moving to a weaker hashing algorithm if > selecting unsalted SHA -- more hashes per second of SHA256 could be > computed per second on equivalent GPU than hashes per second of MD5 > Crypt. > > PBKDF2 at 10k rounds is stronger than MD5 crypt (more time required > for a password cracker); Bcrypt stronger than PBKDF2 with appropriate > work factor selected (more time _and_ larger amounts of memory space > required thwarting GPUs); etc. > > > Also, on what platform have they already used anything stronger than Unix crypt? > > As far as I knew, Cisco were always using; 'type 7' password blobs > vigenere based symmetric encryption with a factory-defined key, type > 6 symmetric encrypted storage (with des/aes key obscured from view), > or type 5 basic unix crypt or Poul-Henning Kamp's MD5 crypt algorithm > used in FreeBSD. > > >> I'm. not one myself..nor am I a crypto mathnerd >> apparently, Cisco is changing its password schemas. >> old: pbkdf2 by 1k, salted >> vs >> New: (type 4) unsalted sha256 >> .. >> discuss.? >> >> there is a cert and Cisco sa on this.. but I'm wondering if anyone has any >> opinions, yea or nay.? > > -- > -JH > > > > ------------------------------ > > Message: 9 > Date: Thu, 21 Mar 2013 20:36:36 +0900 > From: Masataka Ohta > To: "Constantine A. Murenin" > Cc: nanog at nanog.org > Subject: Re: Why are there no GeoDNS solutions anywhere in sight? > Message-ID: <514AF0C4.7000200 at necom830.hpcl.titech.ac.jp> > Content-Type: text/plain; charset=ISO-2022-JP > > Constantine A. Murenin wrote: > >> Are you suggesting that geolocation is inaccurate enough to misplace >> Europe with Asia? > > Yes, of course. > > Think mobile. > > Masataka Ohta > > > > End of NANOG Digest, Vol 62, Issue 67 > ************************************* From woody at pch.net Thu Mar 21 15:21:19 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 21 Mar 2013 08:21:19 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> Message-ID: <6ED9E7E8-DB96-4930-B868-9635DE2295DD@pch.net> On Mar 21, 2013, at 12:23 AM, "Constantine A. Murenin" wrote: >>> Why is there no way to do any of this? >> >> Because it is impractical to assume an IP address can be mapped >> uniquely to a geolocation. > > Why is it impractical? If I have a server in Germany and in Quebec, > why would it be impractical to have the logic in place such that > European visitors would be contacting the server in Germany, and > visitors from US/Canada -- the one in Quebec? There is not "no way to do any of this." People do it all the time. They do it using anycast, which requires a certain amount of network build, or they do it using source-address databases, which have a certain amount of ridiculous FAIL. Are you actually asking why there's no way to do it perfectly at no cost? -Bill From mureninc at gmail.com Thu Mar 21 16:27:13 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 21 Mar 2013 09:27:13 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <514AF0C4.7000200@necom830.hpcl.titech.ac.jp> References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> <514AF0C4.7000200@necom830.hpcl.titech.ac.jp> Message-ID: On 21 March 2013 04:36, Masataka Ohta wrote: > Constantine A. Murenin wrote: > >> Are you suggesting that geolocation is inaccurate enough to misplace >> Europe with Asia? > > Yes, of course. > > Think mobile. Why are you insisting that mobile will have wrong geolocation? Yes, there are cases when due to the portable WiFi hotspots the location may be wrong temporarily, but how is that much different from a suboptimal node selection through a plain round-robin DNS? C. From joelja at bogus.com Thu Mar 21 16:39:11 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 21 Mar 2013 09:39:11 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> <514AF0C4.7000200@necom830.hpcl.titech.ac.jp> Message-ID: <514B37AF.90508@bogus.com> On 3/21/13 9:27 AM, Constantine A. Murenin wrote: > On 21 March 2013 04:36, Masataka Ohta wrote: >> Constantine A. Murenin wrote: >> >>> Are you suggesting that geolocation is inaccurate enough to misplace >>> Europe with Asia? >> Yes, of course. >> >> Think mobile. > Why are you insisting that mobile will have wrong geolocation? Because the GGSN is nowhere near the customer's location. > Yes, there are cases when due to the portable WiFi hotspots the > location may be wrong temporarily, but how is that much different from > a suboptimal node selection through a plain round-robin DNS? > > C. > From mureninc at gmail.com Thu Mar 21 16:39:27 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 21 Mar 2013 09:39:27 -0700 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: <514AFBB4.2060407@apolix.co.za> References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> <514AFBB4.2060407@apolix.co.za> Message-ID: On 21 March 2013 05:23, Graham Beneke wrote: > On 21/03/2013 09:23, Constantine A. Murenin wrote: >> On 20 March 2013 21:29, Masataka Ohta wrote: >>> Constantine A. Murenin wrote: >>> >>>> Why even stop there: all modern browsers usually know the exact >>>> location of the user, often with street-level accuracy. >>> >>> If you think mobile, they don't, especially because "often" is >>> not at all "enough times". >> >> Are you suggesting that geolocation is inaccurate enough to misplace >> Europe with Asia? > > I don't think that it is even a suggestion. It is trivially achievable: > > I have a transit provider which is a US based company. They route a > small slice of their IP space to us over the transit link... > at their PoP in London... > where I pick it up and route it to Johannesburg. > > All the while - geolocation is convinced those IPs reside in the > hometown of my transit provider. > > I also know of many people who use VPNs to intentionally goelocate > themselves somewhere other than their real location in order to get > around certain content filtering. Your two examples are quite the opposite of each other, I don't know if this was your intention. In the first case, when a US-based (and/or ARIN issued) address space is moved to Europe or Africa, a server-based geoloc would result in suboptimal results, but a client-based geoloc would very likely provide sought-after results. In the second, VPN case -- exactly the opposite -- server-based would work great, client based would be suboptimal. Does it show that geoloc is hard to get right? Yes. But what I don't understand is why everyone implies that the status quo with round-robin DNS is any better. C. From buzdale at gmail.com Thu Mar 21 18:09:38 2013 From: buzdale at gmail.com (Buz Dale) Date: Thu, 21 Mar 2013 14:09:38 -0400 Subject: Fwd: Class E addresses in the wild In-Reply-To: References: Message-ID: Is anyone else seeing a lot of Class E address space (240.0.0.0/4) at their borders? Has this space been reinstated in some as yet unknown to me RFC? Thanks, Buz -- Buz Dale buzdale at gmail.com GMT -5 -- -- Buz Dale buzdale at gmail.com GMT -5 -- From dsparro at gmail.com Thu Mar 21 18:15:45 2013 From: dsparro at gmail.com (Dave Sparro) Date: Thu, 21 Mar 2013 14:15:45 -0400 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> <514AFBB4.2060407@apolix.co.za> Message-ID: <514B4E51.1040505@gmail.com> On 3/21/2013 12:39 PM, Constantine A. Murenin wrote: > But what I don't understand is why everyone implies that the status > quo with round-robin DNS is any better. C. Doesn't the Happy Eyeballs address selection algorithm work even when all the potential address are on the same network (be it IPv4 or v6)? As many have pointed out physical location and network location don't always quite correlate. Just recently I've made a change in colos that brought my servers both 400 miles closer to my house, and 30ms further away via the network, and the transit providers in all cases had "Time Warner" in the name. -- Dave From joelja at bogus.com Thu Mar 21 18:16:15 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 21 Mar 2013 11:16:15 -0700 Subject: Fwd: Class E addresses in the wild In-Reply-To: References: Message-ID: <514B4E6F.4080501@bogus.com> On 3/21/13 11:09 AM, Buz Dale wrote: > Is anyone else seeing a lot of Class E address space (240.0.0.0/4) at their > borders? I'd put those is in the martian category. > Has this space been reinstated in some as yet unknown to me RFC? No it hasn't. > Thanks, > Buz > From d3e3e3 at gmail.com Thu Mar 21 18:17:05 2013 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 21 Mar 2013 14:17:05 -0400 Subject: Class E addresses in the wild In-Reply-To: References: Message-ID: No authorized IETF use that I know of. See http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Thu, Mar 21, 2013 at 2:09 PM, Buz Dale wrote: > Is anyone else seeing a lot of Class E address space (240.0.0.0/4) at their > borders? Has this space been reinstated in some as yet unknown to me RFC? > Thanks, > Buz > > -- > Buz Dale > buzdale at gmail.com > GMT -5 > -- > > > > -- > Buz Dale > buzdale at gmail.com > GMT -5 > -- From george.herbert at gmail.com Thu Mar 21 19:06:28 2013 From: george.herbert at gmail.com (George Herbert) Date: Thu, 21 Mar 2013 12:06:28 -0700 Subject: Class E addresses in the wild In-Reply-To: References: Message-ID: It is (or was) fairly commonly in use among internal nets which overflowed RFC 1918 or have to internetwork with other heavy users of RFC 1918 space. I know of at least two service providers and one cell network who were using it for that 3 years ago. Someone leaking internal routes for such? Or attempt to hijack the space? Only the Shadow knows... On Thu, Mar 21, 2013 at 11:17 AM, Donald Eastlake wrote: > No authorized IETF use that I know of. See > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3 at gmail.com > > > On Thu, Mar 21, 2013 at 2:09 PM, Buz Dale wrote: >> Is anyone else seeing a lot of Class E address space (240.0.0.0/4) at their >> borders? Has this space been reinstated in some as yet unknown to me RFC? >> Thanks, >> Buz >> >> -- >> Buz Dale >> buzdale at gmail.com >> GMT -5 >> -- >> >> >> >> -- >> Buz Dale >> buzdale at gmail.com >> GMT -5 >> -- > -- -george william herbert george.herbert at gmail.com From bzs at world.std.com Thu Mar 21 19:14:36 2013 From: bzs at world.std.com (Barry Shein) Date: Thu, 21 Mar 2013 15:14:36 -0400 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> <514AF0C4.7000200@necom830.hpcl.titech.ac.jp> Message-ID: <20811.23580.586363.869234@world.std.com> Wasn't this problem solved by foursquare.com?! -- -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 sander at steffann.nl Thu Mar 21 20:43:11 2013 From: sander at steffann.nl (Sander Steffann) Date: Thu, 21 Mar 2013 21:43:11 +0100 Subject: VPLS PE Redundancy with Supervisor Engine 2T Message-ID: <693630FE-7A32-4ED9-BB53-B1F25D2410F0@steffann.nl> Hi, We're trying to implement VPLS PE Redundancy with Supervisor Engine 2T (VSS) as described in http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-663645.html#wp9000139 and constantly failing. It seems so simple: set up a VSS, use LACP or PAgP port-channels to the distribution switches and do VPLS on the VSS. It just doesn't seem to work. Using WS-X6908-10G-2TXL line cards already gives less problems than with WS-X6704-10GE line cards, but still it fails to work very often. I sometimes wonder if I am going mad or if this setup has never actually been tested... So: has anybody ever set up a network like this, or am I really beta testing for Cisco now? Cheers, Sander Steffann From josh.hoppes at gmail.com Thu Mar 21 23:37:44 2013 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Thu, 21 Mar 2013 18:37:44 -0500 Subject: Why are there no GeoDNS solutions anywhere in sight? In-Reply-To: References: <514A8CAE.70305@necom830.hpcl.titech.ac.jp> <514AFBB4.2060407@apolix.co.za> Message-ID: > But what I don't understand is why everyone implies that the status > quo with round-robin DNS is any better. I don't think anyone believes round robin DNS records is better. It's that attempting to do better requires adding onto or changing standards that must maintain backwards compatibility and thus nearly useless until everyone adopts it, or hack jobs that have hilariously funny failure scenarios that are unavoidable because it comes down to "guess work". From cb.list6 at gmail.com Fri Mar 22 00:10:33 2013 From: cb.list6 at gmail.com (cb.list6) Date: Thu, 21 Mar 2013 17:10:33 -0700 Subject: Class E addresses in the wild In-Reply-To: References: Message-ID: On Thu, Mar 21, 2013 at 12:06 PM, George Herbert wrote: > It is (or was) fairly commonly in use among internal nets which > overflowed RFC 1918 or have to internetwork with other heavy users of > RFC 1918 space. I know of at least two service providers and one cell > network who were using it for that 3 years ago. > I am pretty sure Class E is completely defunct and not used anywhere since Cisco and Juniper routers do not forward the packets (circa 2008 testing) and no known host accept it as a valid address, AFAIK. CB > Someone leaking internal routes for such? Or attempt to hijack the space? > > Only the Shadow knows... > > > On Thu, Mar 21, 2013 at 11:17 AM, Donald Eastlake wrote: >> No authorized IETF use that I know of. See >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3 at gmail.com >> >> >> On Thu, Mar 21, 2013 at 2:09 PM, Buz Dale wrote: >>> Is anyone else seeing a lot of Class E address space (240.0.0.0/4) at their >>> borders? Has this space been reinstated in some as yet unknown to me RFC? >>> Thanks, >>> Buz >>> >>> -- >>> Buz Dale >>> buzdale at gmail.com >>> GMT -5 >>> -- >>> >>> >>> >>> -- >>> Buz Dale >>> buzdale at gmail.com >>> GMT -5 >>> -- >> > > > > -- > -george william herbert > george.herbert at gmail.com > From george.herbert at gmail.com Fri Mar 22 01:19:38 2013 From: george.herbert at gmail.com (George Herbert) Date: Thu, 21 Mar 2013 18:19:38 -0700 Subject: Class E addresses in the wild In-Reply-To: References: Message-ID: On Thu, Mar 21, 2013 at 5:10 PM, cb.list6 wrote: > I am pretty sure Class E is completely defunct and not used anywhere > since Cisco and Juniper routers do not forward the packets (circa 2008 > testing) and no known host accept it as a valid address, AFAIK. Both the net and host sides of this are trivially repairable problems, even for crazy cellphone network operators. As long as you have host source code and a network vendor you can demand custom patches from.... -- -george william herbert george.herbert at gmail.com From mdavids at forfun.net Fri Mar 22 06:39:12 2013 From: mdavids at forfun.net (Marco Davids) Date: Fri, 22 Mar 2013 07:39:12 +0100 Subject: GeoDNS In-Reply-To: <8014D4C1-268B-4457-B27B-E4CFDAA15A01@gmail.com> References: <8014D4C1-268B-4457-B27B-E4CFDAA15A01@gmail.com> Message-ID: <514BFC90.6090905@forfun.net> Op 21-03-13 15:48, kg9020 schreef: > Hello > > Have you tried > > https://github.com/blblack/gdnsd Or maybe https://github.com/miekg/geodns, if you are into Go. Here it an be seen 'in action': http://dns-status.ntppool.org/# -- Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4432 bytes Desc: S/MIME-cryptografische ondertekening URL: From sander at steffann.nl Fri Mar 22 11:52:37 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 22 Mar 2013 12:52:37 +0100 Subject: [c-nsp] VPLS PE Redundancy with Supervisor Engine 2T In-Reply-To: <693630FE-7A32-4ED9-BB53-B1F25D2410F0@steffann.nl> References: <693630FE-7A32-4ED9-BB53-B1F25D2410F0@steffann.nl> Message-ID: <6DF68B2F-D445-46E4-AA37-E933353E8865@steffann.nl> Hi, > We're trying to implement VPLS PE Redundancy with Supervisor Engine 2T (VSS) as described in http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-663645.html#wp9000139 and constantly failing. It seems so simple: set up a VSS, use LACP or PAgP port-channels to the distribution switches and do VPLS on the VSS. It just doesn't seem to work. Using WS-X6908-10G-2TXL line cards already gives less problems than with WS-X6704-10GE line cards, but still it fails to work very often. I sometimes wonder if I am going mad or if this setup has never actually been tested... > > So: has anybody ever set up a network like this, or am I really beta testing for Cisco now? With a lot of thanks, credits etc to Arie Vayner: enabling 'mpls ldp graceful-restart' is a work-around for this problem. If you run into this situation look at: - https://supportforums.cisco.com/thread/2131580 - CSCsw70062 Cheers, Sander From buzdale at gmail.com Fri Mar 22 13:39:56 2013 From: buzdale at gmail.com (Buz Dale) Date: Fri, 22 Mar 2013 09:39:56 -0400 Subject: Class E addresses in the wild In-Reply-To: References: Message-ID: It's in our Martians ACL but we left it off of a couple of new border connections and saw a good bit of it forwarded to us since Wednesday from multiple ISPs. Fixed now but still curious. Thanks, Buz On Thu, Mar 21, 2013 at 9:19 PM, George Herbert wrote: > On Thu, Mar 21, 2013 at 5:10 PM, cb.list6 wrote: > > I am pretty sure Class E is completely defunct and not used anywhere > > since Cisco and Juniper routers do not forward the packets (circa 2008 > > testing) and no known host accept it as a valid address, AFAIK. > > Both the net and host sides of this are trivially repairable problems, > even for crazy cellphone network operators. As long as you have host > source code and a network vendor you can demand custom patches > from.... > > > -- > -george william herbert > george.herbert at gmail.com > -- Buz Dale buzdale at gmail.com GMT -5 -- From dschuemann at gmail.com Fri Mar 22 17:55:40 2013 From: dschuemann at gmail.com (Dustin Schuemann) Date: Fri, 22 Mar 2013 13:55:40 -0400 Subject: Class E addresses in the wild In-Reply-To: References: Message-ID: Fiserv uses this address space for their ATM network. On Fri, Mar 22, 2013 at 9:39 AM, Buz Dale wrote: > It's in our Martians ACL but we left it off of a couple of new border > connections and saw a good bit of it forwarded to us since Wednesday from > multiple ISPs. > Fixed now but still curious. > Thanks, > Buz > > > On Thu, Mar 21, 2013 at 9:19 PM, George Herbert >wrote: > > > On Thu, Mar 21, 2013 at 5:10 PM, cb.list6 wrote: > > > I am pretty sure Class E is completely defunct and not used anywhere > > > since Cisco and Juniper routers do not forward the packets (circa 2008 > > > testing) and no known host accept it as a valid address, AFAIK. > > > > Both the net and host sides of this are trivially repairable problems, > > even for crazy cellphone network operators. As long as you have host > > source code and a network vendor you can demand custom patches > > from.... > > > > > > -- > > -george william herbert > > george.herbert at gmail.com > > > > > > -- > Buz Dale > buzdale at gmail.com > GMT -5 > -- > From carlosm3011 at gmail.com Fri Mar 22 18:13:46 2013 From: carlosm3011 at gmail.com (Carlos M. Martinez) Date: Fri, 22 Mar 2013 15:13:46 -0300 Subject: Symantec contact Message-ID: <514C9F5A.6030602@gmail.com> Hello all, I'm looking for a PoC in Symantec who could help me with an issue in this report: http://www.symantec.com/threatreport/topic.jsp?id=nam&aid=nam_malicious_activity_by_geo I've already tried to contact the emails listed on the website, multiple times, to no avail. Contact me on private. regards, ~Carlos From cscora at apnic.net Fri Mar 22 18:33:31 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Mar 2013 04:33:31 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201303221833.r2MIXVIT031008@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Mar, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 446728 Prefixes after maximum aggregation: 183292 Deaggregation factor: 2.44 Unique aggregates announced to Internet: 220037 Total ASes present in the Internet Routing Table: 43605 Prefixes per ASN: 10.24 Origin-only ASes present in the Internet Routing Table: 34346 Origin ASes announcing only one prefix: 16005 Transit ASes present in the Internet Routing Table: 5773 Transit-only ASes present in the Internet Routing Table: 138 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 380 Unregistered ASNs in the Routing Table: 135 Number of 32-bit ASNs allocated by the RIRs: 4642 Number of 32-bit ASNs visible in the Routing Table: 3486 Prefixes from 32-bit ASNs in the Routing Table: 10051 Special use prefixes present in the Routing Table: 16 Prefixes being announced from unallocated address space: 190 Number of addresses announced to Internet: 2623636172 Equivalent to 156 /8s, 97 /16s and 130 /24s Percentage of available address space announced: 70.9 Percentage of allocated address space announced: 70.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.4 Total number of prefixes smaller than registry allocations: 157705 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 107650 Total APNIC prefixes after maximum aggregation: 33185 APNIC Deaggregation factor: 3.24 Prefixes being announced from the APNIC address blocks: 108812 Unique aggregates announced from the APNIC address blocks: 44235 APNIC Region origin ASes present in the Internet Routing Table: 4823 APNIC Prefixes per ASN: 22.56 APNIC Region origin ASes announcing only one prefix: 1232 APNIC Region transit ASes present in the Internet Routing Table: 818 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 471 Number of APNIC addresses announced to Internet: 719866944 Equivalent to 42 /8s, 232 /16s and 76 /24s Percentage of available APNIC address space announced: 84.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 157052 Total ARIN prefixes after maximum aggregation: 79231 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 157702 Unique aggregates announced from the ARIN address blocks: 72021 ARIN Region origin ASes present in the Internet Routing Table: 15558 ARIN Prefixes per ASN: 10.14 ARIN Region origin ASes announcing only one prefix: 5892 ARIN Region transit ASes present in the Internet Routing Table: 1613 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1078545024 Equivalent to 64 /8s, 73 /16s and 74 /24s Percentage of available ARIN address space announced: 57.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 114247 Total RIPE prefixes after maximum aggregation: 59056 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 117881 Unique aggregates announced from the RIPE address blocks: 76026 RIPE Region origin ASes present in the Internet Routing Table: 17109 RIPE Prefixes per ASN: 6.89 RIPE Region origin ASes announcing only one prefix: 8154 RIPE Region transit ASes present in the Internet Routing Table: 2789 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2244 Number of RIPE addresses announced to Internet: 654647012 Equivalent to 39 /8s, 5 /16s and 30 /24s Percentage of available RIPE address space announced: 95.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, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47537 Total LACNIC prefixes after maximum aggregation: 9355 LACNIC Deaggregation factor: 5.08 Prefixes being announced from the LACNIC address blocks: 51460 Unique aggregates announced from the LACNIC address blocks: 23836 LACNIC Region origin ASes present in the Internet Routing Table: 1868 LACNIC Prefixes per ASN: 27.55 LACNIC Region origin ASes announcing only one prefix: 548 LACNIC Region transit ASes present in the Internet Routing Table: 346 Average LACNIC Region AS path length visible: 4.9 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 747 Number of LACNIC addresses announced to Internet: 124820520 Equivalent to 7 /8s, 112 /16s and 156 /24s Percentage of available LACNIC address space announced: 74.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10057 Total AfriNIC prefixes after maximum aggregation: 2415 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 10683 Unique aggregates announced from the AfriNIC address blocks: 3745 AfriNIC Region origin ASes present in the Internet Routing Table: 594 AfriNIC Prefixes per ASN: 17.98 AfriNIC Region origin ASes announcing only one prefix: 179 AfriNIC Region transit ASes present in the Internet Routing Table: 124 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 45373696 Equivalent to 2 /8s, 180 /16s and 89 /24s Percentage of available AfriNIC address space announced: 45.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2950 11558 922 Korea Telecom (KIX) 17974 2504 840 86 PT TELEKOMUNIKASI INDONESIA 7545 1845 301 89 TPG Internet Pty Ltd 4755 1726 392 197 TATA Communications formerly 9829 1464 1173 43 BSNL National Internet Backbo 9583 1279 97 525 Sify Limited 7552 1158 1062 11 Vietel Corporation 4808 1115 2056 320 CNCGROUP IP network: China169 9498 1069 310 74 BHARTI Airtel Ltd. 24560 1060 385 165 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3033 3694 87 bellsouth.net, inc. 7029 2216 1266 213 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1993 2929 125 Cox Communications, Inc. 1785 1967 677 125 PaeTec Communications, Inc. 20115 1683 1613 620 Charter Communications 4323 1613 1139 401 Time Warner Telecom 30036 1320 291 678 Mediacom Communications Corp 7018 1313 10810 849 AT&T WorldNet Services 11492 1210 222 329 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1832 544 16 Corbina telecom 2118 1116 97 13 EUnet/RELCOM Autonomous Syste 34984 1108 234 206 BILISIM TELEKOM 12479 841 786 66 Uni2 Autonomous System 13188 836 99 36 Educational Network 20940 799 278 635 Akamai Technologies European 31148 786 41 19 FreeNet ISP 6830 714 2314 435 UPC Distribution Services 8551 714 370 43 Bezeq International 58113 664 73 386 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2468 1338 90 NET Servicos de Comunicao S.A 10620 2362 407 238 TVCABLE BOGOTA 7303 1673 1148 209 Telecom Argentina Stet-France 8151 1357 2680 401 UniNet S.A. de C.V. 6503 1176 435 68 AVANTEL, S.A. 14754 942 128 85 Telgua S. A. 18881 834 716 18 Global Village Telecom 27947 795 87 96 Telconet S.A 11830 726 364 14 Instituto Costarricense de El 3816 692 306 85 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 732 274 34 LINKdotNET AS number 6713 535 615 23 Itissalat Al-MAGHRIB 8452 345 958 13 TEDATA 24835 342 80 8 RAYA Telecom - Egypt 3741 262 906 220 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 190 698 88 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3033 3694 87 bellsouth.net, inc. 4766 2950 11558 922 Korea Telecom (KIX) 17974 2504 840 86 PT TELEKOMUNIKASI INDONESIA 28573 2468 1338 90 NET Servicos de Comunicao S.A 10620 2362 407 238 TVCABLE BOGOTA 7029 2216 1266 213 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1993 2929 125 Cox Communications, Inc. 1785 1967 677 125 PaeTec Communications, Inc. 7545 1845 301 89 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2504 2418 PT TELEKOMUNIKASI INDONESIA 28573 2468 2378 NET Servicos de Comunicao S.A 10620 2362 2124 TVCABLE BOGOTA 4766 2950 2028 Korea Telecom (KIX) 7029 2216 2003 Windstream Communications Inc 18566 2080 1895 Covad Communications 22773 1993 1868 Cox Communications, Inc. 1785 1967 1842 PaeTec Communications, Inc. 8402 1832 1816 Corbina telecom 7545 1845 1756 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 mywire Datentechnik GmbH Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:13 /10:29 /11:88 /12:247 /13:483 /14:872 /15:1562 /16:12654 /17:6593 /18:10867 /19:21699 /20:31663 /21:33513 /22:46051 /23:41513 /24:234663 /25:1364 /26:1675 /27:864 /28:182 /29:78 /30:18 /31:0 /32:20 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2030 2080 Covad Communications 6389 1743 3033 bellsouth.net, inc. 7029 1614 2216 Windstream Communications Inc 8402 1547 1832 Corbina telecom 22773 1304 1993 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1203 1320 Mediacom Communications Corp 11492 1172 1210 Cable One 1785 1043 1967 PaeTec Communications, Inc. 7011 942 1187 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:728 2:777 3:3 4:13 5:834 6:3 8:511 12:1936 13:3 14:764 15:11 16:3 17:8 20:19 23:246 24:1802 27:1470 31:1176 32:44 33:2 34:5 36:43 37:1447 38:857 39:2 40:159 41:2657 42:183 44:6 46:1743 47:2 49:614 50:668 52:12 54:28 55:11 57:27 58:1104 59:600 60:304 61:1449 62:1017 63:2038 64:4290 65:2175 66:4282 67:2055 68:1118 69:3268 70:871 71:527 72:1898 74:2548 75:401 76:293 77:1084 78:1017 79:577 80:1229 81:973 82:613 83:557 84:563 85:1149 86:466 87:946 88:380 89:1767 90:262 91:5450 92:602 93:1702 94:1858 95:1552 96:499 97:336 98:1051 99:41 100:29 101:312 103:2312 105:517 106:133 107:207 108:517 109:1815 110:856 111:1040 112:499 113:764 114:684 115:1011 116:867 117:808 118:1007 119:1258 120:378 121:825 122:1740 123:1191 124:1323 125:1316 128:555 129:221 130:320 131:652 132:332 133:143 134:257 135:60 136:221 137:242 138:343 139:181 140:199 141:320 142:535 143:368 144:485 145:90 146:522 147:364 148:701 149:357 150:158 151:476 152:415 153:194 154:34 155:384 156:251 157:392 158:268 159:709 160:334 161:423 162:376 163:203 164:579 165:452 166:376 167:574 168:1018 169:131 170:1020 171:169 172:5 173:1580 174:583 175:431 176:1143 177:1826 178:1974 179:1 180:1380 181:292 182:1224 183:350 184:660 185:303 186:2359 187:1235 188:1906 189:1401 190:6632 192:6421 193:5677 194:4512 195:3464 196:1260 197:871 198:4244 199:5266 200:6034 201:2371 202:8903 203:8772 204:4488 205:2552 206:2785 207:2825 208:4057 209:3536 210:2916 211:1566 212:2007 213:1959 214:916 215:95 216:5194 217:1565 218:604 219:350 220:1269 221:547 222:318 223:492 End of report From cidr-report at potaroo.net Fri Mar 22 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Mar 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201303222200.r2MM00F8082632@wattle.apnic.net> This report has been generated at Fri Mar 22 21:13:18 2013 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-03-13 448211 257346 16-03-13 448743 257380 17-03-13 448568 257603 18-03-13 448652 258302 19-03-13 448881 258115 20-03-13 448504 258217 21-03-13 448538 258322 22-03-13 449261 258110 AS Summary 43719 Number of ASes in routing system 18120 Number of ASes announcing only one prefix 3033 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116943584 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'). --- 22Mar13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 449068 258053 191015 42.5% All ASes AS6389 3033 91 2942 97.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2952 941 2011 68.1% KIXS-AS-KR Korea Telecom AS17974 2504 498 2006 80.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS28573 2479 600 1879 75.8% NET Servi?os de Comunica??o S.A. AS10620 2362 698 1664 70.4% Telmex Colombia S.A. AS18566 2080 431 1649 79.3% COVAD - Covad Communications Co. AS7303 1673 436 1237 73.9% Telecom Argentina S.A. AS4323 1615 405 1210 74.9% TWTC - tw telecom holdings, inc. AS4755 1726 592 1134 65.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1116 83 1033 92.6% RELCOM-AS OOO "NPO Relcom" AS7029 2217 1253 964 43.5% WINDSTREAM - Windstream Communications Inc AS7552 1158 210 948 81.9% VIETEL-AS-AP Vietel Corporation AS7545 1849 917 932 50.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1008 171 837 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS22773 1993 1168 825 41.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18881 834 20 814 97.6% Global Village Telecom AS1785 1967 1193 774 39.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS17908 825 61 764 92.6% TCISL Tata Communications AS4808 1115 356 759 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS14754 942 215 727 77.2% Telgua AS13977 835 126 709 84.9% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 713 50 663 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS8151 1370 707 663 48.4% Uninet S.A. de C.V. AS22561 1079 454 625 57.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 722 101 621 86.0% GIGAINFRA Softbank BB Corp. AS3549 1051 444 607 57.8% GBLX Global Crossing Ltd. AS24560 1060 460 600 56.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1090 496 594 54.5% LEVEL3 Level 3 Communications AS19262 991 402 589 59.4% VZGNI-TRANSIT - Verizon Online LLC Total 45645 13960 31685 69.4% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 151.216.0.0/17 AS50304 BLIX Blix Solutions AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.124.252.0/22 AS7303 Telecom Argentina S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 UOL DIVEO S.A. 200.58.248.0/21 AS27849 201.71.16.0/20 AS28638 QLINK TELECOMUNICACOES E INTERNET LTDA 201.77.96.0/20 AS28639 Econocell do Brasil Ltda 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 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.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. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 22 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Mar 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201303222200.r2MM01tw082650@wattle.apnic.net> BGP Update Report Interval: 14-Mar-13 -to- 21-Mar-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 40868 1.8% 34.5 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS9829 34916 1.6% 38.2 -- BSNL-NIB National Internet Backbone 3 - AS4538 29018 1.3% 55.6 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS4795 28615 1.3% 117.8 -- INDOSATM2-ID INDOSATM2 ASN 5 - AS18004 24707 1.1% 348.0 -- WIRELESSNET-ID-AP WIRELESSNET AS 6 - AS3909 23240 1.1% 2905.0 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - AS28573 22734 1.0% 10.3 -- NET Servi?os de Comunica??o S.A. 8 - AS2708 22300 1.0% 153.8 -- Universidad de Guanajuato 9 - AS35994 19617 0.9% 530.2 -- AKAMAI-AS - Akamai Technologies, Inc. 10 - AS13897 17712 0.8% 8856.0 -- CDC1 - Internet Brands Inc. 11 - AS23947 17666 0.8% 410.8 -- MORATELINDONAP-AS-ID PT.Mora Telematika Indonesia 12 - AS17974 14927 0.7% 7.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS58113 14758 0.7% 22.2 -- LIR-AS LIR DATACENTER TELECOM SRL 14 - AS7029 14332 0.7% 9.5 -- WINDSTREAM - Windstream Communications Inc 15 - AS9198 13891 0.6% 36.9 -- KAZTELECOM-AS JSC Kazakhtelecom 16 - AS9583 13059 0.6% 9.6 -- SIFY-AS-IN Sify Limited 17 - AS2697 11839 0.5% 148.0 -- ERX-ERNET-AS Education and Research Network 18 - AS2 11735 0.5% 706.0 -- HPPL-AS-AP Hancock Prospecting Pty Ltd 19 - AS45271 11513 0.5% 44.8 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 20 - AS35567 11230 0.5% 100.3 -- DASTO-BOSNIA-AS DASTO semtel d.o.o. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13897 17712 0.8% 8856.0 -- CDC1 - Internet Brands Inc. 2 - AS6629 7682 0.3% 3841.0 -- NOAA-AS - NOAA 3 - AS40946 7563 0.3% 3781.5 -- PROCON - Sat Track 4 - AS3909 23240 1.1% 2905.0 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - AS6174 5728 0.3% 2864.0 -- SPRINTLINK8 - Sprint 6 - AS37367 2663 0.1% 2663.0 -- CALLKEY 7 - AS14680 6725 0.3% 2241.7 -- REALE-6 - Auction.com 8 - AS18115 2137 0.1% 2137.0 -- JGS-AS-AP JG Group of Companies 9 - AS2 11735 0.5% 706.0 -- HPPL-AS-AP Hancock Prospecting Pty Ltd 10 - AS5074 3320 0.1% 1660.0 -- ASN-ATTELS - AT&T BMGS 11 - AS4467 1515 0.1% 1515.0 -- EASYLINK3 - AT&T Services, Inc. 12 - AS40279 2699 0.1% 1349.5 -- SWGA-NASHVILLE - Southwestern/Great American Inc. 13 - AS9950 4033 0.2% 1344.3 -- PUBNETPLUS2-AS-KR DACOM 14 - AS41023 3786 0.2% 1262.0 -- ARREKS-AS Agencja Rozwoju Regionalnego ARREKS S.A. 15 - AS36529 2488 0.1% 1244.0 -- AXXA-RACKCO - Rackco.com 16 - AS45344 1173 0.1% 1173.0 -- IIUM-MY International Islamic University Of Malaysia 17 - AS17293 4485 0.2% 1121.2 -- VTXC - VTX Communications 18 - AS45770 576 0.0% 576.0 -- SBY-EPROC-AS-ID Bagian Bina Program - Pemerintah Kota Surabaya 19 - AS46018 546 0.0% 546.0 -- DEPPERIN-AS-ID Departemen Perindustrian Republik Indonesia 20 - AS45698 540 0.0% 540.0 -- BONET-AS-ID Bonet Utama, PT TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.41.70.0/24 10457 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 2 - 98.158.200.0/24 8856 0.4% AS13897 -- CDC1 - Internet Brands Inc. 3 - 98.158.204.0/23 8856 0.4% AS13897 -- CDC1 - Internet Brands Inc. 4 - 192.58.232.0/24 7676 0.3% AS6629 -- NOAA-AS - NOAA 5 - 208.92.131.0/24 7561 0.3% AS40946 -- PROCON - Sat Track 6 - 151.118.255.0/24 7281 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - 151.118.254.0/24 7281 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 8 - 151.118.18.0/24 7253 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - 12.139.133.0/24 5507 0.2% AS14680 -- REALE-6 - Auction.com 10 - 194.63.9.0/24 4859 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 11 - 112.110.84.0/22 4268 0.2% AS45271 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 12 - 112.110.82.0/23 4267 0.2% AS45271 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 13 - 69.38.178.0/24 4209 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 69.31.106.0/23 4187 0.2% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 15 - 192.108.213.0/24 4179 0.2% AS1880 -- STUPI Svensk Teleutveckling & Produktinnovation, STUPI AB 16 - 58.184.229.0/24 4022 0.2% AS9950 -- PUBNETPLUS2-AS-KR DACOM 17 - 23.79.253.0/24 3779 0.2% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 18 - 23.65.27.0/24 3751 0.2% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 19 - 23.2.6.0/23 3751 0.2% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 20 - 184.27.116.0/23 3743 0.2% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From Valdis.Kletnieks at vt.edu Fri Mar 22 22:44:28 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 22 Mar 2013 18:44:28 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: Your message of "Wed, 20 Mar 2013 15:16:57 -0500." <8C04311D-EF95-4C49-97A9-09FE9680F78E@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <8C04311D-EF95-4C49-97A9-09FE9680F78E@delong.com> Message-ID: <20618.1363992268@turing-police.cc.vt.edu> On Wed, 20 Mar 2013 15:16:57 -0500, Owen DeLong said: > On Mar 20, 2013, at 9:55 AM, Seth Mattinen wrote: > > Based on the average clue of your average residential subscriber (anyone > > here need not apply) I'd say that's a good thing. > If BGP were plug-and-play automated with settings specified by the provider, > what would the user's clue level have to do with it? The hypothetical existence of such a box doesn't change the fact that providers have to make business decisions based on actual boxes and users. Yes, if a plug-n-play idiot-proof BGP box existed, then the profit calculus would be different. On the other hand, if there existed a reliable cost-effective means for faster-than-light signaling, if would drastically change intercontinental peering patterns. All the same, anybody who's planning their interconnects in 2013 reality and not looking at who has 40K km of underwater cable and who doesn't is in for a surprise.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mysidia at gmail.com Sat Mar 23 00:44:14 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 22 Mar 2013 19:44:14 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <3612B8CA-A571-4B79-8A1C-C150CA8416B6@istaff.org> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.34C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.titech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.1010503@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC!@delong.com> <53CF2D6C-EB9A-4AE5-9AAC-922A6972B140@istaff.org> <6B67CB99-CF60-4F9D-A9B9-337B18764F3F@delong.com> <3612B8CA-A571-4B79-8A1C-C150CA8416B6@istaff.org> Message-ID: On 3/20/13, John Curran wrote: > On Mar 20, 2013, at 2:25 PM, Owen DeLong wrote: >> However, if there were motivation on the provider side, automated BGP >> configuration could enable consumers to attach to multiple providers and >> actually reduce support calls significantly. Do you really think making a large SP making theirt customers' configuration more complicated, using a protocol at a scale its implementations were never designed for, will amount to a reduction in net average support costs? See... I think there is an economic argument to made against massive multihoming; upward sloping supply curve situation, ultimately slots in the global routing table are a competitive market. Providing service to a network that wants to be multihomed could be expected to incur a greater marginal price on the provider (additional overhead to implement, maintain, and service the more complicated service). If that added price tag exceeds the amount that the customer values their marginal benefit from multihoming, then requiring multihoming hurts the provider, because a lesser quantity is purchased, and hurts the customer, because their increased payment in excess of the benefit is added cost. The more multihomed customers, the more routes, the greater the marginal cost of adding every BGP router, the greater cost of every route advertised, which you could speculate the tier1's will ultimately be passing onto service providers, and then the customers, in due time. The increased price tags reduce the quantity of services purchased. > If you can figure out a way to persuade service providers of this belief, > I would ask that you also persuade them that they have to offer dual-stack > for all of their customers (which may have already resulted in them losing > a small number of customers who expected IPv6 by now... :-) Until people are actually using dual-stack services, the current perceived benefit is $0, so it's really a tough argument to make. You have to rely on the prediction, that within a few years, dual-stack services will provide the added benefit of full internet reachability, and ipv4-only services will have significant impairments. > Thanks! > /John -- -JH From jra at baylink.com Sat Mar 23 18:20:11 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 23 Mar 2013 14:20:11 -0400 (EDT) Subject: Sabey opens Intergate.Manhattan DC In-Reply-To: <27436224.10762.1364062725275.JavaMail.root@benjamin.baylink.com> Message-ID: <15606580.10764.1364062811357.JavaMail.root@benjamin.baylink.com> 1M sq ft datacenter in former VZN CO at 375 Pearl: http://www.wallstreetandtech.com/it-infrastructure/worlds-largest-high-rise-data-center-ope/240151399 >From the story: """ Intergate.Manhattan is not only one of the largest facilities [at 32 stories, all rentable space], but it also the only data center that is located in a city center, according to Sabey. However, some financial services IT experts question locating a large data center in Manhattan. "The fact that a building has integrity, and back up systems, is just one thing," says Steve Rubinow, CIO, Marketplaces Division, Thomson Reuters. "But, as we learned on 9/11 and during Sandy, you also need to be able to get people and materiel to and from the building in times of an emergency. And after 9/11, it became very apparent that building data centers on an island, whether it is Manhattan island or any other island, it is a real bother. It creates an added layer of complexity." Currently, the data center is in its first phase, providing 100,000 square feet of data center space and 5.4 Megawatts of power. Eventually, Intergate.Manhattan will accommodate 40 Megawatts of data center capacity on 600,000 square feet of data center floor space, with the additional 400,000 square feet dedicated to power, cooling and infrastructure. """ Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at delong.com Sat Mar 23 18:28:07 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Mar 2013 11:28:07 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <20618.1363992268@turing-police.cc.vt.edu> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <8C04311D-EF9! 5-4C49-97A9-09FE9680F78E@delong.com> <20618.1363992268@turing-police.cc.vt.edu> Message-ID: On Mar 22, 2013, at 15:44 , wrote: > On Wed, 20 Mar 2013 15:16:57 -0500, Owen DeLong said: >> On Mar 20, 2013, at 9:55 AM, Seth Mattinen wrote: >>> Based on the average clue of your average residential subscriber (anyone >>> here need not apply) I'd say that's a good thing. > >> If BGP were plug-and-play automated with settings specified by the provider, >> what would the user's clue level have to do with it? > > The hypothetical existence of such a box doesn't change the fact that > providers have to make business decisions based on actual boxes and users. > > Yes, if a plug-n-play idiot-proof BGP box existed, then the profit calculus > would be different. On the other hand, if there existed a reliable > cost-effective means for faster-than-light signaling, if would drastically > change intercontinental peering patterns. All the same, anybody who's planning > their interconnects in 2013 reality and not looking at who has 40K km of > underwater cable and who doesn't is in for a surprise.... > There is a difference and you know it. A reliable cost-effective means for FTL signaling is a hard problem without a known solution. An idiot-proof simple BGP configuration is a well known solution. Automating it would be relatively simple if there were the will to do so. However, the reality is that ISPs don't want the solution for a number of reasons: 1. ISPs are actually motivated to prevent customer mobility, not enable it. 2. ISPs are motivated to reduce, not increase the number of multi-homed sites occupying slots in routing tables. In addition, most of the consumers that could benefit from such a solution do not have enough knowledge to know what they should be demanding from their vendors, so they don't demand it. This is a classic case of the "invisible hand" only works when all participants have equal access to information and relatively equal knowledge. The problem with technical products and especially with technical based services products is that the vendor consistently has much greater knowledge than the subscriber and is therefore in a position to optimize for the vendors best interests even when they are counter to the best interests of their customers. Owen From mysidia at gmail.com Sat Mar 23 19:12:48 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 23 Mar 2013 14:12:48 -0500 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <20618.1363992268@turing-police.cc.vt.edu> Message-ID: On 3/23/13, Owen DeLong wrote: > A reliable cost-effective means for FTL signaling is a hard problem without > a known solution. Faster than light signalling is not merely a hard problem. Special relativity doesn't provide that information may travel faster than the maximum speed C. If you want to signal faster than light, then slow down the light. > An idiot-proof simple BGP configuration is a well known solution. Automating > it would be relatively simple if there were the will to do so. Logistical problems... if it's a multihomed connection, which of the two or three providers manages it, and gets to blame the other provider(s) when anything goes wrong: or are you gonna rely on the customer to manage it? Someone might be able to make a protocol that lets this happen, which would need to detect on a per-route basis any performance/connectivity issues, but I would say it's not any known implementation of BGP. > 1. ISPs are actually motivated to prevent customer mobility, not enable it. > 2. ISPs are motivated to reduce, not increase the number of multi-homed > sites occupying slots in routing tables. This is not some insignificant thing. The ISPs have to maintain routing tables as well; ultimately the ISP's customers are in bad shape, if too many slots are consumed. How about 3. Increased troubleshooting complexity when there are potential issues or complaints. The concept of a "fool proof" BGP configuration is clearly a new sort of myth. The idea that the protocol on its own, with a very basic config, does not ever require any additional attention, to achieve expected results; where expected results include isolation from any faults with the path from one of of the user's two, three, or four providers, and balancing for optimal throughput and best latency/loss to every destination. BGP multihoming doesn't prevent users from having issues because: o Connectivity issues that are a responsibility of one of their provider's That they might have expected multihoming to protect them against (latency, packet loss). o very Poor performance of one of their links; or poor performance of one of their links to their favorite destination o Asymmetric paths; which means that when latency or loss is poor, the customer doesn't necessarily know which provider to blame, or if both are at fault, and the providers can spend a lot of time blaming each other. These are all solvable problems, but at cost, and therefore not for massmarket lowest cost ISP service. It's not as if they can have "Hello, DSL technical support... did you try shutting off your other peers and retesting'?" The average end user won't have a clue -- they will need one of the providers, or someone else to be managing that for them, and understand how each provider is connected. I don't see large ISPs training up their support reps for DSL $60/month services, to handle BGP troubleshooting, and multihoming management/repair. > In addition, most of the consumers that could benefit from such a solution > do not have enough knowledge to know what they should be demanding > from their vendors, so they don't demand it. > Owen -- -JH From bill at herrin.us Sat Mar 23 19:53:10 2013 From: bill at herrin.us (William Herrin) Date: Sat, 23 Mar 2013 15:53:10 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <20618.1363992268@turing-police.cc.vt.edu> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <8C04311D-EF95-4C49-97A9-09FE9680F78E@delong.com> <20618.1363992268@turing-police.cc.vt.edu> Message-ID: On Fri, Mar 22, 2013 at 6:44 PM, wrote: > On Wed, 20 Mar 2013 15:16:57 -0500, Owen DeLong said: >> On Mar 20, 2013, at 9:55 AM, Seth Mattinen wrote: >> > Based on the average clue of your average residential subscriber (anyone >> > here need not apply) I'd say that's a good thing. > >> If BGP were plug-and-play automated with settings specified by the provider, >> what would the user's clue level have to do with it? > > The hypothetical existence of such a box doesn't change the fact that > providers have to make business decisions based on actual boxes and users. Providers who don't wish to be leap-frogged have to make business decisions about unserved and underserved demand for which they don't already have an effective product. > Yes, if a plug-n-play idiot-proof BGP box existed, then the profit calculus > would be different. On the other hand, if there existed a reliable > cost-effective means for faster-than-light signaling, if would drastically > change intercontinental peering patterns. That's not a particularly compelling counterpoint. We have a mechanism for multihoming: BGP. We have a mechanism for flying to the moon: rocket ships. At a strictly technical level, either could be made suitable for use by John Q. Public. In both cases the cost attributable to John Q's desired activity, when using known techniques, greatly exceeds his budget. That having been said, I'd be very interested in your take on how FTL would change intercontinental peering patterns. How would dropping all links to a 0 ms latency change the ways in which we choose to interconnect and why? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Sat Mar 23 19:52:30 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Mar 2013 12:52:30 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <20618.136399! 2268@turing-police.cc.vt.edu> Message-ID: <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> On Mar 23, 2013, at 12:12 , Jimmy Hess wrote: > On 3/23/13, Owen DeLong wrote: >> A reliable cost-effective means for FTL signaling is a hard problem without >> a known solution. > > Faster than light signalling is not merely a hard problem. > Special relativity doesn't provide that information may travel faster > than the maximum > speed C. If you want to signal faster than light, then slow down the light. > >> An idiot-proof simple BGP configuration is a well known solution. Automating >> it would be relatively simple if there were the will to do so. > > Logistical problems... if it's a multihomed connection, which of the > two or three providers manages it, and gets to blame the other > provider(s) when anything goes wrong: or are you gonna rely on the > customer to manage it? > The box could (pretty easily) be built with a "Primary" and "Secondary" port. The cable plugged into the primary port would go to the ISP that sets the configuration. The cable plugged into the other port would go to an ISP expected to accept the announcements of the prefix provided by the ISP on the primary port. BFD could be used to illuminate a tri-color LED on the box for each port, which would be green if BFD state is good and red if BFD state is bad. At that point, whichever one is red gets the blame. If they're both green, then traffic is going via the primary and the primary gets the blame. If you absolutely have to troubleshoot which provider is broken, then start by unplugging the secondary. If it doesn't start working in 5 minutes, then clearly there's a problem with the primary regardless of what else is happening. Lather, rinse, repeat for the secondary. > Someone might be able to make a protocol that lets this happen, which > would need to detect on a per-route basis any performance/connectivity > issues, but I would say it's not any known implementation of BGP. A few additional options to DHCP could actually cover it from the primary perspective. For the secondary provider, it's a little more complicated, but could be mostly automated so long as the customer identifies the primary provider and/or provides an LOA for the authorized prefix from the primary to the secondary. The only complexity in the secondary case is properly filtering the announcement of the prefix assigned by the primary. >> 1. ISPs are actually motivated to prevent customer mobility, not enable it. > >> 2. ISPs are motivated to reduce, not increase the number of multi-homed >> sites occupying slots in routing tables. > > This is not some insignificant thing. The ISPs have to maintain > routing tables > as well; ultimately the ISP's customers are in bad shape, if too many slots > are consumed. > I never said it was insignificant. I said that solving the multihoming problem in this manner was trivial if there was will to do so. I also said that the above were contributing factors in the lack of will to do so. > How about > 3. Increased troubleshooting complexity when there are potential > issues or complaints. > I do not buy that it is harder to troubleshoot a basic BGP configuration than a multi-carrier NAT-based solution that goes woefully awry. I'm sorry, I've done the troubleshooting on both scenarios and I have to say that if you think NAT makes this easier, you live in a different world than I do. > The concept of a "fool proof" BGP configuration is clearly a new sort of myth. Not really. Customer router accepts default from primary and secondary providers. So long as default remains, primary is preferred. If primary default goes away, secondary is preferred. Customer box gets prefix (via DHCP-PD or static config or whatever either from primary or from RIR). Advertises prefix to both primary and secondary. All configuration of the BGP sessions is automated within the box other than static configuration of customer prefix (if static is desired). Primary/Secondary choice is made by plugging providers into the Primary or Secondary port on the box. > The idea that the protocol on its own, with a very basic config, does > not ever require > any additional attention, to achieve expected results; where > expected results include isolation from any faults with the path from > one of of the user's two, three, or four providers, and balancing > for optimal throughput and best latency/loss to every destination. I have installed these configurations at customer sites for several of my consulting clients that wanted to multihome their SMBs. Some of them have been running for more than 8 years without a single issue. For all of the above requirements, no. You can't do that with the most advanced manual BGP configurations today. However, if we reduce it to: 1. The internet connection stays up so long as one of the two providers is up. 2. Traffic prefers the primary provider so long as the primary provider is up. 3. My addressing remains stable so long as I remain connected to the primary provider (or if I use RIR based addressing, longer). Then what I have proposed actually is achievable, does work, and does actually meet the needs of 99+% of organizations that wish to multihome. > BGP multihoming doesn't prevent users from having issues because: > > o Connectivity issues that are a responsibility of one of their provider's > That they might have expected multihoming to protect them against > (latency, packet loss). Correct. However, this is true of ANY multihoming solution. The dual- provider NAT solution certainly does NOT improve this. > o very Poor performance of one of their links; or poor > performance of one of their > links to their favorite destination See above. > o Asymmetric paths; which means that when latency or loss is poor, > the customer doesn't necessarily know which provider to blame, > or if both are at fault, and the providers can spend a lot of time > blaming each other. See above. > These are all solvable problems, but at cost, and therefore not for > massmarket lowest cost ISP service. My point is that the automated simple BGP solution I propose can provide a better customer experience than the currently popular NAT-based multihoming with simpler troubleshooting and lower costs. > It's not as if they can have > "Hello, DSL technical support... did you try shutting off your > other peers and retesting'?" ROFL. > The average end user won't have a clue -- they will need one of the > providers, or someone else to be managing that for them, and > understand how each provider is connected. Again, you're setting a much higher goal than I was. My goal was to do something better than what is currently being done. (Connect a router to two providers and use NAT to choose between them). > I don't see large ISPs training up their support reps for DSL > $60/month services, to handle BGP troubleshooting, and multihoming > management/repair. But they already get stuck with this in the current NAT-based solution which is even harder to troubleshoot and creates even more problems. Owen From kyle.creyts at gmail.com Sun Mar 24 02:47:12 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sat, 23 Mar 2013 19:47:12 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: You do realize that there are quite a few people (home broadband subscribers?) who just "go do something else" when their internet goes down, right? There are people who don't understand the difference between "a site being slow" and packet-loss. For many of these people, losing internet service carries zero business impact, and relatively little life impact; they might even realize they have better things to do than watch cat videos or scroll through endless social media feeds. Will they really demand ubiquitous, unabridged connectivity? When? On Mar 23, 2013 12:58 PM, "Owen DeLong" wrote: > > > On Mar 23, 2013, at 12:12 , Jimmy Hess wrote: > > > On 3/23/13, Owen DeLong wrote: > >> A reliable cost-effective means for FTL signaling is a hard problem without > >> a known solution. > > > > Faster than light signalling is not merely a hard problem. > > Special relativity doesn't provide that information may travel faster > > than the maximum > > speed C. If you want to signal faster than light, then slow down the light. > > > >> An idiot-proof simple BGP configuration is a well known solution. Automating > >> it would be relatively simple if there were the will to do so. > > > > Logistical problems... if it's a multihomed connection, which of the > > two or three providers manages it, and gets to blame the other > > provider(s) when anything goes wrong: or are you gonna rely on the > > customer to manage it? > > > > The box could (pretty easily) be built with a "Primary" and "Secondary" port. > > The cable plugged into the primary port would go to the ISP that sets the > configuration. The cable plugged into the other port would go to an ISP > expected to accept the announcements of the prefix provided by the ISP > on the primary port. > > BFD could be used to illuminate a tri-color LED on the box for each port, > which would be green if BFD state is good and red if BFD state is bad. > > At that point, whichever one is red gets the blame. If they're both green, > then traffic is going via the primary and the primary gets the blame. > > If you absolutely have to troubleshoot which provider is broken, then > start by unplugging the secondary. If it doesn't start working in 5 minutes, > then clearly there's a problem with the primary regardless of what else > is happening. > > Lather, rinse, repeat for the secondary. > > > Someone might be able to make a protocol that lets this happen, which > > would need to detect on a per-route basis any performance/connectivity > > issues, but I would say it's not any known implementation of BGP. > > A few additional options to DHCP could actually cover it from the primary > perspective. > > For the secondary provider, it's a little more complicated, but could be > mostly automated so long as the customer identifies the primary provider > and/or provides an LOA for the authorized prefix from the primary to > the secondary. > > The only complexity in the secondary case is properly filtering the announcement > of the prefix assigned by the primary. > > >> 1. ISPs are actually motivated to prevent customer mobility, not enable it. > > > >> 2. ISPs are motivated to reduce, not increase the number of multi-homed > >> sites occupying slots in routing tables. > > > > This is not some insignificant thing. The ISPs have to maintain > > routing tables > > as well; ultimately the ISP's customers are in bad shape, if too many slots > > are consumed. > > > > I never said it was insignificant. I said that solving the multihoming problem > in this manner was trivial if there was will to do so. I also said that the above > were contributing factors in the lack of will to do so. > > > How about > > 3. Increased troubleshooting complexity when there are potential > > issues or complaints. > > > > I do not buy that it is harder to troubleshoot a basic BGP configuration > than a multi-carrier NAT-based solution that goes woefully awry. > > I'm sorry, I've done the troubleshooting on both scenarios and I have > to say that if you think NAT makes this easier, you live in a different > world than I do. > > > The concept of a "fool proof" BGP configuration is clearly a new sort of myth. > > Not really. > > Customer router accepts default from primary and secondary providers. > So long as default remains, primary is preferred. If primary default goes > away, secondary is preferred. > > Customer box gets prefix (via DHCP-PD or static config or whatever > either from primary or from RIR). Advertises prefix to both primary > and secondary. > > All configuration of the BGP sessions is automated within the box > other than static configuration of customer prefix (if static is desired). > > Primary/Secondary choice is made by plugging providers into the > Primary or Secondary port on the box. > > > The idea that the protocol on its own, with a very basic config, does > > not ever require > > any additional attention, to achieve expected results; where > > expected results include isolation from any faults with the path from > > one of of the user's two, three, or four providers, and balancing > > for optimal throughput and best latency/loss to every destination. > > I have installed these configurations at customer sites for several of > my consulting clients that wanted to multihome their SMBs. > > Some of them have been running for more than 8 years without a > single issue. > > For all of the above requirements, no. You can't do that with the most > advanced manual BGP configurations today. > > However, if we reduce it to: > > 1. The internet connection stays up so long as one of the two > providers is up. > > 2. Traffic prefers the primary provider so long as the primary provider > is up. > > 3. My addressing remains stable so long as I remain connected to > the primary provider (or if I use RIR based addressing, longer). > > Then what I have proposed actually is achievable, does work, and > does actually meet the needs of 99+% of organizations that wish to > multihome. > > > BGP multihoming doesn't prevent users from having issues because: > > > > o Connectivity issues that are a responsibility of one of their provider's > > That they might have expected multihoming to protect them against > > (latency, packet loss). > > Correct. However, this is true of ANY multihoming solution. The dual- > provider NAT solution certainly does NOT improve this. > > > o very Poor performance of one of their links; or poor > > performance of one of their > > links to their favorite destination > > See above. > > > o Asymmetric paths; which means that when latency or loss is poor, > > the customer doesn't necessarily know which provider to blame, > > or if both are at fault, and the providers can spend a lot of time > > blaming each other. > > See above. > > > These are all solvable problems, but at cost, and therefore not for > > massmarket lowest cost ISP service. > > My point is that the automated simple BGP solution I propose can provide > a better customer experience than the currently popular NAT-based > multihoming with simpler troubleshooting and lower costs. > > > It's not as if they can have > > "Hello, DSL technical support... did you try shutting off your > > other peers and retesting'?" > > ROFL. > > > The average end user won't have a clue -- they will need one of the > > providers, or someone else to be managing that for them, and > > understand how each provider is connected. > > Again, you're setting a much higher goal than I was. > > My goal was to do something better than what is currently being done. > (Connect a router to two providers and use NAT to choose between them). > > > I don't see large ISPs training up their support reps for DSL > > $60/month services, to handle BGP troubleshooting, and multihoming > > management/repair. > > But they already get stuck with this in the current NAT-based solution which > is even harder to troubleshoot and creates even more problems. > > Owen > > From mpalmer at hezmatt.org Sun Mar 24 04:13:05 2013 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 24 Mar 2013 15:13:05 +1100 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: <20130324041305.GO4159@hezmatt.org> On Sat, Mar 23, 2013 at 07:47:12PM -0700, Kyle Creyts wrote: > You do realize that there are quite a few people (home broadband > subscribers?) who just "go do something else" when their internet goes > down, right? [...] > Will they really demand ubiquitous, unabridged connectivity? > > When? Probably around the time their phone, TV, books, shopping, and *life* are all delivered over that connectivity. Especially if they don't have any meaningful local storage or processing, as everything has been delegated to "the cloud". In practice, however, I suspect that we as providers will just get a whole lot better at providing connectivity, rather than have everyone work out how to do fully-diverse BGP from their homes. - Matt From joelja at bogus.com Sun Mar 24 15:41:33 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 24 Mar 2013 08:41:33 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: <20130324041305.GO4159@hezmatt.org> References: <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> <20130324041305.GO4159@hezmatt.org> Message-ID: <514F1EAD.2060001@bogus.com> On 3/23/13 9:13 PM, Matt Palmer wrote: > On Sat, Mar 23, 2013 at 07:47:12PM -0700, Kyle Creyts wrote: >> You do realize that there are quite a few people (home broadband >> subscribers?) who just "go do something else" when their internet goes >> down, right? > [...] > >> Will they really demand ubiquitous, unabridged connectivity? >> >> When? > Probably around the time their phone, TV, books, shopping, and *life* are > all delivered over that connectivity. Especially if they don't have any > meaningful local storage or processing, as everything has been delegated to > "the cloud". When the cable is down there's the verizon usb stick (which this point can be into the router and serve the whole house), when verizon is down there's t-mobile handset. when t-mobile is down there's a workphone with at&t. When the cable/verizon/t-mobile/at&t are all down for any signifcant length of time, I expect to be digging my neighbors our of the sorts of natural disasters that befall California and listening to the radio and maybe 2-meter. > In practice, however, I suspect that we as providers will just get a whole > lot better at providing connectivity, rather than have everyone work out how > to do fully-diverse BGP from their homes. I'm going to be somewhat contrarian, connectivity/availability with cloud services is important, where you access them from not so much. I doubt very much that reliance on the cloud drives multihoming for end-sites/consumers, it drives a demand for connectivity diversity so that one failure mode doesn't leave you stranded. > > - Matt > > From bill at herrin.us Sun Mar 24 16:06:40 2013 From: bill at herrin.us (William Herrin) Date: Sun, 24 Mar 2013 12:06:40 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: On Sat, Mar 23, 2013 at 10:47 PM, Kyle Creyts wrote: > Will they really demand ubiquitous, unabridged connectivity? > > When? When the older generation that considers the Internet a side show dies off. When your grandparents' power went out, they broke out candles and kerosene lamps. When yours goes out, you pull out flashlights and generators. And when it stays out you book a motel room so your family can have air conditioning and television. For most folks under 30 and many who are older, Internet isn't a side show, it's a way of life. An outage is like a power failure or the car going kaput: a major disruption to life's flow. This need won't be ubiquitous for two to three decades, but every year between now and then the percentage of your customer base which demands unabridged connectivity will grow. What do you have in the pipeline to address that demand as it arrives? BGP multihoming won't get the job done for the hundred million households in North America, let alone the seven billion people in the world. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From george.herbert at gmail.com Sun Mar 24 16:47:06 2013 From: george.herbert at gmail.com (George Herbert) Date: Sun, 24 Mar 2013 09:47:06 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: <47B77DEB-D762-4CFF-83B5-3CD10221DECF@gmail.com> On Mar 23, 2013, at 7:47 PM, Kyle Creyts wrote: > Will they really demand ubiquitous, unabridged connectivity? Let's back up. End users do not as a rule* have persistent inbound connections. If they have DSL and a Cable Modem they can switch manually (or with a little effort automatically) if one goes down. * Servers-at-home-or-small-office is the use case for Owen's magic BGP box. Which is true for many of us and other core geeks but not an appreciable percent of the populace. I believe that full BGP to end user is less practical for this use case than a geographically dispersed BGP external facing intermediary whose connectivity to the "end user servers" is full-mesh multi-provider-multi-physical-link VPNs. It's a lot easier to manage and has less chance of a config goof blowing up bigger network neighbors. Every time I look at productizing this, though, the market's too small to support it. Which probably means it's way too small for home BGP... George William Herbert Sent from my iPhone From jcurran at istaff.org Sun Mar 24 16:54:18 2013 From: jcurran at istaff.org (John Curran) Date: Sun, 24 Mar 2013 12:54:18 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: On Mar 24, 2013, at 12:06 PM, William Herrin wrote: > ... > For most folks under 30 and many who are older, Internet isn't a side > show, it's a way of life. An outage is like a power failure or the car > going kaput: a major disruption to life's flow. Yes, this is increasingly the case (and may not be as generational as you think) > This need won't be ubiquitous for two to three decades, but every year > between now and then the percentage of your customer base which > demands unabridged connectivity will grow. I believe that the percentage which _expects_ unabridged connectivity today is quite high, but that does not necessarily mean actual _demand_ (i.e. folks who go out and make the necessary arrangements despite the added cost and hassle...) The power analogy might be apt here; I know many folks who have a home UPS, a few that have a manual generator, and just one or two who did the entire home automatic UPS/generator combo that's really necessary for 100% reliable power. This reflects a truism: while many people may expect 100% reliable today, the demand (in most areas) simply doesn't match. > What do you have in the pipeline to address that demand as it arrives? See above: increasing expectations does not necessarily equate with demand. FYI, /John Disclaimer: My views alone. Sent via less than 100% reliable networks. From nanog at w-link.com Tue Mar 19 16:44:36 2013 From: nanog at w-link.com (Nanog Mailing List) Date: Tue, 19 Mar 2013 09:44:36 -0700 Subject: Bandwidth.com SIP trunking issue Message-ID: <514895F4.5030803@w-link.com> Hello, I am curious if anyone else whom may use Bandwidth.com for their SIP trunks are receiving the "All circuits are busy now" error message today. This just started this morning, and nothing has changed in machine configuration since yesterday (when everything worked correctly). Thanks for the heads up. -Bret Worldlink ISP 206-361-8785 From fjblas at arcos.inf.uc3m.es Tue Mar 19 21:19:52 2013 From: fjblas at arcos.inf.uc3m.es (Javier Garcia Blas) Date: Tue, 19 Mar 2013 22:19:52 +0100 Subject: Call for Papers: Energy-Efficient HPC & Communication workshop (E2HPC2) 2013. Deadline: March 29th, 2013 Message-ID: <20130319211952.GA21206@piojito.arcos.inf.uc3m.es> Apologies for multiple posting. ===================================================================== The first Energy-Efficient High Performance Computing & Communication workshop will be co-located with EuroMPI 2013 in Madrid. Energy-awareness is now a main topic for HPC systems. The goal of this workshop is to discuss latest researches on the impact and possibles leverages of communications for such systems. E2HPC2 solicits original and non-published or under-review articles on the field of energy-aware communication in HPC environment. This workshop is co-located with EuroMPI as MPI is the main communication interface in those environments. http://www.irit.fr/~Georges.Da-Costa/e2hpc2.html E2HPC will be held on Tuesday 17th of September 2013. Submission of full papers: March 29th, 2013 Program Chair : Georges Da Costa Topics ------ Relevant topics for the conference include, but are not limited to the following: * Energy efficient MPI implementation * Performance/Energy tradeoffs in MPI programs * Energy evaluation and models of HPC applications and communication library * Energy-Aware large scale HPC runtime * Return of experience on complex applications from an energy/power point of view Time-line --------- * Submission of full papers: March 29th, 2013 * Author notification: May 11th, 2013 * Camera Ready papers due: June 15th, 2013 * Workshop: September 17th, 2013 Program Committee ----------------- * Georges Da Costa IRIT/Toulouse III * Jesus Carretero Universidad Carlos III de Madrid * Emmanuel Jeannot INRIA * Jean-Marc Pierson IRIT * Lars Dittmann Technical University of Denmark, Department of Photonics Engineering * Anne-C??cile Orgerie CNRS * Ariel Oleksiak Poznan Supercomputing and Networking Center * Manuel F. Dolz Depto. de Ingenier??a y Ciencia de los Computadores, Universitat Jaume I * Laurent Lefevre INRIA * Julius ??ilinskas Vilnius University * Francisco Almeida La Laguna University * Davide Careglio Universitat Polit??cnica de Catalunya Submission ---------- Contributors are invited to submit a full paper as a PDF document not exceeding 6 pages in English. The title page should contain an abstract of at most 100 words and five specific, topical keywords. The paper must be formatted according to double-column ACM ICPS proceedings style. The usage of LaTeX for preparation of the contribution as well as the submission in camera ready format is strongly recommended. Style files can be found at http://www.acm.org/publications/icps-instructions/. Selected and presented during the workshop papers will be published in the digital library of ACM. All contributions will be fully peer reviewed by the program committee. Papers shall be submitted electronically via Easychair, see https://www.easychair.org/conferences/?conf=e2hpc22013. From joelja at bogus.com Sun Mar 24 21:10:37 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 24 Mar 2013 14:10:37 -0700 Subject: Sabey opens Intergate.Manhattan DC In-Reply-To: <15606580.10764.1364062811357.JavaMail.root@benjamin.baylink.com> References: <15606580.10764.1364062811357.JavaMail.root@benjamin.baylink.com> Message-ID: <514F6BCD.8080902@bogus.com> On 3/23/13 11:20 AM, Jay Ashworth wrote: > 1M sq ft datacenter in former VZN CO at 375 Pearl: > > http://www.wallstreetandtech.com/it-infrastructure/worlds-largest-high-rise-data-center-ope/240151399 > > From the story: > > """ > Intergate.Manhattan is not only one of the largest facilities [at 32 stories, all rentable space], but it also the only data center that is located in a city center, according to Sabey. totally wrong without the context. Sabey Data Center Properties operates 13 facilities in the United States, totaling approximately 2 million square feet of data center space. Intergate.Manhattan is not only one of the largest facilities, but it also the only data center that is located in a city center, according to Sabey. plenty on other DCs in city centers, the only one of theirs that is... > However, some financial services IT experts question locating a large data center in Manhattan. "The fact that a building has integrity, and back up systems, is just one thing," says Steve Rubinow, CIO, Marketplaces Division, Thomson Reuters. "But, as we learned on 9/11 and during Sandy, you also need to be able to get people and materiel to and from the building in times of an emergency. And after 9/11, it became very apparent that building data centers on an island, whether it is Manhattan island or any other island, it is a real bother. It creates an added layer of complexity." > > Currently, the data center is in its first phase, providing 100,000 square feet of data center space and 5.4 Megawatts of power. Eventually, Intergate.Manhattan will accommodate 40 Megawatts of data center capacity on 600,000 square feet of data center floor space, with the additional 400,000 square feet dedicated to power, cooling and infrastructure. > """ > > Cheers, > -- jra From kyle.creyts at gmail.com Mon Mar 25 01:43:56 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sun, 24 Mar 2013 18:43:56 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: As an under-30, working in the industry, I have to say, when the power goes out at home for a few days, we pull out the camping gear. When our cable-based internet goes out, our life changes hardly at all. We go for a walk, or hike, do the things we would normally. I can imagine that an outage of 1 week would be slightly different, but I'm pretty sure that the spans of most of the outages which would be resolved by multi-provider solutions like those outlined herein would probably only apply to situations where the outage would only last less than 48 hours. On Sun, Mar 24, 2013 at 9:06 AM, William Herrin wrote: > On Sat, Mar 23, 2013 at 10:47 PM, Kyle Creyts > wrote: > > Will they really demand ubiquitous, unabridged connectivity? > > > > When? > > When the older generation that considers the Internet a side show dies off. > > When your grandparents' power went out, they broke out candles and > kerosene lamps. > > When yours goes out, you pull out flashlights and generators. And when > it stays out you book a motel room so your family can have air > conditioning and television. > > For most folks under 30 and many who are older, Internet isn't a side > show, it's a way of life. An outage is like a power failure or the car > going kaput: a major disruption to life's flow. > > > This need won't be ubiquitous for two to three decades, but every year > between now and then the percentage of your customer base which > demands unabridged connectivity will grow. > > What do you have in the pipeline to address that demand as it arrives? > BGP multihoming won't get the job done for the hundred million > households in North America, let alone the seven billion people in the > world. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From owen at delong.com Mon Mar 25 02:31:38 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 24 Mar 2013 19:31:38 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.4C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.itech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@gmail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: <940D08B8-7409-43F6-93FF-25F177A3B68E@delong.com> I assume those people will not bother with any attempt to multihome in any form. They are not, therefore, part of what is being discussed here. Owen On Mar 23, 2013, at 19:47 , Kyle Creyts wrote: > You do realize that there are quite a few people (home broadband subscribers?) who just "go do something else" when their internet goes down, right? > > There are people who don't understand the difference between "a site being slow" and packet-loss. For many of these people, losing internet service carries zero business impact, and relatively little life impact; they might even realize they have better things to do than watch cat videos or scroll through endless social media feeds. > > Will they really demand ubiquitous, unabridged connectivity? > > When? > > On Mar 23, 2013 12:58 PM, "Owen DeLong" wrote: > > > > > > On Mar 23, 2013, at 12:12 , Jimmy Hess wrote: > > > > > On 3/23/13, Owen DeLong wrote: > > >> A reliable cost-effective means for FTL signaling is a hard problem without > > >> a known solution. > > > > > > Faster than light signalling is not merely a hard problem. > > > Special relativity doesn't provide that information may travel faster > > > than the maximum > > > speed C. If you want to signal faster than light, then slow down the light. > > > > > >> An idiot-proof simple BGP configuration is a well known solution. Automating > > >> it would be relatively simple if there were the will to do so. > > > > > > Logistical problems... if it's a multihomed connection, which of the > > > two or three providers manages it, and gets to blame the other > > > provider(s) when anything goes wrong: or are you gonna rely on the > > > customer to manage it? > > > > > > > The box could (pretty easily) be built with a "Primary" and "Secondary" port. > > > > The cable plugged into the primary port would go to the ISP that sets the > > configuration. The cable plugged into the other port would go to an ISP > > expected to accept the announcements of the prefix provided by the ISP > > on the primary port. > > > > BFD could be used to illuminate a tri-color LED on the box for each port, > > which would be green if BFD state is good and red if BFD state is bad. > > > > At that point, whichever one is red gets the blame. If they're both green, > > then traffic is going via the primary and the primary gets the blame. > > > > If you absolutely have to troubleshoot which provider is broken, then > > start by unplugging the secondary. If it doesn't start working in 5 minutes, > > then clearly there's a problem with the primary regardless of what else > > is happening. > > > > Lather, rinse, repeat for the secondary. > > > > > Someone might be able to make a protocol that lets this happen, which > > > would need to detect on a per-route basis any performance/connectivity > > > issues, but I would say it's not any known implementation of BGP. > > > > A few additional options to DHCP could actually cover it from the primary > > perspective. > > > > For the secondary provider, it's a little more complicated, but could be > > mostly automated so long as the customer identifies the primary provider > > and/or provides an LOA for the authorized prefix from the primary to > > the secondary. > > > > The only complexity in the secondary case is properly filtering the announcement > > of the prefix assigned by the primary. > > > > >> 1. ISPs are actually motivated to prevent customer mobility, not enable it. > > > > > >> 2. ISPs are motivated to reduce, not increase the number of multi-homed > > >> sites occupying slots in routing tables. > > > > > > This is not some insignificant thing. The ISPs have to maintain > > > routing tables > > > as well; ultimately the ISP's customers are in bad shape, if too many slots > > > are consumed. > > > > > > > I never said it was insignificant. I said that solving the multihoming problem > > in this manner was trivial if there was will to do so. I also said that the above > > were contributing factors in the lack of will to do so. > > > > > How about > > > 3. Increased troubleshooting complexity when there are potential > > > issues or complaints. > > > > > > > I do not buy that it is harder to troubleshoot a basic BGP configuration > > than a multi-carrier NAT-based solution that goes woefully awry. > > > > I'm sorry, I've done the troubleshooting on both scenarios and I have > > to say that if you think NAT makes this easier, you live in a different > > world than I do. > > > > > The concept of a "fool proof" BGP configuration is clearly a new sort of myth. > > > > Not really. > > > > Customer router accepts default from primary and secondary providers. > > So long as default remains, primary is preferred. If primary default goes > > away, secondary is preferred. > > > > Customer box gets prefix (via DHCP-PD or static config or whatever > > either from primary or from RIR). Advertises prefix to both primary > > and secondary. > > > > All configuration of the BGP sessions is automated within the box > > other than static configuration of customer prefix (if static is desired). > > > > Primary/Secondary choice is made by plugging providers into the > > Primary or Secondary port on the box. > > > > > The idea that the protocol on its own, with a very basic config, does > > > not ever require > > > any additional attention, to achieve expected results; where > > > expected results include isolation from any faults with the path from > > > one of of the user's two, three, or four providers, and balancing > > > for optimal throughput and best latency/loss to every destination. > > > > I have installed these configurations at customer sites for several of > > my consulting clients that wanted to multihome their SMBs. > > > > Some of them have been running for more than 8 years without a > > single issue. > > > > For all of the above requirements, no. You can't do that with the most > > advanced manual BGP configurations today. > > > > However, if we reduce it to: > > > > 1. The internet connection stays up so long as one of the two > > providers is up. > > > > 2. Traffic prefers the primary provider so long as the primary provider > > is up. > > > > 3. My addressing remains stable so long as I remain connected to > > the primary provider (or if I use RIR based addressing, longer). > > > > Then what I have proposed actually is achievable, does work, and > > does actually meet the needs of 99+% of organizations that wish to > > multihome. > > > > > BGP multihoming doesn't prevent users from having issues because: > > > > > > o Connectivity issues that are a responsibility of one of their provider's > > > That they might have expected multihoming to protect them against > > > (latency, packet loss). > > > > Correct. However, this is true of ANY multihoming solution. The dual- > > provider NAT solution certainly does NOT improve this. > > > > > o very Poor performance of one of their links; or poor > > > performance of one of their > > > links to their favorite destination > > > > See above. > > > > > o Asymmetric paths; which means that when latency or loss is poor, > > > the customer doesn't necessarily know which provider to blame, > > > or if both are at fault, and the providers can spend a lot of time > > > blaming each other. > > > > See above. > > > > > These are all solvable problems, but at cost, and therefore not for > > > massmarket lowest cost ISP service. > > > > My point is that the automated simple BGP solution I propose can provide > > a better customer experience than the currently popular NAT-based > > multihoming with simpler troubleshooting and lower costs. > > > > > It's not as if they can have > > > "Hello, DSL technical support... did you try shutting off your > > > other peers and retesting'?" > > > > ROFL. > > > > > The average end user won't have a clue -- they will need one of the > > > providers, or someone else to be managing that for them, and > > > understand how each provider is connected. > > > > Again, you're setting a much higher goal than I was. > > > > My goal was to do something better than what is currently being done. > > (Connect a router to two providers and use NAT to choose between them). > > > > > I don't see large ISPs training up their support reps for DSL > > > $60/month services, to handle BGP troubleshooting, and multihoming > > > management/repair. > > > > But they already get stuck with this in the current NAT-based solution which > > is even harder to troubleshoot and creates even more problems. > > > > Owen > > > > From charles-lists at knownelement.com Mon Mar 25 04:56:41 2013 From: charles-lists at knownelement.com (Charles Wyble) Date: Sun, 24 Mar 2013 23:56:41 -0500 Subject: Last mile multihoming Message-ID: So isnt the most likely interruption to service due to a last mile physical media issue? Or say a regional fiber cut that takes out the towers you can reach and the upstream connection from your cable and telco providers? Imo at the edge, BGP mostly protects you from layer 8 fail (if youve done some basic best practice configuration). In theory, issues below that (at least in the dist/core at l1 to 3) are handled by other redundancy protections hidden from you (hsrp, fiber ring with protected path etc). As for dfz explosion, would mpls/private as/ vrf be a workable approach for bgp at the edge? So I live in Austin. I have available to me two hfc providers (grande and twc) and att. I also have sprint/clear vzw/tmo. I havent done an analysis of wisp offerings (if any are on list, please email me at charles at thefnf.org as im looking for a non ilec path for redunancy). So lets break this down: I only know of one att co in town. (Im sure if there is more, you will let me know). So the chances of that failing are decently high. Also my experience with att dsl have been mixed, unless im homed direct to the co. Vz dsl otoh has always been rock solid. Also att is retiring dsl/copper. I refuse to use uverse as they dont offer a unbundled modem/router or a way to do bridge mode. Oh and no ipv6. (If you can put a modem in bridge mode and still have working tv, please let me know. Ive not been able to find a solution). The chances of someone driving into the dslam serving my complex or the pedastal down the street is high (100% as it has happend a couple times). So this means I need a wireless backhaul. All of the providers I can reach colocate on exactly one tower. Surrounded by a chain link fence, across from a walmart. (Im in north austin near cameron and 183 for anyone who lives in town). The chances of the fiber serving that tower being cut is unknown, but not outside the realm of possibility. Or say the walmart big rig over correcting due to a driver coming around the blind curve near there and plowing into thr tower. Etc. So my best bet for uninterrupted connectivity seems to be running two openvpn tunels on my home edge pfsense router, each to a endpoint in a colo. I already have a full rack of gear in joesdatacenter in kc, and its fully redundant. I also run all of my web/mail/software dev from there, so its not soley for bgp purposes. Most folks I imagine may have their stuff in a colo as well and not want to run that at home. (I started a thread on that once upon a time). It so happens, that I have various things which I cant run there (rf equipment which I need to frequently reflash and move around). So running bgp on my colo gear and announcing a /48 that ive assigned to my house seems like a good idea. And I can easily cross connect to kcix and have lots of bgp fun. The latency would be a bit high, but it already is and I dont have any redundant connectivitym Ok. So thats great. Now who is my secondary? Is a vps at say linode sufficient for a secondary bgp announcer? Will they sell me bgp enabled transit? Will other vps providers? Do I need a box in a rack at a local nap? Is there an ix in austin, or should I rack a box in Dallas? Once i have two providerdls, then i can easily use pfsense multi wan failover and if a circuit goes down, life goes on as I rely on bgp to detect the link failure and handle it. Yes? No? Maybe? So to me, this seems like a solved problem. Run multilple diverse (carrier, media type) circuits to your edge, put a pfsense (asa, whatever is your poison but i like pfsense the best for multi wan failover), openvpn (i cant stand ipsec) to colo, cross connect to ... oh I dunno he.net :) bgp for free. Done. For about... hmmm.. 500.00 a month? (Many colos might not do bgp with you for less then a quarter rack, and I presume anyone serious enough about uninterrupted service on a reasonable budget can do 500.00 a month). Thie discussion on soho multihoming has been fascinating to me, and I wanted to go through a thought exercise for what I imagine is a common scenario (main gear in a bgp enabled sp, office gear needing to be reachable by remote personnel in a non bgp enabled sp). Would love to hear what you folks think. -- Charles Wyble charles at thefnf.org / 818 280 7059 CTO Free Network Foundation (www.thefnf.org) From jared at puck.nether.net Mon Mar 25 14:22:08 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 10:22:08 -0400 Subject: Open Resolver Problems Message-ID: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> All, Open resolvers pose a security threat. I wanted to let everyone know about a search tool that can help you find the ones within your organization. Treat it like a big "BETA" stamp is across it, but please try it out and see if you can close down any hosts within your network. This threat is larger than the SMURF amplification attacks in the past and can result in some quite large attacks. I've seen this spilling out into other mailing lists (e.g.: juniper-nap and others). Please send feedback about links that should be included or documentation and spelling errors to me. openresolverproject.org Some basic stats: 27 million resolvers existed as of this dataset collection only 2.1 million of them were "closed". We have a lot to do to close the hosts, please do what you can to help. Thanks, - Jared From swmike at swm.pp.se Mon Mar 25 14:33:09 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 25 Mar 2013 15:33:09 +0100 (CET) Subject: Open Resolver Problems In-Reply-To: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> Message-ID: On Mon, 25 Mar 2013, Jared Mauch wrote: > We have a lot to do to close the hosts, please do what you can to help. I would like to be able to request an IP list of open resolvers in my ASN, perhaps sent to the contact details in RIPE whois database to make sure I'm not falsely representing that ASN. There doesn't seem to be a way to get this done using that webpage? -- Mikael Abrahamsson email: swmike at swm.pp.se From hhoffman at ip-solutions.net Mon Mar 25 14:45:43 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Mon, 25 Mar 2013 10:45:43 -0400 Subject: Open Resolver Problems In-Reply-To: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> Message-ID: <51506317.5080409@ip-solutions.net> What are those who provide open resolvers, such as google, doing to combat the problem? It would be nice to be able to provide open resolvers as a service and combat the various threats associated with them. Cheers, Harry On 03/25/2013 10:22 AM, Jared Mauch wrote: > All, > > Open resolvers pose a security threat. I wanted to let everyone know about a search tool that can help you find the ones within your organization. Treat it like a big "BETA" stamp is across it, but please try it out and see if you can close down any hosts within your network. > > This threat is larger than the SMURF amplification attacks in the past and can result in some quite large attacks. I've seen this spilling out into other mailing lists (e.g.: juniper-nap and others). > > Please send feedback about links that should be included or documentation and spelling errors to me. > > openresolverproject.org > > Some basic stats: > > 27 million resolvers existed as of this dataset collection > > only 2.1 million of them were "closed". > > We have a lot to do to close the hosts, please do what you can to help. > > Thanks, > > - Jared > > From jared at puck.nether.net Mon Mar 25 14:53:05 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 09:53:05 -0500 Subject: Open Resolver Problems In-Reply-To: <51506317.5080409@ip-solutions.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506317.5080409@ip-solutions.net> Message-ID: <11534938-A0ED-439E-8B0E-17B9D4DD9E44@puck.nether.net> I think if we get to that small number from tens of millions then we are in much better shape. Closing them and setting up rate limiting on your authorities will go a long way. Jared Mauch On Mar 25, 2013, at 9:45 AM, Harry Hoffman wrote: > What are those who provide open resolvers, such as google, doing to > combat the problem? > > It would be nice to be able to provide open resolvers as a service and > combat the various threats associated with them. > > > Cheers, > Harry > > On 03/25/2013 10:22 AM, Jared Mauch wrote: >> All, >> >> Open resolvers pose a security threat. I wanted to let everyone know about a search tool that can help you find the ones within your organization. Treat it like a big "BETA" stamp is across it, but please try it out and see if you can close down any hosts within your network. >> >> This threat is larger than the SMURF amplification attacks in the past and can result in some quite large attacks. I've seen this spilling out into other mailing lists (e.g.: juniper-nap and others). >> >> Please send feedback about links that should be included or documentation and spelling errors to me. >> >> openresolverproject.org >> >> Some basic stats: >> >> 27 million resolvers existed as of this dataset collection >> >> only 2.1 million of them were "closed". >> >> We have a lot to do to close the hosts, please do what you can to help. >> >> Thanks, >> >> - Jared >> >> From mike.simkins at sungard.com Mon Mar 25 14:58:00 2013 From: mike.simkins at sungard.com (Mike Simkins) Date: Mon, 25 Mar 2013 14:58:00 -0000 Subject: Open Resolver Problems In-Reply-To: <51506317.5080409@ip-solutions.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506317.5080409@ip-solutions.net> Message-ID: <4491f656efd43b05a1b496d8766ba547@mail.gmail.com> There are a number of open resolvers that are that way by design (i.e. Google), but most of them are there by misconfiguration, having a small number (say < 100) of well-known open resolvers in the world is not a problem, having > 1 million probably is Mike -----Original Message----- From: Harry Hoffman [mailto:hhoffman at ip-solutions.net] Sent: 25 March 2013 14:46 To: nanog at nanog.org Subject: Re: Open Resolver Problems What are those who provide open resolvers, such as google, doing to combat the problem? It would be nice to be able to provide open resolvers as a service and combat the various threats associated with them. Cheers, Harry On 03/25/2013 10:22 AM, Jared Mauch wrote: > All, > > Open resolvers pose a security threat. I wanted to let everyone know about a search tool that can help you find the ones within your organization. Treat it like a big "BETA" stamp is across it, but please try it out and see if you can close down any hosts within your network. > > This threat is larger than the SMURF amplification attacks in the past and can result in some quite large attacks. I've seen this spilling out into other mailing lists (e.g.: juniper-nap and others). > > Please send feedback about links that should be included or documentation and spelling errors to me. > > openresolverproject.org > > Some basic stats: > > 27 million resolvers existed as of this dataset collection > > only 2.1 million of them were "closed". > > We have a lot to do to close the hosts, please do what you can to help. > > Thanks, > > - Jared > > From Valdis.Kletnieks at vt.edu Mon Mar 25 15:13:03 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Mar 2013 11:13:03 -0400 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: Your message of "Sat, 23 Mar 2013 11:28:07 -0700." References: <20130316212156.GA8034@ismet.erje.net> <5145E22D.20305@gmail.com> <51469FAE.7030102@necom830.hpcl.titech.ac.jp> <20130318052237.C9A3127FD9@drugs.dv.isc.org> <5146AA62.40205@necom830.hpcl.titech.ac.jp> <85BF427B-1182-4795-A485-DBE527280C75@arbor.net> <51472895.8000008@necom830.hpcl.titech.ac.jp> <5147BA2C.9000705@necom830.hpcl.iech.ac.jp> <4E4286DD-92D1-4A50-BC31-4BE166D1BEB2@virtualized.org> <5149A10A.101053@mail.com> <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <8C04311D-EF9! 5! -4C49-97A9-09FE9680F78E@elong.com> <20618.1363992268@turing-police.cc.vt.edu> Message-ID: <11949.1364224383@turing-police.cc.vt.edu> On Sat, 23 Mar 2013 11:28:07 -0700, Owen DeLong said: > A reliable cost-effective means for FTL signaling is a hard problem without > a known solution. Agreed. > An idiot-proof simple BGP configuration is a well known solution. Automating > it would be relatively simple if there were the will to do so. As others pointed out, a reliable cost effective way of automating the layer 8 problems is *also* a hard problem without a known solution. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bicknell at ufp.org Mon Mar 25 15:22:28 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 25 Mar 2013 08:22:28 -0700 Subject: Is multihoming hard? [was: DNS amplification] In-Reply-To: References: <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net> <41EADDFF-7012-45DE-93AC-6B92669E76EC@delong.com> <5149CDE3.2020507@rollernet.us> <7C4289A7-EE35-4411-81DF-A5E3BEE9BC2B@delong.com> Message-ID: <20130325152228.GA88121@ussenterprise.ufp.org> In a message written on Sun, Mar 24, 2013 at 12:54:18PM -0400, John Curran wrote: > I believe that the percentage which _expects_ unabridged connectivity > today is quite high, but that does not necessarily mean actual _demand_ > (i.e. folks who go out and make the necessary arrangements despite the > added cost and hassle...) Actually, I think most of the people who care have made alternate arrangements, but I have to back up first. Like most of the US, I live in a area with a pair of providers, BigCable and BigTelco. The reality of those two providers is that from my house they both run down the same backyard. The both go to pedistals next to each other at the edge of the neighborhood. They both ride the same poles down towards the center of town. At some point they finally diverge, to two different central offices. About 80% of the time when one goes out the other does as well. The backhoe digs up both wires. The pole taken out by a car accident takes them both down. Heck, when the power goes out to a storm neither has a generator for their pedistal. The other 20% of the time one has an equipment failure and the other does not. Even if I wanted to pay 2x the monthly cost to have both providers active (and could multi-home, etc), it really doesn't create a significanlty higher uptime, and thus is economically foolish. However, there is an alternative that shares none of this infrastructure. A cell card. Another option finally available due to higher speeds and better pricing is a satellite service. These provide true redundancy from all the physical infrastructure I described above. It could be aruged then, the interesting multi-homing case is between my Cable Modem and my Cell Card, however even that is not the case. Turns out my cell hard has bad latency compared to the cable modem, so I don't want to use it unless I have to, and it also turns out the cell provider charges me for usage, at a modestly high rate, so I don't want to use it unless I have to. The result is an active/passive backup configuration. A device like a cradlepoint can detect the cable modem being down and switch over to the cell card. Sure, incoming connections are not persisitent, but outbound it's hard to notice other than performance getting worse. TL;DR People paying for redundancy want physical redundancy including the last mile. In the US, that exists approximately nowhere for residential users. With no diverse paths to purchase, the discussion of higher level protocol issues is academic. -- 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 Valdis.Kletnieks at vt.edu Mon Mar 25 15:25:59 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Mar 2013 11:25:59 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Mon, 25 Mar 2013 10:22:08 -0400." <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> Message-ID: <12547.1364225159@turing-police.cc.vt.edu> On Mon, 25 Mar 2013 10:22:08 -0400, Jared Mauch said: > Some basic stats: > > 27 million resolvers existed as of this dataset collection > > only 2.1 million of them were "closed". > > We have a lot to do to close the hosts, please do what you can to help. What's the current BCP on how to deal with mobile devices that hard-code your resolvers in their equivalent of /etc/resolv.conf (often because the owner of the device trusts their emnployers/whatever resolver more than they trust the DNS server that the hotel DHCP pointed them at)? (And yes, I *know* that "point at your employers DNS" works against a threat model of "local provider is an idiot" and fails against "local provider is willing to spoof replies from other DNS servers") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From nick at foobar.org Mon Mar 25 15:38:01 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 25 Mar 2013 15:38:01 +0000 Subject: Open Resolver Problems In-Reply-To: References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> Message-ID: <51506F59.7080101@foobar.org> On 25/03/2013 14:33, Mikael Abrahamsson wrote: > I would like to be able to request an IP list of open resolvers in my ASN, > perhaps sent to the contact details in RIPE whois database to make sure I'm > not falsely representing that ASN. Why would that matter? This is publicly available information. A per-asn query would be very useful. Nick From Valdis.Kletnieks at vt.edu Mon Mar 25 15:44:53 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Mar 2013 11:44:53 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Mon, 25 Mar 2013 15:38:01 -0000." <51506F59.7080101@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> Message-ID: <13438.1364226293@turing-police.cc.vt.edu> On Mon, 25 Mar 2013 15:38:01 -0000, Nick Hilliard said: > On 25/03/2013 14:33, Mikael Abrahamsson wrote: > > I would like to be able to request an IP list of open resolvers in my ASN, > > perhaps sent to the contact details in RIPE whois database to make sure I'm > > not falsely representing that ASN. > > Why would that matter? This is publicly available information. Some of us have both publicly-facing authoritative DNS, and inward facing recursive servers that may be open resolvers but can't be found via NS entries (so the IP addresses of those aren't exactly publicly available info). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mattias at ahnberg.pp.se Mon Mar 25 15:54:21 2013 From: mattias at ahnberg.pp.se (Mattias Ahnberg) Date: Mon, 25 Mar 2013 16:54:21 +0100 Subject: Open Resolver Problems In-Reply-To: <51506F59.7080101@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> Message-ID: <5150732D.3090507@ahnberg.pp.se> On 2013-03-25 16:38, Nick Hilliard wrote: > Why would that matter? This is publicly available information. A list of 27 million open resolvers would be a pretty convenient input for miscreants who want to abuse them, I believe? I assume Jared & co doesn't want their collected work to be abused like that. I quickly scripted a RIPE-based ASN lookup tool for myself just so I could look up my own and customers AS-based IP ranges atleast. Thank you so much for making the site available, Jared. Very helpful! -- /ahnberg. From jared at puck.nether.net Mon Mar 25 15:55:12 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 11:55:12 -0400 Subject: Open Resolver Problems In-Reply-To: <13438.1364226293@turing-police.cc.vt.edu> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> Message-ID: On Mar 25, 2013, at 11:44 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 25 Mar 2013 15:38:01 -0000, Nick Hilliard said: >> On 25/03/2013 14:33, Mikael Abrahamsson wrote: >>> I would like to be able to request an IP list of open resolvers in my ASN, >>> perhaps sent to the contact details in RIPE whois database to make sure I'm >>> not falsely representing that ASN. >> >> Why would that matter? This is publicly available information. > > Some of us have both publicly-facing authoritative DNS, and inward > facing recursive servers that may be open resolvers but can't be > found via NS entries (so the IP addresses of those aren't exactly > publicly available info). Scoping your responses based on query-source should work just fine in this case. There's documentation on how to do that online here: http://www.zytrax.com/books/dns/ch9/close.html I highly recommend doing this with your name server. If you have examples of how to do this you want to share and have me post, as I mentioned, please send me your edits and additions. I want to make this valuable. - Jared From jared at puck.nether.net Mon Mar 25 15:58:06 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 11:58:06 -0400 Subject: Open Resolver Problems In-Reply-To: <5150732D.3090507@ahnberg.pp.se> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> Message-ID: On Mar 25, 2013, at 11:54 AM, Mattias Ahnberg wrote: > On 2013-03-25 16:38, Nick Hilliard wrote: >> Why would that matter? This is publicly available information. > > A list of 27 million open resolvers would be a pretty convenient input for > miscreants who want to abuse them, I believe? I assume Jared & co doesn't > want their collected work to be abused like that. > > I quickly scripted a RIPE-based ASN lookup tool for myself just so I could > look up my own and customers AS-based IP ranges atleast. Thank you so much > for making the site available, Jared. Very helpful! There are other tools, such as the one linked to at the measurement factory that will email the contacts for the objects (e.g.: RIPE/ARIN otherwise). Here's the direct link for those that are interested. As I mentioned, this is alpha/beta quality code, but i feel very confident with the data. - Jared From nick at foobar.org Mon Mar 25 16:14:17 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 25 Mar 2013 16:14:17 +0000 Subject: Open Resolver Problems In-Reply-To: <5150732D.3090507@ahnberg.pp.se> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> Message-ID: <515077D9.9020901@foobar.org> On 25/03/2013 15:54, Mattias Ahnberg wrote: > A list of 27 million open resolvers would be a pretty convenient input for > miscreants who want to abuse them, I believe? I assume Jared & co doesn't > want their collected work to be abused like that. http://nmap.org/nsedoc/scripts/dns-recursion.html http://monkey.org/~provos/dnsscan/ There are 224*2^24 possible unicast hosts, and a whole pile less which are routed on the DFZ. I don't think that we can pretend that it's going to help if we hide this information under a stone and hope that people who are inclined to launch DNS DDoS attacks are dumb enough not to be able to figure out how to use these tools. Highlighting the situation and getting operators to do something will help fix the problem. Nick From ahebert at pubnix.net Mon Mar 25 16:35:22 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 25 Mar 2013 12:35:22 -0400 Subject: Open Resolver Problems In-Reply-To: <515077D9.9020901@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> Message-ID: <51507CCA.60901@pubnix.net> Well, Why would you only go after them? Easier target to mitigate the problem? That might be just me, but I find those peers allowing their customers to spoof source IP addresses more at fault. PS: Some form of adaptive rate limitation works for it btw =D ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/25/13 12:14, Nick Hilliard wrote: > On 25/03/2013 15:54, Mattias Ahnberg wrote: >> A list of 27 million open resolvers would be a pretty convenient input for >> miscreants who want to abuse them, I believe? I assume Jared & co doesn't >> want their collected work to be abused like that. > http://nmap.org/nsedoc/scripts/dns-recursion.html > http://monkey.org/~provos/dnsscan/ > > There are 224*2^24 possible unicast hosts, and a whole pile less which are > routed on the DFZ. > > I don't think that we can pretend that it's going to help if we hide this > information under a stone and hope that people who are inclined to launch > DNS DDoS attacks are dumb enough not to be able to figure out how to use > these tools. > > Highlighting the situation and getting operators to do something will help > fix the problem. > > Nick > > > > From jabley at hopcount.ca Mon Mar 25 16:45:40 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 25 Mar 2013 12:45:40 -0400 Subject: Open Resolver Problems In-Reply-To: <51507CCA.60901@pubnix.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> Message-ID: On 2013-03-25, at 12:35, Alain Hebert wrote: > Well, > > Why would you only go after them? > > Easier target to mitigate the problem? > > That might be just me, but I find those peers allowing their > customers to spoof source IP addresses more at fault. > > PS: Some form of adaptive rate limitation works for it btw =D DNS servers (recursive and authoritative-only) are the low-hanging fruit du jour. I agree that there are many other effective amplifiers, and that even maximum DNS hygiene will not make the wider problem go away. A quick note on your final comment, though: whilst adaptive response rate limiting (so-called RRL) is fast developing into an effective mitigation for reflection attacks against authority-only servers, there is far less experience with traffic patterns or the effects of rate-limiting (using RRL or anything else) on recursive servers. The best advice for operation of recursive servers remains "restrict access to legitimate clients", not "apply rate-limiting". Joe From swmike at swm.pp.se Mon Mar 25 16:46:14 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 25 Mar 2013 17:46:14 +0100 (CET) Subject: Open Resolver Problems In-Reply-To: <51507CCA.60901@pubnix.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> Message-ID: On Mon, 25 Mar 2013, Alain Hebert wrote: > That might be just me, but I find those peers allowing their > customers to spoof source IP addresses more at fault. Yes, I wish every "broadband speed test" could include spoofed IP. Unfortunately I would imagine most OSes won't allow normal users to spoof sender IP so I guess it's hard to recognise. We need a hall of shame for that. -- Mikael Abrahamsson email: swmike at swm.pp.se From dave at temk.in Mon Mar 25 16:47:04 2013 From: dave at temk.in (David Temkin) Date: Mon, 25 Mar 2013 12:47:04 -0400 Subject: NANOG 58 - New Orleans - Call For Presentations is open! In-Reply-To: References: Message-ID: Just a reminder that the RFP is still open for NANOG 58! Regards, -Dave On Fri, Mar 1, 2013 at 12:02 PM, David Temkin wrote: > *Fresh off of a great NANOG 57 in Orlando, your program committee is > already working hard to provide a world-class program for NANOG 58 in NOLA > - New Orleans, Louisiana - one of my favorite destinations in the world.* > * > * > *As a reminder, we will be following the same Monday-Wednesday program > that we started at NANOG 57, with Tutorials beginning Monday morning and > closing with the Peering Track (and potentially a social) on Wednesday > evening. * > * > * > *We look forward to seeing everyone in The Big Easy!* > * > > -------------------- > > The North American Network Operators' Group (NANOG) will hold its 58th > meeting in New Orleans on June 3rd - 5th, 2013 Verizon Terremark will > host NANOG 58. The NANOG Program Committee is now seeking proposals for > presentations, panels, tutorials, tracks sessions, keynote materials, and > the NOGLab experience for the NANOG 58 program. We invite presentations > highlighting issues relating to technology already deployed or soon-to-be > deployed in the Internet. Vendors are encouraged to work with operators to > present real-world deployment experiences with the vendor's products and > interoperability via the program and as part of the NOGLab. NANOG 58 > submissions are welcome at http://pc.nanog.org. > > About NANOG > NANOG is the premier meeting for network operators in North America. > Meetings provide a forum for information exchange among network operators, > engineers, and researchers. NANOG meets three times each year, and includes > panels, presentations, tutorial sessions, tracks, informal BOFs, and a > NOGLab which features interoperability demonstrations. NANOG attendees > include operators from networks of all sizes, enterprise operators, peering > coordinators, transport and switching equipment vendors, and network > researchers. NANOG attendees will share ideas and interact with leaders in > the field of network operations, discuss current operational events and > issues, and learn about state-of-the-art operational techniques. > > Materials from NANOG 58 will be archived at: > http://www.nanog.org/meetings/nanog58/ > > Key Dates for NANOG 58 > > ? CFP Opens for NANOG 58: 25-February-2013 > ? CFP Deadline #1: Presentation Abstracts Due: 8-April-2013 > ? CFP Deadline #2: Presentation Slides Due: 29-April-2013 > ? NANOG Highlights Page Posted: 22-April-2013 > ? Preliminary Topic List Posted: 26-April-2013 > ? Meeting Agenda Published: 13-May-2013 > ? Meeting Agenda Final sent to printer: 20-May-2013 > ? Lightning Talk Submissions Open (Abstracts Only): 2-June-2013 > ? Speaker FINAL presentations to PCTool or speaker-support: 31-May-2013 > ? On-Site Registration: 31-May-2013 > > The NANOG Program Committee seeks proposals for presentations, panels, > tutorial sessions, tracks, and BOFs in all areas of network operations, > including (but not limited to): > > - Power and facilities - Topics may include power reliability and > engineering, green power, power efficiency, cooling, and facilities > management. > - Interconnections - Topics may include IXes, intra-building, MMR, > metro-wide connections, peering, and transit purchasing tactics and > strategies. > - Security - Topics may include routing security, route filtering of > large peers/customers, and inter-AS security and cooperation. > - DNS - Topics may include using DNS data for network metrics, botnet > discovery, and geolocation. > - IPv6 - Topics may include real-world deployment challenges, Carrier > Grade NAT, NAT-PT implementations that work and scale, and allocation > strategies. > - Content - Topics may include Distribution (p2p, IPTV), content > payment models, content distribution technologies and networks, and > storage/archiving. > - Disaster recovery - Topics may include risk analysis, training, > agencies, planning methods, hardware portability, key tools, transport > audits, and other lessons learned. > > In general, presentations are being sought by and for network operators of > all sizes. Presentations about difficult problems (and interesting > solutions) that you encounter in the course of your job are encouraged. > > In addition, the Program Committee, through participation with other > organizations and vendor?s, will be programming a NOGLab experience. The > topic of the NOGLab will be timely and feature real-world experiences faced > by operators of today?s Internet. > > If you think you have an interesting topic but want some feedback or > assistance working it into a presentation, please email the Program > Committee chair (chair at pc.nanog.org), and a representative on the Program > Committee will give you the feedback needed to work it into a presentation. > Otherwise, don't delay in submitting your talk, keynote, track, or panel > into the NANOG Program Committee tool, located at http://pc.nanog.org. > For more information about talk types and format, please see > http://nanog.org/presentations/guidelines/talktips.php > > How to Present > The deadline for accepting abstracts and slides is April 8, 2013 . While > the majority of speaking slots may be filled by that date, a limited number > of slots may be available after that date for topics that are exceptionally > timely, important, or critical to the operations of the Internet. > > Complete Presentation Guidelines can be found at > http://nanog.org/presentations/ > > The primary speaker, moderator, or author should submit presentation > information and an abstract online at: http://pc.nanog.org once you have > done this, you will receive instructions for submitting your draft slides. > > - Author's name(s) > - Preferred contact email address > - A preferred phone number for contact > - Submission category (General Session, Panel, Tutorial, or Research > Forum) > - Presentation title > - Abstract > - Slides (attachment or URL), in PDF (preferred) or PowerPoint format. > > We look forward to reviewing your submission. > > Talks > Keynote Presentation: The Program Committee invites speakers to submit > materials for up to one-hour keynote presentations. Speakers should > indicate that their submission is for a keynote in their abstracts. Speaker > must submit slides for a Keynote Presentation. > > General Session Talk: A General Session presentation should be on a topic > of interest to the general NANOG audience, and may be up to 30-minutes long > (including time for Q&A). Speakers must submit slides for a General Session > presentation. > > General Session Panel: Panels are 60-90-minute discussion sessions > between a moderator and a team of panelists. The panel moderator should > submit an abstract on the panel topic, a list of panelists, and how the > panel will be organized. Panel selection will be based on the importance, > originality, focus and timeliness of the topic, expertise of proposed > panelists, as well as the potential for informative and controversial > discussion. After acceptance the panel leader will be given the option to > invite panel authors to submit their presentations to the NANOG program > Committee for review. Until then authors should not submit their individual > presentations for the panel. > > Tracks: Tracks are 90-minute informal agenda blocks on topics, which are > of interest to a portion of the NANOG community. The 90-minute block can be > subdivided into a number of smaller, highly related presentations, panels > or open discussion. A moderator coordinates content within the 90-minute > block of time, and must submit a detailed outline to the Program Committee, > including sub-topics and presenters > Peering > ISP Security > Tools > Typically two tracks or three tracks will be run concurrently. > > Tutorials: Tutorials are 90-minute sessions. A presentation from the > introductory through advanced level on all related topics, including: > Disaster Recovery Planning > Troubleshooting BGP > Best Practices for Determining Traffic Matrices > Options for Blackhole and Discard Routing > BGP/MPLS Layer 3 VPNs > Peering business and engineering basics > A tutorial submission should include an abstract and slides. > > BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics, > which are of interest to a portion of the NANOG community. BOFs may be held > in the hallways, breakout areas or in an unscheduled tutorial room. > Requests for scheduled BOFs will be take place on site at the meeting. > > A typical BOF session may include some structure or presentations, but > usually is focused on community discussion and interaction. > > Frequent BOF topics include: > R&D collaboration > Hot-topics in the media > The less structured nature of BOF sessions allows for the greatest > flexibility from a timing perspective. > > Lightning Talks: A lightning talk is a very short presentation or speech > by any attendee on any topic relevant to the NANOG audience. These are > limited to ten minutes; this will be strictly enforced. > > If you have a topic that's timely, interesting, or even a crackpot idea > you want to share, we encourage you to consider presenting it. The Program > Committee will vote on all Lightning Talk submissions onsite at the > meeting, and a submitter will be notified about his or her submission one > day prior to the scheduled talk time. > > Submit your lightning talk proposal at http://pc.nanog.org starting June > 2, 2013. > > Research Forum: Researchers are invited to present short (10-minute) > summaries of their work for operator feedback. Topics include routing, > network performance, statistical measurement and analysis, and protocol > development and implementation. Studies presented may be works in progress. > Researchers from academia, government, and industry are encouraged to > present. > > The NANOG registration fee is waived for: > > - For General Session presentations, the registration fee will be > waived for a maximum of one speaker. > - For General Session panels, fees will be waived for one panel > moderator and all panelists. > - For Tracks, fees will be waived for one moderator. > - For Research Forum presentations, fees will be waived for one > speaker. > - For Tutorials, fees will be waived for one instructor. > > * From nick at foobar.org Mon Mar 25 16:51:44 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 25 Mar 2013 16:51:44 +0000 Subject: Open Resolver Problems In-Reply-To: <51507CCA.60901@pubnix.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> Message-ID: <515080A0.8030203@foobar.org> On 25/03/2013 16:35, Alain Hebert wrote: > That might be just me, but I find those peers allowing their > customers to spoof source IP addresses more at fault. that is equally stupid and bad. > PS: Some form of adaptive rate limitation works for it btw =D no, it doesn't. In order to ensure that your resolver clients are serviced properly, you need to keep the DNS query rate high enough that if someone has a large bcp38-enabled botnet, they can trash the hell out of whoever they want. The best solution is to disable open recursion completely, and police your clients regularly. Nick From ahebert at pubnix.net Mon Mar 25 17:34:26 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 25 Mar 2013 13:34:26 -0400 Subject: Open Resolver Problems In-Reply-To: <515080A0.8030203@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> <515080A0.8030203@foobar.org> Message-ID: <51508AA2.5070705@pubnix.net> Hi, Well... On 03/25/13 12:51, Nick Hilliard wrote: > On 25/03/2013 16:35, Alain Hebert wrote: >> That might be just me, but I find those peers allowing their >> customers to spoof source IP addresses more at fault. > that is equally stupid and bad. In my eyes, those peers are the source of it. One can justify Open Relay and the lag into moving into not being an attack vector... while the case for allowing IP spoofing is a tad harder to justify. > >> PS: Some form of adaptive rate limitation works for it btw =D > no, it doesn't. In order to ensure that your resolver clients are serviced > properly, you need to keep the DNS query rate high enough that if someone > has a large bcp38-enabled botnet, they can trash the hell out of whoever > they want. We all need to be more flexible and actually work toward fixing both end of the issue. > > The best solution is to disable open recursion completely, and police your > clients regularly. > > Nick I just intervene on one of today's DNS Amp... which is going to many targets mind you... on a client with a NT4.0 Server and another with FreeBSD 5.1 =D ( You can say bye bye to that NT4.0 client revenue :( ) Now about some of "those" peers start enforcing some form of source IP rules... PS: The Open Relay situation is easy to fix for a subscriber type corp (like say a Cable provider)... and less for smaller outfit providing all sort of IT services. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From bill at herrin.us Mon Mar 25 17:51:44 2013 From: bill at herrin.us (William Herrin) Date: Mon, 25 Mar 2013 13:51:44 -0400 Subject: Open Resolver Problems In-Reply-To: <515080A0.8030203@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> <515080A0.8030203@foobar.org> Message-ID: On Mon, Mar 25, 2013 at 12:51 PM, Nick Hilliard wrote: > On 25/03/2013 16:35, Alain Hebert wrote: >> That might be just me, but I find those peers allowing their >> customers to spoof source IP addresses more at fault. > > that is equally stupid and bad. Nothing equal about it. Open resolvers (and other forms of amplification attacks like the basic smurf) are a problem if and only if a target's source IP address can be spoofed. Service providers intentionally or negligently permitting their users to spoof source addresses outside that ISP's domain are the *root cause* of the problem. Even if you close all the open resolvers, most authoritative responses are larger than the queries. At best you've shrunk the amplification factor. What will you do next? Insist that everybody host their DNS somewhere sophisticated rather than running their own server? Hassling the folks who run open resolvers further victimizes the innocent. If you want to solve the problem, start by cleaning up your border so that only locally valid sources can exit. Next, identify peers who fail to demonstrate adequate control over their sources. Finally, set filters on those peers so that sources inconsistent with the received routes are dropped. They won't like it. They'll find it inconvenient, even disruptive to their traffic engineering efforts. But at some point, TE has to take a back seat to closing network abuse issues. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Mon Mar 25 18:04:37 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Mar 2013 14:04:37 -0400 (EDT) Subject: Open Resolver Problems In-Reply-To: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> Message-ID: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > Open resolvers pose a security threat. Could you clarify, here, Jared? Do "open DNS customer-resolver/recursive servers" *per se* cause a problem? Or is it merely "customer zone servers which are misconfigured to recurse", as has always been problematic? That is: is this just a reminder we never closed the old hole, or notification of some new and much nastier hole? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From nick at foobar.org Mon Mar 25 18:09:15 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 25 Mar 2013 18:09:15 +0000 Subject: Open Resolver Problems In-Reply-To: References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> <515080A0.8030203@foobar.org> Message-ID: <515092CB.1020609@foobar.org> On 25/03/2013 17:51, William Herrin wrote: > Hassling the folks who run open resolvers further victimizes the > innocent. running open resolvers will continue to be a major problem as a DDoS platform on the Internet until everyone implements BCP38. When everyone has implemented ingress filtering, we can have a beer and agree that running open resolvers is less harmful. Until then, though, they're a menace. Nick From bill at herrin.us Mon Mar 25 19:21:55 2013 From: bill at herrin.us (William Herrin) Date: Mon, 25 Mar 2013 15:21:55 -0400 Subject: Open Resolver Problems In-Reply-To: <515092CB.1020609@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> <515080A0.8030203@foobar.org> <515092CB.1020609@foobar.org> Message-ID: On Mon, Mar 25, 2013 at 2:09 PM, Nick Hilliard wrote: > On 25/03/2013 17:51, William Herrin wrote: >> Hassling the folks who run open resolvers further victimizes the >> innocent. > > running open resolvers will continue to be a major problem as a DDoS > platform on the Internet until everyone implements BCP38. When everyone > has implemented ingress filtering, we can have a beer and agree that > running open resolvers is less harmful. Until then, though, they're a menace. Nick, Running [unauthenticated UDP-based service du jour] will continue to be a major problem as a DDoS platform on the Internet until everyone implements BCP38. That [unauthenticated UDP-based service du jour] should thus be disallowed is an untenable position. We depend on [unauthenticated UDP-based service du jour] for the correct operation of the Internet, including such examples as authoritative DNS servers. We've been down this path before where we try to tighten the belt on everything we don't absolutely critically need for the sake of allowing the root problem to keep eking by. It ain't pretty and ultimately it isn't successful either: we merely create an arms race where the bad actors converge on the services we -can't- shut down. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Mon Mar 25 20:36:48 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 16:36:48 -0400 Subject: Open Resolver Problems In-Reply-To: <51507CCA.60901@pubnix.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> Message-ID: <7BE8BE72-83B4-4C96-962D-D905D09179BD@puck.nether.net> On Mar 25, 2013, at 12:35 PM, Alain Hebert wrote: > Well, > > Why would you only go after them? > > Easier target to mitigate the problem? > > That might be just me, but I find those peers allowing their > customers to spoof source IP addresses more at fault. > > PS: Some form of adaptive rate limitation works for it btw =D Folks should be deploying unicast-rpf facing their statically routed infrastructure. This includes server lans, PPPoE Pools, etc. Place the filtering at the edge where feasible. This would also include things like your firewall and other devices that shouldn't leak/emit spoofed packets. If you don't know how to do this, or check on it, please ask around, either here or on cisco-nsp or juniper-nap for your platforms. - Jared From linux.yahoo at gmail.com Mon Mar 25 20:42:06 2013 From: linux.yahoo at gmail.com (Manu Chao) Date: Mon, 25 Mar 2013 21:42:06 +0100 Subject: Fake or Real Google servers from China Hong Kong (116.92.194.14x)? Message-ID: Could someone confirm me following IP are legitimated from Google China (HK) or not (fake=dangerous) ??? 116.92.194.140 116.92.194.141 116.92.194.142 116.92.194.143 No DNS resolution from Google DNS, i am suspicious... Any help appreciate From jared at puck.nether.net Mon Mar 25 20:45:59 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 16:45:59 -0400 Subject: Open Resolver Problems In-Reply-To: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> Message-ID: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> On Mar 25, 2013, at 2:04 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jared Mauch" > >> Open resolvers pose a security threat. > > Could you clarify, here, Jared? > > Do "open DNS customer-resolver/recursive servers" *per se* cause a problem? > > Or is it merely "customer zone servers which are misconfigured to recurse", > as has always been problematic? > > That is: is this just a reminder we never closed the old hole, or > notification of some new and much nastier hole? There have been some moderate size attacks recently that I won't go into detail here about. The IPs that are on the website are certainly being used/abused. A recent attack saw a 90% match rate against the "master list" here. This means your open resolver is likely being used. Anything to raise the bar here will minimize the impact to those networks under attack. Turn on RPF facing your colocation and high-speed server lans. We all know hosts become compromised. Help minimize the impact of these attacks by a) doing BCP-38 b) locking down your recursive servers to networks you control c) locking down your authority servers to not provide the same answer 15x in a second to the same querying IP. If it's asking that same question 15x, then it's not you that's broken, it's that client. (Or it's being abused). - Jared From mansaxel at besserwisser.org Mon Mar 25 20:51:06 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 25 Mar 2013 21:51:06 +0100 Subject: Open Resolver Problems In-Reply-To: References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> Message-ID: <20130325205106.GA9242@besserwisser.org> Subject: Re: Open Resolver Problems Date: Mon, Mar 25, 2013 at 12:45:40PM -0400 Quoting Joe Abley (jabley at hopcount.ca): > > DNS servers (recursive and authoritative-only) are the low-hanging fruit du jour. I agree that there are many other effective amplifiers, and that even maximum DNS hygiene will not make the wider problem go away. > > A quick note on your final comment, though: whilst adaptive response rate limiting (so-called RRL) is fast developing into an effective mitigation for reflection attacks against authority-only servers, there is far less experience with traffic patterns or the effects of rate-limiting (using RRL or anything else) on recursive servers. > > The best advice for operation of recursive servers remains "restrict access to legitimate clients", not "apply rate-limiting". Twice agree. I try to have ::1 as resolver on my server machines that are in a position to be used, and only accept queries on ::1. Takes care of access control nicely. For auth servers, those serving DNSSEC records are especially attractive as amplifiers. At the moment, I'd have a hard time defending unrestricted query rates on auth servers if they serve DNSSEC. I've successfully applied the Redbarn patches to my BIND, and I expect the NSD rate-control to be of similar quality, or better. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 BELA LUGOSI is my co-pilot ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jabley at hopcount.ca Mon Mar 25 20:59:25 2013 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 25 Mar 2013 16:59:25 -0400 Subject: Open Resolver Problems In-Reply-To: <20130325205106.GA9242@besserwisser.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> <20130325205106.GA9242@besserwisser.org> Message-ID: <28EB4798-5D1D-45FE-8228-E9C7068CB44F@hopcount.ca> On 2013-03-25, at 16:51, M?ns Nilsson wrote: > I've successfully applied the Redbarn patches to my BIND, and I expect > the NSD rate-control to be of similar quality, or better. We've formed the opinion at ICANN that the observed reaction to reflection attacks by BIND9 + Schryver/Vixie RRL is definitely different from NSD + NSD-RRL, but we don't yet know whether either one is better. Dave Knight is busy building a test lab at DNS-OARC so he can replay identical attack traffic against BIND9, NSD and knot with equivalent RRL configurations to observe their behaviour. The source data he's using initially is from a reflection attack against L-Root that landed in Hamburg; if others here have full pcaps of similar events and are interested in comparing the reactions to it from those three nameservers, let me know and I can put you in touch. Dave plans to talk about his methodology and findings at the DNS-OARC workshop in Dublin in May (assuming his presentation proposal is accepted). (The DNS-OARC workshop is cojoined with the RIPE meeting, for those who are DNS-curious and haven't already considered a couple of extra days of DNS fun alongside the RIPE meeting they were already planning to attend.) Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shortdudey123 at gmail.com Mon Mar 25 20:59:36 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Mon, 25 Mar 2013 15:59:36 -0500 Subject: Fake or Real Google servers from China Hong Kong (116.92.194.14x)? In-Reply-To: References: Message-ID: Whois record isn't Google. inetnum: 116.92.0.0 - 116.92.255.255 descr: This field was added to fix syntax error netname: PACNET remarks: Spam and Security: abuse at pacnet.com remarks: Network Issues : rnoc at pacnet.com country: HK admin-c: PNH4-AP tech-c: PNH4-AP mnt-by: APNIC-HM mnt-lower: MAINT-AP-PACNET mnt-lower: MAINT-AP-PACNET-NOC changed: rnoc at pacnet.com status: ALLOCATED PORTABLE changed: hm-changed at apnic.net 20080604 source: APNIC role: PACNET NIC Handler address: PACNET country: HK phone: +65-6872-1010 e-mail: rnoc at pacnet.com remarks: ------------------------------------- remarks: Spam and Security: abuse at pacnet.com remarks: Network Issues : rnoc at pacnet.com remarks: ------------------------------------- admin-c: PR132-AP admin-c: AN155-AP tech-c: PR132-AP tech-c: AN155-AP nic-hdl: PNH4-AP remarks: http://www.pacnet.com notify: rnoc at pacnet.com mnt-by: MAINT-AP-PACNET changed: rnoc at pacnet.com 20090911 source: APNIC changed: hm-changed at apnic.net 20111114 On Mon, Mar 25, 2013 at 3:42 PM, Manu Chao wrote: > Could someone confirm me following IP are legitimated from Google China > (HK) or not (fake=dangerous) ??? > > 116.92.194.140 > 116.92.194.141 > 116.92.194.142 > 116.92.194.143 > > No DNS resolution from Google DNS, i am suspicious... > > Any help appreciate > From ctassisf at gmail.com Mon Mar 25 21:08:58 2013 From: ctassisf at gmail.com (=?ISO-8859-1?Q?C=E9sar_de_Tassis_Filho?=) Date: Mon, 25 Mar 2013 18:08:58 -0300 Subject: Fake or Real Google servers from China Hong Kong (116.92.194.14x)? In-Reply-To: References: Message-ID: Not sure, but it looks like some Google Global Cache inside an ISP. C?sar On Mon, Mar 25, 2013 at 5:59 PM, Grant Ridder wrote: > Whois record isn't Google. > > > inetnum: 116.92.0.0 - 116.92.255.255 > descr: This field was added to fix syntax error > netname: PACNET > remarks: Spam and Security: abuse at pacnet.com > remarks: Network Issues : rnoc at pacnet.com > country: HK > admin-c: PNH4-AP > tech-c: PNH4-AP > mnt-by: APNIC-HM > mnt-lower: MAINT-AP-PACNET > mnt-lower: MAINT-AP-PACNET-NOC > changed: rnoc at pacnet.com > status: ALLOCATED PORTABLE > changed: hm-changed at apnic.net 20080604 > source: APNIC > > role: PACNET NIC Handler > address: PACNET > country: HK > phone: +65-6872-1010 > e-mail: rnoc at pacnet.com > remarks: ------------------------------------- > remarks: Spam and Security: abuse at pacnet.com > remarks: Network Issues : rnoc at pacnet.com > remarks: ------------------------------------- > admin-c: PR132-AP > admin-c: AN155-AP > tech-c: PR132-AP > tech-c: AN155-AP > nic-hdl: PNH4-AP > remarks: http://www.pacnet.com > notify: rnoc at pacnet.com > mnt-by: MAINT-AP-PACNET > changed: rnoc at pacnet.com 20090911 > source: APNIC > changed: hm-changed at apnic.net 20111114 > > On Mon, Mar 25, 2013 at 3:42 PM, Manu Chao wrote: > > > Could someone confirm me following IP are legitimated from Google China > > (HK) or not (fake=dangerous) ??? > > > > 116.92.194.140 > > 116.92.194.141 > > 116.92.194.142 > > 116.92.194.143 > > > > No DNS resolution from Google DNS, i am suspicious... > > > > Any help appreciate > > > From ahebert at pubnix.net Mon Mar 25 21:15:16 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 25 Mar 2013 17:15:16 -0400 Subject: Open Resolver Problems In-Reply-To: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> Message-ID: <5150BE64.2020907@pubnix.net> Well, On 03/25/13 16:45, Jared Mauch wrote: > On Mar 25, 2013, at 2:04 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Jared Mauch" >>> Open resolvers pose a security threat. >> Could you clarify, here, Jared? >> >> Do "open DNS customer-resolver/recursive servers" *per se* cause a problem? >> >> Or is it merely "customer zone servers which are misconfigured to recurse", >> as has always been problematic? >> >> That is: is this just a reminder we never closed the old hole, or >> notification of some new and much nastier hole? > There have been some moderate size attacks recently that I won't go into detail here about. The IPs that are on the website are certainly being used/abused. A recent attack saw a 90% match rate against the "master list" here. This means your open resolver is likely being used. > > Anything to raise the bar here will minimize the impact to those networks under attack. Turn on RPF facing your colocation and high-speed server lans. We all know hosts become compromised. Help minimize the impact of these attacks by > > a) doing BCP-38 > b) locking down your recursive servers to networks you control > c) locking down your authority servers to not provide the same answer 15x in a second to the same querying IP. If it's asking that same question 15x, then it's not you that's broken, it's that client. (Or it's being abused). > > - Jared I think most of the audience here knows and are sensitive about it. The problems come from from those who don't give a *shit*... And they've been not giving a *shit* it for years. The magic is in "how" to make them care. Do the industry need to go "a la PCI-DSS" for Peers? PS: My pico ISP is soooo on your list Jared =D Not for long hopefully. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From tom at cloudflare.com Mon Mar 25 21:16:20 2013 From: tom at cloudflare.com (Tom Paseka) Date: Mon, 25 Mar 2013 14:16:20 -0700 Subject: Fake or Real Google servers from China Hong Kong (116.92.194.14x)? In-Reply-To: References: Message-ID: Looks like google cache. On Mon, Mar 25, 2013 at 2:08 PM, C?sar de Tassis Filho wrote: > Not sure, but it looks like some Google Global Cache inside an ISP. > > C?sar > > > On Mon, Mar 25, 2013 at 5:59 PM, Grant Ridder >wrote: > > > Whois record isn't Google. > > > > > > inetnum: 116.92.0.0 - 116.92.255.255 > > descr: This field was added to fix syntax error > > netname: PACNET > > remarks: Spam and Security: abuse at pacnet.com > > remarks: Network Issues : rnoc at pacnet.com > > country: HK > > admin-c: PNH4-AP > > tech-c: PNH4-AP > > mnt-by: APNIC-HM > > mnt-lower: MAINT-AP-PACNET > > mnt-lower: MAINT-AP-PACNET-NOC > > changed: rnoc at pacnet.com > > status: ALLOCATED PORTABLE > > changed: hm-changed at apnic.net 20080604 > > source: APNIC > > > > role: PACNET NIC Handler > > address: PACNET > > country: HK > > phone: +65-6872-1010 > > e-mail: rnoc at pacnet.com > > remarks: ------------------------------------- > > remarks: Spam and Security: abuse at pacnet.com > > remarks: Network Issues : rnoc at pacnet.com > > remarks: ------------------------------------- > > admin-c: PR132-AP > > admin-c: AN155-AP > > tech-c: PR132-AP > > tech-c: AN155-AP > > nic-hdl: PNH4-AP > > remarks: http://www.pacnet.com > > notify: rnoc at pacnet.com > > mnt-by: MAINT-AP-PACNET > > changed: rnoc at pacnet.com 20090911 > > source: APNIC > > changed: hm-changed at apnic.net 20111114 > > > > On Mon, Mar 25, 2013 at 3:42 PM, Manu Chao > wrote: > > > > > Could someone confirm me following IP are legitimated from Google China > > > (HK) or not (fake=dangerous) ??? > > > > > > 116.92.194.140 > > > 116.92.194.141 > > > 116.92.194.142 > > > 116.92.194.143 > > > > > > No DNS resolution from Google DNS, i am suspicious... > > > > > > Any help appreciate > > > > > > From marka at isc.org Mon Mar 25 22:03:59 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 26 Mar 2013 09:03:59 +1100 Subject: Open Resolver Problems In-Reply-To: Your message of "Mon, 25 Mar 2013 17:15:16 EDT." <5150BE64.2020907@pubnix.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <5150BE64.2020907@pubnix.net> Message-ID: <20130325220359.D38D43184AF8@drugs.dv.isc.org> In message <5150BE64.2020907 at pubnix.net>, Alain Hebert writes: > Well, > > On 03/25/13 16:45, Jared Mauch wrote: > > On Mar 25, 2013, at 2:04 PM, Jay Ashworth wrote: > > > >> ----- Original Message ----- > >>> From: "Jared Mauch" > >>> Open resolvers pose a security threat. > >> Could you clarify, here, Jared? > >> > >> Do "open DNS customer-resolver/recursive servers" *per se* cause a problem? > >> > >> Or is it merely "customer zone servers which are misconfigured to recurse", > >> as has always been problematic? > >> > >> That is: is this just a reminder we never closed the old hole, or > >> notification of some new and much nastier hole? > > There have been some moderate size attacks recently that I won't go into detail here about. The IPs that a > re on the website are certainly being used/abused. A recent attack saw a 90% match rate against the "master > list" here. This means your open resolver is likely being used. > > > > Anything to raise the bar here will minimize the impact to those networks under attack. Turn on RPF facing > your colocation and high-speed server lans. We all know hosts become compromised. Help minimize the impact > of these attacks by > > > > a) doing BCP-38 > > b) locking down your recursive servers to networks you control > > c) locking down your authority servers to not provide the same answer 15x in a second to the same querying > IP. If it's asking that same question 15x, then it's not you that's broken, it's that client. (Or it's bein > g abused). > > > > - Jared > > I think most of the audience here knows and are sensitive about it. > > The problems come from from those who don't give a *shit*... And > they've been not giving a *shit* it for years. > > The magic is in "how" to make them care. There is only one way sure way to make them care which is to cut them off for a period and repeat the punishment if they fail to clean up their act. You give them notice. You publicise that you are going to do it unless they address their issue by date X. On date X you stop accepting routes through them or to them unless they have cleaned up their act. At the end of the period you start accepting traffic again. You leave the open recursive servers open. They are your canaries. BCP 38 was published in May 2000. There is no excuse for any ISP to not have the requisite equipement to do this. > Do the industry need to go "a la PCI-DSS" for Peers? > > PS: My pico ISP is soooo on your list Jared =D Not for long hopefully. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From damian at google.com Mon Mar 25 23:10:53 2013 From: damian at google.com (Damian Menscher) Date: Mon, 25 Mar 2013 16:10:53 -0700 Subject: Fake or Real Google servers from China Hong Kong (116.92.194.14x)? In-Reply-To: References: Message-ID: These are legitimate. Damian Google Security Team On Mon, Mar 25, 2013 at 1:42 PM, Manu Chao wrote: > Could someone confirm me following IP are legitimated from Google China > (HK) or not (fake=dangerous) ??? > > 116.92.194.140 > 116.92.194.141 > 116.92.194.142 > 116.92.194.143 > > No DNS resolution from Google DNS, i am suspicious... > > Any help appreciate > From damian at google.com Mon Mar 25 23:27:33 2013 From: damian at google.com (Damian Menscher) Date: Mon, 25 Mar 2013 16:27:33 -0700 Subject: Open Resolver Problems In-Reply-To: <51506317.5080409@ip-solutions.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506317.5080409@ip-solutions.net> Message-ID: On Mon, Mar 25, 2013 at 7:45 AM, Harry Hoffman wrote: > What are those who provide open resolvers, such as google, doing to > combat the problem? > https://developers.google.com/speed/public-dns/docs/security#rate_limit Damian From jared at puck.nether.net Tue Mar 26 01:13:27 2013 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 25 Mar 2013 21:13:27 -0400 Subject: Open Resolver Problems In-Reply-To: <5150BE64.2020907@pubnix.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <5150BE64.2020907@pubnix.net> Message-ID: <3023200B-48CC-4F9B-B5CE-B4C937AB19C6@puck.nether.net> On Mar 25, 2013, at 5:15 PM, Alain Hebert wrote: > Well, > > On 03/25/13 16:45, Jared Mauch wrote: >> On Mar 25, 2013, at 2:04 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Jared Mauch" >>>> Open resolvers pose a security threat. >>> Could you clarify, here, Jared? >>> >>> Do "open DNS customer-resolver/recursive servers" *per se* cause a problem? >>> >>> Or is it merely "customer zone servers which are misconfigured to recurse", >>> as has always been problematic? >>> >>> That is: is this just a reminder we never closed the old hole, or >>> notification of some new and much nastier hole? >> There have been some moderate size attacks recently that I won't go into detail here about. The IPs that are on the website are certainly being used/abused. A recent attack saw a 90% match rate against the "master list" here. This means your open resolver is likely being used. >> >> Anything to raise the bar here will minimize the impact to those networks under attack. Turn on RPF facing your colocation and high-speed server lans. We all know hosts become compromised. Help minimize the impact of these attacks by >> >> a) doing BCP-38 >> b) locking down your recursive servers to networks you control >> c) locking down your authority servers to not provide the same answer 15x in a second to the same querying IP. If it's asking that same question 15x, then it's not you that's broken, it's that client. (Or it's being abused). >> >> - Jared > > I think most of the audience here knows and are sensitive about it. > > The problems come from from those who don't give a *shit*... And > they've been not giving a *shit* it for years. > > The magic is in "how" to make them care If this started to move into an AUP violation direction (e.g.: ala spammers, etc) would that motivate people? > Do the industry need to go "a la PCI-DSS" for Peers? I think that any effort we can take here to help educate people to the right standards is helpful. I'd like to see people fix hosts, routers and a number of other things. > PS: My pico ISP is soooo on your list Jared =D Not for long hopefully. Appreciated. And many thanks for others that have emailed me saying their hosts have been fixed as well, and those that have emailed me updated text for the webpage. - jared From morrowc.lists at gmail.com Tue Mar 26 03:19:31 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 25 Mar 2013 23:19:31 -0400 Subject: Open Resolver Problems In-Reply-To: <13438.1364226293@turing-police.cc.vt.edu> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> Message-ID: On Mon, Mar 25, 2013 at 11:44 AM, wrote: > On Mon, 25 Mar 2013 15:38:01 -0000, Nick Hilliard said: >> On 25/03/2013 14:33, Mikael Abrahamsson wrote: >> > I would like to be able to request an IP list of open resolvers in my ASN, >> > perhaps sent to the contact details in RIPE whois database to make sure I'm >> > not falsely representing that ASN. >> >> Why would that matter? This is publicly available information. > > Some of us have both publicly-facing authoritative DNS, and inward > facing recursive servers that may be open resolvers but can't be > found via NS entries (so the IP addresses of those aren't exactly > publicly available info). 'virginia tech dns configuration' into the webcrawler and: https://computing.vt.edu/content/dns-addresses also: ; <<>> DiG 9.7.0-P1 <<>> @198.82.247.34 www.google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29982 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 31 IN A 74.125.228.51 ...snip... -chris From Valdis.Kletnieks at vt.edu Tue Mar 26 07:51:30 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 03:51:30 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Mon, 25 Mar 2013 23:19:31 -0400." References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> Message-ID: <24221.1364284290@turing-police.cc.vt.edu> On Mon, 25 Mar 2013 23:19:31 -0400, Christopher Morrow said: > > Some of us have both publicly-facing authoritative DNS, and inward > > facing recursive servers that may be open resolvers but can't be > > found via NS entries (so the IP addresses of those aren't exactly > > publicly available info). > > 'virginia tech dns configuration' into the webcrawler and: > https://computing.vt.edu/content/dns-addresses Just proving my point - you didn't find the webpage that also lists their IPv6 addresses. :) Now explain how you find a recursive nameserver that isn't listed in an NS entry and *hasn't* been publicized someplace that Google can find it. > also > ; <<>> DiG 9.7.0-P1 <<>> @198.82.247.34 www.google.com That might, must *might* mind you, be somewhat tangentially related to why I asked Jared what the BCP is for dealing with mobile devices with hardcoded DNS lists. :) (Otherwise read as "we'll be glad to fix it if somebody has a brilliant idea on how to do so without generating more calls to the help desk than the near-zero rate we currently get about DNS amplification issues"....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From nick at foobar.org Tue Mar 26 08:13:49 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Mar 2013 08:13:49 +0000 Subject: Open Resolver Problems In-Reply-To: <24221.1364284290@turing-police.cc.vt.edu> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> Message-ID: <515158BD.4070906@foobar.org> On 26/03/2013 07:51, Valdis.Kletnieks at vt.edu wrote: > Now explain how you find a recursive nameserver that isn't listed in an NS > entry and *hasn't* been publicized someplace that Google can find it. Um, you run one of e.g.: http://nmap.org/nsedoc/scripts/dns-recursion.html http://monkey.org/~provos/dnsscan/ Then wait for a while while it churns through the ~224*2^24 packets it needs to scan the entire ipv4 internet. Of course, you could write your own code, but that would take at least 1/2 an hour. Then you have every open resolver on the internet. Now, can you tell me how this is beyond the computing skill of someone who controls a bigass botnet? > (Otherwise read as "we'll be glad to fix it if somebody has a brilliant > idea on how to do so without generating more calls to the help desk than > the near-zero rate we currently get about DNS amplification issues"....) The whole point of this thread is that dns amplification hurts other people, not the resolver which is being abused. Just like in the old days, abusing open mail relays hurt other people more than the relay operator. Nick From rdobbins at arbor.net Tue Mar 26 10:27:27 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 26 Mar 2013 10:27:27 +0000 Subject: Open Resolver Problems In-Reply-To: <515158BD.4070906@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> Message-ID: On Mar 26, 2013, at 3:13 PM, Nick Hilliard wrote: > The whole point of this thread is that dns amplification hurts other people, not the resolver which is being abused. Actually, it often hurts the resolver(s) being abused, as well, leading to availability problems for those who legitimately need the recursive service in question. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From patrick at ianai.net Tue Mar 26 10:48:27 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 26 Mar 2013 18:48:27 +0800 Subject: Open Resolver Problems In-Reply-To: References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> Message-ID: <2BE85FDD-4582-4607-8524-6BF9923F96C8@ianai.net> Composed on a virtual keyboard, please forgive typos. On Mar 26, 2013, at 18:27, "Dobbins, Roland" wrote: > On Mar 26, 2013, at 3:13 PM, Nick Hilliard wrote: > >> The whole point of this thread is that dns amplification hurts other people, not the resolver which is being abused. > > Actually, it often hurts the resolver(s) being abused, as well, leading to availability problems for those who legitimately need the recursive service in question. On more than one occasion, the operator of an open resolver being used to amplify an attack at our network has called / emailed asking us to stop abusing them. It seems the query rate "we" were sending them was crippling their servers. Sometimes they threaten to filter us. How thoughtful of them! Reminds me of: "Yer h4x0ring me on port 80!!1!1!!1" -- TTFN, patrick From jamie at photon.com Tue Mar 26 11:50:52 2013 From: jamie at photon.com (Jamie Bowden) Date: Tue, 26 Mar 2013 11:50:52 +0000 Subject: Open Resolver Problems In-Reply-To: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> Message-ID: <465966A5F5B867419F604CD3E604C1E53B089470@PRA-DCA-MAIL.pra.ray.com> > From: Jared Mauch [mailto:jared at puck.nether.net] > On Mar 25, 2013, at 2:04 PM, Jay Ashworth wrote: > > ----- Original Message ----- > >> From: "Jared Mauch" > > > >> Open resolvers pose a security threat. > > > > Could you clarify, here, Jared? > > > > Do "open DNS customer-resolver/recursive servers" *per se* cause a > problem? > > > > Or is it merely "customer zone servers which are misconfigured to recurse", > > as has always been problematic? > > > > That is: is this just a reminder we never closed the old hole, or > > notification of some new and much nastier hole? > > There have been some moderate size attacks recently that I won't go into > detail here about. The IPs that are on the website are certainly being > used/abused. A recent attack saw a 90% match rate against the "master list" > here. This means your open resolver is likely being used. I'm just going to jump in here and ask what is probably a silly question, but let's suppose I just happen to have, or have access to, a botnet comprised of (tens of) millions of random hosts all over the internet, and I feel like destroying your DNS servers via DDoS; what's stopping me from just directly querying your servers continuously from said botnet until you melt? Those machines send you traffic indirectly through open resolvers, or hit you directly, but either way, it's the same number of machines issuing the same number of queries, and you're no less inundated. If your own servers rate limit to protect themselves, you're losing valid traffic, and if they don't, once you melt down, you're losing valid traffic... Jamie From swmike at swm.pp.se Tue Mar 26 11:54:40 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Mar 2013 12:54:40 +0100 (CET) Subject: Open Resolver Problems In-Reply-To: <515080A0.8030203@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <5150732D.3090507@ahnberg.pp.se> <515077D9.9020901@foobar.org> <51507CCA.60901@pubnix.net> <515080A0.8030203@foobar.org> Message-ID: On Mon, 25 Mar 2013, Nick Hilliard wrote: > The best solution is to disable open recursion completely, and police > your clients regularly. Is there an officially sounding document with "open resolver considered harmful" or alike? It's not trivial to deal with a corporate client with an open resolver. You can't really shut them off, can't filter them etc. Googling for yields nothing I can point customers to. is the closest I can find? -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Tue Mar 26 12:01:32 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 26 Mar 2013 12:01:32 +0000 Subject: Open Resolver Problems In-Reply-To: <465966A5F5B867419F604CD3E604C1E53B089470@PRA-DCA-MAIL.pra.ray.com> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <465966A5F5B867419F604CD3E604C1E53B089470@PRA-DCA-MAIL.pra.ray.com> Message-ID: <572FDFDB-A053-4451-AA50-79D5F8F8109D@arbor.net> On Mar 26, 2013, at 6:50 PM, Jamie Bowden wrote: > let's suppose I just happen to have, or have access to, a botnet comprised of (tens of) millions of random hosts all over the internet, and I feel like destroying your DNS servers via DDoS; DNS reflection/amplification attacks aren't intended as attacks against the DNS, per se; they're intended to crush any/all targeted servers and/or fill transit pipes. Same for SNMP and ntp reflection attacks. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From patrick at ianai.net Tue Mar 26 12:07:22 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 26 Mar 2013 08:07:22 -0400 Subject: Open Resolver Problems In-Reply-To: <572FDFDB-A053-4451-AA50-79D5F8F8109D@arbor.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <465966A5F5B867419F604CD3E604C1E53B089470@PRA-DCA-MAIL.pra.ray.com> <572FDFDB-A053-4451-AA50-79D5F8F8109D@arbor.net> Message-ID: <742FD6F7-6986-4916-9C9A-8012281F93D0@ianai.net> On Mar 26, 2013, at 08:01 , "Dobbins, Roland" wrote: > On Mar 26, 2013, at 6:50 PM, Jamie Bowden wrote: > >> let's suppose I just happen to have, or have access to, a botnet comprised of (tens of) millions of random hosts all over the internet, and I feel like destroying your DNS servers via DDoS; > > DNS reflection/amplification attacks aren't intended as attacks against the DNS, per se; they're intended to crush any/all targeted servers and/or fill transit pipes. To be more clear, the point of DNS reflection attacks is to amplify the amount of bandwidth the botnet can muster (and perhaps hide the true source). If you have 10s of millions of bots, you don't need to amplify. You can crush any single IP address on the 'Net. > Same for SNMP and ntp reflection attacks. And far too many other things. :( -- TTFN, patrick From rdobbins at arbor.net Tue Mar 26 12:15:52 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 26 Mar 2013 12:15:52 +0000 Subject: Open Resolver Problems In-Reply-To: <742FD6F7-6986-4916-9C9A-8012281F93D0@ianai.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <465966A5F5B867419F604CD3E604C1E53B089470@PRA-DCA-MAIL.pra.ray.com> <572FDFDB-A053-4451-AA50-79D5F8F8109D@arbor.net> <742FD6F7-6986-4916-9C9A-8012281F93D0@ianai.net> Message-ID: <98BEA42C-3997-4A01-BE28-B9AE06F16654@arbor.net> On Mar 26, 2013, at 7:07 PM, Patrick W. Gilmore wrote: > To be more clear, the point of DNS reflection attacks is to amplify the amount of bandwidth the botnet can muster (and perhaps hide the true source). Yes, hence the 'amplification' part. ;> More than hiding the actual sources, I think it's more about making it difficult (at first blush) for folks to seine out and filter the attack traffic from the normal 'background radiation' of legitimate traffic. > And far too many other things. :( Good point - game servers, etc. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bmanning at vacation.karoshi.com Tue Mar 26 12:12:46 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 26 Mar 2013 12:12:46 +0000 Subject: ORP In-Reply-To: <742FD6F7-6986-4916-9C9A-8012281F93D0@ianai.net> References: <7956431.10912.1364234677312.JavaMail.root@benjamin.baylink.com> <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <465966A5F5B867419F604CD3E604C1E53B089470@PRA-DCA-MAIL.pra.ray.com> <572FDFDB-A053-4451-AA50-79D5F8F8109D@arbor.net> <742FD6F7-6986-4916-9C9A-8012281F93D0@ianai.net> Message-ID: <20130326121246.GA29915@vacation.karoshi.com.> On Tue, Mar 26, 2013 at 08:07:22AM -0400, Patrick W. Gilmore wrote: > On Mar 26, 2013, at 08:01 , "Dobbins, Roland" wrote: > > On Mar 26, 2013, at 6:50 PM, Jamie Bowden wrote: > > > >> let's suppose I just happen to have, or have access to, a botnet comprised of (tens of) millions of random hosts all over the internet, and I feel like destroying your DNS servers via DDoS; > > > > DNS reflection/amplification attacks aren't intended as attacks against the DNS, per se; they're intended to crush any/all targeted servers and/or fill transit pipes. > > To be more clear, the point of DNS reflection attacks is to amplify the amount of bandwidth the botnet can muster (and perhaps hide the true source). > > If you have 10s of millions of bots, you don't need to amplify. You can crush any single IP address on the 'Net. > > > TTFN, > patrick "You are the Brut Squad!" From cmadams at hiwaay.net Tue Mar 26 12:59:44 2013 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 26 Mar 2013 07:59:44 -0500 Subject: Open Resolver Problems In-Reply-To: <24221.1364284290@turing-police.cc.vt.edu> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> Message-ID: <20130326125944.GA6388@hiwaay.net> Once upon a time, Valdis.Kletnieks at vt.edu said: > Now explain how you find a recursive nameserver that isn't listed in an NS > entry and *hasn't* been publicized someplace that Google can find it. The same way you find open mail relays, SSH hosts with weak user/password combos, bad WordPress installs, etc. - scan for them. If it is open to the Internet, it will be found (or probably already has been). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jlewis at lewis.org Tue Mar 26 14:15:54 2013 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 26 Mar 2013 10:15:54 -0400 (EDT) Subject: Open Resolver Problems In-Reply-To: <51506F59.7080101@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> Message-ID: > On 25/03/2013 14:33, Mikael Abrahamsson wrote: >> I would like to be able to request an IP list of open resolvers in my ASN, >> perhaps sent to the contact details in RIPE whois database to make sure I'm >> not falsely representing that ASN. Or you could just get an off-site system (cloud VM), get the software from http://monkey.org/~provos/dnsscan/, and find all your own open recursive DNS servers. There are different levels of openness for recursive DNS servers though. It looks like Jared's project lists any DNS server that responds with anything other than refused as open. A DNS server could have open recursion "disabled", but still respond with referrals to the root-servers. Older versions of bind seem to do this when configured with allow-recursion for a limited range of IPs. While not really "open" such servers are still useful for DNS amplification. The example config at http://www.team-cymru.org/Services/Resolvers/instructions.html for a bind 9.x caching server can be adapted for older bind versions doing caching+authoratative such that it'll provide recursion to those who should have it, and authority for zones for which it needs to do so. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Valdis.Kletnieks at vt.edu Tue Mar 26 14:21:17 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 10:21:17 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Tue, 26 Mar 2013 08:13:49 -0000." <515158BD.4070906@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> Message-ID: <40638.1364307677@turing-police.cc.vt.edu> On Tue, 26 Mar 2013 08:13:49 -0000, Nick Hilliard said: > Then wait for a while while it churns through the ~224*2^24 packets it > needs to scan the entire ipv4 internet. Of course, you could write your > own code, but that would take at least 1/2 an hour. > Then you have every open resolver on the internet. No you don't. You have every open resolver on a very small legacy portion of the Internet address space that's likely to solve itself in less time than the open mail relay problem took to solve. I know for a fact there's open resolvers on the IPv6 side of the fence. Good luck scanning for those. :) And yes, the miscreants *will* get a list of the IPv6 ones, because unlike whitehat researchers, they won't have a problem with finding a botnet or two, and asking every bot on the nets "What ASN are you in, and what DNS server address did DHCP hand you?" > > (Otherwise read as "we'll be glad to fix it if somebody has a brilliant > > idea on how to do so without generating more calls to the help desk than > > the near-zero rate we currently get about DNS amplification issues"....) > > The whole point of this thread is that dns amplification hurts other > people, not the resolver which is being abused. Just like in the old days, > abusing open mail relays hurt other people more than the relay operator. Yes, and in those days, a lot of sites said "sure, we'll fix it if somebody has a good cheat sheet of how to close our relay *without breaking our own users*". (And yes, I was around in "the old days", and I remember just how hard it was for some sites to fix the problem). The problem is that for the open mail relay problem, you could usually scan your mailserver logs or watch the network traffic for the tell-tale 'MAIL FROM:' and then you'd have a pretty good idea that you needed to get in touch with Fred and have him fix his machine to whatever new regime you decided to use to close your open relay, whether it was SMTP AUTH or 'mail after POP3 AUTH' or whatever. Figuring out which user sent a DNS packet from off-campus is a bit more difficult, as the DNS transaction usually doesn't contain any userid info And if you get a recursive lookup for www.ebay.com from a hotel network, you don't have a lot of other traffic you can try to correlate. Up until a few months ago, we *could* have cross-correlated the DNS traffic to POP3 checks from the same IP address - but that doesn't work as well since we outsourced almost all our mail to Google. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Tue Mar 26 14:37:00 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 10:37:00 -0400 (EDT) Subject: Open Resolver Problems In-Reply-To: Message-ID: <5003635.10942.1364308620912.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > We've been down this path before where we try to tighten the belt on > everything we don't absolutely critically need for the sake of > allowing the root problem to keep eking by. It ain't pretty and > ultimately it isn't successful either: we merely create an arms race > where the bad actors converge on the services we -can't- shut down. Correct. So when the excuse-me-but-fuck are we going to get serious, and apply the IDP to any edge carrier who doesn't implement 38? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Mar 26 14:38:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 10:38:38 -0400 (EDT) Subject: Open Resolver Problems In-Reply-To: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> Message-ID: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > b) locking down your recursive servers to networks you control Sure. But OpenDNS, Google, and the other providers of recursive servers for edge cases can't do that anymore? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From patrick at ianai.net Tue Mar 26 14:43:11 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 26 Mar 2013 10:43:11 -0400 Subject: Open Resolver Problems In-Reply-To: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> Message-ID: <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> On Mar 26, 2013, at 10:38 , Jay Ashworth wrote: >> From: "Jared Mauch" > >> b) locking down your recursive servers to networks you control > > Sure. But OpenDNS, Google, and the other providers of recursive servers > for edge cases can't do that anymore? I wish people would stop bring that up. I guarantee I see at least as many reflection attack as anyone out there. I have not _once_ called/emailed Open, Google, Dyn, Ultra, or any other professional DNS provider asking them to stop amplifying attacks to us. If you can run a server as competently as they can, then no one will complain. For the other 99.99999999% of you, LOCK THAT SHIT DOWN. -- TTFN, patrick From tom at cloudflare.com Tue Mar 26 14:43:15 2013 From: tom at cloudflare.com (Tom Paseka) Date: Tue, 26 Mar 2013 07:43:15 -0700 Subject: Open Resolver Problems In-Reply-To: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> References: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 7:38 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Jared Mauch" > > > b) locking down your recursive servers to networks you control > > Sure. But OpenDNS, Google, and the other providers of recursive servers > for edge cases can't do that anymore? Of cos they can. But they take the security of their open recursive servers very seriously. 99.99999% of the open recursors dont, hence the problem. From nick at foobar.org Tue Mar 26 14:46:00 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Mar 2013 14:46:00 +0000 Subject: Open Resolver Problems In-Reply-To: <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> Message-ID: <5151B4A8.7040009@foobar.org> On 26/03/2013 14:43, Patrick W. Gilmore wrote: > For the other 99.99999999% of you, LOCK THAT SHIT DOWN. amen, brother! From jared at puck.nether.net Tue Mar 26 14:49:42 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 10:49:42 -0400 Subject: Open Resolver Problems In-Reply-To: References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> Message-ID: On Mar 26, 2013, at 10:15 AM, Jon Lewis wrote: >> On 25/03/2013 14:33, Mikael Abrahamsson wrote: >>> I would like to be able to request an IP list of open resolvers in my ASN, >>> perhaps sent to the contact details in RIPE whois database to make sure I'm >>> not falsely representing that ASN. > > Or you could just get an off-site system (cloud VM), get the software from http://monkey.org/~provos/dnsscan/, and find all your own open recursive DNS servers. > > There are different levels of openness for recursive DNS servers though. It looks like Jared's project lists any DNS server that responds with anything other than refused as open. A DNS server could have open recursion "disabled", but still respond with referrals to the root-servers. Older versions of bind seem to do this when configured with allow-recursion for a limited range of IPs. While not really "open" such servers are still useful for DNS amplification. The example config at > > http://www.team-cymru.org/Services/Resolvers/instructions.html > > for a bind 9.x caching server can be adapted for older bind versions doing caching+authoratative such that it'll provide recursion to those who should have it, and authority for zones for which it needs to do so. I was throwing up the 'quick & dirty' data that I had for everyone to get access to quickly. There are a large number of attacks using these servers in the past week. I hope everyone takes a minute and gets with their unix/systems/DNS team and determines what they can do to minimize this. One other important item: Stop your customers from being able to spoof! If you punch in 8.8.8.8 (for example) into the system, you will see a number of devices where if a packet is directed at it that respond with 8.8.8.8, either by spoofing, or by forwarding that request to google and spoofing the origin IP. Same for the 73.73.73.73 IP as well. Those CPE devices should be locked down. - Jared From jra at baylink.com Tue Mar 26 14:51:45 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 10:51:45 -0400 (EDT) Subject: BCP38 - Internet Death Penalty Message-ID: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Ok, let's haul this up out of the other thread. It seems consensus that the anti-source-address-spoofing provisions (at least) of BCP38 have long since become critical to mitigating (and eventually preventing) UDP attacks like DNS reflection and such, and that such attacks are uniformly considered Bad Things. It also seems that, with 13 years to get it done, even if equipment makers have put usable working knobs into their edge routers and concentrators, sufficient numbers of IAPs have not started turning them on. The problem here is, of course, one of externalities and the Common Good, hard sales to make in a business environment. But have we reached the point where it's time to start trying? Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)? Put this in contracts and renewals, with the same penalty? Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs? Cheers, -- jr 'will rouse rabble for food' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rdobbins at arbor.net Tue Mar 26 15:04:16 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 26 Mar 2013 15:04:16 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: On Mar 26, 2013, at 9:51 PM, Jay Ashworth wrote: > Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs? Unfortunately, no - else it would've come to pass quite some time ago. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From Valdis.Kletnieks at vt.edu Tue Mar 26 15:06:05 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 11:06:05 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Tue, 26 Mar 2013 10:51:45 -0400." <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: <43218.1364310365@turing-police.cc.vt.edu> On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said: > Do we need to define a flag day, say one year hence, and start making the > sales pitch to our Corporate Overlords that we need to apply the IDP to > edge connections which cannot prove they've implemented BCP38 (or at very > least, the source address spoofing provisions thereof)? How would one prove this? (In particular, consider the test "have them download the spoofer code from SAIL and run it" - I'm positive there will be sites that will put in a /32 block for the test machine so it "fails" to spoof but leave it open for the rest of the net). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ahebert at pubnix.net Tue Mar 26 15:06:47 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 26 Mar 2013 11:06:47 -0400 Subject: Open Resolver Problems In-Reply-To: <5151B4A8.7040009@foobar.org> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> Message-ID: <5151B987.50302@pubnix.net> Well, And why not targeting all that animosity to the peers allowing source IP spoofing? DNS Servers don't attack you, people letting their customers spoof source IP do. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/26/13 10:46, Nick Hilliard wrote: > On 26/03/2013 14:43, Patrick W. Gilmore wrote: >> For the other 99.99999999% of you, LOCK THAT SHIT DOWN. > amen, brother! > > > > From jared at puck.nether.net Tue Mar 26 15:07:05 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 11:07:05 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: <9265CE3F-A180-4BE6-9615-EB9004E21B3D@puck.nether.net> On Mar 26, 2013, at 11:04 AM, "Dobbins, Roland" wrote: > > On Mar 26, 2013, at 9:51 PM, Jay Ashworth wrote: > >> Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs? > > Unfortunately, no - else it would've come to pass quite some time ago. My observation is that a lot of people sometimes struggle to just hold their routing together at times, let alone to do something that is a second tier feature/capability. - Jared From Valdis.Kletnieks at vt.edu Tue Mar 26 15:07:10 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 11:07:10 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Tue, 26 Mar 2013 07:43:15 -0700." References: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> Message-ID: <43291.1364310430@turing-police.cc.vt.edu> On Tue, 26 Mar 2013 07:43:15 -0700, Tom Paseka said: > On Tue, Mar 26, 2013 at 7:38 AM, Jay Ashworth wrote: > > Sure. But OpenDNS, Google, and the other providers of recursive servers > > for edge cases can't do that anymore? > Of cos they can. But they take the security of their open recursive servers > very seriously. 99.99999% of the open recursors dont, hence the problem. And what, *exactly* do they do different from the other 5-9's? So far, I've seen lots of people say "close that shit down", but only 2 actual URLs posted that basically both say "only do recursion for IP addresses within your ASN". That's at least a *bit* more helpful than just telling us to close it down. Unfortunately, we already know now to do that - but that isn't the problem that some of us are looking to solve, which is "queries from your own users mobile devices that are currently *outside* your ASN". (And *please* make note that although the fine networking staff of AS1312 can probably figure this out on our own once we're supplied with a big enough pile of square tuits and a belt sander, there's a *lot* of AS's out there that are going to need a tad more hand-holding...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Tue Mar 26 15:09:21 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 11:09:21 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: <43218.1364310365@turing-police.cc.vt.edu> Message-ID: <12699154.11030.1364310560979.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said: > > > Do we need to define a flag day, say one year hence, and start making the > > sales pitch to our Corporate Overlords that we need to apply the IDP to > > edge connections which cannot prove they've implemented BCP38 (or at very > > least, the source address spoofing provisions thereof)? > > How would one prove this? (In particular, consider the test "have them > download the spoofer code from SAIL and run it" - I'm positive there > will be sites that will put in a /32 block for the test machine so it > "fails" to spoof but leave it open for the rest of the net). An excellent question. I suspect the largest collection of problem networks are cable/DSL eyeball networks; certainly a cabal of network ops types could be formed, anonymously to the carriers, who could run test software from home... I'm sure there are a bunch of ways that could reasonably give you a heads up that it's time to investigate. Due process is certainly called for, but clearly, lesser threats (if any have been made) aren't solving the problem. Are you conceding that BCP38 *will* solve the problem? Cause that's Question One. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From Nick at nzurku.com Tue Mar 26 15:14:44 2013 From: Nick at nzurku.com (Nick Zurku) Date: Tue, 26 Mar 2013 11:14:44 -0400 Subject: Last mile multihoming In-Reply-To: References: Message-ID: SOHO failover would be significantly easier if you had a VPN server in a datacenter, and setup something like pfSense to connect to the VPN over one or many ISP connections. You really could just buy 2-3 local ISP connections, and let the VPN tunnel reestablish in the event of an outage (under a second, usually, states and connections preserved). I am unsure of bonding all those VPN connections at the same time, but I imagine there is a method to do that. On Mon, Mar 25, 2013 at 12:56 AM, Charles Wyble < charles-lists at knownelement.com> wrote: > So isnt the most likely interruption to service due to a last mile > physical media issue? Or say a regional fiber cut that takes out the > towers you can reach and the upstream connection from your cable and telco > providers? Imo at the edge, BGP mostly protects you from layer 8 fail (if > youve done some basic best practice configuration). In theory, issues below > that (at least in the dist/core at l1 to 3) are handled by other redundancy > protections hidden from you (hsrp, fiber ring with protected path etc). > > As for dfz explosion, would mpls/private as/ vrf be a workable approach > for bgp at the edge? > > So I live in Austin. I have available to me two hfc providers (grande and > twc) and att. I also have sprint/clear vzw/tmo. I havent done an analysis > of wisp offerings (if any are on list, please email me at > charles at thefnf.org as im looking for a non ilec path for redunancy). > > So lets break this down: > > I only know of one att co in town. (Im sure if there is more, you will let > me know). So the chances of that failing are decently high. Also my > experience with att dsl have been mixed, unless im homed direct to the co. > Vz dsl otoh has always been rock solid. Also att is retiring dsl/copper. I > refuse to use uverse as they dont offer a unbundled modem/router or a way > to do bridge mode. Oh and no ipv6. (If you can put a modem in bridge mode > and still have working tv, please let me know. Ive not been able to find a > solution). > > The chances of someone driving into the dslam serving my complex or the > pedastal down the street is high (100% as it has happend a couple times). > > So this means I need a wireless backhaul. All of the providers I can reach > colocate on exactly one tower. Surrounded by a chain link fence, across > from a walmart. (Im in north austin near cameron and 183 for anyone who > lives in town). The chances of the fiber serving that tower being cut is > unknown, but not outside the realm of possibility. Or say the walmart big > rig over correcting due to a driver coming around the blind curve near > there and plowing into thr tower. Etc. > > So my best bet for uninterrupted connectivity seems to be running two > openvpn tunels on my home edge pfsense router, each to a endpoint in a colo. > > I already have a full rack of gear in joesdatacenter in kc, and its fully > redundant. I also run all of my web/mail/software dev from there, so its > not soley for bgp purposes. Most folks I imagine may have their stuff in a > colo as well and not want to run that at home. (I started a thread on that > once upon a time). It so happens, that I have various things which I cant > run there (rf equipment which I need to frequently reflash and move > around). So running bgp on my colo gear and announcing a /48 that ive > assigned to my house seems like a good idea. And I can easily cross connect > to kcix and have lots of bgp fun. The latency would be a bit high, but it > already is and I dont have any redundant connectivitym > > Ok. So thats great. Now who is my secondary? Is a vps at say linode > sufficient for a secondary bgp announcer? Will they sell me bgp enabled > transit? Will other vps providers? Do I need a box in a rack at a local > nap? Is there an ix in austin, or should I rack a box in Dallas? > > Once i have two providerdls, then i can easily use pfsense multi wan > failover and if a circuit goes down, life goes on as I rely on bgp to > detect the link failure and handle it. Yes? No? Maybe? > > So to me, this seems like a solved problem. Run multilple diverse > (carrier, media type) circuits to your edge, put a pfsense (asa, whatever > is your poison but i like pfsense the best for multi wan failover), openvpn > (i cant stand ipsec) to colo, cross connect to ... oh I dunno he.net :) > bgp for free. Done. > > For about... hmmm.. 500.00 a month? (Many colos might not do bgp with you > for less then a quarter rack, and I presume anyone serious enough about > uninterrupted service on a reasonable budget can do 500.00 a month). > > Thie discussion on soho multihoming has been fascinating to me, and I > wanted to go through a thought exercise for what I imagine is a common > scenario (main gear in a bgp enabled sp, office gear needing to be > reachable by remote personnel in a non bgp enabled sp). > > Would love to hear what you folks think. > > > > -- > Charles Wyble > charles at thefnf.org / 818 280 7059 > CTO Free Network Foundation (www.thefnf.org) > From jared at puck.nether.net Tue Mar 26 15:15:12 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 11:15:12 -0400 Subject: Open Resolver Problems In-Reply-To: <5151B987.50302@pubnix.net> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> Message-ID: On Mar 26, 2013, at 11:06 AM, Alain Hebert wrote: > Well, > > And why not targeting all that animosity to the peers allowing > source IP spoofing? > > DNS Servers don't attack you, people letting their customers spoof > source IP do. I don't view this as an either-or situation. One needs both. - Jared From djahandarie at gmail.com Tue Mar 26 15:19:36 2013 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 26 Mar 2013 11:19:36 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <43218.1364310365@turing-police.cc.vt.edu> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <43218.1364310365@turing-police.cc.vt.edu> Message-ID: <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> (Mobile device) On Mar 26, 2013, at 11:06 AM,Valdis.Kletnieks at vt.edu wrote: > On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said: > >> Do we need to define a flag day, say one year hence, and start making the >> sales pitch to our Corporate Overlords that we need to apply the IDP to >> edge connections which cannot prove they've implemented BCP38 (or at very >> least, the source address spoofing provisions thereof)? > > How would one prove this? (In particular, consider the test "have them > download the spoofer code from SAIL and run it" - I'm positive there will > be sites that will put in a /32 block for the test machine so it "fails" > to spoof but leave it open for the rest of the net). Well, I'm not sure this is what's being suggested by Jay, but many peering agreements/policies have something in them that say "prevent spoofing to best effort". Such statements could be strengthened in a global effort, and then spoofed source addresses could lead to depeering much faster/harder than what happens today. It would be reactionary rather than proactive, but still better than what we have now where spoofing is kind of like "it can't be helped". -- Darius Jahandarie From nick at foobar.org Tue Mar 26 15:38:20 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Mar 2013 15:38:20 +0000 Subject: Open Resolver Problems In-Reply-To: <5151B987.50302@pubnix.net> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> Message-ID: <5151C0EC.7000008@foobar.org> On 26/03/2013 15:06, Alain Hebert wrote: > And why not targeting all that animosity to the peers allowing > source IP spoofing? I do - and I gave a bunch of talks in europistan over the last 12 months which included explicit encouragement, practice and configuration for implementing BCP38 as part of real-time black hole system deployment. > DNS Servers don't attack you, people letting their customers spoof > source IP do. DNS amp packets attack me. Please stop them from leaving your network, and I will both implement BCP38 and encourage others to do so. Thank you. Nick From sj_hznm at hotmail.com Tue Mar 26 15:39:30 2013 From: sj_hznm at hotmail.com (Joe) Date: Tue, 26 Mar 2013 15:39:30 +0000 Subject: Question on Ipv6 address Message-ID: I'm new to Ipv6 and trying to understanding something about IPv6 in service provider network. I've got the following questions , could anybody do some helps? 1. In a dial-up network (Q-in-Q for each customer who dials in ) Should each customer be assigned to ipv6 subnet prefix like /64 unique universily? I've read a rfc which stated point-to-point like should be assigned /64. But to my understanding, in dial-up network , each user should only needed to be assigned a single ipv4 address, with wich customer could used in his PC or his home router. 2. In dial-up network, could each vlan's ipv6 link-id be planned with its vlan number? if so, IP v6 address confliction could be avoided when BAS is assigned a /64 or longer prefix. 3. we are testing some BAS with IPv6 accessing, in radius accouting packets, there is IP-v6-prefix, Ip-v6-link-id, Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be calculated with above information? 4. should it be necessary to plan different IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? 5. How could delegated IPv6 prefix be used in service provider's network? is this useful in dial-up access network? each word will be highly appreciated. Joe From jared at puck.nether.net Tue Mar 26 15:42:57 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 11:42:57 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <43218.1364310365@turing-police.cc.vt.edu> <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> Message-ID: On Mar 26, 2013, at 11:19 AM, Darius Jahandarie wrote: > Well, I'm not sure this is what's being suggested by Jay, but many peering agreements/policies have something in them that say "prevent spoofing to best effort". Such statements could be strengthened in a global effort, and then spoofed source addresses could lead to depeering much faster/harder than what happens today. It would be reactionary rather than proactive, but still better than what we have now where spoofing is kind of like "it can't be helped". I'll certainly say that I've worked for many an imperfect network when it comes to this. I've always tried to drop bogons (non routed space) including spoofed packets. While many a network is imperfect, there are places where we can improve. The high-speed servers in data centers or part of your VM infrastructure is one example of a place where: a) They aren't running BGP for multihoming with 10k prefixes b) have a fixed IP subnet for that edge host or management LAN c) could quickly have unicast-rpf enabled with no impact. If you have folks bringing in/out either known or unknown VMs, you must treat these as a possible risk. Same goes for any colocation environment. Those T1 customers you still have? DS3 with one prefix and BGP on? Turn on unicast-rpf there too. You won't break anyone. I recall going around and turning it on dozens of T1's at a time since they all had static routes. Just because the link size is now gig-e (or 10G or 100G) doesn't mean it's not worth doing. Consider this my plea to the community. Ask the question: Can we spoof? What happens when law enforcement comes to the door to confiscate a machine because it was involved in a 10's of gigs of attack? what if it's 100's of gigs? At what size of attack for what duration will make things change? Are there simple places where unicast-rpf makes sense? In front of the firewall is a simple place to drop spoofed packets. You'd be surprised how many of them are broken and emit an internal IP anyways, so don't leak that. I certainly see many places where simple steps like this will improve the overall ecosystem and make us safer. Machines get compromised, but limit the scope of the possible abuse. If nothing is done, will udp/53 become blackholed just like tcp/25 is for many folks? Is that the type of network you want to debug and troubleshoot? - Jared From lists at mtin.net Tue Mar 26 16:05:47 2013 From: lists at mtin.net (Justin Wilson) Date: Tue, 26 Mar 2013 12:05:47 -0400 Subject: Question on Ipv6 address In-Reply-To: Message-ID: I don't mean to hijack the thread so if someone wants to open a new one that?s cool. But my question is what dial-up hardware supports v6? I am *assuming* Cisco does. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.zigwireless.com ? High Speed Internet Options http://www.thebrotherswisp.com ? The Brothers Wisp -----Original Message----- From: Joe Date: Tuesday, March 26, 2013 11:39 AM To: NANOG Subject: Question on Ipv6 address >I'm new to Ipv6 and trying to understanding something about IPv6 in >service provider network. >I've got the following questions , could anybody do some helps? >1. In a dial-up network (Q-in-Q for each customer who dials in ) >Should each customer be assigned to ipv6 subnet prefix like /64 unique >universily? I've read a rfc which stated point-to-point like should be >assigned /64. But to my understanding, in dial-up network , each user >should only needed to be assigned a single ipv4 address, with wich >customer could used in his PC or his home router. >2. In dial-up network, could each vlan's ipv6 link-id be planned with >its vlan number? if so, IP v6 address confliction could be avoided >when BAS is assigned a /64 or longer prefix. >3. we are testing some BAS with IPv6 accessing, in radius accouting >packets, there is IP-v6-prefix, Ip-v6-link-id, >Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be >calculated with above information? >4. should it be necessary to plan different >IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? >5. How could delegated IPv6 prefix be used in service provider's network? >is this useful in dial-up access network? > >each word will be highly appreciated. >Joe > From swmike at swm.pp.se Tue Mar 26 16:20:25 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Mar 2013 17:20:25 +0100 (CET) Subject: BCP38 - Internet Death Penalty In-Reply-To: <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <43218.1364310365@turing-police.cc.vt.edu> <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> Message-ID: On Tue, 26 Mar 2013, Darius Jahandarie wrote: > Well, I'm not sure this is what's being suggested by Jay, but many > peering agreements/policies have something in them that say "prevent > spoofing to best effort". Such statements could be strengthened in a > global effort, and then spoofed source addresses could lead to depeering > much faster/harder than what happens today. It would be reactionary > rather than proactive, but still better than what we have now where > spoofing is kind of like "it can't be helped". I wish the Internet census people would try spoofing from their "botnet" and tell us which ISPs allow spoofing. I don't think this will fixed until there is a hall of shame or some kind of law requiring this and offenders would be fined. Can't we get homeland security into this? Threat to US national security if people can spoof? :P -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Tue Mar 26 16:28:39 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Mar 2013 09:28:39 -0700 Subject: Open Resolver Problems In-Reply-To: <20130326125944.GA6388@hiwaay.net> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <20130326125944.GA6388@hiwaay.net> Message-ID: <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> On Mar 26, 2013, at 5:59 AM, Chris Adams wrote: > Once upon a time, Valdis.Kletnieks at vt.edu said: >> Now explain how you find a recursive nameserver that isn't listed in an NS >> entry and *hasn't* been publicized someplace that Google can find it. > > The same way you find open mail relays, SSH hosts with weak > user/password combos, bad WordPress installs, etc. - scan for them. If > it is open to the Internet, it will be found (or probably already has > been). > Let me rephrase the question? How do you find an open IPv6 recursive name server that isn't listed in an NS entry and hasn't been publicized someplace that Google can find it? Owen From eugen at leitl.org Tue Mar 26 16:36:42 2013 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 26 Mar 2013 17:36:42 +0100 Subject: glass fiber @ 0.997 c Message-ID: <20130326163642.GL6172@leitl.org> http://www.newscientist.com/article/dn23309-information-superhighway-approaches-light-speed.html Information superhighway approaches light speed 18:00 24 March 2013 by Jacob Aron Nothing moves faster than light in a vacuum, but large volumes of data can now travel at 99.7 per cent of this ultimate speed limit. In glass optical fibres, light travels 31 per cent slower than in a vacuum. Hollowing them out so that most of the light travels through air speeds things up. But these hollow fibres are a poor replacement as light scatters at the glass-air interface, limiting the number of wavelengths, and therefore the volume of data, transmitted at once. Now Francesco Poletti and colleagues at the University of Southampton, UK, have made fibres with an ultra-thin glass rim, enabling a much wider band of wavelengths to travel at high speed at once. The team's record is a 73.7 terabit per second transmission over 310?metres, a 15,000-fold increase over ordinary hollow fibres. "Previous fibres either have higher bandwidth but high loss, or lower loss but narrower bandwidth," says Poletti. "We've achieved both in the same fibre." Journal reference: Nature Photonics, DOI: 10.1038/nphoton.2013.45 http://www.nature.com/nphoton/journal/vaop/ncurrent/full/nphoton.2013.45.html Towards high-capacity fibre-optic communications at the speed of light in vacuum F. Poletti, N. V. Wheeler, M. N. Petrovich, N. Baddela, E. Numkam Fokoua, J. R. Hayes, D. R. Gray, Z. Li, R. Slav?k & D. J. Richardson Nature Photonics (2013) doi:10.1038/nphoton.2013.45 Received 13 September 2012 Accepted 08 February 2013 Published online 24 March 2013 Abstract Wide-bandwidth signal transmission with low latency is emerging as a key requirement in a number of applications, including the development of future exaflop-scale supercomputers, financial algorithmic trading and cloud computing1, 2, 3. Optical fibres provide unsurpassed transmission bandwidth, but light propagates 31% slower in a silica glass fibre than in vacuum, thus compromising latency. Air guidance in hollow-core fibres can reduce fibre latency very significantly. However, state-of-the-art technology cannot achieve the combined values of loss, bandwidth and mode-coupling characteristics required for high-capacity data transmission. Here, we report a fundamentally improved hollow-core photonic-bandgap fibre that provides a record combination of low loss (3.5 dB km?1) and wide bandwidth (160 nm), and use it to transmit 37 ? 40 Gbit s?1 channels at a 1.54 ?s km?1 faster speed than in a conventional fibre. This represents the first experimental demonstration of fibre-based wavelength division multiplexed data transmission at close to (99.7%) the speed of light in vacuum. From dougb at dougbarton.us Tue Mar 26 16:39:04 2013 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 26 Mar 2013 09:39:04 -0700 Subject: Open Resolver Problems In-Reply-To: <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <20130326125944.GA6388@hiwaay.net> <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> Message-ID: <5151CF28.50605@dougbarton.us> On 03/26/2013 09:28 AM, Owen DeLong wrote: > > On Mar 26, 2013, at 5:59 AM, Chris Adams wrote: > >> Once upon a time, Valdis.Kletnieks at vt.edu said: >>> Now explain how you find a recursive nameserver that isn't listed in an NS >>> entry and *hasn't* been publicized someplace that Google can find it. >> >> The same way you find open mail relays, SSH hosts with weak >> user/password combos, bad WordPress installs, etc. - scan for them. If >> it is open to the Internet, it will be found (or probably already has >> been). >> > > Let me rephrase the question? How do you find an open IPv6 recursive name server > that isn't listed in an NS entry and hasn't been publicized someplace that Google can > find it? That question was already answered ... ask the bots what their resolving name servers are, then check to see if they are open. As IPv6 deployment increases, the answers will increasingly include IPv6 open resolvers. Doug From saku at ytti.fi Tue Mar 26 16:40:38 2013 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 Mar 2013 18:40:38 +0200 Subject: Open Resolver Problems In-Reply-To: <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <20130326125944.GA6388@hiwaay.net> <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> Message-ID: <20130326164038.GA12618@pob.ytti.fi> On (2013-03-26 09:28 -0700), Owen DeLong wrote: > Let me rephrase the question? How do you find an open IPv6 recursive name server > that isn't listed in an NS entry and hasn't been publicized someplace that Google can > find it? Pwn authorative server catering moderately popular domain and share query sources as torrent file. -- ++ytti From owen at delong.com Tue Mar 26 16:45:11 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Mar 2013 09:45:11 -0700 Subject: Last mile multihoming In-Reply-To: References: Message-ID: <1D4F5DF9-4CFB-4224-B3E7-02ADFE44C817@delong.com> On Mar 26, 2013, at 8:14 AM, Nick Zurku wrote: > SOHO failover would be significantly easier if you had a VPN server in a > datacenter, and setup something like pfSense to connect to the VPN over one > or many ISP connections. I'm essentially doing this now. It does not reduce the DFZ impact. I advertise my routes out of the two data centers where my VPNs terminate (well, GRE tunnels, really) and run iBGP across the tunnels. It works just fine, but it's not simpler than it would be if I could just peer with my direct upstreams. > You really could just buy 2-3 local ISP connections, and let the VPN tunnel > reestablish in the event of an outage (under a second, usually, states and > connections preserved). I am unsure of bonding all those VPN connections at > the same time, but I imagine there is a method to do that. Yes, that's what happens today. How is managing a mesh of VPNs, equipment in two additional data centers, a bunch of tunnels, and an extra 4+ BGP sessions simpler? Owen > > On Mon, Mar 25, 2013 at 12:56 AM, Charles Wyble < > charles-lists at knownelement.com> wrote: > >> So isnt the most likely interruption to service due to a last mile >> physical media issue? Or say a regional fiber cut that takes out the >> towers you can reach and the upstream connection from your cable and telco >> providers? Imo at the edge, BGP mostly protects you from layer 8 fail (if >> youve done some basic best practice configuration). In theory, issues below >> that (at least in the dist/core at l1 to 3) are handled by other redundancy >> protections hidden from you (hsrp, fiber ring with protected path etc). >> >> As for dfz explosion, would mpls/private as/ vrf be a workable approach >> for bgp at the edge? >> >> So I live in Austin. I have available to me two hfc providers (grande and >> twc) and att. I also have sprint/clear vzw/tmo. I havent done an analysis >> of wisp offerings (if any are on list, please email me at >> charles at thefnf.org as im looking for a non ilec path for redunancy). >> >> So lets break this down: >> >> I only know of one att co in town. (Im sure if there is more, you will let >> me know). So the chances of that failing are decently high. Also my >> experience with att dsl have been mixed, unless im homed direct to the co. >> Vz dsl otoh has always been rock solid. Also att is retiring dsl/copper. I >> refuse to use uverse as they dont offer a unbundled modem/router or a way >> to do bridge mode. Oh and no ipv6. (If you can put a modem in bridge mode >> and still have working tv, please let me know. Ive not been able to find a >> solution). >> >> The chances of someone driving into the dslam serving my complex or the >> pedastal down the street is high (100% as it has happend a couple times). >> >> So this means I need a wireless backhaul. All of the providers I can reach >> colocate on exactly one tower. Surrounded by a chain link fence, across >> from a walmart. (Im in north austin near cameron and 183 for anyone who >> lives in town). The chances of the fiber serving that tower being cut is >> unknown, but not outside the realm of possibility. Or say the walmart big >> rig over correcting due to a driver coming around the blind curve near >> there and plowing into thr tower. Etc. >> >> So my best bet for uninterrupted connectivity seems to be running two >> openvpn tunels on my home edge pfsense router, each to a endpoint in a colo. >> >> I already have a full rack of gear in joesdatacenter in kc, and its fully >> redundant. I also run all of my web/mail/software dev from there, so its >> not soley for bgp purposes. Most folks I imagine may have their stuff in a >> colo as well and not want to run that at home. (I started a thread on that >> once upon a time). It so happens, that I have various things which I cant >> run there (rf equipment which I need to frequently reflash and move >> around). So running bgp on my colo gear and announcing a /48 that ive >> assigned to my house seems like a good idea. And I can easily cross connect >> to kcix and have lots of bgp fun. The latency would be a bit high, but it >> already is and I dont have any redundant connectivitym >> >> Ok. So thats great. Now who is my secondary? Is a vps at say linode >> sufficient for a secondary bgp announcer? Will they sell me bgp enabled >> transit? Will other vps providers? Do I need a box in a rack at a local >> nap? Is there an ix in austin, or should I rack a box in Dallas? >> >> Once i have two providerdls, then i can easily use pfsense multi wan >> failover and if a circuit goes down, life goes on as I rely on bgp to >> detect the link failure and handle it. Yes? No? Maybe? >> >> So to me, this seems like a solved problem. Run multilple diverse >> (carrier, media type) circuits to your edge, put a pfsense (asa, whatever >> is your poison but i like pfsense the best for multi wan failover), openvpn >> (i cant stand ipsec) to colo, cross connect to ... oh I dunno he.net :) >> bgp for free. Done. >> >> For about... hmmm.. 500.00 a month? (Many colos might not do bgp with you >> for less then a quarter rack, and I presume anyone serious enough about >> uninterrupted service on a reasonable budget can do 500.00 a month). >> >> Thie discussion on soho multihoming has been fascinating to me, and I >> wanted to go through a thought exercise for what I imagine is a common >> scenario (main gear in a bgp enabled sp, office gear needing to be >> reachable by remote personnel in a non bgp enabled sp). >> >> Would love to hear what you folks think. >> >> >> >> -- >> Charles Wyble >> charles at thefnf.org / 818 280 7059 >> CTO Free Network Foundation (www.thefnf.org) >> From bicknell at ufp.org Tue Mar 26 16:46:32 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 Mar 2013 09:46:32 -0700 Subject: Open Resolver Problems In-Reply-To: <20130326164038.GA12618@pob.ytti.fi> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <20130326125944.GA6388@hiwaay.net> <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> <20130326164038.GA12618@pob.ytti.fi> Message-ID: <20130326164632.GA50228@ussenterprise.ufp.org> In a message written on Tue, Mar 26, 2013 at 06:40:38PM +0200, Saku Ytti wrote: > Pwn authorative server catering moderately popular domain and share query > sources as torrent file. Run authortative server hosting command and control for a botnet, log query sources and use for your own purposes. IPv6 Temporary / Privacy addresses and making your DNS server query from them outbound might be a useful trick. -- 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 owen at delong.com Tue Mar 26 16:52:00 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Mar 2013 09:52:00 -0700 Subject: Question on Ipv6 address In-Reply-To: References: Message-ID: <3F84AEBD-D4DA-4C50-ADE8-E4DBA75B58FF@delong.com> On Mar 26, 2013, at 8:39 AM, Joe wrote: > I'm new to Ipv6 and trying to understanding something about IPv6 in service provider network. > I've got the following questions , could anybody do some helps? > 1. In a dial-up network (Q-in-Q for each customer who dials in ) Should each customer be assigned to ipv6 subnet prefix like /64 unique universily? I've read a rfc which stated point-to-point like should be assigned /64. But to my > understanding, in dial-up network , each user should only needed to be assigned a single ipv4 address, with wich customer could used in his PC or his home router. IPv6 is very different from IPv4. In IPv6, there should be a /64 assigned to the point to point link over which a /48 should be delegated to the customer. If the customer doesn't have a router and is just attaching a single PC, he will not make the Prefix Delegation request and just the point-to-point /64 will be adequate. > 2. In dial-up network, could each vlan's ipv6 link-id be planned with its vlan number? if so, IP v6 address confliction could be avoided when BAS is assigned a /64 or longer prefix. Why would you ever assign a longer prefix? I'm not sure what you mean by "link-id", so I'm not sure what you are attempting to resolve here. > 3. we are testing some BAS with IPv6 accessing, in radius accouting packets, there is IP-v6-prefix, Ip-v6-link-id, Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be calculated with above information? It probably can't. Why do you need to? > 4. should it be necessary to plan different IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? There are multiple ways to structure this. If you put all of the customers into a common NBMA network, then you can use a single /64 prefix to number all of the link addresses from a given BAS to the customer sites. All of the CPE routers will use the same address on the BAS as their default gateway. If you put the customers into individual VLANs, then each VLAN should have a /64 prefix assigned to it. Beyond that, if the customer has a router, you should plan on having a /48 delegated prefix for each customer. > 5. How could delegated IPv6 prefix be used in service provider's network? is this useful in dial-up access network? The delegated prefix isn't used in the service provider's network. It is delegated to the customer for them to number their network. It can be used by the customer regardless of attachment method, though the low speeds of dialup make a complex topology on the far side less likely. Owen From jared at puck.nether.net Tue Mar 26 16:25:09 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 09:25:09 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <43218.1364310365@turing-police.cc.vt.edu> <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> Message-ID: I'm not sure you want this regulated. Jared Mauch On Mar 26, 2013, at 9:20 AM, Mikael Abrahamsson wrote: > Can't we get homeland security into this? Threat to US national security if people can spoof? :P From hhoffman at ip-solutions.net Tue Mar 26 16:59:25 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 26 Mar 2013 12:59:25 -0400 Subject: Open Resolver Problems In-Reply-To: <43291.1364310430@turing-police.cc.vt.edu> References: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <43291.1364310430@turing-police.cc.vt.edu> Message-ID: <5151D3ED.2040907@ip-solutions.net> https://developers.google.com/speed/public-dns/docs/security Cheers, Harry On 03/26/2013 11:07 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 26 Mar 2013 07:43:15 -0700, Tom Paseka said: >> On Tue, Mar 26, 2013 at 7:38 AM, Jay Ashworth wrote: > >>> Sure. But OpenDNS, Google, and the other providers of recursive servers >>> for edge cases can't do that anymore? > >> Of cos they can. But they take the security of their open recursive servers >> very seriously. 99.99999% of the open recursors dont, hence the problem. > > And what, *exactly* do they do different from the other 5-9's? > > So far, I've seen lots of people say "close that shit down", but only 2 > actual URLs posted that basically both say "only do recursion for IP addresses > within your ASN". That's at least a *bit* more helpful than just telling us > to close it down. Unfortunately, we already know now to do that - but that > isn't the problem that some of us are looking to solve, which is "queries from > your own users mobile devices that are currently *outside* your ASN". > > (And *please* make note that although the fine networking staff of AS1312 > can probably figure this out on our own once we're supplied with a big > enough pile of square tuits and a belt sander, there's a *lot* of AS's out > there that are going to need a tad more hand-holding...) > From bill at herrin.us Tue Mar 26 17:01:26 2013 From: bill at herrin.us (William Herrin) Date: Tue, 26 Mar 2013 13:01:26 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 10:51 AM, Jay Ashworth wrote: > But have we reached the point where it's time to start trying? Yes. > Do we need to define a flag day, say one year hence, and start making the > sales pitch to our Corporate Overlords that we need to apply the IDP to > edge connections which cannot prove they've implemented BCP38 (or at very > least, the source address spoofing provisions thereof)? Put this in > contracts and renewals, with the same penalty? Yes, but scope the problem a little differently. 1. The general IDP does not apply to stub networks which do not speak BGP. It is for those stubs' ISPs to determine how they'll handle mis-sourced traffic they receive from those networks. 2. A BGP origin-only network is required to secure its BGP-speaking borders against source address spoofing. It may also secure spoofing from downstream networks (and in fact it SHOULD do so) but it avoids the IDP so long as its BGP-speaking borders are secured. 3. A BGP transit network is required to secure all components of its network against source address spoofing, including all non-BGP stub customers and all origin-only BGP customers. It is not expected to prevent spoofed packets from arriving from neighboring transit BGP networks. It is also expected to promptly assist (24/7/365) with trace requests from any individual presenting legitimate credentials as the assignee of a particular source address and presenting with reasonable evidence that packets with a spoofed address cross a specifically identified system owned by the transit network. Where the packet stream continues, these trace requests must promptly result in identification of the actual source of the packet (if within the transit network's system) or the identification of the neighboring system, the specific entry point and high-level contacts within the neighbor system capable of continuing the trace. Some number of misconfigurations which permit spoofed packets from components of the transit network's components are to be expected and promptly corrected. 4. Applying the IDP _does not_ mean you cut off the network. That'll piss of your customers as much or more than it pisses off theirs. The position is untenable. Instead, the IDP consists of redirecting the offender's public presence web sites to a web site which proclaims the IDP, lists the causes of the IDP and lists the actions required to lift the IDP. 5. IDP can't be a local decision. We should elect or empanel or otherwise select a group of individuals who decide both when a network gets the IDP and when the IDP is lifted. Compliance with the group's decision to impose an IDP can be optional but a riot of RBLs like have developed in the anti-spam community would cause at least as much trouble as it fixes. > Do the engineering heads at the top 10 tier-1/2 carriers carry enough water > to make that sale to the CEOs? To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jabley at hopcount.ca Tue Mar 26 17:09:53 2013 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 26 Mar 2013 13:09:53 -0400 Subject: DNS for mobile devices In-Reply-To: <43291.1364310430@turing-police.cc.vt.edu> References: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <43291.1364310430@turing-police.cc.vt.edu> Message-ID: <6E25B5D8-9459-410D-9CB6-FB0978ACA97F@hopcount.ca> On 2013-03-26, at 11:07, Valdis.Kletnieks at vt.edu wrote: > which is "queries from > your own users mobile devices that are currently *outside* your ASN". This problem made more sense to me ten years ago than it does now. What mobile devices do you support that don't acquire a suitable local DNS resolver using DHCP or PPP? Honest question. I presume you wouldn't bring it up if it wasn't a real problem. Joe From owen at delong.com Tue Mar 26 17:10:58 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Mar 2013 10:10:58 -0700 Subject: Open Resolver Problems In-Reply-To: <5151CF28.50605@dougbarton.us> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <20130326125944.GA6388@hiwaay.net> <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> <5151CF28.50605@dougbarton.us> Message-ID: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> On Mar 26, 2013, at 9:39 AM, Doug Barton wrote: > On 03/26/2013 09:28 AM, Owen DeLong wrote: >> >> On Mar 26, 2013, at 5:59 AM, Chris Adams wrote: >> >>> Once upon a time, Valdis.Kletnieks at vt.edu said: >>>> Now explain how you find a recursive nameserver that isn't listed in an NS >>>> entry and *hasn't* been publicized someplace that Google can find it. >>> >>> The same way you find open mail relays, SSH hosts with weak >>> user/password combos, bad WordPress installs, etc. - scan for them. If >>> it is open to the Internet, it will be found (or probably already has >>> been). >>> >> >> Let me rephrase the question? How do you find an open IPv6 recursive name server >> that isn't listed in an NS entry and hasn't been publicized someplace that Google can >> find it? > > That question was already answered ... ask the bots what their resolving name servers are, then check to see if they are open. As IPv6 deployment increases, the answers will increasingly include IPv6 open resolvers. > > Doug > Let me again rephrase? As a white-hat attempting to find problems to address through legitimate means, how do you ? Owen From joelja at bogus.com Tue Mar 26 17:33:43 2013 From: joelja at bogus.com (joel jaeggli) Date: Tue, 26 Mar 2013 10:33:43 -0700 Subject: Open Resolver Problems In-Reply-To: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <20130326125944.GA6388@hiwaay.net> <06A58F7B-C715-45EE-B2B8-6E57A0D41006@delong.com> <5151CF28.50605@dougbarton.us> <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> Message-ID: <5151DBF7.1040803@bogus.com> On 3/26/13 10:10 AM, Owen DeLong wrote: > On Mar 26, 2013, at 9:39 AM, Doug Barton wrote: > >> On 03/26/2013 09:28 AM, Owen DeLong wrote: >>> On Mar 26, 2013, at 5:59 AM, Chris Adams wrote: >>> >>>> Once upon a time, Valdis.Kletnieks at vt.edu said: >>>>> Now explain how you find a recursive nameserver that isn't listed in an NS >>>>> entry and *hasn't* been publicized someplace that Google can find it. >>>> The same way you find open mail relays, SSH hosts with weak >>>> user/password combos, bad WordPress installs, etc. - scan for them. If >>>> it is open to the Internet, it will be found (or probably already has >>>> been). >>>> >>> Let me rephrase the question? How do you find an open IPv6 recursive name server >>> that isn't listed in an NS entry and hasn't been publicized someplace that Google can >>> find it? >> That question was already answered ... ask the bots what their resolving name servers are, then check to see if they are open. As IPv6 deployment increases, the answers will increasingly include IPv6 open resolvers. >> >> Doug >> > Let me again rephrase? > > As a white-hat attempting to find problems to address through legitimate means, how > do you ? passive DNS collection , e.g. many people lave large lists of resolvers that have connected to their authoritative nameservers. > > Owen > > > From Valdis.Kletnieks at vt.edu Tue Mar 26 18:15:40 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 14:15:40 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Tue, 26 Mar 2013 12:59:25 -0400." <5151D3ED.2040907@ip-solutions.net> References: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <43291.1364310430@turing-police.cc.vt.edu> <5151D3ED.2040907@ip-solutions.net> Message-ID: <12387.1364321740@turing-police.cc.vt.edu> On Tue, 26 Mar 2013 12:59:25 -0400, Harry Hoffman said: > https://developers.google.com/speed/public-dns/docs/security Thanks :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Mar 26 18:15:26 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 14:15:26 -0400 Subject: DNS for mobile devices In-Reply-To: Your message of "Tue, 26 Mar 2013 13:09:53 -0400." <6E25B5D8-9459-410D-9CB6-FB0978ACA97F@hopcount.ca> References: <484C70F0-1549-4FD3-9BBE-31779897AE6C@puck.nether.net> <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <43291.1364310430@turing-police.cc.vt.edu> <6E25B5D8-9459-410D-9CB6-FB0978ACA97F@hopcount.ca> Message-ID: <12367.1364321726@turing-police.cc.vt.edu> On Tue, 26 Mar 2013 13:09:53 -0400, Joe Abley said: > What mobile devices do you support that don't acquire a suitable local DNS resolver using DHCP or PPP? Pretty much all devices are *able* to acquire a DNS resolver via DHCP. > Honest question. I presume you wouldn't bring it up if it wasn't a real problem. The problem starts when you don't *trust* DHCP to hand you a pointer to a *working* DNS resolver (anybody who's had a hotel net hand them a DNS that's either busted or MITMs your queries knows what I mean, and I hope I don't have to explain about the fun involved in using wireless anywhere near a DefCon or Black Hat conference). And yes, unless you turn on DNSSEC you don't have much defense against a hotel net or rogue net that decides to spoof replies to your queries to your home DNS server Now in day-to-day production, it's *mostly* a non-issue, because many/most of the people who hard-code our DNS into their mobile configs will also fire up a VPN to our campus. Unfortunately, that leaves us a lot of interesting to diagnose corner cases involving DNS lookups that happen between when they boot the device and when they launch the VPN (for instance, coding a DNS name rather than an IP for the VPN endpoint :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mejndp at rit.edu Tue Mar 26 19:10:06 2013 From: mejndp at rit.edu (Mark Jeremy) Date: Tue, 26 Mar 2013 15:10:06 -0400 Subject: Question on Ipv6 address In-Reply-To: References: Message-ID: <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9@ex02mail01.ad.rit.edu> Justin, Dial-up modem is just a layer 2 device with no IP address. Just think of it as a converter, its sole function is to convert the telephone line to something your PC can use, in this case, Ethernet. Both IPv4 and IPv6 operate on the layer 3 of the OSI model which is taken care of by the RAS. So basically any dial-up modem support IPv6. -MJ -----Original Message----- From: Justin Wilson [mailto:lists at mtin.net] Sent: Tuesday, March 26, 2013 12:06 PM To: NANOG Subject: Re: Question on Ipv6 address I don't mean to hijack the thread so if someone wants to open a new one that?s cool. But my question is what dial-up hardware supports v6? I am *assuming* Cisco does. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.zigwireless.com ? High Speed Internet Options http://www.thebrotherswisp.com ? The Brothers Wisp -----Original Message----- From: Joe Date: Tuesday, March 26, 2013 11:39 AM To: NANOG Subject: Question on Ipv6 address >I'm new to Ipv6 and trying to understanding something about IPv6 in >service provider network. >I've got the following questions , could anybody do some helps? >1. In a dial-up network (Q-in-Q for each customer who dials in ) Should >each customer be assigned to ipv6 subnet prefix like /64 unique >universily? I've read a rfc which stated point-to-point like should be >assigned /64. But to my understanding, in dial-up network , each user >should only needed to be assigned a single ipv4 address, with wich >customer could used in his PC or his home router. >2. In dial-up network, could each vlan's ipv6 link-id be planned with >its vlan number? if so, IP v6 address confliction could be avoided >when BAS is assigned a /64 or longer prefix. >3. we are testing some BAS with IPv6 accessing, in radius accouting >packets, there is IP-v6-prefix, Ip-v6-link-id, >Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be >calculated with above information? >4. should it be necessary to plan different >IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? >5. How could delegated IPv6 prefix be used in service provider's network? >is this useful in dial-up access network? > >each word will be highly appreciated. >Joe > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6069 bytes Desc: not available URL: From marka at isc.org Tue Mar 26 19:33:55 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 06:33:55 +1100 Subject: Question on Ipv6 address In-Reply-To: Your message of "Tue, 26 Mar 2013 15:10:06 EDT." <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9@ex02mail01.ad.rit.edu> References: <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9@ex02mail01.ad.rit.edu> Message-ID: <20130326193356.1736D31939E5@drugs.dv.isc.org> In message <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9 at ex02mail01.ad.rit.edu>, Mark Jeremy writes: > Justin, > > Dial-up modem is just a layer 2 device with no IP address. Just think of = > it > as a converter, its sole function is to convert the telephone line to > something your PC can use, in this case, Ethernet. Both IPv4 and IPv6 > operate on the layer 3 of the OSI model which is taken care of by the = > RAS. > So basically any dial-up modem support IPv6. This doesn't however mean that the equipment connected to the dialup modem supports IPv6. ISP still need to check this part of the picture. Old PPP implementations may be IPv4 only. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Tue Mar 26 20:09:23 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 16:09:23 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: Message-ID: <20877487.11064.1364328563175.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > Yes, but scope the problem a little differently. > > 1. The general IDP does not apply to stub networks which do not speak > BGP. It is for those stubs' ISPs to determine how they'll handle > mis-sourced traffic they receive from those networks. So, here, you mean customers of such as "Road Runner Business", who have an office full of workstations and maybe some servers. The goal, unless I badly misunderstood it, was to *drop forged traffic coming from this sort of source (assuming you generalize "my PC at home on a cablemodem" as the limiting example of this class, which I do). > 2. A BGP origin-only network is required to secure its BGP-speaking > borders against source address spoofing. It may also secure spoofing > from downstream networks (and in fact it SHOULD do so) but it avoids > the IDP so long as its BGP-speaking borders are secured. This is the next size up of edge network; a buyer of transit. This item does no good; you're expecting *the potential bad actor* *not to act badly*. > 3. A BGP transit network is required to secure all components of its > network against source address spoofing, including all non-BGP stub > customers and all origin-only BGP customers. It is not expected to > prevent spoofed packets from arriving from neighboring transit BGP > networks. *This* is Road Runner. Also Comcast, Mindspring, and the other Top 40 eyeball networks. It is also, of course, larger carriers who sell access in addition to more traditional transit and possibly peering. AFAICT, this is the spot where source-address-spoofing needs to be *enforced*; the people selling connections and transit here *know* what addresses should be coming in those pipes, and can therefore -- if their gear permits, and it damned well should by now -- force the dropping of all packets coming in with bogus source addresses. > It is also expected to promptly assist (24/7/365) with trace requests > from any individual presenting legitimate credentials as the assignee > of a particular source address and presenting with reasonable evidence > that packets with a spoofed address cross a specifically identified > system owned by the transit network. Where the packet stream > continues, these trace requests must promptly result in identification > of the actual source of the packet (if within the transit network's > system) or the identification of the neighboring system, the specific > entry point and high-level contacts within the neighbor system capable > of continuing the trace. Assuming they pass the packets at all, which is what I'm trying to prevent, myself. Surely, special case handling will need to be done for customers who are multihomed, and may originate packets from connection A out connection B, but *this is the layer* where that must be done; you can't do it any closer to the backbone, since the necessary administrative knowledge isn't available there. > 4. Applying the IDP _does not_ mean you cut off the network. That'll > piss of your customers as much or more than it pisses off theirs. The > position is untenable. Instead, the IDP consists of redirecting the > offender's public presence web sites to a web site which proclaims the > IDP, lists the causes of the IDP and lists the actions required to > lift the IDP. Unless I misunderstand you there, you're suggesting that inbound HTTP to public websites *operated by the spoofing entity* should be redirected to a site that shames them? Yeah, that will piss them off less... :-) > 5. IDP can't be a local decision. We should elect or empanel or > otherwise select a group of individuals who decide both when a network > gets the IDP and when the IDP is lifted. Compliance with the group's > decision to impose an IDP can be optional but a riot of RBLs like have > developed in the anti-spam community would cause at least as much > trouble as it fixes. > > Do the engineering heads at the top 10 tier-1/2 carriers carry > > enough water > > to make that sale to the CEOs? > > To ask the CEOs to authorize cutting off access to a competitor's web > site with the full support and approval of a group of recognized > Internet luminaries? The problem with that sub-approach is that luminaries (of the scale that everyone will automatically listen to them), as Jon Postel has said, do not scale. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bmanning at vacation.karoshi.com Tue Mar 26 20:43:27 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 26 Mar 2013 20:43:27 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <43218.1364310365@turing-police.cc.vt.edu> <00BDF355-868A-4B6B-9E96-3CECFC1E7A15@gmail.com> Message-ID: <20130326204327.GE905@vacation.karoshi.com.> but they are paying attention.... /bill On Tue, Mar 26, 2013 at 09:25:09AM -0700, Jared Mauch wrote: > I'm not sure you want this regulated. > > Jared Mauch > > On Mar 26, 2013, at 9:20 AM, Mikael Abrahamsson wrote: > > > Can't we get homeland security into this? Threat to US national security if people can spoof? :P > From mpetach at netflight.com Tue Mar 26 21:16:30 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 26 Mar 2013 14:16:30 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 10:01 AM, William Herrin wrote: > On Tue, Mar 26, 2013 at 10:51 AM, Jay Ashworth wrote: ... >> Do the engineering heads at the top 10 tier-1/2 carriers carry enough water >> to make that sale to the CEOs? > > To ask the CEOs to authorize cutting off access to a competitor's web > site with the full support and approval of a group of recognized > Internet luminaries? I'm not a lawyer, but I do work out with one at the gym. I would strongly encourage people considering this to discuss the following terms with their legal staff *first*: Sherman Anti-Trust Act Anti-competitive practice Refusal to deal restraint of trade collusion cartel Once you've had a polite and cheerful discussion about the feasibility of some set of companies in the public space banding together to restrict access to a subset of their competitors with your legal staff, we can go back to discussing how best to configure our routers. Thanks! Matt From josh at zevlag.com Tue Mar 26 22:04:37 2013 From: josh at zevlag.com (Josh Galvez) Date: Tue, 26 Mar 2013 16:04:37 -0600 Subject: frontiernet.net Email Server Admin Message-ID: Can someone who administers frontiernet.net email servers please contact me off list? Your bounce message does not indicate why our "access to submit messages to this e-mail system has been rejected" Thanks. From george.herbert at gmail.com Tue Mar 26 22:14:10 2013 From: george.herbert at gmail.com (George Herbert) Date: Tue, 26 Mar 2013 15:14:10 -0700 Subject: glass fiber @ 0.997 c In-Reply-To: <20130326163642.GL6172@leitl.org> References: <20130326163642.GL6172@leitl.org> Message-ID: On Tue, Mar 26, 2013 at 9:36 AM, Eugen Leitl wrote: > > http://www.newscientist.com/article/dn23309-information-superhighway-approaches-light-speed.html > > Information superhighway approaches light speed > > 18:00 24 March 2013 by Jacob Aron Nothing moves faster than light in a > vacuum, but large volumes of data can now travel at 99.7 per cent of this > ultimate speed limit. Now I guess we find out exactly how much the various financial firms are willing to pay to shave 0.3 of C off travel time from London to NYC... -- -george william herbert george.herbert at gmail.com From bill at herrin.us Tue Mar 26 22:36:32 2013 From: bill at herrin.us (William Herrin) Date: Tue, 26 Mar 2013 18:36:32 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20877487.11064.1364328563175.JavaMail.root@benjamin.baylink.com> References: <20877487.11064.1364328563175.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 4:09 PM, Jay Ashworth wrote: >> From: "William Herrin" >> 1. The general IDP does not apply to stub networks which do not speak >> BGP. It is for those stubs' ISPs to determine how they'll handle >> mis-sourced traffic they receive from those networks. > > So, here, you mean customers of such as "Road Runner Business", who > have an office full of workstations and maybe some servers. Correct. > The goal, unless I badly misunderstood it, was to *drop forged traffic > coming from this sort of source (assuming you generalize "my PC at > home on a cablemodem" as the limiting example of this class, which I > do). Indeed. But it isn't achievable. $Random_SOHO will continue to be hacked on a regular basis. He doesn't have someone working for him with the skill to prevent it. Further victimizing him with a game of whack-a-mole helps nobody. Besides, his failings aren't important to us. What's important to us is that his failings don't impact us. We achieve that by insisting that his ISP not leak his forged packets on to the public Internet. It would be nice if his ISP didn't accept the forged packets at all, but that's really not our problem and we don't need to make it our business. >> 2. A BGP origin-only network is required to secure its BGP-speaking >> borders against source address spoofing. It may also secure spoofing >> from downstream networks (and in fact it SHOULD do so) but it avoids >> the IDP so long as its BGP-speaking borders are secured. > > This is the next size up of edge network; a buyer of transit. > > This item does no good; you're expecting *the potential bad actor* > *not to act badly*. At last count there are fewer than 45,000 such systems worldwide, not millions upon millions like in group 1. This is a manageable number of potential bad actors to whom the IDP would apply. Also, we're not looking to catch bad actors here. We're looking to catch sloppy actors. We catch bad actors at step 3 by spanking their upstream transit ISPs for failing to prevent source spoofing. >> 3. A BGP transit network is required to secure all components of its >> network against source address spoofing, including all non-BGP stub >> customers and all origin-only BGP customers. It is not expected to >> prevent spoofed packets from arriving from neighboring transit BGP >> networks. > > *This* is Road Runner. Also Comcast, Mindspring, and the other Top 40 > eyeball networks. It is also, of course, larger carriers who sell access > in addition to more traditional transit and possibly peering. Correct. > AFAICT, this is the spot where source-address-spoofing needs to be > *enforced*; Unfortunately, it's also the spot where system complexity reaches a point where as a purely technical matter, source address filtering isn't always possible. You can filter your customers based on the routes they say they plan send you and you can filter your own internal networks based on the addresses you assign but filtering your peers for falsely sourced packets can be as intractable as filtering your upstream for falsely sourced packets. Hence the additional expectations... >> It is also expected to promptly assist (24/7/365) with trace requests >> from any individual presenting legitimate credentials as the assignee >> of a particular source address and presenting with reasonable evidence >> that packets with a spoofed address cross a specifically identified >> system owned by the transit network. Where the packet stream >> continues, these trace requests must promptly result in identification >> of the actual source of the packet (if within the transit network's >> system) or the identification of the neighboring system, the specific >> entry point and high-level contacts within the neighbor system capable >> of continuing the trace. >> 4. Applying the IDP _does not_ mean you cut off the network. That'll >> piss of your customers as much or more than it pisses off theirs. The >> position is untenable. Instead, the IDP consists of redirecting the >> offender's public presence web sites to a web site which proclaims the >> IDP, lists the causes of the IDP and lists the actions required to >> lift the IDP. > > Unless I misunderstand you there, you're suggesting that inbound HTTP to > public websites *operated by the spoofing entity* should be redirected > to a site that shames them? Yeah, that will piss them off less... :-) I don't care about about pissing them off. I care about pissing off my customers. My customers will be pissed off if they can't reach their customers and suppliers. Who will often be hosted by the target of the IDP. But will much more rarely be the target of the IDP. >> To ask the CEOs to authorize cutting off access to a competitor's web >> site with the full support and approval of a group of recognized >> Internet luminaries? > > The problem with that sub-approach is that luminaries (of the scale that > everyone will automatically listen to them), as Jon Postel has said, do > not scale. Which is A-OK because if we're applying more than 1 or 2 IDPs in a year to folks who weren't intentionally bad actors then we're doing it wrong. It shouldn't ever "scale." -- 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 Tue Mar 26 22:53:00 2013 From: bill at herrin.us (William Herrin) Date: Tue, 26 Mar 2013 18:53:00 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 5:16 PM, Matthew Petach wrote: > On Tue, Mar 26, 2013 at 10:01 AM, William Herrin wrote: >> To ask the CEOs to authorize cutting off access to a competitor's web >> site with the full support and approval of a group of recognized >> Internet luminaries? > > Once you've had a polite and cheerful discussion about > the feasibility of some set of companies in the public > space banding together to restrict access to a subset > of their competitors with your legal staff, we can > go back to discussing how best to configure our > routers. This has already been tested vis a vis the anti-spam RBLs. There are no new concepts here to challenge a court. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ahebert at pubnix.net Tue Mar 26 23:04:19 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 26 Mar 2013 19:04:19 -0400 Subject: Open Resolver Problems In-Reply-To: <5151C0EC.7000008@foobar.org> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> <5151C0EC.7000008@foobar.org> Message-ID: <51522973.9010901@pubnix.net> Well, On 03/26/13 11:38, Nick Hilliard wrote: > On 26/03/2013 15:06, Alain Hebert wrote: >> And why not targeting all that animosity to the peers allowing >> source IP spoofing? > I do - and I gave a bunch of talks in europistan over the last 12 months > which included explicit encouragement, practice and configuration for > implementing BCP38 as part of real-time black hole system deployment. > >> DNS Servers don't attack you, people letting their customers spoof >> source IP do. > DNS amp packets attack me. Please stop them from leaving your network, and > I will both implement BCP38 and encourage others to do so. Thank you. > > Nick We're on it here... Been using the work of http://bindguard.activezone.de/ to watch it =D There is a lot of targets... kinda hard to figure out the goal... ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From marka at isc.org Wed Mar 27 01:01:25 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 12:01:25 +1100 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Tue, 26 Mar 2013 14:16:30 PDT." References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: <20130327010126.39F7D319628F@drugs.dv.isc.org> If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity. We are all experts in the field and the courts apply higher standards to us than they do to Joe Blogs. We know machines get compromised. We know how to block spoofed traffic from compromised machines. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From johnl at iecc.com Wed Mar 27 01:06:12 2013 From: johnl at iecc.com (John Levine) Date: 27 Mar 2013 01:06:12 -0000 Subject: Open Resolver Problems In-Reply-To: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> Message-ID: <20130327010612.34231.qmail@joyce.lan> >As a white-hat attempting to find problems to address through legitimate means, how >do you ? You make friends with people with busy authoritative servers and see who's querying them. I suppose you could justify one probe per client and see if they appear to be open. R's, John From jra at baylink.com Wed Mar 27 01:18:53 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 21:18:53 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: Message-ID: <31522812.11076.1364347133485.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > > So, here, you mean customers of such as "Road Runner Business", who > > have an office full of workstations and maybe some servers. > > Correct. > > > The goal, unless I badly misunderstood it, was to *drop forged traffic > > coming from this sort of source (assuming you generalize "my PC at > > home on a cablemodem" as the limiting example of this class, which I > > do). > > Indeed. But it isn't achievable. $Random_SOHO will continue to be > hacked on a regular basis. He doesn't have someone working for him > with the skill to prevent it. Further victimizing him with a game of > whack-a-mole helps nobody. > > Besides, his failings aren't important to us. What's important to us > is that his failings don't impact us. We achieve that by insisting > that his ISP not leak his forged packets on to the public Internet. It > would be nice if his ISP didn't accept the forged packets at all, but > that's really not our problem and we don't need to make it our > business. It's possible I badly misunderstand how things like unicast-rpf work, Bill. I run much tinier networks than most people here. But what I *do* understand of it is: you have to run it *at the edge concentrator*, cause that's the only device which knows which packets to accept... since *it assigned the address for the link*. When I say "drop forged traffic coming from...", *who I mean is 'his ISP'*, as you suggest in the next graf. I don't see that there's anyway to *know* packets have a forged address anywhere north of the edge of the lowest tier IAP the connection is served from. Did I miss something? Or was I simply unclear? > >> 2. A BGP origin-only network is required to secure its BGP-speaking > >> borders against source address spoofing. It may also secure > >> spoofing > >> from downstream networks (and in fact it SHOULD do so) but it > >> avoids > >> the IDP so long as its BGP-speaking borders are secured. > > > > This is the next size up of edge network; a buyer of transit. > > > > This item does no good; you're expecting *the potential bad actor* > > *not to act badly*. > > At last count there are fewer than 45,000 such systems worldwide, not > millions upon millions like in group 1. This is a manageable number of > potential bad actors to whom the IDP would apply. Yes. These are the people to whom edge nodes and private non-BGP nets speak; the tier 3 4 and 5 network providers who run edge concentrators and assign addresses. > Also, we're not looking to catch bad actors here. We're looking to > catch sloppy actors. We catch bad actors at step 3 by spanking their > upstream transit ISPs for failing to prevent source spoofing. ...which you would detect ... how? *Those* aggregator networks have no contractual reason to know what's a valid address coming to them, unlike the networks to which end sites attach directly. > > *This* is Road Runner. Also Comcast, Mindspring, and the other Top 40 > > eyeball networks. It is also, of course, larger carriers who sell access > > in addition to more traditional transit and possibly peering. > > Correct. > > > AFAICT, this is the spot where source-address-spoofing needs to be > > *enforced*; > > Unfortunately, it's also the spot where system complexity reaches a > point where as a purely technical matter, source address filtering > isn't always possible. You can filter your customers based on the > routes they say they plan send you and you can filter your own > internal networks based on the addresses you assign but filtering your > peers for falsely sourced packets can be as intractable as filtering > your upstream for falsely sourced packets. I don't believe that's what I said. Filtering based on routes doesn't help; that's *destination address*, not source, no? Yes, filtering your peers, or even transit customers, is effectively impossible; it has to be done where addresses are handed out. > >> 4. Applying the IDP _does not_ mean you cut off the network. > >> That'll > >> piss of your customers as much or more than it pisses off theirs. > >> The > >> position is untenable. Instead, the IDP consists of redirecting the > >> offender's public presence web sites to a web site which proclaims > >> the > >> IDP, lists the causes of the IDP and lists the actions required to > >> lift the IDP. > > > > Unless I misunderstand you there, you're suggesting that inbound > > HTTP to > > public websites *operated by the spoofing entity* should be > > redirected > > to a site that shames them? Yeah, that will piss them off less... > > :-) > > I don't care about about pissing them off. I care about pissing off my > customers. My customers will be pissed off if they can't reach their > customers and suppliers. Who will often be hosted by the target of the > IDP. But will much more rarely be the target of the IDP. Ok; I apologies; I have laid the bike down in the sandy corner at this point. Huh? > >> To ask the CEOs to authorize cutting off access to a competitor's web > >> site with the full support and approval of a group of recognized > >> Internet luminaries? > > > > The problem with that sub-approach is that luminaries (of the scale that > > everyone will automatically listen to them), as Jon Postel has said, do > > not scale. > > Which is A-OK because if we're applying more than 1 or 2 IDPs in a > year to folks who weren't intentionally bad actors then we're doing it > wrong. It shouldn't ever "scale." Yes, but you can't measure such a panel on output, you have to measure it on *input*, no? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Mar 27 01:43:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 21:43:38 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327010126.39F7D319628F@drugs.dv.isc.org> Message-ID: <10071844.11080.1364348618832.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > If you are with a ISP that does not practice BCP 38 are you willing > to risk your neck that you won't be subject to a "aiding and abetting" > charge? All of us here know that spoofing address like this is a > criminal activity. We are all experts in the field and the courts > apply higher standards to us than they do to Joe Blogs. We know > machines get compromised. We know how to block spoofed traffic > from compromised machines. Careful: source address spoofing, like using a name you don't have on your driver license *is not inherently a crime*. *Fraudulent behaviour which is advanced thereby* makes it an additional crime. SAS is sometimes necessary for testing. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Mar 27 01:57:45 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 21:57:45 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: Message-ID: <14344477.11122.1364349465591.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Ferguson" > > Careful: source address spoofing, like using a name you don't have > > on your > > driver license *is not inherently a crime*. *Fraudulent behaviour > > which > > is advanced thereby* makes it an additional crime. > > > > SAS is sometimes necessary for testing. > > > > An argument could be made that "...fraud is fraud, is fraud, is > fraud..." and should vigorously discouraged. :-) Sure, Ferg. But my point was "be careful what you take as a proxy for fraud; some behaviors have valid uses". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Wed Mar 27 02:04:48 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 26 Mar 2013 19:04:48 -0700 Subject: Open Resolver Problems In-Reply-To: <20130327010612.34231.qmail@joyce.lan> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: >>As a white-hat attempting to find problems to address through legitimate means, how >>do you ? > > You make friends with people with busy authoritative servers and see > who's querying them. I'm confused. Don't most authoritative servers have to answer to just about anyone in order to be useful? Matt From tom at cloudflare.com Wed Mar 27 02:07:16 2013 From: tom at cloudflare.com (Tom Paseka) Date: Tue, 26 Mar 2013 19:07:16 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, Mar 26, 2013 at 7:04 PM, Matthew Petach wrote: > On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: > >>As a white-hat attempting to find problems to address through legitimate > means, how > >>do you ? > > > > You make friends with people with busy authoritative servers and see > > who's querying them. > > I'm confused. Don't most authoritative servers have to > answer to just about anyone in order to be useful? > > Matt > Authoritative DNS servers need to implement rate limiting. (a client shouldn't query you twice for the same thing within its TTL). From jared at puck.nether.net Wed Mar 27 02:13:43 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 19:13:43 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Mar 26, 2013, at 7:04 PM, Matthew Petach wrote: > On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: >>> As a white-hat attempting to find problems to address through legitimate means, how >>> do you ? >> >> You make friends with people with busy authoritative servers and see >> who's querying them. > > I'm confused. Don't most authoritative servers have to > answer to just about anyone in order to be useful? If you give the same answer 15x to the same person in a few seconds one can possibly infer they aren't a caching resolver or are broken. Either way you can think about ignoring them for a few with dampening or similar. From mpetach at netflight.com Wed Mar 27 02:14:08 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 26 Mar 2013 19:14:08 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, Mar 26, 2013 at 7:07 PM, Tom Paseka wrote: > On Tue, Mar 26, 2013 at 7:04 PM, Matthew Petach > wrote: >> >> On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: >> >>As a white-hat attempting to find problems to address through legitimate >> >> means, how >> >>do you ? >> > >> > You make friends with people with busy authoritative servers and see >> > who's querying them. >> >> I'm confused. Don't most authoritative servers have to >> answer to just about anyone in order to be useful? >> >> Matt > > > Authoritative DNS servers need to implement rate limiting. (a client > shouldn't query you twice for the same thing within its TTL). OK, but we started this discussion about open recursive resolvers, right? Securing your recursive resolvers is a very different problem space from trying to come up with rate limits for your authoritative nameservers. In terms of impacts people are feeling today, is most of the pain coming from open recursive servers being abused by miscreants, or from miscreants doing spoofed queries against authoritative nameservers? The concern Valdis raised about securing recursives while still being able to issue static nameserver IPs to mobile devices is an orthogonal problem to Owen putting rate limiters on the authoritative servers for he.net. If we're all lighting up pitchforks and raising torches, I'd kinda like to know at which castle we're going to go throw pitchforks. Matt From Valdis.Kletnieks at vt.edu Wed Mar 27 02:14:47 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 22:14:47 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Wed, 27 Mar 2013 12:01:25 +1100." <20130327010126.39F7D319628F@drugs.dv.isc.org> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <20130327010126.39F7D319628F@drugs.dv.isc.org> Message-ID: <8277.1364350487@turing-police.cc.vt.edu> On Wed, 27 Mar 2013 12:01:25 +1100, Mark Andrews said: > > If you are with a ISP that does not practice BCP 38 are you willing > to risk your neck that you won't be subject to a "aiding and abetting" > charge? All of us here know that spoofing address like this is a > criminal activity. So what you're saying is that every single person who ran the spoofing program to help the SAIL guys gather data is a criminal? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From marka at isc.org Wed Mar 27 02:21:54 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 13:21:54 +1100 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Tue, 26 Mar 2013 21:43:38 EDT." <10071844.11080.1364348618832.JavaMail.root@benjamin.baylink.com> References: <10071844.11080.1364348618832.JavaMail.root@benjamin.baylink.com> Message-ID: <20130327022154.D8EB131970F8@drugs.dv.isc.org> In message <10071844.11080.1364348618832.JavaMail.root at benjamin.baylink.com>, J ay Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > > If you are with a ISP that does not practice BCP 38 are you willing > > to risk your neck that you won't be subject to a "aiding and abetting" > > charge? All of us here know that spoofing address like this is a > > criminal activity. We are all experts in the field and the courts > > apply higher standards to us than they do to Joe Blogs. We know > > machines get compromised. We know how to block spoofed traffic > > from compromised machines. > > Careful: source address spoofing, like using a name you don't have on your > driver license *is not inherently a crime*. *Fraudulent behaviour which > is advanced thereby* makes it an additional crime. Which is why I said "like this" as this bundle of threads started with spoofing of DNS queries. > SAS is sometimes necessary for testing. Indeed. Those are exceptions not the rule. How many residential connections would be doing SAS for testing, compared to configuration errors or as the result on criminal misappropriation of equipement. When both configuration errors and spoofed traffic as the result of criminal misappropriation of equipement both should be dropped what are the courts likely to find? Even with SAS for testing you can filter based on MAC / port / link so only designated machines can send spoofed traffic. I certainly don't want to be the subject of a test case. Mark > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Valdis.Kletnieks at vt.edu Wed Mar 27 02:23:05 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Mar 2013 22:23:05 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Tue, 26 Mar 2013 19:13:43 -0700." References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <8698.1364350985@turing-police.cc.vt.edu> On Tue, 26 Mar 2013 19:13:43 -0700, Jared Mauch said: > If you give the same answer 15x to the same person in a few seconds one can > possibly infer they aren't a caching resolver or are broken. Either way you can > think about ignoring them for a few with dampening or similar. So what you're saying is that a decade after Duane Wessels presented at NANOG saying that 98% of the traffic hitting the root nameservers was total bull, we're not doing much better? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jlewis at lewis.org Wed Mar 27 02:25:32 2013 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 26 Mar 2013 22:25:32 -0400 (EDT) Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, 26 Mar 2013, Matthew Petach wrote: > The concern Valdis raised about securing recursives while still > being able to issue static nameserver IPs to mobile devices > is an orthogonal problem to Owen putting rate limiters on > the authoritative servers for he.net. If we're all lighting up > pitchforks and raising torches, I'd kinda like to know at which > castle we're going to go throw pitchforks. BCP38. As you can see from the wandering conversation, there are many attack vectors that hinge on the ability to spoof the source address, and thereby misdirect responses to your DDoS target. BCP38 filtering stops them all. Or, we can ignore BCP38 for several more years, go on a couple years crusade against open recursive resolvers, then against non-rate-limited authoratative servers, default public RO SNMP communities, etc. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marka at isc.org Wed Mar 27 02:27:55 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 13:27:55 +1100 Subject: Open Resolver Problems In-Reply-To: Your message of "Tue, 26 Mar 2013 19:07:16 PDT." References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <20130327022755.BB9333197311@drugs.dv.isc.org> In message , Tom Paseka writes: > On Tue, Mar 26, 2013 at 7:04 PM, Matthew Petach wrot= > e: > > > On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: > > >>As a white-hat attempting to find problems to address through legitimat= > e > > means, how > > >>do you =85 > > > > > > You make friends with people with busy authoritative servers and see > > > who's querying them. > > > > I'm confused. Don't most authoritative servers have to > > answer to just about anyone in order to be useful? > > > > Matt > > > > Authoritative DNS servers need to implement rate limiting. (a client > shouldn't query you twice for the same thing within its TTL). You are assuming that there is a recursive server making the queries and that there are not multiple recursive server behind a NAT. Neither of these assumptions in true in practice and with the deployment of CGNs these will become less true. I have two recursive server at home behind a NAT today. Both do DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sj_hznm at hotmail.com Wed Mar 27 02:34:02 2013 From: sj_hznm at hotmail.com (Joe) Date: Wed, 27 Mar 2013 02:34:02 +0000 Subject: Question on Ipv6 address In-Reply-To: <3F84AEBD-D4DA-4C50-ADE8-E4DBA75B58FF@delong.com> References: , <3F84AEBD-D4DA-4C50-ADE8-E4DBA75B58FF@delong.com> Message-ID: thanks for replies on the list, but still questions > > IPv6 is very different from IPv4. > > In IPv6, there should be a /64 assigned to the point to point link over which a /48 should be delegated to the customer. > > If the customer doesn't have a router and is just attaching a single PC, he will not make the Prefix Delegation request and just the point-to-point /64 will be adequate. > could we think about this as, in a PPPoE access network, /64 should be assigned to each access vlan, and /48 should be prepared to delegated to a customer who uses router to dials in with PPPoE link and have PCs connected to home router. In order to make full use of v6 address, could /56 be planned for delegated address? > > 2. In dial-up network, could each vlan's ipv6 link-id be planned with its vlan number? if so, IP v6 address confliction could be avoided when BAS is assigned a /64 or longer prefix. > > Why would you ever assign a longer prefix? > I'm not sure what you mean by "link-id", so I'm not sure what you are attempting to resolve here. I means the host part of Ipv6 address. In Ipv4 network , we could identify each PPPoE session by IP address on BAS. Each customer is assigned adifferent VLAN (Q-in-Q) After introducing IPv6, we need the same ability to identify each customer. as network prefix is assigned to PPPoE link,CPE's v6 address is composed by the prefix and interface part. Besides self-calculating IPv6 address by CPE, could weassign CPE special v6 address by a /128 prefix which is compose by a /64 prefix and a interface part driving from Q-in-Qvlan numbers? > > > 3. we are testing some BAS with IPv6 accessing, in radius accouting packets, there is IP-v6-prefix, Ip-v6-link-id, Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be calculated with above information? > > It probably can't. Why do you need to? we need to identify each customer in network. In ipv4 network, each PPPoE customer has a fixed ip address which will be reported radius server by Framed-ip_address attributes. In ipv6 environment, radius accouting packets also contains IP-v6-prefix ?Ip-v6-linkID (identify host part of v6 address) and Ip-v6-delegated-prefix attributes. to my understanding , if only a PC is connected to BAS, IP-v6-prefix + IP-v6-linkID could be used to identify PC's IPv6 address. while if a router is connected, BAS could only get delegated prefix and PC behind home router could not be identified? > > > 4. should it be necessary to plan different IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? > > There are multiple ways to structure this. > > If you put all of the customers into a common NBMA network, then you can use a single /64 prefix to number all of the link addresses from a given BAS to the customer sites. All of the CPE routers will use the same address on the BAS as their default gateway. > > If you put the customers into individual VLANs, then each VLAN should have a /64 prefix assigned to it. > > Beyond that, if the customer has a router, you should plan on having a /48 delegated prefix for each customer. for cutomer has a router, should we plan a /64 prefix for PPPoE link and a /48 (or /56) prefix delegeted to customers? After dials in , when a PC behind router access 6bone website. what address(or prefix) will be seen by web site it visits ? > > > 5. How could delegated IPv6 prefix be used in service provider's network? is this useful in dial-up access network? > > The delegated prefix isn't used in the service provider's network. It is delegated to the customer for them to number their network. It can be used by the customer regardless of attachment method, though the low speeds of dialup make a complex topology on the far side less likely. > best regards Joe From jared at puck.nether.net Wed Mar 27 02:37:32 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 26 Mar 2013 19:37:32 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <17B10118-8B65-4266-9126-AE73F1F289F2@puck.nether.net> Both. And BCP-38 as well. Lots of effort is needed in this space. Jared Mauch On Mar 26, 2013, at 7:14 PM, Matthew Petach wrote: > > In terms of impacts people are feeling today, is most of the pain > coming from open recursive servers being abused by miscreants, > or from miscreants doing spoofed queries against authoritative > nameservers? From marka at isc.org Wed Mar 27 02:40:55 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 13:40:55 +1100 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Tue, 26 Mar 2013 22:14:47 EDT." <8277.1364350487@turing-police.cc.vt.edu> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <20130327010126.39F7D319628F@drugs.dv.isc.org> <8277.1364350487@turing-police.cc.vt.edu> Message-ID: <20130327024055.B1DAF319753C@drugs.dv.isc.org> In message <8277.1364350487 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu w rites: > > On Wed, 27 Mar 2013 12:01:25 +1100, Mark Andrews said: > > > > If you are with a ISP that does not practice BCP 38 are you willing > > to risk your neck that you won't be subject to a "aiding and abetting" > > charge? All of us here know that spoofing address like this is a > > criminal activity. > > So what you're saying is that every single person who ran the spoofing > program to help the SAIL guys gather data is a criminal? See my response to Jay. I did not present this as a absolute. Surveying which connections are open to address spoofing may or may not be a criminal activity. It all depends on intent of the person gathering the data. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Wed Mar 27 02:50:20 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 13:50:20 +1100 Subject: Open Resolver Problems In-Reply-To: Your message of "Tue, 26 Mar 2013 19:14:08 PDT." References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <20130327025020.CF46B31976B0@drugs.dv.isc.org> In message , Matthew Petach writes: > In terms of impacts people are feeling today, is most of the pain > coming from open recursive servers being abused by miscreants, > or from miscreants doing spoofed queries against authoritative > nameservers? Both are currently being abused. Rate limiting itself causes operational problems for legitimate users of authoritative servers and will only have a limited effect for a limited time. It is a stop gap measure. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Wed Mar 27 02:51:35 2013 From: joelja at bogus.com (joel jaeggli) Date: Tue, 26 Mar 2013 19:51:35 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <51525EB7.7010300@bogus.com> On 3/26/13 7:04 PM, Matthew Petach wrote: > On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: >>> As a white-hat attempting to find problems to address through legitimate means, how >>> do you ? >> You make friends with people with busy authoritative servers and see >> who's querying them. > I'm confused. Don't most authoritative servers have to > answer to just about anyone in order to be useful? yes, and that's why they're useful for tracking who has a resolver. >Matt From paigeadele at gmail.com Wed Mar 27 03:09:06 2013 From: paigeadele at gmail.com (Adele Thompson) Date: Tue, 26 Mar 2013 20:09:06 -0700 Subject: glass fiber @ 0.997 c In-Reply-To: <20130326163642.GL6172@leitl.org> References: <20130326163642.GL6172@leitl.org> Message-ID: Jacob Aron Nothing is a bro, I can't wait to try this myself. On Tue, Mar 26, 2013 at 9:36 AM, Eugen Leitl wrote: > > > http://www.newscientist.com/article/dn23309-information-superhighway-approaches-light-speed.html > > Information superhighway approaches light speed > > 18:00 24 March 2013 by Jacob Aron Nothing moves faster than light in a > vacuum, but large volumes of data can now travel at 99.7 per cent of this > ultimate speed limit. > > In glass optical fibres, light travels 31 per cent slower than in a vacuum. > Hollowing them out so that most of the light travels through air speeds > things up. But these hollow fibres are a poor replacement as light scatters > at the glass-air interface, limiting the number of wavelengths, and > therefore > the volume of data, transmitted at once. > > Now Francesco Poletti and colleagues at the University of Southampton, UK, > have made fibres with an ultra-thin glass rim, enabling a much wider band > of > wavelengths to travel at high speed at once. The team's record is a 73.7 > terabit per second transmission over 310?metres, a 15,000-fold increase > over > ordinary hollow fibres. > > "Previous fibres either have higher bandwidth but high loss, or lower loss > but narrower bandwidth," says Poletti. "We've achieved both in the same > fibre." > > Journal reference: Nature Photonics, DOI: 10.1038/nphoton.2013.45 > > > http://www.nature.com/nphoton/journal/vaop/ncurrent/full/nphoton.2013.45.html > > Towards high-capacity fibre-optic communications at the speed of light in > vacuum > > F. Poletti, N. V. Wheeler, M. N. Petrovich, N. Baddela, E. > Numkam Fokoua, J. R. Hayes, D. R. Gray, Z. Li, R. Slav?k & > D. > J. Richardson Nature Photonics (2013) doi:10.1038/nphoton.2013.45 > > Received 13 September 2012 Accepted 08 February 2013 Published online 24 > March 2013 > > Abstract > > Wide-bandwidth signal transmission with low latency is emerging as a key > requirement in a number of applications, including the development of > future > exaflop-scale supercomputers, financial algorithmic trading and cloud > computing1, 2, 3. Optical fibres provide unsurpassed transmission > bandwidth, > but light propagates 31% slower in a silica glass fibre than in vacuum, > thus > compromising latency. Air guidance in hollow-core fibres can reduce fibre > latency very significantly. However, state-of-the-art technology cannot > achieve the combined values of loss, bandwidth and mode-coupling > characteristics required for high-capacity data transmission. Here, we > report > a fundamentally improved hollow-core photonic-bandgap fibre that provides a > record combination of low loss (3.5 dB km?1) and wide bandwidth (160 nm), > and > use it to transmit 37 ? 40 Gbit s?1 channels at a 1.54 ?s km?1 faster speed > than in a conventional fibre. This represents the first experimental > demonstration of fibre-based wavelength division multiplexed data > transmission at close to (99.7%) the speed of light in vacuum. > > From jra at baylink.com Wed Mar 27 03:10:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Mar 2013 23:10:38 -0400 (EDT) Subject: Open Resolver Problems In-Reply-To: Message-ID: <17088355.11124.1364353838442.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Petach" > > You make friends with people with busy authoritative servers and see > > who's querying them. > > I'm confused. Don't most authoritative servers have to > answer to just about anyone in order to be useful? Yes. And that list will contain lots of recursive servers. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From steve.hillier at cira.ca Tue Mar 26 15:13:17 2013 From: steve.hillier at cira.ca (Steve Hillier) Date: Tue, 26 Mar 2013 11:13:17 -0400 Subject: Open Resolver Problems In-Reply-To: <5151B4A8.7040009@foobar.org> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> Message-ID: On 26/03/2013 14:43, Patrick W. Gilmore wrote: >> For the other 99.99999999% of you, LOCK THAT SHIT DOWN. > amen, brother! +1 From fergdawgster at gmail.com Wed Mar 27 01:54:28 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 26 Mar 2013 18:54:28 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: <10071844.11080.1364348618832.JavaMail.root@benjamin.baylink.com> References: <20130327010126.39F7D319628F@drugs.dv.isc.org> <10071844.11080.1364348618832.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 6:43 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Mark Andrews" > >> If you are with a ISP that does not practice BCP 38 are you willing >> to risk your neck that you won't be subject to a "aiding and abetting" >> charge? All of us here know that spoofing address like this is a >> criminal activity. We are all experts in the field and the courts >> apply higher standards to us than they do to Joe Blogs. We know >> machines get compromised. We know how to block spoofed traffic >> from compromised machines. > > Careful: source address spoofing, like using a name you don't have on your > driver license *is not inherently a crime*. *Fraudulent behaviour which > is advanced thereby* makes it an additional crime. > > SAS is sometimes necessary for testing. > An argument could be made that "...fraud is fraud, is fraud, is fraud..." and should vigorously discouraged. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From fergdawgster at gmail.com Wed Mar 27 02:23:11 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 26 Mar 2013 19:23:11 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, Mar 26, 2013 at 7:14 PM, Matthew Petach wrote: > > The concern Valdis raised about securing recursives while still > being able to issue static nameserver IPs to mobile devices > is an orthogonal problem to Owen putting rate limiters on > the authoritative servers for he.net. If we're all lighting up > pitchforks and raising torches, I'd kinda like to know at which > castle we're going to go throw pitchforks. > Open Recursive DNS Resolvers. The need to start seriously addressing this issue is kind of dire. The problem with DNS Amplification attacks is getting worse, not better. Oh yeah... and BCP38, too. :-) They both kind of go hand-in-hand. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From fergdawgster at gmail.com Wed Mar 27 02:37:05 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 26 Mar 2013 19:37:05 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, Mar 26, 2013 at 7:25 PM, Jon Lewis wrote: > On Tue, 26 Mar 2013, Matthew Petach wrote: > >> The concern Valdis raised about securing recursives while still >> being able to issue static nameserver IPs to mobile devices >> is an orthogonal problem to Owen putting rate limiters on >> the authoritative servers for he.net. If we're all lighting up >> pitchforks and raising torches, I'd kinda like to know at which >> castle we're going to go throw pitchforks. > > > BCP38. As you can see from the wandering conversation, there are many > attack vectors that hinge on the ability to spoof the source address, and > thereby misdirect responses to your DDoS target. BCP38 filtering stops them > all. Or, we can ignore BCP38 for several more years, go on a couple years > crusade against open recursive resolvers, then against non-rate-limited > authoratative servers, default public RO SNMP communities, etc. > And I don't plan on being around doing this sort of work in another 10+ years, so let's stop farting around. :-p - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From frnkblk at iname.com Wed Mar 27 04:45:53 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Tue, 26 Mar 2013 23:45:53 -0500 Subject: Question on Ipv6 address In-Reply-To: <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9@ex02mail01.ad.rit.edu> References: <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9@ex02mail01.ad.rit.edu> Message-ID: <005c01ce2aa5$f9ed6c20$edc84460$@iname.com> My understanding is that because IPv6 has a minimum MTU of 1280 and dial-up maxes out at 576, that special measures must be taken for IPv6 to work over a dial-up connection. Please correct me if someone has this working out of the box. Frank -----Original Message----- From: Mark Jeremy [mailto:mejndp at rit.edu] Sent: Tuesday, March 26, 2013 2:10 PM To: Justin Wilson Cc: nanog at nanog.org Subject: RE: Question on Ipv6 address Justin, Dial-up modem is just a layer 2 device with no IP address. Just think of it as a converter, its sole function is to convert the telephone line to something your PC can use, in this case, Ethernet. Both IPv4 and IPv6 operate on the layer 3 of the OSI model which is taken care of by the RAS. So basically any dial-up modem support IPv6. -MJ -----Original Message----- From: Justin Wilson [mailto:lists at mtin.net] Sent: Tuesday, March 26, 2013 12:06 PM To: NANOG Subject: Re: Question on Ipv6 address I don't mean to hijack the thread so if someone wants to open a new one that?s cool. But my question is what dial-up hardware supports v6? I am *assuming* Cisco does. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.zigwireless.com ? High Speed Internet Options http://www.thebrotherswisp.com ? The Brothers Wisp -----Original Message----- From: Joe Date: Tuesday, March 26, 2013 11:39 AM To: NANOG Subject: Question on Ipv6 address >I'm new to Ipv6 and trying to understanding something about IPv6 in >service provider network. >I've got the following questions , could anybody do some helps? >1. In a dial-up network (Q-in-Q for each customer who dials in ) Should >each customer be assigned to ipv6 subnet prefix like /64 unique >universily? I've read a rfc which stated point-to-point like should be >assigned /64. But to my understanding, in dial-up network , each user >should only needed to be assigned a single ipv4 address, with wich >customer could used in his PC or his home router. >2. In dial-up network, could each vlan's ipv6 link-id be planned with >its vlan number? if so, IP v6 address confliction could be avoided >when BAS is assigned a /64 or longer prefix. >3. we are testing some BAS with IPv6 accessing, in radius accouting >packets, there is IP-v6-prefix, Ip-v6-link-id, >Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be >calculated with above information? >4. should it be necessary to plan different >IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in BAS? >5. How could delegated IPv6 prefix be used in service provider's network? >is this useful in dial-up access network? > >each word will be highly appreciated. >Joe > From marka at isc.org Wed Mar 27 05:01:43 2013 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Mar 2013 16:01:43 +1100 Subject: Question on Ipv6 address In-Reply-To: Your message of "Tue, 26 Mar 2013 23:45:53 CDT." <005c01ce2aa5$f9ed6c20$edc84460$@iname.com> References: <8E071111C7D8154CA69338DDF94ACF99E9F6958FF9@ex02mail01.ad.rit.edu> <005c01ce2aa5$f9ed6c20$edc84460$@iname.com> Message-ID: <20130327050143.942BC31983D7@drugs.dv.isc.org> In message <005c01ce2aa5$f9ed6c20$edc84460$@iname.com>, "Frank Bulk \(iname.com \)" writes: > My understanding is that because IPv6 has a minimum MTU of 1280 and > dial-up maxes out at 576, that special measures must be taken for IPv6 > to work over a dial-up connection. > > Please correct me if someone has this working out of the box. > > Frank The defaults depend apon the framing protocol. PPP defaults to 1500 SLIP defaults to 1006 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kmedcalf at dessus.com Wed Mar 27 05:40:42 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 26 Mar 2013 23:40:42 -0600 Subject: Question on Ipv6 address In-Reply-To: Message-ID: <32ae6bcd8fa57a44812b5c6cd25f0924@mail.dessus.com> The "default" mtu of 576 is because, well, 2400 baud signaling is pretty darn slow and interactive performance (or any kind of multileaving of more than a single connection packet stream) is, what do we call it, laggy. Sort of like trying to telnet while doing a bulk transfer if you have bloated buffers, and do not use a decent QoS scheduler -- only with echo times in the order of seconds per character. I believe LCP uses a signed two-octet integer for frame size negotiation, so you can negotiate quite large frames if you so desire and so configure your endpoints. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > > > -----Original Message----- > > From: Frank Bulk (iname.com) [mailto:frnkblk at iname.com] > > Sent: Tuesday, 26 March, 2013 22:46 > > To: 'Mark Jeremy'; Justin Wilson > > Cc: nanog at nanog.org > > Subject: RE: Question on Ipv6 address > > > > My understanding is that because IPv6 has a minimum MTU of 1280 and > dial- > > up > > maxes out at 576, that special measures must be taken for IPv6 to work > > over > > a dial-up connection. > > > > Please correct me if someone has this working out of the box. > > > > Frank > > > > -----Original Message----- > > From: Mark Jeremy [mailto:mejndp at rit.edu] > > Sent: Tuesday, March 26, 2013 2:10 PM > > To: Justin Wilson > > Cc: nanog at nanog.org > > Subject: RE: Question on Ipv6 address > > > > Justin, > > > > Dial-up modem is just a layer 2 device with no IP address. Just think of > > it > > as a converter, its sole function is to convert the telephone line to > > something your PC can use, in this case, Ethernet. Both IPv4 and IPv6 > > operate on the layer 3 of the OSI model which is taken care of by the > RAS. > > So basically any dial-up modem support IPv6. > > > > -MJ > > > > -----Original Message----- > > From: Justin Wilson [mailto:lists at mtin.net] > > Sent: Tuesday, March 26, 2013 12:06 PM > > To: NANOG > > Subject: Re: Question on Ipv6 address > > > > I don't mean to hijack the thread so if someone wants to open a new one > > that?s cool. But my question is what dial-up hardware supports v6? I am > > *assuming* Cisco does. > > > > > > Justin > > > > -- > > Justin Wilson > > Aol & Yahoo IM: j2sw > > http://www.mtin.net/blog ? xISP News > > http://www.zigwireless.com ? High Speed Internet Options > > http://www.thebrotherswisp.com ? The Brothers Wisp > > > > > > > > -----Original Message----- > > From: Joe > > Date: Tuesday, March 26, 2013 11:39 AM > > To: NANOG > > Subject: Question on Ipv6 address > > > > >I'm new to Ipv6 and trying to understanding something about IPv6 in > > >service provider network. > > >I've got the following questions , could anybody do some helps? > > >1. In a dial-up network (Q-in-Q for each customer who dials in ) Should > > >each customer be assigned to ipv6 subnet prefix like /64 unique > > >universily? I've read a rfc which stated point-to-point like should > be > > >assigned /64. But to my understanding, in dial-up network , each user > > >should only needed to be assigned a single ipv4 address, with wich > > >customer could used in his PC or his home router. > > >2. In dial-up network, could each vlan's ipv6 link-id be planned with > > >its vlan number? if so, IP v6 address confliction could be avoided > > >when BAS is assigned a /64 or longer prefix. > > >3. we are testing some BAS with IPv6 accessing, in radius accouting > > >packets, there is IP-v6-prefix, Ip-v6-link-id, > > >Ip-v6-delegated-prefix. how could dial-up PC's IPv6 address be > > >calculated with above information? > > >4. should it be necessary to plan different > > >IP-v6-prefix(IP-v6-delegated-prefix) for each dial-up customers in > BAS? > > >5. How could delegated IPv6 prefix be used in service provider's > network? > > >is this useful in dial-up access network? > > > > > >each word will be highly appreciated. > > >Joe > > > > > > > > > > > From nick at foobar.org Wed Mar 27 11:20:54 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Mar 2013 11:20:54 +0000 Subject: Open Resolver Problems In-Reply-To: <40638.1364307677@turing-police.cc.vt.edu> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> <40638.1364307677@turing-police.cc.vt.edu> Message-ID: <5152D616.2060200@foobar.org> On 26/03/2013 14:21, Valdis.Kletnieks at vt.edu wrote: > And if you get a recursive lookup for www.ebay.com from a hotel network, I'm struggling to understand why it's necessary to hard-code dns servers into the ip networking configuration of a portable device. By definition, these devices will already have dhcp enabled. Nick From jcurran at arin.net Wed Mar 27 12:05:38 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 12:05:38 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA493AD@CHAXCH01.corp.arin.net> On Mar 26, 2013, at 10:51 AM, Jay Ashworth wrote: > The problem here is, of course, one of externalities and the Common Good, > hard sales to make in a business environment. "Common Good" situations are readily dealt with, but generally not on a voluntary basis. You establish how the resource is to be managed, and then you put in place mechanisms to deal with enforcement. The problem is that en-force-ment contains "force", which is something that we really don't want anyone (or set of anyones) using except "governments" (which in our social constructs are the only ones supposed to be telling one party under penalty of force not to do something otherwise in its best interest.) The problem, of course, with asking governments for help is that the output often does not resemble anything related to the original problem statement and can make the situation worse... If you setup an economic system where folks do the right thing because it is in their own interest, that's one option that doesn't involve government, but we know that is hard to do on technical grounds alone... A group of commercial entities that work together to setup a system which strongly encourages others to follow particular practices does indeed need to worry about Matt Petach's list of statutes, and exercise extreme care in its processes less the result be more about some form of market control and less about common good management. Net result is that management of a common good without some form of government involvement quickly gets quite challenging. If we had truly global operational best practices for the Internet (ones that went through a fairly well-defined policy development process which included multiple operator forums from around the globe) then you might have a solid chance of producing output which avoided the various anti- competitive aspects, and yet were a reasonable basis for governments to then step up and indicate should be required for ISPs in their operations. It wouldn't take very many governments asking "How do I reduce SPAM and DDoS attacks?" and hearing back "Please require ISPs to adhere to this Best Common Operating Practice Foo-01" before it became common practice. FYI, /John From ahebert at pubnix.net Wed Mar 27 12:19:06 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 27 Mar 2013 08:19:06 -0400 Subject: Open Resolver Problems In-Reply-To: <5152D616.2060200@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> <40638.1364307677@turing-police.cc.vt.edu> <5152D616.2060200@foobar.org> Message-ID: <5152E3BA.3040701@pubnix.net> Well, On 03/27/13 07:20, Nick Hilliard wrote: > On 26/03/2013 14:21, Valdis.Kletnieks at vt.edu wrote: >> And if you get a recursive lookup for www.ebay.com from a hotel network, > I'm struggling to understand why it's necessary to hard-code dns servers > into the ip networking configuration of a portable device. By definition, > these devices will already have dhcp enabled. > > Nick I can only talk as a very small outfit, too often our roaming/office customers have issues with their local DNS server (in embedded devices like their $60 linksys) or the local telco (ACME Cable Company)... Having them using our DNS servers save a lot of time and a massive amount of money and headache... same idea as offering them our outgoing mail server (with authentication of course) instead of letting them deal with their Telco's. Mind you none of my 2 servers are a problem because they where always rate-limited... But a few of my clients where for an amount around ~80Mbps of amps. And got fixed within the hour. Now about the struggling about BCP38... ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From ahebert at pubnix.net Wed Mar 27 12:20:05 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 27 Mar 2013 08:20:05 -0400 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <5152E3F5.30109@pubnix.net> Same ol' same ol' (at least since I started this around '93 =D) On 03/26/13 22:25, Jon Lewis wrote: > On Tue, 26 Mar 2013, Matthew Petach wrote: > >> The concern Valdis raised about securing recursives while still >> being able to issue static nameserver IPs to mobile devices >> is an orthogonal problem to Owen putting rate limiters on >> the authoritative servers for he.net. If we're all lighting up >> pitchforks and raising torches, I'd kinda like to know at which >> castle we're going to go throw pitchforks. > > BCP38. As you can see from the wandering conversation, there are many > attack vectors that hinge on the ability to spoof the source address, > and thereby misdirect responses to your DDoS target. BCP38 filtering > stops them all. Or, we can ignore BCP38 for several more years, go on > a couple years crusade against open recursive resolvers, then against > non-rate-limited authoratative servers, default public RO SNMP > communities, etc. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > IP Spoofing still exists because of lazy Peers... Same as the ability to hijack a subnet with BGP... ( *wave* DoD from 2-3 weeks ago ) But, as always, its our responsibility to kill our infrastructure, was IRC Servers in the past, now DNS Servers... Just for those lazy Peers to not HAVE to fix their broken setup. Same ol', same ol'. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From rsk at gsp.org Wed Mar 27 12:40:42 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 27 Mar 2013 08:40:42 -0400 Subject: Open Resolver Problems In-Reply-To: <5152D616.2060200@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> <40638.1364307677@turing-police.cc.vt.edu> <5152D616.2060200@foobar.org> Message-ID: <20130327124042.GA20146@gsp.org> On Wed, Mar 27, 2013 at 11:20:54AM +0000, Nick Hilliard wrote: > I'm struggling to understand why it's necessary to hard-code dns servers > into the ip networking configuration of a portable device. By definition, > these devices will already have dhcp enabled. It's necessary because many operations are screwing with DNS results in order to advance/suppress political agendas, impose their moral code via censorship, profit via redirection to search portals, etc. If we could actually trust that J. Random Hotel would not do so, then yes, whatever DNS servers are assigned via DHCP would suffice. (Let me caveat this by saying that I don't have a problem with screwing with DNS results for operational reasons, e.g., I think refusing to send DNS queries into DROP-listed space is a good security practice.) ---rsk From nick at foobar.org Wed Mar 27 12:47:46 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Mar 2013 12:47:46 +0000 Subject: Open Resolver Problems In-Reply-To: <20130327124042.GA20146@gsp.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> <40638.1364307677@turing-police.cc.vt.edu> <5152D616.2060200@foobar.org> <20130327124042.GA20146@gsp.org> Message-ID: <5152EA72.5030203@foobar.org> On 27/03/2013 12:40, Rich Kulawiec wrote: > It's necessary because many operations are screwing with DNS results in > order to advance/suppress political agendas, impose their moral code > via censorship, profit via redirection to search portals, etc. If we > could actually trust that J. Random Hotel would not do so, then yes, > whatever DNS servers are assigned via DHCP would suffice. then use a vpn and/or provide that service to your users. Sure, hotels and public access wifi does all sorts of stupid and obnoxious stuff, but the way to work around this is not by hardwiring your dns to some open resolver. Nick From thepacketmaster at hotmail.com Wed Mar 27 12:49:10 2013 From: thepacketmaster at hotmail.com (James Smith) Date: Wed, 27 Mar 2013 08:49:10 -0400 Subject: Line cut in Mediterranean? Message-ID: Getting reports from a third party vendor that there's been a line cut in the Mediterranean that is affecting some Internet traffic. Anyone have any details? From bill at herrin.us Wed Mar 27 12:57:26 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 08:57:26 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327024055.B1DAF319753C@drugs.dv.isc.org> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> <20130327010126.39F7D319628F@drugs.dv.isc.org> <8277.1364350487@turing-police.cc.vt.edu> <20130327024055.B1DAF319753C@drugs.dv.isc.org> Message-ID: On Tue, Mar 26, 2013 at 10:40 PM, Mark Andrews wrote: > Surveying which connections are open to address spoofing may or may > not be a criminal activity. It all depends on intent of the person > gathering the data. Such is the nature of law. When a dead body shows up shot, intent (fancily called "mens rea") is the difference between murder, manslaughter and self-defense. Its true of source address spoofing. Its true of collusion and anti-trust as well. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From petrus.lt at gmail.com Wed Mar 27 12:59:19 2013 From: petrus.lt at gmail.com (Pierre Emeriaud) Date: Wed, 27 Mar 2013 13:59:19 +0100 Subject: Line cut in Mediterranean? In-Reply-To: References: Message-ID: Hello James, 2013/3/27 James Smith : > > Getting reports from a third party vendor that there's been a line cut in the Mediterranean that is affecting some Internet traffic. Anyone have any details? > SMW4 : http://www.seacom.mu/news/article-140/seacom-outage-08-40-gmt/ "SEACOM can confirm that at 06:20 GMT 27 March, the SMW4 cable system suffered a cable cut off the coast of Egypt. Earlier this morning, SEACOM had restored all services on both SMW4 and IMEWE cable systems. SEACOM is currently in the process of prioritizing and reallocating already available capacity for customers and sourcing further capacity to re-establish full restoration. We will update further as information becomes available." regards, pierre. From nick at foobar.org Wed Mar 27 13:02:11 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Mar 2013 13:02:11 +0000 Subject: Line cut in Mediterranean? In-Reply-To: References: Message-ID: <5152EDD3.2090703@foobar.org> On 27/03/2013 12:49, James Smith wrote: > Getting reports from a third party vendor that there's been a line cut > in the Mediterranean that is affecting some Internet traffic. Anyone > have any details? smw4 is down, off the north coast of egypt: > http://www.itnewsafrica.com/2013/03/seacom-suffers-another-cable-disruption/ Nick From sthaug at nethelp.no Wed Mar 27 13:16:32 2013 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 27 Mar 2013 14:16:32 +0100 (CET) Subject: Line cut in Mediterranean? In-Reply-To: References: Message-ID: <20130327.141632.74710115.sthaug@nethelp.no> > Getting reports from a third party vendor that there's been a line cut in the Mediterranean that is affecting some Internet traffic. Anyone have any details? See the outages list: https://puck.nether.net/pipermail/outages/2013-March/005386.html Steinar Haug, Nethelp consulting, sthaug at nethelp.no From thepacketmaster at hotmail.com Wed Mar 27 13:20:09 2013 From: thepacketmaster at hotmail.com (James Smith) Date: Wed, 27 Mar 2013 09:20:09 -0400 Subject: Line cut in Mediterranean? In-Reply-To: References: Message-ID: Thanks for the quick responses, great information! > From: thepacketmaster at hotmail.com > To: nanog at nanog.org > Subject: Line cut in Mediterranean? > Date: Wed, 27 Mar 2013 08:49:10 -0400 > > > Getting reports from a third party vendor that there's been a line cut in the Mediterranean that is affecting some Internet traffic. Anyone have any details? > From ahebert at pubnix.net Wed Mar 27 13:23:47 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 27 Mar 2013 09:23:47 -0400 Subject: Open Resolver Problems In-Reply-To: <5152EA72.5030203@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> <40638.1364307677@turing-police.cc.vt.edu> <5152D616.2060200@foobar.org> <20130327124042.GA20146@gsp.org> <5152EA72.5030203@foobar.org> Message-ID: <5152F2E3.1020905@pubnix.net> Little bit of fun with http://bindguard.activezone.de/ This little example with an open resolver with only 200 queries a minute... The following list show the # of queries made followed by the query in question. False positive: 69.x.x.x 2 a1.mzstatic.com IN A + 2 a1001.phobos.apple.com IN A + 1153 a.root-servers.net IN A + ^- 1153 root queries under 10s... from a small office... Old uncontrolled botnet: 5.x.x.141 1020 isc.org IN ANY +ED 64.x.x.22 1440 isc.org IN ANY +ED 64.x.x.82 1075 isc.org IN ANY +ED 64.x.x.50 1011 isc.org IN ANY +ED 64.x.x.242 1103 isc.org IN ANY +ED This result come from my cheap scripts(tm) and bindguard. If anyone wish to try it I can provide you with some support files and examples. Just contact me offlist. PS: It will be later today... Enjoy today's drama. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From bill at herrin.us Wed Mar 27 13:37:15 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 09:37:15 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <31522812.11076.1364347133485.JavaMail.root@benjamin.baylink.com> References: <31522812.11076.1364347133485.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Mar 26, 2013 at 9:18 PM, Jay Ashworth wrote: >> From: "William Herrin" >> Indeed. But it isn't achievable. $Random_SOHO will continue to be >> hacked on a regular basis. He doesn't have someone working for him >> with the skill to prevent it. Further victimizing him with a game of >> whack-a-mole helps nobody. >> >> Besides, his failings aren't important to us. What's important to us >> is that his failings don't impact us. We achieve that by insisting >> that his ISP not leak his forged packets on to the public Internet. It >> would be nice if his ISP didn't accept the forged packets at all, but >> that's really not our problem and we don't need to make it our >> business. > > It's possible I badly misunderstand how things like unicast-rpf work, > Bill. No, you're pretty close. The technology known as unicast-rpf works anywhere there's a choke point where traffic to and from a given set of IP addresses has no other candidate paths. > When I say "drop forged traffic coming from...", *who I mean is 'his ISP'*, > as you suggest in the next graf. I don't see that there's anyway to *know* > packets have a forged address anywhere north of the edge of the lowest tier > IAP the connection is served from. RPF is but a subset of source address filtering strategies, the one where the source address filtering always mirrors the routing table. As a origin-only BGP AS, I know exactly what sources I expect to leave my system. And my ISPs know what source addresses I've told them to expect. RPF won't work reliably on those links, but they can be configured manually or with a tool to accept only the source addresses I've declared. If I declare 0.0.0.0/0, a reasonable ISP understands that I'm lying. If I declare a particular /24 and two days later the ISP gets a trace request from the apparent registrant (who isn't me) it's not hard to infer that I may be a bad actor. > Did I miss something? Or was I simply unclear? The problem with RPF is that understanding where you can and can't employ it is part of a senior network engineer's skill set. But the trivial network architectures where it can be applied are often handed off to a junior network engineer. The skill set is available primarily in the places where it can't be used. > ...which you would detect ... how? *Those* aggregator networks have > no contractual reason to know what's a valid address coming to them, > unlike the networks to which end sites attach directly. They most certainly do have a valid contractual reason to know what routes and source addresses their origin-only AS customer intends to send them and the responsible transit networks already do filter those links. > Filtering based on routes doesn't help; that's *destination address*, not > source, no? Except for the special case where RPF is usable, that's correct. > Yes, filtering your peers, or even transit customers, is effectively > impossible; it has to be done where addresses are handed out. Filtering that subset of your customers which consists of non-BGP speakers and BGP origin-only networks is neither impossible nor particularly hard. Harder than "rpf on", but not hard. Even if they lie about what addresses to expect, they're not left with carte blanche to impersonate any address at all. The more transit BGP systems which do this, the smaller the spoofing problem becomes. And there are few enough _transit_ BGP systems (less than 10,000) that they can be realistically and usefully held accountable for a failure to do so. >> I don't care about about pissing them off. I care about pissing off my >> customers. My customers will be pissed off if they can't reach their >> customers and suppliers. Who will often be hosted by the target of the >> IDP. But will much more rarely be the target of the IDP. > > Ok; I apologies; I have laid the bike down in the sandy corner at > this point. Huh? My leeway with the CEO ends when I lose customers. So does yours. For an IDP to be acceptable, the Penalty part has to be something painful to the offender without pissing off my customers. Cutting him off the network pisses off my customers who can no longer reach his customers. It's why no one wins a peering battle with Cogent: Cogent is willing to take the heat. Deep sixing the packets to his particular web site is far more tenable, especially when paired with an explanation of the credible threat he poses to my customers' networks. >> Which is A-OK because if we're applying more than 1 or 2 IDPs in a >> year to folks who weren't intentionally bad actors then we're doing it >> wrong. It shouldn't ever "scale." > > Yes, but you can't measure such a panel on output, you have to measure > it on *input*, no? Not particularly. There's nothing wrong with picking the worst current offenders and letting the rest slide with a warning to clean up their act or be next on the list. 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 Wed Mar 27 13:47:15 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 09:47:15 -0400 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka wrote: > Authoritative DNS servers need to implement rate limiting. (a client > shouldn't query you twice for the same thing within its TTL). Right now that's a complaint for the mainstream software authors, not for the system operators. When the version of Bind in Debian Stable implements this feature, I'll surely turn it on. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jabley at hopcount.ca Wed Mar 27 13:54:57 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 27 Mar 2013 09:54:57 -0400 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <74105DD6-7870-474F-A150-D55C494F5E9F@hopcount.ca> On 2013-03-27, at 09:47, William Herrin wrote: > On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka wrote: >> Authoritative DNS servers need to implement rate limiting. (a client >> shouldn't query you twice for the same thing within its TTL). > > Right now that's a complaint for the mainstream software authors, not > for the system operators. When the version of Bind in Debian Stable > implements this feature, I'll surely turn it on. RRL is a moving target, although a promising one. There are currently three implementations of RRL which all behave slightly differently. There is active discussion between the vendors who have implemented RRL, and between early adopters and the vendors. The specification is not yet stable, and changes in the functionality and the rate-limiting behaviour continue to be made. My assessment is that the implementations I have seen are ready for production use, but I think it's understandable given the moving goalpoasts that some vendors have not yet promoted the code to be included in stable releases. As an operator, I understand the benefits of using packaged, stable releases of code. However, we also have a responsibility to deal with operational problems in a timely way. I think it's worth considering that it may well be worth deviating from internal policies about code deployment in this instance; the benefits of doing so can be substantial, and the costs of doing so (especially if we expect them to be time-limited) are not that high. Joe From jared at puck.nether.net Wed Mar 27 13:56:57 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Mar 2013 09:56:57 -0400 Subject: Open Resolver Problems In-Reply-To: <5152EA72.5030203@foobar.org> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <24221.1364284290@turing-police.cc.vt.edu> <515158BD.4070906@foobar.org> <40638.1364307677@turing-police.cc.vt.edu> <5152D616.2060200@foobar.org> <20130327124042.GA20146@gsp.org> <5152EA72.5030203@foobar.org> Message-ID: On Mar 27, 2013, at 8:47 AM, Nick Hilliard wrote: > then use a vpn and/or provide that service to your users. Sure, hotels and > public access wifi does all sorts of stupid and obnoxious stuff, but the > way to work around this is not by hardwiring your dns to some open resolver. I've been in many a hotel where 4.2.2.1 is reachable with ttl=1 You must use a VPN or something else to get around places like that. The hotel I'm typing from right now is even more broken.. Jareds-MacBook-Air:~ jared$ ping 4.2.2.1 PING 4.2.2.1 (4.2.2.1): 56 data bytes 64 bytes from 4.2.2.1: icmp_seq=0 ttl=53 time=17.159 ms 64 bytes from 4.2.2.1: icmp_seq=0 ttl=53 time=17.181 ms (DUP!) 64 bytes from 4.2.2.1: icmp_seq=1 ttl=53 time=16.787 ms 64 bytes from 4.2.2.1: icmp_seq=1 ttl=53 time=17.156 ms (DUP!) 64 bytes from 4.2.2.1: icmp_seq=2 ttl=53 time=22.056 ms 64 bytes from 4.2.2.1: icmp_seq=2 ttl=53 time=22.081 ms (DUP!) ^C - Jared From jbates at brightok.net Wed Mar 27 14:00:05 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 09:00:05 -0500 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <5152FB65.9060309@brightok.net> On 3/27/2013 8:47 AM, William Herrin wrote: > On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka wrote: >> Authoritative DNS servers need to implement rate limiting. (a client >> shouldn't query you twice for the same thing within its TTL). > Right now that's a complaint for the mainstream software authors, not > for the system operators. When the version of Bind in Debian Stable > implements this feature, I'll surely turn it on. > > Tracking the clients would be a huge dataset and be especially complicated in clusters. They'd be better off at detecting actual attack vectors rather than rate limiting. However, there are enough nodes out there to easily spread a trickle to avoid individual detections. You don't want to DOS your amplifier, after all. It also wouldn't be hard to rotate through different requests to defeat the "rate limits". Jack From jra at baylink.com Wed Mar 27 14:23:03 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Mar 2013 10:23:03 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA493AD@CHAXCH01.corp.arin.net> Message-ID: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Curran" > On Mar 26, 2013, at 10:51 AM, Jay Ashworth wrote: > > The problem here is, of course, one of externalities and the Common > > Good, hard sales to make in a business environment. > > > "Common Good" situations are readily dealt with, but generally not on a > voluntary basis. You establish how the resource is to be managed, and > then you put in place mechanisms to deal with enforcement. The problem > is that en-force-ment contains "force", which is something that we > really don't want anyone (or set of anyones) using except "governments" > (which in our social constructs are the only ones supposed to be telling one > party under penalty of force not to do something otherwise in its best > interest.) Basically, though there are lots of other things that are close. > The problem, of course, with asking governments for help is that the > output often does not resemble anything related to the original problem > statement and can make the situation worse... Yup, a problem which is indeed perennial, and which we mentioned in an earlier set of exchanges. > If we had truly global operational best practices for the Internet (ones > that went through a fairly well-defined policy development process which > included multiple operator forums from around the globe) then you might > have a solid chance of producing output which avoided the various anti- > competitive aspects, and yet were a reasonable basis for governments > to then step up and indicate should be required for ISPs in their > operations. > It wouldn't take very many governments asking "How do I reduce SPAM > and DDoS attacks?" and hearing back "Please require ISPs to adhere to this > Best Common Operating Practice Foo-01" before it became common > practice. Indeed, but I have an even better example of how that's already done, that is probably pertinent. The National Electric Code is assimilated law now, I think, in every state in the US. It is promulgated by the National Fire Protection Association, which is a standards organization originally started by insurors to reduce their exposure and expenses; by professional consensus, they have become, effectively, a lawmaking body. So they're not the government, they're subject-matter experts, technically competent to have opinions, and their opinions are assimilated into controlling law. Is BCP38 *not* well enough though out even for large and medium sized carriers to adopt as contractual language, much less for FCC or someone to impose upon them? If so, we should work on it further. If not, do carriers need to be threatened with its imposition to get them to adopt it contractually? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bill at herrin.us Wed Mar 27 14:34:31 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 10:34:31 -0400 Subject: Open Resolver Problems In-Reply-To: <5152FB65.9060309@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> Message-ID: On Wed, Mar 27, 2013 at 10:00 AM, Jack Bates wrote: > On 3/27/2013 8:47 AM, William Herrin wrote: >> Right now that's a complaint for the mainstream software authors, not >> for the system operators. When the version of Bind in Debian Stable >> implements this feature, I'll surely turn it on. > > Tracking the clients would be a huge dataset and be especially complicated > in clusters. They'd be better off at detecting actual attack vectors rather > than rate limiting. I count this among the several reasons I intend to wait until a solution has been accepted into the bind mainline. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Wed Mar 27 14:46:10 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 09:46:10 -0500 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> Message-ID: <51530632.3020402@brightok.net> On 3/27/2013 9:34 AM, William Herrin wrote: > On Wed, Mar 27, 2013 at 10:00 AM, Jack Bates wrote: >> >> Tracking the clients would be a huge dataset and be especially complicated >> in clusters. They'd be better off at detecting actual attack vectors rather >> than rate limiting. > I count this among the several reasons I intend to wait until a > solution has been accepted into the bind mainline. > > You'll also find that it serves little purpose. The only 2 methods for stopping DNS amplification to my knowledge are: 1) tcp 2) require all requests to pad out to maximum response 3) BCP38 (in spirit) The first has latency, load, and connection limitations. It is just too expensive. The second would stop amplification, however, it will not stop botnets using them in attempts to hide the bot nodes in a very effective manner. It's also unlikely that we'd ever see it implemented. The only effective fix is still BCP38 (in spirit). Jack From jbates at brightok.net Wed Mar 27 15:02:04 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 10:02:04 -0500 Subject: BCP38 - Internet Death Penalty In-Reply-To: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> Message-ID: <515309EC.4070402@brightok.net> On 3/27/2013 9:23 AM, Jay Ashworth wrote: > Is BCP38 *not* well enough though out even for large and medium sized > carriers to adopt as contractual language, much less for FCC or > someone to impose upon them? If so, we should work on it further. BCP38 could definitely use some work. It is correct as a general concept. It does not go into depth of the different available technologies and how they might be of use. For example, dhcp is nice, but it usually requires uRPF (sometimes with exceptions) depending on the vendor. If BGP filters are being applied, it is usually not hard to apply packet filtering according to the same route filters. Some NSPs use traditional ingress filtering, while others have uRPF enabled with exception lists. Some require that you send all networks, but set communities for networks you don't want routed yet allowed via uRPF (which usually means anyone connected to the same router as you will still route your way). It's also not a bad idea for an ISP to deploy EGRESS filters if they do not offer BGP Transit services. This way they are not depending on their transit providers to handle spoof protection and they cover their entire network regardless of last mile ingress filtering. This doesn't generally work well when doing transit services of any size due to the number of egress filter updates you'd have to issue, but it is great for the small/medium ISP. Jack From marka at isc.org Wed Mar 27 15:20:14 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Mar 2013 02:20:14 +1100 Subject: Open Resolver Problems In-Reply-To: Your message of "Wed, 27 Mar 2013 09:46:10 CDT." <51530632.3020402@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> <51530632.3020402@brightok.net> Message-ID: <20130327152014.9464E31A05B6@drugs.dv.isc.org> In message <51530632.3020402 at brightok.net>, Jack Bates writes: > On 3/27/2013 9:34 AM, William Herrin wrote: > > On Wed, Mar 27, 2013 at 10:00 AM, Jack Bates wrote: > >> > >> Tracking the clients would be a huge dataset and be especially complicated > >> in clusters. They'd be better off at detecting actual attack vectors rather > >> than rate limiting. > > I count this among the several reasons I intend to wait until a > > solution has been accepted into the bind mainline. > > > > > You'll also find that it serves little purpose. The only 2 methods for > stopping DNS amplification to my knowledge are: > > 1) tcp > > 2) require all requests to pad out to maximum response > > 3) BCP38 (in spirit) 4) a variant of dns cookies see the draft by Donald Eastlake III if you can accept a couple of extra bytes in the reply to a non cookie query * minimal amplification to spoofed queries. * remove the need to randomise source ports. * state is stored in the stubs / recursives serves about the upstream. * works with recursive servers and authoritative servers hash (server secret + client differentiator + time) -> crypto hash query [code = 0 (8 bits), extended id (64 bits), client differentiator (64 bits), server time (32 bits), crypto hash ] response [code (8 bit), extended id (64 bits), client differentiator' (64 bits), server time' (32 bits), crypto hash' ] A query is only accepted if the presented client differentiator and server time along with the server secret give the presented hash and not too much time has elasped otherwise code is set to 1 and the completed option is returned. clients record everything after the extended id to send with future queries. client differentiator, server time and crypto hash may be missing on the initial query. > The first has latency, load, and connection limitations. It is just too > expensive. > > The second would stop amplification, however, it will not stop botnets > using them in attempts to hide the bot nodes in a very effective manner. > It's also unlikely that we'd ever see it implemented. > > The only effective fix is still BCP38 (in spirit). > > > Jack > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Wed Mar 27 15:20:45 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 10:20:45 -0500 Subject: BCP38 needs advertising Message-ID: <51530E4D.7000901@brightok.net> Outside of needing more details and examples, BCP38 could use more advertising. The best option, if they would accept it, is to have all RIRs mention BCP38 as well as require that mention of BCP38 be included in all IP justification requests to customers (so that those who receive netblocks from their ISPs are also aware of it). For ARIN, at least, having it mentioned in the attestation process wouldn't be a bad idea. At least someone of management would be aware of it. The only issue is see concerning the RIRs is that they may object to it being out of scope to their duties. However, informing people of something is not requiring implementation of something. On the other hand, we know that there are a great number of networks that don't participate with the community at large and may have no idea about BCP38 and why it is important. Jack From marka at isc.org Wed Mar 27 15:25:55 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Mar 2013 02:25:55 +1100 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Wed, 27 Mar 2013 10:02:04 CDT." <515309EC.4070402@brightok.net> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> Message-ID: <20130327152555.08D4B31A0684@drugs.dv.isc.org> In message <515309EC.4070402 at brightok.net>, Jack Bates writes: > On 3/27/2013 9:23 AM, Jay Ashworth wrote: > > Is BCP38 *not* well enough though out even for large and medium sized > > carriers to adopt as contractual language, much less for FCC or > > someone to impose upon them? If so, we should work on it further. > > BCP38 could definitely use some work. It is correct as a general > concept. It does not go into depth of the different available > technologies and how they might be of use. For example, dhcp is nice, > but it usually requires uRPF (sometimes with exceptions) depending on > the vendor. If BGP filters are being applied, it is usually not hard to > apply packet filtering according to the same route filters. Some NSPs > use traditional ingress filtering, while others have uRPF enabled with > exception lists. Some require that you send all networks, but set > communities for networks you don't want routed yet allowed via uRPF > (which usually means anyone connected to the same router as you will > still route your way). Technologies change. Concepts rarely do. BCP38 is technology neutral. > It's also not a bad idea for an ISP to deploy EGRESS filters if they do > not offer BGP Transit services. This way they are not depending on their > transit providers to handle spoof protection and they cover their entire > network regardless of last mile ingress filtering. This doesn't > generally work well when doing transit services of any size due to the > number of egress filter updates you'd have to issue, but it is great for > the small/medium ISP. EGRESS filters are just INGRESS filters applied a couple of hops later. > Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Wed Mar 27 15:29:34 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 15:29:34 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> On Mar 27, 2013, at 10:23 AM, Jay Ashworth wrote: > Indeed, but I have an even better example of how that's already done, that > is probably pertinent. > > The National Electric Code is assimilated law now, I think, in every > state in the US. It is promulgated by the National Fire Protection > Association, which is a standards organization originally started by > insurors to reduce their exposure and expenses; by professional consensus, > they have become, effectively, a lawmaking body. > > So they're not the government, they're subject-matter experts, technically > competent to have opinions, and their opinions are assimilated into > controlling law. Indeed... a perfect example of industry self-regulation supplemented by a mandatory legal framework referencing the best practice documents. > Is BCP38 *not* well enough though out even for large and medium sized > carriers to adopt as contractual language, ... You're back to discussing voluntary mechanisms in the above, but your example is a case where compliance is due to legislation at both federal and state levels. > much less for FCC or someone to > impose upon them? If so, we should work on it further. Umm... How many North American ISP's/datacenters/web hosting firms were aware of the BCP 38 development as it was on-going, and participated in some manner in its review? The IETF is a wonderful organization, but it is not exactly overflowing with representation from the service provider community. Also, given that you really need these practices picked up on a global basis, repeat the above question with "Global" rather than North American... If you actually want to see certain technical practices made mandatory for Internet service providers globally, then you need a development process for those practices which fairly robust to insure that the practices are equally germane and reasonable to many different service providers in many different parts of the world. It's actually relatively easy to get governments to require compliance with accepted technical practices for the Internet, the problem has been we've never taken the effort to produce best practices with sufficient rigor than any given government can know that it has the necessary backing (of many of the service providers in its domain) needed to actually require compliance. (With regard to the FCC, there is some question as to whether or not their mandate would allow establishing required practices for ISPs... To the extent that VoIP traffic is being carried, this is far more likely to be possible, and hence folks should be aware of various activities such as the CSRIC "Communications Security, Reliability and Interoperability Council", which develops recommendations that could effectively become requirements on Internet Service Providers in some contexts. Noe that the problem with this sort of approach is that having dozens of countries all developing their own specific technical best practices is most likely to cumulatively interact in ways impossible to comply with... Hence, the need for clear global technical best practices, through which countries with a particular desire to "improve the state of the Internet" can channel their legislative desires...) FYI, /John From bill at herrin.us Wed Mar 27 15:40:36 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 11:40:36 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <515309EC.4070402@brightok.net> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> Message-ID: On Wed, Mar 27, 2013 at 11:02 AM, Jack Bates wrote: > It's also not a bad idea for an ISP to deploy EGRESS filters if they do not > offer BGP Transit services. Nor is it a bad idea for their upstream to inquire as to whether the downstream offers BGP transit services and apply INGRESS filters if they do not. > This way they are not depending on their transit > providers to handle spoof protection and they cover their entire network > regardless of last mile ingress filtering. This doesn't generally work well > when doing transit services of any size due to the number of egress filter > updates you'd have to issue, but it is great for the small/medium ISP. Build a web page where a downstream can set the filters on his interface at his convenience. Apply some basic sanity checks against wide-open. Worry about small lies from a forensic after-the-fact perspective. This problem has a trivial technology-only solution. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Wed Mar 27 15:51:35 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 10:51:35 -0500 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327152555.08D4B31A0684@drugs.dv.isc.org> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <20130327152555.08D4B31A0684@drugs.dv.isc.org> Message-ID: <51531587.2080101@brightok.net> On 3/27/2013 10:25 AM, Mark Andrews wrote: > Technologies change. Concepts rarely do. BCP38 is technology neutral. If we follow that, we should just state "Don't allow spoofed IP Addresses!" and leave it to the individual to figure it out. BCP38 leaves that premise by mentioning ingress filtering as well as mentioning some issues with DHCP. If nothing else, it should have an extensive appendix to point people to the correct documentation for implementation. > EGRESS filters are just INGRESS filters applied a couple of hops later. They are not, and I can think of quite a few people who would stare blankly at you for making such a statement. Of course, I can think of plenty of people who we'd like to see implementing BCP38 concepts that would need you to define ingress and egress. Fact: Ignorance is abound on the Internet, even in the running of networks. If you want a solid change, we're going to have to educate people; especially those who are not on NANOG, don't know about the IETF, and have never heard of an RFC or BCP. Jack From owen at delong.com Wed Mar 27 15:54:27 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Mar 2013 08:54:27 -0700 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: It's been available in linux for a long time, just not in BIND? Here is a working ip6tales example: -A RH-Firewall-1-INPUT -s 2620:0:930::/48 -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -s 2001:470:1f00:3142::/64 -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -s 2620:0:930::/48 -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -s 2001:470:1f00:3142::/64 -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT YMMV and you may wish to provide tighter limits (less than 30 QPM or a burst of <90). Owen On Mar 27, 2013, at 6:47 AM, William Herrin wrote: > On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka wrote: >> Authoritative DNS servers need to implement rate limiting. (a client >> shouldn't query you twice for the same thing within its TTL). > > Right now that's a complaint for the mainstream software authors, not > for the system operators. When the version of Bind in Debian Stable > implements this feature, I'll surely turn it on. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From jbates at brightok.net Wed Mar 27 16:05:12 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 11:05:12 -0500 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> Message-ID: <515318B8.2060306@brightok.net> On 3/27/2013 10:40 AM, William Herrin wrote: > Build a web page where a downstream can set the filters on his > interface at his convenience. Apply some basic sanity checks against > wide-open. Worry about small lies from a forensic after-the-fact > perspective. This problem has a trivial technology-only solution. Well, that would definitely be easier than the RR updates I have to do. I'm not arguing that the process can't be done. The problem is, there are a number of networks that don't know it needs to be done and why, or they don't know how to do it. There are a number of networks that have no concept of scripting changes into their routers. Implementing BCP38 isn't a technology issue as much as an education issue. The BCP provides a brief methodology to accomplish its goals. It doesn't mention other methods or point to resources that an uneducated person may need. The problem might not be with BCP38. Perhaps it is as detailed as it needs to be from an IETF standpoint. However, it is not enough information to cultivate the changes we need. Jack From me at anuragbhatia.com Wed Mar 27 16:38:38 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 27 Mar 2013 22:08:38 +0530 Subject: Line cut in Mediterranean? In-Reply-To: References: Message-ID: Yes smw4 issues across Egypt. In India (and Pakistan also) services are badly impacted. Here in India most of traffic from major networks is going via East Asia route and we are experiencing latency of over 700ms with US and Europe from last few hours. On Wed, Mar 27, 2013 at 6:50 PM, James Smith wrote: > > Thanks for the quick responses, great information! > > > From: thepacketmaster at hotmail.com > > To: nanog at nanog.org > > Subject: Line cut in Mediterranean? > > Date: Wed, 27 Mar 2013 08:49:10 -0400 > > > > > > Getting reports from a third party vendor that there's been a line cut > in the Mediterranean that is affecting some Internet traffic. Anyone have > any details? > > > > -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software IP Service Level Agreement Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-ipsla@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software IP Service Level Agreement Vulnerability Advisory ID: cisco-sa-20130327-ipsla Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software implementation of the IP Service Level Agreement (IP SLA) feature contains a vulnerability in the validation of IP SLA packets that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. Mitigations for this vulnerability are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-ipsla Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTp8QwD+IPK7Dzz7B0uga/FtZKjYU9XC ik2D1EIVMDWcFNYovn8A/i2M+COtgQr9j/7CuMRdNfnAoA65JOxRHu4NTW7cdZoo =w51Y -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Protocol Translation Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-pt@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Protocol Translation Vulnerability Advisory ID: cisco-sa-20130327-pt Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software Protocol Translation (PT) feature contains a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-pt Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd4ACgkQUddfH3/BbTr/hQEAhB32OjahAaNFUbeYsZloNqCX C9JHEqRP4k4Y27LcWZUA+wTwW0yKpKzQ9+ZDvaWYiXtL1iSvOhlSjS178A3kMIhb =JlLG -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Smart Install Denial of Service Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-smartinstall@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Smart Install Denial of Service Vulnerability Advisory ID: cisco-sa-20130327-smartinstall Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Smart Install client feature in Cisco IOS Software contains a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. Affected devices that are configured as Smart Install clients are vulnerable. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that have the Smart Install client feature enabled. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-smartinstall Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd4ACgkQUddfH3/BbToUsAD+NSDtaCAvOzfjmsqhxVZN6Uy+ ceAxXTPCp6M0n8yGk0sA/1uJk8CWE1yjCtTu1IDGX8K/SUvWFEUi0pqFyKfKVFEa =eRMY -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-nat@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Network Address Translation Vulnerability Advisory ID: cisco-sa-20130327-nat Revision 1.0 For Public Release 2013 March 27 10:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software implementation of the virtual routing and forwarding (VRF) aware network address translation (NAT) feature contains a vulnerability when translating IP packets that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-nat Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTrndAD/Qxm/suF3S/US+6bDND+/OKB3 9KpBW/wUPVC2+87IFRQBAIXFrAjFqnbmmBAKFEVZztVhRN1TlOW9JL7mKd6SXwZw =jAQM -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Resource Reservation Protocol Denial of Service Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-rsvp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Resource Reservation Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20130327-rsvp Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Resource Reservation Protocol (RSVP) feature in Cisco IOS Software and Cisco IOS XE Software contains a vulnerability when used on a device that has Multiprotocol Label Switching with Traffic Engineering (MPLS-TE) enabled. Successful exploitation of the vulnerability could allow an unauthenticated, remote attacker to cause a reload of the affected device. Repeated exploitation could result in a sustained denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. There are no workarounds available to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-rsvp Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd4ACgkQUddfH3/BbTqZ+AD/SPWuHu+4uf/xKA+RAbRbCZxd H9SFakcWJIPsy9TYjBABAI6/LmnQ9FrB1PHcVABckjYOnB+9JUd03ynxrsFPzIQS =W+Lt -----END PGP SIGNATURE----- From ahebert at pubnix.net Wed Mar 27 16:48:16 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 27 Mar 2013 12:48:16 -0400 Subject: BCP38 needs advertising In-Reply-To: <51530E4D.7000901@brightok.net> References: <51530E4D.7000901@brightok.net> Message-ID: <515322D0.4030006@pubnix.net> bcp38.org coming soon =D ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/27/13 11:20, Jack Bates wrote: > Outside of needing more details and examples, BCP38 could use more > advertising. > > The best option, if they would accept it, is to have all RIRs mention > BCP38 as well as require that mention of BCP38 be included in all IP > justification requests to customers (so that those who receive > netblocks from their ISPs are also aware of it). > > For ARIN, at least, having it mentioned in the attestation process > wouldn't be a bad idea. At least someone of management would be aware > of it. > > The only issue is see concerning the RIRs is that they may object to > it being out of scope to their duties. However, informing people of > something is not requiring implementation of something. On the other > hand, we know that there are a great number of networks that don't > participate with the community at large and may have no idea about > BCP38 and why it is important. > > > Jack > > > > > From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Internet Key Exchange Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-ike@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Internet Key Exchange Vulnerability Advisory ID: cisco-sa-20130327-ike Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Cisco IOS Software Internet Key Exchange (IKE) feature contains a denial of service (DoS) vulnerability. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are not available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-ike Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTovwQD8DwYcxZks8h9lxLcC9YX0Stal GfVltUM7jduv3M2tsQgBAIdGU+jBhC8Ct4i/0idzEkoX6o8TAK3EbcUqZt9QjK6F =Viuu -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 27 16:13:56 2013 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 27 Mar 2013 12:13:56 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Zone-Based Policy Firewall Session Initiation Protocol Inspection Denial of Service Vulnerability Message-ID: <201303271213018.cisco-sa-20130327-cce@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS Software Zone-Based Policy Firewall Session Initiation Protocol Inspection Denial of Service Vulnerability Advisory ID: cisco-sa-20130327-cce Revision 1.0 For Public Release 2013 March 27 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a memory leak vulnerability that could be triggered through the processing of malformed Session Initiation Protocol (SIP) messages. Exploitation of this vulnerability could cause an interruption of services. Only devices that are configured for SIP inspection are affected by this vulnerability. Cisco has released free software updates that address this vulnerability. There are no workarounds for devices that must run SIP inspection. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-cce Note: The March 27, 2013, Cisco IOS Software Security Advisory bundled publication includes seven Cisco Security Advisories. All advisories address vulnerabilities in Cisco IOS Software. Each Cisco IOS Software Security Advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all Cisco IOS Software vulnerabilities in the March 2013 bundled publication. Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar13.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAlFQcd0ACgkQUddfH3/BbTo1NQD+JTLByafJPlfucXQ7tGEHnYy5 vVv944CH2/B0vC3+AHUA/Aw9dc2MzCzkrKELNu9FQDBFkr5lIhdY9i942xPDfHKQ =6IL2 -----END PGP SIGNATURE----- From fergdawgster at gmail.com Wed Mar 27 17:17:46 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 27 Mar 2013 10:17:46 -0700 Subject: BCP38 needs advertising In-Reply-To: <515322D0.4030006@pubnix.net> References: <51530E4D.7000901@brightok.net> <515322D0.4030006@pubnix.net> Message-ID: Please reference: http://openresolverproject.org/ http://spoofer.csail.mit.edu/ http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack ...and anything else to raise the awareness level. Thanks, - ferg (co-perpetrator of BCP38) :-) On Wed, Mar 27, 2013 at 9:48 AM, Alain Hebert wrote: > bcp38.org coming soon =D > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 03/27/13 11:20, Jack Bates wrote: >> Outside of needing more details and examples, BCP38 could use more >> advertising. >> >> The best option, if they would accept it, is to have all RIRs mention >> BCP38 as well as require that mention of BCP38 be included in all IP >> justification requests to customers (so that those who receive >> netblocks from their ISPs are also aware of it). >> >> For ARIN, at least, having it mentioned in the attestation process >> wouldn't be a bad idea. At least someone of management would be aware >> of it. >> >> The only issue is see concerning the RIRs is that they may object to >> it being out of scope to their duties. However, informing people of >> something is not requiring implementation of something. On the other >> hand, we know that there are a great number of networks that don't >> participate with the community at large and may have no idea about >> BCP38 and why it is important. >> >> >> Jack >> >> >> >> >> > > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From huasong at kalorama.com Wed Mar 27 16:42:38 2013 From: huasong at kalorama.com (Huasong Zhou) Date: Wed, 27 Mar 2013 16:42:38 +0000 Subject: Line cut in Mediterranean? In-Reply-To: Message-ID: <8A84F8DB3EFEB94293B800F287084ECA22661407@mbx028-e1-va-4.exch028.domain.local> Maybe it was because of this: Global Internet Slows after 'biggest attack in history' http://www.bbc.co.uk/news/technology-21954636 Huasong Zhou Associate Kalorama Group, LLC 1000 Potomac Street, NW, Suite 350 Washington, D.C. 20007 Mobile: +1 763 221 6784 Email: huasong at kalorama.com www.kalorama.com On 3/27/13 12:38 PM, "Anurag Bhatia" wrote: >Yes smw4 issues across Egypt. > >In India (and Pakistan also) services are badly impacted. > > >Here in India most of traffic from major networks is going via East Asia >route and we are experiencing latency of over 700ms with US and Europe >from >last few hours. > >On Wed, Mar 27, 2013 at 6:50 PM, James Smith >wrote: > >> >> Thanks for the quick responses, great information! >> >> > From: thepacketmaster at hotmail.com >> > To: nanog at nanog.org >> > Subject: Line cut in Mediterranean? >> > Date: Wed, 27 Mar 2013 08:49:10 -0400 >> > >> > >> > Getting reports from a third party vendor that there's been a line cut >> in the Mediterranean that is affecting some Internet traffic. Anyone >>have >> any details? >> > >> >> > > > >-- > >Anurag Bhatia >anuragbhatia.com > >Linkedin | >Twitter >Skype: anuragbhatia.com From arturo.servin at gmail.com Wed Mar 27 18:02:56 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 27 Mar 2013 15:02:56 -0300 Subject: BCP38 needs advertising In-Reply-To: References: <51530E4D.7000901@brightok.net> <515322D0.4030006@pubnix.net> Message-ID: <51533450.6070901@gmail.com> And do not forget .... http://tools.ietf.org/html/bcp38 :) -as On 3/27/13 2:17 PM, Paul Ferguson wrote: > Please reference: > > http://openresolverproject.org/ > http://spoofer.csail.mit.edu/ > http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack > > ...and anything else to raise the awareness level. > > Thanks, > > - ferg (co-perpetrator of BCP38) :-) > > On Wed, Mar 27, 2013 at 9:48 AM, Alain Hebert wrote: > >> bcp38.org coming soon =D >> >> ----- >> Alain Hebert ahebert at pubnix.net >> PubNIX Inc. >> 50 boul. St-Charles >> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >> >> On 03/27/13 11:20, Jack Bates wrote: >>> Outside of needing more details and examples, BCP38 could use more >>> advertising. >>> >>> The best option, if they would accept it, is to have all RIRs mention >>> BCP38 as well as require that mention of BCP38 be included in all IP >>> justification requests to customers (so that those who receive >>> netblocks from their ISPs are also aware of it). >>> >>> For ARIN, at least, having it mentioned in the attestation process >>> wouldn't be a bad idea. At least someone of management would be aware >>> of it. >>> >>> The only issue is see concerning the RIRs is that they may object to >>> it being out of scope to their duties. However, informing people of >>> something is not requiring implementation of something. On the other >>> hand, we know that there are a great number of networks that don't >>> participate with the community at large and may have no idea about >>> BCP38 and why it is important. >>> >>> >>> Jack >>> >>> >>> >>> >>> >> >> > > > From aftab.siddiqui at gmail.com Wed Mar 27 18:13:19 2013 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Wed, 27 Mar 2013 23:13:19 +0500 Subject: Line cut in Mediterranean? In-Reply-To: <8A84F8DB3EFEB94293B800F287084ECA22661407@mbx028-e1-va-4.exch028.domain.local> References: <8A84F8DB3EFEB94293B800F287084ECA22661407@mbx028-e1-va-4.exch028.domain.local> Message-ID: Well, it's not just SMW4 outage, we've been witnessing serious issues on IMEWE for couple of weeks now and this outages just made it worse. So, right now most of the traffic taking east bound routes. Who needs DDoS at this stage, these links are already chocked up :) > Maybe it was because of this: Global Internet Slows after 'biggest attack > in history' > http://www.bbc.co.uk/news/technology-21954636 > > -- Regards, Aftab A. Siddiqui From fergdawgster at gmail.com Wed Mar 27 18:31:32 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 27 Mar 2013 11:31:32 -0700 Subject: BCP38 needs advertising In-Reply-To: <51533450.6070901@gmail.com> References: <51530E4D.7000901@brightok.net> <515322D0.4030006@pubnix.net> <51533450.6070901@gmail.com> Message-ID: But of course. :-) Also, just saw this: http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet - ferg On Wed, Mar 27, 2013 at 11:02 AM, Arturo Servin wrote: > > And do not forget .... > > http://tools.ietf.org/html/bcp38 > > :) > > -as > > > On 3/27/13 2:17 PM, Paul Ferguson wrote: >> Please reference: >> >> http://openresolverproject.org/ >> http://spoofer.csail.mit.edu/ >> http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack >> >> ...and anything else to raise the awareness level. >> >> Thanks, >> >> - ferg (co-perpetrator of BCP38) :-) >> >> On Wed, Mar 27, 2013 at 9:48 AM, Alain Hebert wrote: >> >>> bcp38.org coming soon =D >>> >>> ----- >>> Alain Hebert ahebert at pubnix.net >>> PubNIX Inc. >>> 50 boul. St-Charles >>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >>> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >>> >>> On 03/27/13 11:20, Jack Bates wrote: >>>> Outside of needing more details and examples, BCP38 could use more >>>> advertising. >>>> >>>> The best option, if they would accept it, is to have all RIRs mention >>>> BCP38 as well as require that mention of BCP38 be included in all IP >>>> justification requests to customers (so that those who receive >>>> netblocks from their ISPs are also aware of it). >>>> >>>> For ARIN, at least, having it mentioned in the attestation process >>>> wouldn't be a bad idea. At least someone of management would be aware >>>> of it. >>>> >>>> The only issue is see concerning the RIRs is that they may object to >>>> it being out of scope to their duties. However, informing people of >>>> something is not requiring implementation of something. On the other >>>> hand, we know that there are a great number of networks that don't >>>> participate with the community at large and may have no idea about >>>> BCP38 and why it is important. >>>> >>>> >>>> Jack >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From jra at baylink.com Wed Mar 27 18:44:26 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Mar 2013 14:44:26 -0400 (EDT) Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" Message-ID: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet Yes: 120 gigabits/second, primarily of DNS amplification traffic. Still think it's optional to implement BCP38 pervasively? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mdavids at forfun.net Wed Mar 27 18:44:47 2013 From: mdavids at forfun.net (Marco Davids) Date: Wed, 27 Mar 2013 19:44:47 +0100 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <51533E1F.3000202@forfun.net> Op 27-03-13 16:54, Owen DeLong schreef: > It's been available in linux for a long time, just not in BIND? Not entirely true: http://www.redbarn.org/dns/ratelimits > > Here is a working ip6tales example: > Tricky... There is also the 'hashlimit' module (at least for v4, not sure about v6), that may be a better approach, because it works on a 'per ip address'-basis. See https://lists.isc.org/pipermail/bind-users/2012-July/088223.html for some inspiration of how it may be of value. -- Marco On Mar 27, 2013, at 6:47 AM, William Herrin wrote: >> On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka wrote: >>> Authoritative DNS servers need to implement rate limiting. (a client >>> shouldn't query you twice for the same thing within its TTL). >> Right now that's a complaint for the mainstream software authors, not >> for the system operators. When the version of Bind in Debian Stable >> implements this feature, I'll surely turn it on. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 > -- Marco Davids -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4432 bytes Desc: S/MIME-cryptografische ondertekening URL: From Valdis.Kletnieks at vt.edu Wed Mar 27 18:45:31 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 Mar 2013 14:45:31 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Wed, 27 Mar 2013 10:51:35 -0500." <51531587.2080101@brightok.net> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <20130327152555.08D4B31A0684@drugs.dv.isc.org> <51531587.2080101@brightok.net> Message-ID: <10924.1364409931@turing-police.cc.vt.edu> On Wed, 27 Mar 2013 10:51:35 -0500, Jack Bates said: > They are not, and I can think of quite a few people who would stare > blankly at you for making such a statement. Of course, I can think of > plenty of people who we'd like to see implementing BCP38 concepts that > would need you to define ingress and egress. Of course, the fact they don't understand ingress and egress are *totally* unrelated to the fact they can't figure out how to deploy BCP38, correct? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jared at puck.nether.net Wed Mar 27 18:52:16 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Mar 2013 14:52:16 -0400 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <62572589-280D-4155-B785-1D6960430FC1@puck.nether.net> On Mar 27, 2013, at 11:54 AM, Owen DeLong wrote: > It's been available in linux for a long time, just not in BIND? > > Here is a working ip6tales example: > > -A RH-Firewall-1-INPUT -s 2620:0:930::/48 -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT > -A RH-Firewall-1-INPUT -s 2001:470:1f00:3142::/64 -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT > -A RH-Firewall-1-INPUT -s 2620:0:930::/48 -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT > -A RH-Firewall-1-INPUT -s 2001:470:1f00:3142::/64 -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT > -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT > > YMMV and you may wish to provide tighter limits (less than 30 QPM or a burst of <90). I am very concerned about examples such as this possibly being implemented by a well intentioned sysadmin or neteng type without understanding their query load and patterns. bind with the rrl patch does log when things are happening. While the data is possible to extract from iptables, IMHO it's not quite as easy to audit as a syslog. - Jared From jra at baylink.com Wed Mar 27 19:01:36 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Mar 2013 15:01:36 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: <10924.1364409931@turing-police.cc.vt.edu> Message-ID: <15305412.11238.1364410896490.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Wed, 27 Mar 2013 10:51:35 -0500, Jack Bates said: > > They are not, and I can think of quite a few people who would stare > > blankly at you for making such a statement. Of course, I can think > > of plenty of people who we'd like to see implementing BCP38 concepts > > that would need you to define ingress and egress. > > Of course, the fact they don't understand ingress and egress are *totally* > unrelated to the fact they can't figure out how to deploy BCP38, correct? Oh, Jeezus; do we need to start seeing geek licenses[1] before we'll turn up your BGP session or Transit link now? Have we really sunk that low?[2] Cheers, -- jra [1] Seriously; I think we need these; for escalating to Tier 3 support if nothing else.[3] [2] No, I don't actually want an answer to this; I'm depressed enough. [3] "Hello, Road Runner business support!" "Yes, my Geek License number is G 17135, and I need to speak to your backbone BGP coordinator." "I'll transfer you right now, sir." -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jabley at hopcount.ca Wed Mar 27 19:03:17 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 27 Mar 2013 15:03:17 -0400 Subject: Open Resolver Problems In-Reply-To: <62572589-280D-4155-B785-1D6960430FC1@puck.nether.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <62572589-280D-4155-B785-1D6960430FC1@puck.nether.net> Message-ID: <4AB7F172-1307-4D58-BE45-1954F0FCFCE9@hopcount.ca> On 2013-03-27, at 14:52, Jared Mauch wrote: > I am very concerned about examples such as this possibly being implemented by a well intentioned sysadmin or neteng type without understanding their query load and patterns. bind with the rrl patch does log when things are happening. While the data is possible to extract from iptables, IMHO it's not quite as easy to audit as a syslog. For an authoritative-only server, people can expect coarse rate-limits such as those quoted earlier with iptables to give false positives and to reject legitimate queries. RRL is far safer. For a recursive server, I agree you need a much better understanding of your traffic patterns before you try something like the iptables example. Dropping queries from your own clients' stub resolvers has an immediate support cost. You *really* don't want false positives, there. Joe From wbailey at satelliteintelligencegroup.com Wed Mar 27 19:09:11 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Mar 2013 19:09:11 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> Message-ID: Is someone pissed off at Spamhaus, or was the intention to packet them so hard their entire network ceased to exist so they can no longer offer DROP/RBL/xyz service? Seldom do hax0r nations target things without some type of "justification". I don't really care who is being internet murdered, I care why. It's probably the same people who have been posting news articles from Ashworth's email. On 3/27/13 11:44 AM, "Jay Ashworth" wrote: >http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet > >Yes: 120 gigabits/second, primarily of DNS amplification traffic. > >Still think it's optional to implement BCP38 pervasively? > >Cheers, >-- jra >-- >Jay R. Ashworth Baylink >jra at baylink.com >Designer The Things I Think RFC >2100 >Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >St Petersburg FL USA #natog +1 727 647 >1274 > > From saku at ytti.fi Wed Mar 27 19:18:19 2013 From: saku at ytti.fi (Saku Ytti) Date: Wed, 27 Mar 2013 21:18:19 +0200 Subject: BCP38 - Internet Death Penalty In-Reply-To: <515318B8.2060306@brightok.net> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> Message-ID: <20130327191819.GA16425@pob.ytti.fi> On (2013-03-27 11:05 -0500), Jack Bates wrote: > I'm not arguing that the process can't be done. The problem is, > there are a number of networks that don't know it needs to be done > and why, or they don't know how to do it. There are a number of > networks that have no concept of scripting changes into their > routers. Exactly. If we target BCP38 at last-mile we have 0 hope to achieve sufficient coverage to make spoofing attacks less practical than HTTP GET from unspoofed address. I think we should educate tier2 operators who offer transit to tier3. It's most practical place for BCP38. tier1<->tier2 can't do it, strict IRR prefix-filtering is not practical. tier2<->tier3 can do it, it's practical to do strict BGP prefix-filter. If you are doing strict BGP prefix-filter, it's either very easy to generate ACL while at it or 0 work in say JunOS, as you can just use same prefix-list for firewall filter. Open recursors may have been discussion point pre-DNSSEC world, post DNSSEC world it's easy enough to find large RRs from arbitrary authorative server, that is, even if you'd close all open recursors problem would not go away. -- ++ytti From j at 2600hz.com Wed Mar 27 19:18:29 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Wed, 27 Mar 2013 19:18:29 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: References: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com>, Message-ID: <8DE012AC-6B51-48A7-8609-52D9BC2883BB@2600hz.com> That was a really big attack. The scary part is that it's all DNS reflection, meaning the attackers only need 3Gbps of bandwidth to generate 300Gbps of DDoS. Imagine if they compromised some of the medium sized corporate networks along with these Botnets. I don't know if the exchanges could hold up against 1Tbps of DDoS, and the difference between 300 and 1000Gbps is not a lot. While I'm excited that CloudFlare is doing such a good job bringing this to the attention of the masses I can't help but feel that this is essentially a time bomb. If this attack was an order of magnitude larger, things might be very different. Cheers, Joshua Sent from my iPhone On Mar 27, 2013, at 12:10 PM, "Warren Bailey" wrote: > Is someone pissed off at Spamhaus, or was the intention to packet them so > hard their entire network ceased to exist so they can no longer offer > DROP/RBL/xyz service? > > Seldom do hax0r nations target things without some type of > "justification". I don't really care who is being internet murdered, I > care why. > > It's probably the same people who have been posting news articles from > Ashworth's email. > > On 3/27/13 11:44 AM, "Jay Ashworth" wrote: > >> http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet >> >> Yes: 120 gigabits/second, primarily of DNS amplification traffic. >> >> Still think it's optional to implement BCP38 pervasively? >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 647 >> 1274 >> >> > > > From bill at herrin.us Wed Mar 27 19:22:59 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 15:22:59 -0400 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: References: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Mar 27, 2013 at 3:09 PM, Warren Bailey wrote: > Is someone pissed off at Spamhaus, or was the intention to packet them so > hard their entire network ceased to exist so they can no longer offer > DROP/RBL/xyz service? According to the New York Times it was 300 gbps and Cyberbunker was the bad guy. http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becomes-internet-snarling-attack.html?pagewanted=all&_r=0 -Bill From jordan at viviotech.net Wed Mar 27 19:24:33 2013 From: jordan at viviotech.net (Jordan Michaels) Date: Wed, 27 Mar 2013 12:24:33 -0700 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: References: Message-ID: <51534771.5000404@viviotech.net> You won't care "who" until the target is you. ;) Warm Regards, Jordan Michaels On 03/27/2013 12:09 PM, Warren Bailey wrote: > Seldom do hax0r nations target things without some type of > "justification". I don't really care who is being internet murdered, I > care why. From wbailey at satelliteintelligencegroup.com Wed Mar 27 19:29:14 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Mar 2013 19:29:14 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: Message-ID: As cyberbunker stops killing spamhaus and goes after Gilmore.. I think these are the guys who used to colo HavenCo after they burnt their platform down? I'm not sure how I feel about Cloudflare comparing being packeted to a nuclear bomb? After the packeting drys up, is there really total devastation? Seems to me it would better to compare it to something like a giant traffic jam (http://en.wikipedia.org/wiki/China_National_Highway_110_traffic_jam) not miles of land completely wiped out with zero hope of salvage? Unless cisco has implemented a mechanism to melt a router when the traffic exceeds 100gbps? ;) On 3/27/13 12:22 PM, "William Herrin" wrote: >On Wed, Mar 27, 2013 at 3:09 PM, Warren Bailey > wrote: >> Is someone pissed off at Spamhaus, or was the intention to packet them >>so >> hard their entire network ceased to exist so they can no longer offer >> DROP/RBL/xyz service? > >According to the New York Times it was 300 gbps and Cyberbunker was the >bad guy. > >http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becom >es-internet-snarling-attack.html?pagewanted=all&_r=0 > >-Bill > From fergdawgster at gmail.com Wed Mar 27 19:30:43 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 27 Mar 2013 12:30:43 -0700 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <8DE012AC-6B51-48A7-8609-52D9BC2883BB@2600hz.com> References: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> <8DE012AC-6B51-48A7-8609-52D9BC2883BB@2600hz.com> Message-ID: On Wed, Mar 27, 2013 at 12:18 PM, Joshua Goldbard wrote: > That was a really big attack. > > The scary part is that it's all DNS reflection, meaning the attackers only need 3Gbps of bandwidth to generate 300Gbps of DDoS. > > Imagine if they compromised some of the medium sized corporate networks along with these Botnets. I don't know if the exchanges could hold up against 1Tbps of DDoS, and the difference between 300 and 1000Gbps is not a lot. > > While I'm excited that CloudFlare is doing such a good job bringing this to the attention of the masses I can't help but feel that this is essentially a time bomb. If this attack was an order of magnitude larger, things might be very different. > Consider this a call-to-arms, in all aspects. Please. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From surfer at mauigateway.com Wed Mar 27 19:55:12 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Mar 2013 12:55:12 -0700 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" Message-ID: <20130327125512.A9FF6736@resin11.mta.everyone.net> --- bill at herrin.us wrote: From: William Herrin According to the New York Times it was 300 gbps and Cyberbunker was the bad guy. http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becomes-internet-snarling-attack.html?pagewanted=all&_r=0 ----------------------------------------- Got a link that we don't have to allow cookies and have to create an account to read? scott From eric.carroll at acm.org Wed Mar 27 19:45:11 2013 From: eric.carroll at acm.org (Eric M. Carroll) Date: Wed, 27 Mar 2013 15:45:11 -0400 Subject: Enforcing Source Integrity: BCP38 and Open Resolver Problems Message-ID: The root cause of high scale directed amplification attacks is the failure to assure the integrity of the source IP address. This failure leads to a large set of directed amplification attack vectors. BCP38 was written in 2000, coming up on its 13th anniversary. This root cause, and various methodologies & technologies to resolve it, have been an ongoing discussion since back to the 90s. The failure to enforce this BCP or the related technological mechanisms to force implementation is the root cause of why the Internet cannot always trust source addresses and why these attack vectors persist. Until the ISP community gets serious about forcing the integrity of source addresses throughout its topology, various flavours of attack whose root cause is the spoofed source addresses will continue. Yes, it is not easy to do because it is a transitive trust issue, linked to topology and address management policy. Yes it would be easier if there was a magic bullet to validate source addresses built into the architecture. But there is not, the architecture is what it is. If every step of the chain enforced the integrity of source addresses, this risk would be resolved. There are multiple different steps that could be taken, including law enforcement, statute, contractual, policy, process and technological mechanisms. Every ISP and content providers' business model is threatened by this vulnerability. Every attack drives up operational expenses for everyone. Opportunity costs of missed sales and impacted business are everywhere. It is a pure tragedy of the commons - for lack of enforcement, the whole system is threatened in scale. This problem cannot be allowed to rest at the edges simply by pointing at the current amplification vector. Yesterday it was something different. Tomorrow it will different again. The constant is the rising scale of the Internet and resulting increase in scale of the attack and its corresponding economic impact. The root cause is not today's Google issue. The ISP community has the power to enforce this through policy and technological means. Whether it has the will and ability to self-organize and enforce is a different issue (and also, a long standing one). The discussion needs to be not just about the edge issue of the day. It needs to be about what forum, and what means can be used to enforce this integrity. Post-9/11 the ISP community has significantly more hammers in its arsenal now that it did in May 2000. Perhaps NANOG is not the right forum to discuss, but if not, what is? This is truly an operational threat to the whole community. Leadership needs to come from the largest providers, not just from the smallest. Today the threat is rogue data centres hosting spammers trying to game the system, tolerated by their up stream providers. Does this really need to be a hostile state or quasi-state actor deliberately threatening the infrastructure before serious coordinated action is taken? We really do know better. Eric Carroll From bill at herrin.us Wed Mar 27 19:54:08 2013 From: bill at herrin.us (William Herrin) Date: Wed, 27 Mar 2013 15:54:08 -0400 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <20130327125512.A9FF6736@resin11.mta.everyone.net> References: <20130327125512.A9FF6736@resin11.mta.everyone.net> Message-ID: On Wed, Mar 27, 2013 at 3:55 PM, Scott Weeks wrote: > According to the New York Times it was 300 gbps and Cyberbunker was the bad guy. > http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becomes-internet-snarling-attack.html?pagewanted=all&_r=0 > ----------------------------------------- > > Got a link that we don't have to allow cookies and have to create an account to read? >From the New York Times? It didn't ask me for an account. YMMV. I suspect you will need cookies. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From huasong at kalorama.com Wed Mar 27 19:40:47 2013 From: huasong at kalorama.com (Huasong Zhou) Date: Wed, 27 Mar 2013 19:40:47 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <20130327125512.A9FF6736@resin11.mta.everyone.net> Message-ID: <8A84F8DB3EFEB94293B800F287084ECA22661CBC@mbx028-e1-va-4.exch028.domain.local> Try this one: http://www.bbc.co.uk/news/technology-21954636 On 3/27/13 3:55 PM, "Scott Weeks" wrote: > > >--- bill at herrin.us wrote: >From: William Herrin > >According to the New York Times it was 300 gbps and Cyberbunker was the >bad guy. >http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becom >es-internet-snarling-attack.html?pagewanted=all&_r=0 >----------------------------------------- > > >Got a link that we don't have to allow cookies and have to create an >account to read? > >scott > From wbailey at satelliteintelligencegroup.com Wed Mar 27 20:05:29 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Mar 2013 20:05:29 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <8A84F8DB3EFEB94293B800F287084ECA22661CBC@mbx028-e1-va-4.exch028.domain.local> References: <20130327125512.A9FF6736@resin11.mta.everyone.net>, <8A84F8DB3EFEB94293B800F287084ECA22661CBC@mbx028-e1-va-4.exch028.domain.local> Message-ID: At least they compared it to a traffic jam. ;) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Huasong Zhou Date: 03/27/2013 1:00 PM (GMT-08:00) To: surfer at mauigateway.com,nanog at nanog.org Subject: Re: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" Try this one: http://www.bbc.co.uk/news/technology-21954636 On 3/27/13 3:55 PM, "Scott Weeks" wrote: > > >--- bill at herrin.us wrote: >From: William Herrin > >According to the New York Times it was 300 gbps and Cyberbunker was the >bad guy. >http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becom >es-internet-snarling-attack.html?pagewanted=all&_r=0 >----------------------------------------- > > >Got a link that we don't have to allow cookies and have to create an >account to read? > >scott > From marka at isc.org Wed Mar 27 20:54:28 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Mar 2013 07:54:28 +1100 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Wed, 27 Mar 2013 15:29:34 -0000." <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> Message-ID: <20130327205429.2E7C931A1578@drugs.dv.isc.org> In message <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0 at CHAXCH01.corp.arin.net>, John Curran writes: > On Mar 27, 2013, at 10:23 AM, Jay Ashworth wrote: > > > Indeed, but I have an even better example of how that's already done, > that > > is probably pertinent. > > > > > The National Electric Code is assimilated law now, I think, in every > > state in the US. It is promulgated by the National Fire Protection > > Association, which is a standards organization originally started by > > insurors to reduce their exposure and expenses; by professional > consensus, > > they have become, effectively, a lawmaking body. > > > > So they're not the government, they're subject-matter experts, > technically > > competent to have opinions, and their opinions are assimilated into > > controlling law. > > Indeed... a perfect example of industry self-regulation supplemented by > a mandatory legal framework referencing the best practice documents. > > > Is BCP38 *not* well enough though out even for large and medium sized > > carriers to adopt as contractual language, ... > > You're back to discussing voluntary mechanisms in the above, but > your example is a case where compliance is due to legislation at > both federal and state levels. > > > much less for FCC or someone to > > impose upon them? If so, we should work on it further. > > Umm... How many North American ISP's/datacenters/web hosting firms were > aware of the BCP 38 development as it was on-going, and participated in > some manner in its review? The IETF is a wonderful organization, but it > is not exactly overflowing with representation from the service provider > community. Also, given that you really need these practices picked up > on a global basis, repeat the above question with "Global" rather than > North American... I'd say enough were aware. :-) 8. Acknowledgments The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions. > If you actually want to see certain technical practices made mandatory > for Internet service providers globally, then you need a development > process for those practices which fairly robust to insure that the > practices are equally germane and reasonable to many different service > providers in many different parts of the world. It's actually relatively > easy to get governments to require compliance with accepted technical > practices for the Internet, the problem has been we've never taken the > effort to produce best practices with sufficient rigor than any given > government can know that it has the necessary backing (of many of the > service providers in its domain) needed to actually require compliance. > > (With regard to the FCC, there is some question as to whether or not > their mandate would allow establishing required practices for ISPs... > To the extent that VoIP traffic is being carried, this is far more > likely to be possible, and hence folks should be aware of various > activities such as the CSRIC "Communications Security, Reliability > and Interoperability Council", which develops recommendations that > could effectively become requirements on Internet Service Providers > in some contexts. > nteroperability-council-iii> > Noe that the problem with this sort of approach is that having dozens > of countries all developing their own specific technical best practices > is most likely to cumulatively interact in ways impossible to comply > with... Hence, the need for clear global technical best practices, > through which countries with a particular desire to "improve the > state of the Internet" can channel their legislative desires...) > > FYI, > /John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fergdawgster at gmail.com Wed Mar 27 21:19:05 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 27 Mar 2013 14:19:05 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327205429.2E7C931A1578@drugs.dv.isc.org> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> Message-ID: On Wed, Mar 27, 2013 at 1:54 PM, Mark Andrews wrote: > > In message <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0 at CHAXCH01.corp.arin.net>, John Curran writes: >> >> Umm... How many North American ISP's/datacenters/web hosting firms were >> aware of the BCP 38 development as it was on-going, and participated in >> some manner in its review? The IETF is a wonderful organization, but it >> is not exactly overflowing with representation from the service provider >> community. Also, given that you really need these practices picked up >> on a global basis, repeat the above question with "Global" rather than >> North American... > > I'd say enough were aware. :-) > > 8. Acknowledgments > > The North American Network Operators Group (NANOG) [5] group as a > whole deserves special credit for openly discussing these issues and > actively seeking possible solutions. Also, thanks to Justin Newton > [Priori Networks] and Steve Bielagus [IronBridge Networks]. for > their comments and contributions. > I think the core group of backbone engineers, and to some degree others at the periphery of the DFZ, understand the issues. And yes, I think it gets back to an education problem on "why you should care". As I mentioned on another list earlier today, let's face it -- this is going to require a large-scale, very public, and probably multi-year education & awareness effort (as if 13+ years isn't enough already!). How long did it take to get some movement on open SMTP relays? You get the idea. Some people are going to have to step and add a few thousand more frequent flier miles and get out to various geographic constituencies, at various events, and start talking about this. And we need a lot more people on board. Nation & international campaigns, etc. And there may even be some stick approaches to accompany the carrot, but some awareness is going to have to happen. Sing it from the mountain tops. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From surfer at mauigateway.com Wed Mar 27 21:54:44 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Mar 2013 14:54:44 -0700 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" Message-ID: <20130327145444.A9FF4584@resin11.mta.everyone.net> --- bill at herrin.us wrote: From: William Herrin According to the New York Times it was 300 gbps and Cyberbunker was the bad guy. http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becomes-internet-snarling-attack.html?pagewanted=all&_r=0 ----------------------------------------- Got a link that we don't have to allow cookies and have to create an account to read? ------------------------------------------------------------ I found it using startpage.com's proxy and pasted it below for others that don't want to create accounts and all: A squabble between a group fighting spam and a Dutch company that hosts Web sites said to be sending spam has escalated into one of the largest computer attacks on the Internet, causing widespread congestion and jamming crucial infrastructure around the world, John Markoff and Nicole Perlroth write on Wednesday in The New York Times. Millions of ordinary Internet users have experienced delays in services like Netflix or could not reach a particular Web site for a short time. However, for the Internet engineers who run the global network, the problem is more worrisome. The attacks are becoming increasingly powerful, and computer security experts worry that if they continue to escalate, people may not be able to reach basic Internet services, like e-mail and online banking. The dispute started when the spam-fighting group, called Spamhaus, added the Dutch company Cyberbunker to its blacklist, which is used by e-mail providers to weed out spam. Cyberbunker, named for its headquarters, a five-story former NATO bunker, offers hosting services to any Web site ?except child porn and anything related to terrorism,? according to its Web site. A spokesman for Spamhaus, which is based in Europe, said the attacks began on March 19, but had not stopped the group from distributing its blacklist. Patrick Gilmore, chief architect at Akamai Networks, a digital content provider, said Spamhaus?s role was to generate a list of Internet spammers. Of Cyberbunker, he added: ?These guys are just mad. To be frank, they got caught. They think they should be allowed to spam.? Mr. Gilmore said that the attacks, which are generated by swarms of computers called botnets, concentrate data streams that are larger than the Internet connections of entire countries. He likened the technique, which uses a long-known flaw in the Internet?s basic plumbing, to using a machine gun to spray an entire crowd when the intent is to kill one person. The so-called distributed denial of service, or DDoS, attacks have reached previously unknown magnitudes, growing to a data stream of 300 billion bits per second. Questioned about the attacks, Sven Olaf Kamphuis, an Internet activist who said he was a spokesman for the attackers, said in an online message that, ?We are aware that this is one of the largest DDoS attacks the world had publicly seen.? Mr. Kamphuis said Cyberbunker was retaliating against Spamhaus for ?abusing their influence.? scott From dot at dotat.at Wed Mar 27 21:33:58 2013 From: dot at dotat.at (Tony Finch) Date: Wed, 27 Mar 2013 21:33:58 +0000 Subject: Open Resolver Problems In-Reply-To: <74105DD6-7870-474F-A150-D55C494F5E9F@hopcount.ca> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <74105DD6-7870-474F-A150-D55C494F5E9F@hopcount.ca> Message-ID: Joe Abley wrote: > > My assessment is that the implementations I have seen are ready for > production use, but I think it's understandable given the moving > goalpoasts that some vendors have not yet promoted the code to be > included in stable releases. It is in the current stable release of NSD 3.2.15 though it is a build-time option. It is in the current release candidate of knot DNS 1.2.0-rc4. It will be in BIND-9.10 which has not yet reached public beta. Our servers have been abused as reflectors, and we're using the BIND RRL patch with versions 9.8 and 9.9 to stop the attack traffic. There are other interim options such as using firewall rate limiting which is worse than RRL because it is much more likely to hurt legitimate queries. For example, http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html Or you can use a configuration add-on such as bindguard. http://bindguard.activezone.de Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From dot at dotat.at Wed Mar 27 21:41:59 2013 From: dot at dotat.at (Tony Finch) Date: Wed, 27 Mar 2013 21:41:59 +0000 Subject: Open Resolver Problems In-Reply-To: <5152FB65.9060309@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> Message-ID: Jack Bates wrote: > > Tracking the clients would be a huge dataset and be especially complicated in > clusters. The memory usage is guite manageable: for the BIND patch it is at most 40-80 bytes (for 32 or 64 bit machines) per request per second. You're doing well if you need a megabyte. There's no need to get complicated with clusters: it's enough of an improvement just to track rates per server. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From surfer at mauigateway.com Wed Mar 27 22:03:59 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 27 Mar 2013 15:03:59 -0700 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" Message-ID: <20130327150359.A9FF47A8@resin11.mta.everyone.net> "...Sven Olaf Kamphuis, an Internet activist who said he was a spokesman for the attackers..." I wonder is he'll ever post here again as he has in the past. It probably would not go well for him if he did... scott From wbailey at satelliteintelligencegroup.com Wed Mar 27 21:46:05 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Mar 2013 21:46:05 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <20130327145444.A9FF4584@resin11.mta.everyone.net> Message-ID: Wasn't there a ton of drama with the SpamHaus guys a year or so ago regarding RBL's on NANOG? On 3/27/13 2:54 PM, "Scott Weeks" wrote: > >--- bill at herrin.us wrote: >From: William Herrin > >According to the New York Times it was 300 gbps and Cyberbunker was the >bad guy. >http://www.nytimes.com/2013/03/27/technology/internet/online-dispute-becom >es-internet-snarling-attack.html?pagewanted=all&_r=0 >----------------------------------------- > >Got a link that we don't have to allow cookies and have to create an >account to read? >------------------------------------------------------------ > > >I found it using startpage.com's proxy and pasted it below for >others that don't want to create accounts and all: > > >A squabble between a group fighting spam and a Dutch company that hosts >Web sites said to be sending spam has escalated into one of the largest >computer attacks on the Internet, causing widespread congestion and >jamming crucial infrastructure around the world, John Markoff and Nicole >Perlroth write on Wednesday in The New York Times. > >Millions of ordinary Internet users have experienced delays in services >like Netflix or could not reach a particular Web site for a short time. >However, for the Internet engineers who run the global network, the >problem is more worrisome. The attacks are becoming increasingly >powerful, and computer security experts worry that if they continue to >escalate, people may not be able to reach basic Internet services, like >e-mail and online banking. > >The dispute started when the spam-fighting group, called Spamhaus, added >the Dutch company Cyberbunker to its blacklist, which is used by e-mail >providers to weed out spam. Cyberbunker, named for its headquarters, a >five-story former NATO bunker, offers hosting services to any Web site >?except child porn and anything related to terrorism,? according to its >Web site. > >A spokesman for Spamhaus, which is based in Europe, said the attacks >began on March 19, but had not stopped the group from distributing its >blacklist. > >Patrick Gilmore, chief architect at Akamai Networks, a digital content >provider, said Spamhaus?s role was to generate a list of Internet >spammers. Of Cyberbunker, he added: ?These guys are just mad. To be >frank, they got caught. They think they should be allowed to spam.? > >Mr. Gilmore said that the attacks, which are generated by swarms of >computers called botnets, concentrate data streams that are larger than >the Internet connections of entire countries. He likened the technique, >which uses a long-known flaw in the Internet?s basic plumbing, to using a >machine gun to spray an entire crowd when the intent is to kill one >person. The so-called distributed denial of service, or DDoS, attacks >have reached previously unknown magnitudes, growing to a data stream of >300 billion bits per second. > >Questioned about the attacks, Sven Olaf Kamphuis, an Internet activist >who said he was a spokesman for the attackers, said in an online message >that, ?We are aware that this is one of the largest DDoS attacks the >world had publicly seen.? Mr. Kamphuis said Cyberbunker was retaliating >against Spamhaus for ?abusing their influence.? > > >scott From neil at domino.org Wed Mar 27 21:47:59 2013 From: neil at domino.org (Neil J. McRae) Date: Wed, 27 Mar 2013 21:47:59 +0000 Subject: Line cut in Mediterranean? In-Reply-To: References: <8A84F8DB3EFEB94293B800F287084ECA22661407@mbx028-e1-va-4.exch028.domain.local>, Message-ID: <24F8E79A-CD37-40BE-AAFF-AF2AB01DA8D8@domino.org> quite a few EU to India cables are impacted right now 4/7 down. Sent from my iPad On 27 Mar 2013, at 18:14, "Aftab Siddiqui" wrote: > Well, it's not just SMW4 outage, we've been witnessing serious issues on > IMEWE for couple of weeks now and this outages just made it worse. > So, right now most of the traffic taking east bound routes. > Who needs DDoS at this stage, these links are already chocked up :) > >> Maybe it was because of this: Global Internet Slows after 'biggest attack >> in history' >> http://www.bbc.co.uk/news/technology-21954636 > > > -- > Regards, > > Aftab A. Siddiqui > From dot at dotat.at Wed Mar 27 21:49:17 2013 From: dot at dotat.at (Tony Finch) Date: Wed, 27 Mar 2013 21:49:17 +0000 Subject: Open Resolver Problems In-Reply-To: <51530632.3020402@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> <51530632.3020402@brightok.net> Message-ID: Jack Bates wrote: > You'll also find that [DNS RRL] serves little purpose. In my experience it works extremely well. Yes it is possible to work around it, but you still need to stop the attacks that are happening now. It is good to make the attacker's job harder. > 1) tcp RRL pushes legitimate clients to TCP if they get muddled up with attack traffic. > 2) require all requests to pad out to maximum response I expect that is as easy to deploy as BCP38, IPv6, and DNSSEC. > 3) BCP38 (in spirit) That should be deployed as well as RRL. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From neil at domino.org Wed Mar 27 21:53:21 2013 From: neil at domino.org (Neil J. McRae) Date: Wed, 27 Mar 2013 21:53:21 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> References: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> Message-ID: that article is absolute rubbish. take with large pinch of salt, rockstar in hamster outfit type nonsense. $dayjob didn't lose any traffic during the period, some guys where affected because of the lottery of being on the same switch as couldfare. regards, Neil. On 27 Mar 2013, at 18:45, "Jay Ashworth" wrote: > http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet > > Yes: 120 gigabits/second, primarily of DNS amplification traffic. > > Still think it's optional to implement BCP38 pervasively? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > > From jbates at brightok.net Wed Mar 27 21:59:16 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Mar 2013 16:59:16 -0500 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> <51530632.3020402@brightok.net> Message-ID: <51536BB4.5070101@brightok.net> On 3/27/2013 4:49 PM, Tony Finch wrote: > Jack Bates wrote: > >> 3) BCP38 (in spirit) > That should be deployed as well as RRL. > > Tony. If BCP38 was properly deployed, what would be the purpose of RRL outside of misbehaving clients or direct attacks against that one server? We already know the fix for spoofing. Trying to tweak every service that spoofing effectively takes advantage of will not be a winning game. Sending legitimate clients to TCP is also a losing game. DNS is UDP for a reason. The infrastructure to switch it to TCP is prohibitive and completely destroys the anycast mechanisms. Jack From Valdis.Kletnieks at vt.edu Wed Mar 27 21:59:51 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 Mar 2013 17:59:51 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Wed, 27 Mar 2013 14:19:05 -0700." References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> Message-ID: <21236.1364421591@turing-police.cc.vt.edu> On Wed, 27 Mar 2013 14:19:05 -0700, Paul Ferguson said: > And there may even be some stick approaches to accompany the carrot, > but some awareness is going to have to happen. > > Sing it from the mountain tops. http://www.sans.org/dosstep/roadmap.php Note the date. Note the list of recommendations. Note the flat spot on my forehead from continual pounding against vertical surfaces. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jason at ackley.net Wed Mar 27 22:10:10 2013 From: jason at ackley.net (Jason Ackley) Date: Wed, 27 Mar 2013 17:10:10 -0500 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> Message-ID: On Wed, Mar 27, 2013 at 4:19 PM, Paul Ferguson wrote: > Some people are going to have to step and add a few thousand more > frequent flier miles and get out to various geographic constituencies, > at various events, and start talking about this. And we need a lot > more people on board. Nation & international campaigns, etc. > > Agree 100%. One thing that I will mention is a subtle issue that needs more thought. I think one of the challenges for this is answering the question of 'How does this make it better for my network on day one?' . Well , it doesn't for the majority of impact that people may be seeing. For example - Let us say someone is not currently running a fully BCP38-compliant network (shame on them, blah blah). They can do the remaining work to fix this in XXX hours at YYY cost. The issue for them may be that they are the *destination* of the attacks that leverage non-BCP38 compliant networks. So even after investing XXX hours and YYY dollars it doesn't 'cure' the majority of the problems for them related to spoofing. So any spend on this is not a 'fix' as much as it is a 'fix for others'. (which certainly still needs to be done , don't get me wrong!) Spoofing remains a problem until *everyone* gets it done or there is enough motivation to get it done without benefit to your own network. If Network_Zed is the last to go BCP38-complaint in 2023 , then the rest of the internet is still vulnerable to the nasty items that can take place from the Network_Zed network until that time. Accepting that I think we need to find ways to make it where it stays on the radar - as has been suggested via walls of shame, RIR pressure, etc. Perhaps 'spoofing fees' etc ? I hate to have an approach of 'fix this or I will hit you with this stick!' - but this has got to stop.. OK, back to my hole watching all the presumably spoofed incoming traffic that happens to be on udp/53 and looking for ANY? isc.org :-) -- jason From ahebert at pubnix.net Wed Mar 27 22:19:57 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 27 Mar 2013 18:19:57 -0400 Subject: BCP38 needs advertising In-Reply-To: References: <51530E4D.7000901@brightok.net> <515322D0.4030006@pubnix.net> <51533450.6070901@gmail.com> Message-ID: <5153708D.90201@pubnix.net> Noted. But today's contribution by Eric M. Caroll might end up on the front page =D. I got the domains... Now I just need a few free hours to setup something useful. As always, don't be shy to drop me contribution offlist. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/27/13 14:31, Paul Ferguson wrote: > But of course. :-) > > Also, just saw this: > > http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet > > - ferg > > On Wed, Mar 27, 2013 at 11:02 AM, Arturo Servin wrote: > >> And do not forget .... >> >> http://tools.ietf.org/html/bcp38 >> >> :) >> >> -as >> >> >> On 3/27/13 2:17 PM, Paul Ferguson wrote: >>> Please reference: >>> >>> http://openresolverproject.org/ >>> http://spoofer.csail.mit.edu/ >>> http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack >>> >>> ...and anything else to raise the awareness level. >>> >>> Thanks, >>> >>> - ferg (co-perpetrator of BCP38) :-) >>> >>> On Wed, Mar 27, 2013 at 9:48 AM, Alain Hebert wrote: >>> >>>> bcp38.org coming soon =D >>>> >>>> ----- >>>> Alain Hebert ahebert at pubnix.net >>>> PubNIX Inc. >>>> 50 boul. St-Charles >>>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >>>> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >>>> >>>> On 03/27/13 11:20, Jack Bates wrote: >>>>> Outside of needing more details and examples, BCP38 could use more >>>>> advertising. >>>>> >>>>> The best option, if they would accept it, is to have all RIRs mention >>>>> BCP38 as well as require that mention of BCP38 be included in all IP >>>>> justification requests to customers (so that those who receive >>>>> netblocks from their ISPs are also aware of it). >>>>> >>>>> For ARIN, at least, having it mentioned in the attestation process >>>>> wouldn't be a bad idea. At least someone of management would be aware >>>>> of it. >>>>> >>>>> The only issue is see concerning the RIRs is that they may object to >>>>> it being out of scope to their duties. However, informing people of >>>>> something is not requiring implementation of something. On the other >>>>> hand, we know that there are a great number of networks that don't >>>>> participate with the community at large and may have no idea about >>>>> BCP38 and why it is important. >>>>> >>>>> >>>>> Jack >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> > > From sethm at rollernet.us Wed Mar 27 22:22:37 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 27 Mar 2013 15:22:37 -0700 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: References: Message-ID: <5153712D.4080500@rollernet.us> On 3/27/13 2:46 PM, Warren Bailey wrote: > Wasn't there a ton of drama with the SpamHaus guys a year or so ago > regarding RBL's on NANOG? > There's always someone who publicly flips out over being listed by a major DNSBL at least once a year. ~Seth From rsk at gsp.org Wed Mar 27 22:25:40 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 27 Mar 2013 18:25:40 -0400 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: References: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> <8DE012AC-6B51-48A7-8609-52D9BC2883BB@2600hz.com> Message-ID: <20130327222540.GA16879@gsp.org> On Wed, Mar 27, 2013 at 12:30:43PM -0700, Paul Ferguson wrote: > Consider this a call-to-arms, in all aspects. Please. +1 No. Not enough. +10. But...our collective track record in responding in a timely and effective fashion to such calls is not very good. Twenty years ago we could have killed spam. Ten years ago we could have killed botnets. We didn't do either (despite *numerous* warnings of how bad it would get -- warnings dismissed as unduly pessimistic at the time, now viewed as naively optimistic) and in part because we didn't...now we have this. There are entire business sectors which now exist just to make up for our failure to do those things when we had the chance. And while there are good and smart people in those doing some good and smart things, all those sectors are really doing are (a) costing us a ton of money and (b) helping us tread water. I suggest we fix these problems before we wind up creating yet another market for yet another several billion dollars that could be better used on making forward progress. Or worse, before some government somewhere decides to "solve" this problem for a value of "solved" involving (shudder) legislation. --rsk From jcurran at arin.net Wed Mar 27 22:31:32 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 22:31:32 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327205429.2E7C931A1578@drugs.dv.isc.org> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA544FA@CHAXCH01.corp.arin.net> On Mar 27, 2013, at 4:54 PM, Mark Andrews wrote: >> Umm... How many North American ISP's/datacenters/web hosting firms were >> aware of the BCP 38 development as it was on-going, and participated in >> some manner in its review? ... > > I'd say enough were aware. :-) > > 8. Acknowledgments > > The North American Network Operators Group (NANOG) [5] group as a > whole deserves special credit for openly discussing these issues and > actively seeking possible solutions. Also, thanks to Justin Newton > [Priori Networks] and Steve Bielagus [IronBridge Networks]. for > their comments and contributions. Mark - That's plenty of consideration for voluntary efforts (which is what we've tried to date in various forums with rather limited success...) Whether that's sufficient notice and consideration on which to base mandatory requirements from a public policy perspective is not clear. Frankly, I would suggest that NANOG document a best common operating practice (BCOP) based on BCP38 (written at a somewhat higher level which describes what types of connections ingress filtering it applies to, e.g. consumer edge, business, transit, etc.; whether it should be just a customer default or an absolute requirement, etc.), and then holding an approval process to make the result a NANOG BCOP... If this were done in a fairly formal manner, the result would be closer to the prior example (National Fire Protection Association code) and would far more convincing both in aiding governments to pick up this cause in the region, as well as encouraging similar efforts elsewhere. FYI, /John From nicholas.hatch at gmail.com Wed Mar 27 22:37:31 2013 From: nicholas.hatch at gmail.com (nick hatch) Date: Wed, 27 Mar 2013 15:37:31 -0700 Subject: Verizon Wireless security contact needed Message-ID: Hi all, I just discovered a somewhat-exigent issue which affects confidentiality for Verizon Wireless customers. (PSTN / Voice) I'm failing at trying to find a Verizon Wireless security contact through normal means. If someone can provide a contact off-list it would be much appreciated. Thanks, -Nick From wbailey at satelliteintelligencegroup.com Wed Mar 27 22:40:51 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Mar 2013 22:40:51 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FA544FA@CHAXCH01.corp.arin.net> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org>, <8DA1853CE466B041B104C1CAEE00B3748FA544FA@CHAXCH01.corp.arin.net> Message-ID: I think the media fire about this will enlighten many c level executives. After that, it's a matter of them saying "go do this". You can't get any traction if there isn't a perceived issue, from what I've seen anyways. I still think the ipv4 to 6 transition will require media outlets running special coverage on the end of the Internet because we broke it by not addressing issues. I've shouted from roof tops on various occasions, only to hear months later about how we should have seen something coming. Get CNN to run Nanog has a solution and watch the hordes gather. People slow down on the freeway to see an accident, they'll slow down long enough to see what's happened and drive off. When their house is on fire, it's a completely different story. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: John Curran Date: 03/27/2013 3:33 PM (GMT-08:00) To: Mark Andrews Cc: NANOG Subject: Re: BCP38 - Internet Death Penalty On Mar 27, 2013, at 4:54 PM, Mark Andrews wrote: >> Umm... How many North American ISP's/datacenters/web hosting firms were >> aware of the BCP 38 development as it was on-going, and participated in >> some manner in its review? ... > > I'd say enough were aware. :-) > > 8. Acknowledgments > > The North American Network Operators Group (NANOG) [5] group as a > whole deserves special credit for openly discussing these issues and > actively seeking possible solutions. Also, thanks to Justin Newton > [Priori Networks] and Steve Bielagus [IronBridge Networks]. for > their comments and contributions. Mark - That's plenty of consideration for voluntary efforts (which is what we've tried to date in various forums with rather limited success...) Whether that's sufficient notice and consideration on which to base mandatory requirements from a public policy perspective is not clear. Frankly, I would suggest that NANOG document a best common operating practice (BCOP) based on BCP38 (written at a somewhat higher level which describes what types of connections ingress filtering it applies to, e.g. consumer edge, business, transit, etc.; whether it should be just a customer default or an absolute requirement, etc.), and then holding an approval process to make the result a NANOG BCOP... If this were done in a fairly formal manner, the result would be closer to the prior example (National Fire Protection Association code) and would far more convincing both in aiding governments to pick up this cause in the region, as well as encouraging similar efforts elsewhere. FYI, /John From neil at domino.org Wed Mar 27 22:41:50 2013 From: neil at domino.org (Neil J. McRae) Date: Wed, 27 Mar 2013 22:41:50 +0000 Subject: Line cut in Mediterranean? In-Reply-To: <24F8E79A-CD37-40BE-AAFF-AF2AB01DA8D8@domino.org> References: <8A84F8DB3EFEB94293B800F287084ECA22661407@mbx028-e1-va-4.exch028.domain.local>, , <24F8E79A-CD37-40BE-AAFF-AF2AB01DA8D8@domino.org> Message-ID: Via renesys http://www.washingtonpost.com/world/middle_east/egypt-naval-forces-capture-3-scuba-divers-trying-to-sabotage-undersea-internet-cable/2013/03/27/dd2975ec-9725-11e2-a976-7eb906f9ed9b_story.html Sent from my iPhone On 27 Mar 2013, at 21:53, "Neil J. McRae" > wrote: quite a few EU to India cables are impacted right now 4/7 down. Sent from my iPad On 27 Mar 2013, at 18:14, "Aftab Siddiqui" > wrote: Well, it's not just SMW4 outage, we've been witnessing serious issues on IMEWE for couple of weeks now and this outages just made it worse. So, right now most of the traffic taking east bound routes. Who needs DDoS at this stage, these links are already chocked up :) Maybe it was because of this: Global Internet Slows after 'biggest attack in history' http://www.bbc.co.uk/news/technology-21954636 -- Regards, Aftab A. Siddiqui From jcurran at arin.net Wed Mar 27 22:45:07 2013 From: jcurran at arin.net (John Curran) Date: Wed, 27 Mar 2013 22:45:07 +0000 Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" In-Reply-To: <20130327222540.GA16879@gsp.org> References: <4548283.11234.1364409866426.JavaMail.root@benjamin.baylink.com> <8DE012AC-6B51-48A7-8609-52D9BC2883BB@2600hz.com> <20130327222540.GA16879@gsp.org> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FA54660@CHAXCH01.corp.arin.net> On Mar 27, 2013, at 6:25 PM, Rich Kulawiec wrote: > Or worse, before some government somewhere decides to "solve" this > problem for a value of "solved" involving (shudder) legislation. In general, governments have avoided regulating various aspects of the Internet, in part because of lack of understanding and in part because the community keeps telling them that trying to regulate won't work because of its decentralized nature. As the Internet becomes increasingly important to each country's economy and its citizens, the status quo is not likely to continue. The real question is, when governments do decide to try and help "improve the Internet", who will they be listening to, and will the operator community have spoken with a clear enough voice in these matters on what actually would make for an improvement? FYI, /John From dot at dotat.at Wed Mar 27 22:51:53 2013 From: dot at dotat.at (Tony Finch) Date: Wed, 27 Mar 2013 22:51:53 +0000 Subject: Open Resolver Problems In-Reply-To: <51536BB4.5070101@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> <51530632.3020402@brightok.net> <51536BB4.5070101@brightok.net> Message-ID: Jack Bates wrote: > > If BCP38 was properly deployed, what would be the purpose of RRL outside of > misbehaving clients or direct attacks against that one server? If fictional scenario, irrelevant answer. Given the current situation, efforts to deploy both RRL and BCP38 in parallel will reduce the mess we are in. Let's race to see who gets to full deployment first. > The infrastructure to switch it to TCP is prohibitive and completely > destroys the anycast mechanisms. Yeah, anycast for HTTP doesn't work at all. Just ask CloudFlare. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jabley at hopcount.ca Wed Mar 27 23:00:12 2013 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 27 Mar 2013 19:00:12 -0400 Subject: Open Resolver Problems In-Reply-To: <51536BB4.5070101@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> <51530632.3020402@brightok.net> <51536BB4.5070101@brightok.net> Message-ID: On 2013-03-27, at 17:59, Jack Bates wrote: > DNS is UDP for a reason. Not a great reason, as it turns out. But hindsight is 20/20. > The infrastructure to switch it to TCP is prohibitive and completely destroys the anycast mechanisms. No. Joe From marka at isc.org Wed Mar 27 23:01:34 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 28 Mar 2013 10:01:34 +1100 Subject: BCP38 - Internet Death Penalty In-Reply-To: Your message of "Wed, 27 Mar 2013 17:10:10 CDT." References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> Message-ID: <20130327230134.A948031A1DF7@drugs.dv.isc.org> In message , Jason Ackley writes: > > On Wed, Mar 27, 2013 at 4:19 PM, Paul Ferguson wrote: > > > > Some people are going to have to step and add a few thousand more > > frequent flier miles and get out to various geographic constituencies, > > at various events, and start talking about this. And we need a lot > > more people on board. Nation & international campaigns, etc. > > > > > Agree 100%. > > One thing that I will mention is a subtle issue that needs more thought. I > think one of the challenges for this is answering the question of 'How does > this make it better for my network on day one?' . Well , it doesn't for > the majority of impact that people may be seeing. Firstly you protect your customers from your other customer machines that are compromised. Secondly you reduce your legal liability. Third you can use it to improve the reputation of your network. > For example - Let us say someone is not currently running a fully > BCP38-compliant network (shame on them, blah blah). They can do the > remaining work to fix this in XXX hours at YYY cost. > > The issue for them may be that they are the *destination* of the attacks > that leverage non-BCP38 compliant networks. So even after investing XXX > hours and YYY dollars it doesn't 'cure' the majority of the problems for > them related to spoofing. So any spend on this is not a 'fix' as much as it > is a 'fix for others'. (which certainly still needs to be done , don't get > me wrong!) > > Spoofing remains a problem until *everyone* gets it done or there is > enough motivation to get it done without benefit to your own network. It's a reducing problem as more networks filter. > If Network_Zed is the last to go BCP38-complaint in 2023 , then the rest of > the internet is still vulnerable to the nasty items that can take place > from the Network_Zed network until that time. Or the rest of the world can just shun Network_Zed. > Accepting that I think we need to find ways to make it where it stays on > the radar - as has been suggested via walls of shame, RIR pressure, etc. > Perhaps 'spoofing fees' etc ? > > I hate to have an approach of 'fix this or I will hit you with this stick!' > - but this has got to stop.. > > OK, back to my hole watching all the presumably spoofed incoming traffic > that happens to be on udp/53 and looking for ANY? isc.org :-) Which you can chase back to offending sources and complain to them about. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From freedman at freedman.net Wed Mar 27 23:03:56 2013 From: freedman at freedman.net (Avi Freedman) Date: Wed, 27 Mar 2013 19:03:56 -0400 (EDT) Subject: Cloudflare, and the 120Gbps DDOS "that almost broke the Internet" Message-ID: <20130327230357.115EC5500008A@freedman.net> An important question... I recall a peering panel at an ISPCON in 1996 when the current Peering Badguys, BBN, were represented by John, who listened to a ton of bitching for an hour about the unfairness of it all and said (paraphrasing)... "I understand you all have your opinions and desires but I just want to point out one thing. It is now 1996, 2 years after the widespread adoption of the web, and in every city in the US there are at least two ISPs happily providing unlimited {dialup} access for under $20/mo. What do you think we'd have if it were run or regulated by the government?" Luckily, many bureaucrats and politicians in our government do understand that. And so far The Community has been able to put pressure on international bodies and other governments don't have the clout. Hopefully that remains the case for some time. Avi > In general, governments have avoided regulating various aspects of > the Internet, in part because of lack of understanding and in part > because the community keeps telling them that trying to regulate > won't work because of its decentralized nature. As the Internet > becomes increasingly important to each country's economy and its > citizens, the status quo is not likely to continue. > > The real question is, when governments do decide to try and help > "improve the Internet", who will they be listening to, and will > the operator community have spoken with a clear enough voice in > these matters on what actually would make for an improvement? > > FYI, > /John From mysidia at gmail.com Wed Mar 27 23:23:30 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 27 Mar 2013 18:23:30 -0500 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: On 3/26/13, Dobbins, Roland wrote: > On Mar 26, 2013, at 9:51 PM, Jay Ashworth wrote: Perhaps you should reframe your strategy as "security problem", and show how providers have implemented BCP38, how it is such a common practice, that not implementing BCP38 may fall short of the minimum standard of due care required to avoid liability, in case your network is abused to launch an attack.. Incurs possible legal risks that should be reviewd by lawyers, due to possible liability in facilitating a DoS attack. That may be better at persuading your CEOs of large SPs than "It's just good engineering"; it's not that following BCP38 is just excellent practice. It's also that ignoring BCP38 in some circumstances might be extremely poor, even negligent practice. Possibly Develop an industry certification/accreditation based on network engineering practices, and make it potentially so that service providers want to carry it. Then their marketing people can display their "See our network is more secure and reliable" logo on the website, and pressure other networks to seek 3rd party qualification; include BCP38 as one of several criteria, "designed to help reduce the degree of malicious activity, unmitigated DoS incidents, instability, or poor/inconsistent user experience". If enough networks carry some sort of mark of quality, then maybe it becomes meaningful as a tool persuasion: there may be a smaller quantity of demand for the purchase of services from networks that don't carry it, unless they compensate by lowering their price. While you're at it, include as recommended practices, and provide multiple levels of "Verified good network neighbor" status: o 3rd party audited practices with regards to responsiveness and cooperation by contacts to address abuse and connectivity issues. o Requirement the network have a policy of assisting with the mitigation of attack traversing any peers or customers, through required extensive network information sharing. o Truthful representation of service in all marketing materials. o No "banned" internet protocols or ports, (e.g. "Our network doesn't allow SSH protocol"); no NAT'ing by the SP. o A no-spamming policy, a no-repeated-failed-login policy, a no port scanning policy, a no DoS policy that includes requirement the SP investigate spam or other complaints and take sufficient actions to disable offending hosts or networks, or ensure further spam is blocked.. o Appropriate filtering of incoming bgp announcements. o Accurate WHOIS information, listing the actual contact, no 3rd party or intermediary for number resources, domains, etc. o Easily accessible and responsive technical and abuse contacts for all services. o Not subverting or altering DNS query responses, or other packets, as they cross the network; for example, not offering name lookup servers that claim to provide DNS service, but covertly rewrite or capture NXDOMAIN or other responses, sending an altered response instead. >> Do the engineering heads at the top 10 tier-1/2 carriers carry enough >> water to make that sale to the CEOs? > Unfortunately, no - else it would've come to pass quite some time ago. -- -JH From arturo.servin at gmail.com Wed Mar 27 23:23:44 2013 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 27 Mar 2013 20:23:44 -0300 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> Message-ID: <51537F80.3030203@gmail.com> I am afraid you are right. It is going to cost us money and time, but unfortunately I do not see another way out. /as On 3/27/13 6:19 PM, Paul Ferguson wrote: > As I mentioned on another list earlier today, let's face it -- this is > going to require a large-scale, very public, and probably multi-year > education & awareness effort (as if 13+ years isn't enough already!). From smb at cs.columbia.edu Wed Mar 27 23:53:18 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 27 Mar 2013 19:53:18 -0400 Subject: Line cut in Mediterranean? In-Reply-To: References: <8A84F8DB3EFEB94293B800F287084ECA22661407@mbx028-e1-va-4.exch028.domain.local>, , <24F8E79A-CD37-40BE-AAFF-AF2AB01DA8D8@domino.org> Message-ID: The BBC has a similar story: http://www.bbc.co.uk/news/world-middle-east-21963100 On Mar 27, 2013, at 6:41 PM, Neil J. McRae wrote: > Via renesys > > http://www.washingtonpost.com/world/middle_east/egypt-naval-forces-capture-3-scuba-divers-trying-to-sabotage-undersea-internet-cable/2013/03/27/dd2975ec-9725-11e2-a976-7eb906f9ed9b_story.html > > > Sent from my iPhone > > On 27 Mar 2013, at 21:53, "Neil J. McRae" > wrote: > > quite a few EU to India cables are impacted right now 4/7 down. > > Sent from my iPad > > On 27 Mar 2013, at 18:14, "Aftab Siddiqui" > wrote: > > Well, it's not just SMW4 outage, we've been witnessing serious issues on > IMEWE for couple of weeks now and this outages just made it worse. > So, right now most of the traffic taking east bound routes. > Who needs DDoS at this stage, these links are already chocked up :) > > Maybe it was because of this: Global Internet Slows after 'biggest attack > in history' > http://www.bbc.co.uk/news/technology-21954636 > > > -- > Regards, > > Aftab A. Siddiqui > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb From Valdis.Kletnieks at vt.edu Thu Mar 28 00:16:57 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 27 Mar 2013 20:16:57 -0400 Subject: Open Resolver Problems In-Reply-To: Your message of "Wed, 27 Mar 2013 16:59:16 -0500." <51536BB4.5070101@brightok.net> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <5152FB65.9060309@brightok.net> <51530632.3020402@brightok.net> <51536BB4.5070101@brightok.net> Message-ID: <27774.1364429817@turing-police.cc.vt.edu> On Wed, 27 Mar 2013 16:59:16 -0500, Jack Bates said: > On 3/27/2013 4:49 PM, Tony Finch wrote: > > Jack Bates wrote: > > > >> 3) BCP38 (in spirit) > > That should be deployed as well as RRL. > > > > Tony. > > If BCP38 was properly deployed, what would be the purpose of RRL outside > of misbehaving clients or direct attacks against that one server? It would be quite sufficient just for the misbehaving clients aspect. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From rdobbins at arbor.net Thu Mar 28 04:18:23 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 28 Mar 2013 04:18:23 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327230134.A948031A1DF7@drugs.dv.isc.org> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> <20130327230134.A948031A1DF7@drugs.dv.isc.org> Message-ID: On Mar 28, 2013, at 6:01 AM, Mark Andrews wrote: > Secondly you reduce your legal liability. IANAL, but this has yet to be proven, AFAIK. One approach that hasn't been tried, to my knowledge, is educating the insurance companies about how they can potentially reduce *their* liability for payouts by requiring that real, actionable security BCPs such as BCP38/84, running closed resolvers, implementing iACLs, et. al. are implemented by those they insure. Does anyone have insight into examples of how insurance policies have been paid out as a result of losses stemming from availability-related security events? Another approach is educating the 'risk management' and 'business continuity' communities about the risks and how to mitigate them, and how doing so enhances business continuity. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From fergdawgster at gmail.com Thu Mar 28 04:42:27 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 27 Mar 2013 21:42:27 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> <20130327230134.A948031A1DF7@drugs.dv.isc.org> Message-ID: On Wed, Mar 27, 2013 at 9:18 PM, Dobbins, Roland wrote: > > On Mar 28, 2013, at 6:01 AM, Mark Andrews wrote: > >> Secondly you reduce your legal liability. > > IANAL, but this has yet to be proven, AFAIK. > > One approach that hasn't been tried, to my knowledge, is educating the insurance companies about how they can potentially reduce *their* liability for payouts by requiring that real, actionable security BCPs such as BCP38/84, running closed resolvers, implementing iACLs, et. al. are implemented by those they insure. > > Does anyone have insight into examples of how insurance policies have been paid out as a result of losses stemming from availability-related security events? > > Another approach is educating the 'risk management' and 'business continuity' communities about the risks and how to mitigate them, and how doing so enhances business continuity. > Funny you should mention it. Actually, I do know someone who is in the "digital insurance" (for lack of a better term) business, and although I just met them a few weeks ago, somehow I get the feeling that it is a growth industry. I'm semi --> :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From rdobbins at arbor.net Thu Mar 28 04:56:53 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 28 Mar 2013 04:56:53 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net> <20130327205429.2E7C931A1578@drugs.dv.isc.org> <20130327230134.A948031A1DF7@drugs.dv.isc.org> Message-ID: <63DCD749-7BF9-435C-A6A1-4CDFA1DFC511@arbor.net> On Mar 28, 2013, at 11:42 AM, Paul Ferguson wrote: > Actually, I do know someone who is in the "digital insurance" (for lack of a better term) business, and although I just met them a few weeks ago, somehow I get the feeling that it is a growth industry. I think this concept applies to traditional insurers, as well as newer tech-focused insurers, as they're all potentially on the hook for payouts due to business-disrupting events of all sorts - including DDoS-induced losses. Perhaps your friend can provide some insight and/or pointers on this general topic? Ideally, it would be a Good Thing to engage with the various actuarial organizations in order to brief them at properly-calibrated level of detail in order to educate them on this topic, followed by engagement with specific insurers. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From randy at psg.com Thu Mar 28 06:46:25 2013 From: randy at psg.com (Randy Bush) Date: Thu, 28 Mar 2013 15:46:25 +0900 Subject: alexandria cable cutters? Message-ID: nyt reports capture of scuba divers attempting to cut telecom egypt undersea fiber. http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html randy From nanog at mitteilung.com Thu Mar 28 06:48:33 2013 From: nanog at mitteilung.com (nanog at mitteilung.com) Date: Thu, 28 Mar 2013 07:48:33 +0100 Subject: Open Resolver Problems In-Reply-To: <51522973.9010901@pubnix.net> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> <5151C0EC.7000008@foobar.org> <51522973.9010901@pubnix.net> Message-ID: <5153E7C1.2090308@mitteilung.com> Am 27.03.2013 00:04, schrieb Alain Hebert: > > We're on it here... > > Been using the work of http://bindguard.activezone.de/ to watch it =D > > There is a lot of targets... kinda hard to figure out the goal... > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > A new export of my blocking list is now available. Over 1500 bad hosts are now in my bogon configuration and every day it be more and more ... See here: http://bindguard.activezone.de/bogon-list.txt In the last 10 weeks are 749 new blocked hosts [ result of a small environment ] :-( Mar 28 07:40:56 BindGuard: Stats (PID 34874): 761 entries, 525851 updates, 885070 ignored, 749 blocked, 1486207 events parsed. Mar 28 07:40:56 BindGuard: Used Memory: 0.24 MByte (Index: 131072 Bytes, Free: 15624 / Entries: 125670 Bytes) Mar 28 07:40:56 BindGuard: Version 0.69, Uptime: 10 weeks, 6 days, 23 hours, 12 minutes, 38 seconds Regards, Markus From nanog at deman.com Thu Mar 28 08:11:07 2013 From: nanog at deman.com (Michael DeMan) Date: Thu, 28 Mar 2013 01:11:07 -0700 Subject: Can we not just fix it? WAS:Re: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: AsI think as we all know the deficiency is the design of the DNS system overall. No disrespect to anybody, but lots of companies make money off of the design deficiencies and try to position themselves as offering 'value add services' or something similar. Basically they make money because the inherent design of the DNS system is the antithesis of being able to deliver information on a best effort basis. Entire 'value add' economic ecosystems are created with these kinds of things and once it is done, it is extremely difficult to un-do. If the endpoint is not available or is unreliable, this is all well understood and 100% captured in the modern implementations of the Internet with it be OSI or TCP/IP and even with numerous extensions from there. The fundamental cause and source of failure for these kinds of attacks comes from the the way the DNS (and lets not even get into 'valid' SSL certs) is designed. It is fundamentally flawed. I am sure there were plenty of political reasons for it to have ended up this way instead of being done in a more robust fashion? For all the gripes and complaints - all I see is complaints of the symptoms and nobody calling out the original cause of the disease? On Mar 27, 2013, at 6:47 AM, William Herrin wrote: > On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka wrote: >> Authoritative DNS servers need to implement rate limiting. (a client >> shouldn't query you twice for the same thing within its TTL). > > Right now that's a complaint for the mainstream software authors, not > for the system operators. When the version of Bind in Debian Stable > implements this feature, I'll surely turn it on. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From drc at virtualized.org Thu Mar 28 08:27:58 2013 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Mar 2013 22:27:58 -1000 Subject: Can we not just fix it? WAS:Re: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <1053BF6D-2E1F-4302-9160-BCE424D6EC86@virtualized.org> On Mar 27, 2013, at 10:11 PM, Michael DeMan wrote: > AsI think as we all know the deficiency is the design of the DNS system overall. One of the largest DDoS attacks I've witnessed was SNMP-based, walking entire OID sub-trees (with spoofed source addresses) across thousands of CPEs that defaulted to allowing SNMP queries over the WAN interface. "Oops". Topped out around 70 Gbps if I remember correctly. No DNS involved. > The fundamental cause and source of failure for these kinds of attacks comes from the the way the DNS (and lets not even get into 'valid' SSL certs) is designed. Not really. You're at least one layer too high. (not even going to question what "'valid' SSL certs" have to do with the DNS) > It is fundamentally flawed. I am sure there were plenty of political reasons for it to have ended up this way instead of being done in a more robust fashion? I suspect if you look at the number of queries per second the best TCP stacks could handle circa mid-1980s and compare that number to an average UDP stack, you might see an actual reason instead of conspiracy theories. > For all the gripes and complaints - all I see is complaints of the symptoms and nobody calling out the original cause of the disease? You mean connectionless datagram transmission without validation of packet source? Regards, -drc From saku at ytti.fi Thu Mar 28 09:58:41 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 28 Mar 2013 11:58:41 +0200 Subject: Can we not just fix it? WAS:Re: Open Resolver Problems In-Reply-To: <1053BF6D-2E1F-4302-9160-BCE424D6EC86@virtualized.org> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <1053BF6D-2E1F-4302-9160-BCE424D6EC86@virtualized.org> Message-ID: <20130328095841.GA7515@pob.ytti.fi> On (2013-03-27 22:27 -1000), David Conrad wrote: > One of the largest DDoS attacks I've witnessed was SNMP-based, walking entire OID sub-trees (with spoofed source addresses) across thousands of CPEs that defaulted to allowing SNMP queries over the WAN interface. "Oops". Topped out around 70 Gbps if I remember correctly. No DNS involved. Wonderful data point. Services are not the problem. Open recursors are not the problem, there are millions of them, and even if we close all of them, attack vector remains almost identically the same, as due to DNSSEC it's easy to find large RR in authorative servers. I think most everyone is missing the key notion that BCP38 does not need to be deployed my millions. Most people are NOT doing ACL filtering towards their transit customers, Tier1<->Tier2 cannot do it (strict IRR is not practical). Tier2<->Tier3 can do it, and should do it. We have about 6000 tier2 networks that we need to fix to make spooffing attack vectors impractical. It's entirely doable if we can agree that ACL towards your transit customer is BCP and start approaching/educating/helping (github scripts to do it automatically for your JunOS, IOS, TimOS, IOS-XR...) these 6000 networks. -- ++ytti From rsk at gsp.org Thu Mar 28 11:12:25 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 28 Mar 2013 07:12:25 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> References: <29802798.10948.1364309505175.JavaMail.root@benjamin.baylink.com> Message-ID: <20130328111225.GA8559@gsp.org> I think this would be a good time for me to quote the best thing I've ever read on NANOG: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie ---rsk From BECHA at ripe.net Thu Mar 28 11:52:27 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 28 Mar 2013 12:52:27 +0100 Subject: Line cut in Mediterranean? In-Reply-To: References: Message-ID: <51542EFB.7040707@ripe.net> Dear James, all, On 3/27/13 1:49 PM, James Smith wrote: > Getting reports from a third party vendor that there's been a line > cut in the Mediterranean that is affecting some Internet traffic. > Anyone have any details? a view from RIPEstat (interface to the routing data collected by RIS / RIPE NCC), comparing 4 countries, is detailed in this RIPELabs article: https://labs.ripe.net/Members/mirjam/mediterranean-cable-disruption-as-seen-in-ripestat Regards, Vesna From adam.vitkovsky at swan.sk Thu Mar 28 12:20:07 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 28 Mar 2013 13:20:07 +0100 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130327191819.GA16425@pob.ytti.fi> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> Message-ID: <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> > If you are doing strict BGP prefix-filter, it's either very easy to generate ACL while at it Yes and that is exactly what needs to become a habit for all the operators. We all do care what our neighbors advertise to us or what prefixes we accept from them. But only a few really do care whether that's actually what is leaving our neighbor's network. It's a pity that rpf is not "on" by default for interfaces over which the ebgp session is configured. adam From Valdis.Kletnieks at vt.edu Thu Mar 28 13:23:02 2013 From: Valdis.Kletnieks at vt.edu (Valdis Kletnieks) Date: Thu, 28 Mar 2013 09:23:02 -0400 Subject: So how big was it *really*? Message-ID: <39905.1364476982@turing-police.cc.vt.edu> So we all have heard the breathless news reports of how the recent urinating contest between Spamhaus and a butthurt ISP was the "biggest in history". Where would you guys put it, if measured as "percent of total worldwide available Internet bandwidth/resources"? My gut feeling is that by that metric, it didn't even make the top 20. Think back to the Morris worm, or Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. And even if you restrict the discussion to intentional targeted attacks, I'm sure we've had worse (Smurf, anybody? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From hhoffman at ip-solutions.net Thu Mar 28 13:29:04 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 28 Mar 2013 09:29:04 -0400 Subject: So how big was it *really*? In-Reply-To: <39905.1364476982@turing-police.cc.vt.edu> References: <39905.1364476982@turing-police.cc.vt.edu> Message-ID: <515445A0.2070508@ip-solutions.net> It's interesting, this just came up on gizmodo. As I said in another forum, take it for what it's worth: http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie Cheers, Harry On 03/28/2013 09:23 AM, Valdis Kletnieks wrote: > So we all have heard the breathless news reports of how the recent > urinating contest between Spamhaus and a butthurt ISP was the "biggest > in history". > > Where would you guys put it, if measured as "percent of total worldwide > available Internet bandwidth/resources"? My gut feeling is that by that > metric, it didn't even make the top 20. Think back to the Morris worm, or > Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. And > even if you restrict the discussion to intentional targeted attacks, I'm sure > we've had worse (Smurf, anybody? :) > From simon at slimey.org Thu Mar 28 13:36:03 2013 From: simon at slimey.org (Simon Lockhart) Date: Thu, 28 Mar 2013 13:36:03 +0000 Subject: So how big was it *really*? In-Reply-To: <515445A0.2070508@ip-solutions.net> References: <39905.1364476982@turing-police.cc.vt.edu> <515445A0.2070508@ip-solutions.net> Message-ID: <20130328133601.GT20231@virtual.bogons.net> On Thu Mar 28, 2013 at 09:29:04AM -0400, Harry Hoffman wrote: > It's interesting, this just came up on gizmodo. As I said in another > forum, take it for what it's worth: > > http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie And there's a (semi-)public response from one of Cloudfare's upstreams: http://cluepon.net/ras/gizmodo Simon From rdobbins at arbor.net Thu Mar 28 13:42:56 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 28 Mar 2013 13:42:56 +0000 Subject: So how big was it *really*? In-Reply-To: <515445A0.2070508@ip-solutions.net> References: <39905.1364476982@turing-police.cc.vt.edu> <515445A0.2070508@ip-solutions.net> Message-ID: <28540483-6405-4119-AC45-FB04264BD5CF@arbor.net> On Mar 28, 2013, at 8:29 PM, Harry Hoffman wrote: > http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie Yes and no. There's been quite a bit of exaggerated (and unhelpful, IMHO) hype around this entire episode from the outset; by the same token, the attacks did produce non-inconsiderable disruptive collateral effects in EMEA and APAC for various intervals, which would not likely be observed by an American sitting in his home in America watching online American content and accessing American applications and services hosted on American servers located in American IDCs in America. Some folks don't seem to grasp the whole 'global' notion of the Internet, and the facet that not everyone who uses or does something on the Internet resides in America. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bill at herrin.us Thu Mar 28 13:43:14 2013 From: bill at herrin.us (William Herrin) Date: Thu, 28 Mar 2013 09:43:14 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> Message-ID: On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky wrote: > It's a pity that rpf is not "on" by default for interfaces over which the > ebgp session is configured. Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, "It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only)" I might have agreed with you. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Thu Mar 28 13:41:37 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 Mar 2013 09:41:37 -0400 Subject: So how big was it *really*? In-Reply-To: <515445A0.2070508@ip-solutions.net> References: <39905.1364476982@turing-police.cc.vt.edu> <515445A0.2070508@ip-solutions.net> Message-ID: On Mar 28, 2013, at 9:29 AM, Harry Hoffman wrote: > It's interesting, this just came up on gizmodo. As I said in another > forum, take it for what it's worth: > > http://gizmodo.com/5992652/that-internet-war-apocalypse-is-a-lie I can't comment in detail, but there are some "lost in translation" moments with the reporting. If you look at externally observable data, something surely happened at LINX on the 23rd: https://stats.linx.net/cgi-pub/aggregate/week I think it's easy to get fully into a doom-and-gloom scenario, but even if the numerical reporting is correct there wasn't a broad impact observed similar to slammer/blaster where everyone was congested. I will say, please don't treat this as 100% hype and look at unicast-rpf and securing your DNS servers in parallel. That threat certainly is real. With 21,432,212 hosts that respond to dns queries (with the right answerl not including those that send a referral to root which is quite large), an amplification attack would be quite easy. It's somewhere around 1:173 hosts run a service that responds. That is real and clearly measurable. your bind settings to look for are: http://www.zytrax.com/books/dns/ch7/queries.html additional-from-auth yes | no ; additional-from-cache yes | no ; - Jared From rdobbins at arbor.net Thu Mar 28 13:51:26 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 28 Mar 2013 13:51:26 +0000 Subject: BCP38 - Internet Death Penalty In-Reply-To: <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> Message-ID: On Mar 28, 2013, at 7:20 PM, Adam Vitkovsky wrote: > It's a pity that rpf is not "on" by default for interfaces over which the > ebgp session is configured. As has been noted here and on cisco-nsp several times, unfortunately, there are too many instances in which enabling uRPF automagically would break things and thus overwhelm vendor support desks for network vendors to do this. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From pauldotwall at gmail.com Thu Mar 28 13:54:23 2013 From: pauldotwall at gmail.com (Paul WALL) Date: Thu, 28 Mar 2013 09:54:23 -0400 Subject: Verizon Wireless security contact needed In-Reply-To: References: Message-ID: You should get yourself a lawyer. This is what happened the last time someone from this community attempted to report a security/data breach issue to a mobile provider: http://en.wikipedia.org/wiki/Weev Drive Slow, Paul Wall On 3/27/13, nick hatch wrote: > Hi all, > > I just discovered a somewhat-exigent issue which affects > confidentiality for Verizon Wireless customers. (PSTN / Voice) > > I'm failing at trying to find a Verizon Wireless security contact > through normal means. If someone can provide a contact off-list it > would be much appreciated. > > Thanks, > > -Nick > > From neil at domino.org Thu Mar 28 14:03:52 2013 From: neil at domino.org (Neil J. McRae) Date: Thu, 28 Mar 2013 14:03:52 +0000 Subject: So how big was it *really*? In-Reply-To: Message-ID: On 28/03/2013 13:41, "Jared Mauch" wrote: >If you look at externally observable data, something surely happened at >LINX on the 23rd: > >https://stats.linx.net/cgi-pub/aggregate/week Yes, the polling server couldn't reach one of the networks - remember that there are two networks at LINX. I can tell you as one of the biggest peers at LINX if that much traffic had gone we would have known about it. >From our perspective we observed almost nothing in-terms of impact other than not being able to reach cloudflare. We need to act I totally agree. Regards, Neil. From neil at domino.org Thu Mar 28 14:14:26 2013 From: neil at domino.org (Neil J. McRae) Date: Thu, 28 Mar 2013 14:14:26 +0000 Subject: So how big was it *really*? In-Reply-To: <39905.1364476982@turing-police.cc.vt.edu> Message-ID: Surely the question is what was the impact? If I had just installed 3 new 100G iinks the day before then its going to be a lot bigger than if I didn't haven them. In my view this was a minor blip, but very well sniper rifled at Cloudflare - they have a lot of pissed off customers looking the blog they have. Folks need to fix there infrastructure so this doesn't happen though. On 28/03/2013 13:23, "Valdis Kletnieks" wrote: >So we all have heard the breathless news reports of how the recent >urinating contest between Spamhaus and a butthurt ISP was the "biggest >in history". > >Where would you guys put it, if measured as "percent of total worldwide >available Internet bandwidth/resources"? My gut feeling is that by that >metric, it didn't even make the top 20. Think back to the Morris worm, or >Blaster/Nachi/etc - *nobody* had any free bandwidth when those happened. >And >even if you restrict the discussion to intentional targeted attacks, I'm >sure >we've had worse (Smurf, anybody? :) > From adam.vitkovsky at swan.sk Thu Mar 28 14:51:30 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 28 Mar 2013 15:51:30 +0100 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> Message-ID: <01c501ce2bc3$bb742050$325c60f0$@swan.sk> Yes I see now I have worded it miserably :) What I got on my mind was an eBGP session to stub site /single homed customer. Now that I think about it I believe it could have been "on" by default on all the router interfaces and would have to be turned off manually(or automatically if mpls is enabled on the interface) for core interfaces and interfaces facing dual-homed sites. Anyways disabling urpf would than soon become a part of standard interface-config templates. So I guess no matter what tools we'd have it boils down to (and I don't want to use a word "laziness") maybe comfortability of operators. adam -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Thursday, March 28, 2013 2:43 PM To: Adam Vitkovsky Cc: Saku Ytti; nanog at nanog.org Subject: Re: BCP38 - Internet Death Penalty On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky wrote: > It's a pity that rpf is not "on" by default for interfaces over which > the ebgp session is configured. Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, "It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only)" I might have agreed with you. 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 Thu Mar 28 15:39:45 2013 From: bill at herrin.us (William Herrin) Date: Thu, 28 Mar 2013 11:39:45 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <01c501ce2bc3$bb742050$325c60f0$@swan.sk> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> Message-ID: On Thu, Mar 28, 2013 at 10:51 AM, Adam Vitkovsky wrote: > What I got on my mind was an eBGP session to stub site /single homed > customer. Hi Adam, "Single homed stub site" is not a configuration option in any BGP setup I'm aware of, so how would the router select RPF as the default for a single-homed stub site? On the other hand, a router can usually make a determination about "routing protocol is active on this interface." That's not true of a few BGP-only configurations, but it's true everywhere else in the network interior. Any interface where the routing is 100% static is by definition a single-homed stub. And for the purposes of this discussion, radius, tacacs and dhcp are not routing protocols; a radius-assigned route is static on the interface to which it is assigned. Hence RPF could safely enable itself by default there. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Thu Mar 28 16:19:53 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Mar 2013 09:19:53 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> Message-ID: <20130328161953.GA62536@ussenterprise.ufp.org> In a message written on Thu, Mar 28, 2013 at 11:39:45AM -0400, William Herrin wrote: > "Single homed stub site" is not a configuration option in any BGP > setup I'm aware of, so how would the router select RPF as the default > for a single-homed stub site? I'm not sure if this is what the OP was talking about or not, but it reminded me of a feature I have wanted in the past. If you think about a simple multi-homing situation where a person has their own IP space, their own ASN, and connects to two providers they will announce all of their routes to both providers. They may in fact do prepending, or more specifics such that one provider is preferred, but to get full redundancy all of their blocks need to go to both providers. uRPF _strict_ only allows traffic where the active route is back out the interface. There are a number of cases where this won't be true for my simple scenario above (customer uses a depref community, one ISP is a transit customer of the other being used for multi-homing, customer has more than one link to the same ISP and uses prepending on one, etc). As a result, it can't be applied. uRPF _loose_ on the other hand only checks if a route is in the table, and with the table rapidly approaching all of the IP space in use that's denying less and less every day. The feature I would like is to set the _packet filter_ based on the _received routes_ over BGP. Actually, received routes post prefix list. Consider this syntax: neighbor 1.2.3.4 install-dynamic-filter Gig10/1/2 prefix-list customer-prefixes Anything that was received would go through the prefix-list customer-prefixes (probably the same list used to filter their announcements), and then get turned into a dynamic ACL applied to the inbound interface (Gig10/1/2 in this case). I suspect such a feature would allow 99.99% of the BGP speakers to be "RPF" filtered in a meaningful way, automatically, where uRPF strict is not usable today. -- 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 jra at baylink.com Thu Mar 28 16:49:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 12:49:06 -0400 (EDT) Subject: BCP38 - Internet Death Penalty In-Reply-To: Message-ID: <7881971.11300.1364489346207.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Ferguson" > As I mentioned on another list earlier today, let's face it -- this is > going to require a large-scale, very public, and probably multi-year > education & awareness effort (as if 13+ years isn't enough already!). > > How long did it take to get some movement on open SMTP relays? You get > the idea. > > Some people are going to have to step and add a few thousand more > frequent flier miles and get out to various geographic constituencies, > at various events, and start talking about this. And we need a lot > more people on board. Nation & international campaigns, etc. > > And there may even be some stick approaches to accompany the carrot, > but some awareness is going to have to happen. > > Sing it from the mountain tops. Alain has registered bcp38.info, et al; I'll be talking to him off-list about slapping up a CMS somewhere to pour some content into, and we'll boil it down for everyone, in the immortal words of C.J. Cregg: "...like they are five-year olds... and [we'll try to do it] like we are not." Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cmadams at hiwaay.net Thu Mar 28 16:49:44 2013 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 28 Mar 2013 11:49:44 -0500 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130328161953.GA62536@ussenterprise.ufp.org> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> <20130328161953.GA62536@ussenterprise.ufp.org> Message-ID: <20130328164944.GA13834@hiwaay.net> Once upon a time, Leo Bicknell said: > The feature I would like is to set the _packet filter_ based on the > _received routes_ over BGP. On JUNOS, you can use routing-options { forwarding-table { unicast-reverse-path feasible-paths; } } to get that behavior (although it is a global option, not per-interface, I don't think there's any harm in using it). > Actually, received routes post prefix list. > Consider this syntax: > > neighbor 1.2.3.4 install-dynamic-filter Gig10/1/2 prefix-list customer-prefixes > > Anything that was received would go through the prefix-list > customer-prefixes (probably the same list used to filter their > announcements), and then get turned into a dynamic ACL applied to > the inbound interface (Gig10/1/2 in this case). JUNOS does that as well. You can use the same prefix-list in both a BGP policy filter and a firewall filter. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jra at baylink.com Thu Mar 28 17:07:24 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 13:07:24 -0400 (EDT) Subject: Tier 2 ingress filtering Message-ID: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> In the current BCP38/DDoS discussions, I've seen a lot of people suggesting that it's practical to do ingress filtering at places other than the edge. My understanding has always been different from that, based on the idea that the carrier to which a customer connects is the only one with which that end-site has a business relationship, and therefore (frex), the only one whom that end-site could advise that they believe they have a valid reason to originate traffic from address space not otherwise known to the carrier; jack-leg dual-homing, for example, as was discussed in still a third thread this week. The edge carrier's *upstream* is not going to know that it's reasonable for their customer -- the end-site's carrier -- to be originating traffic with those source addresses, and if they ingress filter based on the prefixes they route down to that carrier, they'll drop that traffic... which is not fraudulent, and has a valid engineering reason to exist and appear on their incoming interface. Fixing that will require the construction of an entirely new tracking system at the Tier 2, which is not really the case for the Tier 3 edge carrier, as I see it - you generally just turn unicast-rpf on for everyone's port, unless you have a signed waiver in your file cabinet, in which case you turn it off. Am I missing something? Or is the overarching problem large enough that people are willing to throw the baby out with the bathwater? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Mar 28 17:10:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 13:10:30 -0400 (EDT) Subject: So how big was it *really*? In-Reply-To: <20130328133601.GT20231@virtual.bogons.net> Message-ID: <1497934.11316.1364490629995.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Simon Lockhart" > And there's a (semi-)public response from one of Cloudfare's > upstreams: > > http://cluepon.net/ras/gizmodo Money quote: """ In defense of the claims in other articles, there is a huge difference between "taking down the entire Internet" and "causing impact to notable portions of the Internet". My company, most other large Internet carriers, and even the largest Internet exchange points, all deliver traffic at multi-terabits-per-second rates, so in the grand scheme of things 300 Gbps is certainly not going to destroy the Internet, wipe anybody off the map, or even show up as more than a blip on the charts of global traffic levels. That said, there is absolutely NO network on this planet who maintains 300 Gbps of active/lit but unused capacity to every point in their network. This would be incredibly expensive and wasteful, and most of us are trying to run for-profit commercial networks, so when 300 Gbps of NEW traffic suddenly shows up and all wants to go to ONE location, someone is going to have a bad day. """ Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bill at herrin.us Thu Mar 28 17:10:53 2013 From: bill at herrin.us (William Herrin) Date: Thu, 28 Mar 2013 13:10:53 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130328161953.GA62536@ussenterprise.ufp.org> References: <27306172.11186.1364394183942.JavaMail.root@benjamin.baylink.com> <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> <20130328161953.GA62536@ussenterprise.ufp.org> Message-ID: On Thu, Mar 28, 2013 at 12:19 PM, Leo Bicknell wrote: > If you think about a simple multi-homing situation where a person > has their own IP space, their own ASN, and connects to two providers > they will announce all of their routes to both providers. > > The feature I would like is to set the _packet filter_ based on the > _received routes_ over BGP. Actually, received routes post prefix list. Hi Leo, Since you've configured a prefix list to specify what BGP routes you're willing to accept from the simple multihomed customer (you have, right?) why set a source filter from the same data instead of trying to build it from routing table guesswork? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Thu Mar 28 17:16:48 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 28 Mar 2013 17:16:48 +0000 Subject: Tier 2 ingress filtering In-Reply-To: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> Message-ID: <20130328171648.GC18649@vacation.karoshi.com.> is there a clear understanding of "the edge" in the network operations community? in a simpler world, it was not that difficult, but interconnect has blossomed and grown all sorts of noodly appendages/extentions. I fear that edge does not mean what you think it means anymore. /bill On Thu, Mar 28, 2013 at 01:07:24PM -0400, Jay Ashworth wrote: > In the current BCP38/DDoS discussions, I've seen a lot of people suggesting > that it's practical to do ingress filtering at places other than the edge. > > My understanding has always been different from that, based on the idea > that the carrier to which a customer connects is the only one with which > that end-site has a business relationship, and therefore (frex), the only > one whom that end-site could advise that they believe they have a valid > reason to originate traffic from address space not otherwise known to > the carrier; jack-leg dual-homing, for example, as was discussed in still > a third thread this week. > > The edge carrier's *upstream* is not going to know that it's reasonable > for their customer -- the end-site's carrier -- to be originating traffic > with those source addresses, and if they ingress filter based on the > prefixes they route down to that carrier, they'll drop that traffic... > > which is not fraudulent, and has a valid engineering reason to exist and > appear on their incoming interface. > > Fixing that will require the construction of an entirely new tracking system > at the Tier 2, which is not really the case for the Tier 3 edge carrier, > as I see it - you generally just turn unicast-rpf on for everyone's port, > unless you have a signed waiver in your file cabinet, in which case > you turn it off. > > Am I missing something? > > Or is the overarching problem large enough that people are willing to > throw the baby out with the bathwater? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 From Valdis.Kletnieks at vt.edu Thu Mar 28 17:47:45 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 Mar 2013 13:47:45 -0400 Subject: Tier 2 ingress filtering In-Reply-To: Your message of "Thu, 28 Mar 2013 17:16:48 -0000." <51547c51.8b87e50a.7d35.1e9aSMTPIN_ADDED_BROKEN@mx.google.com> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <51547c51.8b87e50a.7d35.1e9aSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <53436.1364492865@turing-police.cc.vt.edu> On Thu, 28 Mar 2013 17:16:48 -0000, bmanning at vacation.karoshi.com said: > > is there a clear understanding of "the edge" in the network operations > community? in a simpler world, it was not that difficult, but interconnect > has blossomed and grown all sorts of noodly appendages/extentions. I fear > that edge does not mean what you think it means anymore. For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable connections, it's still the edge and still trivially filterable. If that's a problem, the ISP can upsell a business-class connection that doesn't filter. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Thu Mar 28 17:51:45 2013 From: bill at herrin.us (William Herrin) Date: Thu, 28 Mar 2013 13:51:45 -0400 Subject: Tier 2 ingress filtering In-Reply-To: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Mar 28, 2013 at 1:07 PM, Jay Ashworth wrote: > My understanding has always been different from that, based on the idea > that the carrier to which a customer connects is the only one with which > that end-site has a business relationship, and therefore (frex), the only > one whom that end-site could advise that they believe they have a valid > reason to originate traffic from address space not otherwise known to > the carrier; jack-leg dual-homing, for example, as was discussed in still > a third thread this week. Hi Jay, There's a two part heirarchy of contracts involved in every legitimate end-to-end communication which occurs over the Internet, right? You buy service from someone who buys service on your behalf from someone who buys service on his behalf from someone. The other endpoint does the same, starting with his ISP. The contract hierarchies meet at the top, either with a single backbone ISP or with a pair of backbone ISPs who do settlement-free peering with each other. So, you represent to your ISP that you're authorized to use a certain range of addresses. He represents to his upstream that he's authorized to use them on your behalf, and so on. The reliability of these representations obviously falls at they grow distant from the source. So what? That's a problem for RPKI. The problem we need concern ourselves with is dropping packets whose source addresses are inconsistent with our customer's _representation_ of the addresses he's authorized to originate, however reliable or unreliable that representation may turn out to be. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Thu Mar 28 17:55:12 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 28 Mar 2013 17:55:12 +0000 Subject: Tier 2 ingress filtering In-Reply-To: <53436.1364492865@turing-police.cc.vt.edu> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <51547c51.8b87e50a.7d35.1e9aSMTPIN_ADDED_BROKEN@mx.google.com> <53436.1364492865@turing-police.cc.vt.edu> Message-ID: <20130328175512.GE18649@vacation.karoshi.com.> On Thu, Mar 28, 2013 at 01:47:45PM -0400, Valdis.Kletnieks at vt.edu wrote: > On Thu, 28 Mar 2013 17:16:48 -0000, bmanning at vacation.karoshi.com said: > > > > is there a clear understanding of "the edge" in the network operations > > community? in a simpler world, it was not that difficult, but interconnect > > has blossomed and grown all sorts of noodly appendages/extentions. I fear > > that edge does not mean what you think it means anymore. > > For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable > connections, it's still the edge and still trivially filterable. If that's a > problem, the ISP can upsell a business-class connection that doesn't filter. ;) > 5 9s? I'll go w/ big, but this seems a stretch to me. if true (it might be), then filtering ought be done and catch the delta. I still posit a baseline that does not fit this lowhanging fruit... (trill networks, L2 transparent bridging, L2-L3-VPNs, etc.) /bill From bicknell at ufp.org Thu Mar 28 17:58:03 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Mar 2013 10:58:03 -0700 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> <20130328161953.GA62536@ussenterprise.ufp.org> Message-ID: <20130328175803.GB62536@ussenterprise.ufp.org> In a message written on Thu, Mar 28, 2013 at 01:10:53PM -0400, William Herrin wrote: > Since you've configured a prefix list to specify what BGP routes > you're willing to accept from the simple multihomed customer (you > have, right?) why set a source filter from the same data instead of > trying to build it from routing table guesswork? In the simplest case I described (user has for instance one netblock) the packet filter will match the routing filter, and doing what you described would not be a huge extra burden. Howver, it is still a burden, it's writing everything twice (prefix list plus ACL), and it's making configs longer and less readable. But the real power here comes by applying this filter further up the food chain. Consider peering with a regional entity at an IX. Most people don't prefix filter there (and we could have a lively argument about the practicality of that), so the prefix list might be something like: deny my_prefix/foo le 32 permit 0.0.0.0/0 le 24 With a max-prefix of 100. That doesn't turn into a useful packet filter for the peer, but using my method the peer could be RPF filtered based on what they send, automatically. -- 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 jared at puck.nether.net Thu Mar 28 18:16:58 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 Mar 2013 14:16:58 -0400 Subject: Per-ASN data (Re: Open Resolver Problems) In-Reply-To: <5153E7C1.2090308@mitteilung.com> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> <5151C0EC.7000008@foobar.org> <51522973.9010901@pubnix.net> <5153E7C1.2090308@mitteilung.com> Message-ID: <44F2D720-AAD1-4669-97EC-FF91E7A6960F@puck.nether.net> I wanted to share PER-ASN data for those that are interested in this generally. If you are a contact for these ASNs, you can e-mail me from your corporate address to get access to the list. Thank you for many of you that have secured hosts!!!! COUNT ASN# 1357979 4134 1144551 8151 1089464 9121 896102 3462 623486 45899 618161 4837 554655 17974 513878 13285 486146 22927 486081 3352 483686 209 457952 3269 423432 9318 377811 1267 356685 5617 334125 19262 318274 24560 291114 4766 266952 9198 248563 9050 245165 18403 233639 18881 230318 9737 229251 7418 228180 8167 223017 36947 221978 7303 221487 43234 219076 3215 216288 8452 207389 3816 197305 5610 194241 45758 194227 45629 191824 19429 184158 4812 183616 6697 177759 9829 177058 17813 175616 36351 166778 17552 163671 6147 140349 8400 138785 21844 138369 9299 128307 8866 120188 13489 117991 5390 115057 4788 111726 7552 108487 9394 105874 47589 94346 4713 93301 7738 91777 6849 85895 24863 82668 12741 79534 9269 77572 6389 77428 32244 77166 9105 76574 12874 76104 4808 73145 24940 67576 6400 66648 12880 65260 45595 64153 32475 63932 6332 60420 2379 54987 14420 54299 12297 52710 6830 52274 30722 51229 26496 49623 6057 49488 13036 48045 3320 47141 2554 46894 5384 46790 6855 44998 32613 44090 2516 42977 36444 42588 36992 40757 7018 39099 46606 38890 7385 38714 5650 38622 9158 38466 8997 38451 8560 37635 2856 37494 5089 36477 6730 36057 7132 35626 12301 35556 8612 34938 24835 34652 31549 34547 22394 34546 6713 34274 12978 34214 8359 33944 22561 33886 44957 33763 286 33548 1136 32513 17816 32481 55430 32439 7545 31919 4780 30890 27695 30410 21788 29843 15557 29639 28812 29512 1221 29463 35805 28758 41440 28602 47794 28533 43447 28494 16265 28268 34296 28196 25019 28000 4847 27701 13354 27498 9146 27370 27699 27211 6799 27021 13768 27017 20773 26858 17676 26622 41592 26610 44178 26233 25847 25962 2609 25751 3301 25732 15975 25730 8376 25526 29256 24531 19066 24342 6983 23560 25405 23445 33774 23185 17511 23058 34170 22868 17430 22670 8926 22003 19029 21958 4538 21860 12576 21596 25653 21496 10036 21009 29386 20915 8972 20640 9808 20429 22833 20375 13999 20102 11398 19931 30496 19906 34984 19839 5778 19635 9824 19469 12912 19350 17858 19327 9143 18896 9329 18878 7029 18757 8968 18667 56046 18658 8708 18309 6877 18040 25513 17877 11830 17718 4802 17699 11556 17619 2119 16924 28787 16772 4230 16672 174 16373 7497 16370 53006 16309 29550 16079 17762 15825 23352 15718 40244 15673 29049 15590 17964 15571 4725 15289 13213 15122 25144 15026 33182 14698 56040 14615 35819 14613 10474 14555 20860 14410 21003 14408 48159 14381 2514 14219 26599 14174 9790 14149 9125 14147 22773 14138 33812 14132 2527 14107 12260 14043 3303 14001 29182 13969 20825 13881 18566 13865 25515 13863 56041 13710 20738 13612 25490 13511 9605 13360 1785 13333 23752 13147 35041 13048 9845 12989 39501 12986 9924 12938 3292 12902 2828 12886 6703 12831 2518 12704 20676 12328 20115 12325 46475 12306 12486 12216 4323 12209 15589 12206 32748 12180 701 12105 36137 12083 3209 11967 8551 11934 23889 11916 4775 11903 13977 11821 3329 11771 10299 11768 22822 11740 16086 11705 9116 11705 3651 11570 25124 11533 33070 11531 12683 11483 6739 11475 15003 11459 45951 11423 6871 11364 131090 11244 24158 11217 16276 11115 5432 11079 5410 10726 2497 10678 17623 10651 3239 10497 10796 10416 7657 10393 8402 10388 12332 10380 58085 10380 17621 10332 5483 10300 22368 10280 3595 10272 45609 10207 9617 From bill at herrin.us Thu Mar 28 18:20:48 2013 From: bill at herrin.us (William Herrin) Date: Thu, 28 Mar 2013 14:20:48 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <20130328175803.GB62536@ussenterprise.ufp.org> References: <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> <20130328161953.GA62536@ussenterprise.ufp.org> <20130328175803.GB62536@ussenterprise.ufp.org> Message-ID: On Thu, Mar 28, 2013 at 1:58 PM, Leo Bicknell wrote: > But the real power here comes by applying this filter further up the > food chain. Consider peering with a regional entity at an IX. Most > [...] > > That doesn't turn into a useful packet filter for the peer, but using my > method the peer could be RPF filtered based on what they send, > automatically. Hi Leo, Be nice if that were correct. If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. And if your customer sets a BGP community defined to mean "don't advertise to peers" then you won't advertise it to the peer. Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table. Which means that your peer can't take the received routes from your BGP session as gospel for what source addresses to expect. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From blair.trosper at gmail.com Thu Mar 28 18:51:14 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 28 Mar 2013 13:51:14 -0500 Subject: Google public DNS flapping/non-functional Message-ID: Could someone from Google contact me off list to discuss the public resolvers? I'm getting NXDOMAIN and then a proper response literally one second later. And from there it's just 20 GOTO 10...the resolver seems to be having a psychotic episode, or...at the very least...an identity crisis. Other public resolver services have no issue with this, but the problem seems to be affected by anything I throw at either 8.8.8.8 or 8.8.4.4 to resolve. (The IPv6 public resolvers are doing the same thing, I should point out.) I understand that those ingress addresses are any/multicast, so perhaps the problem I'm having is confined to a single datacenter in my region...and thus may not be affecting people outside of that DC. Thanks, Blair From saku at ytti.fi Thu Mar 28 19:02:43 2013 From: saku at ytti.fi (Saku Ytti) Date: Thu, 28 Mar 2013 21:02:43 +0200 Subject: Tier 2 ingress filtering In-Reply-To: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> Message-ID: <20130328190243.GA11065@pob.ytti.fi> On (2013-03-28 13:07 -0400), Jay Ashworth wrote: > The edge carrier's *upstream* is not going to know that it's reasonable > for their customer -- the end-site's carrier -- to be originating traffic > with those source addresses, and if they ingress filter based on the > prefixes they route down to that carrier, they'll drop that traffic... Question is, is it reasonable to expect customer to know what networks they have. If yes, then you can ask them to create route objects and then you can BGP prefix-filter and ACL on them. I do both, and it has never been problem to my customers (enterprises, CDNs, eyeballs). But if your customer has many other transit customer it can quickly become less practical. I'm sure for many/most customers of tier1 it would not be reasonable expects to keep such list up-to-date. You can't do it at top-level nor it's not practical to hope that some day BCP38 is done in reasonably many last-mile port. But there are only 6000 non-stubby networks, if you do it at network before stubby network, it's entirely practical and maintainable, provided we'd want to do it. -- ++ytti From jra at baylink.com Thu Mar 28 19:05:57 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 15:05:57 -0400 (EDT) Subject: Tier 2 ingress filtering In-Reply-To: <53436.1364492865@turing-police.cc.vt.edu> Message-ID: <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Thu, 28 Mar 2013 17:16:48 -0000, bmanning at vacation.karoshi.com > said: > > > > is there a clear understanding of "the edge" in the network operations > > community? in a simpler world, it was not that difficult, but interconnect > > has blossomed and grown all sorts of noodly appendages/extentions. I > > fear that edge does not mean what you think it means anymore. > > For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable > connections, it's still the edge and still trivially filterable. If that's a > problem, the ISP can upsell a business-class connection that doesn't > filter. ;) C'mon guys: the edge is where people who *source and sink* packets connect to people who *move* packets. There may be some edges *inside* carriers, but there is certainly an edge where carriers hook up customers. And no, this should apply to business-grade connections as much as resi. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Mar 28 19:27:04 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 15:27:04 -0400 (EDT) Subject: Tier 2 ingress filtering In-Reply-To: Message-ID: <12944408.2.1364498824887.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > So, you represent to your ISP that you're authorized to use a certain > range of addresses. He represents to his upstream that he's authorized > to use them on your behalf, and so on. The former is a first-hand transaction: if you're lying to your edge carrier, he can cut you off with no collateral damage. The latter, though, is arms-length, *and* has no reasonable way to be implemented that I can see without extending whatever OAM&P system that carrier has atop their gear. > The reliability of these representations obviously falls at they grow > distant from the source. So what? That's a problem for RPKI. The > problem we need concern ourselves with is dropping packets whose > source addresses are inconsistent with our customer's _representation_ > of the addresses he's authorized to originate, however reliable or > unreliable that representation may turn out to be. That's great, but that's a couple orders of magnitude of added complexity that, quite frankly Bill, I can't sell just now. :-) Worse (to bring this ontopic for NANOG): that complexity needs to live *inside routers*, unless I'm very much mistaken. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fergdawgster at gmail.com Thu Mar 28 19:42:30 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 28 Mar 2013 12:42:30 -0700 Subject: Tier 2 ingress filtering In-Reply-To: <12944408.2.1364498824887.JavaMail.root@benjamin.baylink.com> References: <12944408.2.1364498824887.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Mar 28, 2013 at 12:27 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "William Herrin" > >> So, you represent to your ISP that you're authorized to use a certain >> range of addresses. He represents to his upstream that he's authorized >> to use them on your behalf, and so on. > > The former is a first-hand transaction: if you're lying to your edge > carrier, he can cut you off with no collateral damage. > Of course, he has to notice it first. :-) ObOpinion: It's best to *enforce* a policy which disallows a downstream network from sourcing spoofed packets -- and the closer to the "edge" you are, the better, Hierarchy is great for that. :-) I guess the next best thing is "Trust but verify"? - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From jra at baylink.com Thu Mar 28 19:47:19 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 15:47:19 -0400 (EDT) Subject: Tier 2 ingress filtering In-Reply-To: <20130328190243.GA11065@pob.ytti.fi> Message-ID: <16467978.8.1364500039086.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Saku Ytti" > On (2013-03-28 13:07 -0400), Jay Ashworth wrote: > > > The edge carrier's *upstream* is not going to know that it's reasonable > > for their customer -- the end-site's carrier -- to be originating traffic > > with those source addresses, and if they ingress filter based on the > > prefixes they route down to that carrier, they'll drop that > > traffic... > > Question is, is it reasonable to expect customer to know what networks > they have. If by "customer" you mean the same thing I do: an end user who sources and sinks packets, which is fed by some Internet Access Provider... then my answer is the same thing it was before: "No, but it doesn't matter, because we're talking about ingress filters on the carrier which provides them with public address space, and *it* *does* know which network they've been given." > If yes, then you can ask them to create route objects and then you can > BGP > prefix-filter and ACL on them. I do both, and it has never been > problem to > my customers (enterprises, CDNs, eyeballs). You are at least 30,000 feet higher than the conversation I'm having. BGP-speaking end sites are a whole different matter, and sufficiently smaller in number (2-5 orders of magnitude, depending on what you sell) that they're not really pertinent here. > But if your customer has many other transit customer it can quickly become > less practical. I'm sure for many/most customers of tier1 it would not > be reasonable expects to keep such list up-to-date. Correct, and this was the substance of my question. > You can't do it at top-level nor it's not practical to hope that some > day BCP38 is done in reasonably many last-mile port. I don't know that that's true, actually; unicast-rpf does, as I understand it, most of the work, and is in most of the current firmware. > But there are only 6000 non-stubby networks, if you do it at network > before stubby network, it's entirely practical and maintainable, provided > we'd want to do it. Your assertion is the thing for which I'm requesting support in this query. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Mar 28 19:51:49 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 15:51:49 -0400 (EDT) Subject: Tier 2 ingress filtering In-Reply-To: Message-ID: <2944378.12.1364500309571.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Ferguson" > > The former is a first-hand transaction: if you're lying to your edge > > carrier, he can cut you off with no collateral damage. > > Of course, he has to notice it first. :-) Sure. > ObOpinion: It's best to *enforce* a policy which disallows a > downstream network from sourcing spoofed packets -- and the closer to > the "edge" you are, the better, Hierarchy is great for that. :-) Sure; that's sort of my point: this is *much* more effectively done at the actual edge; I think the systemic complexity of pushing it further in goes up as a log function -- meaning that the fact that there are only maybe 6000 transit networks is a red herring. > I guess the next best thing is "Trust but verify"? Always. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From morrowc.lists at gmail.com Thu Mar 28 20:44:50 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Mar 2013 16:44:50 -0400 Subject: alexandria cable cutters? In-Reply-To: References: Message-ID: On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush wrote: > nyt reports capture of scuba divers attempting to cut telecom egypt > undersea fiber. > > http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html how likely is it that a diver can cut an armored cable close to shore? without using explosives I mean... From lathama at gmail.com Thu Mar 28 20:50:21 2013 From: lathama at gmail.com (Andrew Latham) Date: Thu, 28 Mar 2013 16:50:21 -0400 Subject: alexandria cable cutters? In-Reply-To: References: Message-ID: On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow wrote: > On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush wrote: >> nyt reports capture of scuba divers attempting to cut telecom egypt >> undersea fiber. >> >> http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html > > how likely is it that a diver can cut an armored cable close to shore? > without using explosives I mean... Its quite easy with a Thermal Lance... http://en.wikipedia.org/wiki/Thermal_lance -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From Valdis.Kletnieks at vt.edu Thu Mar 28 21:05:38 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 Mar 2013 17:05:38 -0400 Subject: Per-ASN data (Re: Open Resolver Problems) In-Reply-To: Your message of "Thu, 28 Mar 2013 14:16:58 -0400." <44F2D720-AAD1-4669-97EC-FF91E7A6960F@puck.nether.net> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> <5151C0EC.7000008@foobar.org> <51522973.9010901@pubnix.net> <5153E7C1.2090308@itteilung.com> <44F2D720-AAD1-4669-97EC-FF91E7A6960F@puck.nether.net> Message-ID: <10340.1364504738@turing-police.cc.vt.edu> On Thu, 28 Mar 2013 14:16:58 -0400, Jared Mauch said: > > I wanted to share PER-ASN data for those that are interested in this generally. If you are a contact for these ASNs, you can e-mail me from your corporate address to get access to the list. > > Thank you for many of you that have secured hosts!!!! I'm embarrassed to admit we appear to have on the order of 150 or so misconfigured hosts. LARTs will be dispatched. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Mar 28 21:08:54 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 28 Mar 2013 17:08:54 -0400 Subject: Tier 2 ingress filtering In-Reply-To: Your message of "Thu, 28 Mar 2013 15:05:57 -0400." <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> References: <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> Message-ID: <10501.1364504934@turing-police.cc.vt.edu> On Thu, 28 Mar 2013 15:05:57 -0400, Jay Ashworth said: > ----- Original Message ----- > > From: "Valdis Kletnieks" > > For 5 9's worth of eyeball networks hanging off consumer-grade ADSL and cable > > connections, it's still the edge and still trivially filterable. If that's a > > problem, the ISP can upsell a business-class connection that doesn't > > filter. ;) > > C'mon guys: the edge is where people who *source and sink* packets > connect to people who *move* packets. There may be some edges *inside* > carriers, but there is certainly an edge where carriers hook up customers. Exactly - packets leaving Comcast's network and going to another tier 1/2, the receiver may have a hard time figuring out if the packet is legit or not. But it's trivial for Comcast to tell whether the packet that just came out my cablemodem is consistent with what their DHCP server told my CPE. (For the record, the last time I tried running the spoofer.sail stuff on my home gear, it was totally unable to sneak a packet out, so at least part of Comcast does this right). And the fact that there's places where it *is* hard to deploy isn't an excuse for not doing it in the 98% of places where it's a slam dunk. > And no, this should apply to business-grade connections as much as resi. Oh, I was intending *those* would be filtered by default as well, but you could request an opt-out if you were trying to do multi-homing on the cheap as some people have suggested (similar to blocking outbound 25 by default, unless the user actually has a mail server). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Thu Mar 28 21:17:49 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 28 Mar 2013 21:17:49 +0000 Subject: alexandria cable cutters? In-Reply-To: Message-ID: I'm trying to make sense of this.. - Welding Gear is expensive, underwater gear is insanely expensive. - Welding is pretty difficult.. - Underwater welding requires knowledge of SCUBA *AND* welding techniques under water. - There are 8 undersea cables located near the cable that was being cut. - There are a TON of EDFA's in the area, which are much easier to destroy. - Of the 8 undersea cables leaving Alexandria, only one was being tampered with? Does this not look like something that is either state sponsored, or someone trying to break a certain circuit? Obviously we won't know for some time what the circumstances were (if ever), but going after a specific cable with a welder sounds like someone had a real reason. And if this *WAS* state sponsored, I would be really curious as to why they did not use regular UDT guys with regular UDT stuff that goes boom under water. Not to mention the fact that they were using a welder, underwater, on a 15kV -48VDC fiber optic plant in dirty(ish) salt water - which sounds like a pretty bad idea. On 3/28/13 1:50 PM, "Andrew Latham" wrote: >On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow > wrote: >> On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush wrote: >>> nyt reports capture of scuba divers attempting to cut telecom egypt >>> undersea fiber. >>> >>> >>>http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt- >>>internet.html >> >> how likely is it that a diver can cut an armored cable close to shore? >> without using explosives I mean... > >Its quite easy with a Thermal Lance... > >http://en.wikipedia.org/wiki/Thermal_lance > >-- >~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > From joelja at bogus.com Thu Mar 28 21:17:52 2013 From: joelja at bogus.com (joel jaeggli) Date: Thu, 28 Mar 2013 14:17:52 -0700 Subject: alexandria cable cutters? In-Reply-To: References: Message-ID: <5154B380.7000300@bogus.com> On 3/28/13 1:50 PM, Andrew Latham wrote: > On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow > wrote: >> On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush wrote: >>> nyt reports capture of scuba divers attempting to cut telecom egypt >>> undersea fiber. >>> >>> http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html >> how likely is it that a diver can cut an armored cable close to shore? >> without using explosives I mean... > Its quite easy with a Thermal Lance... > > http://en.wikipedia.org/wiki/Thermal_lance > The oil services industry has rather frequent application for cutting metal objects under-water. http://www.csunitec.com/saws/reciprocating_hydraulic.html From jra at baylink.com Thu Mar 28 21:21:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 28 Mar 2013 17:21:31 -0400 Subject: Tier 2 ingress filtering In-Reply-To: <10501.1364504934@turing-police.cc.vt.edu> References: <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> <10501.1364504934@turing-police.cc.vt.edu> Message-ID: Yeah, that's what I meant: ingress filter all edge connections except maybe BGP, and accept optout requests. Valdis.Kletnieks at vt.edu wrote: >On Thu, 28 Mar 2013 15:05:57 -0400, Jay Ashworth said: >> ----- Original Message ----- >> > From: "Valdis Kletnieks" >> > For 5 9's worth of eyeball networks hanging off consumer-grade ADSL >and cable >> > connections, it's still the edge and still trivially filterable. If >that's a >> > problem, the ISP can upsell a business-class connection that >doesn't >> > filter. ;) >> >> C'mon guys: the edge is where people who *source and sink* packets >> connect to people who *move* packets. There may be some edges >*inside* >> carriers, but there is certainly an edge where carriers hook up >customers. > >Exactly - packets leaving Comcast's network and going to another tier >1/2, >the receiver may have a hard time figuring out if the packet is legit >or not. >But it's trivial for Comcast to tell whether the packet that just came >out >my cablemodem is consistent with what their DHCP server told my CPE. >(For the record, the last time I tried running the spoofer.sail stuff >on my home gear, it was totally unable to sneak a packet out, so at >least >part of Comcast does this right). > >And the fact that there's places where it *is* hard to deploy isn't an >excuse >for not doing it in the 98% of places where it's a slam dunk. > >> And no, this should apply to business-grade connections as much as >resi. > >Oh, I was intending *those* would be filtered by default as well, but >you >could request an opt-out if you were trying to do multi-homing on the >cheap >as some people have suggested (similar to blocking outbound 25 by >default, >unless the user actually has a mail server). -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From casey at deccio.net Thu Mar 28 21:22:40 2013 From: casey at deccio.net (Casey Deccio) Date: Thu, 28 Mar 2013 14:22:40 -0700 Subject: Google public DNS flapping/non-functional In-Reply-To: References: Message-ID: On Thu, Mar 28, 2013 at 11:51 AM, Blair Trosper wrote: > Could someone from Google contact me off list to discuss the public > resolvers? > > I'm getting NXDOMAIN and then a proper response literally one second later. > And from there it's just 20 GOTO 10...the resolver seems to be having a > psychotic episode, or...at the very least...an identity crisis. > > These symptoms have been seen on DNSSEC validating resolvers when they encounter a signed zone that is misconfigured. Google has recently begun DNSSEC validation, so it could very well be related, depending the configuration of the zone in question, including whether or not it is signed, and Google's resolver/validator implementation. Casey From saku at ytti.fi Thu Mar 28 23:34:03 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 29 Mar 2013 01:34:03 +0200 Subject: Tier 2 ingress filtering In-Reply-To: <16467978.8.1364500039086.JavaMail.root@benjamin.baylink.com> References: <20130328190243.GA11065@pob.ytti.fi> <16467978.8.1364500039086.JavaMail.root@benjamin.baylink.com> Message-ID: <20130328233403.GA13048@pob.ytti.fi> On (2013-03-28 15:47 -0400), Jay Ashworth wrote: > > You can't do it at top-level nor it's not practical to hope that some > > day BCP38 is done in reasonably many last-mile port. > > I don't know that that's true, actually; unicast-rpf does, as I understand > it, most of the work, and is in most of the current firmware. Even if all of last mile devices support uRPF, which it does not, getting all these 100s of millions of ports configured correctly does not strike as practical goal. Fixing 6000 non-stubby transit providers catering sufficiently small tails is much more practical goal. -- ++ytti From rajiva at cisco.com Thu Mar 28 23:45:19 2013 From: rajiva at cisco.com (Rajiv Asati (rajiva)) Date: Thu, 28 Mar 2013 23:45:19 +0000 Subject: Tier 2 ingress filtering In-Reply-To: <20130328233403.GA13048@pob.ytti.fi> References: <20130328190243.GA11065@pob.ytti.fi> <16467978.8.1364500039086.JavaMail.root@benjamin.baylink.com>, <20130328233403.GA13048@pob.ytti.fi> Message-ID: Saku, > all these 100s of millions of ports configured correctly does not strike as > practical goal. It is practical, IMO, similar to configuring IP address/prefix (or QoS policies) on every port. In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. > Fixing 6000 non-stubby transit providers catering sufficiently small tails > is much more practical goal. Agreed. Cheers, Rajiv Sent from my Phone On Mar 29, 2013, at 7:36 AM, "Saku Ytti" wrote: > On (2013-03-28 15:47 -0400), Jay Ashworth wrote: > >>> You can't do it at top-level nor it's not practical to hope that some >>> day BCP38 is done in reasonably many last-mile port. >> >> I don't know that that's true, actually; unicast-rpf does, as I understand >> it, most of the work, and is in most of the current firmware. > > Even if all of last mile devices support uRPF, which it does not, getting > all these 100s of millions of ports configured correctly does not strike as > practical goal. > Fixing 6000 non-stubby transit providers catering sufficiently small tails > is much more practical goal. > > -- > ++ytti > From saku at ytti.fi Thu Mar 28 23:49:56 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 29 Mar 2013 01:49:56 +0200 Subject: Tier 2 ingress filtering In-Reply-To: References: <20130328190243.GA11065@pob.ytti.fi> <16467978.8.1364500039086.JavaMail.root@benjamin.baylink.com> <20130328233403.GA13048@pob.ytti.fi> Message-ID: <20130328234956.GA18193@pob.ytti.fi> On (2013-03-28 23:45 +0000), Rajiv Asati (rajiva) wrote: > In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. There is incredible amount of L3 interfaces in the last mile, old ghetto stuff, latest gen Cisco, which does not do uRPF. -- ++ytti From jeff-kell at utc.edu Thu Mar 28 23:55:15 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 28 Mar 2013 19:55:15 -0400 Subject: Tier 2 ingress filtering In-Reply-To: <20130328234956.GA18193@pob.ytti.fi> References: <20130328190243.GA11065@pob.ytti.fi> <16467978.8.1364500039086.JavaMail.root@benjamin.baylink.com> <20130328233403.GA13048@pob.ytti.fi> <20130328234956.GA18193@pob.ytti.fi> Message-ID: <5154D863.5020907@utc.edu> On 3/28/2013 7:49 PM, Saku Ytti wrote: > On (2013-03-28 23:45 +0000), Rajiv Asati (rajiva) wrote: > In fact, what makes it easier is that uRPF can be part of the template that can be universally applied to every edge port. > There is incredible amount of L3 interfaces in the last mile, old ghetto > stuff, latest gen Cisco, which does not do uRPF. Very true. Some of it you can even configure as such, it just doesn't do anything... Jeff From mysidia at gmail.com Fri Mar 29 00:04:16 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 28 Mar 2013 19:04:16 -0500 Subject: Tier 2 ingress filtering In-Reply-To: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> Message-ID: On 3/28/13, Jay Ashworth wrote: > My understanding has always been different from that, based on the idea > that the carrier to which a customer connects is the only one with which > that end-site has a business relationship, and therefore (frex), the only > one whom that end-site could advise that they believe they have a valid > reason to originate traffic from address space not otherwise known to [snip] Do you have a LOA on file for that peer/customer to route traffic to (or from) the prefix? If yes, then it's legitimate that they source traffic from it, or request that the prefix be included in their filters for BGP and ingress controls. If no, then consult the routing policy that applies to them. Ingress source addresses should optimally ideally be filtered at turnup to the list of authorized prefixes, if uRPF cannot be implemented (uRPF is convenient, but not necessarily necessary to implement ingress filtering), then access list based on source address, even the nearly oldest of the most ghetto equipment should be offering basic ACL functions. If the downstream need extra prefixes that you couldn't have known about, then it's the downstream network's job to contact you to have the prefix added to filters, before they start sourcing traffic from those addresses. By definition if they wouldn't be allowed to route traffic _to_ that address over your link, your network's routing policy documents could and probably ought to say, that it's not allowed to source traffic from such unauthorized addresses. If the peer is your transit provider that is authorized to give you default and route any prefix, then sure, allow any source, because they are authorized (except source addresses that belong to your network or your customers that have not secured your network's permission to be multihoming with their link and specified address space, of course).. > -- jra -- -JH From jlewis at lewis.org Fri Mar 29 00:48:55 2013 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 28 Mar 2013 20:48:55 -0400 (EDT) Subject: Tier 2 ingress filtering In-Reply-To: <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> References: <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, 28 Mar 2013, Jay Ashworth wrote: > C'mon guys: the edge is where people who *source and sink* packets > connect to people who *move* packets. There may be some edges *inside* > carriers, but there is certainly an edge where carriers hook up customers. > > And no, this should apply to business-grade connections as much as resi. I tested several days ago and was surprised/impressed to find that my home cable provider does not allow me to spoof. AFAICR, all of the Tier1/Tier2 providers I've dealt with over the years (UUNet, Sprintlink, C&W, MCI, Digex, Intermedia, Abovenet, Level3, TWTelecom, Cogent, BHN, I'm probably forgetting a few) have done BGP prefix-list filters on their transit customers. If they know what routes you might want to announce to them, wouldn't it be reasonable to use that same list of prefixes (in the vast majority of cases) as the basis for an input ACL on your interface? It'd be extra work for the T1/T2 networks to do this, and arguably, all the customer networks should be doing it inside their own networks, but we all know that not everyone who buys a connection and configures BGP has half a clue, and for the ones that do, we can all appreciate the idea of a belt and suspenders. It's time for people to stop passing the buck on BCP38 (we don't do it, because it really ought to be done at that other level) and start implementing it where possible. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From peterehiwe at gmail.com Fri Mar 29 01:13:08 2013 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Fri, 29 Mar 2013 02:13:08 +0100 Subject: Should the Facebook's, Google , Amazon's of this world operate a BGP looking glass ? Message-ID: Hi All Should major social networking sites like Facebook,Google and Amazon operate an IP looking glass ? i think they should , here is a short justification write-up i did , using a real life troubleshooting scenario. http://www.slideshare.net/peterehiwe/why-major-content-providers-need-an-ip-looking-glass -- Warm Regards Peter From jared at puck.nether.net Fri Mar 29 01:36:53 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 Mar 2013 18:36:53 -0700 Subject: Tier 2 ingress filtering In-Reply-To: References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> Message-ID: <9B2F085B-4412-44BD-9B43-B40D12A0F040@puck.nether.net> See below Jared Mauch On Mar 28, 2013, at 5:04 PM, Jimmy Hess wrote: > Ingress source addresses should optimally ideally be filtered at > turnup to the list of authorized prefixes, if uRPF cannot be > implemented (uRPF is convenient, but not necessarily necessary to > implement ingress filtering), then access list based on source > address, even the nearly oldest of the most ghetto equipment should > be offering basic ACL functions. Not everything can do acls at scale. Not all customers have anything reflecting symmetric routing creating a problem in the capabilities in the equipment working as desired. Many customers honestly don't know how their things work or think they work in ways that are not fully accurate. You get lots of default pointing even when they run BGP. Lots of people update prefix lists as a last resort vs proactively. Nobody removes things, making it hard. Automation of systems is also hard. Not impossible, but hard. I'm hoping some of the SDN marketing becomes reality when it comes to managing these configs. Maybe I will be able to have urpf work with my rpki and sdn. From goemon at anime.net Fri Mar 29 01:48:33 2013 From: goemon at anime.net (goemon at anime.net) Date: Thu, 28 Mar 2013 18:48:33 -0700 (PDT) Subject: Tier 2 ingress filtering In-Reply-To: References: <20947669.0.1364497409592.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, 28 Mar 2013, Jon Lewis wrote: > It's time for people to stop passing the buck on BCP38 (we don't do it, > because it really ought to be done at that other level) and start > implementing it where possible. An economic factor will be required for BCP38 to be effective. It will have to cost more money to not implement BCP38 than it will to implement it, in order to get widespread adoption. -Dan From ben at meh.net.nz Fri Mar 29 03:44:19 2013 From: ben at meh.net.nz (Ben Aitchison) Date: Fri, 29 Mar 2013 16:44:19 +1300 Subject: Open Resolver Problems In-Reply-To: References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> Message-ID: <20130329034419.GA26823@meh.net.nz> On Tue, Mar 26, 2013 at 07:07:16PM -0700, Tom Paseka wrote: > On Tue, Mar 26, 2013 at 7:04 PM, Matthew Petach wrote: > > > On Tue, Mar 26, 2013 at 6:06 PM, John Levine wrote: > > >>As a white-hat attempting to find problems to address through legitimate > > means, how > > >>do you ? > > > > > > You make friends with people with busy authoritative servers and see > > > who's querying them. > > > > I'm confused. Don't most authoritative servers have to > > answer to just about anyone in order to be useful? > > > > Matt > > > > Authoritative DNS servers need to implement rate limiting. (a client > shouldn't query you twice for the same thing within its TTL). unbound with it's dns-prefetching queries a dns servers again in I think the last 10% of ttl when returning hit to client to refresh ttl and keep it current. To me this doesn't seem excessive, and will improve performance for regularly accessed sites with short ttls which are quite common now (google, facebook, etc) It'd break if doing that extreme rate limiting. But so would things like rebooting a dns server, I think if rate limiting is done it has to be on the leniant side. Also how do you know that the dns resolver got a successful reply? Just because you've received a packet from a client doesn't mean that you can reach the client. So if there's one way traffic or excessive dual way packet loss the chances of prematurely blocking clients and creating longer outages is too great. That said, a lot of these amplifications attacks use ANY requests, which normal clients don't. And those could be rate limited down without effecting normal traffic I'm sure. Ben. From mysidia at gmail.com Fri Mar 29 10:11:02 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 29 Mar 2013 05:11:02 -0500 Subject: Open Resolver Problems In-Reply-To: <20130329034419.GA26823@meh.net.nz> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <20130329034419.GA26823@meh.net.nz> Message-ID: On 3/28/13, Ben Aitchison wrote: > On Tue, Mar 26, 2013 at 07:07:16PM -0700, Tom Paseka wrote: >> >> Authoritative DNS servers need to implement rate limiting. (a client >> shouldn't query you twice for the same thing within its TTL). The RFC doesn't say that is a should; a client MAY only query you once for a record within its TTL; the TTL is the duration after which the entry /must/ be expunged from the cache, it is an allowed maximum, not a minimum lifetime. A client may query plenty of times within its TTL. Sufficiently low rate limits on the authoritative would open the possibility of new kinds of attacks. If the authoritative DNS server decides to limit its rate of response, this might be used to conduct a DoS against the recursive nameserver's ability to lookup queries against the authoritative NS applying the limit. This could be leveraged remotely through a malicious website, remote loading bad image URLs from a significant number of non-existent subdomains, causing the rate limit to be attained. This may also be used to facilitate cache poisoning against legitimate recursors, targeting the domain whose authoritative servers apply a strict limit, by intentionally causing the recursor to make the maximum number of queries allowed, before sending spoofed responses. Especially a client that answers many different queries for a large number of clients and has limited cache sizes may query many times within a TTL. The average record cache lifetime might be 15 to 40 seconds (with as low as 1 second in cases), even if the record TTL is 86400. Or the cache may be manually flushed by the operator, in order to have a local DNS record change take effect more immediately (since most resolvers do not provide an admin command to flush only one zone from their cache). No guarantee is made about the size of the client's cache, number of records, or the client's cache aging policy. The response may be discarded or aged out, well before its TTL has elapsed. There may be other 'more popular' records on the same DNS resolver that are retained in the cache until TTL. Additional queries may be issued as a cache-poisoning avoidance mechanism. The same DNS servers might get queried multiple times successively for different records within the same zone. > unbound with it's dns-prefetching queries a dns servers again in I think the > last 10% of ttl when > returning hit to client to refresh ttl and keep it current. -- -JH From swmike at swm.pp.se Fri Mar 29 11:12:04 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 29 Mar 2013 12:12:04 +0100 (CET) Subject: Per-ASN data (Re: Open Resolver Problems) In-Reply-To: <44F2D720-AAD1-4669-97EC-FF91E7A6960F@puck.nether.net> References: <9317550.10944.1364308718442.JavaMail.root@benjamin.baylink.com> <3271B954-CD96-4783-8116-7F5554753DE3@ianai.net> <5151B4A8.7040009@foobar.org> <5151B987.50302@pubnix.net> <5151C0EC.7000008@foobar.org> <51522973.9010901@pubnix.net> <5153E7C1.2090308@mitteilung.com> <44F2D720-AAD1-4669-97EC-FF91E7A6960F@puck.nether.net> Message-ID: On Thu, 28 Mar 2013, Jared Mauch wrote: > I wanted to share PER-ASN data for those that are interested in this > generally. If you are a contact for these ASNs, you can e-mail me from > your corporate address to get access to the list. Interesting. My guess is that at least some of these have a lot of CPEs with global resolving turned on on the WAN port. So yes, I think it's very important to have these lists emailed regularily to alert people who might not check themselves all the time. The ISP operated CPEs should hopefully be possible to fix within weeks of notice (hopefully settings and/or software is controlled by the ISP). -- Mikael Abrahamsson email: swmike at swm.pp.se From marka at isc.org Fri Mar 29 11:24:16 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 29 Mar 2013 22:24:16 +1100 Subject: Open Resolver Problems In-Reply-To: Your message of "Fri, 29 Mar 2013 16:44:19 +1300." <20130329034419.GA26823@meh.net.nz> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <20130329034419.GA26823@meh.net.nz> Message-ID: <20130329112417.33B3E31AD16B@drugs.dv.isc.org> In message <20130329034419.GA26823 at meh.net.nz>, Ben Aitchison writes: > That said, a lot of these amplifications attacks use ANY requests, which > normal clients don't. And those could be rate limited down without > effecting normal traffic I'm sure. > > Ben. And you need to learn that normal clients *do* issue type any queries. Blocking any queries would be easy if normal clients didn't issue any queries. You would have need controls added to nameserver to block them if there wern't normal clients issuing any queries. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jgreco at ns.sol.net Fri Mar 29 11:58:03 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 29 Mar 2013 06:58:03 -0500 (CDT) Subject: Open Resolver Problems In-Reply-To: <20130329112417.33B3E31AD16B@drugs.dv.isc.org> Message-ID: <201303291158.r2TBw4jm087896@aurora.sol.net> > In message <20130329034419.GA26823 at meh.net.nz>, Ben Aitchison writes: > > That said, a lot of these amplifications attacks use ANY requests, which > > normal clients don't. And those could be rate limited down without > > effecting normal traffic I'm sure. > > And you need to learn that normal clients *do* issue type any > queries. Blocking any queries would be easy if normal clients > didn't issue any queries. You would have need controls added to > nameserver to block them if there wern't normal clients issuing any > queries. So you fsckin' rate limit them to a reasonable level. Really, I've spent a disappointing amount of time listening to the "but but but you can't DOOOOOOOOO that" from the ISC camp over the years, and while I understand Vixie's concerns about breaking things in unexpected ways, the reality of it all is that a DDoS attack is trivially identifiable from other traffic for any number of reasons, such as "like duh we don't usually see a megabit of queries from off site" or "like duh we don't usually see repeated queries for the same question from off site" or "like duh we don't usually see ANY queries from off site". So now go back and read what Ben wrote again, because > > And those could be rate limited down without > > effecting normal traffic I'm sure. THIS BIT IS THE EFFIN' POINT, WHICH YOU GUYS KEEP EFFIN' IGNORING. Look, this is a bad situation. Many networks don't BCP38. Many networks have unlimited open recursers. Many networks don't monitor for trouble. And then someone finds out how to take advantage. Well, all those things are bad, I'm sure we agree. However, some of us have decades of precedent and lots of deployment that make running an open recurser a necessity. That CAN be done, at least in our case, through some exemptions, and then running everything else through a drinking straw, because we KNOW that normal usage patterns of remote clients are ${x}. Now sadly I can't easily do a better job than just rate limiting inbound and outbound traffic because ISC won't entertain the idea. But what agenda does that bullheadedness serve? If you think you're "saving DNS" by not allowing administrators to twiddle with intelligent response rates, well, many of us will just take a bigger wrench and fix it with the brute force method. ... 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 mohta at necom830.hpcl.titech.ac.jp Fri Mar 29 11:58:30 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 29 Mar 2013 20:58:30 +0900 Subject: Open Resolver Problems In-Reply-To: <20130329034419.GA26823@meh.net.nz> References: <239F547E-5353-43EF-9EA7-6E91C44C9C66@delong.com> <20130327010612.34231.qmail@joyce.lan> <20130329034419.GA26823@meh.net.nz> Message-ID: <515581E6.9050704@necom830.hpcl.titech.ac.jp> Ben Aitchison wrote: >> Authoritative DNS servers need to implement rate limiting. (a client >> shouldn't query you twice for the same thing within its TTL). > > unbound with it's dns-prefetching queries a dns servers again in I think the last 10% of ttl when > returning hit to client to refresh ttl and keep it current. They are the worst things to do against DDOS, as queries must be repeated if query or reply packets are dropped, often because of DDOS. Rate limiting with token bucket of 5 or 7 packet deep could be useful, though it enables 5 or 7 times of amplification. > That said, a lot of these amplifications attacks use ANY > requests, which normal clients don't. And those could be > rate limited down without effecting normal traffic I'm sure. We should rather obsolete DNSSEC, which amplifies a lot even though it is not really deployed. Masataka Ohta From rdobbins at arbor.net Fri Mar 29 12:06:36 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 29 Mar 2013 12:06:36 +0000 Subject: Open Resolver Problems In-Reply-To: <201303291158.r2TBw4jm087896@aurora.sol.net> References: <201303291158.r2TBw4jm087896@aurora.sol.net> Message-ID: <95D324B3-305A-4DB0-B4EC-B560B6629120@arbor.net> On Mar 29, 2013, at 6:58 PM, Joe Greco wrote: > Really, I've spent a disappointing amount of time listening to the "but but but you can't DOOOOOOOOO that" What they're really worried about is folks arbitrarily deciding to permanently mask out ANY queries altogether as a matter of policy, rather than either rate-limiting them or selectively filtering them during an actual attack, and only within the scope of the servers/records being abused for that particular attack. Many measures which are not only permissible but are often vitally necessary in order to achieve partial service recovery during an attack can cause prohibitive levels of brokenness when implemented as matters of permanently-enforced policy. Given the history of such overt stupidity as blocking TCP/53, disallowing UDP DNS packets larger than 512 bytes, blocking ICMP necessary for PMTU-D, et. al., their concerns are not unreasonable. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jgreco at ns.sol.net Fri Mar 29 12:20:48 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 29 Mar 2013 07:20:48 -0500 (CDT) Subject: Open Resolver Problems In-Reply-To: <95D324B3-305A-4DB0-B4EC-B560B6629120@arbor.net> Message-ID: <201303291220.r2TCKnXe088250@aurora.sol.net> > On Mar 29, 2013, at 6:58 PM, Joe Greco wrote: > > > Really, I've spent a disappointing amount of time listening to the "but b= > ut but you can't DOOOOOOOOO that"=20 > > What they're really worried about is folks arbitrarily deciding to permanen= > tly mask out ANY queries altogether as a matter of policy, rather than eith= > er rate-limiting them or selectively filtering them during an actual attack= > , and only within the scope of the servers/records being abused for that pa= > rticular attack. > > Many measures which are not only permissible but are often vitally necessar= > y in order to achieve partial service recovery during an attack can cause p= > rohibitive levels of brokenness when implemented as matters of permanently-= > enforced policy. Given the history of such overt stupidity as blocking TCP= > /53, disallowing UDP DNS packets larger than 512 bytes, blocking ICMP neces= > sary for PMTU-D, et. al., their concerns are not unreasonable. There's a difference between "concerns" and bullheadedness. In the meantime, refusing to give admins tools to cope with an attack in a surgical-strike manner is basically just helping the attackers. As an administrator, I can cause brokenness in any number of clever, dumb, or accidental ways. However, it is also up to me to cause the network to work in the manner we need it to, and if I had a better understanding of our traffic than Vixie has, /which I do/, then I am in a better place to make intelligent decisions about what should and shouldn't be allowed and at what rates. In the meantime, all the "but but but THAT'LL BREAK THE INTARWEB" stuff, okay, great, so they don't want to supply tools that might break things. News flash, 300Gbps DNS attack underway. Not like THAT will break anything. ... 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 adam.vitkovsky at swan.sk Fri Mar 29 12:36:53 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Fri, 29 Mar 2013 13:36:53 +0100 Subject: BCP38 - Internet Death Penalty In-Reply-To: References: <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> <20130328161953.GA62536@ussenterprise.ufp.org> <20130328175803.GB62536@ussenterprise.ufp.org> Message-ID: <020e01ce2c7a$18090680$481b1380$@swan.sk> > If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. > And if your customer sets a BGP community defined to mean "don't advertise to peers" then you won't advertise it to the peer. > Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table. Yes asymmetric routing would kill the update-based urpf unless there would be an informational urpf NRLI we could use for these purposes adam From ahebert at pubnix.net Fri Mar 29 12:54:12 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 29 Mar 2013 08:54:12 -0400 Subject: BCP38 needs advertising In-Reply-To: References: <51530E4D.7000901@brightok.net> <515322D0.4030006@pubnix.net> Message-ID: <51558EF4.7090002@pubnix.net> Well, http://www.BCP38.info is up. Now to make it sexy :( Being that my English is barely passable (my French is worst btw) =D, I won't be able to carry this alone. PS: Account creation is up and verified... I'm gathering reference to other projects and sites (feel free to send them to me offlist); The wiki is/will be fully indexed on major search engines; I'm planning to also add reference to documented events to increase eyeballs on BCP38; Nothing is set in stone... from the wiki (maybe another CMS), the look, the registrar or even the hosting location. Hopefully this can become usefull =D ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/27/13 13:17, Paul Ferguson wrote: > Please reference: > > http://openresolverproject.org/ > http://spoofer.csail.mit.edu/ > http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack > > ...and anything else to raise the awareness level. > > Thanks, > > - ferg (co-perpetrator of BCP38) :-) > > On Wed, Mar 27, 2013 at 9:48 AM, Alain Hebert wrote: > >> bcp38.org coming soon =D >> >> ----- >> Alain Hebert ahebert at pubnix.net >> PubNIX Inc. >> 50 boul. St-Charles >> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >> >> On 03/27/13 11:20, Jack Bates wrote: >>> Outside of needing more details and examples, BCP38 could use more >>> advertising. >>> >>> The best option, if they would accept it, is to have all RIRs mention >>> BCP38 as well as require that mention of BCP38 be included in all IP >>> justification requests to customers (so that those who receive >>> netblocks from their ISPs are also aware of it). >>> >>> For ARIN, at least, having it mentioned in the attestation process >>> wouldn't be a bad idea. At least someone of management would be aware >>> of it. >>> >>> The only issue is see concerning the RIRs is that they may object to >>> it being out of scope to their duties. However, informing people of >>> something is not requiring implementation of something. On the other >>> hand, we know that there are a great number of networks that don't >>> participate with the community at large and may have no idea about >>> BCP38 and why it is important. >>> >>> >>> Jack >>> >>> >>> >>> >>> >> > > From tore at fud.no Fri Mar 29 12:31:47 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 29 Mar 2013 13:31:47 +0100 Subject: Tier 2 ingress filtering In-Reply-To: <20130328190243.GA11065@pob.ytti.fi> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> Message-ID: <515589B3.5070709@fud.no> * Saku Ytti > Question is, is it reasonable to expect customer to know what > networks they have. If yes, then you can ask them to create route > objects and then you can BGP prefix-filter and ACL on them. I do > both, and it has never been problem to my customers (enterprises, > CDNs, eyeballs). I've had some problems with my upstream providers' ingress filtering, for example: - Traffic sourced from a prefix announced as a more-specific route at transit connection in location A got filtered on a transit connection in location B, where only a greater aggregate was announced. - A GRE tunnel anchored in my routers' addresses in the eBGP link network (part of my provider's address space) stopped working, as my outbound packets was dropped by the provider's ingress filtering. - Traceroutes that reaches my network through provider A show one missing hop if my best return path back to the traceroute source is through provider B, and provider B is doing ingress filtering. This is because the ICMP TTL/HL exceeded packet is sourced from provider A's address space (my router's interface address in the eBGP link net). AFAIK, you represent one of my upstream providers, so sorry, but saying your customers have never had problems with your ingress filtering isn't entirely accurate. Everything works fine now, though. Best regards, -- Tore Anderson From bill at herrin.us Fri Mar 29 13:13:35 2013 From: bill at herrin.us (William Herrin) Date: Fri, 29 Mar 2013 09:13:35 -0400 Subject: BCP38 - Internet Death Penalty In-Reply-To: <020e01ce2c7a$18090680$481b1380$@swan.sk> References: <515309EC.4070402@brightok.net> <515318B8.2060306@brightok.net> <20130327191819.GA16425@pob.ytti.fi> <01a501ce2bae$95f4b7f0$c1de27d0$@swan.sk> <01c501ce2bc3$bb742050$325c60f0$@swan.sk> <20130328161953.GA62536@ussenterprise.ufp.org> <20130328175803.GB62536@ussenterprise.ufp.org> <020e01ce2c7a$18090680$481b1380$@swan.sk> Message-ID: On Fri, Mar 29, 2013 at 8:36 AM, Adam Vitkovsky wrote: >> If the best route you pick for the customer's advertisement goes to your > upstream instead of your customer, you won't advertise it to your peer. >> And if your customer sets a BGP community defined to mean "don't advertise > to peers" then you won't advertise it to the peer. >> Yet they may well transmit packets to you for which delivery to that peer > is directed by your routing table. > > Yes asymmetric routing would kill the update-based urpf unless there would > be an informational urpf NRLI we could use for these purposes Hi Adam, If we go down that path, let's not overload BGP. A distinct source address advisory protocol could have highly desirable auto-aggregation and update rate characteristics versus BGP. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nicolai-nanog at chocolatine.org Fri Mar 29 18:05:36 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Fri, 29 Mar 2013 13:05:36 -0500 Subject: BGP hijack of Spamhaus? Message-ID: <20130329180535.GA6737@vectra.student.iastate.edu> Hi all, Regarding the Spamhaus DDoS attack, there's a Cisco article [0] detailing its chronology, which cites greenhost.nl [1] claiming a BGP hijack by AS34109 (CB3ROB). Here, a /32 was announced (and accepted...) for 0.ns.spamhaus.org, and the fraudulent server returned 127.0.0.2 for *all* DNSBL queries, with the intent to undermine confidence in Spamhaus. Are there any confirmations of this claim? This needs to be investigated and proven/disproven. Nicolai 0. http://blogs.cisco.com/security/chronology-of-a-ddos-spamhaus/ 1. https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/ From job.snijders at atrato.com Fri Mar 29 18:14:52 2013 From: job.snijders at atrato.com (Job Snijders) Date: Fri, 29 Mar 2013 19:14:52 +0100 Subject: BGP hijack of Spamhaus? In-Reply-To: <20130329180535.GA6737@vectra.student.iastate.edu> References: <20130329180535.GA6737@vectra.student.iastate.edu> Message-ID: <87B9E13E-C271-4004-BCB3-8017FB2E4EEC@atrato.com> Hi Nicolai, It really happened, here are my notes. http://instituut.net/~job/cb3rob-spamhaus-hijack-21-mar-2013.txt Renesys also confirmed seeing the /32 from that direction, but they could not share the data because of an NDA. Because it was a /32, it was a hyperlocal event, if you can read Dutch and read the comments on the greenhost.nl blog, you'll see that Kamphuis is not denying, but rather elaborates on what he did: "wijst er ook maar even op dat onze uiteraard in-house developed dns code die we voor dit project ingezet hebben ook keurig op stdout liet zien WAT er door WIE werdt opgevraagd?" Roughly translates to: "Let me emphasize that our in-house developed dns code, which was used for this project very nicely logged to stdout WHO was requesting WHAT" Kind regards, Job On Mar 29, 2013, at 7:05 PM, Nicolai wrote: > Hi all, > > Regarding the Spamhaus DDoS attack, there's a Cisco article [0] > detailing its chronology, which cites greenhost.nl [1] claiming a BGP > hijack by AS34109 (CB3ROB). Here, a /32 was announced (and accepted...) > for 0.ns.spamhaus.org, and the fraudulent server returned 127.0.0.2 for > *all* DNSBL queries, with the intent to undermine confidence in > Spamhaus. > > Are there any confirmations of this claim? This needs to be > investigated and proven/disproven. > > Nicolai > > 0. http://blogs.cisco.com/security/chronology-of-a-ddos-spamhaus/ > 1. https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/ > -- AS5580 - Atrato IP Networks From cscora at apnic.net Fri Mar 29 18:33:27 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Mar 2013 04:33:27 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201303291833.r2TIXRM6011790@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Mar, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 447475 Prefixes after maximum aggregation: 183552 Deaggregation factor: 2.44 Unique aggregates announced to Internet: 220877 Total ASes present in the Internet Routing Table: 43648 Prefixes per ASN: 10.25 Origin-only ASes present in the Internet Routing Table: 34351 Origin ASes announcing only one prefix: 16022 Transit ASes present in the Internet Routing Table: 5791 Transit-only ASes present in the Internet Routing Table: 140 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 32 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 384 Unregistered ASNs in the Routing Table: 137 Number of 32-bit ASNs allocated by the RIRs: 4661 Number of 32-bit ASNs visible in the Routing Table: 3506 Prefixes from 32-bit ASNs in the Routing Table: 10199 Special use prefixes present in the Routing Table: 16 Prefixes being announced from unallocated address space: 208 Number of addresses announced to Internet: 2624177100 Equivalent to 156 /8s, 105 /16s and 195 /24s Percentage of available address space announced: 70.9 Percentage of allocated address space announced: 70.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.4 Total number of prefixes smaller than registry allocations: 158321 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 107311 Total APNIC prefixes after maximum aggregation: 33191 APNIC Deaggregation factor: 3.23 Prefixes being announced from the APNIC address blocks: 108485 Unique aggregates announced from the APNIC address blocks: 44275 APNIC Region origin ASes present in the Internet Routing Table: 4812 APNIC Prefixes per ASN: 22.54 APNIC Region origin ASes announcing only one prefix: 1227 APNIC Region transit ASes present in the Internet Routing Table: 817 Average APNIC Region AS path length visible: 4.8 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 473 Number of APNIC addresses announced to Internet: 719971904 Equivalent to 42 /8s, 233 /16s and 230 /24s Percentage of available APNIC address space announced: 84.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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, 150/8, 153/8, 163/8, 171/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, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 157280 Total ARIN prefixes after maximum aggregation: 79283 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 157969 Unique aggregates announced from the ARIN address blocks: 72182 ARIN Region origin ASes present in the Internet Routing Table: 15575 ARIN Prefixes per ASN: 10.14 ARIN Region origin ASes announcing only one prefix: 5914 ARIN Region transit ASes present in the Internet Routing Table: 1617 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1079709056 Equivalent to 64 /8s, 91 /16s and 13 /24s Percentage of available ARIN address space announced: 57.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 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, 23/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, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/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: 115077 Total RIPE prefixes after maximum aggregation: 59200 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 118791 Unique aggregates announced from the RIPE address blocks: 76668 RIPE Region origin ASes present in the Internet Routing Table: 17110 RIPE Prefixes per ASN: 6.94 RIPE Region origin ASes announcing only one prefix: 8143 RIPE Region transit ASes present in the Internet Routing Table: 2794 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2256 Number of RIPE addresses announced to Internet: 654721764 Equivalent to 39 /8s, 6 /16s and 66 /24s Percentage of available RIPE address space announced: 95.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, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47583 Total LACNIC prefixes after maximum aggregation: 9393 LACNIC Deaggregation factor: 5.07 Prefixes being announced from the LACNIC address blocks: 51566 Unique aggregates announced from the LACNIC address blocks: 23883 LACNIC Region origin ASes present in the Internet Routing Table: 1875 LACNIC Prefixes per ASN: 27.50 LACNIC Region origin ASes announcing only one prefix: 555 LACNIC Region transit ASes present in the Internet Routing Table: 348 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 753 Number of LACNIC addresses announced to Internet: 125351976 Equivalent to 7 /8s, 120 /16s and 184 /24s Percentage of available LACNIC address space announced: 74.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9887 Total AfriNIC prefixes after maximum aggregation: 2435 AfriNIC Deaggregation factor: 4.06 Prefixes being announced from the AfriNIC address blocks: 10456 Unique aggregates announced from the AfriNIC address blocks: 3677 AfriNIC Region origin ASes present in the Internet Routing Table: 601 AfriNIC Prefixes per ASN: 17.40 AfriNIC Region origin ASes announcing only one prefix: 183 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 44065536 Equivalent to 2 /8s, 160 /16s and 99 /24s Percentage of available AfriNIC address space announced: 43.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2950 11558 922 Korea Telecom (KIX) 17974 2507 840 86 PT TELEKOMUNIKASI INDONESIA 7545 1850 301 90 TPG Internet Pty Ltd 4755 1723 392 198 TATA Communications formerly 9829 1482 1189 43 BSNL National Internet Backbo 9583 1211 91 497 Sify Limited 7552 1171 1066 12 Vietel Corporation 4808 1122 2109 326 CNCGROUP IP network: China169 9498 1060 310 73 BHARTI Airtel Ltd. 24560 1056 385 169 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3032 3694 87 bellsouth.net, inc. 7029 2194 1266 213 Windstream Communications Inc 18566 2070 382 185 Covad Communications 22773 2006 2929 125 Cox Communications, Inc. 1785 1973 677 125 PaeTec Communications, Inc. 20115 1669 1610 613 Charter Communications 4323 1605 1138 396 Time Warner Telecom 30036 1322 291 666 Mediacom Communications Corp 7018 1311 10805 851 AT&T WorldNet Services 11492 1215 223 328 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1851 544 16 Corbina telecom 34984 1121 234 207 BILISIM TELEKOM 2118 1116 97 13 EUnet/RELCOM Autonomous Syste 12479 843 786 66 Uni2 Autonomous System 13188 837 99 33 Educational Network 20940 794 276 632 Akamai Technologies European 31148 786 41 19 FreeNet ISP 8551 717 370 43 Bezeq International 6830 715 2314 436 UPC Distribution Services 58113 666 74 386 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2489 1346 92 NET Servicos de Comunicao S.A 10620 2360 407 236 TVCABLE BOGOTA 7303 1673 1152 210 Telecom Argentina Stet-France 8151 1360 2674 402 UniNet S.A. de C.V. 6503 1186 435 68 AVANTEL, S.A. 14754 941 127 87 Telgua S. A. 18881 841 716 18 Global Village Telecom 27947 803 87 94 Telconet S.A 11830 725 364 14 Instituto Costarricense de El 3816 692 306 85 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1137 80 4 MOBITEL 24863 666 274 33 LINKdotNET AS number 6713 536 615 23 Itissalat Al-MAGHRIB 8452 346 446 12 TEDATA 24835 275 80 8 RAYA Telecom - Egypt 3741 262 906 220 The Internet Solution 12258 193 28 67 Vodacom Internet Company 29975 191 667 21 Vodacom 16637 189 698 88 MTN Network Solutions 33776 182 12 19 Starcomms Nigeria Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3032 3694 87 bellsouth.net, inc. 4766 2950 11558 922 Korea Telecom (KIX) 17974 2507 840 86 PT TELEKOMUNIKASI INDONESIA 28573 2489 1346 92 NET Servicos de Comunicao S.A 10620 2360 407 236 TVCABLE BOGOTA 7029 2194 1266 213 Windstream Communications Inc 18566 2070 382 185 Covad Communications 22773 2006 2929 125 Cox Communications, Inc. 1785 1973 677 125 PaeTec Communications, Inc. 8402 1851 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2507 2421 PT TELEKOMUNIKASI INDONESIA 28573 2489 2397 NET Servicos de Comunicao S.A 10620 2360 2124 TVCABLE BOGOTA 4766 2950 2028 Korea Telecom (KIX) 7029 2194 1981 Windstream Communications Inc 18566 2070 1885 Covad Communications 22773 2006 1881 Cox Communications, Inc. 1785 1973 1848 PaeTec Communications, Inc. 8402 1851 1835 Corbina telecom 7545 1850 1760 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 mywire Datentechnik GmbH Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.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:17 /9:13 /10:29 /11:87 /12:248 /13:483 /14:876 /15:1560 /16:12662 /17:6610 /18:10882 /19:21746 /20:31815 /21:33548 /22:46213 /23:41548 /24:234827 /25:1390 /26:1780 /27:863 /28:178 /29:63 /30:18 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2020 2070 Covad Communications 6389 1742 3032 bellsouth.net, inc. 7029 1597 2194 Windstream Communications Inc 8402 1544 1851 Corbina telecom 22773 1315 2006 Cox Communications, Inc. 30036 1203 1322 Mediacom Communications Corp 11492 1177 1215 Cable One 36998 1131 1137 MOBITEL 1785 1044 1973 PaeTec Communications, Inc. 7011 931 1175 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:741 2:792 3:3 4:13 5:834 6:3 8:513 12:1920 13:3 14:764 15:11 16:3 17:8 20:19 23:245 24:1801 27:1445 31:1179 32:44 33:2 34:5 36:43 37:1696 38:861 39:2 40:160 41:2591 42:183 44:6 46:1763 47:2 49:613 50:671 52:12 54:28 55:11 57:27 58:1106 59:564 60:296 61:1381 62:983 63:2038 64:4292 65:2177 66:4285 67:2061 68:1115 69:3273 70:874 71:526 72:1899 74:2555 75:402 76:293 77:1089 78:1020 79:580 80:1251 81:974 82:610 83:579 84:555 85:1151 86:469 87:948 88:512 89:1786 90:262 91:5449 92:608 93:1690 94:1866 95:1524 96:499 97:340 98:1049 99:41 100:29 101:311 103:2325 105:488 106:135 107:207 108:514 109:1803 110:876 111:1043 112:499 113:767 114:684 115:960 116:869 117:798 118:1003 119:1265 120:382 121:716 122:1738 123:1194 124:1326 125:1315 128:640 129:222 130:331 131:655 132:332 133:145 134:258 135:62 136:220 137:244 138:343 139:181 140:197 141:313 142:542 143:366 144:483 145:90 146:524 147:363 148:698 149:356 150:162 151:532 152:415 153:194 154:34 155:384 156:251 157:391 158:271 159:711 160:334 161:424 162:375 163:202 164:572 165:451 166:371 167:575 168:1016 169:132 170:1021 171:172 172:4 173:1578 174:583 175:436 176:1135 177:1868 178:1971 179:1 180:1385 181:300 182:1037 183:355 184:662 185:324 186:2401 187:1245 188:1905 189:1403 190:6687 192:6457 193:5674 194:4521 195:3467 196:1300 197:765 198:4278 199:5281 200:5994 201:2362 202:8876 203:8751 204:4487 205:2547 206:2791 207:2831 208:4063 209:3540 210:2916 211:1566 212:1995 213:1931 214:928 215:94 216:5198 217:1579 218:605 219:330 220:1270 221:544 222:319 223:496 End of report From bill at herrin.us Fri Mar 29 18:49:07 2013 From: bill at herrin.us (William Herrin) Date: Fri, 29 Mar 2013 14:49:07 -0400 Subject: Tier 2 ingress filtering In-Reply-To: <515589B3.5070709@fud.no> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no> Message-ID: On Fri, Mar 29, 2013 at 8:31 AM, Tore Anderson wrote: > I've had some problems with my upstream providers' ingress filtering, > for example: > > - Traffic sourced from a prefix announced as a more-specific route at > transit connection in location A got filtered on a transit connection in > location B, where only a greater aggregate was announced. Yep, I've heard of that. This is very bad behavior on your ISP's part. Spank them and if need be, name and shame. > - A GRE tunnel anchored in my routers' addresses in the eBGP link > network (part of my provider's address space) stopped working, as my > outbound packets was dropped by the provider's ingress filtering. Yep, I've encountered that. One of my providers decided that the IP on the exterior address of my router should not reach the Internet. Bad behavior. Spank, then name and shame. > - Traceroutes that reaches my network through provider A show one > missing hop if my best return path back to the traceroute source is > through provider B, and provider B is doing ingress filtering. This is > because the ICMP TTL/HL exceeded packet is sourced from provider A's > address space (my router's interface address in the eBGP link net). This is a bug, if you will, in router design. It isn't just traceroute that's missing a hop; if that router needed to send an ICMP destination unreachable in support of path MTU detection for some pair of hosts' TCP, the impacted TCP session would collapse. It gets even worse if you want to configure a particular router link with RFC1918 addresses. I've long thought router vendors should introduce a configuration option to specify the IP address from which ICMP errors are emitted rather than taking the interface address from which the packet causing the error was received. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Fri Mar 29 18:57:56 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 29 Mar 2013 14:57:56 -0400 Subject: alexandria cable cutters? In-Reply-To: References: Message-ID: On Thu, Mar 28, 2013 at 4:50 PM, Andrew Latham wrote: > On Thu, Mar 28, 2013 at 4:44 PM, Christopher Morrow > wrote: >> On Thu, Mar 28, 2013 at 2:46 AM, Randy Bush wrote: >>> nyt reports capture of scuba divers attempting to cut telecom egypt >>> undersea fiber. >>> >>> http://www.nytimes.com/aponline/2013/03/27/world/middleeast/ap-ml-egypt-internet.html >> >> how likely is it that a diver can cut an armored cable close to shore? >> without using explosives I mean... > > Its quite easy with a Thermal Lance... > > http://en.wikipedia.org/wiki/Thermal_lance sure, if you want to hang around and see the cut and perhaps do something about it... if you just want to drop-and-go... wrapping the cable in a pound/half-kilo of semtex/c4 will do fine. I'd expect 'alquaida' type folk to have easier access to explosives than a thermal lance as well. -chris From jra at baylink.com Fri Mar 29 19:14:34 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 29 Mar 2013 15:14:34 -0400 (EDT) Subject: BCP38.info is now active In-Reply-To: <51558EF4.7090002@pubnix.net> Message-ID: <22726096.163.1364584474019.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Alain Hebert" > http://www.BCP38.info is up. > > Now to make it sexy :( I'm workin' on it. > Being that my English is barely passable (my French is worst btw) > =D, I won't be able to carry this alone. Well, my English is *fantastic*, so I'll be happy to pith in. Or, y'know, "pitch". :-) > I'm gathering reference to other projects and sites (feel free > to send them to me offlist); Excellent point. > I'm planning to also add reference to documented events to > increase eyeballs on BCP38; I believe you mean people's after action reports, here; also an excellent idea. Create a new article for each event, named something like "Mar 2013 Cloudflare DNS DDOS attack" > Nothing is set in stone... from the wiki (maybe another CMS), > the look, the registrar or even the hosting location. Well, Mediawiki is certainly the platform I have the most background driving, but as long as the data can be ported, I don't object to changing... until people start making links to the inside of the site. :-} I too encourage people to dive in, though perhaps not yet to start publicizing the site widely for it's intended end purpose until we flesh it out for a week or so. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From cidr-report at potaroo.net Fri Mar 29 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Mar 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201303292200.r2TM00gh098346@wattle.apnic.net> This report has been generated at Fri Mar 29 21:13:17 2013 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-03-13 449261 258122 23-03-13 448921 257748 24-03-13 448792 258345 25-03-13 449799 256878 26-03-13 449721 257116 27-03-13 450093 256659 28-03-13 449061 256971 29-03-13 449781 257079 AS Summary 43764 Number of ASes in routing system 18138 Number of ASes announcing only one prefix 3032 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116943584 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'). --- 29Mar13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 449596 257085 192511 42.8% All ASes AS6389 3032 91 2941 97.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4766 2952 941 2011 68.1% KIXS-AS-KR Korea Telecom AS17974 2507 513 1994 79.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS28573 2488 616 1872 75.2% NET Servi?os de Comunica??o S.A. AS22773 2004 147 1857 92.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 2360 696 1664 70.5% Telmex Colombia S.A. AS18566 2070 474 1596 77.1% COVAD - Covad Communications Co. AS7303 1673 436 1237 73.9% Telecom Argentina S.A. AS4323 1608 400 1208 75.1% TWTC - tw telecom holdings, inc. AS4755 1723 632 1091 63.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1116 83 1033 92.6% RELCOM-AS OOO "NPO Relcom" AS7029 2195 1231 964 43.9% WINDSTREAM - Windstream Communications Inc AS7552 1171 225 946 80.8% VIETEL-AS-AP Vietel Corporation AS7545 1854 915 939 50.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 1009 172 837 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS18881 841 20 821 97.6% Global Village Telecom AS14754 942 142 800 84.9% Telgua AS1785 1973 1202 771 39.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1122 362 760 67.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS36998 1137 382 755 66.4% SDN-MOBITEL AS13977 834 126 708 84.9% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS8151 1369 704 665 48.6% Uninet S.A. de C.V. AS855 714 50 664 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS24560 1056 424 632 59.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 733 108 625 85.3% GIGAINFRA Softbank BB Corp. AS22561 1079 454 625 57.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 1053 444 609 57.8% GBLX Global Crossing Ltd. AS3356 1090 496 594 54.5% LEVEL3 Level 3 Communications AS19262 992 403 589 59.4% VZGNI-TRANSIT - Verizon Online LLC AS11830 725 146 579 79.9% Instituto Costarricense de Electricidad y Telecom. Total 45422 13035 32387 71.3% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA LTDA 190.52.192.0/24 AS27919 190.52.193.0/24 AS27919 190.52.194.0/24 AS27919 190.52.195.0/24 AS27919 190.52.196.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.197.0/24 AS27919 190.52.198.0/24 AS27919 190.52.199.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.200.0/24 AS27947 Telconet S.A 190.52.201.0/24 AS27947 Telconet S.A 190.52.202.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.203.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.205.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.206.0/24 AS3549 GBLX Global Crossing Ltd. 190.52.207.0/24 AS3549 GBLX Global Crossing Ltd. 190.124.252.0/22 AS7303 Telecom Argentina S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 UOL DIVEO S.A. 200.58.248.0/21 AS27849 200.107.248.0/24 AS27919 200.107.249.0/24 AS27919 200.107.250.0/24 AS27919 200.107.251.0/24 AS27919 200.107.252.0/24 AS28006 CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 201.71.16.0/20 AS28638 QLINK TELECOMUNICACOES E INTERNET LTDA 201.77.96.0/20 AS28639 Econocell do Brasil Ltda 201.222.32.0/20 AS27821 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 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.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. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc. 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 29 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Mar 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201303292200.r2TM01TT098354@wattle.apnic.net> BGP Update Report Interval: 21-Mar-13 -to- 28-Mar-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 61887 2.3% 27.4 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS58113 47518 1.8% 71.3 -- LIR-AS LIR DATACENTER TELECOM SRL 3 - AS8452 33762 1.2% 27.4 -- TE-AS TE-AS 4 - AS4538 28391 1.0% 52.7 -- ERX-CERNET-BKB China Education and Research Network Center 5 - AS28573 26266 1.0% 10.3 -- NET Servi?os de Comunica??o S.A. 6 - AS9829 25940 0.9% 17.3 -- BSNL-NIB National Internet Backbone 7 - AS7552 24066 0.9% 19.6 -- VIETEL-AS-AP Vietel Corporation 8 - AS3909 22124 0.8% 670.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - AS14754 19759 0.7% 21.0 -- Telgua 10 - AS7011 19366 0.7% 16.1 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. 11 - AS17974 18395 0.7% 7.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS13897 17385 0.6% 4346.2 -- CDC1 - Internet Brands Inc. 13 - AS2708 17152 0.6% 117.5 -- Universidad de Guanajuato 14 - AS24863 16368 0.6% 18.1 -- LINKdotNET-AS 15 - AS36998 15288 0.6% 11.9 -- SDN-MOBITEL 16 - AS45271 15232 0.6% 43.5 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 17 - AS23947 13753 0.5% 299.0 -- MORATELINDONAP-AS-ID PT.Mora Telematika Indonesia 18 - AS9583 13511 0.5% 10.0 -- SIFY-AS-IN Sify Limited 19 - AS18004 13336 0.5% 185.2 -- WIRELESSNET-ID-AP WIRELESSNET AS 20 - AS35994 12300 0.5% 120.6 -- AKAMAI-AS - Akamai Technologies, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13897 17385 0.6% 4346.2 -- CDC1 - Internet Brands Inc. 2 - AS6174 5854 0.2% 2927.0 -- SPRINTLINK8 - Sprint 3 - AS14680 6856 0.2% 2285.3 -- REALE-6 - Auction.com 4 - AS5074 3339 0.1% 1669.5 -- ASN-ATTELS - AT&T BMGS 5 - AS37367 3299 0.1% 1649.5 -- CALLKEY 6 - AS58395 6407 0.2% 1601.8 -- CATFISH-AS-ID PT. DUNIACATFISH KREATIF MEDIA 7 - AS4467 1507 0.1% 1507.0 -- EASYLINK3 - AT&T Services, Inc. 8 - AS17293 4773 0.2% 1193.2 -- VTXC - VTX Communications 9 - AS45344 1042 0.0% 1042.0 -- IIUM-MY International Islamic University Of Malaysia 10 - AS3 4343 0.2% 420.0 -- CMED-AS Cmed Technology Ltd 11 - AS40946 5033 0.2% 838.8 -- PROCON - Sat Track 12 - AS41023 3053 0.1% 763.2 -- ARREKS-AS Agencja Rozwoju Regionalnego ARREKS S.A. 13 - AS54057 3460 0.1% 692.0 -- WST-INET - Wheat State Telephone, Inc. 14 - AS3909 22124 0.8% 670.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 15 - AS46399 632 0.0% 632.0 -- YAPSTONE - Yapstone, Inc. 16 - AS46105 595 0.0% 595.0 -- HMLP-ASN - HealthCor Management, L.P. 17 - AS37440 2737 0.1% 547.4 -- Airtel-MW 18 - AS45770 523 0.0% 523.0 -- SBY-EPROC-AS-ID Bagian Bina Program - Pemerintah Kota Surabaya 19 - AS46017 516 0.0% 516.0 -- BAKOSURTANAL-AS-ID Badan Koordinasi Survei dan Pemetaan Nasional (BAKOSURTANAL) 20 - AS42860 1474 0.1% 491.3 -- EFT Energy Financing Team (Switzerland) AG TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.41.70.0/24 9682 0.3% AS2697 -- ERX-ERNET-AS Education and Research Network 2 - 98.158.204.0/23 8692 0.3% AS13897 -- CDC1 - Internet Brands Inc. 3 - 98.158.200.0/24 8689 0.3% AS13897 -- CDC1 - Internet Brands Inc. 4 - 192.58.232.0/24 7799 0.3% AS6629 -- NOAA-AS - NOAA 5 - 151.118.18.0/24 7360 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - 151.118.254.0/24 7346 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - 151.118.255.0/24 7346 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 8 - 103.11.254.0/24 6323 0.2% AS58395 -- CATFISH-AS-ID PT. DUNIACATFISH KREATIF MEDIA 9 - 12.139.133.0/24 5682 0.2% AS14680 -- REALE-6 - Auction.com 10 - 208.92.131.0/24 5024 0.2% AS40946 -- PROCON - Sat Track 11 - 112.110.82.0/23 4919 0.2% AS45271 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 12 - 112.110.84.0/22 4910 0.2% AS45271 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 13 - 194.63.9.0/24 4528 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 202.95.159.0/24 4312 0.1% AS9875 -- PESAT1-AS-AP PT. Pasifik Satelit Nusantara 15 - 69.38.178.0/24 4105 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 216.183.32.0/19 3969 0.1% AS17293 -- VTXC - VTX Communications 17 - 58.184.229.0/24 3834 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM 18 - 50.115.154.0/24 3440 0.1% AS54057 -- WST-INET - Wheat State Telephone, Inc. 19 - 41.75.40.0/21 3298 0.1% AS37367 -- CALLKEY 20 - 115.170.128.0/17 2986 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From phil at cluestick.net Fri Mar 29 22:24:34 2013 From: phil at cluestick.net (Phil Dyer) Date: Fri, 29 Mar 2013 18:24:34 -0400 Subject: BCP38.info is now active In-Reply-To: <22726096.163.1364584474019.JavaMail.root@benjamin.baylink.com> References: <51558EF4.7090002@pubnix.net> <22726096.163.1364584474019.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Mar 29, 2013 at 3:14 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Alain Hebert" > > > http://www.BCP38.info is up. > > > I can't prove that from my neck of the woods... $ dig www.bcp38.info ; <<>> DiG 9.7.6-P1 <<>> www.bcp38.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22339 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.bcp38.info. IN A phil ?? From owen at delong.com Fri Mar 29 22:37:57 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Mar 2013 15:37:57 -0700 Subject: BCP38.info is now active In-Reply-To: References: <51558EF4.7090002@pubnix.net> <22726096.163.1364584474019.JavaMail.root@benjamin.baylink.com> Message-ID: <14690D76-D583-4392-B4C0-71F3BD01E18C@delong.com> I get amusing results as well: delong-dhcp227:owen (182) ~/idisk_backup/draft-delong-ula-example % host www.bcp38.info www.bcp38.info has address 192.172.250.28 www.bcp38.info has IPv6 address 2607:2a00:1:6::c0ac:fa1c Host www.bcp38.info not found: 3(NXDOMAIN) Owen On Mar 29, 2013, at 15:24 , Phil Dyer wrote: > On Fri, Mar 29, 2013 at 3:14 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Alain Hebert" >> >>> http://www.BCP38.info is up. >>> >> > > I can't prove that from my neck of the woods... > > $ dig www.bcp38.info > > ; <<>> DiG 9.7.6-P1 <<>> www.bcp38.info > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22339 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.bcp38.info. IN A > > phil > > ?? From ahebert at pubnix.net Fri Mar 29 23:08:06 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 29 Mar 2013 19:08:06 -0400 Subject: BCP38.info is now active In-Reply-To: <14690D76-D583-4392-B4C0-71F3BD01E18C@delong.com> References: <51558EF4.7090002@pubnix.net> <22726096.163.1364584474019.JavaMail.root@benjamin.baylink.com> <14690D76-D583-4392-B4C0-71F3BD01E18C@delong.com> Message-ID: <51561ED6.7050600@pubnix.net> Well, Usual failure from my part =D. But I think I see what's happening... ns1.bcp38.org ns2.bcp38.org Are not yet registered. I've move them to "production" servers until it complete. Let me know. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/29/13 18:37, Owen DeLong wrote: > I get amusing results as well: > > delong-dhcp227:owen (182) ~/idisk_backup/draft-delong-ula-example % host www.bcp38.info > www.bcp38.info has address 192.172.250.28 > www.bcp38.info has IPv6 address 2607:2a00:1:6::c0ac:fa1c > Host www.bcp38.info not found: 3(NXDOMAIN) > > Owen > > On Mar 29, 2013, at 15:24 , Phil Dyer wrote: > >> On Fri, Mar 29, 2013 at 3:14 PM, Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Alain Hebert" >>>> http://www.BCP38.info is up. >>>> >> I can't prove that from my neck of the woods... >> >> $ dig www.bcp38.info >> >> ; <<>> DiG 9.7.6-P1 <<>> www.bcp38.info >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22339 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;www.bcp38.info. IN A >> >> phil >> >> ?? > > > From nanog at haller.ws Sat Mar 30 03:04:16 2013 From: nanog at haller.ws (Patrick) Date: Sat, 30 Mar 2013 11:04:16 +0800 Subject: Tier 2 ingress filtering In-Reply-To: References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no> Message-ID: <20130330030415.GS14491@haller.ws> On 2013-03-29 14:49, William Herrin wrote: > I've long thought router vendors should introduce a configuration > option to specify the IP address from which ICMP errors are emitted > rather than taking the interface address from which the packet causing > the error was received. Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip unnumbered loop0' everywhere. ;) From alejandroacostaalamo at gmail.com Sat Mar 30 03:21:58 2013 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Fri, 29 Mar 2013 22:51:58 -0430 Subject: Tier 2 ingress filtering In-Reply-To: <20130330030415.GS14491@haller.ws> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no> <20130330030415.GS14491@haller.ws> Message-ID: Hi, On 3/29/13, Patrick wrote: > On 2013-03-29 14:49, William Herrin wrote: >> I've long thought router vendors should introduce a configuration >> option to specify the IP address from which ICMP errors are emitted >> rather than taking the interface address from which the packet causing >> the error was received. > > Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip > unnumbered loop0' everywhere. ;) Why do you think it will be better?, can you explain? So far I can only think in a more difficult troubleshooting if this idea/feature gets spread. I guess based in the scenario where the output interface can not reach Internet sounds as a practical solution however for sure the output interface is reachable inside the provider network. Thks, Alejandro, > From frogstarr78 at gmail.com Sat Mar 30 03:55:55 2013 From: frogstarr78 at gmail.com (Scott Noel-Hemming) Date: Fri, 29 Mar 2013 20:55:55 -0700 Subject: Open Resolver Problems In-Reply-To: <13438.1364226293@turing-police.cc.vt.edu> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> Message-ID: <5156624B.7030708@gmail.com> On 03/25/2013 08:44 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 25 Mar 2013 15:38:01 -0000, Nick Hilliard said: >> On 25/03/2013 14:33, Mikael Abrahamsson wrote: >>> I would like to be able to request an IP list of open resolvers in my ASN, >>> perhaps sent to the contact details in RIPE whois database to make sure I'm >>> not falsely representing that ASN. >> Why would that matter? This is publicly available information. > Some of us have both publicly-facing authoritative DNS, and inward > facing recursive servers that may be open resolvers but can't be > found via NS entries (so the IP addresses of those aren't exactly > publicly available info). Sounds like your making the faulty assumption that an attacker would use normal means to find your servers. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From dougb at dougbarton.us Sat Mar 30 05:00:09 2013 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 29 Mar 2013 22:00:09 -0700 Subject: Open Resolver Problems In-Reply-To: <201303291158.r2TBw4jm087896@aurora.sol.net> References: <201303291158.r2TBw4jm087896@aurora.sol.net> Message-ID: <51567159.8040603@dougbarton.us> On 03/29/2013 04:58 AM, Joe Greco wrote: > Really, I've spent a disappointing amount of time listening to the > "but but but you can't DOOOOOOOOO that" from the ISC camp over the > years Joe, Perhaps you haven't been keeping up with the Response Rate Limiting work? http://www.redbarn.org/dns/ratelimits http://ss.vix.com/~vixie/isc-tn-2012-1.txt From bill at herrin.us Sat Mar 30 05:07:11 2013 From: bill at herrin.us (William Herrin) Date: Sat, 30 Mar 2013 01:07:11 -0400 Subject: Tier 2 ingress filtering In-Reply-To: References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no> <20130330030415.GS14491@haller.ws> Message-ID: On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta wrote: > On 3/29/13, Patrick wrote: >> On 2013-03-29 14:49, William Herrin wrote: >>> I've long thought router vendors should introduce a configuration >>> option to specify the IP address from which ICMP errors are emitted >>> rather than taking the interface address from which the packet causing >>> the error was received. >> >> Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip >> unnumbered loop0' everywhere. ;) > > Why do you think it will be better?, can you explain? Hi Alejandro, Consider the alternatives: 1. Provide a router configuration option (per router and/or per interface) to emit ICMP error messages from a specified IP address rather than the interface address. 2. At every border, kick packets without an Internet-legitimate source address up to the slow path for network address translation to a source address which is valid. 3. Design your network so that any router with at least one network interface whose IP address is not valid on the Internet has exactly the same MTU on every interface, and at least an MTU of 1500 on all of them, guaranteeing that the router will never emit a fragmentation-needed message. And do this consistently. Every time. 4. Redesign TCP so it doesn't rely on ICMP destination unreachable messages to determine path MTU and get your new design deployed into every piece of software on the Internet. 5. Accept that TCP will break unexpectedly due to lost fragmentation-needed messages, presenting as a particularly nasty and intermittent failure that's hard to track and harder to fix. Which do you find least offensive? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From saku at ytti.fi Sat Mar 30 13:32:46 2013 From: saku at ytti.fi (Saku Ytti) Date: Sat, 30 Mar 2013 15:32:46 +0200 Subject: Tier 2 ingress filtering In-Reply-To: <515589B3.5070709@fud.no> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no> Message-ID: <20130330133246.GA18899@pob.ytti.fi> On (2013-03-29 13:31 +0100), Tore Anderson wrote: > I've had some problems with my upstream providers' ingress filtering, > for example: That sounds like uRPF, which you should not run towards your transit customers. I'm talking only about using ACL. And I stand-by that I've never had to fix something that is broken. Now naturally it has happened that my customer has gotten new prefix, and things have been wonky, because they forgot to make route object, which meant we didn't allow prefix nor allow it in ACL. However, I think my customers prefer this. The alternative is that everything works fine for 6month, until the other transit who does not BGP filter goes down, after which the network stops propagating and everything is down. At least with ACL you notice the problem immediately. -- ++ytti From jra at baylink.com Sat Mar 30 15:39:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 30 Mar 2013 11:39:02 -0400 (EDT) Subject: Tier 2 ingress filtering - folo In-Reply-To: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> Message-ID: <32569862.229.1364657942803.JavaMail.root@benjamin.baylink.com> Quite a number of people have responded to this post. But no one's actually addressed my key question: ----- Original Message ----- > From: "Jay Ashworth" > In the current BCP38/DDoS discussions, I've seen a lot of people suggesting > that it's practical to do ingress filtering at places other than the > edge. > > My understanding has always been different from that, based on the idea > that the carrier to which a customer connects is the only one with which > that end-site has a business relationship, and therefore (frex), the > only one whom that end-site could advise that they believe they have a > valid reason to originate traffic from address space not otherwise known to > the carrier; jack-leg dual-homing, for example, as was discussed in > still a third thread this week. Here's the important part: > The edge carrier's *upstream* is not going to know that it's > reasonable for their customer -- the end-site's carrier -- to be originating > traffic with those source addresses, and if they ingress filter based on the > prefixes they route down to that carrier, they'll drop that traffic... > > which is not fraudulent, and has a valid engineering reason to exist > and appear on their incoming interface. An edge carrier, to whom an end-site connects, *can know* that that particular end-site will need an exemption, for reasons like non-BGP dual-homing or load- balancing. But there's no way for an upstream transit carrier to know that *at the present time*. So, short of building another big RPKI infrastructure to authenticate it (which isn't going to happen this decade) or getting lots of carriers to cooperate in some other information exchange so they know where to poke extra holes (which isn't going to happen this decade), is there any way at all to actually do ingress filtering at the transit level -- as many here advocate -- without throwing out the baby of *valid* unexpected source addressed packets with the bathwater of *actual* fraud? IP packets with source addresses that don't match the address space of the interface you got them on are *not* a 100.0% accurate proxy for fraud and attacks. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From saku at ytti.fi Sat Mar 30 16:34:25 2013 From: saku at ytti.fi (Saku Ytti) Date: Sat, 30 Mar 2013 18:34:25 +0200 Subject: Tier 2 ingress filtering - folo In-Reply-To: <32569862.229.1364657942803.JavaMail.root@benjamin.baylink.com> References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <32569862.229.1364657942803.JavaMail.root@benjamin.baylink.com> Message-ID: <20130330163425.GA29893@pob.ytti.fi> On (2013-03-30 11:39 -0400), Jay Ashworth wrote: > But there's no way for an upstream transit carrier to know that *at the present > time*. We expect our customers to mark any customers they have in their AS-SET. And we filter BGP announcements and we ACL traffic based on that. I know mandating strict IRR is not practical to everyone today. But for me, it's practical. Sometimes I need to educate customers how to create route object or AS-SET. At least every non-stubby ASN facing stubby ASN should be able to do strict IRR. This is about 6000 networks. Compared to other options: 1) close recursive name servers - even if all are closed, attack vector is virtually the same, as large RR can be found in arbitrary authorative due to DNSSEC - snmpbulkwalk - UDP du jour 2) implement uRPF at last mile - hundreds of millions of ports, many of them running on autopilot, good chunk of them will never ever support uRPF Obviously if we could choose 2) it would be best, but we can't choose it. -- ++ytti From nicolai-nanog at chocolatine.org Sat Mar 30 21:08:41 2013 From: nicolai-nanog at chocolatine.org (Nicolai) Date: Sat, 30 Mar 2013 16:08:41 -0500 Subject: BGP hijack of Spamhaus? In-Reply-To: <87B9E13E-C271-4004-BCB3-8017FB2E4EEC@atrato.com> References: <20130329180535.GA6737@vectra.student.iastate.edu> <87B9E13E-C271-4004-BCB3-8017FB2E4EEC@atrato.com> Message-ID: <20130330210841.GB25133@vectra.student.iastate.edu> On Fri, Mar 29, 2013 at 07:14:52PM +0100, Job Snijders wrote: > Hi Nicolai, > > It really happened, here are my notes. > > http://instituut.net/~job/cb3rob-spamhaus-hijack-21-mar-2013.txt Thanks again for this, Job. (Other response in private mail.) I just wanted to note for anyone interested, there's another article stating that AS34109 (CB3ROB) had also recently hijacked 205.19.72.0/23, owned by the DoD, over the two week period from March 7-21. http://www.bgpmon.net/looking-at-the-spamhouse-ddos-from-a-bgp-perspective/ Nicolai From mpetach at netflight.com Sat Mar 30 21:57:53 2013 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 30 Mar 2013 14:57:53 -0700 Subject: So how big was it *really*? In-Reply-To: <1497934.11316.1364490629995.JavaMail.root@benjamin.baylink.com> References: <20130328133601.GT20231@virtual.bogons.net> <1497934.11316.1364490629995.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Mar 28, 2013 at 10:10 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Simon Lockhart" > >> And there's a (semi-)public response from one of Cloudfare's >> upstreams: >> >> http://cluepon.net/ras/gizmodo > > Money quote: > > """ > so when 300 Gbps > of NEW traffic suddenly shows up and all wants to go to ONE location, > someone is going to have a bad day. > """ I am *sooo* reminded of http://xkcd.com/1133/ and http://youwillnotgotospacetoday.tumblr.com/ 'Your internet is having a bad day, and your packets will not be going to their destination' ^_^; Matt From Valdis.Kletnieks at vt.edu Sat Mar 30 22:42:56 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 30 Mar 2013 18:42:56 -0400 Subject: So how big was it *really*? In-Reply-To: Your message of "Sat, 30 Mar 2013 14:57:53 -0700." References: <20130328133601.GT20231@virtual.bogons.net> <1497934.11316.1364490629995.JavaMail.root@benjamin.baylink.com> Message-ID: <65602.1364683376@turing-police.cc.vt.edu> On Sat, 30 Mar 2013 14:57:53 -0700, Matthew Petach said: > I am *sooo* reminded of > http://xkcd.com/1133/ > and > http://youwillnotgotospacetoday.tumblr.com/ > > 'Your internet is having a bad day, and > your packets will not be going to their destination' I heard the failure of a server to boot described as "You will not go to userspace today". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From alejandroacostaalamo at gmail.com Sun Mar 31 02:17:13 2013 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Sat, 30 Mar 2013 21:47:13 -0430 Subject: Tier 2 ingress filtering In-Reply-To: References: <32958044.11312.1364490444084.JavaMail.root@benjamin.baylink.com> <20130328190243.GA11065@pob.ytti.fi> <515589B3.5070709@fud.no> <20130330030415.GS14491@haller.ws> Message-ID: Hi William, Thanks for your response, my comments below: On 3/30/13, William Herrin wrote: > On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta > wrote: >> On 3/29/13, Patrick wrote: >>> On 2013-03-29 14:49, William Herrin wrote: >>>> I've long thought router vendors should introduce a configuration >>>> option to specify the IP address from which ICMP errors are emitted >>>> rather than taking the interface address from which the packet causing >>>> the error was received. >>> >>> Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip >>> unnumbered loop0' everywhere. ;) >> >> Why do you think it will be better?, can you explain? > > Hi Alejandro, > > Consider the alternatives: > > 1. Provide a router configuration option (per router and/or per > interface) to emit ICMP error messages from a specified IP address > rather than the interface address. I imagine that and it sounds terrific. I guess at least this option should come disabled by default. > > 2. At every border, kick packets without an Internet-legitimate source > address up to the slow path for network address translation to a > source address which is valid. IMHO this can be achieved with the current behaviour. > > 3. Design your network so that any router with at least one network > interface whose IP address is not valid on the Internet has exactly > the same MTU on every interface, and at least an MTU of 1500 on all of > them, guaranteeing that the router will never emit a > fragmentation-needed message. And do this consistently. Every time. If you have pmtud enabled you won't need this every time > > 4. Redesign TCP so it doesn't rely on ICMP destination unreachable > messages to determine path MTU and get your new design deployed into > every piece of software on the Internet. You will have the same problem using only one output interface for ICMP error/messages. Of course based in your comments you mean you will need to troubleshoot this interface only once. > > 5. Accept that TCP will break unexpectedly due to lost > fragmentation-needed messages, presenting as a particularly nasty and > intermittent failure that's hard to track and harder to fix. Same answer as in 3. > > > Which do you find least offensive? None of them if offensive, I think this could be a nice feature to have but I hope it's disable by default. > > Regards, > Bill Herrin Thanks, Regards, Alejandro Acosta, > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From jra at baylink.com Sun Mar 31 02:53:18 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 30 Mar 2013 22:53:18 -0400 (EDT) Subject: CIO Mag on the Spanhaus attack Message-ID: <26555655.281.1364698398014.JavaMail.root@benjamin.baylink.com> Mentions ODRP, doesn't mention BCP38. http://www.cio.com/article/730882/Spamhaus_Attacks_Expose_Huge_Open_DNS_Server_Dangers Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From netfortius at gmail.com Sun Mar 31 07:47:25 2013 From: netfortius at gmail.com (Stefan) Date: Sun, 31 Mar 2013 02:47:25 -0500 Subject: [Q] Any detailed enterprise WAN QoS design/config for MPLS services, f/various ISPs? Message-ID: Been looking for Verizon and AT&T AVPN MPLS, specifically. Pointers highly appreciated, as the nanog archive does not seem to have searchable items ref such. Cisco docs have some info, but I am mostly looking for tried and proven configs with the specifics that Verizon and AT&T offer. Traditional AT&T (e.g.) means involve the likes of (for main DC): policy-map description CoS Profile % RT (nb1/nb2/nb3) class <0> priority percent class <1> set dscp af21 bandwidth class C<2> set dscp af31 bandwidth policy-map <3> class <4> set dscp af21 class <5> set dscp af31 class <6> priority percent policy-map class class-default shape average service-policy ... interface GigabitEthernet2/0/0.x ... ip pim sparse-mode service-policy output <3> ... or the likes (can't even tell if I consistently sanitized the info, but you get the point) I am interested in main hub/DC + remotes - docs, preferably. TIA, ***Stefan From jra at baylink.com Sun Mar 31 14:48:55 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 31 Mar 2013 10:48:55 -0400 (EDT) Subject: BCP38 tester? Message-ID: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com> Is there a program which users can run on an end-site workstation which would test whether they are being some link which is doing BCP38, or some related type of source-address ingress filtering? I'm hoping for something that could be downloaded by users and run, and try to forge a few packets to somewhere useful, which could be logged somehow in conjunction with some unforged packets containing a traceroute, so we could build up a database of leaky networks. On a related topic, while I know GRC Research's Steve Gibson is a bit of a polarizing personality, he does have a fairly sizable consumer audience, and might be a great distribution venue for such a thing. Or, perhaps, is there someone on here from Ookla? Patrick? Could Akamai be persuaded to take an interest in this as a research project? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fergdawgster at gmail.com Sun Mar 31 14:54:55 2013 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 31 Mar 2013 07:54:55 -0700 Subject: BCP38 tester? In-Reply-To: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com> References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com> Message-ID: You mean like this? :-) http://spoofer.csail.mit.edu/ - ferg On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth wrote: > Is there a program which users can run on an end-site workstation which > would test whether they are being some link which is doing BCP38, or some > related type of source-address ingress filtering? > > I'm hoping for something that could be downloaded by users and run, and > try to forge a few packets to somewhere useful, which could be logged > somehow in conjunction with some unforged packets containing a traceroute, > so we could build up a database of leaky networks. > > On a related topic, while I know GRC Research's Steve Gibson is a bit of > a polarizing personality, he does have a fairly sizable consumer audience, > and might be a great distribution venue for such a thing. > > Or, perhaps, is there someone on here from Ookla? > > Patrick? Could Akamai be persuaded to take an interest in this as a > research project? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com From jra at baylink.com Sun Mar 31 15:50:12 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 31 Mar 2013 11:50:12 -0400 (EDT) Subject: BCP38 tester? In-Reply-To: Message-ID: <14263436.313.1364745012871.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Ferguson" > You mean like this? :-) > > http://spoofer.csail.mit.edu/ I dunno; does that automatically submit the details to a central site, and not bother the user with anything more than "Your connection appears to be protected with BCP38 filtering" or "No, your provider appears not to be using BCP38 filtering; we'll let them know"? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jlewis at lewis.org Sun Mar 31 17:31:37 2013 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 31 Mar 2013 13:31:37 -0400 (EDT) Subject: BCP38 tester? In-Reply-To: References: <28787874.307.1364741335939.JavaMail.root@benjamin.baylink.com> Message-ID: They should updated their autoconf. It fails on modern 64-bit Linux. On Sun, 31 Mar 2013, Paul Ferguson wrote: > You mean like this? :-) > > http://spoofer.csail.mit.edu/ > > - ferg > > > On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth wrote: > >> Is there a program which users can run on an end-site workstation which >> would test whether they are being some link which is doing BCP38, or some >> related type of source-address ingress filtering? >> >> I'm hoping for something that could be downloaded by users and run, and >> try to forge a few packets to somewhere useful, which could be logged >> somehow in conjunction with some unforged packets containing a traceroute, >> so we could build up a database of leaky networks. >> >> On a related topic, while I know GRC Research's Steve Gibson is a bit of >> a polarizing personality, he does have a fairly sizable consumer audience, >> and might be a great distribution venue for such a thing. >> >> Or, perhaps, is there someone on here from Ookla? >> >> Patrick? Could Akamai be persuaded to take an interest in this as a >> research project? >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink jra at baylink.com >> Designer The Things I Think RFC 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII >> St Petersburg FL USA #natog +1 727 647 1274 >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > fergdawgster(at)gmail.com > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mysidia at gmail.com Sun Mar 31 21:09:35 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 31 Mar 2013 16:09:35 -0500 Subject: Open Resolver Problems In-Reply-To: <5156624B.7030708@gmail.com> References: <1BCE4663-EEB4-44EB-997F-906B232F41A1@puck.nether.net> <51506F59.7080101@foobar.org> <13438.1364226293@turing-police.cc.vt.edu> <5156624B.7030708@gmail.com> Message-ID: On 3/29/13, Scott Noel-Hemming wrote: >> Some of us have both publicly-facing authoritative DNS, and inward >> facing recursive servers that may be open resolvers but can't be >> found via NS entries (so the IP addresses of those aren't exactly >> publicly available info). > Sounds like your making the faulty assumption that an attacker would use > normal means to find your servers. A distributed scan of the entire IPv4 space for all internet IPs running open DNS servers is fairly doable; actually a long term scan taking 100 to 200 days of continuous DNS scanning is completely trivial. The fact a recursive DNS server exists at a certain IP address can also be exposed to the operators of authoritative (or root) DNS servers, through the queries that the recursive servers make. For example: an internet advertiser can place syndicated ads on certain websites, containing images referring to a server on their domain (that requires resolving their domain), and then mine data from the IP addresses that are contacting their authoritative DNS servers in order to make queries. For some domains, the authoritative DNS servers might even want to ping the recursor, and use the result to decide what set of answers to send for future queries, in order to reply with choices that are anticipated to minimize latency. -- -JH From l-nanog at iodi.se Sun Mar 31 23:53:15 2013 From: l-nanog at iodi.se (Joseph Chin) Date: Mon, 1 Apr 2013 00:53:15 +0100 Subject: Dropping connectivity for Cyberbunker? Message-ID: <01cb01ce2e6a$e9ef7ac0$bdce7040$@iodi.se> This article talks about convincing direct peers and transit providers to stop Net connectivity to the culprit http://www.darkreading.com/blog/240151931/who-supplies-cyberbunker.html Would it not be easier if a majority of the ISPs simply filter BGP prefixes containing the aforementioned ASes in the paths? Maybe many of you are already quietly doing it? This probably won't stop the baddies from spoofing source addresses for attacks, but it will make Cyberbunker economically unviable as no one will be able to reach assets hosted on their IP addresses. They have proven beyond a reasonable doubt that they have no intention to behave as civilized Netizens. So why should the rest of us continue to play nice? Does anyone see a problem with this action?