- Test - lists.nanog.org

AW: Phantom packet loss is being shown when using pathping in connection with asynchronous routing - although there is no real loss.
by Gunther Stammwitz 06 Jun '06

06 Jun '06

Hello Alan, Thanks for your reply. I know that icmp is being handled by the router's cpu and that the forwarding is being done in hardware. The interesting part here is that the loss starts at the router where the asynchronous routing begins and is even being seen at the final destination host - but this only happens with pathping and mtr. An ordinary ping doesn't show this problem. The problems in mtr/pathping disappear when a synchronous routing is being established. What's the case for this? What are the programmers of mtr and pathping doing wrong or is there another problem mayb in the implementation of icmp? Gunther > -----Ursprüngliche Nachricht----- > Von: Alan Clegg [mailto:alan@clegg.com] > Gesendet: Dienstag, 6. Juni 2006 17:27 > An: Gunther Stammwitz > Betreff: Re: Phantom packet loss is being shown when using > pathping in connection with asynchronous routing - although > there is no real loss. [..] > > I'd guess that the routing devices are just droping/ignoring > ICMP echo request packets. They are the least interesting > packet, and are quite often, responses to them are given > extremely low priority. > > Just my guess, > AlanC

1 0

2006.06.05 NANOG-NOTES Network Neutrality panel notes
by Matthew Petach 06 Jun '06

06 Jun '06

