Session 1/1 (60 min) =-=-=-=-=-=-=-=-=- THURSDAY, July 24, 2014 1730-1830, 60 Mins Administration 5 minutes Halpern/Manderson/Iannone - Blue Sheets - Co-Chairs Composition - Agenda Bashing - Status reports for WG drafts [terry] this is my last session as working group chair, I now leave the WG in a capable hands of Joel and Luigi. Now you should all make statement to the microphone in haiku form. Chairs exempted :) Thank you [collective applauses] o WG Drafts update - LISP Introduction 10 minutes Chairs/D. Saucez/A. Cabellos [luigi] Albert is here on this document, we were slow on this document so we decided to add editors to speedup the things now the original author withdraw but granted full copyright permission so we can continue his great job. Damien and Albert are the new editors. Albert will present what they did so far. [albert] We did two things: - changed a bunch of things (check diff) and included many suggestions that you can find in the document by searching “suggestion by the editors”. next slide remind what we are entitled to do according to charter, an architectural description making it easier to read the rest of the specifications. Must include description of the cache management and ETR synchronisation. next slide we have changed the format of the citations, editorial polishing, removed emphasis notation which is not standard, text more neutral as before it contained statements comparing LISP to other protocols which is out of the WG. Improved overall readability and corrected few typos. We aligned with terminology in the main RFC to be easier to read next slide We removed a bunch of paragraphs (see diff). Either because they were redundant or because they provided too many details (too verbose). We believe an intro document must be way shorter than the specs, which is not the case today. We removed paragraph including description or statement of things out of the WG or charter (e.g., LISP-NAT is not a WG doc). Removed references to I-D.LISP-perspective which is not a WG doc. We added a figure that was not yet in the doc: a figure that shows the EID space, RLOC space and mapping system For the suggestions, I will not detail all of them. We believe that the draft should focus on describing the LISP architecture and should be really concise. Use technical language and use terms used by the WG and specifications. Engineers learns by examples, so we want to show the life of a packet and it to appear very early in the document (page 2 or 3). We should remove all reference or statements not in charter or WG or subjective The structure should be short and technical Upfront add a “how lisp operates” Key aspect of LISP should appear clearly and they are 1. the data-plane (encapsulation) 2. the control-plane (mappings, Map-Request/Reply) 3. inter-working 4. cache management (TTL, SMR…) 5. ETR synchronisation as required by the charter 6. Security: I want to poll the WG to know if it must be included or not 7. Use cases: not in the main doc, but as appendix as LISP is flexible and we have to show people how LISP can be used (e.g., TE, datacenter … ) That’s it [albert] do we need to include security? [fabio] you should define what is security. How I read the charter, that should be what is in the RFCs. I would agree to have a section describing the elements in place for security. For me, there is no need to go further than that. [joel] there is requirements to security consideration, this will not be a replacement for threats and for lisp-sec but that should be some material here. [ron] the structure is very different on the slide that what is in today so should I assume something new will be submitted soon so I should not bother with what is today [joel] no, if you read what is today, you will see big comments that say “should we do this”. We need comments from the WG. We need folks to review. [joel] august wg review, september editors propose the new doc, october discuss that new document and say either we blew it or we like it, we are out of time. The goal is to have it complete for Honolulu [ron] so the value of that document is that it suggest that structure [ron] now about security. You have no choice than to have a security consideration in the doc, you must point out the salient features of lisp and how they differ from the control-plane as we know it today. That might inform where the threats documents needs to go. If you say LISP has a pull model as opposed to a push that informs that you have to think about caches. If you say that it is a map-and-encap you have an issue where tunnel liveness is important. So it says the threat document what is important so yes, this section is useful. [dino] way too detailed for an intro, we should just keep an overview in the intro document and just say what are the security mechanism that are proposed and not what it doesn’t do [albert] we should focus on what is in the WG and the security mechanisms we have so far. [albert] the document at the end must remain compact, let say 20 pages, so security should be compact like 2 pages. [ron] I agree with Dino in a way, you don’t want this security considerations to be a monster but you want it to be enough that if you read the security section you have some ideas of what you might see in the threats document [albert] agree [damien] so you propose to expose what is different from internet today and so people can understand what security issue may come with LISP [ron] "thumb up" [darel] Albert, good so far, I like what you have started, please complete ASAP, that was an Haiku for Terry :) [ed] I agree with the statement and we have to get it done quickly. One concern I have in reading -04 version, there is a lot that is removed. Good example is any discussion related to NAT is removed or suggested to be removed. I am concerned about interactions with other routing mechanisms or middle boxes that exist now and that should be addressed in this document. Example: LISP uses UDP and all pointing to the same port is problematic for, e.g., firewalls, or NATs where you need 2 rules, inbound and outbound. I don’t know if they belong to security part but I do anticipate LISP tunnels will go through CGNs so I am not sure that removing all NAT stuff would finally help then. [joel] the problem is that the material to do that is not in the WG document and it may happen that the WG will come up with something different. So we might concentrate on what is in the WG so to finally complete this document [albert] you have a point, that should be introduced at least in the LISP intro document. In the deployment RFC we have some discussion about that and maybe we could add some of the deployment discussion in the intro document [ed] at least a discussion about the asymmetric nature of the protocol. No so much about how to solve the problem because anyway we don’t know yet exactly how to do, but at least we have to inform the reader that there are issues from that point of view. [chairs] thank you, please comment on the suggestion on the mailing list, you have slightly more than a month to do that - LISP Threats Analysis http://tools.ietf.org/wg/lisp/draft-ietf-lisp-threats 15 minutes D. Saucez [damien] Summary of what has been made on threats. A lot of discussion on the mailing list (100s of mails + private mails). Thank you to Ron and Ross for their fruitful comments. Based on that we decided to restructure completely the document. We changed the structure completely and remove all assumptions (e.g., we also consider now on-path attacker) no assumption anymore on who are the attackers, they can be anybody, anywhere. To make it easier we distinguish the mode of operation and threat categories and vectors. The doc is fully restructured, we don’t want to become a receipt of attacks because as in any other protocols, we can make hundreds of different attacks. So what we do is to abstract the kind of attacks we can have. This is why the threat model is split in attackers mode of operations (i.e., where are the attackers) and the threat categories (i.e., what is the purpose of the attack). And back from the previous version we took the vectors and mapped them to the modes and categories. Changelog: everything changed Modes of operation. Attackers can be on the path = catch packets, or off the path: not able to catch the packet but can inject packets. Internal vs external: internal is someone part of the network trying to break your own system. Live vs time shifted: the attacks ends as soon as the attacker stops making actions. Time shifted, the attack continues even if the attacker is neutralised. Control vs data plane Any combination can be done and we call that cross-mode, copyright by Ron :) In terms of threat categories we have two kinds: data or control plane. By that we mean the feature that is used, not the target (e.g., a data plane feature can be used to impact the control plane). We give the vectors but not explain in detail how to do (we don’t say use this bit, but instead we say if you used, for example, LSB then you can achieve X because of this particularity of LSB). Threat categories: what people really want to do. Replay: you take a packet and you use it afterwards to do something. In the document we don’t care of what will be done, just the fact that doing a replay is possible. Manipulation: capture then modify the packet and launch the attack Interception and suppression: I get the packet and prevent it to be delivered finally Spoofing: I change my identify Rogue: without hiding my identity I manage to make people trust me even I should not be trusted DoS Performance attack: by launching some attack, I cause processing/memory usage to slow down the process Intrusion attack: you are able to enter into the network to access something you are not supposed to have access Amplification attack: the traffic the attacker generates directly is much lower than the traffic resulting from the attack + combination of any of them. Charter says we have to present the risks and the solutions to help solving the issues. Question for the WG: What about saying that the threat doc only lists the risks so we rapidly converge? So for that we need all people in WG to comment the list in the mailing list. And then extend lisp-sec to propose some solutions (mitigations) to these issues. If solutions in threats, it will never end, we will not converge. What does the WG think of that? [fabio] splitting might be a good idea, I am author of lisp-sec. At least you have a place where you have articulate the threats very well in threats. [ron] well, you have the same information whether it is in one document or two so we are arguing about the presentation more than the content. But we have to keep in mind that when you introduce mitigations the mitigation itself may be a new threat (e.g., rate limit). If we go with the 2 documents you cannot anyway close the document until we made both. [joel] per se the charter is never finished because we are always writing new document that may introduce new threats. We can’t address everything. A way to solve that is that the sec document must then explain the implication of what it introduces or recommends. The threat document identifies the basic mechanisms so if sec introduces something new it has to state it. Anyway, whatever we propose may have security implications [ron] Given we have the feedback loop problem, it would be better to put mitigations in the threat document so at least between intro and threats documents we have a close set of documents. [damien] if in threat you really list all the abstracted risks, and if security experts can prove we are covering all the general risks in terms of security (e.g., a DoS is a DoS, and for example, your rate limiting example is after all just a DoS). So if we are sure we cover all risks in the threats, then after what we can do in sec is to say: ok we propose this mitigation and this mitigation might cause an attack of category X, that is listed (if we did it well) in the threat document. [ron] Imagine the threat is complete but sec is not. At that point the assumption is then that threats are there but not mitigable (yet). So the sec doc must be just as high priority as threat is and then the blocking will still be there. [joel] that is not the deal we made with the IESG and you were there [ron] Well the deal is what is written on the slide! [joel] yes, Ron is right we did say we will deal with mitigation [fabio] the way I read that is solution that *helps* to solve these issues. As we know security evolves with time. What we can do is make the best in describing the threats and then indicate solution that may help defend. We can achieve this goal. More than that, I doubt we could do it. I never saw that in any protocol, and my previous life was in security. Nobody will ever claim to be safe against any possible attack. [ed] the problem is the pointer feedback issue. Going from one doc to the other is strange. I am not sure of splitting the document. [damien] imagine we don’t split the document. What about asking a thorough review of the document to say if yes or no the document lists all the risks and when we have the consensus, we propose the mitigations in the same document. Therefore, we can have an iterative process but at least we have a ground base and we can build up on strong basis. [ed] I agree with that. [ed] The document as it is restructured now makes a lot of sense. It is a much better document now. The new document is now good to include mitigations [ron] Yes, the structure of the document has greatly improved. [ron] Yes, I agree with the proposition you made. 1st we agree on the threats then we do the mitigations, and if we need to iterate, we iterate. If we do that all in the same document, that’s goodness. - LISP EID Block Management http://tools.ietf.org/html/draft-ietf-lisp-eid-block-mgmnt 5 min L. Iannone [luigi] Small update on management draft, this is the companion of the document asking to reserve an EID block at IANA. Several interactions last time. We just removed a small paragraph that was a repetition of another one. We also deleted a paragraph about a fee(?) policy as it is not the purpose of this document to do that A sentence about the reliability of the registration of the information where we say 99 dot something, we rephrased to be more neutral. Not much discussion so do we move it for WG last call and park it behind EID block? [brian] do you need to update this doc on something that could be in the intro document? [luigi] EID request has been updated just because of date issues [luigi] I don’t see any such thing [brian] be sure that the total experiment has been done. [darrel] for me what we say will not change anything. I don’t see any interaction. [chair] discuss on the mailing list o Non WG Documents - LISP OAM (Operation Administration Management) http://tools.ietf.org/html/draft-rodrigueznatal-lisp-oam-00 10 mins A. Cabellos [albert] Present a new draft the main idea is that when we were working on lisp use cases (e.g., multicast, troubleshooting, MPTCP) we realised that a bunch of things were not specific to one use case but common to all of them. Maybe we can try to understand those requirements and how they influence LISP and document them to see if maybe in the future we can extend LISP that way. The reasons why it is happening is that at the end LISP offers some control over the underlay (e.g., what is the reachablilty, what is the liveness, load balancing and control how the traffic steers on the underlay). But many underlay details are hidden to the LISP overlay. You don’t know any property about the path, you don’t know if the path is lossy, you don’t know what is the length, what is the topological location of proxies/xTRs/… We believe that some use case may require more information from the underlay. This document analyse that use cases and understand the requirements. We are not proposing anything else. It is just an analysis document. Now, let’s go to use cases. This use case has already been discussed in the WG, it is signal free multicast and replication engineering. Imagine you want to create a multicast tree. If you don’t have full underlay multicast support you can take advantage of RTRs to create a replication tree and to unicast replicated packets with LISP. In LISP RE we define this use case and create the machinery able to build such overlays but we needed to measure the latency and distance between RTRs, you also need to discover the RTRs that are available and what is their capacity. Finally you need to tell RTR they have to perform a certain action (here replicate packets). The conclusion is that we need discovery of xTRs, the capacity of xTR, ask xTR to perform some actions, be able to measure latency in the underlay. This other use case is on NFV. You want to steer traffic using LISP on several RTRs and you may want to apply different virtual network functions on each RTR. You need to discover the RTRs and their capabilities and ask them to apply given functions (e.g., firewall, DPI…). So you need to discover RTRs, discover their functions, and ask them to apply some functions In this use case has not been discussed in the WG but is very standard when troubleshooting LISP (or simply operate it). Imagine you have 2 PxTRs and first you need to discover them. For now on, you have to manually configure the xTR to use them, that would be good to automatically discover them and chose which one is better. Then let say that the path to the chosen xTR is lossy, you may want to be able to troubleshoot this information and react accordingly by choosing another PxTR. Or for instance, you want to reach this end host via the PxTR that is topologically closer to the end host. So again using information from the underlay to chose accordingly. In this case requirements are discovery of proxies and metric from the underlay. Here we described some of them, but of course it can be more than that (delay, loss, mtu, …). This use case has not been discussed in the WG neither and is related to MPTCP. Imagine that the host is single homed. In this case that doesn’t make much sense to use MPTCP but there are several disjoint paths between the ITR and the ETR, we could take advantage of MPTCP to use these disjoint paths by using the RTRs. The xTR could also be a proxy MPTCP which could create 3 subflows to use the 3 disjoint paths toward the destination. This xTR is also a proxy MPTCP or the node generates the sub flows. What the RTR has to do when it receives the sub flows is to load balance them. You need to discover the capabilities of the nodes, to measure the latency and distance to chose the xTR wisely, you may want to tell the RTR to load balance sub flows for this communication. Requirement here are discovery of xTR/RTRx, capabilities, load balancing and again the typical metrics. Summary: there are 3 phases: 1. discover devices and capabilities 2. discover information from the overlay (e.g., lentecy, MTU, loss, load and LISP state). This information should be available to some entity, maybe the mapping system 3. you want to tell LISP entities they should act differently depending on the traffic. [erik] I did not understand MPTCP case. On the example you have only equal cost. Do you only consider equal cost? [albert] here we are creating 3 MPTCP sub flows. This host is single homed. [erik] yes, I know that. Wait, they are not equal cost, sorry I didn’t see that. [erik] the RTR in this case is any existing router? [crowd] no, it is a LISP router [erik] ah, I haven’t payed enough attention, ok [erik] do you really need to proxy MPTCP as opposed to getting some way that MPTCP sets up several sub flows and then you can just load balanced based on usual hashing (source port here) [albert] if the host is MPTCP, someone has to tell him, or the XTR acts as a proxy and creates the sub flows [erik] yes but it would not work with SSL [erik] what if you just alway open multiple flows with MPTCP, no matter what, so you don’t need to proxy [albert] you can do that with the current implementation actually [darrel] it might be interesting to look at the full suite of possible information that you listed, even if it is not exhaustive, it is already a lot of things. In things that are deployed for experimentation we see that RLOC probing uses timestamping in the different implementations and that could be a first step to look based on that what are the types of things from your list that we can already do today. The latency you can get it for kind of for free (not the loss or capacity) and it might be interesting to start there. [albert] I agree, this is a kind of opportunistic approach and take advantage of metrics that xTR are already measuring so no need to do anything else but just access the information. [sharon] you said we don’t know much about the underlay. May know or may not know, depends on the RTRs for OAM we found that it is very practical is not to measure the latency, but the difference of latency to catch when the queue builds up cause you don’t want to lose packets. That’s one of the OAM aspect [albert] You mean the jitter? [sharon] when it changes [albert] the variability of the latency [sharon] you want to feel when queues build up before packet drops [albert] it is a good metric [sharon] RTR can use segment routing or multhoming and you can use that to measure the dynamics of the underlay [sharon] to your first presentation about internetworking you use proxies, in LVO3, they call that gateways so maybe you could add that terminology [albert] I think we should use the terminology that is in the RFCs because according to the charter we should try to make the main specifications easier to read. So using the same terminology is better. I do agree that saying as an analogy a PxTR is like a gateway. [sharon] regarding middleboxes or any network function. If it is done as in the traditional IP which is shelved in the xTR same box this is out of scope, this is the problem of the vendor. If it is in the underlay by the underlay, then it is the problem of the underlay. If it is on the outer lay instead of trying to explain the whole thing maybe just refer to SFC. Maybe merging SFF and xTR in the same box because you save hops but you can point to that because there is further studies. Same for MPTCP, this is another function, instead of trying to analyse it just say there is a function and that’s it. [sharon] about lisp intro people now talk about flows [chair] we are running out of time, discuss intro on the mailing list [ron] have you thought of the scaling characteristics of this mechanism? What if you have thousands xTRs? [albert] you mean in terms of discovering them? managing them? [ron] yes, both [albert] this document does not cover anything related to proposals but I don’t think that it would cause any issue to the mapping system that scales. At the end it is the same as SDN that people agree it scales [joel] let’s not go to that topic please [chair] we have to move on, we don’t have time - LISP Data-Plane Confidentiality http://tools.ietf.org/html/draft-farinacci-lisp-crypto 10 mins D. Farinacci [chair] Dino if you want you have 2 minutes [dino] ok [chair] sorry Darrel [dino] some chronology. We presented some of these ideas in the meeting in Vancouver fall last year. Joel recommended to go to SAAG to get some advice and put them early in the process as it is a security work. We did that and in spring we have our first -00 draft that we presented. I implemented -00 and updated slides based on implementation experience and comments we got. Quick overview. We do a diffie hellman exchange in the Map-Request Map-Reply exchange. Therefore keys are not stored by any third party. There is no private or public key stored anywhere in the system. They are just ephemeral keys. The ITR encrypts first then encaps, the ETR decaps then decrypts. Key can be part of RLOC probing so key can be changed continuously. I thought of showing you how my implementation functions. This is an ITR trace. A packet is received. Those are the EIDs, we do a lookup in the map cache, it is not found. We send a Map-Request. In the Map-Request we use the security LCAF and provide the DH parameters. The Map-Reply gives the parameters and the ITR can compute the ephemeral key. What we do is Encrypt then Encap, Decap then decrypt. This shows you the encryption it found the entry in the Map-Cache, there is a shared key. It used key-id 1 the key we negotiated, this is encrypted and voila. The ETR Can decrypt as it has the same shared key. Here are the changes in the specs. We added a group-id because it was requested in commentaries. The group-id was documented in various places. I put references in the spec. Please comment on the specs. There is a command about a bit in security type lcaf. That was used for DDT sec that we don’t use. I just added we don’t use it. We added text to say that ITR and ETR can negotiate less keys. If I want to negotiate 3 keys but the other 2 keys we go to the least common denominator We added text to explain how LISP sec solved the problem of MiM attacks during key exchange. We added text that RLOC probing is used for RLOC reachability tests but can also be used for rekeying. But when a key is already established you don’t want to rekey every time so if DH parameters do not change, we should not rekey. I added text that even though we use normal DH now, we could use elliptic curve DH to reduce CPU requirements. [chairs] we don’t have time for comments, mailing list please [brian weis] the document is not clear, is that passive attacker or active attacker. [dino] brian is in the acks as he helped a lot - LISP Generic Protocol Extension http://tools.ietf.org/html/draft-lewis-lisp-gpe 5 mins D. Lewis Cancelled [brian] This is not related to this document. [brian] consider this more as a gentle encouragement rather than me trying to be abusive but the plan that was lied down for the architecture and intro document is going to be very crucial for this WG going forward and at this point in time, I have to say that if this document doesn’t progress at the rate that is planned, then Honolulu may be the last time this WG meets. So I urge people participating in this wg to make sure they provided their comments and feedback to the document editors because they have been assigned to make the work done and they need your help to do it. [joel] the chairs apologies to the WG members for the pressure. It is our fault [darrel] come on we do that WG after WG [joel] the chairs should have pushed sooner and fixed it. It is primarily our fault and almost completely. It is my personal fault I blew it. I am sorry, but if we want it to work, we have to work. [dino] to Brian and put this on the record. We will work hard to have it to work but when we will give it to you ADs, you better do your part and push it as well because you created a deadline for us that was unnecessary. [brian] I only speak for 1/15th of the IESG. My working style for the past 2 + years is that if the WG gives me a document that is a consensus document and that the consensus is observable, then I am more than happy to take it forward. I can not speak for the other 14 ADs [dino] (I can’t hear what he says) [joel] he will do his job [brian] the only reason I am pushing on this is because when this charter was put, the WG agreed to a set of deadlines in the milestones that were rather agressive and it did not go anywhere. That is a sign of unproductively. [crowd] (can’t understand too many people at the same time) [brian] NVO3 is not my working group. Feel free to talk to any of my other working groups. I have done the same thing to them [dino] you will close the WG for a single document problem? [joel] and did not fix it [brian] yes, and did not fix it [fabio] please put on the record. I was on a WG this morning at 9 am and the about in the same time frame I have not seen a single RFC coming out of this WG and I haven’t seen such a drastic action and have seen WG talking about re-chartering. I have noted in this group we have delivered 2 RFCs in the same time frame we have walked our ass off thanks to the work of people in the room and in the list, on the threat analysis how many message you got in the last couple of months. I have seen activity in this group. Clearly the introduction document is a deliverable and we have a planing for it. [brian] just to make sure I was not misinterpreted I just want to see progress I am not saying it has to be done for Honolulu I want to see active progress. [crowd] (seems Dino say something like it will be done for Honolulu) [brian] that would be great [brian] and the nice thing is that once this document goes forward there is already one document sitting in the queue waiting for this one to go forward. [Terry] in haiku form: "The LISP working group Toronto now at an end next in Hawaii"