Locator/ID Separation Protocol (LISP) WG THURSDAY, November 12, 2009 0900-1130 Morning Session I Orchid East ===================================================== CHAIR(s): Darrel Lewis (darlewis@cisco.com) Sam Hartman (hartmans-ietf@mit.edu) SECRETARY: Terry Manderson (terry.manderson@icann.org) AGENDA started at 9.05 o Administrivia 5 minutes Lewis/Hartman - Scribe(s)? Jabber (Marshal Eubanks) - Blue Sheets o Agenda Bashing 5 minutes Lewis/Hartman Lewis reviewed the agenda. Wes George requested: deployment scenarios requested for today due to clash the RRG tomorrow Lewis: can't due to presenter clash Jari Arrkko: Question on interop testing. Lewis: Will be covered tomorrow started at 9.09 o Review of Open Issues LISP Mapping Request Format see WG meeting materials page 30 Minutes Halpern Describe background and issue on format Does not cover every factor About mapper servers map resolvers and the alt infrastructure Two views of the functionality Should the request have one IP header or two? 1st way to look at it, fundamentally mapping system as a relay agent 2nd way to look at it, mapping system information provision Result: difference protocol behaviours as to functionality Recaps the map request debate Decomposition according to Joel - define the components conceptually - then if you need a different structure you put several logical pieces in the same physical item - examples - simple concepts, simple to assemble Address families - EIDs or RLOCs can be built using ipv4 or ipv6 - double encapsulation does introduce constraints - inner header must have an RLOC from the same address family asn the id Additional issues - what authentication capabilities are needed? - hide parts from the alt? - mapping part of data probe? Lewis: This is a presentation that sparks discussion, Joel can you summarise recommended changes? Halpern: View the map system as an question / answer system Since double header is awkward. Redundant information. Fuller: You're referring to the interface that the mapping system sees? Halpern: yes Lewis: Any piece of functioality missing? Hartman: (as indiv) Format of relay header ends up being an IP packet creates some complexity, you receive packets not destined for yourself. Frowned upon generally. One issue to think about. Lewis: Clarifies Sams issue/request. Dino: Believes that it is not an issue due processing at the control plane as the packet is received on the ETR, UDP port says its control plane, can choose to have IP send it to itself. Lewis: Any implementations required to support this indirection? Dino: A packet could find its way through ETR that is also ALT transit. It could forward it, but its all done at the control plane. Hartman: That true if the implementation IP is stack tightly coupled. if using some other IP stack, not true that you can easily do a good job of processing that inner IP packet. Dino: Any linux/unix system will do this. Hartman: Significant complexity, implement in kernel, and implement in LISP. Don't think only issue but don't want to spend too much time on the issue. Roque: Clarification question, Confused. authentication or authorisation on mapping request?? please clarify. Joel: Interesting questions, binding info carried in a request, what is being asserted with what confidence when messages are sent. The way you look at the system tends to direct the type of authentication. Dino: Highlights different models, yes? Halpern: Architecture affects the pieces, yes. Lewis: Should we have version number in data plane? Should dest IP of map request be a key to the lookup? Dino: Wanted to deploy systems that were easily available, or even implement lisp processing. Pull alt out of mapping system. Gives more options (DHT/DNS) in mapping systems (user flexibility). Hartman: What do you mean "up stream of map resolver" Dino: upstream of the map resolver means the path the map request will take once it is received by the mr and destined to the authoritative map server. Hartman: So in today's architecture the ALT is upstream of the map resolver. Dino: and in future architectures, using DHT, DHT boxes would be upstream of the map resolver as well Halpern: Might not want to view the ALT it as a relay. Ability to replace pieces highly valuable. Dino: Case of where to put functionality in ITR/map servers etc. Lewis: more implementers speak up please. Luigi: Could be seen as optimisation of ALT, constrained if we switch from the ALT to another mapping system. Need to look for trade off between XTR and map resolver. Hartman: Dino says one way is more flexible in core, Joel says doing the other way its more flexible. Everyone in agreement to maintain flexibility. debate is about which way is more flexible or what type of flexibility. Luigi: Its a difficult choice Lewis: I think we need a concrete proposal for consensus. hartman: Joel had proposal and and Dino sent a long list of questions. I created a email to cover it and realised it was more complex that initially thought but sent that with procedures that covers different scenarios Lewis: Way to move forward ? any further comments? Dino: Want performance of mapping system to be efficient and easy to do lookup. Rather put headers in ITR (trivial) than in mapping system, and keep map resolver as simple as possible. Lewis: will take it to the mailing list. ended at 9.44 LISP Security Analysis & Discussion 30 Minutes see wiki and WG mailing list for background Hartman started at 10.45 (note, questions are interspersed with presentation notes as was the nature of the presentation) LISP security will take stops for discussion started wiki page http://tools.ietf.org/wg/lidp/trac/wiki/Security01 [ Luigi: We started draft at request of chairs, asked for volunteers, and we volunteered. ] others have though about this before. i.e. mobility what level of security trying to achieve don't want to make it worse if you are behind lisp don't want to harm other areas in ietf [ Dave Meyer: complete list? or more? I don't see deployability there ] [ Dave: my argument is that these things aren't independent ] [ Hartman: I believe deployability needs to balance against everything else ] [ Hartman: in agreement ] someone needs propose to enhance lisp with security Goals see slides Control plane Question to WG, reusable set of goals?? (see slides) count: 15 for, 0 not Mapping system protect against DOS nor facilitates it off-path v on-path attacker [ Jari: integrity of mapping data, clarify? ] [ Hartman: that you have the right answer ] limit scope of replay attacks [ Roque: Making mapping system less vulnerable than dnssec? ] [ Hartman: Need to have a time bound on replay ] [ Roque: you said, not make it worse than today. ] [ Hartman: we can discuss ] end to end cryptography not the answer want to offload the cpu/crypto to someone else want something today [ Meyer: clarify want "sufficient" security for "experiment".. subjective terms? can't find meaning. ] [ Hartman: Arguing that you need good enough non cryto security i.e. nonce in map request ] [ Meyer: but you are using subjective terms ] [ Lewis: Don't want security to be so poor that no one wants to use lisp ] [ Hartman: Want security of list to be comparable to rest of the internet by using simple mechanisms, even whout end to end cryptography ] [ Joe touch: Is there some reason lisp mapping need to more or stronger that arp? ] [ Hartman: yes. (why?) examples on wiki, security on arp is inappropriate ] [ Joe touch: so there are corner cases where they are relevant, but others where they are very similar to each other and I think should be noted. ] - lisp mapping (next slide) [ Jari: Unhappy - You seem to be starting from the solution. For me start from requirement. lisp doesn't decrease security ] [ Hartman: Sense of the room is that we are there, but hear but only need to sign end to end and cut corners - I don't buy it. ] [ Jari ok. then we are on the same page ] layers of security - ITR to map resolver - mapping core - map server to ETR - ETR to ITR want comments to agree with this approach [ Dave Myer: explain what you have in mind? ] [ Hartman: might see ITRs on access networks. ] [ Lewis (as Indv): while we might want signed map data, seems to be a contradiction of "no worse than the internet" ] [ Hartman: need to improve map system - not. move slower. ] [ Wes George: agree with you on not relying on end to end signing. Want to make sure you are covering end to end. light-wight version heavy-weight ] [ Hartman: yes needs to cover that in security analysis ] [ Wasserman: concern we not kidding ourselves. Map system is different than bgp as it is. Peering versus full question/answer - different requirements and different participants] [ Hartman: one of the bullets yes. ] [ Roque: who signs, need some guidance ] [ Lewis: want to wait until end to look how to move forward. ] pet peeve. potential attack ETR can lie (claiming 0::0/0) Suggest this is an attack. proposed requirement: See slide [ Lewis: we should try to agree on larger issue first, agree that this is a viable attack? ] [ Dino: existing text says we have a solution to this with proxy reply bit ] [ Hartman: no. not a solution. ] [ Dino: no ] [ Hartman: the attack is where I have a key, but I claim more ] [ Dave: bgp has this today, amount of infrastructure to do this is massive if you put this in path to getting lisp deployed it will have the same effect on bgp ] [ Lewis (as idv) : I think we can rat hole on this easily, but we could as a map request goes to an ETR it always passes through a map server if the map server were to send a reply with just the max lenght to the itr the itr can choose. the other idea is to have the etr first to its map server to do a sanity check on it then deliver it to the ITR. ] [ Joel: problem is conceptual idea of stopping ETRs from over claiming is a good thing. Wording is a swamp. lets not get distracted with insoluble problems. ] [ Lewis: Action item take this conceptual issue to list. ] [ Jari: reason I like lisp: SOHO, but small players don't have the same trust.. ] Hartman: Luigi's draft.. please read draft and wiki page. [ Lewis: integrate those two? ] [ Hartman: need round of comments between Luigi and Myself ] [ Luigi: will comment. ] ended at 10.30 LISP Internet Groper (LIG) (moved from Friday) draft-farinacci-lisp-lig-01 Meyer 10 minutes started at 10.30 - start building tools - user requirements map system working? is MR and MS working? is site registered? diff address families what are the various normal questions? - fetches map entry - both router and host lig available - lig self - destination is EID or legacy address implemntations nxos ios implementation linux/freebsd/macos working group document? Hartman: what do expect it to cover? Meyer: in draft Margaret: useful tool. no object to publish. Yari: comment no problem publishing as wg if there is spec in it. as opposed to saying there is a implementation Margaret: its a procedural implementation of a spec Lewis: will send a call to wg-ml ends at 10.42 Starts at 10.42 WG update from the AD 15 minutes See WG mailing list for background Arkko Thinks lisp is one of best WGs - happy with fundamentals need a chairs / editors that wg well together feel it is his fault make a change in the team getting new people as chairs and base specification. wg has intense discussion, need to have common deployment models. concerned that wg gets drowned in a sea of details, need prioritisation balances the ability to publish vs getting feedback by next ietf we should have deployment stuff clear solved stuff about the base document does require signifiant effort ask wg at large to read ML. Dave Meyer: this is a radical move. I would like to know how this is so broken. Jari: perception of the relationships were not in good enough state to work together - trust had disappeared between them. That was my assessment. or something was going to break very soon. Dave: let me summarise: something is going to break in the future so everything is going to change now. Jari: yes.. I was worried about this. I blame myself. Session end at 10.54 FRIDAY, November 13, 2009 0900-1130 Morning Session I Orchid WEST ===================================================== o Other updates started at 9.05 Lewis: agenda Jabber Scribe: Wes George. LISP Deployment Scenarios see WG mailing list for background 20 Minutes Lewis & Wasserman start at 9.07 lewis running through agenda lisp deployment scenarios Goal: help lisp in practical deployment scenarios red means rloc, green is eid (see picture on slide 4) JARI: 1) thinking about tpes of deployment thinking about lower end 2) draw nats / firewals etc lewis: all those would be below this l isp Xtrs split ITR/ETR Site encapsulate as soon as possible, and decapsulate as soon as possible. Florin Corass from jabber: slide 4 but if those are low end routers doesn't it bring up the discussion from yesterday when Dino argued that these routers should be able to do encapsulation for communicating with the Map-Resolver? Isn't it to much load for them? Lewis: what we found that generating a packet is the cost. the cost is the map request Wasserman: you have to write 20/40 more bites into a buffer, its not very big Lewis: map requests is not the bounding issue. lisp XTRs for interservice provider TE advantages Disadvtages - extra header, adl locked, db maintenance Implications - Jari: I don't understand, can someone explain Dino: explains ref slide 7. Jari: so essentially does one layer of lisp at provider, then more at customer? Dino: reverse that, first at customer - dino explains.. finishes with "there is always MTU issues" Jari: spec wise how many headers Dino: 2 headers Wasserman: concurs, don't want to throw packet away Jari: this seem rational. we have to select the ones that are high priority, shouldn't address too much, should make explicit decision. Dino: Darrel made a good point as this reduces more specifics from site and SP. Wes: Typically the downstream offer the more specifics Jari: full belief that this feature it is useful, need to work out which of these will be put in? XTRs at the provider edge advantages - site doesn't have to upgrade CE - multihoming to a single SP might work - degenerate of the VPN case local NAT in - Disadvantages - site loses control of egress TE Jari: lots of problems, won't even get multihoming. Lewis: Its up here as a common question, not because I endorse it. Hartman: don't have to use it right? Lewis: true, but look at Myer locator reachability Hartman: get sense of room that this is not a high priority. room: not high priority to be confirm on lisp by new chairs. Margaret: these are the reasons not to do it this way Meyer: People will do what they need to do. are there things that we need to support in this scenario? Hartman: Should that work be a priority. answer is no. Dino: scenario where this could be useful - if wanted a PE implementation, configures to set L bit off Locators could be everything controlled by the service provider. Lewis: Map reply issue? Dino: More semantics of map reply from different places. Lewis: yeah, the PE might say instead of itself as a locator it my put some other IP address in the É. Hartmans: hang on - just decided we don't want to spend time on thisÉ lets move on. Map servers (slide 10) Redundant servers are desirable impacts need mechanismn to configure EID prefixes, keys, and map servers on ETRs Jari: find important that we consider relationships with registrars Lewis; need to have a relationship with who advertises your id to the alt. Jari: can you also configure others Lewis: you could. but need to consider filtering practicing in the alt Hartman: but do you want that. There is a question of aggregation and deagregation Wasserman: you cant just register with anyone (shared keys) Hartman: there are archirtuctural things we can do. Dino: aggregation can be done effeciently for both v6 and v4.. you have options to commercial mobility if staying within address boundary. want topology to follow addressing Hartman: disagrees not sufficient ids available in v4 back to presentation slide 11 Joel: what is benefit to sip for doing this Lewis: incentivising provider to not cary as many routes. Hartman: another possibility, whoever offers id prefix will offer map resolver. don't want to repeat failures of DNS open resolvers is a mistake, should have security associations with map resolvers. Dino: more efficient to do same thing Dino: more cost to do the same thing Hartman: disagree with the claim with more efficient to forward packets Jari question audio Dino: making good point is this chicken egg problem. do we have to have full blown map servers enough demand to put map servers in? Jari: If I urn this on, my ISP there is infrastructure available. Lewis: understand were you are coming from Wasserman: people who do lisp initial will run al the services. slide 12 Proxy ITRs Proxy ETR advantages Dino: because of this, benefit comes right away back to presentation - issues about address families - issues about strict urpf proxy ETR the solution XTR behind a NAT - early adopter Jari: not sure about this. Hartman: we need sufficient nat traversal so that they can get something working Lewis: guidelines to get something working Jari: make sense Wasserman: don't want to break this to get plane off the ground but don't want to do full nat traversal Lewis: wrap up. Jari says yes. Hartman: unwedged thinking about lisp. Luigi: need more work, nice to see impact on traffic metrics, impact on business relationships. Lewis: agree end at 10:21 LISP Implementaitons Update 10 Minutes see WG meeting materials page Wasserman Start at 10.23 Interop testing event monday night, Four implementations represented lack of interop well understood Dino: all implementtaion to -05 spec implementation status: cisco lisp openlisp LISP-click Meyer: when you say control plane?? Wasserman responds ZLISP Interop matrix possible spec issues mandatory rloc probes? support map/request/reply Dino: spec doesn't say static map cache entries. (Disscusion about rloc probes.) Meyer: one other: IOS implementation ended at 10.33 LISP Network Update 10 minutes Meyer/Lewis started at 10.33 MR and MS (a.rloc.lisp4.net) ended at 10.36 LISP Mobility Archetecture draft-meyer-lisp-mn-00.txt Meyer 30 minutes started at 10.37 agenda user goals solution overview Roaming - control plane roaming - data plane summary Joel: detail questions: s2 map cache update, how? Meyer: every mechanism we can. Pref? Joel: probe low ttls. Dino: look at terms in state and looks good. cost is a gig to store a million entries. Dino: /32 id stays in the map system back to summary Dino: ask researchers, what if we weren't using alt? Hartman: why be concerned all mapping dbs could cover that? Meyer: not clear. Joel: what you just said is the confusion. need to preserve the property of map-server abstraction Hartman: core is that can register a prefix and all map requests of to a given map server. Dino: not if you can or cant its the number of /32s moving. Lewis: location is different to map data itself. Hartman: map system may support something else. as implementer you don't have to do that. Jari: said it wasn't in scope (as working group document) Wes: I think it should be in WG list. need to capture requirements, lightweight and heavy implementation, need tighter integration to mobile device, need to deal with exiting infrastructure in integration. Meyer: starting with android Margaret: personally not adopt get base spec out, then do mobile as second round. Meyer: echos Jari's comment. jar: clarify as AD: get base stuff out. Joel: relationship to mobile nodes in a lisp site to move out to a non-lisp site, any thoughts? case is when a node get and eid, and fixed and then un tethers. Meyer: there is a analogy in the cell phone world.. point well taken Wes: generally agree with get basic stuff done first, cover basics requirements to interact with lisp, dealing different standards bodies. has to work with all disparate standards. Jari: re damage to routing, everything today is out of routing table Wes: mostly true, but still places that need to capture the routing. Jari: true. Dino: thought about having a lisp mobile node roaming.. can talk to other mobile nodes. are all these levels needed. there will be evolution and can work together. Meyer: wanting to bond radios Wes: agree ip should the the inter working layer - need to look at map if it becomes a spegati. finished at 11.13 WG concluded.