Minutes for LISP at IETF-88
minutes-88-lisp-1

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]
=================================================