Re: Screwed Again: House Rejects Net Neutrality
On Fri, 9 Jun 2006, Fergie wrote: Sorry to interrupt the ever-so-interesting discussions on the list, but this is actually important. Sorry for the editorial comment -- now for the facts. The current bill is mostly about Cable TV licensing, with some other stuff like VOIP 9-1-1 thrown in, and doesn't change the rules for the Internet. http://www.washingtonpost.com/wp-dyn/content/article/2006/06/08/AR2006060802087.html House Votes to Ease Cable TV Licensing for Phone Companies By Arshad Mohammed Washington Post Staff Writer Friday, June 9, 2006; Page D02 The House of Representatives yesterday passed a bill making it easier for phone companies to offer video programming, bringing consumers a step closer to having more choices for their cable TV service. [...] In any case, for those who remember ABC Saturday morning Schoolhouse Rock, there are a few more steps involving the Senate, Conference committees and the President before a bill becomes law. Expect the lobbying to continue on all sides through the current election season. Whatever you think the country's laws should be, you still have time to make your views known to your representative.
2006.06.07 NANOG-NOTES Smart Network Data Services
(I'm starting to guess I'd finish sending these out faster if I stopped falling asleep on my keyboard so often... --Matt) 2006.06.07 Welcome to Wednesday morning http://www.nanog.org/ click on Evaluation Form Let us know how the M-W vs S-Tu format; next time will be S-Tu due to ARIN joint meeting, but need more feedback! Bill Woodcock, been on program committee And lightning talk people need to send their slides to Steve Feldman!! Elliot Gilliam, ISP community, notifications to Smart Network Data Services [slides are at http://www.nanog.org/mtg-0606/pdf/eliot-gillum.pdf AGENDA postmaster services SNDS problem goal today tomorrow motivation feedback/dialog questions/discussion Postmaster--starting point for any issues you have sending mail into Hotmail/MSN Live. It's like AOL skunkfeed, you can do junk mail reporting. Lets you see what bad stuff is coming from your domain. SenderID Site is at: http://postmaster.msn.com/snds/ Problem: bad stuff on the internet (spam, phishing, zombies, ID theft, DDoS) makes customers unhappy. Solution #1 -- try to stop it before it hits customers doesn't really *solve* the problem Solution #2 -- take what we learn, apply it upstream, get more bang for buck #2: #1 is too low ISP-centric efficiency solution #1, n ISPs have n-1 problems, total is O(n^2) n ISPs have 1 problem (themselves), total is O(n) reduces work of the overall system. Crux today people and ISPs are measured by how much BAD stuff they *receive* Not judged by what they send out. similar to healthcare industry no tight feedback loop to ISP behaviour nice quotes on slides http://www.circleid.com/posts/how_to_stop_spam 7 step program (like 12 step, but shorter) 1: recognize the problem: SNDS 2: believe that someone can help you : Me 3: Decide to do something : You 8: Make an inventory of those harmed : SNDS 9: Make amends to them :Tools 10: Continue to inventory : SNDS 12: Tell others about the program :You What is SNDS Website that offers free, instant access to MSN data on activity coming from your IP space data that correlates with internet evils informs ISP to enable local policy decisions Automated authorization mechanism uses WHOIS and rDNS users are people not companies A force multiplier attempt. You can do it on your own, no need to sign up your company officially as long as you're an rWHOIS/WHOIS contact. SNDS goal: provide info which allows ISPs to detect and fix any undesired activity. qualitative and quantitative data No ISP left behind stop problems upstream of the destination Bring total cost of remediation to absolute minimum keep service free Make internet a better place. We have data! Windows Live Mail/MSN Hotmail is a spam and spoofing target. 4 billion inbound mails/day 90/10 spam/ham by filtering technologies User reports on spam, fraud, etc. Inbound mail system slide--ugly to read, too dark. SNDS website slide shown. You can see daily aggregated traffic from your network; activity periods, IPs, commands and messages seen on port 25, samples of exchanges. Filter results on your mail rate at which users press this is junk on your mail. Trap counts for when IPs hit their junk filters. comments column is catch-all for anything else they might put in; like open proxies, when tested positive. export to CSV button, so you can feed the data in to your own systems if you want. Today's Scenario Illustrate magnitude and evidence of a problem. additional resources monitoring infrastructure SNDS Stats 2500 users mostly senders 67 million IPs 10-20% of inbound mail and complaints Output drops by 57% on /24+ when monitored by SNDS SNDS tomorrow Usability signup by ASN better support for upstream providers access transfer Utility programmatic access Data virus-infected emails phishing honeymonkey sample messages Expand the the coverage, try to hit more of the problems on the net. Provide sample messages, compelling evidence when facing customers This hasn't shipped yet, it's what he's hoping to have in a month or two. Tomorrow's Scenarios Lowered barrier to entry recurring cost ISP types end-user tier 1/2 monitoring, tier 2/3 directly attack more than just spam virus emails - infected PCs, outbound virus filters phishing/malware hosting - takedowns. Is asymmetric routing a sign of people trying to launch hidden abuses of the net? Looking to hit more issues, like spotting virus-laden messages; either infected, or an open relay. Hoping that automation speeds response. Safety Tools Stinger: http://vil.nai.com/vil/stinger Nessus: http://www.nessus.org/ [oy, read the list from his slide, it's long.] green items on the list are free, others are pay-for products. Pay-for isn't necessarily a bad thing if you get benefit! Safety tool breakdown from MSN on next slide. Motivation: Hypothesis: everyone benefits Customers: infected uses get fixed safer, cheaper, better internet experience ISPs solution #1 isn't solving
2006.06.07 NANOG-NOTES Issues with IPv6 multihoming
(hope the inclusion of URLs in the notes isn't making them all end up in people's spam folders... --Matt) 2006.06.07 Vince Fuller, from Cisco and Jason Schiller from UUnet [slides are at: http://www.nanog.org/mtg-0606/pdf/vince-fuller.pdf IPv6 issues routing and multihoming scalability with respect to routing issues. how we got where we are today define locator endpoint-id and their functions Explain why these concepts matter, why this separation is a good thing understand that v4 and v6 mingle these functions, and why it matters recognized exponential growth - late 1980s CLNS as IP replacement dec 1990 IETF OSI, TP4 over CLNS--edict handed down from IETF revolt against that, IP won ROAD group and the three trucks 1991-1992 running out of class-B network numbers explosive growth of default-free routing table eventual exhaustion of 32-bit address space two efforts -- short-term vs long-term More at the long and winding ROAD http://rms46.vlsm.org/1/42.html Supernetting and CIDR 1992-1993 Two efforts to fix it; CIDR, short term effort, long term effort became IPv6. IETF ipng solicitation RFC 1550 Dec 1993 Direction and technical criteria for ipng choice RFC1719 and RFC 1726, Dec 1994 proliferation of proposals TUBA == IP over CLNS NIMROD==how to deal with it from high level Lots of flaming back and forth, not much good technical work. choice eventually made on political choices, not technical merit. Things lost in shuffle...er compromise included: variable length addresses decoupling of transport and network-layer addresses clear separation of endpoint-id/locator (more later) routing aggregation/abstraction math is hard, let's go shopping -- solving the real issues was set aside, people focused on writing packet headers instead identity -- what's in a name think of an endpoint-id as the name of a device or protocol stack instance that is communicating over a network in the real world, this is like your name--who you are. a domain name is a human readable analogue endpoint-IDs: persistent--long term binding, stays around as long as machine is up ease of administrative assignment hierarchy along organization boundry (like DNS), not topology portable: stay the same no matter where in the hierarchy you are Globally unique! unlike human names. ^_^ Locators: where you are in the network think of source and dest addresses in routing and forwarding as locators real-world analogy is street addresses or phone numbers. typically some hierarchy (like address), or like historical phone number (before portability!) Desireable properties of locators: hierarchical assignment according to topology (isomorphic) dynamic, transparent renumbering without disruption unique when fully specified, but may be abstracted to reduce unwanted state variable length realworld--don't need to exact street address in Australia to fly there Possbly applied to traffic without end-system knowledge effectively like NAT, but doesn't beak end-to-end Why should I care? v4/v6 there are only addresses which serve as both endpoint-ids and locators this means they don't have the desirable properties of either: assignment to organizations is painful because use as locator constrains it to be topological exceptions to topology create additional global state renumbering is hard; DHCP isn't enough, sessions get distrupted, source-based filtering breaks, etc. Doesn't scale for large numbers of provider-indep or multihomed sites why should I care? currently, v6 is only a few hundred prefixes; won't be a problem until it really ccatches on, at which point it's too late. larger v6 space gives potentially more pain NAT is effectively id/locator split--what happens if NAT goes away in v6? scale of IP networks still very small compared to what it could grow to re-creating the routing swamp with ipv6 with longer addresses could be disasterous; not clear if internet could be saved in that case. Been ignored by IETF for 10+ years concepts have been known since 60s. Can v6 be fixed? And what is GSE, anyhow? Mike O'Dell proposed this in 1997 with 8+8/GSE keep v6 packet format, implement id/locator split http://ietfreport.isoc.org/idref/draft-ietf-ipngwg-gseaddr basic idea: separate 16-byte addrss into 8-byte EID and 8-byte routing goop/locator change TCP/UDP to only care about 8-bytes. allow routing system to muck with other 8 bytes in-flight achieves goal of EID/locator split while keeping most of IPv6, hopefully without requiring new database for EID-to-locator mapping Allows for scalable multi-homing Renumbering can be fast and painless/transparent to hosts. GSE issues problems with it--incompatible changes to TCP/UDP in 1997, no IPv6 installed base, easy to change; now, v6 deployed, is it too late to change? violation of end-to-end principle. perceived security weakness of trusting naked EID (steve bellovin says this is a non-issue) mapping of EID to EID+RG may add complexity to DNS depending on how implemented scalable TE not
The Cidr Report
This report has been generated at Fri Jun 9 21:48:37 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
02-06-06185948 122700
03-06-06186208 122508
04-06-06186215 122492
05-06-06186199 122459
06-06-06186279 122916
07-06-06186581 122644
08-06-06186580 122654
09-06-06186532 122618
AS Summary
22301 Number of ASes in routing system
9342 Number of ASes announcing only one prefix
1467 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91563008 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 09Jun06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 186522 1229616356134.1% All ASes
AS4323 1305 266 103979.6% TWTC - Time Warner Telecom,
Inc.
AS4134 1229 291 93876.3% CHINANET-BACKBONE
No.31,Jin-rong Street
AS18566 943 187 75680.2% COVAD - Covad Communications
Co.
AS721 1014 317 69768.7% DISA-ASNBLK - DoD Network
Information Center
AS22773 661 47 61492.9% CCINET-2 - Cox Communications
Inc.
AS6197 1009 479 53052.5% BATI-ATL - BellSouth Network
Solutions, Inc
AS7018 1467 944 52335.7% ATT-INTERNET4 - ATT WorldNet
Services
AS19916 563 65 49888.5% ASTRUM-0001 - OLM LLC
AS855550 64 48688.4% CANET-ASN-4 - Aliant Telecom
AS17488 514 42 47291.8% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS9498 572 149 42374.0% BBIL-AP BHARTI BT INTERNET
LTD.
AS3602 524 104 42080.2% AS3602-RTI - Rogers Telecom
Inc.
AS18101 414 28 38693.2% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS15270 429 50 37988.3% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS17676 486 110 37677.4% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS4755 872 515 35740.9% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS11492 622 268 35456.9% CABLEONE - CABLE ONE
AS4766 657 307 35053.3% KIXS-AS-KR Korea Telecom
AS22047 419 78 34181.4% VTR BANDA ANCHA S.A.
AS812370 30 34091.9% ROGERS-CABLE - Rogers Cable
Inc.
AS6467 382 52 33086.4% ESPIRECOMM - Xspedius
Communications Co.
AS16852 355 50 30585.9% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS8151 705 404 30142.7% Uninet S.A. de C.V.
AS19262 664 370 29444.3% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS14654 292 15 27794.9% WAYPORT - Wayport
AS16814 329 52 27784.2% NSS S.A.
AS3352 305 30 27590.2% TELEFONICA-DATA-ESPANA
Internet Access Network of
TDE
AS5668 528 253 27552.1% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS6198 509 241 26852.7% BATI-MIA - BellSouth Network
Solutions, Inc
AS19115 348 86 26275.3% CHARTER-LEBANON - Charter
BGP Update Report
BGP Update Report Interval: 26-May-06 -to- 08-Jun-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS912127269 2.3% 65.4 -- TTNET TTnet Autonomous System 2 - AS17974 17031 1.4% 49.2 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 3 - AS10139 16250 1.4% 53.5 -- MERIDIAN-PH-AP Meridian Telekoms 4 - AS13127 16050 1.4% 263.1 -- VERSATEL AS for the Trans-European Versatel IP Transport backbone 5 - AS11492 13075 1.1% 24.1 -- CABLEONE - CABLE ONE 6 - AS683011785 1.0% 72.7 -- UPC UPC Broadband 7 - AS17430 11322 1.0% 235.9 -- GWBN-CHENGDU Great Wall Broadband Network Service Co.,Ltd 8 - AS701810540 0.9% 24.9 -- ATT-INTERNET4 - ATT WorldNet Services 9 - AS201159608 0.8% 19.9 -- CHARTER-NET-HKY-NC - Charter Communications 10 - AS243269325 0.8% 211.9 -- TTT-AS-AP TTT Public Company Limited, Service Provider,Bangkok 11 - AS182318746 0.7% 69.4 -- EXATT-AS-AP Exatt Technologies Private Ltd. 12 - AS4755 8338 0.7% 10.2 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 13 - AS3462 7846 0.7% 182.5 -- HINET Data Communication Business Group 14 - AS7011 7094 0.6% 10.8 -- FRONTIER-AND-CITIZENS - Frontier Communications, Inc. 15 - AS5803 7030 0.6% 76.4 -- DDN-ASNBLK - DoD Network Information Center 16 - AS3475 6411 0.5% 278.7 -- LANT-AFLOAT - NCTAMS LANT DET HAMPTON ROADS 17 - AS2386 6400 0.5% 7.1 -- INS-AS - ATT Data Communications Services 18 - AS239186319 0.5% 48.2 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS 19 - AS175576207 0.5% 15.5 -- PKTELECOM-AS-AP Pakistan Telecom 20 - AS182076046 0.5% 31.7 -- BGBB-INDIA-AP Iqara Telecom India Pvt Ltd. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS368775008 0.4%2504.0 -- 2 - AS199825152 0.4%1288.0 -- TOWERSTREAM-PROV - Towerstream 3 - AS353792494 0.2%1247.0 -- EASYNET EASYNET s.c. 4 - AS210271233 0.1%1233.0 -- ASN-PARADORES PARADORES Autonomous System 5 - AS398631011 0.1%1011.0 -- CROSSNET Crossnet LLC 6 - AS34378 912 0.1% 912.0 -- RUG-AS Razguliay-UKRROS Group 7 - AS4678 3405 0.3% 851.2 -- FINE CANON NETWORK COMMUNICATIONS INC. 8 - AS36565 842 0.1% 842.0 -- COUNTY-OF-MONTGOMERY-PA - County of Montgomery 9 - AS256901367 0.1% 683.5 -- MAMSI - Mid Atlantic Medical Services Inc. 10 - AS167051340 0.1% 670.0 -- STORAGEAPPS - Storage Apps Inc. 11 - AS7013 1192 0.1% 596.0 -- NETSELECT - Health Sciences Libraries Consortium 12 - AS3944 586 0.1% 586.0 -- PARTAN-LAB - Partan Partan 13 - AS14548 580 0.1% 580.0 -- LISTEN-SF-1 - Listen.com 14 - AS144102879 0.2% 575.8 -- DALTON - MCM, Inc., DBA: [EMAIL PROTECTED] 15 - AS247754483 0.4% 560.4 -- AS24775 QinetiQ Ltd 16 - AS239171055 0.1% 527.5 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 17 - AS3043 3126 0.3% 521.0 -- AMPHIB-AS - Amphibian Media Corporation 18 - AS12408 496 0.0% 496.0 -- BIKENT-AS Bikent Ltd. Autonomous system 19 - AS24896 460 0.0% 460.0 -- UKRINTELL-AS IntellCOM Provider LIR, Kiev, Ukraine Northern Nowhere 20 - AS219441360 0.1% 453.3 -- DTSI-1 - Data Technology Services Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 152.74.0.0/16 3991 0.3% AS11340 -- Red Universitaria Nacional 2 - 81.212.149.0/243535 0.3% AS9121 -- TTNET TTnet Autonomous System 3 - 81.212.141.0/243503 0.2% AS9121 -- TTNET TTnet Autonomous System 4 - 61.0.0.0/8 3402 0.2% AS4678 -- FINE CANON NETWORK COMMUNICATIONS INC. 5 - 220.114.32.0/213158 0.2% AS17430 -- GWBN-CHENGDU Great Wall Broadband Network Service Co.,Ltd 6 - 211.162.88.0/213152 0.2% AS17430 -- GWBN-CHENGDU Great Wall Broadband Network Service Co.,Ltd 7 - 209.140.24.0/243101 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 8 - 195.175.82.0/232806 0.2% AS9121 -- TTNET TTnet Autonomous System 9 - 196.47.64.0/22 2556 0.2% AS36877 -- 10 - 81.212.125.0/242495 0.2% AS9121 -- TTNET TTnet Autonomous System 11 - 196.47.68.0/22 2452 0.2% AS36877 -- 12 - 81.212.124.0/242449 0.2% AS9121 -- TTNET TTnet Autonomous System 13 - 209.160.56.0/221975 0.1% AS14361 -- HOPONE-DCA - HopOne Internet Corporation 14 - 206.251.163.0/24 1703 0.1% AS4314
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
On Thu, 8 Jun 2006, Jeroen Massar wrote: snip In the end, the complete solution to most of these issues will be in the form of S-BGP (http://www.ir.bbn.com/sbgp/) and similar solutions. And the IETF is fortunately working on this: http://www.ietf.org/html.charters/sidr-charter.html It might take some time still, but it will come one day and then these issues are gone. At the moment you'll just have to trust your peers and try to get them to implement a sane policy on what kind of announcements they accept or I'd like to trust my peers not to allow botnets on their networks, and to trust the botnet guys not to just run 10 more. I'd like to trust different networks not to allow spoofing. It ain't happening. I am happy folks like at RIPE and the IETF are looking at solutions, but sBGP isn't a new idea, and well, how LONG have we been waiting for DNS-SEC now? Obviously what we all (not me or you) are doing is not working. What worked for us a few years ago, now doesn't work either. There needs to be a strong distinction between what works operationally for individual networks and for the whole Internet. Gadi.
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
On Thu, 8 Jun 2006, Todd Underwood wrote: 8.0.0.0/8 8.0.0.0/9 Interesting, apparently ISP's are not the only ones using BGP tricks. 8.2.64.0/23 8.2.144.0/22 8.3.0.0/23 8.3.12.0/24 8.3.13.0/24 8.3.15.0/24 8.3.33.0/24 8.3.37.0/24 8.3.46.0/24 8.3.208.0/24 8.4.86.0/24 8.4.96.0/20 8.4.113.0/24 8.4.224.0/24 8.5.192.0/22 8.6.89.0/24 8.6.220.0/22 8.6.240.0/24 8.6.241.0/24 8.6.244.0/23 8.7.49.0/24 8.7.81.0/24 8.7.83.0/24 8.7.86.0/23 8.7.96.0/21 8.7.176.0/23 8.7.216.0/24 8.8.9.0/24 8.8.176.0/24 8.8.178.0/24 8.8.192.0/23 8.8.196.0/22 8.8.200.0/23 8.8.202.0/23 8.9.3.0/24 8.9.4.0/24 8.9.5.0/24 8.9.6.0/24 8.9.10.0/24 8.9.36.0/24 8.9.37.0/24 8.9.192.0/24 8.9.193.0/24 8.10.2.0/24 8.10.50.0/24 8.10.114.0/24 8.10.115.0/24 8.10.116.0/23 8.10.119.0/24 8.10.128.0/24 8.10.208.0/24 8.10.241.0/24 8.11.192.0/24 8.11.252.0/24 8.11.253.0/24 8.11.254.0/23 8.14.128.0/23 8.14.176.0/23 8.15.3.0/24 8.128.0.0/9 9.4.0.0/16 11.11.11.0/24 12.0.0.0/8 12.0.0.0/9 12.0.18.0/24 12.0.19.0/24 12.0.20.0/23 12.0.22.0/24 12.0.28.0/24 12.0.29.0/24 12.0.43.0/24 12.0.48.0/20 12.0.102.0/24 12.0.153.0/24 12.0.170.0/24 12.0.176.0/24 12.0.232.0/24 12.0.239.0/24 12.0.252.0/23 12.1.54.0/24 12.1.56.0/24 12.1.57.0/24 12.1.58.0/24 12.1.59.0/24 12.1.96.0/24 12.1.211.0/24 12.1.216.0/24 12.1.225.0/24 12.1.230.0/24 12.1.235.0/24 12.2.6.0/23 12.2.22.0/24 12.2.35.0/24 12.2.46.0/24 12.2.49.0/24 12.2.59.0/24 12.2.60.0/22 12.2.88.0/22 12.2.115.0/24 12.2.120.0/24 12.2.124.0/24 12.2.126.0/24 12.2.127.0/24 12.2.142.0/24 12.2.169.0/24 12.2.210.0/24 12.3.4.0/23 12.3.7.0/24 12.3.19.0/24 12.3.33.0/24 12.3.54.0/24 12.3.57.0/24 12.3.59.0/24 12.3.70.0/24 12.3.80.0/22 12.3.91.0/24 12.3.119.0/24 12.3.147.0/24 12.3.164.0/24 12.3.165.0/24 12.3.167.0/24 12.3.170.0/24 12.3.212.0/24 12.4.26.0/24 12.4.27.0/24 12.4.50.0/23 12.4.50.0/24 12.4.51.0/24 12.4.52.0/23 12.4.52.0/24 12.4.53.0/24 12.4.96.0/23 12.4.96.0/24 12.4.97.0/24 12.4.100.0/24 12.4.121.0/24 12.4.124.0/24 12.4.193.0/24 12.4.194.0/24 12.4.196.0/22 12.4.199.0/24 12.4.211.0/24 12.4.225.0/24 12.5.1.0/24 12.5.48.0/21 12.5.48.0/24 12.5.49.0/24 12.5.50.0/23 12.5.52.0/24 12.5.53.0/24 12.5.54.0/23 12.5.56.0/22 12.5.56.0/23 12.5.58.0/24 12.5.59.0/24 12.5.60.0/22 12.5.67.0/24 12.5.96.0/24 12.5.103.0/24 12.5.122.0/23 12.5.127.0/24 12.5.128.0/24 12.5.129.0/24 12.5.130.0/24 12.5.131.0/24 12.5.134.0/24 12.5.136.0/24 12.5.144.0/24 12.5.162.0/24 12.5.173.0/24 12.5.186.0/23 12.5.207.0/24 12.5.226.0/24 12.5.238.0/24 12.5.245.0/24 12.6.4.0/24 12.6.5.0/24 12.6.9.0/24 12.6.21.0/24 12.6.42.0/23 12.6.89.0/24 12.6.94.0/24 12.6.95.0/24 12.6.129.0/24 12.6.136.0/24 12.6.152.0/23 12.6.193.0/24 12.6.195.0/24 12.6.200.0/24 12.6.201.0/24 12.6.206.0/24 12.6.208.0/20 12.6.245.0/24 12.6.247.0/24 12.7.5.0/24 12.7.7.0/24 12.7.51.0/24 12.7.134.0/24 12.7.135.0/24 12.7.172.0/24 12.8.2.0/23 12.8.7.0/24 12.8.56.0/24 12.8.97.0/24 12.8.129.0/24 12.8.167.0/24 12.8.177.0/24 12.8.184.0/24 12.8.188.0/24 12.8.197.0/24 12.8.198.0/24 12.8.199.0/24 12.9.10.0/24 12.9.29.0/24 12.9.124.0/24 12.9.136.0/24 12.9.138.0/24 12.9.139.0/24 12.9.144.0/24 12.9.194.0/23 12.9.196.0/22 12.9.206.0/24 12.9.238.0/24 12.9.239.0/24 12.9.241.0/24 12.9.245.0/24 12.9.249.0/24 12.10.20.0/23 12.10.44.0/23 12.10.90.0/24 12.10.91.0/24 12.10.115.0/24 12.10.132.0/24 12.10.133.0/24 12.10.150.0/24 12.10.189.0/24 12.10.217.0/24 12.10.219.0/24 12.10.230.0/23 12.10.253.0/24 12.11.0.0/18 12.11.88.0/23 12.11.130.0/24 12.11.131.0/24 12.11.148.0/24 12.11.149.0/24 12.11.150.0/24 12.11.151.0/24 12.11.152.0/24 12.11.171.0/24 12.11.183.0/24 12.12.0.0/20 12.12.16.0/20 12.12.32.0/20 12.12.48.0/20 12.12.64.0/20 12.12.80.0/20 12.12.96.0/20 12.12.112.0/20 12.12.192.0/18 12.12.208.0/22 12.12.232.0/21 12.13.62.0/24 12.13.74.0/24 12.13.112.0/24 12.13.116.0/22 12.13.141.0/24 12.13.164.0/23 12.13.211.0/24 12.14.2.0/24 12.14.36.0/24 12.14.38.0/24 12.14.41.0/24 12.14.80.0/23 12.14.170.0/24 12.14.172.0/23 12.14.232.0/23 12.14.237.0/24 12.14.238.0/23 12.15.7.0/24 12.15.28.0/24 12.15.40.0/24 12.15.41.0/24 12.15.42.0/24 12.15.43.0/24 12.15.46.0/24 12.15.47.0/24 12.15.58.0/24 12.15.72.0/24 12.15.146.0/24 12.15.160.0/24 12.15.168.0/23 12.15.168.0/24 12.15.169.0/24 12.15.205.0/24 12.15.224.0/24 12.16.12.0/24 12.16.40.0/24 12.16.41.0/24 12.16.44.0/22 12.16.59.0/24 12.16.157.0/24 12.16.164.0/24 12.16.165.0/24 12.17.14.0/24 12.17.15.0/24 12.17.22.0/24 12.17.30.0/24 12.17.39.0/24 12.17.64.0/22 12.17.140.0/23 12.17.142.0/23 12.17.158.0/23 12.17.162.0/24 12.17.196.0/23 12.17.199.0/24 12.17.202.0/23 12.17.214.0/23 12.17.226.0/24 12.17.227.0/24 12.18.25.0/24 12.18.28.0/23 12.18.36.0/24 12.18.49.0/24 12.18.76.0/24 12.18.80.0/23 12.18.116.0/24 12.18.155.0/24 12.18.158.0/23 12.18.160.0/22 12.18.170.0/23 12.18.177.0/24
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
On Thu, 8 Jun 2006, Ariel Biener wrote: On Wednesday 07 June 2006 21:58, Gadi Evron wrote: Gadi, There's no real need for such drastic measures over this. The Internet is no longer a safe place, meaning that the sane NSPs/ISPs sanitize their networks rather than trust someone else to do it for them, or trust someone else to never make mistakes. As such, the diligent network operators and their networks will not even be affected by this. Indeed, the Internet is not a safe place. It always surprises me when people think otherwise. Regardles, it is a place where someone else's mistake can cost YOU. Also, there is a sentence that I like, I learned it from a proffessor here, but it is well known: Never attribute to malice something that can be easily explained by sheer stupidity. One of the most true I ever heard, and indeed, stupidity does hurt us. Does it matter if it is malicious by /intent/? best, --Ariel -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP: http://www.tau.ac.il/~ariel/pgp.html
Re: a fun hijack: 1/8, 2/8, 3/8, 4/8, 5/8, 7/8, 8/8, 12/8 briefly announced by AS 23520 (today)
I am happy folks like at RIPE and the IETF are looking at solutions, but sBGP isn't a new idea, and well, how LONG have we been waiting for DNS-SEC now? I just read a paper yesterday from '97 that suggested complete registries would be available within the next couple of years ;)
who runs http://www.networkthinktank.com/ ?
the web site and whois info are just about as completely anonymous as can be.
Re: who runs http://www.networkthinktank.com/ ?
On Fri, Jun 09, 2006 at 08:01:37PM +0200, William Waites wrote: Maybe there's someone in Hannover that knows who they are... Their telephone number is just an anonymous mailbox... Very mysterious indeed... FWIW, the WHOIS location is residential. Doesn't provide much information, nor does it imply anything... http://maps.google.com/maps?f=qhl=enq=1413+Gesna+Drive,+Hanover,+MD+21076ll=39.142443,-76.700792spn=0.011949,0.026779t=hom=1 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 10 Jun, 2006 Analysis Summary BGP routing table entries examined: 190168 Prefixes after maximum aggregation: 104652 Unique aggregates announced to Internet: 93198 Total ASes present in the Internet Routing Table: 22396 Origin-only ASes present in the Internet Routing Table: 19479 Origin ASes announcing only one prefix:9338 Transit ASes present in the Internet Routing Table:2917 Transit-only ASes present in the Internet Routing Table: 60 Average AS path length visible in the Internet Routing Table: 3.5 Max AS path length visible: 24 Max AS path prepend of ASN (34527) 16 Prefixes from unregistered ASNs in the Routing Table: 7 Unregistered ASNs in the Routing Table: 5 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 1543668456 Equivalent to 92 /8s, 2 /16s and 130 /24s Percentage of available address space announced: 41.6 Percentage of allocated address space announced: 60.2 Percentage of available address space allocated: 69.1 Total number of prefixes smaller than registry allocations: 94114 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:40710 Total APNIC prefixes after maximum aggregation: 16880 Prefixes being announced from the APNIC address blocks: 38424 Unique aggregates announced from the APNIC address blocks:18579 APNIC Region origin ASes present in the Internet Routing Table:2598 APNIC Region origin ASes announcing only one prefix:747 APNIC Region transit ASes present in the Internet Routing Table:398 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 227781728 Equivalent to 13 /8s, 147 /16s and 172 /24s Percentage of available APNIC address space announced: 71.2 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 97710 Total ARIN prefixes after maximum aggregation:57771 Prefixes being announced from the ARIN address blocks:71728 Unique aggregates announced from the ARIN address blocks: 26653 ARIN Region origin ASes present in the Internet Routing Table:10759 ARIN Region origin ASes announcing only one prefix:4051 ARIN Region transit ASes present in the Internet Routing Table: 993 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 18 Number of ARIN addresses announced to Internet: 293558272 Equivalent to 17 /8s, 127 /16s and 88 /24s Percentage of available ARIN address space announced: 76.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 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 38053 Total RIPE prefixes after maximum aggregation:25405 Prefixes being announced from the RIPE address blocks:35075 Unique aggregates announced from the RIPE address blocks: 23703 RIPE Region origin ASes present in the Internet Routing Table: 8129 RIPE Region origin ASes announcing only one prefix:4266 RIPE Region transit ASes present in the Internet Routing Table:1342 Average RIPE Region AS path
Re: who runs http://www.networkthinktank.com/ ?
It's me. I wouldn't say anonymous, but not a whole lot of personal information out there. For the most part the info is legit. Nothing mysterious going on, just an attempt to keep my name out of spammer databases. Was there an issue? The site hasn't been updated in a while, I had a motherboard meltdown and haven't had a chance to swap it out. I haven't made it more public because I am working out kinks. Kind of a hobby. jas Paul Vixie wrote: the web site and whois info are just about as completely anonymous as can be.
earthlink.net mail admin contact?
Would somebody from earthlink.net mail ops please contact me off-list? thx -mark -- Mark Jeftovic [EMAIL PROTECTED] Founder President, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(866) 273-2892
Extreme Networks BD 6808 errors -- help to interpret.
I've recently stumbled over an error in the logs of one of my Black Diamond 6808's. Due to redundant MSMs this hasn't had any practical effect yet, but I have just initiated a ticket on the matter. Parallell to that I thought I'd take the oportunity to ask if anyone here has any more insight on what this means, what is happening and possibly what could cause it. Is it simply a matter of a broken MSM, or what could trigger something like this? Replies onlist or offlist appreciated, whatever you prefer. Thank you in advance, SYST: The signature of NMC0 is disappered. Reset the NMC10 SYST: Removed MSM-B base module SYST: slave MSM communications pipe is closed SYST: MSM-B is inserted. SYST: Start initializing MSM-B base module SYST: MSM-B SN = 701021-17 0235F-70778 SYST: slave MSM communications pipe is open SYST: Done initializing MSM-B base module SYST: MSM-B HW_AN=0 SW_AN=0 DECODE=0 INTSTAT=0 ANRCVCFG=0 CTRL=1000 SYST: slot 3 HW_AN=a1 SW_AN=13 DECODE=1b INTSTAT=bf8 ANRCVCFG=41a0 CTRL=ff3ffc00 SYST: MSM-B=[701021-17 0235F-70778 ] SYST: slot 3=[701026-15 0315F-80358 ] SYST: backplane=[701000-08 0230h00123 ] SYST: [2] Connection between MSM-B mother board port 2 and I/O module 3 port 1 broke, fix immediately SYST: MSM-B HW_AN=0 SW_AN=0 DECODE=0 INTSTAT=0 ANRCVCFG=0 CTRL=1000 SYST: slot 4 HW_AN=a1 SW_AN=13 DECODE=84 INTSTAT=bf8 ANRCVCFG=41a0 CTRL=ff3ffc00 SYST: MSM-B=[701021-17 0235F-70778 ] SYST: slot 4=[701024-21 0238F-70372 ] SYST: backplane=[701000-08 0230h00123 ] SYST: [2] Connection between MSM-B mother board port 3 and I/O module 4 port 1 broke, fix immediately SYST: MSM-B HW_AN=0 SW_AN=0 DECODE=0 INTSTAT=0 ANRCVCFG=0 CTRL=1000 SYST: slot 6 HW_AN=a1 SW_AN=13 DECODE=1b INTSTAT=bf8 ANRCVCFG=41a0 CTRL=ff3ffc00 SYST: MSM-B=[701021-17 0235F-70778 ] SYST: slot 6=[701026-15 0315F-80383 ] SYST: backplane=[701000-08 0230h00123 ] SYST: [2] Connection between MSM-B mother board port 5 and I/O module 6 port 1 broke, fix immediately KERN: Secondary Mgmt port initialized KERN: Secondary Mgmt port enabled SYST: The signature of NMC0 is disappered. Reset the NMC10 SYST: Removed MSM-B base module SYST: slave MSM communications pipe is closed SYST: MSM-B is inserted. SYST: Start initializing MSM-B base module SYST: MSM-B SN = 701021-17 0235F-70778 SYST: slave MSM communications pipe is open SYST: Done initializing MSM-B base module KERN: Secondary Mgmt port initialized KERN: Secondary Mgmt port enabled SYST: The signature of NMC0 is disappered. Reset the NMC10 SYST: Removed MSM-B base module SYST: slave MSM communications pipe is closed SYST: MSM-B is inserted. SYST: Start initializing MSM-B base module SYST: MSM-B SN = 701021-17 0235F-70778 SYST: slave MSM communications pipe is open SYST: Done initializing MSM-B base module KERN: Secondary Mgmt port initialized KERN: Secondary Mgmt port enabled -- /mattias ahnberg (AS20514).
2006.06.07 NANOG-NOTES Lightning talk notes
(I think these were the toughest to take notes on, since they went by so fast; took the most cleaning up afterwards. But they were also the best talks of the 3 days. I wish we could have flipped, and taken more time on Tuesday for them so we really could have dug in and asked the questions we were itching to ask. ^_^; --Matt) 2006.06.07 Lightning talks Marty Hannigan, Renesys: [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/1-hannigan.pdf Critical infrastructure, root server location analysis Where to stick your servers. :) he took some public info out there on root-servers.org talked to some people, extrapolated from larger set of data. operator demographics. in US: 3 corp a, c, j 2 edu b and d 1 mil g 2 research e/h 3 nonprofit f, i, l autonomica is responsible for l, but hosts some instances on a CDN; CDN is a US formed entity in EU: 1 non profit k asia/japan: 1 nonprofit m 92% of system operated in US, 8% non-us; 5% margin of error +-. US entity type non-us 8% us corp 39% us mil 23% us edu 15% us nonprofit 15% where? in 54 countries all religions all methods of governance politically: 79% are democratic governments 21% in other forms of government global diversification for security and performance instances spread across continents different networks different proceedures different software different hardwware different weaknesses weaknesses become strength, since they are diverse; no one weakness knocks out all servers. little less open to insider malfeasance Global distribution NA 38% EU 35% Asia 12% AUs 8% east EU 3% LA 2% Africa 2% ANT 0% getting reasonable coverage in the world situating a root server relationship 101 who you know ICANN, operator, IX, and RIR relationships regulators how you spin it national pride performance and security betterment of user experience Threats no different from anyone else direct attacks proxy attacks botnets easy money miscreants masking other activities Not sure what motivations to attack root servers; can't extort money from nonprofits let's attack a root server target $-root location; eu hosting facility multi-post cabinet config with cabling and power under floor unlocked cabinet, single factor facility entry physical attack open cabinet door access to power hijack attempt advertise a route return bad answers network attack spoof source random host queries packet floods summary: root system is less likely to be subject to insider attack or weakness but can be attacked by layer 3 there is likely good resarch data coming across those interfaces trend towards a collapsed root system, where root and TLD share same hardware or networks should be more closely examined. slides will be up soon, talk to him in the hallway NEXT, Anton Kapela Network RTTs [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/2-kapela.pdf I'm pinging 10: high rate active probes we're pinging stuff really quickly adjusted host kern.hz to 1000 select() gets pretty accurate +-1ms emmission accuracy stuff is responding Interesting 0.001% of data relates to end-to-end queuing what has been sampled? some cisco 7513s IOS 12.3 mainline linux 2.4.20 freebsd 4.8 NT4 sp6 various end-to-end paths on u-wisc network raw data isn't terrible interesting. in adaptive link layer protocols, see rate shifting manifested in RTT wireless, HPNA/HCNA, powerline ethernet 10,30,60,90 second peaks fourier transforms, wavelet transforms, frequency domain 1000 seconds at 10ms intervals break into composite, aggregate graph at top, 0-50hz span on x axis, y axis is contribution summary of entire graph. bottom right graph is rough 200 samples of a range from 0-5hz, 100pps, deduce delay at half that sampling rate. delay is not a simple boring thing; has scheduler delays, path dynamics not visible before to see queue depths. shark fins showed up; congestion events do occur, are quite measurable. when links are hot, queues are obvious, esp. on highly multiplexed links. bottom left, cubic resonance, several tens of thousands of multiplexed flows hitting odd resonance. pinging windows machine, composite spectral fingerprint; 10,20,25,30 spikes Linux fewer spikes freebsd low and flat IOS is 10, 20, 30 and grass of 1hz spacing below 10hz. win32 delay spectrum also has 1hz fuzz below 10hz. Sampled RTT and performed signal analysis of it; now what? is network time continuous? is round trip time discreet or continous? no changes in revealed as you go down lower is delay a signal' anyway what's with the 0 hz DC component in the FT output? could this be used for fingerprinting? yes, could be like next nmap. packet-level fingerprinting is trivial to fake; but IP stack scheduler behaviour doesn't change so easily. NEXT: Mikael Abrahamsson Affect on traffic from the TPB bust with Kurtis Lindqvist [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/3-abrahamsson.pdf Bittorrent background p2p protocol for filesharing. text
Re: 2006.06.07 NANOG-NOTES Lightning talk notes
thanks for taking (and posting) notes matt! [snip] NEXT: Rick Wesson, Support Intelligence [hehe] Understanding abuse, aggregate it, push it back to operators, let them know what they're doing to other people. [no slides, he does a live presentation of his tool] How do I believe you? realtime data visualization, Feb 8th, 2006 visualization. 130 different data sources, 90% passive; 10,000 domain aggregated spam trap, very evil SMTP that filters and bans IP for some time. 1.2million events per day aggregated, about 700,000 unique IPs for the global internet. BGP peers, aggregate based on announcements made. Put into tool so network operators can visualize their prefixes, drill in, and see abuse each prefix generates. hover over point, it shows the operator, IP address, and what the problem was (spam, insecure web server, etc) This shows problem areas that need to be addressed! disseminate this information, help ISPs clean up their networks. Can also pass along information of abuse that has happened to you. If you have an AS, he can tell you what your AS has been used for, abused for, owned, etc. email him for more info...except he didn't list his email info. ^_^; my bad. [EMAIL PROTECTED] or [EMAIL PROTECTED] works. always happy to help. -rick
2006.06.07 NANOG-NOTES Anycast benefits for k root server
Break ends at 11:40, PGP signing will take place, and don't forget to fill out servers. ANYCAST fun for the final sessions. Lorenzo Colitti, RIPE NCC [slides are at: http://www.nanog.org/mtg-0606/pdf/lorenzo-colitti.pdf Agenda: introduction latency client-side server-side Benefit of individual nodes Stability Routing issues Why anycast? root server anycast widely deployed c, f, i j, k, m at least reasons for anycasting provide resiliency: eg contain DOS attacks spread server and network load increase performance but is it effective? measure latency ideally for every given client, BGP should chose node with lowest RTT. does it? from every client, measure RTTs to anycast IP address service interfaces of global nodes (not anycasted) for every client, compare K RTT to RTT of closest global node a = RTTk/min(RTTi) if 1, BGP is picking right node if 1, BGP picks the wrong node if 1, seeing local node. Latency with TTM: methodology DNS queries from ~100 TTM test boxes dig hostname.bind see which host answers extract RTT take min of 5 queries check paths to service interfaces; is it same as prod IP according to RIS, mostly 'yes' TTM probe locations, mostly in europe Latency with TTM: results (5 nodes) most values are close to one; generally BGP doing pretty good job. from 2 nodes to 5 nodes (2 nodes, April 2005) (5 nodes, April 2006) mostly same results, clustered around one, whether 2 or 5 nodes. consistency of 'a' over time average of that over time. TT103 is outlier calculated over time, threw out that one outlier. results are pretty consistent. average is little higher than one, mostly consistent over time measuring from servers TTM latency measurements not optimal locations biased towards europe limited number of probes (~100) don't reflect k client distribution how to fix? ping clients from servers much larger dataset methodology process packet traces on k global nodes extract list of client IP addreses ping all addresses from all global nodes plot distribution of 'a' 6 hours of data 246,769,005 queries 845,328 unique IP addresses CDF of 'a' seen from servers results not as good as seen by TTM only 50% of clients have a = 1 about 10% are 4x slower/farther. probably due to TTM clustering in europe latency conclusions 5 node result vs 2 node, comparable, at least in TTM non-TTM results not so rosy. How many nodes are needed--is 5 enough? evaluate existing instances how to measure benefit of an instance? Assume optimal instance selection that is, every client sees closest instance this is upper benefit of benefit consistent to see if we've reached diminishing returns for every client, see how much its performance if the chosen node didn't exist. B is loss factor, how much a client would suffer if an instance were knocked out B = RTTknockout/RTT... Graph for LINX; 90% of clients wouldn't see an impact if it went away; 10% would see a worsening. geographic distribution pretty wide AMS-IX about 20% would suffer performance degregation; busiest two nodes, see a lot of clients, important to k deployment. If they plot it for both LINX and AMSIX together, about 65% wouldn't be affected, most of others would see 4x, 10% would be 7x worse. So taken together, the *two* nodes are important. Tokyo; best node for few clients; but those served, BADLY served by others; about 10% who would go more than 7x if it went way, those clients mostly Asia. Miami node at NOTA, moderate benefit for some clients, US and southAm would be badly served by europe or Tokyo. Delhi node is mostly ineffective, most would be served better by other nodes. Condense the graph into one number to get a value for effectiveness of each node. weighted average of B for each client. if benefit value is 1, node doesn't provide any benefit at all. larger numbers show higher benefits. Europe, when taken together, high benefit, as is Tokyo; Miami node not so effective, and Delhi is nearly ineffective. Does anycast provide any value then? knock out all except LINX; dark red curve (pre 1997) 10% wouldn't notice, 85% would get worse, benefit value is 18.8, so anycast does bring value. Stability the more routes competing in BGP with more nodes doesn't matter for single packet UDP exchanges does matter for TCP Look at node switches that occur. collect packet dumps on each node. extract all 53/UDP traffic k nodes only NTP synchronized if IP shows up on two nodes, log a switch. 5 nodes, april 2006, 0.06% saw switches 2830 switchers out of 845,328, 0.33% switchers no big issue with instance switchers. Routing issues k-root structure 5 global nodes (prepended) linkx, amsix, tokyo, mia, del different prepending values no-export causing reachability TT103 has value of 200, the graph axis is cut. tt103 is in Yokohama; Tokyo is 2ms away; but the query goes to Delhi through Tokyo to LA. 416ms vs 2, so value is 208. Thanks to Matsuzaki and Randy Bush, got BGP paths from AS2497 bad interaction of different prepending lengths need
2006.06.07 NANOG-NOTES TCP Anycast--don't spread the FUD!
(this was one of the coolest talks from the three days, actually, and has gotten me *really* jazzed about some cool stuff we can do internally. Huge props to Matt, Barrett, and Todd for putting this together!! --Matt) 2006.06.07 TCP anycast, Matt Levine, Barrett Lyon with thanks to Todd Underwood TCP anycast, don't believe the FUD Todd Underwood is in Chicago Barrett Lyon starts off. [slides may eventually be at: http://www.nanog.org/mtg-0606/pdf/tcp-anycast.pdf IPv4 anycast from a network perspective, nothing special just another route with multiple next-hops services exist on each next-hop, and respond from the anycast IP address. It's the packets, stupid perceived problem: TCP and anycast don't play together for long-lived flows. eg, high-def porn downloads [do porn streams need to last more than 2 minutes?] some claim it exists, and works... yes, been in production for years now. Anycast at CacheFly deployed in 2002 prefix announced on 3 continents 3 POPs in US 5 common carriers (transit) + peering be sensible to who you peer with Effective BGP communities from upstreams is key keep traffic where you want it. Proxy Anycast proxy traffic is easy to anycast! move HTTP traffic through proxy servers. customers are isolated on a VIP/virtual address, which happens to exist in every datacenter. Virtual address lives over common carriers allowing even distribution of traffic state is accomplished with custom hardware to keep state information synchronized across proxies. Node geography anycast nodes that do not keep state must be geographically separated Coasts and countries work really well for keeping route instability largely isolated. Nodes that are near by could possibly require state between them if local routes are unstable. IP utilization Anycast is wasteful people use /24's as their service blocks; use 1 /32 out of a whole /24. Really? How much IP space do you need to advertise from 4 sites via unicast? Carriers and Peering for content players, having even peering and carriers is key. you may cause EU eyeballs to go to CA if you're not careful with where you peer with people. having an EU centric transit provider in the US without having the same routes in EU could cause EU traffic to home in the US Use quality global providers to keep traffic balanced. When peering... keep in mind a peer may isolate traffic to a specific anycast node Try to peer with networks where it makes sense; don't advertise your anycast to them where they don't have eyeballs! Try to make sure your peers and transit providers know your communities and what you're trying to do, and make sure you understand their communities well! Benefits of Anycast. for content players moving traffic without major impact or DNS lag provides buffers for major failures allows for simplistic traffic management, with a major (potential) performance upside. it's BGP you don't control, though, so not much you can do to adjust inbound wins. HTTP has significant cost to using DNS to try to shift traffic around; six or more DNS lookups to acquire content; anycast trims those DNS lookups down significantly! Ability to interface tools to traffic management. No TTL issues! Data, May 9, 2006 Renesys: monitored changes in atomic-aggregator for a CacheFly anycast prefix AS path changes and pop changes Keynote: monitored availability/performance of 30k file Revision3: monitored behavour of longlived downloads of DiggNation videocast--over 7TB transferred. Renesys data: 130BGP updates for may 9th; low volume day stable prefixes 34 distinct POP changes based on atomic aggregator property on prefixes 130 updates is considered a stable prefix. SJC issue: thirty-five minute window, 0700 to 0735 UTC, saw: 98 updates, 20 actual pop changes based on atomic aggregator changes, all from one san jose provider, fail from SJC to CHI back to SJC unable to correlate these shifts with any traffic changes; mostly likely we don't have a big enough sample size. possibly just not a lot of people using those routes. BGP seems stable--what about TCP flows? AVG time between SJC and CHI and back again was about 20 seconds; very quick on the trigger to go back to SJC; would break all TCP sessions happening at the time. For the most part, TCP seems stable. Keynote: 30k download from 31 locations every 5 minutes, or average of 1 poll per 9.6 seconds compared against 'Keynote Business 40' data collected on May 9, 2006 represents short-lived TCP flows, though. Orange line is Keynote business 40 pegged 100% availability load time was lower than the business 40. (0.2s vs 0.7s for business 40) Revsion 3 data monitored IPTV downloads for 24 hours (thanks, jay!) span port; analyzed packet captures look for new TCP sessions not beginning with SYN compare that against global active connection table. looked for sessions that appeared out of nowhere. Long-lived data 683,204 TCP sessions. anything less than 10 minutes thrown out 23,795 sessions lasted
2006.06.07 NANOG-NOTES DNSSEC bootstrapping with DLV
(last notes from NANOG37, yay! I definitely fell further behind this time around than in Dallas. Unfortunately, I don't think I'll be allowed to go to St. Louis, so I probably won't be able to provide notes for NANOG38. --Matt) 2006.06.07 Deploying DNSSEC--bootstrap yourself Joao Damas, ISC [notes are at http://www.nanog.org/mtg-0606/pdf/joao-damas.pdf DNSSEC status standard is complete and usable some minor nits with regards to some privacy issues 2 implementations: NSD, BIND at least one DNSSEC aware resolver (BIND 9.3.2 and later) Really, you just need some data. DNSSEC follows a hierarchical model for signatures. sign the root zone get root zone to delegation sign TLDs get TLDs to delegation-sign SLDs, etc. Today, the root zone remains unsigned likely will be this way for some time Very few TLDs have signed their zones and offer delegation signatures .se, .ru, .org DNSSEC provides for local trust anchors you can use trust-anchors clause in BIND problem: if you have too many, it becomes a nightmare to maintain, so it doesn't get used. very manual process Enter DLV, domain lookaside validation it's an implementation feature, not a change to the protocol; matter of local policy enables access to a remote, signed repository of trust anchors, via the DNS implemented in BINDs resolver so far more to follow? unfortunately, requires you to trust remote repository DLV lookup a DLV enabled resolver will try to find a secure entry point using regular DNSSEC; only if it fails is DLV used, if it is configured. [picture of DLV lookup chain] On resolver (BIND) add to named.conf in the options section //DNSSEC conifg dnnssec-enable yes dnssec-lookaside . trust-anchor dlv.isc.org.; get the key from ISC's web: http://www.isc.org/ops/dlv ISC is operating a DLV registry free of charge for anone who wants to secure their DNS Likely some closed orgs will use their own (eg mil) have a look, start using it! Any questions? Q: Mark Kosters, Verisign: Any plans to configure DLV registries per TLD? A: BIND code only allows for one right now. Q: Would be good to allow it to be configured per TLD. Q: Randy Bush, IIJ: some feeling or understanding how IANA, root would validate keys/zones it has keys for; don't understand how ISC proposes to validate keys it would be storing. He suggests they publish the security policy. A: In case of registrars proxying keys; they trust registrar. Otherwise, it's like PGP; show me your face, show me your key. Q: Paul vixie, ISC, following up on Mark Kosters; you can only have one DLV for any point in the namespace; you can specify a different one for a TLD than root; that allows a TLD DLV to be paranoid, like .mil. who doesn't want to trust anyone else with key information. If every TLD wanted to do that, they would find high levels of cut-and-paste fatigue, so ISC will operate a root level DLV server as well. Q: Rick Wesson, runs Alice's Registry, a small registrar. he's considering doing this, he can help DNS holders register their keys if people are interested, and will help get them into the DLV tree. Q: Sam Wiler?, Sparta: concerns from Randy about how ISC will authenticate the entries. Registrars should consider running their own DLV servers, as they have the relationship with the domain holder. Code? Apparently you don't need code... NANOG 37, ending slides. 425 attendees, 118 first timers lots of countries most USA, 11 canada, scattered others. ISP, then NSP, then other categories. top 3 companies represented: Cisco, Juniper, Equinix HUGE thanks to Rodney Joffe and Neustar for puling off a miracle to make this happen at the last minute! Thanks to sponsors, bear, gear, other. Susan R Harris, many thanks to her for all the work she has put in over the years and to make this happen! Also huge thanks to all the other people at Merit And we'll see you in St. Luis, Oct 8-10th, joint meeting with ARIN, things set in stone. Network will go down in 30 minutes or so--pack up and go home! :) I think that was the fastest closing I've seen at a NANOG yet. ^_^;;
Re: 2006.06.06 NANOG-NOTES MPLS TE tutorial
On 6/8/06, Matthew Petach [EMAIL PROTECTED] wrote: (still here, just been really busy at work today; will try to finish sending the notes out tonight. --Matt) 2006.06.06 MPLS TE tutorial Pete Templin, Nextlink Gyah!! Huge apologies to Pete, who really works for Texlink. I used to work at Nextlink, and in taking notes, my fingers went down their old familiar path a bit too easily. Again, Pete Templin works at Texlink, not Nextlink--apologies for that gaffe, Pete. ^_^;; Matt
Re: 2006.06.07 NANOG-NOTES Smart Network Data Services
On 6/9/06, Simon Waters [EMAIL PROTECTED] wrote: On Friday 09 Jun 2006 12:22, Matthew Petach wrote: SNDS tomorrow Usability The sign-up process is very painful. Microsoft Passports really aren't appropriate for business accounts, my employer don't have a mothers maiden name, or a first pet. At one point it claimed the name of my first pet must have more than 5 characters in it ? (Perhaps they should aim for things likely to have more information in them, besides my mothers maiden name has been published in the newspapers). I sent a request for help, as the process fell over at the stage of authorising the first address range I requested. With a failure to handle the URL sent for me to click. Interesting--it's good for me to hear what people are saying about it, as I can't access it myself--my MSN accounts were all locked, and part of the termination agreement stipulated that I'm forbidden from accessing their services. It does mean the service is limiting its own scope by requiring Passport-based logins like that, as I'll never be able to use it to see if any of the domains/netblocks I'm responsible for might be originating spam. Perhaps if Microsoft is truly interested in helping clean up the Internet, they might lift the Passport login requirement? Matt [tempted to set Reply-To: to [EMAIL PROTECTED], but that might be considered antisocial. ^_^ ]
Re: 2006.06.07 NANOG-NOTES TCP Anycast--don't spread the FUD!
Q: Randy Bush, IIJ, 10th anniversary of much of the Anycast UDP deployment. s/udp/tcp/ udp preceeded by at least four or five years. randy
