CHAIR(s): Joel Halpern ( jmh AT joelhalpern.com ) Terry Manderson ( Terry.Manderson AT icann.org ) SECRETARY: Wassim Haddad ( wassim.haddad AT ericsson.com ) Luigi Iannone ( luigi.iannone AT telecom-paristech.fr ) 9:00-11:30 Thursday 7th November 2013. Session 1/1 (150 min) ================================================= Note Takers: Luigi Iannone, Wassim Haddad, and Damien Saucez Jabber scriber: Luigi Iannone Note Well! Agenda bashing http://tools.ietf.org/wg/lisp/agenda?item=agenda-88-lisp.html Chairs' Slides http://www.ietf.org/proceedings/88/slides/slides-88-lisp-0.pptx ================================================= - Interim meeting - Status reports for WG drafts o Deployment & MIB - WG Draft updates o draft-ietf-lisp-introduction o draft-ietf-lisp-threats-08 o drat-ietf-lisp-eid-block-06 o draft-iannone-eid-block-mgmnt-03 - Other related items and Drafts o draft-brockners-lisp-sr-00.txt o draft-arango-pim-join-attributes-for-lisp-00 o draft-lewis-lisp-gpe-01 o draft-barkai-lisp-nfv-02 o draft-maino-nvo3-lisp-cp-03 - AOB (time permitting) o Secure data-plane for LISP o dino-atl-lisp-future No Agenda Change Proposed. ================================================= - Interim meeting Report (Terry Manderson) ================================================= No Specific Comments - Status reports for WG drafts o Deployment & MIB ================================================= MIB passed as RFC 7052 http://www.rfc-editor.org/rfc/rfc7052.txt Deployement (by Wassim Haddad as shepherd of the document) http://tools.ietf.org/html/draft-ietf-lisp-deployment-10 Wassim Haddad => Updated document, to solve remaining issues, should come before the end of the week. draft-ietf-lisp-introduction (Darrel Lewis) Document: http://tools.ietf.org/html/draft-ietf-lisp-introduction-03 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-9.pptx ================================================= Joel Halpern => The term indexing subsystem is taken from another place in the base document. Sometimes, Noel Chiappa had to introduce new terms, but if you folks believe is there any inconsistency, please send an email. Fabio Maino => In the interim meeting there was consensus, but is good to extend the discussion to the WG. Fabio Maino => Next steps were also discussed at the interim meeting. People were fine leaving the document as it is. The problem splitting the document in two parts is about what to do with the second part, which is not stand-alone. There was the suggestion to incorporate the second part in the perspective document, on which Noel is also working. Personally, and considering the charter of the WG, part one, with some minor addition looks sufficient to fulfill what is in the scope of the charter. Would be interesting to hear from the mailinglist what are people's thoughts. For me we are very close (especially with the next version -04 of the draft) to what is in the charter. Joel Halpern => I am confused. I thought we discussed this on the mailing list, agreeing on putting part two in the introduction document. We can re-open the discussion, but I think that was done. Fabio Maino => If you thing there is agreement then we can move forward. Ed Lopez => I was also attending the interim meeting and the conclusion was to keep the two parts in one document. The argument about splitting the document came from the length of the document. It wasn't a compelling argument. Terry Manderson => Can people that have read version 03 of the document raise their hand? A dozen hands raised in the room. Terry Manderson => My understanding on the discussion is as well that both parts will be in the document. Dino Farinacci => I remember Noel agreeing with what you just said and putting text at the beginning of part one of the document stating that if the reader wants more details then there is part two. So, the intention of Noel is to keep both parts in the document. Terry Manderson => Next steps? Darrel Lewis => Is close. Terry Manderson => Is close enough for WG Last Call? Fabio Maino => Yes it is. Terry Manderson => Show hands if you think this document is ready for WG Last Call. Matthew ???? => Why the document is not in RFC format? Joel Halpern => RFC Editor will check the document format. Terry Manderson => Show hands who thinks this document is not ready for WG last call. No hands showing up. [Rough consensus on document ready for WG Last Call] Terry Manderson => OK, we will do an official Last Call from the mailinglist. draft-ietf-lisp-threats (Damien Saucez) Document: http://tools.ietf.org/html/draft-ietf-lisp-threats-08 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-1.pdf ================================================= Terry Manderson => How many people have read this document? Around 7 persons raised the hand. Terry Manderson => Show hands for people that think this document is ready for WG Last Call? [Substantial number of hands raised] Terry Manderson => Show hands for people that think this document is not ready for WG Last Call? [No hands raised] [Rough consensus for WG Last Call] Terry Manderson => OK, we will take the Last Call on the list. draft-ietf-lisp-eid-block (Luigi Iannone) Document: http://tools.ietf.org/html/draft-ietf-lisp-eid-block-06 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-2.pdf ================================================= Brian Haberman => In my AD role, the thought of moving to a 3 years allocation reduces my concerns about this allocation, and the fact of reducing the size to a /32 make it even better, because we are now in the same range like other experimental allocations like ORCHID (RFC 4843). This is a more reasonable approach than a /16 for 10+ years, and the fact that you are willing to move forward the text that states that any permanent allocation needs discussion among the different communities that have an interest here is a reasonable approach. Kaveh Ranjbar => Referring to slide 6 and the previous comment, why do you think that discussion for permanent allocation will occur only between 2017 and 2020? Whatever you ask to IANA, the other stakeholder will want to say something on that. Luigi Iannone => You are free to talk about the EDI block, but let's have the block now, let's experiment for three years, then if we keep the block we need to have a formal discussion on what will be the permanent allocation and how will be managed. Formally this has to happen in the second period, but nothing prevents IANA, IETF, and RIRs to discuss before. This is just to put a formal timeframe where official work is done. Kaveh Ranjbar => I just think that January 2014 is when IANA and RIRs and other stakeholders should start to discuss. Geoff Huston => As one that put some objection on the mailinglist, moving to an experimental allocation of a /32 seems to me perfectly acceptable, within what seems to be a special allocation for the purpose of experimentation. As I said on the mailinglist in response to Dino's comment "is all about size", to me it is all about the size. A /32 sits in the boundaries of what I have always understood is an experimental allocation. This is the size I am perfectly confortable with. I appreciate the work done on the mailinglist and meetings, I just re-iterate what I have already stated. Brian Haberman => Last comment raises another issue. The discussion that will take place among IETF, IANA, and RIRs will probably end up in this block being in a different range, so do not hardcode this range. Luigi Iannone => In the document we already say not to hardcode. However, if we change the document for a /32, we have to clearly spell out that final allocation might be in a totally different range. Brian Haberman => The second part is that I want that everybody using this range understands that, depending on how you advertise it in the routing system, it may incur in some other pain like 6to4 relay routers get because they advertise the wrong size block. Be prepared to see weird traffic patterns if you advertise this in BGP. Dino Farinacci => So let's not advertise it. Brian Haberman => Ok. Luigi Iannone => It is already in the document that is not meant to be natively injected in the BGP routing infrastructure. Is only done through proxy xTRs and is clear that people cannot get a chuck of the prefix and freely inject it in the BGP table. Dino Farinacci => Even so, Brian is right. Luigi Iannone => Agreed. David Conrad => I do not really care about the size of the block, whatever works for the folks that will use it in the experiment is ok, however, having said that, I have to admit some confusing about the size of the block. In RFC 7020, we went saying that the conservation depends on the available free pool, so given the size of the IPv6 free pool it does not make sense to me to be overly conservative about the size of the block to be used according to RFC 2860 for experimentation. Whatever works, to me the size of the block should not be a significant concern. Terry Manderson => It seems that there is a general agreement that going for 3+3 plan looks a good and sensible idea, so can people that do not agree with this idea show their hands? [No hands raised] Terry Manderson => Now who thinks is a good idea? [Substantial number of hands raised] [Rough consensus on using the 3+3 plan] Terry Manderson => About the size, for which in this case I do not really care about the specific size, like David Conrad's comment. People who do not believe a /32 is appropriate can raise their hands? [No hands raised] Terry Manderson => Now people who think a /32 is appropriate, please raise your hand. [Substantial number of hands raised] [Rough consensus in asking the allocation of a /32] Terry Manderson => You think the document is close to go for WG Last Call? Luigi Iannone => If we update the document with the /32 prefix I think we are close to WG Last Call. Terry Manderson => Based on the premise that as a WG we just decided on the technical details of the document, who think that this document is ready for WG Last Call? Please raise your hand. [Substantial number of hands raised] Terry Manderson => Who think that this is not ready for WG Last Call? Please raise your hand. [No hands raised] [Rough consensus on document ready for WG Last Call] Terry Manderson => OK, we will move for WG Last Call on the mailinglist. draft-ietf-iannone-lisp-eid-block-mgmnt (Luigi Iannone) Document: http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-3.pdf ================================================= Geoff Huston => Concerning the /48 minimum allocation, is there a specific LISP issue related to this minimum allocation? The current practice of RIRs is that the default allocation size is a /56. If you are bigger than normal (whatever normal means) then you can make a case to go larger. If you need a bigger default allocation for LISP please state so. Luigi Iannone => There was no specific technical reason for /48, so moving to a /56 is not a problem at all for me. Geoff Huston => So I suggest you consider to put /56 in the document. Terry Manderson => As an individual. I do not see a reason for any minimum allocation whatsoever. You may structure a guideline as to what might be, but certainly you can do way smaller if you so choose. Terry Manderson => As an individual. Question about reverse DNS: why? Luigi Iannone => Just to have information on who is using the block. Terry Manderson => As an individual. I do not see value in this. Luigi Iannone => Who we do look up who is using the prefix? Terry Manderson => As an individual. Who is using the chunk comes from the registry structure you created in the document. Luigi Iannone => Fine to me if you think is not necessary. Darrel Lewis => I echo Terry's comment. I do not see any reason for a minimum allocation. Erik Nordmark => The reason why we use minimum allocation is to allow sub-netting. Here the space can be flat, unless you use it to provide sub-allocation, so it could be any size. David Conrad => A lot of equipment out there assume a /64 allocation for SLAAC and that sort of things. Is that useful, necessary, or even a point within the context of LISP? When writing the document we put /48 because we thought is the current agreement in within the context of the IETF. In the context of LISP, if there is no requirement like SLAAC then "no minimum" is the right answer. Luigi Iannone => To move forward, we can delete the requirement of a minimum allocation, but add that when we ask for an allocation we must justify the size we are asking. David Conrad => The question of the reverse DNS is an ongoing battle within the operational community on whether or not has any point, at least for IPv6. The reason why it is in the document is because these arguments have not been solved, to be prepared for at least part of the community that believes that reverse delegation has value. Geoff Huston => I think reverse delegation in IPv6 is something bizarre. If we can get rid of this piece of the architecture let's do it. Get rid of bullet 7 since does not seem to serve any purpose. But we do not need to change several things at the same time, so, if everybody uses it then keep it, but there is no real need. Dino Farinacci => You can even want /120, because people will walk around with their own subnetwork of sensors, they will change locator at the same time, so /120 looks like a good aggregation point. Luigi Iannone => That might be too small. There are documents suggesting using one IPv6 address per application, hence 256 addresses would not be sufficient to cover all the needs. But I am diverging, this is not the point right now. Ed Lopez => I agree with Terry concerning the reverse DNS, it is painful. Concerning the minimum allocation, if we were talking about requesting a /16 EID block, nobody would argument the /48, but since we are requesting a /32 it now becomes a problem. When we go from temporary to permanent, this could be another point to re-address. Luigi Iannone => To sum up the discussion: no minimum allocation and apparently not much support for reverse DNS. Terry Manderson => This document is tightly related to the previous one, and it makes sense to move them forward together. Does the WG believe this document should be WG document? Please show hands [Substantial number of hands raised] Terry Manderson => There is people that believe it should not be WG document? [No hands raised] [Rough consensus to adopt the document as WG item] Terry Manderson => Who has read this document? [Around 16 raised hands] Terry Manderson => Will get to the list to confirm WG document adoption. draft-brockners-lisp-sr (Swetha Bhandari) Document: http://tools.ietf.org/html/draft-brockners-lisp-sr-00 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-4.pdf ================================================= Joel Halpern => If this is a good idea, as it seems to be, there is no reason to integrate this in the LCAF draft. We can put an entry in the registry. Joel Halpern => I am missing something in the problem or solution space. The LISP mapping system does not have any dynamic topology knowledge, while the use case you describe looks like you want to probe the underlying network, so the segment route is driven by the knowledge of the underlay topology and that would not work. If the segment route depends on abstract policies, that would work and we need to describe how it would work. But if it depends on the underlay topology I am concerned that this would couple things that are not supposed to be coupled. Swetha Bhandari => I am stating that the policies of the control elements should not drive the mapping system but rather drive the segment points directly. Joel Halpern => Things which know the underlay topology should use the underlay topology elements, things that are about abstract overlay behavior should use the overlay. Dino Farinacci => You are proposing to use the ELP type 10 LCAF, so there is no need to change the document or use the registry, because ELP has a list of AFI, so if you already went to have an AFI for segment routing it works as it is. Dino Farinacci => For the second question is how dynamic is the situation and there is any setup to be done? If a packet reaches an RTR, you do a an database lookup and may be you have an RLOC or an ELP back because you want to encapsulate into another segment, but this segment underlay wants to do some TE via segment routing. In this case do I need to setup something ahead of time? Because if so there will be this registration process to register that information that when I use the RLOC to send traffic to you there is also some underlay stuff to be done. Is this registration ahead of time done by policies or there is a circuit setup? Swetha Bhandari => Is the former, I do not think there will be a circuit setup required. Joel Halpern => Circuit setup is not the issue here. Dino Farinacci => Well with MPLS tunneling there is a circuit setup. Joel Halpern => The way it is done in the SPRING group there is no circuit setup for segment routing. Darrel Lewis => As co-author I have two comments. There is no reason to tie this to ELP. The two may co-exist but I do not see reasons to re-use the ELP type. Dino Farinacci => If you use an AFI it can go anywhere. Darrel Lewis => Want to clarify that there is no coupling here. Darrel Lewis => The second point is about why is this underlay information going in the overlay and what is the impact in the mapping system when that coupling happens? The idea spurred from the case when you deploy LISP over an underlay different from the global routing system with aggregated addresses, like for instance an MPLS-VPN. When you have non-aggregated addresses specifying PCE links, we see benefits in our experimentation. On of these benefits comes in the form of locator liveness, because if I have an explicit route for a locator, without aggregation, and that route goes away, I know right away that the locator is not reachable without the need of doing probing. Joel Halpern => This needs to be explained in the draft. Darrel Lewis => Sure, we will include the feedback. The principle that is coming out here is that, at the cost of some scalability of the mapping system, the more you know about the underlay the more you can do things with it, like the locator liveness example. We will make sure this is clear in the draft going forward. Erik Nordmark => My understanding of the mapping system was that is origin independent and is driven by the destination and the reachability of its locators. This problem looks useful, but also that needs to be source dependent, so I do not see how the mapping system in itself can do this. Joel Halpern => By the way, by spec, the queries are not coming from the mapping system, rather from the ITR that has no idea of the underlay near the ETR. Darrel Lewis => According to Noel's terminology in the intro document, the mapping system is distributed among the ITRs, the indexing system and their interface, so the ITRs are the mapping system. But there is a valid point the Erik is bringing up, and the document needs to be clear on that, there has always been the idea that there can be individual replies to a map-requests, depending on some set of policies applied to the content of the map-request. What is happening here is that the map-request needs to include some source topology information to provide information to the ETR that is responding. Joel Halpern => As I asked on the mailinglist and never had an answer: a lot of these LCAFs depend on assumptions about ITRs and mapping system, assuming one single mapping system. If there is the need of some pre-configuration we need to say that at least. Darrel Lewis => In practice this is certainly done by pre-configuration of which mapping system to use depending on the virtual component on the ITRs. We should say that. Dino Farinacci => Does a segment route has reachability status? This could exacerbate the RLOC probing problem, because an RLOC can have several segment routes to it, we are actually creating another level of indirection, you need to probe through which segment the RLOC is reachable. There might be a scalability issue, making the already challenging RLOC probing problem even worse. If the segment routing underlay has the capability to tell whether an RLOC is reachable through it depending on the source, then there is no scalability issue. It is what it does? Darrel Lewis => Yes. Matsuzaki Yoshinobu => Is there any risk of traffic amplification? Because this looks like the problem routing header type zero used to have. Swetha Bhandari => The way that could happen in segment routing has yet to be defined. Joel Halpern => The SPRING charter states that they will look at when it is safe to use segment routing and make sure they will not work when they shouldn't. Darrel Lewis => We are not adding any additional requirement to segment routing, we are just using what segment routing is providing us. Terry Manderson => The feedback to take is that "no you do not need to put this in the LCAF" and that there are few clarification points. draft-arango-pim-join-attributes-for-lisp (Darrel Lewis) Document: http://tools.ietf.org/html/draft-arango-pim-join-attributes-for-lisp-00 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-5.pptx ================================================= Hao Weiguo => How can you solve the multi-homing scenario? Darrel Lewis => An ITR for a given flow will pick only a given destination. So the attributes for multi-homing in the LISP encapsulation do not really apply here. Dino Farinacci => The question relates more to the machinery described in RFC 6831. In that document we state that we should encapsulate multicast in multicast, but in the TE draft and the RE draft we say that we can use unicast encapsulation of multicast packet, so when an ETR joins an ITR with a unicast RLCO has to clearly say that is an alternative not a replication. There is some text in the RE draft but we have to make it more clear. Darrel Lewis => Yes, to separate encapsulation from replication. Dino Farinacci => Please bring it to the mailinglist. Stig Venaas => Speaking as PIM WG Chair, we had to make sure that this work is useful. Is it useful? Terry Manderson => The question to the WG is: do people believe this work done in the PIM WG is useful? Please raise hands. [Substantial number of hands raised] Terry Manderson => If you do not think is useful, please raise your hand. [No hands raised] Terry Manderson => The WG thinks it is useful. Stig Venaas => Thanks, so this will be discussed in the PIM WG tomorrow. draft-lewis-lisp-gpe (Darrel Lewis) Document: http://tools.ietf.org/html/draft-lewis-lisp-gpe-01 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-6.pptx ================================================= Joel Halpern => Can you describe the difference between this draft and the draft Yong? [http://tools.ietf.org/id/draft-yong-nvo3-nve-01.txt] Darrel Lewis => The draft Yong proposes changes to VxLAN and NVGRE. The VxLAN changes are very similar to this proposal or the Quinn proposal. The difference lays in the fact that Yong just proposes a protocol field, while this proposal and Quinn sets the field with a bit. So they are one bit apart. Dino Farinacci => I hope we can avoid putting encapsulation types in the database, because VxLAN has an old port number and a new port number, then there is a P bit in the header, so has LISP, and you do not know what the destination ETR is going to support. I hope the industry will jump on this new stuff sooner rather then later. Like broadcom that does have a programmable port number but not a P bit. I hope it does not come back to hunt us, where when you lookup for an EID you obtain an RLOC and also the list of encapsulation that it supports. Darrel Lewis => I do not want to go down that path with LISP. There is a back-compatibility section in the LISP draft with the details. In short we want that unmodified ETR that do not support the P-bit are able to decapsulate LISP packets sent from ITRs that do support the P-bit. So we plan for this two-step compatibility but we expect people to move this way forward. Luigi Iannone => Why replacing the Nonce/Version part of the LISP header, getting rid of 3 features of LISP? While using the Locator-Status-Bits you could have lost only one? Darrel Lewis => Based on our implementation experience we found great value in the Locator-Status-Bits and less in Nonce/Echo-Nonce/Versioning, so we decided for this trade-off. Terry Manderson => Keep working on this, there is need for more discussion. How many people have read this document? [Substantial number of hands raised] Terry Manderson => We can continue the discussion on the LISP mailinglist. For the working group document we would need to re-charter because you are proposing a change to the LISP header format. Dino Farinacci => Has this been presented in the NVO3 WG? Fabio Maino => There has been a similar presentation with an explicit reference to LISP. draft-barkai-lisp-nfv (Sharon Barkai) Document: http://tools.ietf.org/html/draft-barkai-lisp-nfv-02 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-7.pdf ================================================= Matsuzaki Yoshinobu => In your slides, LISP is for overlay topology while segment routing is for underlay topology, so is LISP used to establish underlay paths? Is it how is implemented in OpenDayLight? Sharon Barkai => In OpenDayLight you can populate the mapping system with outerlay information, which means which function are were and derive that for orchestration, and also which functions what. The underlay awareness segments are policies based landmarks steering of traffic, but that has not been yet inserted in OpenDayLight. Sharon Barkai => Could this document be considered to become WG document? Terry Manderson => I have to discuss with my co-chair before getting back to you. draft-maino-nvo3-lisp-cp (Fabio Maino) Document: http://tools.ietf.org/html/draft-maino-nvo3-lisp-cp-03 Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-10.pdf ================================================= Fabio Maino => No specific request, just an update on what we are doing in NVO3. Protecting encapsulation with encryption (Dino Farinacci) Document: No existing draft Slides: http://www.ietf.org/proceedings/88/slides/slides-88-lisp-8.pdf ================================================= Joel Halpern => When you are talking about this I would not say "pass the security key" but rather "pass the key material" there are lots of tools to derive the actual traffic key without passing directly the key. Joel Halpern => You do not need to encrypt the map-reply, if you use one of the tools of the security guys. The problem you are describing is hard but there are easy ways to solve it. Joel Halpern => The one time key from the ITR is not actually protected during its flow in the mapping system, and if we use a technique that does not require the protection we do not need to invent the protection in all those other hops. That's why I am trying to simplify things here. There are very simple security tools that allow to derive keys when there is a message exchange already in place just adding some extra data. The fact that that data is unprotected does not matter. Just work with the security guys. Just need to state "we have this message exchange can you help us to secure the tunnel?" Dino Farinacci => Yes, I am indeed going to present this in the SAAG WG. Ed Lopez => The message in this presentation is how to take advantage of the LISP infrastructure, not on whether or not we are going to use the mapping system, or lisp-sec. Joel Halpern => My concern is that we are creating needless complexity. Ed Lopez => Understood that we have to segregate what we do from what is outside the scope. Brian Weis => In lisp-sec you are passing around a one-time key (OTK), I hope it is protected sufficiently for its purposes. Joel Halpern => For its purpose it is sufficiently protected, even if the security material is not protected. By the way that draft needs security review. Ed Lopez => I agree with Brian, on the fact that there is a little scope creep in the OTK in lisp-sec and that needs to be explored. Terry Manderson => I would like to see the question raised on the mailinglist about where this key material should be placed and where the exchange should happen. Please raise the question on the mailinglist. Dino Farinacci => Do you mean the security mailinglist? Terry Manderson => Yes, you should. Brian Weis => It is way too early to bring this to the SAAG WG. It will raise a lot of questions. Joel Halpern => That is why I am saying that the message should be asking for help, not about the details presented here. Brian Weis => Showing these slides you will not get the outcome you are looking for. Brian Weis => Getting back to over-engineering and complexity, you can put something together that looks like providing some level of protection, but there is a difference between that and a high quality one. Brian Weis => What is really the goal of this? This would work against passive attackers, who are doing surveillance only. But would not be safe against active attackers. If you can claim that the control plane is protected from surveillance, because for instance lisp-sec is sufficiently protected, then you can have session keys that protect the data plane from surveillance. That could be a nice thing, but need to see where the quality is. We are talking about things like this a lot this week in the security area, things like opportunistic security, which can protect against surveillance but is weak against active attackers. So the main message here is to look at this as anti-surveillance method. Darrel Lewis =>Cost is not only the complexity of the protocol. It is also the fragility of the system. We know that availability suffers in encrypted environment because they are more CPU intensive and easier to DoS. The benefits are not coming only from the complexity of the system but also from its overall robustness. Luigi Iannone => There is some design space to explore. Maybe you don't want confidentiality but only source authentication, so you can just sign the packet and avoid encrypt it, if this satisfies your security requirements. Luigi Iannone => How many keys? per EID? Per RLOC? What security level is given there? IMO there is a trade-off to explore. And I definitely want to see the draft. Dino Farinacci => There will be at least one key per RLOC, or, as Brian suggested, multiple keys so that you can roll them. The mapping system can manage key change easily because it looks just like a mobility event. The question is what to do with packet arriving with an old key after the mapping has changed. That is why Brian was suggesting a key-ID field. Ed Lopez => The point of encrypting everything for confidentiality leads the question of: is there anything in the EID space that should be known at the RLOC space ? Is there any leakage? Dino Farinacci => Do you mean if there is anything from the payload? Ed Lopez => No, from the EID header and back. Dino Farinacci => While discussing on this with Fabio, we decided not to encrypt the UDP header because you use it for load balancing in the core and you do not want to decrypt the LISP header to read its content. Keep those clear seems to be harmless. Joel Halpern => You need the LISP header to tell you whether or not the rest is encrypted, so you need the LISP header in the clear. Dino Farinacci => Yes, and Joel made the comment that we may need to allocate one of the three remaining reserved bits to say whether the content is encrypted. Brian Weis => There is a difference between what you encrypt and what you integrity protect. : and anyway we have to know what is in the packet! Dino Farinacci =>Do we have to add integrity check? Do existing mechanism sufficient to provide both confidentiality and integrity or we need something more? Brian Weis => Today we always consider confidentiality and integrity together. Terry Manderson => Please send questions to list, and make sure to cc security to ask where the security material should go, whether or not use opportunistic. Security is in the charter, so we do not need to re-charter to work on this item, but please write the draft in concert with security people. [Session closed] =================================================