June 2006 - Test - lists.nanog.org

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 05 Jun '06

05 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

NANOG 37 - Lost & Found
by Carol Wadsworth 05 Jun '06

05 Jun '06

Found: Lexar JumpDrive by second floor seating area in Hilton close to convention center entrance. Claim at NANOG Registration.

1 0

Problem With the Real Player Stream?
by Scott Weeks 05 Jun '06

05 Jun '06

I can't hear anything on the Real Player stream due to a very loud hum. Is it me or can something be done? scott

3 2

RE: Problem With the Real Player Stream?
by Scott Weeks 05 Jun '06

05 Jun '06

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] > On Behalf Of Scott Weeks > I can't hear anything on the Real Player stream due to a > very loud hum. Is it me or can something be done? ----- Original Message Follows ----- From: "William S. Duncanson" <caesar(a)starkreality.com> > Not just you, I encountered the same thing. The WMV > stream is clean though. I just went and turned on my Microsloth box and that stream's good. Thanks. scott

1 0