(since there's no slides for these online anywhere, and the slides were going past pretty quickly, I have to apologize for the gaps in the notes ahead of time. --MNP) 2006.06.05 Network Neutrality Panel [slides are not yet online] next up is the controversial subject of network neutrality; Bill Woodcock will be chairing the panel, so Randy Bush can go be a member of the audience again. Bill Woodcock: network neutrality has been in front of press and legislatures for the past several months, and has been in the works behind the scenes for almost a year. Brokaw Price, peering at Yahoo! Sean Doran, free agent, "rooting" for Sprint back in the day Sean Donelan, now at cisco, Gene Lew, at neustar now, has done cable operations before. Sean can pretend to be Vint Cerf for this panel. :D Network Neutrality--what does it mean to operations people? History: Michael Powell, Feb, 2004, defined four internet consumer rights (chairman FCC) freedom to access content freedom to use applications freedom to connect personal devices freedom to obtain service plan information History of net neutrality concept: feb 2005, madison river telephone company consent decree "Madison River shall not block ports used for VoIP..." August 2005, FCC policy statement access lawful internet content run applications and services subject to the needs of law enforcement connect legal devices that do no harm to the networks competition amongst... All of these principles are subject to reasonable network management. That last bullet is what gives telcos ability to quote QoS as a mandatory network management requirement. March 2006, internet non-discrimination act senate bill 2360 only 2% of americans have a choice in last mile. shall not interfere with block, degrade, alter, modify, impair, or change bits or content May take measures to protect customers from attacks may protect their own network infrastructu May 2006 Internet freedom and non-discrimination modifies clayton anti-trust act. Passed based on party lines. Turns over to Sean to talk about his thoughts. Sean Donelan Doesn't represent anyone right now. The Huck Finn approach. And no, you can't configure this on your router. What are we talking about? Rep John Conyers (D-MI) "internet as we know it is at risk" Same guy noted in 2003 about cable operators being smart enough to not poison their customer pool Not really a new issue: ANS CO+RE in 1991 unapproved networks filtered from R&E gateways ANS and CIX, June 1992 ANS agreed to "provisionally" interconnect CIX proposed filtering resellers (194) NSF NAP/NREN solicitation (1993) required NSPs connect to all priority Network Access Points (NAPs) uncertainty created opportunities for new service providers pizzahut.com debate--couldn't reach it from university networks, but you could reach it from UUnet. Two-tiered internet even back then. Regulations chasing change TitleI -- General FCC Authority (pre 1984) TitleII common carrier voice/phone calls/later data TitleIII spectrum licensing broadcast TV and radio TitleVI Cable Television (post 1984) FCC moved DSL (but not UNE-L and cable modems) back into TitleI again. VoIP is still unknown. Telecom act of 1996 was another biggie. before 1996, enhanced services transmitted over a common carrier. After 1996, info services were defined by the telecom act; they run over telecommunications provisioned by anyone, not just common carriers. That's why cable companies can offer telecommunications even though they're not common carriers. Also why Radio and TV can put IP in subcarrier without being common carriers. So, we have a really odd blend, they're not mutually exclusive. Now you have the potential for new entrants from any direction. Most home services now come over cable companies; multiple resellers of same product wasn't enough to satisfy customers. Customers are very fickle Interfering with a customer's use of the Internet would hurt the provider's business. No-one can predict what the next "Killer App" will be. and *everyone* can complain Both sides need each other to succeed. Predicting in advance what customers want and will consider improvement vs interference is hard to the point of being nearly impossible. And what customers consider an improvement one year may become interference, or what was once interference will now be considered improvement. If you start writing regulations, you imply investigative and reporting requirements along with it. Who would enforce these regulations? And regulations seldom prevent people from being evil, the government simply sets the price for being evil. Broadcast fairness doctrine--equal time; nobody can buy public advocacy on national networks, except for politicians, who get the best rates. Kingsbury committment--ATT had to interconnect with everyone--but that meant you didn't need a second long distance company, so ended up supporting monopoly expansion. Universal service backfired by giving a monopoly to those giving out the free phones to... Back to Bill Woodcock: Arguments in favour preference will go to dominant players instead of technological innovators If market isn't free, consumers must be protected from predatory practices. Nondescrimination is part of common carrier status Many access networks were built under monopoly protection are they thus the moral property of the consumers who were forced to pay to create them? Arguments against descrimination required to protect customers from "bad" traffic. service bundling needed to encourage future investment in infrastructure Nondescrimination is compelled speech in the first amendment sense. QandA for the panel. Q: Free speech: can carriers claim "common carrier" protection from responsibility for customer content, and simultaneously claim a seemingly-contradictory 1st amendment protection from compelled speech? Sean Doran--Canadian, working in EU on similar issues; can carriers degrade non-customer or competitor's traffic as part of deregulatory process? Unbundling local loops, etc; if people were given access to these components on an equal cost basis, would incumbent be able to sustain a biased offering around degraded service? Risk was taken that rather than regulate a monopoly, the regulators would create an artificial basis where the competitive playing field was forced to be level; seems to have worked, they've seen 100fold to 100,000fold price decreases since 1997; double-digit mbit connectivity four double-digit prices in US dollars are available in major cities; can get triple digit BW for triple digits in stockholm for example. Mutually competitive providers, incumbent PTT is forced to sell access to all comers at same price level. Regulating on other levels tends to enhance the power of the incumbent, rather than limit it, since they generally have the stronger lobbying power. Bill Norton at mike--In US, given the large amount of video traffic on the net, do cable companies have enough infrastructure to handle forseeable traffic levels? Since he can't be compelled to pay for speech that isn't paid for, he'll just replace your ads with his own as they pass along the wire. What about mandatory revenue sharing? Bill Woodcock passes the question to Brokaw Price from Yahoo! Well, Brokaw notes that's a push model, vs the reality of the internet, which is a pull environment. If incumbents did that, the model for the internet would start to collapse, as customer wouldn't be able to be sure where their traffic was coming from; more likely the incumbent would be likely to compete directly, rather than trying to circumvent. But that's likely to create more of a walled garden environment, and we've seen those walled gardens collapse in the past. Sean notes AOL could do it since they have proxies (ad replacement, that is). More likely that telcos would be able to show that a free-for-a-month link is better than your other providers, so you should pay them to get that better connectivity--and since you can't see into their routers, you have no way of knowing *why* their direct paid-for link is better than the alternative transit provider's link. The congestion issue is all this just an excuse for backbones to not upgrade, and just pass the pain and costs around to different players? Gene notes that Neustar is not taking any official position on network neutrality. But then back to earlier question; the ads on baseball games are often not what exist in the stadium, they're what the broadcaster decides their audience should see. Being a former carrier, it's debatable about skipping upgrades and forcing QoS payments instead to deal with congestion issues. Where he lives, he has 5 broadband providers he can chose from; in major metro markets, that's often true, and with municipal wifi coming into the play, could be a dark horse that will force the issue. The competition issue: do network neutrality and local loop unbundling matter only in the absence of competition? Brokaw: well, competition is generally good, gives customer a chance to decide which provider is better, assuming the customer has the wherewithall to move. In areas where the customer can't change, yes, it's likely to be more of a problem. In the content space, if he only has one option to reach a huge consumer base, price elasticity raises his ugly head, and it's likely the user experience will be adjusted to reflect that increased cost; and that's an ugly outlook for the internet if we follow it out to its conclusion. And if the big players are forced to do that, it's likely the smaller players will be under even more pressure. 3 choices: do we have sufficient competition now? Do we need more regulation? Or do we need more competition? Brokaw: consolidation is reducing the number of competitors in the market; it's still a free market, so we're not yet down to monopolies yet. It's a tough call. We're struggling with what the end vision will be. Sean Doran: US needs more competition; there's already too much regulation in all the wrong areas. Congress is introducing bills all over the place, likely to do for network neutrality the same thing they did with spam. not likely to turn out well. Sean Donelan: regulation tends to freeze things as a status quo; just adds more regulation, rather than adding more real competition. Regulation just gives more brand names without real competition. He feels regulation is useful as long as it goes in the right direction; tries to make everything look alike, rather than rewarding innovation. Greg Lew: Is there enough competition, or more needed? Well, yes for his area, but large areas (20%) don't have access to broadband, so those areas need more competition, definitely. Q: Michael Sinatri?, UC Berkeley. Service Provider (TV station) pays the content provider for the content, and negotiates the ad space placed on that. If the content is being provided for free, what right does the SP have to modify the content mid-stream? Content Accelerators--shrink images before being sent; if customer pays for that, does that infringe on content provider's original data? Q: Ted Seeley, Sprint. Incumbent ILECs spend millions to build out infrastructure to support that video distribution. Why pay SBC when you can buy it from Sony? That is, the ILEC spends the dollars to expand their network, hoping to recoup the cost from the customers over a 10 year period; But there's no guarantee that customer will be there for the full 10 year amortized time for paying back the buildout; if they jump ship to someone else, how do those upgrades get paid for? Q: Patrick Gilmore: if telco wants to charge content providers for bits they're sending, what are they going to charge each other for the high volume of illegal content they're sending back and forth to each other, which according to their own stats is the bulk of their traffic? Survey forms available on the web! If you're sticking around, fill it out. If you're leaving, fill it out! Maps with food places; will start up again at 2:15 for afternoon bofs. Lunchtime now!

1 0

2006.06.05 NANOG-NOTES IPv6 deployment at Comcast
by Matthew Petach 06 Jun '06

06 Jun '06

Randy Bush, moderator of the next section He begged to do the introduction for a specific reason; deployment of IPv6 that is beneficial to this companies' P&L; possibly the only one in existence thus far. He did a very studied and purposeful view of using IPv6 to benefit his company! IPv6 @ comcast Managing 100+ million IP Addresses [slides are at: http://www.nanog.org/mtg-0606/pdf/alain-durand.pdf Alain Durand Office of the CTO Director IPv6 Architecture Alain_Durand(a)cable.comcast.com Agenda Comcast needs for IPv6 Comcast plans for IPv6 Challenges simplistic view of comcast IP problem 20 million subscribers in video 2.5 set-top boxes per subscriber 2 IP per set top-box per DOCSIS std. total 100 millions IP addresses needed that's not including high speed data, nor comcast digital voice, nor mergers/acquisition Used to use RFC1918 for cable modems. that space was exhausted in 2005 Comcast recently was allocated the largest part of net 73 and has renumbered cable modems in that space. In the control plane, all devices need to be remotely managed, so NAT isn't going to help us IPv6 is the clear solution for us However, even we are starting now, the move to IPv6 isn't going to happen overnight. Triple play effect on the use of IP addresses 2005 HSD only 2006 T+ Cable Modem 1 1 Home computer/router 1 1 eMTA (voice adapter) 0 1-2 Set top box (STB) 0 2 total num of IP addresss 1-2 8-9 (assume 2.5 STB per household IP Addresses: Natural Growth vs New Services nice graph--based on trends, not real data Contingency plans: use public address space use "dark" space (pre-RFC1918 space) federalization (split into separate domains) (trying to avoid that) IPv6 strategy start early deployment plans started back in 2005 deploy v6 initially on the control plane for the management and operation of the edge devices they manage DOCSIS CM, set top boxes, packetCable MTA (voice) be ready to offer customers new services that use IPv6 LATER, not now--first step is to just be able to manage their own gear. migration to v6 must be minimally disruptive. deploying v6 must be in roadmap for all vendors ops, infrastructure, systems must be ready to support v6 devices. over time, IPv6 will penetrate Comcast "DNA" Deploy v6 for IP addrs of the CM and STB architecture: dual-stack at the core, v6 only at the edges deployment approach: from the core to the edges backbone->regional networks->CMTS->devices this is an incremental deloyment; existing deployments will be untouched in the beginning Follow same operational model as with IPv4; lots of DHCP! News Flash: All routers on Comcast IP backbone are IPv6 eanbled first ping on 10GE production backbone TTLs aren't quite working properly, still checking on that. [so, even mainstream vendors still don't have v6 working quite properly yet] New CM will be v6 ready (dual-stack capable) On an IPv4 only CMTS, CM will have v4 address only On v6 enabled CMTS, CM will only have v6 address No CM boxes will have both; if they could support v4 on all, wouldn't have this issue to start with! Provisioning, Monitoring, Back-Office mostly software upgrade problem not unlike the Y2K issue fields need to be bigger in database and web scripts Should system "X" be upgraded for v6? does it communicate with devices that are v6 only? payload Q: does sstem "x" manipulate IP data that could be v6 (store, input, display) Comcast inventory analysis About 100 systems 10 need major upgrades for transport 30 need minor upgrades just for display/storage Back office management of cable modems. network transport will still be v4 however, back office systems may need to be modified to display/input/store v6 related data (CM v6 addr) Payload can be v6 while transport is v4. IPv6 certification Basic IPv4 compliance taken for granted today IP level component testing is limited IPv6 is still new technology maturity level of vendor implementations vary greatly some have v6 for 10 years even those have features not fully baked others have nothing, will rush to buy 3rd party stack. Bar for v6 product acceptance has to be higher than what we typically accept now for IPv4 Formal v6 requirement list before purchasing v6 conformance testing/certification to accept product v6 training most engineers have heard about it, don't know much fear factor can expect new hires to have 2-4 years of v4, but 0 v6 initial and continuous training process is critical! v6 vendors CM (cable modems) (DOCSIS 3.0/2.0b) CMTS Router Provisioning system OSS Video/Voice back-end systems Retail Market (Consumer electronics) Home Gateways Video (eg TV with embedded cable modem) Right now, provisioning system is most challenging. v6 protocols MIBS: some OSS vendors implement RFC2465 (deprecated) some router vendor implement partial RFC4293 (new combined v4+v6 MIB, but only v6 part) IGP comcast run OSPF v2 for IPv4 looking at OSPF v3 and IS-IS for IPv6 Integrating v4 and v6 security Integrating v4 and v6 QoS OSPF v2 and v3 share acronym, that's about it. QoS code points will be challenging; mark, and then trust QoS to deal with markings independent of the type of packets the markings are on. That's pretty much it. Not such a difficult process, mainly making sure the vendors do the right thing, beating on them with a big stick. Q: Dave Huberman, ARIN--without going into specifics of comcast--thank you, that's a very big landmark! You have upgrade so many items, spend all this time retraining staff, training new staff; how do you sell this gigantic cost to the 44th floor? A: The cost is non-negligible, but it pertains to business continuance, so in general executives aren't going to say no to it. Q: Lane?--similar question, it's an upper management support question. It costs money to do this! A: Extremely strong business motivation for doing it in the case of comcast; a good object lesson for others in how to get management on board with v6 migrations. More pushback from midlevel managers than from the top levels has been seen, actually. Q: Steve Schultz, NASA; any plans to implement IPv6 multicast, interdomain? At some point, will need to bring multicast to the set top boxes? Will they need both v4 and v6 multicast streams in core? A: They only want one multicast stream, from bandwidth size requirements, so will translate at the edges for now from v4 to v6. This effort is all for device management, though, so multicast won't be an issue for a while. Q: Doug Montgomery?; need for certification and profiles--do you see LOGO program for v6, as sufficient? A: Has been looking at v6 LOGO phase 1 and phase 2, they go deeply into neighbor discovery, but doesn't cover MIBs, or routing protocols, or transports other than ethernet. It's a minimum entrance requirement (phase 1 now, phase 2 in a few months), but that's not sufficient on its own; they have requirements above and beyond LOGO phase 1 and phase 2. Q: Merike, global security; some vendors have limitations on their v6 security features; what has vendor response been to them, since they're a big company. A: They have had to raise pressure on a few, yes; but since nobody wants to lose Comcast account, they have been responsive. Q: Tony Hain, Cisco. Doing this with management, not seeing any demand from customers; customers shouldn't know underlying protocols, so they'll never demand. Is there a plan to eventually get it to customers? A: it's really based on services they can offer; if there's a service that's v6 only that they can sell to customers, they'll roll out v6 to the home. Q: someone from Juniper: why comcast needs 100 million IP addresses. They use v4 right now, what do they use? A: they don't have 100 million yet, that's what they're growing to; using 10/8 and 73/8 for now, may use some dark space during the migration period. They're still using public space for now. Q: Bora Akyul?, Broadcom; you mentioned this in the certification. Plenty of RFCs that obsolete each other. IPv6 is richly optioned protocol compared to v4. How do you decide which options you want to use? Will you publicize those to your vendors? A: DHCP v6 vs stateless autoconfiguration, may be conflicting methods. They decided they wanted to use DHCP v6, NOT stateless autoconfiguration, for example. Q: Exactly! will they use a lot of extension headers? Q: No, keep it simple! Q: Randy Bush, IIJ? Two things he knows; a) what is the simplest way to get from here to there b) don't try to convert the users--they don't need to know what's happening at the protocol layer Q: Matt, Yahoo, asks about whether they will be planning to give net 73 back when the IPv6 conversion is done? A: Well, they have a bunch of other systems that need to communicate using v4, until they have a solution that can do v6, will keep the v4 addresses.

1 0

2006.06.05 NANOG-NOTES interdomain routng via Wiser, Ratul Mahjan
by Matthew Petach 06 Jun '06

06 Jun '06

2006.06.05 A simple coordination mechasims for interdomain routing [slides are at: http://www.nanog.org/mtg-0606/pdf/ratul-mahajan.pdf Ratul Mahjan David Wetherall Tom Anderson University of Washington now @ Microsoft Research the nature of internet routing within a contractual framework, ISPs select routes that are best for themselves. Potential downsides higher BW provisioning requires manual tweaking to fix egregious problems inefficient end-to-end paths An alternative approach: coordinated routing ISPs have joint control path selection is based on the preferences of both ISPs Potential benefits lower BW provisioning no egregious cases that need manual tweaking efficient end-to-end paths basis for interdomain QoS Existing mechanisms cannot implement coordinated routing route optimization boxes help (stub) ISPs pick better routs from those available MEDS implement receiver's preferences. Cannot create better paths that don't already show up in the routing table. What makes for a good coordination mechanism? MEDS have some nice properties ISPs can express their own metrics ISPs are not required to disclose sensitive info lightweight requires only pairwise contracts Provides joint control and benefits all ISPs. Our solution: Wiser operates in a lowest-cost routing framework downstream ISPs advertise their cost upstream ISPs select paths based on both their own and received costs. Problems with vanilla lowest-cost routing ISP costs are incomparable Can be easily gamed When you bring incomparable costs together, the ISPs that use higher costs win out. Cost normalization Normalize costs such that both ISPs have "equal say" Normalize such that sum of costs is the same. Makes the system harder to game. Bounds on cost usage Downstreams log cost usage of the upstream ISPs Compute the ratio of avg. cost of paths used and announced Contractually stipulate a bound on the ratio. Similar to existing ratio requirements. Wiser in action Announce costs in routing messages. normalization occurs between ISP pairs. Example results using major ISP topologies for experiments Wiser provides better control under link failure. Wiser produces shorter path lengths Implementation XORP prototype Simple, backward-compatible extensions to BGP embed costs in non-transitive BGP communities border routers jointly compute normalization factors and log cost usage a slightly modified BGP decision process Benefits even the first two ISPs that deploy it. Summary Wiser is a simple mechanism to coordinate interdomain routing may lower provisioning, reduce manual tweaking, produce more efficient paths and help with interdomain QoS Feedback: ratul(a)cs.washington.edu http://www.cs.washington.edu/research/networking/negotiation/ Danny McPhereson: Q: how do you normalize across multiple ISPs? A: routing advertisements happen on the sum of the costs announced from me to you, and from you to me. He derived it from different values in his experimentation; utilization and latency in general. Q: Randy Bush: Whatever metrics are, you just normalize by summing them up. But Danny notes if you have multiple ISPs, how do you normalize them together? Q: Danny: where was the 20ms of control plane savings seen that he claimed in slide 11? A: That was based on default ISP policy, prefer customers over peers, etc. So the delay was control plane plus data plane; it wasn't control plane alone. He based it on the old rockefuel equation. Randy Bush: vendors--this is cool stuff, open your ears. Break time now.

1 0

2006.06.05 NANOG-NOTES Pretty Good BGP Josh Karlin
by Matthew Petach 06 Jun '06

06 Jun '06

2006.06.05 Pretty Good BGP Josh Karlin, Stephanie Forrest, Jennifer Rexford slides are at: http://www.nanog.org/mtg-0606/pdf/josh-karlin.pdf Main idea: delay suspicious routes lower the preference of suspicious routes for 24 hrs Benefits: network has a chance to stop the attack before it spreads accidental short-term routes do no harm no loss of reachability adaptive simple Algorithm Detection: monitor BGP update messages treat origin AS for prefix seen in past few days as normal new origin AS treated with suspicion for 24 hours. treat new sub-prefixes as suspicious for 24 hours. Response: suspicious prefixes given low localpref, not used or propagated suspicious sub-prefixes are temporarily ignored Example prefix hijack (without PGBGP) same specificity Example sub-prefix hijack (without PGBGP) two /9's cut from a /8 In these examples, AS 5 acted in its own self interest, but it helped protect the rest of the net beyond it. Simulations of two deployment strategies Random, and core+random. Random, with 0 deployed, half the network will be affected, better solution as higher fraction of ASes deploying it. If core of network deploys (core ASes have at least 15 peer-to-peer links) only 62 out of the 20,000 ASes. All but 2% of network protected with that. Sub-prefix hijack suppression a bit tougher, but still good results as core implements it. hijacks in the wild 1997, AS 7007 sub-prefix hijacked most of the internet for over 2 hours Dec 2005 26-95 hijackings during month jan 2006, panix's /16 stolen by conEd Feb 26, 2006, sprint and verio carried TTNET as origin AS for 4/8, 8/8, and 12/8 IAR: internet alert registry IAR verifies hijack attempts a near realtime database of suspicious routes email alerts are sent to those who opt-in for the ASes they choose to recieve alerts for operators recieve alerts only when their AS has caused the hijack or is the victim Tier1 ASs receive one hijack alert per day typically working prototype Solutions with guarantees (and lots of overhead) sBGP soBGP psBGP Anomaly dectors Whisper MOAS lists Geographic based Good Practice proper route filters Route filters protect the internet from you and your customers, not vice versa. Why pretty good BGP? maintains autonomy incrementally deployable no flag day no change to the BGP protocol Effective with a small deployment only requires a software upgrade or change in config generation. Most important, requires minimum operator intervention http://cs.unm.edu/~karlinjf/pgbgp/ Q: (someone)? from UCLA--if you delay the route for 24 hours, if the original AS withdraws it, what happens? A: you'll still end up using the new route, as it just has a lower localpref, so moves will still work. Q: Danny McPherson -- what if origin AS is spoofed to match the origin AS by the hijacker--does this stop it? A: No, that's a man-in-the-middle, or at least it looks like it, and this can't handle that, so it's only pretty good; that would be a later phase. Q: He also notes if your prefix is hijacked, your email alert is likely to get jacked as well. A: True--subscribe from multiple prefixes/domains to be safe! Q: Phil Rosenthal, ISPrime. What happens when a small ISP in south america leaks the internet to an upstream that doesn't filter them? A: Yes, those leaks suck up a lot of memory; this doesn't help because the origin AS is still correct, but the intervening paths are bogus. If the route for a sub-prefix is seen with the origin AS along the path, not seen as a hijack. Q: Jared Mauch, NTT america; follow-on point, you just have a strange AS along the path, but the rest of the origin is correct. A: No, they don't look at the whole path yet; maybe in the future Q: Sandy Murphy, Sparta--thinking of statement at the end, it handles backup routes ok. it works best where operational changes of the origin happen at a human-paced interval. There are some prefixes which seem to oscillate at a much more rapid pace. What about studying prefix behaviour over a longer period of time? Is it locked into 24 hours, or can be adjusted to match better frequency? A: Not locked at 24 hours, could be adjusted to different 'sensitivity' as needed. Q: Randy Bush, IIJ: The internet is not static, those things which relay on viewing it as static like route flap dampening can bite us. We need to enable more and more dynamic behaviour, not less, and Randy thinks this is going the wrong direction. A: That's nice, but presenter disagrees and thinks this is a helpful step in the right direction.

1 0

2006.06.05 NANOG-NOTES AS-PATH prepending measurements
by Matthew Petach 06 Jun '06

06 Jun '06

2006.06.05 Active measurement of the AS path prepending method. [ slides are at http://www.nanog.org/mtg-0606/pdf/samantha-lo.pdf This is the research forum part of the meeting, people doing real research on real networks. Samantha Lo and Rocky KC Chang department of computing {cssmlo,csrchang}(a)comp.polyu.edu.hk Kowloon, Hong Kong Dr. Rocky Chang is her supervisor. Motivations: Apply AS-path prepending on a trial-and-error basis to control the inbound traffic. How effective can the AS-path prepending method be? what would happen to the routes after prepending on a link? The measurement setup; dual-homed stub AS. connected to 9304 and 4528 Two upstream links, L1 and L2. Announce a beacon prefix to both links with prepending on L1. graph of prepending length on the X axis. from 0 to 5, then back down. Wait 6 hours between each change to stabilize. goes from 102:29 at 0 on L1, to 14:91 at 5 on L1. Greatest change is between prepending length of 2 and 3. When decreasing, see an unbalanced phenomenon. Who was responsive to prepending? Incoming link to beacon prefix changes, next-hop of routes also changes in remote AS Passive-responsive are those where the next-hop for the route didn't change, but the subsequent path is different. Active-responsive, next-hop actually changes. Non-responsive ASes, see no change. 43 ASes no change in either incoming link or next-hop On L1: 14 ASes use one next-hop only Passive-responsive ASes 26 ASes incoming link change no change in next-hop Active responsive ASes 47 ASes: both incoming link and next-hop changes possible reasons: apply shortest-path policy no localpref override. Active responsive ASes: UUnet, Teleglobe, bunch of others, slide went pretty quickly Most of them are located 4 AS-hops away from L1; after prepending, they are 5 AS-hops away from L2. Routes to L1 at 4, via L2 at 6 when starting. What if both ASpaths via L1 and L2 have the same length? equal to or greater policy: AS1239 located 4 AS hops via L1, and 5 AS hops via L2. AS3662 has prepended once. So prepending once on L1, 5 < 6, no change. prepending twice on L1, 6 = 6, route changes to L2 even though they're equal. AS3257, located same as 1239 when increasing prepending to 2, L1 is 6 (4+2), L2 is (5+1), but still uses L1. When increased to 3, 7>6, it finally changes to L2. When decreasing to 2 again, it's equal again, but it doesn't flip back to L1 until the prepending is down to 1, at which point 5 < 6, then it finally shifts to L1. This is the "greater than" policy. Same prepending length, uses different routes. 'sticks' to previously used path. BGP update graph. After prepending, update messages continue for several hours. Conclusions and future work Route changes are introduced by active-responsive ASes shortest path policies topology -> when they will change possible applications predict amount of traffic shifts discover the upstream ASes policies Thankss to Michael Lo and Lorenzo Collitti Q: Randy Bush, IIJ, notes that from her slides, Tim Griffen describes her "delayed reaction" as 'BGP wedgies'. It comes from the BGP tie breakers, it's not something you'll be able to predict. A: She notes it's a policy choice of tiebreakers. Q: Randy insists it's not a matter of policy choice; it's built into BGP, and not something they have control over. Moving on to next speaker

1 0

2006.06.05 NANOG-NOTES TCP authentication with Ron Bonica
by Matthew Petach 06 Jun '06

06 Jun '06

2006.06.05 Ron Bonica slides are at http://www.nanog.org/mtg-0606/pdf/ron-bonica-joint%20presenters.pdf Authentication for TCP-based routing and management protocols, from Juniper. A joint presentation, Alcatel, Cisco, Juniper. Starts at NANOG at Washington 2 years ago, security BOF; someone said they would MD5 auth if they could update keys without bouncing their sessions. Suprisingly small number of people actually using MD5 authentication. Motivation many ops don't authenticate TCP based routing protocols RFC 2385 doesn't meet operator needs. Concerns: CPU utilization not so much of an issue for Juniper, [Cisco, Alcatel] Juniper architecture separates forwarding and control plane Key management hard to change keys requires bouncing sessions Weak cryptography easy attacks against MD5 Alternative approaches Application: in the protocols (BGP, LDP, etc) TLS --too much of a headache transport TCP Network IKE/IPsec Chosen Approach: better TCP authentication enhanced TCP auth option Hitless key rollover key chains configured on peer systems time based key rollover key identifier Stronger cryptography HMAC-SHA-1-96 CMAC-AES-128-96 Enhanced Authentication Option Kind - Length T/K Alg ID Res Key ID KEY Key chain contains a tolerance parameter up to 64 keys each key contains id [0..63] auth algorithm shared secret start and end time, both for trans and receive Sending system procedure identify active key candidates start-time <= system-time end-time > system-time if there are no candidates, log event and discard outbound packet If there are multiple candidates, select key with most recent start-time for sending Calculate MAC using active key calculate over TCP pseudo header, TCP header, and TCP payload by default, include TCP options (if you set the T bit, ignore TCP options) Format enhanced auth option active key ID ... Receiving system proc. lookup key specified by TCP option determine whether that key is eligible startime <= system - tolerance end time > endtime + tolerance [not sure if that shouldn't be end time > system time + tolerance, actually. --MNP] Calculate MAC if calculated MAC matches received MAC, accept the packet auth error procedure discard datagram log do NOT send indication to originator (doesn't adjust TCP counters) Config example: see examples on slide deck, they went past too quickly. Q: how many of us are authenticating IBGP sessions? A: majority in the room are Q: how many of us are interested in a better way of handling key changes? A: lots of people! Q: Russ Bundy?: are you planning on taking this work into IETF to publish through that path? A: Yes, went to RPsec, RPsec2, and SAG working group mailing lists. Q: Randy Bush, IIJ, were there any simpler proposals? Clearly this was designed for the IVTF. A: None that weren't already rejected by the team themselves. Q: Steve Bellovin, Columbia U. No longer security IAD. Why reject IKE and IPsec? It does all this, plus more (which isn't so good) Why not tie algorithm to the key, get it out of the header, get more bits for other uses? A: actually, alg. could be taken from the key; that's the type of comment they're looking for in the IETF; one arg for putting it in option is that is a quick way to check without calculating the MAC, second Q: is more interesting; why not use IKE with just auth. -- no need for confidentiality in this case. It was discussed, one idea was to just use IPsec with preshared keys, but then you have same key rollover system, and key negotiation. Those are all probably good ideas. Would like to do this as a first phase, allow for manual key rollovers, and in a second phase, you can negotiate a key for one-time use. Q: but in IKE/IPsec, you can use preshared key mode in IKE; A: but in this case, you'd still need a system like this to roll over the keys since you want to be able to change keys on each end asynchronously Christopher Ranch: Made the right choices, thank you! Q: Eric ? from cisco: why is this more complicated? A: being able to have multiple keys and roll them over. There are networks that have used the same key for 10 years since they don't want to bounce their sessions. You just can't do that with IKE. This is an operations driven requirement, that it be hitless. Q: Jared Mauch, NTT america: how does he go in and take his iBGP session, roll to this system without making the NANOG mailing list? A: [no answer provided] Q: Bora Kilf?, Broadcom: about IKE not being able to roll keys without a hit; if you use IKE v1, you can lose the IKE SA, have the IPsec SA, rekey your IKE SA, and then rekey your IPsec SA. He agrees with steve, looks like they're re-iventing large parts of IKE/IPsec all over again. Q: Gary? want to avoid colo meets; you want to be able to re-set keys without having to coordinate people in different timezones. Encourage people to participate in SAG to discuss this and provide feedback. Research forum speakers up next.

1 0

2006.06.05 NANOG welcome notes
by Matthew Petach 06 Jun '06

06 Jun '06

(getting my notes from today's talks out, finally. ^_^ ; --Matt) 2006.06.05 Welcome notes Program chair, Steve Feldman Thanks to Rodney Joffe, Neustar/Ultra services People who were instrumental in getting connectivity into the room here deserve a big round of applause NANOG program committee, Joe Abley ...wow, slide went fast. ^_^; Agenda changes--none so far. Remote participation: streaming options: http://www.nanog.org/streaming.html Realmedia multicast MPEG2, ???? Reminders: network security don't use cleartext passwords! do use end-to-end encryption (ssh, vpn) PGP key signing see link off www.nanog.org for details Beer and Gear tonight. Interpreting badges Blue badge: steering committee yellow badge: program committee red badge: mailing list committee green = blue + yellow Green dot == peering coordinator Black dot == network security red dot == PGP signing Lightning talks six 10 minute slots available on-topic for mailing list signups http://www.nanogpc.org/lightning deadling is 12:30pm tuesday talks will be wednesday morning. Over to Rodney Joffe now. Welcome to NANOG 37 Almost the NANOG that wasn't. significant effort, thanks to Merit and others; an uphill battle, both from time and location. Encourage other people to host! Not expensive, just takes time. Benefits of Hosting: choose the location (sort of): much easier to do at home. if you wait too long, you don't have a choice of venues. Tee-shirt: you get to pick designs for it! Wonderful engineering opportunties! NANOG Community--you get to give something back to the community. He's hosted through three companies now over time. Exposure--touched on by Randy and Bill yesterday. Generate favourable goodwill for your company; it's not a marketing event, but still gets name out. Network Architecture Plan A: Existing SBC/ATT OC12 at demarc cool! we should be able to get connectibity real cheap Nope: SJCC exclusive licensee says $10K charge to access it, even if gear is donated. Plan B: AboveNet GigE at the DEMARC, hot but unused, and owned by AboveNet from an earlier conf. Nope: SJCC exclusive licensee still has mandatory $10K access fee Plan C: Hilton has fiber run to SJCC infrastructure OK. Let's use microwave to connect Hilton to MAE-WEST 55 S. Market st. Plan C: Microwave from the Hilton to Joe Pucik's 13th floor office at mae-west fiber from 12th floor to 2nd floor meet me room cross connect to S&D across S&D fiber to PAIX Palo Alto to Jared Mauch/NTT But... 55 S Market == Faraday cage. :( No signal. FC quality glass. Plan D: Tango 54mb microwave from hilton to Dave 'Bungie' Rand's 18th floor penthouse roof at 50 west san fernando fiber from bungi to switch and data PAIX, to Jared Mauch at NTT. Hotel wasn't the biggest challenge, connectivity was. First thing you need to do after picking a hotel that can handle 500 people, 200 rooms. ONLY pick hotels that have fiber with someone you recognize from NANOG. Second thing is to make sure there aren't any access or use fees that have nothing to do with the equipment or bringing gear in. Otherwise, you find there are interesting charges that can be levied against you as you progress! Shout outs: Jared Mauch Christopher Queseda Joe Pucik? Ralph Whitmore Dave Rand UltraDNS and Neustar Volunteers! $10,000 colo space--picture is evil. Other end is the penthouse of the Knight Ridder building. Nice shot!

1 0

Layer3 down?
by Dennis Dayman 06 Jun '06

06 Jun '06

>From my IT department: "It seems that the internet is having issues at a Layer3 Communications router, this normally would not be a problem but L3 runs some routing for the internet backbone. The techs at L3 are working on the problem and we do not have an eta as to when it will be back up, this situation is completely out of our control. You may experience short network outages or severe latency." -Dennis

4 4

NANOG 37: Security BOF Agenda
by Danny McPherson 06 Jun '06

06 Jun '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI.... - -danny - -------------------------------------- Security BOF - NANOG 37 Moderators: Danny & Roland - --- Probing Open Recursive Name Servers John Kristoff Analyzing the results of remote open recursive name server probes. We look at the effectiveness of different probing techniques against different sets of data including reflectors used in recent attacks, other known open recursives and a large set of DNS server queriers. Some of the who and what are open will be briefly examined as as well as some unexpected responses to our probes that may invite further analysis. - --- Infrastructure Security Survey Results Craig Labovitz - --- Does Web 2.0 = Security 0.0? Roland Dobbins 'Web 2.0' hosted applications are going mainstream; recent events have highlighted the fact that not only enterprises, but millions of small businesses, SOHO users, and individuals who depend upon these applications are adversely impacted when disruptive network events occur. However, there has to date been little or no engagement between the traditional computer security community, the operational security community, and the developers/providers of these applications. What can be done - and what *should* be done, and by whom - to help integrate 'Web 2.0' application providers into the operational security community? What role, if any, should nsp-sec play? - ----- Email question for discussion from Monika Machado What tools are used by network operators for event correlation and aggregation and how effective are these tools for trending, analysis and reacting to incidents? - --- Open MIC/Discussion - ----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEhMvhVbIg27AGOxoRAjCeAJ9hltsKqcX0pZenonFc1PwtnCUWlQCgnNpp pGZlxdieQ5kqvTUmG9ljicE= =UCcR -----END PGP SIGNATURE-----

1 0