Re: [lisp] Moving draft-ietf-lisp-name-encoding to standard track?

[Fabio Maino (fmaino)]

I support moving this document to standard track

Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Thursday, January 11, 2024 at 4:53 AM
To: LISP mailing list list 
Cc: lisp-cha...@ietf.org 
Subject: [lisp] Moving draft-ietf-lisp-name-encoding to standard track?
Hi All,

Happy new year!

As you may have seen from Alberto’s shepherd review of the name encoding 
document, it is suggested to move the document to standard track.

Jim Guichard (our AD) is OK as long as the WG is OK with this change and that 
deployment experience is added to the document.

Hence, this email opens a two weeks call to check if you agree with the change.

Please reply to this email stating whether you are in favor or you are against.
(Silence does not count)

Please reply.

Ciao

L.




Begin forwarded message:

From: "Alberto Rodriguez-Natal \(natal\)" 
Subject: [lisp] Shepherd's review of draft-ietf-lisp-name-encoding
Date: December 28, 2023 at 12:00:33 GMT+1
To: "lisp@ietf.org" 

Hi all,

The shepherd’s review of the LISP Distinguished Name Encoding has been posted. 
The document is in good shape and minor identified nits have been fixed. Please 
find the review here:

https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/shepherdwriteup/

However, as part of the review, it was raised the question if the document is 
in the right stream (currently in Experimental). Given that there are known 
implementations of the spec and that it has been running in production for some 
time, my suggestion is to consider moving this document to Standards track 
instead.

Thanks,
Alberto
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished

[Fabio Maino (fmaino)]

Dino, 
Back then Albert Lopez, Vina and others invested quite some time addressing in 
draft-ermagan-lisp-nat-traversal a lot of corner cases that were coming from 
mobiity. 

Before we move forward with a NAT document we should make sure we either 
explicitly leave out those use cases, or address them. 

Thanks,
Fabio

On 3/21/23, 12:37 PM, "lisp on behalf of Dino Farinacci" 
mailto:lisp-boun...@ietf.org> on behalf of 
farina...@gmail.com > wrote:


draft-farinacci-lisp-lispers-net-nat proposes an implemented solution for the 
problem.


Dino


> On Mar 21, 2023, at 6:25 AM, Albert López  > wrote:
> 
> On 14/3/23 10:46, Luigi Iannone wrote:
>> LISP NAT Traversal: we have a candidate document
> 
> Here we have the problem of handovers between RTRs. Some time ago I proposed 
> a possible solution but I believe we need to think a little more to find a 
> more optimal solution.
> Albert López
> 
> ___
> lisp mailing list
> lisp@ietf.org 
> https://www.ietf.org/mailman/listinfo/lisp 
> 


___
lisp mailing list
lisp@ietf.org 
https://www.ietf.org/mailman/listinfo/lisp 




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Supporting lisp-geo [Was: Re: lisp - Requested session has been scheduled for IETF 115]

[Fabio Maino (fmaino)]

Chairs, 
I would like to support Dino's request for WG adoption of 
https://datatracker.ietf.org/doc/draft-farinacci-lisp-geo/. 

It's a well written document that defines the Geo-coordinate LCAF type. The 
draft brings up a couple of good use cases that illustrates how the LCAF type 
would be used. 

It's a fairly simple document, and I can't think of anything that I would do 
differently. I'm also supportive of getting this to last call as soon as IETF 
procedure allows. 

Thanks,
Fabio 

On 10/15/22, 10:37 AM, "lisp on behalf of Dino Farinacci" 
 wrote:

And I would like to request WG document for draft-farinacci-lisp-geo again. 
It has been around for a long time and has an LCAF encoding code point in RFC 
8060. I can present this draft too in London. 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP Specifications Published!! :-)

[Fabio Maino (fmaino)]

Now it’s time to pull the Prosecco!

Thanks and congratulations to all those that have made this possible…

Fabio

From: lisp  on behalf of Dino Farinacci 

Date: Thursday, October 20, 2022 at 2:43 PM
To: Alvaro Retana 
Cc: "lisp@ietf.org list" 
Subject: Re: [lisp] LISP Specifications Published!! :-)

Phew I am exhausted. LOL.

Thank you to the 100s of people who contributed to the requirements, design, 
implementation, documentation, and deployment of these set of standards.

Dino


On Oct 20, 2022, at 2:34 PM, Alvaro Retana  wrote:
FYI

The RFC Editor just published the group of 8 RFCs that include the base 
specifications! :-)

RFC9299 through RFC9306

Thank you for all the hard work and congratulations!!!

Alvaro.

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call: draft-ietf-lisp-name-encoding-00.txt

[Fabio Maino (fmaino)]

I support handing this document over to the AD.

Encoding Distinguished Names in LISP is a simple but important feature, and the 
document does a very good job of articulating how it should be done providing a 
few good examples of why is relevant.

Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Wednesday, September 28, 2022 at 6:46 AM
To: Dino Farinacci , "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: [lisp] WG Last Call: draft-ietf-lisp-name-encoding-00.txt

Hi All,

As you can see from the email exchange Dino asked for Working Group Last Call 
for  draft-ietf-lisp-name-encoding-00.txt

This email open the usual two weeks Working Group Last Call, to end October 
14th, 2022.

Please review!

Let the WG know if you agree that it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it 
would take to address your concerns.

NOTE: silence IS NOT consensus! Please review!

Thanks



On 6 Sep 2022, at 17:52, Dino Farinacci 
mailto:farina...@gmail.com>> wrote:

I would like to request WG last call on this document.

Dino


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lisp-name-encoding-00.txt
Date: September 6, 2022 at 4:31:12 AM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lisp@ietf.org
Reply-To: internet-dra...@ietf.org, 
lisp@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.

   Title   : LISP Distinguished Name Encoding
   Author  : Dino Farinacci
 Filename: draft-ietf-lisp-name-encoding-00.txt
 Pages   : 8
 Date: 2022-09-05

Abstract:
  This draft defines how to use the AFI=17 Distinguished Names in LISP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-name-encoding/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-name-encoding-00


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] New lisp WG Co-Chair

[Fabio Maino (fmaino)]

Joel, thanks for the steady guidance and strong support you have provided to 
the WG over the years. I can think of so many reasons why we really wouldn't be 
where we are without your help. Good luck with whatever is your next challenge 
at the IETF.

Padma, congratulations and welcome in your new role, and thanks for the work 
done over the years as WG secretary. I'm really looking forward to work with 
you, Deborah, Luigi and the whole WG to bring home the RFCs and continue the 
evolution of LISP.


Fabio

On 8/18/22, 9:52 AM, "lisp on behalf of Dino Farinacci"  wrote:

And we can’t discard the team player you were Deborah in supporting them!

Thanks to you too. 

Dino

> On Aug 18, 2022, at 6:51 AM, BRUNGARD, DEBORAH A  wrote:
> 
> +1 on Dino's sincere words - Joel and Luigi were instrumental in guiding 
LISP to where it is today as a standards track working group!
> All the best Joel!
> Welcome Padma!
> 
> Deborah
> 
> 
> -Original Message-
> From: lisp  On Behalf Of Dino Farinacci
> Sent: Wednesday, August 17, 2022 5:57 PM
> To: Alvaro Retana 
> Cc: lisp@ietf.org list 
> Subject: Re: [lisp] New lisp WG Co-Chair
> 
> I'd like to say a few words about Joel. 
> 
> Not only did he run this WG for quite a long time, he was also involved 
in the Routing Research Group (as was Luigi) and started a lot of the seed 
ideas for LISP. I have worked with Joel for many decades and his ability to 
spot architecture bugs and issues is unique and makes him one of a kind. His 
expertise will be missed but I gather he will still be involved technically.
> 
> I want to say, on behalf of the original LISP authors, a huge thank you 
Joel for your huge contributions. I think the protocol and its deployments are 
better off because of your consultation and effort.
> 
> Appreciative,
> Dino
> 
>> On Aug 17, 2022, at 2:42 PM, Alvaro Retana  
wrote:
>> 
>> Dear lisp WG:
>> 
>> Joel has decided to step down as lisp Co-Chair.   For the last 12+
>> years, he has been instrumental in the focus of the WG, including
>> bringing the updated Standards Track specifications to publication
>> (which we expect anytime!).  Joel: thank you for all the time and
>> effort you have put into the WG; we all look forward to your continued
>> contributions to the IETF!
>> 
>> In consultation with Luigi and the other ADs, we have asked Padma
>> Pillay-Esnault to take on the role of lisp Co-Chair.  As you know,
>> Padma has served as the WG's Secretary since 2017.  In addition, she
>> has been an active IETF contributor for many years.  Welcome Padma!
>> 
>> This change is effective immediately.
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lisp__;!!BhdT!m6eMzIsJkPrQVPhjYY_YWdzYl48H-J5Wn5uKluz1b-_3oCSWw97UPuyDvES-5IHLRukeIwPCd6AyjNXT$
  
> 
> ___
> lisp mailing list
> lisp@ietf.org
> 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lisp__;!!BhdT!m6eMzIsJkPrQVPhjYY_YWdzYl48H-J5Wn5uKluz1b-_3oCSWw97UPuyDvES-5IHLRukeIwPCd6AyjNXT$
  

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] AD Review of draft-ietf-lisp-sec-25

[Fabio Maino (fmaino)]

Thanks Alvaro, 
I believe Damien and Luigi are already taking a first pass. 

After a quick review between the authors, we should be able to return it back 
to you. 

Fabio 

On 4/28/22, 9:17 AM, "Alvaro Retana"  wrote:

Hi!

I'm just moving this message up in people's mailer to make sure everyone
saw it.

If you’re already working in it, sorry for the interruption.

Alvaro.

On April 21, 2022 at 3:27:18 PM, Alvaro Retana (aretana.i...@gmail.com)
wrote:


Dear authors:

Thank you for the work on this document!

I put detailed comments inline below.

As we have a constrained timeline for this document, I would like to start
the IETF Last-Call in no more than a couple of weeks.  I don't think my
comments will be hard to address.  In fact, there are comments that I
repeat in different sections, and some overlap.

Please reply inline to this message to expedite my review of any updates.
Also, if you think talking would clear things up faster, feel free to find
time on my calendar:  https://doodle.com/mm/alvaroretana/book-a-time

Thanks!

Alvaro.


[Line numbers from idnits.]

...
15 Abstract

17   This memo specifies LISP-SEC, a set of security mechanisms that
18   provides origin authentication, integrity and anti-replay protection
19   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
20   process.  LISP-SEC also enables verification of authorization on EID-
21   prefix claims in Map-Reply messages.

[nit] s/via mapping lookup process/via the mapping lookup process/g


...
100 1.  Introduction
...
120   This memo specifies LISP-SEC, a set of security mechanisms that
121   provides origin authentication, integrity and anti-replay protection
122   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
123   process.  LISP-SEC also enables verification of authorization on EID-
124   prefix claims in Map-Reply messages, ensuring that the sender of a
125   Map-Reply that provides the location for a given EID-prefix is
126   entitled to do so according to the EID prefix registered in the
127   associated Map-Server.  Map-Register/Map-Notify security, including
128   the right for a LISP entity to register an EID-prefix or to claim
129   presence at an RLOC, is out of the scope of LISP-SEC as those
130   protocols are protected by the security mechanisms specified in
131   [I-D.ietf-lisp-rfc6833bis].  However, LISP-SEC extends the Map-
132   Register message to allow an ITR to securely downgrade to non LISP-
133   SEC Map-Requests.  Additional security considerations are described
134   in Section 6.

[major] "securely downgrade to non LISP-SEC Map-Requests"

To "securely downgrade" to no security doesn't sound right to me.  See more
comments in §6.7.


...
176 4.  LISP-SEC Threat Model

178   LISP-SEC addresses the control plane threats, described in section
179   3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including
180   manipulations of Map-Request and Map-Reply messages, and malicious
181   ETR EID prefix overclaiming.  LISP-SEC makes two main assumptions:
182   (1) the LISP mapping system is expected to deliver a Map-Request
183   message to their intended destination ETR as identified by the EID,
184   and (2) no man-in-the-middle (MITM) attack can be mounted within the
185   LISP Mapping System.  How the Mapping System is protected from MITM
186   attacks depends from the particular Mapping System used, and is out
187   of the scope of this memo.  Furthermore, while LISP-SEC enables
188   detection of EID prefix overclaiming attacks, it assumes that Map-
189   Servers can verify the EID prefix authorization at registration time.

[] As part of the efforts to make the language in IETF documents more
inclusive, consider using "on-path attack" instead of MITM.  This term in
already in use in some parts of this document.

https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/


...
202 5.  Protocol Operations
...
210   LISP-SEC builds on top of the security mechanisms defined in
211   [I-D.ietf-lisp-rfc6833bis] to address the threats described in
212   Section 4 by leveraging the trust relationships existing among the
213   LISP entities participating to the exchange of the Map-Request/Map-
214   Reply messages.  Those trust relationships are used to securely
215   distribute, as described in Section 8.4, a per-message One-Time Key
216   (OTK) that provides origin authentication, integrity and anti-replay
217   protection to mapping data conveyed via the mapping lookup process,
218   and that effectively prevent overclaiming attacks.  The processing of
219   security parameters during the Map-Request/Map-Reply exchange is as
220   follows

Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

[Fabio Maino (fmaino)]

As an author, I support the document.

I think it’s a very interesting use case,  that shows how LISP can support a 
global geo-localization index infrastructure. A good example of how a fast, 
scalable lookup infrastructure can support, up to a certain extent,  use cases 
that are typically considered the domain of peer-to-peer architectures.

The document articulates the peculiarities of the use case, providing a guide 
on how to leverage the H3 geospatial  indexing system on top of LISP.

Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, February 23, 2021 at 11:17 PM
To: "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon

Folks,

while this document has gathered attention during face to face meetings, we 
received very few email in support of WG LC!

In order to gather more consensus we prefer to extend the Last Call period by 
two weeks, to end by March 10th.

Please speak up and state whether or not this document is ready to be published.

Ciao

Luigi & Joel



On 3 Feb 2021, at 16:25, Luigi Iannone mailto:g...@gigix.net>> 
wrote:

Hi All,

The authors of  draft-ietf-lisp-nexagon submitted the current version back in 
October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the document 
stable and ready for  WG Last Call.

This email open the usual two weeks Working Group Last Call, to end February 
17th, 2021.

Please review this WG document and let the WG know if you agree that it is 
ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it 
would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-pubsub

[Fabio Maino (fmaino)]

As a contributor I support handing this draft to the AD.

Pubsub operations are an important extension for the LISP architecture. There 
are a number of use cases where ITRs need to be notified of rapidly changing 
mappings. This draft leverages the Map-Request/Mao-Notify messages to handle 
subscribe and notify operations that implement the LISP pubsub semantic.

Thanks,
Fabio



From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, January 12, 2021 at 11:20 PM
To: "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: [lisp] WG Last Call for draft-ietf-lisp-pubsub

Hi All,

The authors of  draft-ietf-lisp-pubsub submitted a new version addressing the 
issues raised during SECDIR review.
The document seems mature and stable and authors are asking for formal WG Last 
Call.

This email open the usual two weeks Working Group Last Call, to end January 
28th, 2021.

Please review this WG document and let the WG know if you agree that it is 
ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain what it 
would take to address your concerns.

NOTE: silence IS NOT consensus!

Thanks

Luigi & Joel
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Moving forward with lisp-nexagon

[Fabio Maino (fmaino)]

It’s indeed a very interesting use case and application for the LISP protocol. 
As an author, I would like to see the WG involved with this topic.

Thanks,
Fabio

From: lisp  on behalf of Sharon Barkai 

Date: Sunday, August 2, 2020 at 9:45 AM
To: "lisp@ietf.org list" 
Subject: [lisp] Moving forward with lisp-nexagon

We have presented the nexagon
 https://tools.ietf.org/html/draft-ietf-lisp-nexagon-04 

work at several LISP WG sessions.  We have made significant improvements to the 
work over that time in AAA, security, privacy, and grammar thanks to prominent 
non author wg members.


This ID can help show what can be done with lisp mapped addressable-states and 
brokered mp2mp channels by simply using standard lisp ucast/mcast interfaces.


ID can also help iot / street-processing specs evolve from sending things to a 
“server”. Show an interoperable extendible paradigm, and actually interoperate 
and extend themed-channels with enterprise EID  “MIBs”.


Before asking the chairs for formal WG adoption as authors, would like to know 
if folks are interested in seeing this advanced, and willing to help move it 
forward.


Thank you.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Magnus, 
sounds good, I'll update that text as soon the publication window reopens. 

Thanks!
Fabio

On 7/14/20, 2:45 AM, "Magnus Westerlund"  
wrote:

Hi,

From my perspective the below is still a normative reference formulation. 
You
have to read the reference to be able to determine if you SHOULD follow 
them or
not. 

Maybe adopting the paragraph which draft-ietf-tsvwg-ecn-encap-guidelines
proposes to update RFC 3819 with: 

  By following the guidelines in [RFC], subnetwork designers can
  enable a layer-2 protocol to participate in congestion control
  without dropping packets via propagation of explicit congestion
  notification (ECN [RFC3168]) to receivers.

Into the below text can make it inforamtive. 


   Keeping in mind the recommendation above, new encapsulated payloads,
   when registered with LISP-GPE, should be designed for explicit
   congestion signals to propagate consistently from lower layer
   protocols into IP.  Then the IP internetwork layer can act as a
   portability layer to carry congestion notification from non-IP-aware
   congested nodes up to the transport layer (L4).  Such new
   encapsulated payloads, when registered with LISP-GPE, MUST be
   accompanied by a set of guidelines derived from [RFC6040]. 
   Following the guidelines in [I-D.ietf-tsvwg-ecn-encap-guidelines],
   designers of new LISP-GPE encapsualtions can enable LISP GPE and the 
   encapsulated payload to participate in congestion control without 
dropping 
   packets via propagation of explicit congestion notification (ECN 
[RFC3168]) 
   to receivers.

Please word smith. I still think this is borde line case for a informative
reference but at least it is not directly part of an RFC 2119 language 
sentence.

Cheers

Magnus


On Mon, 2020-07-13 at 19:04 +0000, Fabio Maino (fmaino) wrote:
> Magnus, 
> here is how we modified the latest version of the draft trying to reflect 
your
> concerns, and to deal with the status of the ecn-encap-guidelines draft. 
> 
> 4.2.  Congestion Control Functionality
> 
>LISP-GPE does not natively provide congestion control functionality
>and relies on the payload protocol traffic for congestion control.
>As such LISP-GPE MUST be used with congestion controlled traffic or
>within a network that is traffic managed to avoid congestion (TMCE).
>An operator of a traffic managed network (TMCE) may avoid congestion
>by careful provisioning of their networks, rate-limiting of user data
>traffic and traffic engineering according to path capacity.
> 
>Keeping in mind the recommendation above, new encapsulated payloads,
>when registered with LISP-GPE, should be designed for explicit
>congestion signals to propagate consistently from lower layer
>protocols into IP.  Then the IP internetwork layer can act as a
>portability layer to carry congestion notification from non-IP-aware
>congested nodes up to the transport layer (L4).  Such new
>encapsulated payloads, when registered with LISP-GPE, MUST be
>accompanied by a set of guidelines derived from [RFC6040] and SHOULD
>follow the guidelines defined in  
[I-D.ietf-tsvwg-ecn-encap-guidelines].
> 
> 
> Thanks,
> Fabio
> 
> On 7/10/20, 6:54 AM, "Magnus Westerlund" 
> wrote:
> 
> On Thu, 2020-07-09 at 13:57 -0400, Joel M. Halpern wrote:
> > Magnus, while it is possible we will still get hold ups on the LISP 
> > documents, I would really prefer to avoid creating a normative 
> > dependency on something that at best is 6 months away.  
Particularly 
> > since the TSVWG has not cared enough to maintain the document.
> 
> I can understand that. So then think you need to figure out what
> requirements
> from that document that you thought was relevant to say that they 
MUST be
> included in a future specification and include them in the GPE 
document so
> that 
> the ecn-encap-guidelines would only be inforamtional reference. 
> 
> Cheers
> 
> Magnus
> 
> > 
> > Yours,
> > Joel
> > 
> > On 7/9/2020 1:50 PM, Magnus Westerlund wrote:
> > > Hi,
> > > 
> > > No, RFC 3819 is not a good replacement for the draft. I would note
> that only
> > > a
> > > minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap-
> guidelines.
> > > 
> >

Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Magnus, thanks for your comments. 

Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft is expired, 
so making it normative might not be an option. 

Since it is meant to replace RFC3819, should we refer to RFC3819 instead? 

Thanks,
Fabio

  

On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker"  
wrote:

Magnus Westerlund has entered the following ballot position for
draft-ietf-lisp-gpe-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Section 4.2:

To me it looks like this is normative reference:

Such new encapsulated payloads, when registered with LISP-
   GPE, MUST be accompanied by a set of guidelines derived from
   [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].

Section 4.3.1:

Thanks for writing relevant guidance on how to mitigate the risks with zero
checksum. Especially the one on traffic separation from other traffic so 
that
it can be caught on the boundaries of the network to prevent the risk to 
other
networks from corrupted traffic.




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Eric, 
Now I see what you mean wrt the abstract/title discrepancy. 

In the next rev we will change the abstract text into: 

This document describes extensions to the Locator/ID Separation
   Protocol (LISP) Data-Plane, via changes to the LISP header, that
   support multi-protocol encapsulation *and allow to introduce new protocol 
capabilities.*


Thanks,
Fabio

 

On 7/8/20, 2:20 AM, "Eric Vyncke (evyncke)"  wrote:

Hello Fabio

Thank you for the prompt and detailed reply of yours.

About the discrepancy between the doc title and abstract, I still strongly 
suggest to update the abstract that is too restrictive (limited to 
multi-protocol extension) as GPE via shim headers allows for other kind of 
extensions.

All my COMMENTs were and are still non-blocking, but, I still regret that 
this document is not part of the 6830bis and the use of 8-bit forcing a 
specific registry. (no need to reply)

Finally, the cosmetic issue of having 0x04 for IPv4 and 0x06 for IPv6 won't 
break my heart too much but this would have been cool though (code points do 
not need to be incremental).

Regards

-éric

-Original Message-----
    From: "Fabio Maino (fmaino)" 
Date: Wednesday, 8 July 2020 at 01:42
To: Eric Vyncke , The IESG 
Cc: "lisp-cha...@ietf.org" , 
"draft-ietf-lisp-...@ietf.org" , "lisp@ietf.org" 

Subject: Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-gpe-16: 
(with COMMENT)

Thanks for your review Eric. Please see below our replies. 

On 7/7/20, 1:02 AM, "lisp on behalf of Éric Vyncke via Datatracker" 
 wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to 
all
email addresses included in the To and CC lines. (Feel free to cut 
this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/




--
COMMENT:

--

Thank you for the work put into this document. This is really 
useful work and
the document is easy to read.

Please find below a couple of non-blocking COMMENTs (and I would 
appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
As this document is in the same 'batch'/timing as the RFC 6830 bis, 
is there a
reason why this extension is not in the bis document itself?

[FM] there were quite a few changes and discussions introduced in 
6830bis. The WG thought that keeping lisp-gpe as a separate document would 
simplify the review process. 

-- Section 3 --
What is the reason why not reusing an existing 'next protocol' 
registry? Or
using a 16-bit Ethernet type like field (as in GRE) ?

[FM] the LISP header uses the last 3 octets in the first 32-bit word 
for the nonce/versioning features. We designed a reduced NP field to try to 
squeeze a limited version of those features using octets 2-3 of lisp-gpe. It 
turned out that the limitations imposed by the shorter field where too much, 
and eventually the WG decided to eliminate the nonce/versioning features 
altogether from lisp-gpe. Reversing now back to 16-bit NP field, would impact 
the early lisp-gpe implementations that have been built so far. 

As a side cosmetic note, I would have preferred to have 0x04 for 
IPv4 and 0x06
for IPv6.

[FM] we decided to assign them incrementally. We really didn’t have 
enough meaningful payloads to get up to 6... 


"the shim header MUST come before the further protocol" but, if 
there are other
headers defined in LISP (I must confess my ignorance on this), 
should the shim
header be just after the LISP header ? I.e. the first one of a 
potential chain
(cfr IPv6 extension header chains) ?

It is unclear whether a shim header 'next protocol' field can also 
have a value
associated to yet another shim header.

[FM] Good catch. We have re-phrased the text to make clear that there 
might be multiple shim headers, and they should be in front of the actual 
payload identified by NP 0x01-0x7F. 
This is ithe new text:  " When shim headers are us

Re: [lisp] Robert Wilton's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Rob, 
Thanks for your review. Please see below. 

On 7/7/20, 3:41 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Hi,

I found this document easy to read and understand.

A couple of minor comments:

4.3.  UDP Checksum

   By default, UDP checksum MUST be used when LISP-GPE is transported
   over IPv6.  A tunnel endpoint MAY be configured for use with zero UDP
   checksum if additional requirements in Section 4.3.1 are met.

This paragraph could probably be moved/merged into section 4.3.1?

[FM] good catch. We have moved it there in rev-17

4.4.  DSCP, ECN and TTL

   When a LISP-GPE router performs Ethernet encapsulation, the inner
   header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped
   to, or used to determine the LISP Instance IDentifier (IID) field.

This text doesn't appear to be related to DSCP, ECN or TTL.  Perhaps tweak 
the
title of this section to cover this text?

[FM] Good point. Changed to " DSCP, ECN, TTL, and 802.1Q". 

Thanks,
Fabio


Regards,
Rob




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Martin Duke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Thanks for your comments, Martin. Please see below. 

On 7/6/20, 9:18 PM, "Martin Duke via Datatracker"  wrote:

Martin Duke has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

I found the requirements in Section 4.3.1 (IPv6 zero checksum) quite onerous
and can’t help but wonder if it’s worth the complexity, or just that people
already have it implemented in hardware.

[FM] There was quite a lot of discussion in the WG around this, and the "MAY" 
use UDP zero check sum text seem to have reached some consensus that allows 
implementors to make an informed decision. 

This seems like a very useful extension for LISP.


s/octet/octet

s/payolads/payloads

[FM] typos are now fixed in rev-17. 


Thanks,
Fabio


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

[Fabio Maino (fmaino)]

Thanks for your review Eric. Please see below our replies. 

On 7/7/20, 1:02 AM, "lisp on behalf of Éric Vyncke via Datatracker" 
 wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-lisp-gpe-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Thank you for the work put into this document. This is really useful work 
and
the document is easy to read.

Please find below a couple of non-blocking COMMENTs (and I would appreciate 
a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
As this document is in the same 'batch'/timing as the RFC 6830 bis, is 
there a
reason why this extension is not in the bis document itself?

[FM] there were quite a few changes and discussions introduced in 6830bis. The 
WG thought that keeping lisp-gpe as a separate document would simplify the 
review process. 

-- Section 3 --
What is the reason why not reusing an existing 'next protocol' registry? Or
using a 16-bit Ethernet type like field (as in GRE) ?

[FM] the LISP header uses the last 3 octets in the first 32-bit word for the 
nonce/versioning features. We designed a reduced NP field to try to squeeze a 
limited version of those features using octets 2-3 of lisp-gpe. It turned out 
that the limitations imposed by the shorter field where too much, and 
eventually the WG decided to eliminate the nonce/versioning features altogether 
from lisp-gpe. Reversing now back to 16-bit NP field, would impact the early 
lisp-gpe implementations that have been built so far. 

As a side cosmetic note, I would have preferred to have 0x04 for IPv4 and 
0x06
for IPv6.

[FM] we decided to assign them incrementally. We really didn’t have enough 
meaningful payloads to get up to 6... 


"the shim header MUST come before the further protocol" but, if there are 
other
headers defined in LISP (I must confess my ignorance on this), should the 
shim
header be just after the LISP header ? I.e. the first one of a potential 
chain
(cfr IPv6 extension header chains) ?

It is unclear whether a shim header 'next protocol' field can also have a 
value
associated to yet another shim header.

[FM] Good catch. We have re-phrased the text to make clear that there might be 
multiple shim headers, and they should be in front of the actual payload 
identified by NP 0x01-0x7F. 
This is ithe new text:  " When shim headers are used with other protocols 
identified by next protocol values from 0x0 to 0x7D, all the shim headers MUST 
come first."

== NITS ==
The document title "LISP Generic Protocol Extension" is generic while the
document is mainly about "multi-protocol encapsulation". Should the title be
changed? As a non-English speaker, I read the title as how to make 
any/generic
extension to the LISP protocol and not as a LISP extension to support the
transport of generic/any protocol.

[FM] one can use lisp-gpe to extend the LISP encapsulation protocol to support 
generic payloads (IPv6, ethernet, NSH, iOAM, GBP, ...) in addition to IP. 
However it is also possible to use lisp-gpe to extend LISP features. For 
example, one could use a shim header to implement a nonce/versioning field of 
arbitrary size. That's the reason we think of the draft as a LISP Generic 
Protocol Extension.  

-- Section 3 --

[FM] all the suggestions below are addressed in rev-17

Strongly suggest to make it clear by adding a MUST in  "and ignored on
receipt", i.e., "and MUST be ignored on receipt"

"0x05 to 0x7D " the final ':' is missing.

Why not writing " 0x7E, 0x7F:" ?

"deploy new GPE features", GPE is not expanded before this first use (even 
if
quite obvious in this document).

s/octect/octet/

Thanks,
Fabio

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Thanks anyway Mirja, 
your help along all of this was much appreciated! 

Fabio



On 6/8/20, 12:42 PM, "Mirja Kuehlewind"  wrote:

Thanks a lot! I believe all my comments are addressed but I’m also not an 
AD anymore…



> On 1. Jun 2020, at 07:55, Fabio Maino (fmaino) 
 wrote:
> 
> Hi Mirja, 
> Rev -15, that was just published, should address your comments: 
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
> 
> Let me know if you have any further comment. 
> 
> Thanks,
> Fabio
> 
> On 3/13/20, 4:19 AM, "Mirja Kuehlewind"  wrote:
> 
>Hi authors, hi Deborah,
> 
>Sorry for being super later on this but I was looking at this document 
again and I realised that there is still one open issue that needs fixing: I 
noticed that I also had a discuss point on guidance on DSCP which is not 
addressed yet. However, the more important and really critical point is that 
the doc talks about setting the 3-bit Type of Service (ToS) that does exist 
anymore: RFC1349 was obsoleted by RFC2474, so there is now only a 6-bit DSCP 
field. This is really a pain point in todays Internet and needs to be fixed! I 
also recommend to add a reference to RFC2474 (then this problem would maybe 
have been detected earlier). And still as my discuss says some more guidance on 
the use of DCSP would be good as well!
> 
>Thanks!
>Mirja
> 
> 
> 
>> On 10. Jan 2020, at 20:03, BRUNGARD, DEBORAH A  wrote:
>> 
>> Hi Mirja,
>> 
>> The plan is to Last Call the set of documents (gpe, bis's) and put on a 
future telechat. First, the author teams want to ensure they have addressed all 
the current Discusses/comments and they are working to get the documents ready.
>> 
>> Thanks all - the documents are much improved!
>> Deborah
>> 
    >> 
>> -Original Message-
>> From: Mirja Kuehlewind  
>> Sent: Wednesday, January 08, 2020 5:22 AM
>> To: Fabio Maino (fmaino) ; BRUNGARD, DEBORAH A 

>> Cc: The IESG ; lisp-cha...@ietf.org; lisp@ietf.org; 
magnus.westerl...@ericsson.com; draft-ietf-lisp-...@ietf.org; Luigi Iannone 

>> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with 
DISCUSS and COMMENT)
>> 
>> Hi Fabio,
>> 
>> Thanks for all the work. Changes look good to me and I think my discuss 
comments are addressed.
>> 
>> One small comment/nit: I think you also should define the “Reserved” 
field in Figure 2. It’s not mention in the text, and even though the meaning is 
obvious, I assume it was an oversight that it's not described.
>> 
>> Given the large set of changes, it’s good that another wg last call took 
place. I think given more or less whole document has changes, it could be 
approbate to also have another IETF last call and put it back on a future 
telechat agenda. But I let Deborah decide about this. 
>> 
>> Deborah what's your plan here?
>> 
>> Mirja
>> 
>> 
>> 
>>> On 8. Jan 2020, at 00:02, Fabio Maino (fmaino)  wrote:
>>> 
>>> Hi Mirja,
>>> It took quite some time, but I think we are finally making progress 
>>> with the review of draft-ietf-lisp-gpe and the related LISP RFCbis 
>>> drafts 
>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>>> ..org_doc_draft-2Dietf-2Dlisp-2Drfc6830bis_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQ
>>> icvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVl
>>> PPk33Nw&s=oRnVaMWUr_mvYyEiDEkkNTuBOAIOJ_vBnr3COsvsMrI&e=
>>> , 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw&s=3I9q-AoB6EQNPtTNvKH36_EP-xCFPQESZPH7CeFoVuo&e=
  ).
>>> 
>>> Could you please take a look at the latest rev -13 of 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Dgpe_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw&s=BueHq0NVA0sDhX7r1hme2y4YHEnu52LCy7alSTn3nIc&e=
 , and let us  know if we have addressed your comments?
>>> 
>>> Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have 
done two main changes that might help addressing your DISCUSS: 
>>> 1.  We have introduced the concept of shim header, along the line 
o

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Done!

Fabio

From: Fabio Maino 
Date: Wednesday, June 3, 2020 at 9:43 AM
To: Luigi Iannone 
Cc: "lisp@ietf.org" , "draft-ietf-lisp-...@ietf.org" 

Subject: Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

Sounds good Luigi.

I’ll publish an updated version that reflects your suggestions later today.

Fabio

From: Luigi Iannone 
Date: Tuesday, June 2, 2020 at 10:45 PM
To: Fabio Maino 
Cc: "lisp@ietf.org" , "draft-ietf-lisp-...@ietf.org" 

Subject: Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt
Resent-From: 
Resent-To: Fabio Maino , , 
, Darrel Lewis , 
Resent-Date: Tuesday, June 2, 2020 at 10:44 PM

Hello again,

if you agree to change the text as for may previous email table in section 6 
IANA Considerations must be updated as well.

Ciao

L.








On 3 Jun 2020, at 07:38, Luigi Iannone mailto:g...@gigix.net>> 
wrote:

Hi Fabio,

thanks for the clarification. I think that I finally got it:

0x7E to 0x7F is for just experimentation.

 0xFE to 0xFF is for shim headers experimentation

My confusion came from the fact that is not clearly stated.

Can we modify the text as:

0x7E to 0x7F:  Experimentation and testing
0x80 to 0xFD:  Unassigned (shim headers)
0xFE to 0xFF:  Experimentation and testing (shim headers)

So that the difference  is clearly stated.

Ciao

L.





On 2 Jun 2020, at 19:34, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciso Luigi, please see below...

On 6/2/20, 12:11 AM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:





On 1 Jun 2020, at 07:53, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciao Luigi,
The reason is to allow to experiment with shim headers and non-shim headers at 
the same time. As you may remember shim headers have a more fixed encodng and 
must be located before non-shim headers.

   That is OK for me.

   But my question is why this:



0x7E to 0x7F:  Experimentation and testing

FM> The two above are for experimentation of NON shim headers



   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing



FM These two are for experimentation of shim headers.

Shim headers are placed (and processed) first, so we want to give the freedom 
to experiment with both.

For example, one would want to experiment with a shim header (identified by 
0xFE) that carries some special metadata for IPv4 payloads, while someone else 
would want to experiment with IPv8 payloads (identified with 0x7E). A third 
person might want to experiment, at the same time, with a shim header that 
carries special metadata for IPv8.

Fabio






   Instead of this (range has been adapted):

   0x7E to 0xFB:  Unassigned (shim headers)
   0xFC to 0xFF:  Experimentation and testing

   ??

   Certainly I am missing something ;-)

   Ciao

   L.






Thanks,
Fabio



On 5/31/20, 10:47 PM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:

  Thank you for updating the document.

  I have a quick question.

  Looking at the next protocol values we now see:

   0x7E to 0x7F:  Experimentation and testing
   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing

  Can you provide a rationale why not having just one bigger experimentation 
and testing range instead of two with an unassigned range in the middle?

  Thanks

  Ciao

  L.





On 1 Jun 2020, at 07:41, 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.

 Title   : LISP Generic Protocol Extension
 Authors : Fabio Maino
   Jennifer Lemon
   Puneet Agarwal
   Darrel Lewis
   Michael Smith
Filename: draft-ietf-lisp-gpe-15.txt
Pages   : 15
Date: 2020-05-31

Abstract:
This document describes extentions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-gpe-15
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Sounds good Luigi.

I’ll publish an updated version that reflects your suggestions later today.

Fabio

From: Luigi Iannone 
Date: Tuesday, June 2, 2020 at 10:45 PM
To: Fabio Maino 
Cc: "lisp@ietf.org" , "draft-ietf-lisp-...@ietf.org" 

Subject: Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt
Resent-From: 
Resent-To: Fabio Maino , , 
, Darrel Lewis , 
Resent-Date: Tuesday, June 2, 2020 at 10:44 PM

Hello again,

if you agree to change the text as for may previous email table in section 6 
IANA Considerations must be updated as well.

Ciao

L.







On 3 Jun 2020, at 07:38, Luigi Iannone mailto:g...@gigix.net>> 
wrote:

Hi Fabio,

thanks for the clarification. I think that I finally got it:

0x7E to 0x7F is for just experimentation.

 0xFE to 0xFF is for shim headers experimentation

My confusion came from the fact that is not clearly stated.

Can we modify the text as:

0x7E to 0x7F:  Experimentation and testing
0x80 to 0xFD:  Unassigned (shim headers)
0xFE to 0xFF:  Experimentation and testing (shim headers)

So that the difference  is clearly stated.

Ciao

L.




On 2 Jun 2020, at 19:34, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciso Luigi, please see below...

On 6/2/20, 12:11 AM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:




On 1 Jun 2020, at 07:53, Fabio Maino (fmaino) 
mailto:fma...@cisco.com>> wrote:

Ciao Luigi,
The reason is to allow to experiment with shim headers and non-shim headers at 
the same time. As you may remember shim headers have a more fixed encodng and 
must be located before non-shim headers.

   That is OK for me.

   But my question is why this:


0x7E to 0x7F:  Experimentation and testing

FM> The two above are for experimentation of NON shim headers


   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing


FM These two are for experimentation of shim headers.

Shim headers are placed (and processed) first, so we want to give the freedom 
to experiment with both.

For example, one would want to experiment with a shim header (identified by 
0xFE) that carries some special metadata for IPv4 payloads, while someone else 
would want to experiment with IPv8 payloads (identified with 0x7E). A third 
person might want to experiment, at the same time, with a shim header that 
carries special metadata for IPv8.

Fabio






   Instead of this (range has been adapted):

   0x7E to 0xFB:  Unassigned (shim headers)
   0xFC to 0xFF:  Experimentation and testing

   ??

   Certainly I am missing something ;-)

   Ciao

   L.





Thanks,
Fabio



On 5/31/20, 10:47 PM, "Luigi Iannone" mailto:g...@gigix.net>> 
wrote:

  Thank you for updating the document.

  I have a quick question.

  Looking at the next protocol values we now see:

   0x7E to 0x7F:  Experimentation and testing
   0x80 to 0xFD:  Unassigned (shim headers)
   0xFE to 0xFF:  Experimentation and testing

  Can you provide a rationale why not having just one bigger experimentation 
and testing range instead of two with an unassigned range in the middle?

  Thanks

  Ciao

  L.




On 1 Jun 2020, at 07:41, 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.

 Title   : LISP Generic Protocol Extension
 Authors : Fabio Maino
   Jennifer Lemon
   Puneet Agarwal
   Darrel Lewis
   Michael Smith
Filename: draft-ietf-lisp-gpe-15.txt
Pages   : 15
Date: 2020-05-31

Abstract:
This document describes extentions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-gpe-15
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] support for INT in LISP-GPE

[Fabio Maino (fmaino)]

In-Band Network Telemetry (INT) is specified in 
https://p4.org/assets/INT-current-spec.pdf.

We’ve been asked by implementors to include a codepoint in lisp-gpe to support 
that header.

I understand that the normal procedure to follow would be to write a INT draft 
that would request IANA to assign the needed codepoint. However, I believe that 
such a draft doesn’t exist and I don’t know of anyone writing it.

Is there any way we can reference in lisp-gpe that external spec and ask IANA 
to allocate a codepoint for INT?

Thanks,
Fabio

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Ciso Luigi, please see below...

On 6/2/20, 12:11 AM, "Luigi Iannone"  wrote:



> On 1 Jun 2020, at 07:53, Fabio Maino (fmaino)  wrote:
> 
> Ciao Luigi, 
> The reason is to allow to experiment with shim headers and non-shim 
headers at the same time. As you may remember shim headers have a more fixed 
encodng and must be located before non-shim headers.

That is OK for me. 

But my question is why this:

> 0x7E to 0x7F:  Experimentation and testing

FM> The two above are for experimentation of NON shim headers

> 0x80 to 0xFD:  Unassigned (shim headers)  
> 0xFE to 0xFF:  Experimentation and testing

>FM These two are for experimentation of shim headers. 

Shim headers are placed (and processed) first, so we want to give the freedom 
to experiment with both. 

For example, one would want to experiment with a shim header (identified by 
0xFE) that carries some special metadata for IPv4 payloads, while someone else 
would want to experiment with IPv8 payloads (identified with 0x7E). A third 
person might want to experiment, at the same time, with a shim header that 
carries special metadata for IPv8. 

Fabio

  




Instead of this (range has been adapted):

0x7E to 0xFB:  Unassigned (shim headers)
0xFC to 0xFF:  Experimentation and testing

??

Certainly I am missing something ;-)

Ciao

L.



> 
> Thanks,
> Fabio
> 
> 
> 
> On 5/31/20, 10:47 PM, "Luigi Iannone"  wrote:
> 
>Thank you for updating the document.
> 
>I have a quick question.
> 
>Looking at the next protocol values we now see:
> 
> 0x7E to 0x7F:  Experimentation and testing
> 0x80 to 0xFD:  Unassigned (shim headers)  
> 0xFE to 0xFF:  Experimentation and testing
> 
>Can you provide a rationale why not having just one bigger 
experimentation and testing range instead of two with an unassigned range in 
the middle?
> 
>Thanks
> 
>Ciao
> 
>L.
> 
> 
> 
>> On 1 Jun 2020, at 07:41, internet-dra...@ietf.org wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
>> This draft is a work item of the Locator/ID Separation Protocol WG of 
the IETF.
>> 
>>   Title   : LISP Generic Protocol Extension
>>   Authors : Fabio Maino
>> Jennifer Lemon
>> Puneet Agarwal
>> Darrel Lewis
>> Michael Smith
>>  Filename: draft-ietf-lisp-gpe-15.txt
>>  Pages   : 15
>>  Date: 2020-05-31
>> 
>> Abstract:
>>  This document describes extentions to the Locator/ID Separation
>>  Protocol (LISP) Data-Plane, via changes to the LISP header, to
>>  support multi-protocol encapsulation.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-lisp-gpe-15
>> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-15
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-15
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> 


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Hi Mirja, 
Rev -15, that was just published, should address your comments: 
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/

Let me know if you have any further comment. 

Thanks,
Fabio

On 3/13/20, 4:19 AM, "Mirja Kuehlewind"  wrote:

Hi authors, hi Deborah,

Sorry for being super later on this but I was looking at this document 
again and I realised that there is still one open issue that needs fixing: I 
noticed that I also had a discuss point on guidance on DSCP which is not 
addressed yet. However, the more important and really critical point is that 
the doc talks about setting the 3-bit Type of Service (ToS) that does exist 
anymore: RFC1349 was obsoleted by RFC2474, so there is now only a 6-bit DSCP 
field. This is really a pain point in todays Internet and needs to be fixed! I 
also recommend to add a reference to RFC2474 (then this problem would maybe 
have been detected earlier). And still as my discuss says some more guidance on 
the use of DCSP would be good as well!

Thanks!
Mirja



> On 10. Jan 2020, at 20:03, BRUNGARD, DEBORAH A  wrote:
> 
> Hi Mirja,
> 
> The plan is to Last Call the set of documents (gpe, bis's) and put on a 
future telechat. First, the author teams want to ensure they have addressed all 
the current Discusses/comments and they are working to get the documents ready.
> 
> Thanks all - the documents are much improved!
> Deborah
> 
> 
> -Original Message-
> From: Mirja Kuehlewind  
> Sent: Wednesday, January 08, 2020 5:22 AM
> To: Fabio Maino (fmaino) ; BRUNGARD, DEBORAH A 

> Cc: The IESG ; lisp-cha...@ietf.org; lisp@ietf.org; 
magnus.westerl...@ericsson.com; draft-ietf-lisp-...@ietf.org; Luigi Iannone 

> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with 
DISCUSS and COMMENT)
> 
> Hi Fabio,
> 
> Thanks for all the work. Changes look good to me and I think my discuss 
comments are addressed.
> 
> One small comment/nit: I think you also should define the “Reserved” 
field in Figure 2. It’s not mention in the text, and even though the meaning is 
obvious, I assume it was an oversight that it's not described.
> 
> Given the large set of changes, it’s good that another wg last call took 
place. I think given more or less whole document has changes, it could be 
approbate to also have another IETF last call and put it back on a future 
telechat agenda. But I let Deborah decide about this. 
> 
> Deborah what's your plan here?
> 
> Mirja
> 
> 
> 
>> On 8. Jan 2020, at 00:02, Fabio Maino (fmaino)  wrote:
>> 
>> Hi Mirja,
>> It took quite some time, but I think we are finally making progress 
>> with the review of draft-ietf-lisp-gpe and the related LISP RFCbis 
>> drafts 
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
>> .org_doc_draft-2Dietf-2Dlisp-2Drfc6830bis_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQ
>> icvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVl
>> PPk33Nw&s=oRnVaMWUr_mvYyEiDEkkNTuBOAIOJ_vBnr3COsvsMrI&e=
>> , 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Drfc6833bis_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw&s=3I9q-AoB6EQNPtTNvKH36_EP-xCFPQESZPH7CeFoVuo&e=
  ).
>> 
>> Could you please take a look at the latest rev -13 of 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dlisp-2Dgpe_&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=P3uTUROTWL7J4b_XZZt4t4VKyYB-AcvU0YVlPPk33Nw&s=BueHq0NVA0sDhX7r1hme2y4YHEnu52LCy7alSTn3nIc&e=
 , and let us  know if we have addressed your comments?
>> 
>> Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have done 
two main changes that might help addressing your DISCUSS: 
>> 1.   We have introduced the concept of shim header, along the line 
of what Mirja suggested in her comment. The chairs thought that the change was 
significant enough to require a new last call with the WG, that we did after 
Singapore
>> 2.We have introduced section 4 that, following what done in 
RFC8085 and RFC8086, defines the scope of applicability of LISP-GPE and makes 
considerations related with congestion control, UDP checksum, and ethernet 
payload encapsulation. 
>> 
>> Please, let me know if you have any further question or suggestion. 
>> 
>> I have attached a diff from rev -05 that is the one to which your ballot 
comments were referring to. 
>>

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-15.txt

[Fabio Maino (fmaino)]

Ciao Luigi, 
The reason is to allow to experiment with shim headers and non-shim headers at 
the same time. As you may remember shim headers have a more fixed encodng and 
must be located before non-shim headers. 

Thanks,
Fabio



On 5/31/20, 10:47 PM, "Luigi Iannone"  wrote:

Thank you for updating the document.

I have a quick question.

Looking at the next protocol values we now see:

 0x7E to 0x7F:  Experimentation and testing 
 0x80 to 0xFD:  Unassigned (shim headers)   
 0xFE to 0xFF:  Experimentation and testing

Can you provide a rationale why not having just one bigger experimentation 
and testing range instead of two with an unassigned range in the middle?

Thanks

Ciao

L.



> On 1 Jun 2020, at 07:41, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> This draft is a work item of the Locator/ID Separation Protocol WG of the 
IETF.
> 
>Title   : LISP Generic Protocol Extension
>    Authors : Fabio Maino
>  Jennifer Lemon
>  Puneet Agarwal
>  Darrel Lewis
>  Michael Smith
>   Filename: draft-ietf-lisp-gpe-15.txt
>   Pages   : 15
>   Date: 2020-05-31
> 
> Abstract:
>   This document describes extentions to the Locator/ID Separation
>   Protocol (LISP) Data-Plane, via changes to the LISP header, to
>   support multi-protocol encapsulation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lisp-gpe-15
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-15
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-15
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Thanks for the quick turnaround Mirja. 

I'll add text that refers to the Reserved field in the the next rev. 

Thanks,
Fabio



On 1/8/20, 2:22 AM, "Mirja Kuehlewind"  wrote:

Hi Fabio,

Thanks for all the work. Changes look good to me and I think my discuss 
comments are addressed.

One small comment/nit: I think you also should define the “Reserved” field 
in Figure 2. It’s not mention in the text, and even though the meaning is 
obvious, I assume it was an oversight that it's not described.

Given the large set of changes, it’s good that another wg last call took 
place. I think given more or less whole document has changes, it could be 
approbate to also have another IETF last call and put it back on a future 
telechat agenda. But I let Deborah decide about this. 

Deborah what's your plan here?

Mirja



> On 8. Jan 2020, at 00:02, Fabio Maino (fmaino)  wrote:
> 
> Hi Mirja,
> It took quite some time, but I think we are finally making progress with 
the review of draft-ietf-lisp-gpe and the related LISP RFCbis drafts 
(https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
> , https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ ).
> 
> Could you please take a look at the latest rev -13 of 
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/, and let us  know if we 
have addressed your comments?
> 
> Wrt lisp-gpe, compared with rev -05 that you last reviewed, we have done 
two main changes that might help addressing your DISCUSS: 
> 1.We have introduced the concept of shim header, along the line 
of what Mirja suggested in her comment. The chairs thought that the change was 
significant enough to require a new last call with the WG, that we did after 
Singapore
> 2. We have introduced section 4 that, following what done in 
RFC8085 and RFC8086, defines the scope of applicability of LISP-GPE and makes 
considerations related with congestion control, UDP checksum, and ethernet 
payload encapsulation. 
> 
> Please, let me know if you have any further question or suggestion. 
> 
> I have attached a diff from rev -05 that is the one to which your ballot 
comments were referring to. 
> 
    > Thanks,
> Fabio
> 
> 
> On 9/20/18, 1:22 PM, "Fabio Maino"  wrote:
> 
>Thanks for your notes Mirja.
> 
>I'll publish an updated rev this evening to consolidate the changes 
that 
>I believe we have agreed upon, and then I'll work on those that are 
>still open.
> 
>Please see below.
> 
> 
>On 9/19/18 12:42 PM, Mirja Kühlewind wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-lisp-gpe-05: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> Thanks for addressing the TSV-ART review (and Magnus for doing the 
review)! I
>> assume that the proposed text will be incorporated in the next version. 
(Would
>> have been even better if those (larger) changes would have been added 
before
>> the doc was put on the telechat; please update as soon as possible so 
other AD
>> can review that text as well).
>> 
>> However, I think the text still needs to say more about HOW the PCP 
should be
>> mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 
802.11.
>> Is the same mapping applicable here?
> 
>Agree. As pointed out by Magnus' latest email there's more 
investigation 
>needed here. I'll get back on this.
> 
>> 
>> Also, I'm not an expert for that part, but I guess there also is further
>> guidance needed on HOW to map the VID...?
> 
>This is really straightforward, as the VID is a 12-bit field, and the 
>IID is 24-bit. Implementation that I'm aware of typically carve a 
>portion

Re: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Ben, 
Thanks for your comments, and happy new year! 

Please see below. 

On 12/30/19, 11:49 AM, "Benjamin Kaduk via Datatracker"  
wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

Thanks for the updates in -10 through -12 to leave nonce/versioning to
additional shim headers/extensions; that does alleviate the concerns that
left me balloting Abstain on the -09.

I do have some (new) comments on the -12.

Section 3

Conceptually, I'm thinking about this document as allocating the 'P' bit in
the header and specifying its format when the P bit is set to 1; I don't
expect it to be making changes to generic non-GPE LISP behavior.  So it's
a little surprising to see that bits 0-3 are now marked as Reserved (though
that could probably be wordsmithed away, and the existing Section 2 probably
sets the reader up to do the right thing already), and fairly surprising to
see the following in the P-Bit description:

  If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
  to the definition in [I-D.ietf-lisp-rfc6830bis] with bits N, L, E
  and V set to 0.

Is the claim that once an implementation supports GPE, it will never use the
non-shim-header versions of echo-nonce, map-versioning, etc?  If not, then I
don't think it's appropriate to say "with bits N, L, E, and V set to 0"
here.

[FM] I think you make a good point, especially that we don't want to alter the 
behavior of the protocol when P=0. We can re-word the document accordingly: we 
leave NLEV bits in the header definition, and we limit the document to specify 
the behavior for the case when P=1. 

I'm also not sure I fully understand the motivation for pulling out
the Locator-Status-Bits, as that field's width is unchanged from stock
6830bis.  Leaving them to a TBD shim-header does prevent the conflict with
the Instance ID field, and perhaps the current usage patterns justify such a
shift, so this may be more of a side note than an indication of a flaw in
the document.

[FM] Indeed, there isn't a strong rationale to prevent the use of LSBs with 
GPE. Following your suggestion of specifying GPE as "allocating the P bit in 
LISP" we can leave that feature available even when P=1. 


Section 7

   LISP-GPE, as many encapsulations that use optional extensions, is
   subject to on-path adversaries that by manipulating the g-Bit and the
   packet itself can remove part of the payload.  Typical integrity

Is "g-Bit" supposed to be "P-Bit"?  I am failing to remember what the g-Bit
is, at least...

[FM] yes, typo. Will fix in next rev. 

   With LISP-GPE, issues such as data-plane spoofing, flooding, and
   traffic redirection may depend on the particular protocol payload
   encapsulated.

I'd consider adding another clause, "noting that an attacker that is
spoofing LISP-GPE traffic can claim to encapsulate any protocol payload
type" -- the risk here is based on what types the receiver's implementation
supports, not just what the legitimate sender is encapsulating.

[FM] Ok, we will address this in the next rev. 

I'll post an updated version to reflect the comments above asap. 


Thanks,
Fabio




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Benjamin Kaduk's Abstain on draft-ietf-lisp-gpe-09: (with COMMENT)

[Fabio Maino (fmaino)]

Hi Ben, 
this is to pop up the lisp-gpe review as per conversation in Singapore. 

Thanks,
Fabio 

On 11/19/19, 12:00 AM, "Fabio Maino (fmaino)"  wrote:

Hi Benjamin, 
We have published rev -12 of LISP-GPE that shoukd address the down ref to 
RFC8060 that you brought up, and some changes discussed this morning in the 
LISP WG. 

Please find attached the diff file from rev. -11. 

I hope this, together with the removal of nonce, map-versioning and LSB 
features that was done in rev -11, can help to turn your Abstain into a Yes.

The document is going back into last call. 

Thanks,
Fabio

On 11/8/19, 2:09 PM, "Benjamin Kaduk"  wrote:

Hi Fabio,

That seems like a reasonable approach -- thanks for taking my comments 
into
consideration!

-Ben

On Mon, Nov 04, 2019 at 07:53:41PM +, Fabio Maino (fmaino) wrote:
> Hi Ben, 
> Here is how we propose to move forward. 
> 
> Given that with LISP-GPE we have the opportunity to add additional 
protocol features defining new shim headers, we have removed the Nonce, 
Map-Versioning, and LSBs fields from the main LISP-GPE header. 
> 
> It will then be possible to define a LISP-GPE shim header that 
includes a 64-bit (or even 128-bit) Nonce, as well as a proper Map-versioning 
and LSBs fields. That could be done with an appropriate separate draft, that 
hopefully will address the concerns about those 3 features that have been 
expressed in the review of 6830bis. 
> 
> I have attached rev -11 of the draft and a diff file that reflects 
the approach above.
> 
> It'd be great to hear your thoughts. 
> 
> We will discuss this approach with the WG in Singapore, and if 
there's support, we could go to LC right after the meeting. 
> 
> Thanks,
> Fabio
> 
>  
> 
> 
> 
> 
> 
> On 10/25/19, 5:20 PM, "Benjamin Kaduk via Datatracker" 
 wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lisp-gpe-09: Abstain
> 
> When responding, please keep the subject line intact and reply to 
all
> email addresses included in the To and CC lines. (Feel free to 
cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found 
here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
> 
> 
> 
> 
--
> COMMENT:
> 
--
> 
> Thank you for addressing my Discuss-level points (I can accept 
that for the -09
> that RFC 8060 need not be a normative reference).  I am balloting 
Abstain because
> I am uncomfortable with only 16 bits of nonce, but I recognize 
that there is a need
> for this sort of encapsulation and it must fit within the 
constraints of the core protocol.
> Though, given Alissa's Discuss, it is technically still possible 
for the core protocol to
> grow a larger nonce that would alleviate my concerns.  But, since 
the issue stems from
> a different document (and because I did not raise the issue 
earlier), it is not appropriate
> for me to ballot Discuss on this document for that point.
> 
> [original COMMENT section unchanged; contents presumably stale]
> 
> Section 1
> 
>LISP-GPE MAY also be used to extend the LISP Data-Plane 
header, that
>has allocated all by defining a Next Protocol "shim" header 
that
> 
> nit: allocated all of what?
> 
> Section 3
> 
> This is not exactly the responsibility of LISP-GPE merely because 
it
> allocates the last bit in this bitmap, but it seems like it would 
be quite
> useful to have a table of which combinations of values are valid 
vs.
> nonsensical, given the somewhat complicated interaction between 
some of
> these flag bits.
> 
>   Si

Re: [lisp] I-D Action: draft-ietf-lisp-gpe-12.txt

[Fabio Maino (fmaino)]

Sounds good. 

Next version will reflect this change.. 

Fabio

On 11/21/19, 10:29 AM, "Dino Farinacci"  wrote:

Ack.

Dino

> On Nov 21, 2019, at 10:27 AM, Luigi Iannone  wrote:
> 
> may be we can drop that and keep only LISP-GPE.
> 
> L.
> 
> 
> 
>> On 21 Nov 2019, at 10:26, Luigi Iannone  wrote:
>> 
>> the shim headers.
>> 
>> L.
>> 
>>> On 21 Nov 2019, at 10:25, Dino Farinacci  wrote:
>>> 
>>> What are “related features”.
>>> 
>>> Dino
>>> 
>>>> On Nov 21, 2019, at 10:17 AM, Luigi Iannone  wrote:
>>>> 
>>>> Hi Fabio,
>>>> 
>>>> I would suggest that you change the text in section 5.1 as follows:
>>>> 
>>>> OLD:
>>>> 
>>>>The detection of ETR capabilities to support multiple data 
plane 
>>>>encapsulations and shim headers is out of the scope of this 
document. 
>>>>Given that the applicability domain of LISP-GPE is a 
traffic-managed
>>>>controlled environment, ITR/ETR (xTR) configuration mechanisms 
>>>>may be used for this purpose.
>>>> 
>>>> NEW:
>>>> 
>>>>The discovery of xTR capabilities to support LISP-GPE and 
related features 
>>>>is out of the scope of this document. 
>>>>Given that the applicability domain of LISP-GPE is a 
traffic-managed
>>>>controlled environment, ITR/ETR (xTR) configuration mechanisms 
>>>>may be used for this purpose.
>>>> 
>>>> 
>>>> Other than that, the document looks good to me.
>>>> 
>>>> Ciao
>>>> 
>>>> L.
>>>> 
>>>> 
>>>> 
>>>>> On 19 Nov 2019, at 16:00, Fabio Maino (fmaino)  
wrote:
>>>>> 
>>>>> ___
>>>> 
>>>> ___
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>> 
> 



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Support draft-nexagon wg adoption

[Fabio Maino (fmaino)]

Hi Luigi,
as a co-author I support adoption of this document.

It’s a very interesting use case that leverages LISP aspects such as signal 
free multicast and pub-sub that are some of the most interesting features of 
the LISP protocol stack. It’s also a very interesting example of how LISP can 
support applications that have very unique mobility requirements.

Fabio



From: lisp  on behalf of Luigi Iannone 
Date: Wednesday, November 20, 2019 at 10:41 AM
To: Sharon Barkai 
Cc: "lisp-cha...@ietf.org" , "lisp@ietf.org list" 

Subject: Re: [lisp] Support draft-nexagon wg adoption

Hi,

happy to see that there is already support for this document.

This email formally opens the two weeks WG adoption call.

Please have a look at the document and send an email on whether you agree or 
not to adopt it.
(Silence is NOT consensus)


Thanks


Ciao


L.








On 19 Nov 2019, at 13:36, Sharon Barkai 
mailto:sharon.bar...@getnexar.com>> wrote:

Hey, following very productive session today and as discussed would like to 
formally ask group for draft adoption.

Cheers,
Sharon

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-08: (with DISCUSS and COMMENT)

[Fabio Maino (fmaino)]

Thanks Benjamin, 
Moving 8060 to normative was my unintentional mistake, sorry. We had actually 
reduced the dependency from 8060 in rev -08. 

I've just published -09 that brings 8060 back to informative (and also 
addresses the 'partial mitigation' comment). 
 
Thanks,
Fabio


On 10/24/19, 5:45 PM, "Benjamin Kaduk via Datatracker"  
wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-gpe-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
DISCUSS:
--

Thank you for the updates in the -08!
Can you please say "partially mitigates" instead of "mitigates" in "However,
the use of common anti-spoofing mechanisms such as uRPF mitigates this
form of attack."?

Now that RFC 8060 is a normative reference, it's a downref that I believe 
will
need to be IETF LC'd again.


--
COMMENT:
--

[original COMMENT section unchanged; contents presumably stale]

Section 1

   LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
   has allocated all by defining a Next Protocol "shim" header that

nit: allocated all of what?

Section 3

This is not exactly the responsibility of LISP-GPE merely because it
allocates the last bit in this bitmap, but it seems like it would be quite
useful to have a table of which combinations of values are valid vs.
nonsensical, given the somewhat complicated interaction between some of
these flag bits.

  Similarly, the encoding of the Source and Dest Map-Version fields,
  compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8
  bits.  This still allows to associate 256 different versions to
  each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping
  to inform commmunicating ITRs and ETRs about modifications of the
  mapping.

Are we limited to 256 versions total, or is there some sort of larger
version space that we truncate to send (a la a wraparound process)?
I understand that map-versioning is primarily in a separate document but it
seems important for this document to describe to what extent it is limiting
functionality.

Section 3.1

   To ensure that protocols that are encapsulated in LISP-GPE will work
   well from a transport interaction perspective, the specification of a
   new encapsulated payload MUST contain an analysis of how LISP-GPE
   SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit
   Congestion Notification (ECN) bits whenever they apply to the new
   encapsulated payload.

This MUST is duplicated in the next three paragraphs; I would suggest
leaving this introduction as non-normative, with something like "needs to
contain an analysis of how LISP-GPE will deal with [...]"
Also, nit: "the outer UDP Checksum"

Section 4

   When encapsulating IP packets to a non LISP-GPE capable router the
   P-bit MUST be set to 0.  [...]

   A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the
   P-bit set to 1) to a non-LISP-GPE capable router.

I'm failing to see how these two sentences are not redundant.

Section 5.1

Just to be clear, the intent is that if there is some non-IETF protocol
that we want to encapsulate, we write a two-page Standards-Track RFC that
says "this GPE codepoint means to do what this non-IETF document says"?

Section 6

   However, the use of common anti-spoofing
   mechanisms such as uRPF prevents this form of attack.

I think "mitigates" is probably better than "prevents" in this case.

   LISP-GPE, as many encapsulations that use optional extensions, is
   subject to on-path adversaries that by manipulating the g-Bit and the
   packet itself can remove part of the payload.  Typical integrity
   protection mechanisms (such as IPsec) SHOULD be used in combination
   with LISP-GPE by those protocol extensions that want to protect from
   on-path attackers.

The g-Bit is present in the Map-Reply message, which can in the general
c

Re: [lisp] [Call for Agenda Items] IETF 105 Preliminary Agenda

[Fabio Maino (fmaino)]

Luigi,
Sorry this is coming very late, but can I  have 10 min for an update on 
LISP-SEC?

Thanks,
Fabio

From: lisp  on behalf of Luigi Iannone 
Date: Tuesday, June 25, 2019 at 12:04 AM
To: "lisp@ietf.org list" 
Subject: [lisp] [Call for Agenda Items] IETF 105 Preliminary Agenda

All,

The preliminary agenda for our meeting in Montreal has been published: 
https://datatracker.ietf.org/meeting/105/agenda.html

We will meet Monday Afternoon 13:30 -> 15:30 on July 22.

While the agenda is still subject to changes it is time to think about 
presentation slots.

Please send your requests for agenda items (Presenter’s name, title, slot 
duration)
to lisp-cha...@tools.ietf.org

Ciao

L.
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt)

[Fabio Maino (fmaino)]

Hi Mohamed,
Thanks again for your comments.

They should be addressed by rev -18.

See my previous message to the list for the details.

Thanks,
Fabio

From: lisp  on behalf of "mohamed.boucad...@orange.com" 

Date: Monday, January 28, 2019 at 11:50 PM
To: Luigi Iannone , "lisp@ietf.org list" 
Cc: "lisp-cha...@ietf.org" 
Subject: Re: [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt)

Hi Luigi, all,

FWIW, please find some comments to this document at :


  *   pdf: 
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-lisp-sec-17-rev%20Med.pdf
  *   doc: 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-lisp-sec-17-rev%20Med.doc

These are easy to fix.

Cheers,
Med

De : lisp [mailto:lisp-boun...@ietf.org] De la part de Luigi Iannone
Envoyé : lundi 28 janvier 2019 14:30
À : lisp@ietf.org list
Cc : lisp-cha...@ietf.org
Objet : [lisp] WG Last Call for LISP-SEC (draft-ietf-lisp-sec-17.txt)

Hi All,

since work on bis documents is re-starting to move forward it is about time to 
move forward other pieces of the LISP ecosystem.

As such the LISP Security document has been revised a while ago for two reason:
- Make sure is PS quality
- Make sure it is compliant with latest changes in the bis documents.

The second point has been re-checked by the authors just last week, and seems 
we are ready to move the document forward.

This email open the usual two weeks Working Group Last Call, to end February 
11th, 2019.

Please review this WG document and let the WG know if you agree that it is 
ready for handing to the AD.
If you have objections, please state your reasons why, and explain what it 
would take to address your concerns.

Thanks

Luigi & Joel





___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Deriving Map-Register/Notify authentication key from PSK [Was: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT)]

[Fabio Maino]

On 3/20/19 8:05 AM, Benjamin Kaduk wrote:

On Mon, Mar 18, 2019 at 03:01:07PM -0700, Fabio Maino wrote:

Hi Ben,
I'm starting this separated thread to discuss this point.

Thanks for splitting it off.


On 2/7/19 5:50 AM, Benjamin Kaduk wrote:

This document includes a mechansism to use HMAC keyed by a pre-shared key
to authenticate messages (Map-Register and Map-Notify*); it is directly
using the long-term PSK as the HMAC key.  This is not really consistent
with current IETF best practices (e.g,. BCP 107), which tend to not use the
long-term key directly for keying messages, but rather to incorporate some
form of key derivation step, to protect the long-term key from
cryptanalysis and reduce the need to track long-term per-key data usage
limits.  It is probably not feasible to directly require all LISP
implementations to switch keying strategy, but it seems quite advisable to
define new algorithm ID types that include a key derivation step before the
HMAC, and to begin efforts to convert the ecosystem to the more sustainable
cryptographic usage.  I would like to discuss what actions are reasonable
to take at this time, on this front.


We plan to proceed as follows.

Currently the Map-Register/Map-Notify protocols messages are
authenticated using a Pre-Shared Key (PSK) identified by the Key ID
field in the Map-Register/Notify message (I'll refer to Map-Register
only from now on, but everything applies to both protocols). The Key ID
field allows rotation of the PSK.

The Algorithm ID identifies the algorithm used. Currently the values
defined are : (0) None, (1) HMAC-SHA1-96, and (2) HMAC-SHA-256-128

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Key ID | Algorithm ID  |  Authentication Data Length   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~ Authentication Data   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We plan to introduce a simple key hierarchy that starting from the PSK
derives per "application" specific keys (applications being
Map-Register/Map-Notify Authentication, LISP-SEC OTK key wrapping, ...
). We will use the most significant bits of the Key ID as actual
identifier of the PSK, and the least significant ones to rotate through
application specific keys for a given PSK.


PSK [identified by Key ID-MSb]

      +--> Map-Register/Notification Key [identified by Key ID-LSb]

      +--> LISP-SEC OTK Wrapping Key [identified by Key ID-LSb]

      +--> ...


For example, if we use the 4 Most Significant bits in the Key ID to
identify the PSK and the 4 Least Significant bits to rotate per
application keys the ETR/MS will use an HKDF (RFC 5869) for
per-application key derivation. Something like:

It's not clear to me that we need to use explicit identifier space to
indicate what type of key we derived -- shouldn't that be implicit from the
context in which we're processing a mesage?


Map-Register Authentication Key = HKDF(Key ID + "Map-Register
Authentication" + PSK)   where "Map-Register Authentication" is a string
that identifies the Map-Register application.

It's good and important to include an identifier like this ("Map-Register
Authentication") to produce different keys for performing different types
of operations, but I think I may have been too brief when I introduced the
topic of key derivation.  The general risk is that if we have a single key that
gets used over and over for the same class of operation over a long period
of time, an attacker can collect lots of ciphertexts produced by the same
key, and do some forms of cryptanalysis that benefit from having more
ciphertexts.  Whether this reused key is the original PSK explicitly shared
between parties, or one deterministically derived from it for just
map-register authentication or map-notify protection doesn't make much
difference to the attacker -- there's still a lot of ciphertexts produced
using the same key.  (That key just happens to have been the output of a
KDF instead of directly shared).  The main goal of the KDF is to stop
presenting many ciphertexts over time produced with the same key, by
generating a fresh derived key for each exchange.  So, in addition to that
context label for what type of key it is, we want something fresh per
message, perhaps that binds the derived key to the specific message at
hand.  I haven't thought very hard about the details yet, but it seems
likely that we'd want to include the nonce as KDF input.  In some protocols
we end up putting almost the entire message being protected in as
additional input, but that's not always necessary or even helpful.


This sounds reasonable.

We could use the 64-bit nonce contained in the map-register/notify so we 
have a fresh key every time.  This would require a KDF operation for 
each Map-R

[lisp] Deriving Map-Register/Notify authentication key from PSK [Was: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT)]

[Fabio Maino]

Hi Ben,
I'm starting this separated thread to discuss this point.


On 2/7/19 5:50 AM, Benjamin Kaduk wrote:

This document includes a mechansism to use HMAC keyed by a pre-shared key
to authenticate messages (Map-Register and Map-Notify*); it is directly
using the long-term PSK as the HMAC key.  This is not really consistent
with current IETF best practices (e.g,. BCP 107), which tend to not use the
long-term key directly for keying messages, but rather to incorporate some
form of key derivation step, to protect the long-term key from
cryptanalysis and reduce the need to track long-term per-key data usage
limits.  It is probably not feasible to directly require all LISP
implementations to switch keying strategy, but it seems quite advisable to
define new algorithm ID types that include a key derivation step before the
HMAC, and to begin efforts to convert the ecosystem to the more sustainable
cryptographic usage.  I would like to discuss what actions are reasonable
to take at this time, on this front.



We plan to proceed as follows.

Currently the Map-Register/Map-Notify protocols messages are 
authenticated using a Pre-Shared Key (PSK) identified by the Key ID 
field in the Map-Register/Notify message (I'll refer to Map-Register 
only from now on, but everything applies to both protocols). The Key ID 
field allows rotation of the PSK.


The Algorithm ID identifies the algorithm used. Currently the values 
defined are : (0) None, (1) HMAC-SHA1-96, and (2) HMAC-SHA-256-128


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Key ID | Algorithm ID  |  Authentication Data Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Authentication Data   ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


We plan to introduce a simple key hierarchy that starting from the PSK 
derives per "application" specific keys (applications being 
Map-Register/Map-Notify Authentication, LISP-SEC OTK key wrapping, ... 
). We will use the most significant bits of the Key ID as actual 
identifier of the PSK, and the least significant ones to rotate through 
application specific keys for a given PSK.



PSK [identified by Key ID-MSb]

    +--> Map-Register/Notification Key [identified by Key ID-LSb]

    +--> LISP-SEC OTK Wrapping Key [identified by Key ID-LSb]

    +--> ...


For example, if we use the 4 Most Significant bits in the Key ID to 
identify the PSK and the 4 Least Significant bits to rotate per 
application keys the ETR/MS will use an HKDF (RFC 5869) for 
per-application key derivation. Something like:


Map-Register Authentication Key = HKDF(Key ID + "Map-Register 
Authentication" + PSK)   where "Map-Register Authentication" is a string 
that identifies the Map-Register application.


As an example a Map-Register that has the Key ID field set to 0xd0 
refers to Map-Register Key 0x0 generated using PSK 0xd. If the ETR wants 
to rotate to a new Map-Register Authentication Key (without changing 
PSK) it will set the Key-ID field to 0xd1. A new PSK will be provisioned 
before all the 16 Map-register Authentication Keys associated with PSK 
0xd are used.


We will use the Algorithm ID to encode the particular KDF used. As an 
example the Algorithm ID defined for the Map-Register authentication 
protocol would be:


HMAC-SHA-256-128-HKDF-SHA1-128 that include HMAC-SHA-256-128 as 
Map-register authentication Algorithm, and HKDF-SHA1-128 as Key 
Derivation Algorithm.


This is compatible with the existing Algorithm IDs defined up to now 
(encoded with values 0,1 and 2) that will be deprecated.


This seems general enough that we can extend it to other security 
services used with the various LISP messages (e,g, to derive a wrapping 
key to transport the OTK in LISP-SEC)


Please let us know if you have comments or suggestions.

We will post the text to describe this in more details as soon as it's 
ready.



Thanks,

Fabio








___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT))

[Fabio Maino]

d with |    |
   | the S-bit set to |    |
   | 0 |    |
+--++

   In this way the ITR that sent a LISP-SEC protected Map-Request always
   receives a LISP-SEC protected Map-Reply.  However, the ETR-Cant-Sign
   E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach
   additional ETRs that have LISP-SEC disabled.  This mechanism allows
   the ITR to securely downgrade to non LISP-SEC requests, if so
   desired.

5.7.1.  Generating a LISP-SEC Protected Encapsulated Map-Request

   The Map-Server decapsulates the ECM and generates a new ECM
   Authentication Data.  The Authentication Data includes the OTK-AD and
   the EID-AD, that contains EID-prefix authorization information, that
   are eventually received by the requesting ITR.

   The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from
   the ITR-OTK received with the Map-Request.  MS-OTK is derived
   applying the key derivation function specified in the KDF ID field.
   If the algorithm specified in the KDF ID field is not supported, the
   Map-Server uses a different algorithm to derive the key and updates
   the KDF ID field accordingly.

   The Map-Server and the ETR MUST be configured with a pre-shared key
   for mapping registration according to [I-D.ietf-lisp-rfc6833bis].  If
   MS-OTK confidentiality is required, then the MS-OTK SHOULD be
   encrypted, by wrapping the MS-OTK with the algorithm specified by the
   OTK Encryption ID field as specified in Section 5.5.

   The Map-Server includes in the EID-AD the longest match registered
   EID-prefix for the destination EID, and an HMAC of this EID-prefix.
   The HMAC is keyed with the ITR-OTK contained in the received ECM
   Authentication Data, and the HMAC algorithm is chosen according to
   the Requested HMAC ID field.  If The Map-Server does not support this
   algorithm, the Map-Server uses a different algorithm and specifies it
   in the EID HMAC ID field.  The scope of the HMAC operation covers the
   entire EID-AD, from the EID-AD Length field to the EID HMAC field,
   which must be set to 0 before the computation.

   The Map-Server then forwards the updated ECM encapsulated Map-
   Request, that contains the OTK-AD, the EID-AD, and the received Map-
   Request to an authoritative ETR as specified in
   [I-D.ietf-lisp-rfc6833bis].

5.7.2.  Generating a Proxy Map-Reply

   LISP-SEC proxy Map-Reply are generated according to
   [I-D.ietf-lisp-rfc6833bis], with the Map-Replay S-bit set to 1.  The
   Map-Reply includes the Authentication Data that contains the EID-AD,
   computed as specified in Section 5.7.1, as well as the PKT-AD
   computed as specified in Section 5.8.







Thanks,
Fabio

On 2/28/19 3:46 PM, Fabio Maino wrote:

Hi Benjamin,
thanks for bringing this up.

I think it makes  sense to have a mechanism for secure downgrade, and 
it should indeed simplify adoption and transition to LISP-SEC.


I discussed what you proposed here with the LISP-SEC authors and with 
Dino and Alberto. We agree to the principles of what you are proposing.


I'll send detailed text, but here is a brief description of what we 
plan to do.


The Map-Register has already the capability to encode ETR's support 
for  LISP-SEC. We will change the behavior of the MS to signal to the 
ITR when the ETR is not LISP-SEC capable.


This will happen when
- the ITR is sending a LISP-SEC Map-Request, AND
- the corresponding ETR has not registered as LISP-SEC capable, AND
- the ETR is in "non-proxy mode" (that is the mode in which the 
Map-reply should be originated at the ETR. (MS/ITR behavior won't 
change if the ETR is in "proxy mode")


In this case the MS will send a Negative Map-Reply, protected by 
LISP-SEC, that includes an ETR-Cant-Sign bit that informs the ITR that 
the ETR doesn't support LISP-SEC. The integrity of the ECS bit is 
protected by LISP-SEC, as the rest of the Map-Reply. This will work 
without changes to the ETR.


In this way the ITR has the option to choose to downgrade to non 
LISP-SEC if it wants to favor reachability.


Thanks,
Fabio



On 2/9/19 2:14 PM, Benjamin Kaduk wrote:

Splitting off a sub-thread for one fairly narrow point that AFAICT needs
further discussion to clarify the path forward:

On Thu, Feb 07, 2019 at 05:50:39AM -0800, Benjamin Kaduk wrote:

--
DISCUSS:
--


[...]

    3.  LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented.  Network
    operartors should carefully weight how the LISP-SEC threat 
model

    applies to their particular use case or deployment. If they
    decide to ignore a particular recommendation, they should make
    sure the risk associated with the corresponding threats is 

Re: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT))

[Fabio Maino]

Hi Benjamin,
thanks for bringing this up.

I think it makes  sense to have a mechanism for secure downgrade, and it 
should indeed simplify adoption and transition to LISP-SEC.


I discussed what you proposed here with the LISP-SEC authors and with 
Dino and Alberto. We agree to the principles of what you are proposing.


I'll send detailed text, but here is a brief description of what we plan 
to do.


The Map-Register has already the capability to encode ETR's support for  
LISP-SEC. We will change the behavior of the MS to signal to the ITR 
when the ETR is not LISP-SEC capable.


This will happen when
- the ITR is sending a LISP-SEC Map-Request, AND
- the corresponding ETR has not registered as LISP-SEC capable, AND
- the ETR is in "non-proxy mode" (that is the mode in which the 
Map-reply should be originated at the ETR. (MS/ITR behavior won't change 
if the ETR is in "proxy mode")


In this case the MS will send a Negative Map-Reply, protected by 
LISP-SEC, that includes an ETR-Cant-Sign bit that informs the ITR that 
the ETR doesn't support LISP-SEC. The integrity of the ECS bit is 
protected by LISP-SEC, as the rest of the Map-Reply. This will work 
without changes to the ETR.


In this way the ITR has the option to choose to downgrade to non 
LISP-SEC if it wants to favor reachability.


Thanks,
Fabio



On 2/9/19 2:14 PM, Benjamin Kaduk wrote:

Splitting off a sub-thread for one fairly narrow point that AFAICT needs
further discussion to clarify the path forward:

On Thu, Feb 07, 2019 at 05:50:39AM -0800, Benjamin Kaduk wrote:

--
DISCUSS:
--


[...]

3.  LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented.  Network
operartors should carefully weight how the LISP-SEC threat model
applies to their particular use case or deployment.  If they
decide to ignore a particular recommendation, they should make
sure the risk associated with the corresponding threats is well
understood.

I'm concerned enough about the risk of having a "ITR requests lisp-sec but
ETR didn't use it" case that causes complete breakage, that I want to talk
about this a bit more.  We currently in this document say that lisp-sec is
mandatory to implement (which presumably covers at least ITRs, ETRs,
Map-Resolvers, and Map-Servers).  LISP-SEC itself says that "and ETR that
supports LISP-SEC MUST set the S bit in its Map-Register messages".  Is it
possible that an ETR might "implement" but then not "support" LISP-SEC?  If
so, then we should consider the possibility that we need an authenticated
signal (from the mapping system to the ITR) that downgrading from lisp-sec
is allowed.  There seem to be several possibilities for how one might
construct such a signal; two that came to mind to me would be (1) to define a
new ACT value for "repeat without lisp-sec" that could be returned as a
negative Map-Response directly from the mapping system wherever the mapping
system is able to discern that the ETR in question does not support
lisp-sec (I don't actually know if this could happen at Map-Resolver or
would need to be delayed until the final Map-Server) and (2) to have an
optional Map-Request field that the ETR is required to copy unchanged to
the Map-Reply; this could then include a message HMAC'd in the ITR-OTK that
indicates lisp-sec non-support and binds to the nonce in the request.
Whether these are workable ideas seems to depend on aspects of the mapping
system to which I cannot speak.

In terms of some background assumptions I've been making (that of course
could be false, so I'm trying to make them explicit), I am assuming that
many or most current LISP deployments do not utilize LISP-SEC at runtime.
It's less clear to me how many deployments/implementations simply do not
have LISP-SEC capabilities at all, or how easy it is to get
software/firmware updates to the needed devices.  Regardless, if there
are existing RFC 6833 deployments that want to migrate to 6833bis when it
is finalized, we should consider what steps would be needed to safely
deploy LISP-SEC without disruption.  In particular, it seems a useful goal
to try to get the security benefit of LISP-SEC for those machines/sites
that have LISP-SEC capability without waiting for the entire administrative
domain's deployment to get updated software/firmware, which I assume is at
least a 5-year lead time in many sites.

Given that at this point my analyses are mostly treating the mapping system
as something of a closed "magic box" that takes Map-Requests as input and
emits them to the appropriate ETRs (or internal proxy function), I'm forced
to conclude that any incremental update to using LISP-SEC will inherently
require the entire mapping system to upgrade first, before any concrete
usage of LISP-SEC should be expected.  Hopefully that's less of a burden
than upgrading entire deployments, since the m

Re: [lisp] comments on draft-ietf-lisp-sec-17

[Fabio Maino]

Thanks Ben,
we will indeed be looking at these comments with the perspective of the 
RFCbis in mind.


Fabio

On 2/19/19 8:07 AM, Benjamin Kaduk wrote:

Hi folks,

Since this document is still sort-of in WGLC, I'm sending my notes on it.
They were originally written as notes to myself during my review of
6833bis, so my apologies for the parts that are inscrutable.  I can try to
clarify as needed.

-Ben


Section 3

authoritative.  In this way the ETR can maliciously redirect traffic
directed to a large number of hosts.

needs clarification

Section 4

LISP-SEC builds on top of the security mechanisms defined in
[I-D.ietf-lisp-rfc6833bis] to address the threats described in
Section 3 by leveraging the trust relationships existing among the
LISP entities participating to the exchange of the Map-Request/Map-
Reply messages.  [...]

I think this may be better as "participating in" (or maybe "party to").

o  The ITR, upon needing to transmit a Map-Request message, generates
   and stores an OTK (ITR-OTK).  This ITR-OTK is included into the
   Encapsulated Control Message (ECM) that contains the Map-Request
   sent to the Map-Resolver.  To provide confidentiality to the ITR-
   OTK over the path between the ITR and its Map-Resolver, the ITR-
   OTK SHOULD be encrypted using a preconfigured key shared between
   the ITR and the Map-Resolver, similar to the key shared between
   the ETR and the Map-Server in order to secure ETR registration
   [I-D.ietf-lisp-rfc6833bis].

I think this is "MUST be protected; SHOULD encrypt using the preconfigured
key".

o  The Map-Server derives a new OTK, the MS-OTK, by applying a Key
   Derivation Function (KDF) to the ITR-OTK.  This MS-OTK is included
   in the Encapsulated Control Message that the Map-Server uses to
   forward the Map-Request to the ETR.  To provide MS-OTK
   confidentiality over the path between the Map-Server and the ETR,
   the MS-OTK SHOULD be encrypted using the key shared between the
   ETR and the Map-Server in order to secure ETR registration
   [I-D.ietf-lisp-rfc6833bis].

and likewise this would be "MUST be protected; SHOULD encrypt using the key
used for registration".

o  If the Map-Server is acting in proxy mode, as specified in
   [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the
   generation of the Map-Reply.  In this case the Map-Server
   generates the Map-Reply on behalf of the ETR as described below.

nit: is what's "described below" the normal ETR procedure (as opposed to
the "on behalf of" behavior)?  Perhaps "using the same procedure the ETR
would use, as described below".

o  The ETR, upon receiving the ECM encapsulated Map-Request from the
   Map-Server, decrypts the MS-OTK, if needed, and originates a
   standard Map-Reply that contains the EID-to-RLOC mapping
   information as specified in [I-D.ietf-lisp-rfc6833bis].

nit: is this really "originates" (vs. "constructs") if we're going to add
the HMAC AD before sending, per the next step?

o  The ITR, upon receiving the Map-Reply, uses the locally stored
   ITR-OTK to verify the integrity of the EID-prefix authorization
   data included in the Map-Reply by the Map-Server.  The ITR
   computes the MS-OTK by applying the same KDF used by the Map-
   Server, and verifies the integrity of the Map-Reply.  If the
   integrity checks fail, the Map-Reply MUST be discarded.  [...]

A typical crypto workflow would be to verify the outer message first before
inspecting the inner contents.  Because this flow is using OTKs, I don't
see an actual attack (and perhaps the EID-prefix authorization is still
useful), but it's unclear that there's any reason to deviate from the
normal practice (which would put the MS-OTK computation and Map-Reply
verification first, then the EID-prefix authorization data integrity
verification).

Section 5.1

   OTK Length: The length (in bytes) of the OTK Authentication Data
   (OTK-AD), that contains the OTK Preamble and the OTK.

nit: it also contains the "OTK length" and "OTK encryption ID" fields, if
the figure is to be believed about the definition of "OTK-AD".

   EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server.
   Before computing the HMAC operation the EID HMAC field MUST be set
   to 0.  The HMAC covers the entire EID-AD.

nit: could note that the length of the HMAC depends on the algorithms used.

Section 5.2

There's a bit of churn between the EID-AD field descriptions in Section 5.1
and the ones here.  The Section 5.1 text does have to cover the
ITR-to-Map-Server version that is somewhat abbreviated, so it's unclear if
the best choice is to do a full consolidation and have Section 5.2 just say
"The EID-AD fields are copied unchanged from the Map-Request received at
the ETR".  Perhaps there's a middle ground of "the X, Y, and Z fields have
the same content and inter

Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

[Fabio Maino]

On 9/28/18 3:38 PM, Joel M. Halpern wrote:
As co-chair, I would like to hear from the working group as to whether 
making LISP-SEC mandatory to Implement (not Mandatory to Use) for 
LISP6830bis and 6833bis implementations is

a) desirable


I have always seen LISP-SEC as part of the LISP "core" set of documents, 
so I agree that it is desirable to make it mandatory to implement.


There are also quite a few comments from Benjamin and Eric's review, 
including to make more clear the scope of applicability, that would 
certainly benefit the RFCbis.


As an author of LISP-SEC I'm willing to help addressing the changes 
above in the documents under review (as well as in LISP-SEC).


Fabio



b) acceptable
c) undesirable but livable
d) unacceptable or worse.

Please, do not just pick a letter.  Include explanation of your opinion.
This is not a decision the ADs and Authors can make for the working 
group.


Yours,
Joel


 Forwarded Message 
Subject: Re: Benjamin Kaduk's Discuss on 
draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

Date: Fri, 28 Sep 2018 17:03:40 -0500
From: Benjamin Kaduk 
To: Joel M. Halpern 
CC: The IESG , draft-ietf-lisp-rfc6830...@ietf.org, 
Luigi Iannone , lisp-cha...@ietf.org, lisp@ietf.org


Hi Joel,


On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote:
Is there text we can add about the scoping that will change your 
discuss into a series of useful comments?


I had attempted to structure my Discuss points so that they would 
either be
useful comments as is, or rendered moot by a reduced scope.  I guess I 
can
try to clarify those below.  (To be clear, reducing the scope is only 
going

to move from "has potentially existentially bad problems" to "has
substantial issues that likely require reengineering to resolve".)

If so, Some indication of how you would like that phrased would help 
us address these.


I think Ekr's ballot position on 6833bis has a good summary of the
architecture assumptions that the reduced scope allows us to make.
In order to have the document be able to plausibly make those claims, it
looks like we'd need to at least:
(1) update the Abstract/Introduction to clarify that the EID namespace is
    only defined within a single administrative domain.
(2) (optionally, if it makes sense) mention in the introduction that this
    administrative domain can include transport over other networks in 
the

    same way that a VPN would function[*], without requiring cooperation
    from or interaction with the other networks' administrators
(3) remove the "global" text from the EID-to-RLOC Database and Map-Cache
    definitions
(4) update the EID-Prefix definition to talk about the local site or
    administrative domain's "address allocation authority"
(5) Take a look at the EID definition to consider whether references 
to "on

    the public Internet" are still valid, and the text about assignment
    in a hierarchical manner should be revised for the new scope as well.
    Likewise for EID-internal structure that is "not visible to the 
global

    routing system"

(I stopped skimming and looking for problematic text around section 6)

[*] Ideally this would be done without using the term "VPN" itself, since
I'd like to get a movement going to restrict "VPN" to include
confidentiality (i.e., privacy) protection.  "virtual network" or 
"overlay

network" may or may not be good candidate replacement terms.


If not, we seem to have a larger problem.


Well, we appear to have five ADs that are supporting making LISP-SEC a
normative reference and thus MTI; I don't know if that scale of change
meets your threshold for a "larger problem".


Yours,
Joel

On 9/26/18 11:44 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lisp-rfc6830bis-20: Discuss
> > When responding, please keep the subject line intact and reply to 
all
> email addresses included in the To and CC lines. (Feel free to cut 
this

> introductory paragraph, however.)
> > > Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html

> for more information about IESG DISCUSS and COMMENT positions.
> > > The document, along with other ballot positions, can be found 
here:

> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
> > > > 
--

> DISCUSS:
> --
> > I have grave concerns about the suitability of LISP as a whole, 
in its

> present form, for advancement to the Standards-Track. While some of my
> concerns are not specific to this document, as the core protocol
> (data-plane) spec, it seems an appropriate place to attach them to.
> > I am told, out of band, that the intended deployment model is no 
longer to

> cover the entire Internet (c.f. the MISSREF-state
> draft-ietf-lisp-introduction's "with LISP, the dge of the Internet 
and the

> core can be logically se

Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

[Fabio Maino]

On 9/28/18 3:41 PM, Joel M. Halpern wrote:

Thank you Benjamin.  This response helps me understand the situation.
I have sent a note to the WG about making LISP-SEC MTI.  That kind of 
change needs WG support.




I second that. The email was indeed very helpful, and I think we can use 
it (together with Eric's notes) as a guide to move forward.


Thanks,
Fabio


Yours,
Joel

On 9/28/18 6:03 PM, Benjamin Kaduk wrote:

Hi Joel,


On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote:
Is there text we can add about the scoping that will change your 
discuss

into a series of useful comments?


I had attempted to structure my Discuss points so that they would 
either be
useful comments as is, or rendered moot by a reduced scope.  I guess 
I can
try to clarify those below.  (To be clear, reducing the scope is only 
going

to move from "has potentially existentially bad problems" to "has
substantial issues that likely require reengineering to resolve".)


If so, Some indication of how you would like that phrased would help us
address these.


I think Ekr's ballot position on 6833bis has a good summary of the
architecture assumptions that the reduced scope allows us to make.
In order to have the document be able to plausibly make those claims, it
looks like we'd need to at least:
(1) update the Abstract/Introduction to clarify that the EID 
namespace is

 only defined within a single administrative domain.
(2) (optionally, if it makes sense) mention in the introduction that 
this
 administrative domain can include transport over other networks 
in the
 same way that a VPN would function[*], without requiring 
cooperation

 from or interaction with the other networks' administrators
(3) remove the "global" text from the EID-to-RLOC Database and Map-Cache
 definitions
(4) update the EID-Prefix definition to talk about the local site or
 administrative domain's "address allocation authority"
(5) Take a look at the EID definition to consider whether references 
to "on

 the public Internet" are still valid, and the text about assignment
 in a hierarchical manner should be revised for the new scope as 
well.
 Likewise for EID-internal structure that is "not visible to the 
global

 routing system"

(I stopped skimming and looking for problematic text around section 6)

[*] Ideally this would be done without using the term "VPN" itself, 
since

I'd like to get a movement going to restrict "VPN" to include
confidentiality (i.e., privacy) protection.  "virtual network" or 
"overlay

network" may or may not be good candidate replacement terms.


If not, we seem to have a larger problem.


Well, we appear to have five ADs that are supporting making LISP-SEC a
normative reference and thus MTI; I don't know if that scale of change
meets your threshold for a "larger problem".


Yours,
Joel

On 9/26/18 11:44 PM, Benjamin Kaduk wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut 
this

introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/



--
DISCUSS:
--

I have grave concerns about the suitability of LISP as a whole, in its
present form, for advancement to the Standards-Track.  While some 
of my

concerns are not specific to this document, as the core protocol
(data-plane) spec, it seems an appropriate place to attach them to.

I am told, out of band, that the intended deployment model is no 
longer to

cover the entire Internet (c.f. the MISSREF-state
draft-ietf-lisp-introduction's "with LISP, the dge of the Internet 
and the

core can be logically separated and interconnected by LISP-capable
routers", etc.), and that full Internet-scale operation is no longer a
goal.  However, since that does not seem to be reflected in the 
current

batch of documents up for IESG review, I am forced to ballot on them
"as-is", namely as targetting global Internet deployment. The 
requirements

placed on the mapping system are so stringent so as to be arguably
unachievable at Internet-scale, though that arguably has more of an
interaction with the control-plane than the data-plane. It's still in
scope here, though, as part of the overall description of the protocol
flow.


(rendered moot by scope reduction)

There are an almost innumerable number of downgrade attacks 
possible, and

the control-plane and data-plane security mechanisms are not normative
dependencies of the current corpus of documents, and as such are 
n

Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

[Fabio Maino]

On 9/28/18 3:41 PM, Joel M. Halpern wrote:

Thank you Benjamin.  This response helps me understand the situation.


I second that. The email was indeed very helpful, and I think we can use 
it (together with Eric's notes) as a guide to move forward.


Thanks,
Fabio

I have sent a note to the WG about making LISP-SEC MTI.  That kind of 
change needs WG support.


Yours,
Joel

On 9/28/18 6:03 PM, Benjamin Kaduk wrote:

Hi Joel,


On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote:
Is there text we can add about the scoping that will change your 
discuss

into a series of useful comments?


I had attempted to structure my Discuss points so that they would 
either be
useful comments as is, or rendered moot by a reduced scope.  I guess 
I can
try to clarify those below.  (To be clear, reducing the scope is only 
going

to move from "has potentially existentially bad problems" to "has
substantial issues that likely require reengineering to resolve".)


If so, Some indication of how you would like that phrased would help us
address these.


I think Ekr's ballot position on 6833bis has a good summary of the
architecture assumptions that the reduced scope allows us to make.
In order to have the document be able to plausibly make those claims, it
looks like we'd need to at least:
(1) update the Abstract/Introduction to clarify that the EID 
namespace is

 only defined within a single administrative domain.
(2) (optionally, if it makes sense) mention in the introduction that 
this
 administrative domain can include transport over other networks 
in the
 same way that a VPN would function[*], without requiring 
cooperation

 from or interaction with the other networks' administrators
(3) remove the "global" text from the EID-to-RLOC Database and Map-Cache
 definitions
(4) update the EID-Prefix definition to talk about the local site or
 administrative domain's "address allocation authority"
(5) Take a look at the EID definition to consider whether references 
to "on

 the public Internet" are still valid, and the text about assignment
 in a hierarchical manner should be revised for the new scope as 
well.
 Likewise for EID-internal structure that is "not visible to the 
global

 routing system"

(I stopped skimming and looking for problematic text around section 6)

[*] Ideally this would be done without using the term "VPN" itself, 
since

I'd like to get a movement going to restrict "VPN" to include
confidentiality (i.e., privacy) protection.  "virtual network" or 
"overlay

network" may or may not be good candidate replacement terms.


If not, we seem to have a larger problem.


Well, we appear to have five ADs that are supporting making LISP-SEC a
normative reference and thus MTI; I don't know if that scale of change
meets your threshold for a "larger problem".


Yours,
Joel

On 9/26/18 11:44 PM, Benjamin Kaduk wrote:

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut 
this

introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/



--
DISCUSS:
--

I have grave concerns about the suitability of LISP as a whole, in its
present form, for advancement to the Standards-Track.  While some 
of my

concerns are not specific to this document, as the core protocol
(data-plane) spec, it seems an appropriate place to attach them to.

I am told, out of band, that the intended deployment model is no 
longer to

cover the entire Internet (c.f. the MISSREF-state
draft-ietf-lisp-introduction's "with LISP, the dge of the Internet 
and the

core can be logically separated and interconnected by LISP-capable
routers", etc.), and that full Internet-scale operation is no longer a
goal.  However, since that does not seem to be reflected in the 
current

batch of documents up for IESG review, I am forced to ballot on them
"as-is", namely as targetting global Internet deployment. The 
requirements

placed on the mapping system are so stringent so as to be arguably
unachievable at Internet-scale, though that arguably has more of an
interaction with the control-plane than the data-plane. It's still in
scope here, though, as part of the overall description of the protocol
flow.


(rendered moot by scope reduction)

There are an almost innumerable number of downgrade attacks 
possible, and

the control-plane and data-plane security mechanisms are not normative
dependencies of the current corpus of documents, and as such are 
no

Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-gpe-06: (with COMMENT)

[Fabio Maino]

Thanks for  your comments Alvaro. Please see below.


On 9/25/18 11:14 AM, Alvaro Retana wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-lisp-gpe-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
COMMENT:
--

I have some non-blocking comments (and nits):

(1) §1: "LISP-GPE MAY also be used to extend the LISP Data-Plane header..."  I
think that MAY is out of place because there's nothing normative about the
statement.


ok. I'll fix in -07 with s/MAY/can/.



(2) §3: "If the P-bit is clear (0) the LISP header conforms to the definition
in [I-D.ietf-lisp-rfc6830bis]."  I find this statement a little confusing
because even with the bit set, the header still conforms to rfc6830bis, except
for the Nonce/Map-Version field. IOW, it sounds as if the bit makes the header
non-conforming.

ok. I'll fix in -07 with s/conform/is bit-by-bit equivalent/




(3) §3: For clarity, it would be nice to add a figure showing the header with
the P and V bits set.


A similar comment was raised by another reviewer. It was decided that 
this document will use the same convention of 6830bis (that doesn't have 
a figure with the V bit set).




(4) §3.1: "...the specification of a new encapsulated payload MUST contain an
analysis of how LISP-GPE SHOULD deal with..."  s/SHOULD/should  In this case
the "SHOULD" is not normative.

ok. will fix in -07




(5) For IP packets, two encapsulation mechanisms exist, the base one defined in
rfc6830bis and the generic one defined in this document.  When encapsulating
towards a GPE-capable router, which mechanisms should be used?  Should one have
preference over the other?  I'm thinking it probably doesn't matter (since the
receiving router can understand both) -- I'm trying to figure out whether there
are operational considerations or guidance that are worth mentioning.


I can't think of a strong reason why one would be better than the other, 
and I see no harm in allowing both behaviors. I'd leave the choice to 
the implementors.



Thanks,

Fabio

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05

[Fabio Maino]

On 9/21/18 2:04 AM, Luigi Iannone wrote:

Hi Fabio,

just one comment on the following sentence (section 1)

LISP-GPE MAY also be used to extend the LISP Data-Plane header, that
   has allocated all by defining a Next Protocol "shim" header that
   implements new data plane functions not supported in the LISP header.

Something is missing in this sentence.

May be: LISP-GPE MAY also be used to extend the LISP Data-Plane 
header, **since
   all of the reserved bits have been allocated, **  by defining a 
Next Protocol "shim" header that

   implements new data plane functions not supported in the LISP header.
Ciao


Thanks for catching this Luigi. It will be addressed in -07.

Fabio



L.



On 21 Sep 2018, at 07:12, Fabio Maino <mailto:fma...@cisco.com>> wrote:


I have incorporated the changes as discussed, so hopefully rev 6. can 
be used by reviewers before the telechat: 
https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt


Here is the diff: goo.gl/tCKD4A <http://goo.gl/tCKD4A>


I believe the following comments are still open. I'll work with the 
respective authors to address them in the next rev of the document.



A. [Deborah/Magnus] it is being discussed on a separate private 
thread if the following should be added to the IANA section:
"To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the registration of a 
new encapsulated payload MUST contain an analysis of how LISP-GPE 
SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
Congestion Notification (ECN) bits whenever they apply to the new 
encapsulated payload. The analysis for the new encapsulated payload 
registered in this document is in section 3.1."



B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired 
yesterday, and cannot be referenced. I'll add it back to section 3.1 
as soon as the draft is refreshed.


C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions 
for Ethernet Encapsulated Payloads


>>>The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to 
protect UDP, LISP and Ethernet headers against corruption.


So this is not the necessary documentation of the analysis that 
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
There needs to be an analysis here to verify that this protocol 
combination do work. You will actually have to discuss how the 
Ethernet encapsulation fulfills the requirements listed in Section 4 
of RFC 6936.


https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
analysis was included. I would also note the applicability 
limitations this has.


Which actually brings up an additional issue for Ethernet 
encapsulation. For IP the assumption is that the IP traffic that is 
encapsulated is congestion controlled. This assumption is even less 
certain when having Ethernet. Thus, some consideration of that issue 
is likely needed.


>>>When a LISP-GPE router performs Ethernet encapsulation, the inner 
802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 
mapped from the encapsulated frame to the Type of Service field in 
the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 
field as per guidelines provided by [RFC8325].


I don't know enough about IEEE and the various versions of Ethernet 
and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
to the 802.11 User Priorities discussed in RFC8325. Please 
investigate if they are the same, and if they are the same 
priorities, then make a explicit statement that they are applicable.


D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH 
Encapsulated Payloads


>>> The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to 
protect UDP, LISP, and NSH headers against corruption.


Same as for Ethernet also the NSH header needs to have a documented 
analsysis of fulfillment of the requirements.



Thanks,

Fabio






On 9/20/18 1:03 PM, Fabio Maino wrote:

Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev 
that I plan to publish later today.


I'll then work on the comments on this email and will send you the 
corresponding actions.


Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:


Hi Fabio,

Most of the below text is excellent. Some comments inline for 
needed clarifications and additions.


On 9/18/2018 9:52 PM, Fabio Maino wrote:

Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the sectio

Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05

[Fabio Maino]

I have incorporated the changes as discussed, so hopefully rev 6. can be 
used by reviewers before the telechat: 
https://www.ietf.org/id/draft-ietf-lisp-gpe-06.txt


Here is the diff: goo.gl/tCKD4A


I believe the following comments are still open. I'll work with the 
respective authors to address them in the next rev of the document.



A. [Deborah/Magnus] it is being discussed on a separate private thread 
if the following should be added to the IANA section:
"To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the registration of a new 
encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD 
deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion 
Notification (ECN) bits whenever they apply to the new encapsulated 
payload. The analysis for the new encapsulated payload registered in 
this document is in section 3.1."



B. [Magnus] draft-ietf-tsvwg-ecn-encap-guidelines has expired yesterday, 
and cannot be referenced. I'll add it back to section 3.1 as soon as the 
draft is refreshed.


C. [Magnus/Mirja] in 3.1.1 Payload Specific Transport Interactions for 
Ethernet Encapsulated Payloads


>>>The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to protect 
UDP, LISP and Ethernet headers against corruption.


So this is not the necessary documentation of the analysis that 
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
There needs to be an analysis here to verify that this protocol 
combination do work. You will actually have to discuss how the Ethernet 
encapsulation fulfills the requirements listed in Section 4 of RFC 6936.


https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
analysis was included. I would also note the applicability limitations 
this has.


Which actually brings up an additional issue for Ethernet encapsulation. 
For IP the assumption is that the IP traffic that is encapsulated is 
congestion controlled. This assumption is even less certain when having 
Ethernet. Thus, some consideration of that issue is likely needed.


>>>When a LISP-GPE router performs Ethernet encapsulation, the inner 
802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped 
from the encapsulated frame to the Type of Service field in the outer 
IPv4 header, or in the case of IPv6 the 'Traffic Class' field as per 
guidelines provided by [RFC8325].


I don't know enough about IEEE and the various versions of Ethernet and 
WLAN here to be certain that 802.1Q PCP's can be mapped directly to the 
802.11 User Priorities discussed in RFC8325. Please investigate if they 
are the same, and if they are the same priorities, then make a explicit 
statement that they are applicable.


D. [Magnus] 3.1.2 Payload Specific Transport Interactions for NSH 
Encapsulated Payloads


>>> The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to protect 
UDP, LISP, and NSH headers against corruption.


Same as for Ethernet also the NSH header needs to have a documented 
analsysis of fulfillment of the requirements.



Thanks,

Fabio






On 9/20/18 1:03 PM, Fabio Maino wrote:

Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev 
that I plan to publish later today.


I'll then work on the comments on this email and will send you the 
corresponding actions.


Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:


Hi Fabio,

Most of the below text is excellent. Some comments inline for needed 
clarifications and additions.


On 9/18/2018 9:52 PM, Fabio Maino wrote:

Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the section 3.1 below to specify the general transport 
requirements for the registration of new LISP-GPE payloads, and I 
will introduce two subsections to instantiate those requirements for 
Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the 
"IANA Considerations" section I'll refer to this new section 3.1 as 
a requirement for registration of new encapsulated payload.


"3.1 Payload Specific Transport Interactions

To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the specification of 
a new encapsulated payload MUST contain an analysis of how LISP-GPE 
SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
Congestion Notification (ECN) bits whenever they apply to the new 
encapsulated payload.


For IP payloads, section 

Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-gpe-05: (with DISCUSS and COMMENT)

[Fabio Maino]

Thanks for your notes Mirja.

I'll publish an updated rev this evening to consolidate the changes that 
I believe we have agreed upon, and then I'll work on those that are 
still open.


Please see below.


On 9/19/18 12:42 PM, Mirja Kühlewind wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lisp-gpe-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



--
DISCUSS:
--

Thanks for addressing the TSV-ART review (and Magnus for doing the review)! I
assume that the proposed text will be incorporated in the next version. (Would
have been even better if those (larger) changes would have been added before
the doc was put on the telechat; please update as soon as possible so other AD
can review that text as well).

However, I think the text still needs to say more about HOW the PCP should be
mapped to DSCPs. RFC8325 doesn't provide guidelines but a mapping for 802.11.
Is the same mapping applicable here?


Agree. As pointed out by Magnus' latest email there's more investigation 
needed here. I'll get back on this.




Also, I'm not an expert for that part, but I guess there also is further
guidance needed on HOW to map the VID...?


This is really straightforward, as the VID is a 12-bit field, and the 
IID is 24-bit. Implementation that I'm aware of typically carve a 
portion of the IID space to encode the VID.





--
COMMENT:
--

Given this doc uses the last reserved bit in the lisp header, I would really
like to see more discussion how the data plane lisp can still be extended. I
think the solution is straight-forward (define a shim layer for the extension
and announce this capability in the Map-Reply), however, spelling this out
seems to be appropriate for this doc.


Correct, that's the idea. I'll add a sentence that states that a 
lisp-gpe next protocol header can be used to extend the lisp data-plane 
functions.



Thanks,
Fabio






___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05

[Fabio Maino]

Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev that 
I plan to publish later today.


I'll then work on the comments on this email and will send you the 
corresponding actions.


Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:


Hi Fabio,

Most of the below text is excellent. Some comments inline for needed 
clarifications and additions.


On 9/18/2018 9:52 PM, Fabio Maino wrote:

Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the section 3.1 below to specify the general transport 
requirements for the registration of new LISP-GPE payloads, and I 
will introduce two subsections to instantiate those requirements for 
Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the 
"IANA Considerations" section I'll refer to this new section 3.1 as a 
requirement for registration of new encapsulated payload.


"3.1 Payload Specific Transport Interactions

To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the specification of a 
new encapsulated payload MUST contain an analysis of how LISP-GPE 
SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
Congestion Notification (ECN) bits whenever they apply to the new 
encapsulated payload.


For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] 
specifies how to handle UDP Checksums encouraging implementors to 
consider UDP checksum usage guidelines in section 3.4 of [RFC8085] 
when it is desirable to protect UDP and LISP headers against 
corruption. Each new encapsulated payloads, when registered with 
LISP-GPE, MUST be accompanied by a similar analysis.


Encapsulated payloads may have a priority field that may or may not 
be mapped to the DSCP field of the outer IP header (part of Type of 
Service in IPv4 or Traffic Class in IPv6). Such new encapsulated 
payloads, when registered with LISP-GPE, MUST be accompanied by an 
analysis similar to the one performed in Section 3.1.1 of this 
document for Ethernet payloads.


Encapsulated payloads may have Explicit Congestion Notification 
mechanisms that may or may not be mapped to the outer IP header ECN 
field. Such new encapsulated payolads, when registered with LISP-GPE, 
MUST  be accompanied by a set of guidelines derived from 
[draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].


The rest of this section specifies payload specific transport 
interactions considerations for the two new LISP-GPE encapsulated 
payloads specified in this document: Ethernet and NSH.


3.1.1 Payload Specific Transport Interactions for Ethernet 
Encapsulated Payloads


The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to 
protect UDP, LISP and Ethernet headers against corruption.


So this is not the necessary documentation of the analysis that 
IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
There needs to be an analysis here to verify that this protocol 
combination do work. You will actually have to discuss how the 
Ethernet encapsulation fulfills the requirements listed in Section 4 
of RFC 6936.


https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
analysis was included. I would also note the applicability limitations 
this has.


Which actually brings up an additional issue for Ethernet 
encapsulation. For IP the assumption is that the IP traffic that is 
encapsulated is congestion controlled. This assumption is even less 
certain when having Ethernet. Thus, some consideration of that issue 
is likely needed.





When a LISP-GPE router performs Ethernet encapsulation, the inner 
802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 
mapped from the encapsulated frame to the Type of Service field in 
the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 
field as per guidelines provided by [RFC8325].


I don't know enough about IEEE and the various versions of Ethernet 
and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
to the 802.11 User Priorities discussed in RFC8325. Please investigate 
if they are the same, and if they are the same priorities, then make a 
explicit statement that they are applicable.




When a LISP-GPE router performs Ethernet encapsulation, the inner 
header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 
used to determine the LISP Instance ID field.


3.1.2 Payload Specific Transport Interactions for NSH Encapsulated 
Payloads


The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to

Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05

[Fabio Maino]

Hi Magnus,
thanks for your comments.

I think I see the points you are making.

I'll add the section 3.1 below to specify the general transport 
requirements for the registration of new LISP-GPE payloads, and I will 
introduce two subsections to instantiate those requirements for Ethernet 
and NSH (section 4.2 and 4.3 will be moved here). In the "IANA 
Considerations" section I'll refer to this new section 3.1 as a 
requirement for registration of new encapsulated payload.


"3.1 Payload Specific Transport Interactions

To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the specification of a 
new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD 
deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion 
Notification (ECN) bits whenever they apply to the new encapsulated payload.


For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] specifies 
how to handle UDP Checksums encouraging implementors to consider UDP 
checksum usage guidelines in section 3.4 of [RFC8085] when it is 
desirable to protect UDP and LISP headers against corruption. Each new 
encapsulated payloads, when registered with LISP-GPE, MUST be 
accompanied by a similar analysis.


Encapsulated payloads may have a priority field that may or may not be 
mapped to the DSCP field of the outer IP header (part of Type of Service 
in IPv4 or Traffic Class in IPv6). Such new encapsulated payloads, when 
registered with LISP-GPE, MUST be accompanied by an analysis similar to 
the one performed in Section 3.1.1 of this document for Ethernet payloads.


Encapsulated payloads may have Explicit Congestion Notification 
mechanisms that may or may not be mapped to the outer IP header ECN 
field. Such new encapsulated payolads, when registered with LISP-GPE, 
MUST  be accompanied by a set of guidelines derived from 
[draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].


The rest of this section specifies payload specific transport 
interactions considerations for the two new LISP-GPE encapsulated 
payloads specified in this document: Ethernet and NSH.


3.1.1 Payload Specific Transport Interactions for Ethernet Encapsulated 
Payloads


The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to protect 
UDP, LISP and Ethernet headers against corruption.


When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q 
[IEEE.802.1Q_2014] priority code point (PCP) field MAY be mapped from 
the encapsulated frame to the Type of Service field in the outer IPv4 
header, or in the case of IPv6 the 'Traffic Class' field as per 
guidelines provided by [RFC8325].


When a LISP-GPE router performs Ethernet encapsulation, the inner header 
802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or used to 
determine the LISP Instance ID field.


3.1.2 Payload Specific Transport Interactions for NSH Encapsulated Payloads

The UDP Checksum considerations specified in section 5.3 of 
[draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
Implementors are encouraged to consider the UDP checksum usage 
guidelines in section 3.4 of [RFC8085] when it is desirable to protect 
UDP, LISP, and NSH headers against corruption.


When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN 
values MAY be mapped as specified for the Next Protocol encapsulated by 
NSH (namely IPv4, IPv6 and Ethernet)."



I will also add a paragraph to "Iana Considerations" that says:


"To ensure that protocols that are encapsulated in LISP-GPE will work 
well from a transport interaction perspective, the registration of a new 
encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD 
deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion 
Notification (ECN) bits whenever they apply to the new encapsulated 
payload. The analysis for the new encapsulated payload registered in 
this document is in section 3.1."


Please, let me know if this address your comments.

Thanks,
Fabio



On 8/29/18 2:17 AM, Magnus Westerlund wrote:

Reviewer: Magnus Westerlund
Review result: Not Ready

This document has been reviewed as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG for their information and to allow them to address any issues
raised.

When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always cctsv-...@ietf.org  if you reply to or forward this review.

Issue A.

The reason I state Not Ready has to do with this documents failure to consider
the use of zero checksum for IPv6 when tunneling other things than

Re: [lisp] Call for adoption of draft-farinacci-lisp-ecdsa-auth-03.txt

[Fabio Maino]

support.

Fabio

On 9/5/18 12:46 AM, Luigi Iannone wrote:

Folks,

As you can see from Dino’s email (below) the authors are requesting 
that the document


https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/

be adopted as WG item.

This email starts the usual 14 days call for adoption, this call will 
end on

Thursday the 19th September, 2018.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, 
please
also indicate if you are able and willing to either contribute to, 
or review, (or both) the draft.


Sitting in silence does not indicate support, please respond 
appropriately.


The Chairs
Joel & Luigi


On 4 Sep 2018, at 21:05, Dino Farinacci > wrote:


Folks, here is an update that reflects comments we received at the 
Montreal presentation:




A diff file is included for your convenience.

At this time, I would like to request this document for working group 
adoption.


Thanks,
Dino/Erik





Begin forwarded message:

*From: *internet-dra...@ietf.org 
*Subject: **I-D Action: draft-farinacci-lisp-ecdsa-auth-03.txt*
*Date: *September 4, 2018 at 12:00:14 PM PDT
*To: *mailto:i-d-annou...@ietf.org>>
*Reply-To: *internet-dra...@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



   Title   : LISP Control-Plane ECDSA Authentication and 
Authorization

   Authors : Dino Farinacci
 Erik Nordmark
Filename    : draft-farinacci-lisp-ecdsa-auth-03.txt
Pages   : 17
Date    : 2018-09-04

Abstract:
  This draft describes how LISP control-plane messages can be
  individually authenticated and authorized without a a priori shared-
  key configuration.  Public-key cryptography is used with no new PKI
  infrastructure required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farinacci-lisp-ecdsa-auth/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-farinacci-lisp-ecdsa-auth-03
https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-ecdsa-auth-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-ecdsa-auth-03


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


___
lisp mailing list
lisp@ietf.org 
https://www.ietf.org/mailman/listinfo/lisp




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-ietf-lisp-rfc6830bis-14

[Fabio Maino]

Looks good Dino.

Noted one nit in section 18, not worth spinning a new version IMO:

"The is 1 remaining bit" -> "The 1 remaining bit"

Fabio


On 8/20/18 11:42 AM, Dino Farinacci wrote:

WG, here is a diff with changes to reflect Scott’s comment. I wanted the list 
of implementator to-be-aware changes to get working group quick review.

I’m about to add a “Changes since RFC 6833” section to RFC 6833bis as well.

Thanks,
Dino





On Aug 20, 2018, at 9:03 AM, Scott O. Bradner  wrote:

a specific section only dealing with the changes since the RFC is best

there is too much noise in the per iteration log (which as you already note 
should be removed)

Scott


On Aug 20, 2018, at 8:57 AM, Dino Farinacci  wrote:

Note we do have a Document Change Log in Appendix B detailing the changes put 
in each version starting with RFC6830. Would that suffice? Or you still think a 
specific section is required?

Dino




On Aug 20, 2018, at 8:44 AM, Scott O. Bradner  wrote:

it would be best to have a section called “changes since RFC 6830” so there is 
no ambiguity that the section covers the changes

it would be fine to have that section just say “See  “Implementation 
Considerations.”

Scott



On Aug 20, 2018, at 8:26 AM, Dino Farinacci  wrote:



Hi Dino

On Aug 20, 2018, at 8:18 AM, Dino Farinacci  wrote:

There were little changes that an implementor would need to know about for the 
data-plane. But there were for the control-plane (i.e. RFC6833bis). But in 
either case, we’ll add a section in each bis document.

thanks - even if the section says “nothing to worry about” it will be useful

I’ll title it “Implementation Considerations” and place it between 17 and 18?

14. Multicast Considerations  . . . . . . . . . . . . . . . . . .  29
15. Router Performance Considerations . . . . . . . . . . . . . .  30
16. Security Considerations . . . . . . . . . . . . . . . . . . .  31
17. Network Management Considerations . . . . . . . . . . . . . .  32
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32



Are you going to be reviewer for 6833bis as well?

not assigned that yet but I will take a look

I will try to get the sections done in the next day or so. I’m at the 3GPP 
meetings this week.

Dino


Scott

Dino


On Aug 20, 2018, at 6:14 AM, Scott O. Bradner  wrote:

I was just assigned to do a ops-dir review of  draft-ietf-lisp-rfc6830bis-14

this is not the review - that will come soon

but since this is a “bis” document that is to replace an existing RFC it needs 
to have a
“changes since RFC 6830” section so that implementors of the earlier RFC will 
be able to tell
what they need to change to bring their code up to date without having to 
compare the
RFCs line by line (and likely miss something)

Scott



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04

[Fabio Maino]

Hi Adrian,
here is the updated draft that should address all your comments: 
https://tools.ietf.org/html/draft-ietf-lisp-gpe-05.


Rfcdiff pointer: https://goo.gl/bMbRvC

Please let me know if you have any other suggestion.

Thanks again,
Fabio

On 8/15/18 11:30 AM, Adrian Farrel wrote:

Hi Fabio,

That additional text is helpful, thanks.

Adrian


-Original Message-
From: Fabio Maino [mailto:fma...@cisco.com]
Sent: 15 August 2018 19:15
To: Adrian Farrel; rtg-...@ietf.org
Cc: lisp@ietf.org; i...@ietf.org; draft-ietf-lisp-gpe@ietf.org
Subject: Re: Rtgdir last call review of draft-ietf-lisp-gpe-04

Hi Adrian,
thanks for such a detailed review.

I went through your comments and I can incorporate all of them into a
new version of the draft.

Wrt the reduction in size of the Map-Versioning and Nonce fields, I
could add in Section 3, right after the definition of the encoding of
those fields, the following:


The encoding of the Nonce field in LISP-GPE, compared with the one
used in RFC6830bis for the LISP data plane encapsulation, reduces the
length of the nonce from 24 to 16 bits. As per RFC6830bis, ITRs are
required to generate different nonces when sending to different RLOCs,
but the same nonce can be used for a period of time when encapsulating
to the same ETR. The use of 16 bits nonces still allows  an ITR to
determine to and from reachability for up to 64k RLOCs at the same time.

Similarly, the encoding of the Source and Dest Map-Version fields,
compared with RFC6830bis, is reduced from 12 to 8 bits. This still
allows to associate 256 different versions to each EID-to-RLOC mapping
to inform commmunicating ITRs and ETRs about modifications of the
mapping.



Either Deborah, Joel, or Luigi: if you could please confirm that it is
ok to publish a new version of the draft at this point, I'll update it
right away.

Thanks,
Fabio




On 8/9/18 9:05 AM, Adrian Farrel wrote:

Reviewer: Adrian Farrel
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them as normal review comments. I believe

that

this review comes between WG publication and the start of IETF last call - you
may wish to discuss with your AD whether to treat these comments separately

or

as part of IETF last call.

Document: draft-ietf-lisp-gpe-04.txt
   Reviewer: Adrian Farrel
   Review Date: 9-August-2018
   IETF LC End Date: No known
   Intended Status: Standards Track

Summary
I have significant concerns about this document and recommend that the

Routing

ADs discuss these issues further with the authors. The issues are not
substantially technical in nature, but do indicate the need for significant
reworking of the text. I have tried to make suggestions for new text.

Comments:

This document specifies an alternate LISP header format that can be used to
allow LISP to carry payloads other than IP. A new capabilities flag is defined
so that routers know whether this new format is supported, and a new flag in
the header itself indicates when the new format is in use.

The document is clear and readable, but has some issues of presentation that
could close a few potential misunderstandings and thus improve implmentation
prospects.

No attempt is made in the document to explain how/why the reduction in size

of

some standard LISP header fields is acceptable. For example, if

implementations

of this spec can safely operate with a 16 bit Nonce or 8 bit Map-Versions, why
does 6830/6830bis feel the need for 24 and 12 bit fields rspectively?

===Major Issues===

Section 3 has a mix of minor and leess minor issues...

OLD
 This document defines the following changes to the LISP header in
 order to support multi-protocol encapsulation:

 P Bit:  Flag bit 5 is defined as the Next Protocol bit.  The P bit
MUST be set to 1 to indicate the presence of the 8 bit next
protocol field.

P = 0 indicates that the payload MUST conform to LISP as defined
in [I-D.ietf-lisp-rfc6830bis].  Flag bit 5 was chosen as the P bit
because this flag bit is currently unallocated.

 Next Protocol:  The lower 8 bits of the first 32-bit word are used to
carry a Next Protocol.  This Next Protocol field contains the
protocol of the encapsulated payload packet.

LISP uses the lower 24 bits of the first word for either a nonce,
an echo-nonce, or to support map-versioning
[I-D.ietf-lisp-6834bis].  These are all optional capabilities that
are indicat

Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04

[Fabio Maino]

Hi Adrian,
thanks for such a detailed review.

I went through your comments and I can incorporate all of them into a 
new version of the draft.


Wrt the reduction in size of the Map-Versioning and Nonce fields, I 
could add in Section 3, right after the definition of the encoding of 
those fields, the following:


The encoding of the Nonce field in LISP-GPE, compared with the one 
used in RFC6830bis for the LISP data plane encapsulation, reduces the 
length of the nonce from 24 to 16 bits. As per RFC6830bis, ITRs are 
required to generate different nonces when sending to different RLOCs, 
but the same nonce can be used for a period of time when encapsulating 
to the same ETR. The use of 16 bits nonces still allows  an ITR to 
determine to and from reachability for up to 64k RLOCs at the same time.


Similarly, the encoding of the Source and Dest Map-Version fields, 
compared with RFC6830bis, is reduced from 12 to 8 bits. This still 
allows to associate 256 different versions to each EID-to-RLOC mapping 
to inform commmunicating ITRs and ETRs about modifications of the 
mapping.





Either Deborah, Joel, or Luigi: if you could please confirm that it is 
ok to publish a new version of the draft at this point, I'll update it 
right away.


Thanks,
Fabio




On 8/9/18 9:05 AM, Adrian Farrel wrote:

Reviewer: Adrian Farrel
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them as normal review comments. I believe that
this review comes between WG publication and the start of IETF last call - you
may wish to discuss with your AD whether to treat these comments separately or
as part of IETF last call.

Document: draft-ietf-lisp-gpe-04.txt
  Reviewer: Adrian Farrel
  Review Date: 9-August-2018
  IETF LC End Date: No known
  Intended Status: Standards Track

Summary
I have significant concerns about this document and recommend that the Routing
ADs discuss these issues further with the authors. The issues are not
substantially technical in nature, but do indicate the need for significant
reworking of the text. I have tried to make suggestions for new text.

Comments:

This document specifies an alternate LISP header format that can be used to
allow LISP to carry payloads other than IP. A new capabilities flag is defined
so that routers know whether this new format is supported, and a new flag in
the header itself indicates when the new format is in use.

The document is clear and readable, but has some issues of presentation that
could close a few potential misunderstandings and thus improve implmentation
prospects.

No attempt is made in the document to explain how/why the reduction in size of
some standard LISP header fields is acceptable. For example, if implementations
of this spec can safely operate with a 16 bit Nonce or 8 bit Map-Versions, why
does 6830/6830bis feel the need for 24 and 12 bit fields rspectively?

===Major Issues===

Section 3 has a mix of minor and leess minor issues...

OLD
This document defines the following changes to the LISP header in
order to support multi-protocol encapsulation:

P Bit:  Flag bit 5 is defined as the Next Protocol bit.  The P bit
   MUST be set to 1 to indicate the presence of the 8 bit next
   protocol field.

   P = 0 indicates that the payload MUST conform to LISP as defined
   in [I-D.ietf-lisp-rfc6830bis].  Flag bit 5 was chosen as the P bit
   because this flag bit is currently unallocated.

Next Protocol:  The lower 8 bits of the first 32-bit word are used to
   carry a Next Protocol.  This Next Protocol field contains the
   protocol of the encapsulated payload packet.

   LISP uses the lower 24 bits of the first word for either a nonce,
   an echo-nonce, or to support map-versioning
   [I-D.ietf-lisp-6834bis].  These are all optional capabilities that
   are indicated in the LISP header by setting the N, E, and the V
   bit respectively.

   When the P-bit and the N-bit are set to 1, the Nonce field is the
   middle 16 bits.

   When the P-bit and the V-bit are set to 1, the Version field is
   the middle 16 bits.

   When the P-bit is set to 1 and the N-bit and the V-bit are both 0,
   the middle 16-bits are set to 0.

   This document defines the following Next Protocol values:

   0x1 :  IPv4

   0x2 :  IPv6

   0x3 :  Ethernet

   0x4 :  Network Service Header [RFC8300]

 0   1   2  

Re: [lisp] WG Last Call for draft-ietf-lisp-vendor-lcaf

[Fabio Maino]

I support handing this document to the AD.

It's pretty straightforward, and I'm aware of implementations that plan 
to take advantage of this feature.


Fabio

On 7/6/18 6:06 AM, Luigi Iannone wrote:

Folks,

As Alberto mentioned in a previous mail, in London there was consensus 
to move forward draft-ietf-lisp-vendor-lcaf 
[https://tools.ietf.org/html/draft-ietf-lisp-vendor-lcaf-02] (after 
the few fixes that I asked).


Fixes are done, hence, this email starts the usual two weeks WG Last 
Call, to end July 20th, 2018.


Please review this WG document and let the WG know if you agree that 
it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain 
what it would take to address your concerns.


Thanks

Luigi & Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] The LISP WG has placed draft-iannone-6834bis in state "In WG Last Call"

[Fabio Maino (fmaino)]

Support.

Fabio

On May 21, 2018 8:43 AM, IETF Secretariat  
wrote:

The LISP WG has placed draft-iannone-6834bis in state
In WG Last Call (entered by Joel Halpern)

The document is available at
https://datatracker.ietf.org/doc/draft-iannone-6834bis/

Comment:
A small delta to bring RFC 6834 to proposed Standards.  Going directly to WG
last call to avoid slowing down other work, and because it is so small.
Please do speak up, either with support or objection.

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-rfc6830bis-12

[Fabio Maino]

I support handing the LISP dataplane document  to the AD.

I recommend that, as was agreed at the last IETF, draft-ietf-lisp-gpe 
quickly follows  so we can have multiprotocol support standardized as well.


Thanks,
Fabio


On 4/5/18 7:17 AM, Luigi Iannone wrote:

Hi All,

During our last meeting it was apparent that the work on the LISP 
document [https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-12 
]

seems done and the document ready for WG Last Call.

This email starts the usual two weeks WG Last Call, to end April 20th, 
2018.


Please review this WG document and let the WG know if you agree that 
it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain 
what it would take to address your concerns.


Thanks

Luigi & Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-rfc6833bis-10

[Fabio Maino]

I have read the document and I think it's ready to be handed to the AD.

I feel the document does a very good job of describing the LISP CP, and 
addresses the issues that were raised by the WG.


Thanks,
Fabio

On 4/5/18 7:35 AM, Luigi Iannone wrote:

Hi All,

During our last meeting it was apparent that the work on the LISP 
document  [https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-10]

seems done and the document ready for WG Last Call.

This email starts the usual two weeks WG Last Call, to end April 20th, 
2018.


Please review this WG document and let the WG know if you agree that 
it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain 
what it would take to address your concerns.


Thanks

Luigi & Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] MS-SMR draft

[Fabio Maino]

I agree with Dino.

Fabio

On 4/6/18 8:07 AM, Dino Farinacci wrote:

Well it wasn’t a previous WG solution. It was an individual submission that one 
vendor implemented. Since the WG supports pubsub going forward, I think a 
forward pointer from the individual submission to the WG document is sufficient.

Dino


On Apr 6, 2018, at 1:04 AM, Luigi Iannone  wrote:

Hi,

I was wondering….. why not putting this as an appendix in the pubsub document? 
Stating that was the previous solution for what pubs does and that is kept in 
appendix as informational material.

any thoughts?

L.



On 5 Apr 2018, at 23:17, Alberto Rodriguez-Natal  
wrote:

Sounds good to me Dino. I'll wait for the adoption call of lisp-pubsub to end 
and will update this document as appropriate.

Thanks,
Alberto

On Thu, Apr 5, 2018 at 9:47 AM, Dino Farinacci  wrote:
Just one editorial comment Alberto. If the pubsub draft is about to be a 
working group document, maybe this document should point to 
draft-ietf-lisp-pubsub-00?

Dino


On Apr 4, 2018, at 11:49 PM, Alberto Rodriguez-Natal  
wrote:

Hi all,

We have just posted an updated version of the MS-originated SMRs draft [1]. The 
revised document discusses how/when the MS is supposed to send SMRs and 
includes a note pointing to draft-rodrigueznatal-lisp-pubsub as the preferred 
PubSub mechanism.

Let us know if you have any comment. As discussed in London, we would like to 
move forward with this as informational (and preferably as a WG item).

Thanks,
Alberto

[1] https://tools.ietf.org/html/draft-rodrigueznatal-lisp-ms-smr-06

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-gpe-03

[Fabio Maino]

As an author, I support handing over this document to the AD.



Fabio

On 4/5/18 7:08 AM, Luigi Iannone wrote:

Hi All,

During our last meeting, the authors of the LISP GPE document 
 [https://tools.ietf.org/html/draft-ietf-lisp-gpe-03]
asked for Last Call. The room showed consensus and no objections were 
raised.


This email starts the usual two weeks WG Last Call, to end April 20th, 
2018.


Please review this WG document and let the WG know if you agree that 
it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain 
what it would take to address your concerns.


Thanks

Luigi & Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP-GPE Review

[Fabio Maino]

I have published rev -03 
(https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/) that fixes a 
couple of nits identified by Joel.


Changes are highlighted in the attached file.

Thanks,
Fabio



On 3/30/18 3:53 PM, Fabio Maino wrote:
I have updated the lisp-gpe draft 
(https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/) to reflect 
Luigi's comments as discussed in London.


Let me know if you have other comments. If not, this should be ready 
for last call.



Thanks,
Fabio


On 3/8/18 6:05 AM, Luigi Iannone wrote:

Hi All,

I read the LISP-GPE document.
Hereafter you can find my comments.

Ciao

L.







Internet Engineering Task Force D. 
Lewis
Internet-Draft 
Cisco
Intended status: Standards Track    J. 
Lemon
Expires: September 6, 2018  
Broadcom

P. Agarwal
Innovium
L. Kreeger

 P. 
Quinn
 M. 
Smith
 N. 
Yadav
    F. 
Maino, Ed.

Cisco
March 05, 2018


 LISP Generic Protocol Extension
  draft-ietf-lisp-gpe-01

Abstract

    This draft describes extending the Locator/ID Separation Protocol
    (LISP),

I would add “Data-Plane” .


via changes to the LISP header, to support multi-protocol
    encapsulation.

Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current 
Internet-

    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six 
months
    and may be updated, replaced, or obsoleted by other documents at 
any

    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on September 6, 2018.

Copyright Notice

    Copyright (c) 2018 IETF Trust and the persons identified as the
    document authors.  All rights reserved.





Lewis, et al.   Expires September 6, 2018   
[Page 1]

Internet-Draft   LISP Generic Protocol Extension March 2018


    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with 
respect
    to this document.  Code Components extracted from this document 
must

    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Table of Contents

    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . 
.   2
  1.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . 
.   3
  1.2.  Definition of Terms . . . . . . . . . . . . . . . . . . 
.   3
    2.  LISP Header Without Protocol Extensions . . . . . . . . . . 
.   3
    3.  Generic Protocol Extension for LISP (LISP-GPE)  . . . . . . 
.   3
    4.  Backward Compatibility  . . . . . . . . . . . . . . . . . . 
.   5
  4.1.  Type of Service . . . . . . . . . . . . . . . . . . . . 
.   5
  4.2.  VLAN Identifier (VID) . . . . . . . . . . . . . . . . . 
.   5
    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 
.   5
    6.  Security Considerations . . . . . . . . . . . . . . . . . . 
.   5
    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 
.   6
    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . 
.   6
  8.1.  Normative References  . . . . . . . . . . . . . . . . . 
.   6
  8.2.  Informative References  . . . . . . . . . . . . . . . . 
.   7
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . 
.   7


1.  Introduction

    LISP, as defined in [RFC6830]
I would not cite 6830 in this document. The document defining the 
standard is 6830bis, hence I would refer only to the latter.



and extended in
    [I-D.ietf-lisp-rfc6830bis], defines an encapsulation format that
    carries IPv4 or IPv6 (henceforth referred to as IP) packets in a 
LISP

    header and outer UDP/IP transport.

    The LISP header does not specify the protocol being encapsulated 
and

    therefore is currently limited to encapsulating only IP packet
    payloads.  Other protocols, most notably VXLAN [RFC7348] (which
    defines a similar header format to LISP), are used to 
enca

Re: [lisp] The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state "Call For Adoption By WG Issued"

[Fabio Maino]

As an author, I support adoption of this document.

This is an important and much needed extension of the LISP protocol that 
enable publish subscribe functionalities.


Fabio

On 4/3/18 6:14 PM, IETF Secretariat wrote:

The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state
Call For Adoption By WG Issued (entered by Joel Halpern)

The document is available at
https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-pubsub/

Comment:
As requested by the authors, calling for WG adoption.



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP-GPE Review

[Fabio Maino]

ve.

[RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
   "Network Service Header (NSH)", RFC 8300,
   DOI 10.17487/RFC8300, January 2018, <https://www.rfc-
   editor.org/info/rfc8300>.








Lewis, et al.   Expires September 6, 2018   [Page 6]
Internet-Draft   LISP Generic Protocol Extension  March 2018


8.2.  Informative References



This is Authoritative.

[I-D.ietf-lisp-rfc6830bis]
   Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
   Cabellos-Aparicio, "The Locator/ID Separation Protocol
   (LISP)", draft-ietf-lisp-rfc6830bis-10 (work in progress),
   March 2018.

Authors' Addresses

Darrel Lewis
Cisco Systems

Email: darle...@cisco.com


John Lemon
Broadcom
3151 Zanker Road
San Jose, CA  95134
USA

Email: john.le...@broadcom.com


Puneet Agarwal
Innovium
USA

Email: pun...@acm.org


Larry Kreeger
USA

Email: lkree...@gmail.com


Paul Quinn
Cisco Systems

Email: pa...@cisco.com


Michael Smith
Cisco Systems

Email: michs...@cisco.com



Lewis, et al.   Expires September 6, 2018   [Page 7]
Internet-Draft   LISP Generic Protocol Extension  March 2018


Navindra Yadav
Cisco Systems

Email: nya...@cisco.com


Fabio Maino (editor)
Cisco Systems
San Jose, CA  95134
USA

Email: fma...@cisco.com







































Lewis, et al.   Expires September 6, 2018   [Page 8]

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] New name for upcoming LISP -OAM- document

[Fabio Maino]

I suggest "Considerations on LISP Mobility, Deployment and Traceroute" 
that puts a little less emphasis on mobility.


I second Luigi's call to get done with this document and move on.


Thanks,
Fabio

On 3/19/18 4:25 PM, Luigi Iannone wrote:

Hi All,

during today f2f meeting concern has been expressed about the name to use for 
the document that will collect what is neither data-plane nor control-plane.

The name OAM was found not accurate because the document will not cover all of 
what is normally in a OAM document.

The suggested name is “LISP Mobility, Deployment and Traceroute considerations”.

The chairs would like to hear from the mailing list if there is any objection 
or you have a better name to suggest.

Please send an email by the end of the week.

Thanks

Jole and Luigi
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Confirm/Deny changes on draft 6830bis

[Fabio Maino]

On 1/12/18 8:20 AM, Albert Cabellos wrote:

Hi all

As editor of 6830bis I´d like to confirm or deny the following changes 
which I believe have support.


Please note that I have intentionally ignored minor/editorial changes 
to help sync all the participants. I hope that the list below captures 
the most relevant ones.


Also note that I don´t necessarily agree with all the changes listed 
below, but that´s an opinion with a different hat.


WG: Please CONFIRM or DENY:

---

A.- Remove definitions of PA and PI

confirm.

I think one of the goals of the charter was to to open up to a broad set 
of use cases where that terminology might not be meaningful.




B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ 
and ‘identifier of the underlay’ respectively.


personally, I'm not keen to this change of terminology.

EID and RLOC have become of common use, and well understood, even 
outside of the LISP circles. I've often assisted to conversations in 
non-LISP groups where people use the term LISP EID/RLOC to qualify IP 
addresses in the overlay/underlay.





C.- In section 5.3, change the description of the encap/decap 
operation concerning how to deal with ECN and DSCP bits to (new text 
needs to be validated by experts):


When doing ITR/PITR encapsulation:

o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
the case of IPv6) SHOULD be copied from the inner-header 'Time to
Live' field.

o  The outer-header 'Differentiated Services Code Point' (DSCP)
field (or the 'Traffic Class' field, in the case of IPv6) SHOULD
be copied from the inner-header DSCP field ('Traffic Class' field,
in the case of IPv6) considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and
7 of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC3168]. ITR
encapsulation MUST copy the 2-bit 'ECN' field from the inner
header to the outer header. Re-encapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the new outer header.

When doing ETR/PETR decapsulation:

 o  The inner-header 'Time to Live' field (or 'Hop Limit' field,
in the case of IPv6) SHOULD be copied from the outer-header 'Time
to Live' field, when the Time to Live value of the outer header is
less than the Time to Live value of the inner header.  Failing to
perform this check can cause the Time to Live of the inner header
to increment across encapsulation/decapsulation cycles.  This
check is also performed when doing initial encapsulation, when a
packet comes to an ITR or PITR destined for a LISP site.

o  The inner-header 'Differentiated Services Code Point' (DSCP)
field (or the 'Traffic Class' field, in the case of IPv6) SHOULD
be copied from the outer-header DSCP field ('Traffic Class' field,
in the case of IPv6) considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and
7 of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC3168]. If
the 'ECN' field contains a congestion indication codepoint (the
value is '11', the Congestion Experienced (CE) codepoint), then
ETR decapsulation MUST copy the 2-bit 'ECN' field from the
stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR.  These requirements preserve
CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between
the tunnel endpoints.

Note that if an ETR/PETR is also an ITR/PITR and chooses to
re-encapsulate after decapsulating, the net effect of this is that
the new outer header will carry the same Time to Live as the old
outer header minus 1.

Copying the Time to Live (TTL) serves two purposes: first, it
preserves the distance the host intended the packet to travel;
second, and more importantly, it provides for suppression of
looping packets in the event there is a loop of concatenated
tunnels due to misconfiguration.  See Section 18.3 for TTL
exception handling for traceroute packets.



Confirm.


D.- Simplify section ‘Router Locator Selection’ stating that the 
data-plane MUST follow what´s stored in the map-cache (priorities and 
weights), the remaining text should go to an OAM document.

Confirm on the section semplification.

Wrt putting the rest in a separate OAM document, I don't have a strong 
opinion. Probably not having a new document requires less work to be 
done that makes me lean toward NOT having a new OAM document.




E.- Rewrite Section “Routing Locator Reachability” considering the 
following changes:


*    Keep bullet point 1 (examine LSB), 6 (receiving a
data-packet) and Echo-Nonce
*    Move to 

Re: [lisp] Adoption call: draft-lewis-lisp-gpe-04.txt

[Fabio Maino]

As an author I support the adoption of this document.

This simple LISP dataplane extension enables multiprotocol support in 
LISP. It allows use of LISP in L2 overlays, and introduces the 
capability to support dataplane extensions such as Network Service 
Header or Group Based Policy.


This is bit-by-bit compatible with RFC6830bis and allows the use of 
Map-Versioning and Echo-Noncing, albeit with a reduced size of the 
corresponding dataplane metadata.


An earlier version of the draft has been implemented in the FD.io 
(http://FD.io) and OOR (https://www.openoverlayrouter.org/) open source 
data plane implementations.


Thanks,
Fabio



On 12/15/17 8:23 AM, Joel Halpern wrote:
The authors of the lisp-gpe draft (below) have requested working group 
adoption for this document.


This email starts a two week last call for working group adoption of 
this document.


Please respond, positively or negatively.  Silence does NOT mean 
consent.  Please include explanation / motivation / reasoning for your 
view.


Also remember that this is not a last call.  Once the document is 
adopted (assuming it is), we as a working group can make changes as 
needed.  The primary quesitonin this call is whether this is a good 
basis for work we want to do.


Thank you,
Joel (& Luigi)


 Forwarded Message 
Subject: I-D Action: draft-lewis-lisp-gpe-04.txt
Date: Fri, 15 Dec 2017 08:13:24 -0800
From: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



    Title   : LISP Generic Protocol Extension
    Authors : Darrel Lewis
  John Lemon
  Puneet Agarwal
  Larry Kreeger
  Paul Quinn
  Michael Smith
  Navindra Yadav
      Fabio Maino
Filename    : draft-lewis-lisp-gpe-04.txt
Pages   : 8
Date    : 2017-12-15

Abstract:
   This draft describes extending the Locator/ID Separation Protocol
   (LISP), via changes to the LISP header, to support multi-protocol
   encapsulation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lewis-lisp-gpe/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-lewis-lisp-gpe-04
https://datatracker.ietf.org/doc/html/draft-lewis-lisp-gpe-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-lewis-lisp-gpe-04


Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

right.

Up to now the authors of the related documents have made an effort to 
keep the Next Protocol registries aligned, but it would be nice to have 
a single registry for the three applications.


Fabio

On 12/15/17 8:26 AM, Joel M. Halpern wrote:

I have issued the adoption call.

There is one obvious question that does not block adoption, but does 
block completion.  Is there some way we can use a common registry for 
the next protocol field for this, vxlan gpe, and NSH?


Yours,
Joel

On 12/15/17 11:17 AM, Fabio Maino wrote:

Sounds good Luigi.

I have just updated 
https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 that has now an 
intended status of standard track.


We are ready for WG adoption.

Thanks,
Fabio

On 12/15/17 1:08 AM, Luigi Iannone wrote:



On 14 Dec 2017, at 19:28, Fabio Maino  wrote:

On 12/14/17 10:11 AM, Joel M. Halpern wrote:

Let's separate things:

1) We can have a call for adoption of LISP GPE.  Meetings are not 
special in terms of working group formal actions.
agree. Doing it seems to be helpful whatever the WG decides to do 
with 6830bis.

That works for me.

2) My personal read is that if we assign the bit a meaning in 
6830bis, then the reference has to be normative, as a reader 
seeking to understand the RFC would need to read the other 
document to know what the bit meant.  (My thanks to Luigi for 
catching this.)

Sounds reasonable, the reference should be normative then.

Now, there are other drafts in the normative section: once GPE is 
adopted we would be in the same situation, and we could deal with 
it in the same way we do for the others.


That is not correct. As part of my review (Send it out later today) 
I have seen that a lot of references that are declared Normative are 
actually not at all so.


The only Normative reference which is in draft status is 6833bis, 
which is a different matter.


So the way to proceed is:

Mark the bit reserved in 6830bis and say nothing. Nobody can 
allocate the bit without WG consensus, hence there is risk in 
proceeding this way.


Adopt LISP-GPE which will be  a self contained document allocating 
the bit.


Ciao

Luigi



2') I see no reason why the bit should be assigned in 6830bis.  As 
long as we leave it reserved in 6830bis, LISP-GPE can assign it. 
That is what RFCs and registries are for.
It would be helpful to document all the LISP  dataplane features in 
6830bis. I think this  was one of the goals of having a dataplane 
document.


Since we are so close, and there's consensus, if 1 and 2 above 
makes sense the WG could start the call for adoption of GPE asap. 
If that works the WG could then proceed with the last call for 
6830bis.


Fabio


So my personal preference would be to leave the protocol 
identification bit out of 6830bis.


Yours,
Joel

On 12/14/17 12:59 PM, Fabio Maino wrote:
Since there seem to be consensus, can we ask for WG adoption of 
LISP-GPE and include it as an informative reference as the other 
drafts that are in 6830bis?


Can the chairs open a call for adoption in the mailing list, or 
do we need to wait the next IETF?


This might be similar to what Dino proposes below.

Thanks,
Fabio

On 12/14/17 9:01 AM, Dino Farinacci wrote:
I would prefer to not merge the two documents. Should we say in 
RFC6830bis that the R-bit is already allocated but don’t way why 
and make no reference. If no, I go for option A.


Dino


On Dec 14, 2017, at 2:58 AM, Luigi Iannone  wrote:

His All,

happy to see so much consensus :-)



As a chair I have to point out that if you add text in 6830bis 
to allocate the last bit and refer to draft-lewis-lisp-gpe you 
are creating an authoritative dependency on a to a document 
that as for now is not even WG item.
This will block the publication of 6830bis as RFC (remember the 
intro document…….).


There are two possible solutions:

A. 6830bis remains unchanged, leaving the P-bit marked as 
reserved for future use. draft-lewis-lisp-gpe will than 
allocate this last bit and detail the operations.


B. We merge the two documents.

I do not have a preference, up to the WG to decide, but better 
to avoid document dependencies that will block publication.




Ciao

L.




On 29 Nov 2017, at 23:32, Fabio Maino  wrote:

I would like to suggest a way to address mutiprotocol support 
in RFC6830bis, that may address what was discussed in Singapore.
This is based on using the last reserved bit in the LISP 
header as P bit to indicate support for multiprotocol 
encapsulation, as specified in the LISP-GPE draft 
(https://tools.ietf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol    |
 I \ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S / | Instance 
ID/Locator-Status-Bits   |
 P 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

Sounds good Luigi.

I have just updated https://tools.ietf.org/html/draft-lewis-lisp-gpe-04 
that has now an intended status of standard track.


We are ready for WG adoption.

Thanks,
Fabio

On 12/15/17 1:08 AM, Luigi Iannone wrote:



On 14 Dec 2017, at 19:28, Fabio Maino  wrote:

On 12/14/17 10:11 AM, Joel M. Halpern wrote:

Let's separate things:

1) We can have a call for adoption of LISP GPE.  Meetings are not special in 
terms of working group formal actions.

agree. Doing it seems to be helpful whatever the WG decides to do with 6830bis.

That works for me.


2) My personal read is that if we assign the bit a meaning in 6830bis, then the 
reference has to be normative, as a reader seeking to understand the RFC would 
need to read the other document to know what the bit meant.  (My thanks to 
Luigi for catching this.)

Sounds reasonable, the reference should be normative then.

Now, there are other drafts in the normative section: once GPE is adopted we 
would be in the same situation, and we could deal with it in the same way we do 
for the others.


That is not correct. As part of my review (Send it out later today) I have seen 
that a lot of references that are declared Normative are actually not at all so.

The only Normative reference which is in draft status is 6833bis, which is a 
different matter.

So the way to proceed is:

Mark the bit reserved in 6830bis and say nothing. Nobody can allocate the bit 
without WG consensus, hence there is risk in proceeding this way.

Adopt LISP-GPE which will be  a self contained document allocating the bit.

Ciao

Luigi




2') I see no reason why the bit should be assigned in 6830bis.  As long as we 
leave it reserved in 6830bis, LISP-GPE can assign it. That is what RFCs and 
registries are for.

It would be helpful to document all the LISP  dataplane features in 6830bis. I 
think this  was one of the goals of having a dataplane document.

Since we are so close, and there's consensus, if 1 and 2 above makes sense the 
WG could start the call for adoption of GPE asap. If that works the WG could 
then proceed with the last call for 6830bis.

Fabio



So my personal preference would be to leave the protocol identification bit out 
of 6830bis.

Yours,
Joel

On 12/14/17 12:59 PM, Fabio Maino wrote:

Since there seem to be consensus, can we ask for WG adoption of LISP-GPE and 
include it as an informative reference as the other drafts that are in 6830bis?

Can the chairs open a call for adoption in the mailing list, or do we need to 
wait the next IETF?

This might be similar to what Dino proposes below.

Thanks,
Fabio

On 12/14/17 9:01 AM, Dino Farinacci wrote:

I would prefer to not merge the two documents. Should we say in RFC6830bis that 
the R-bit is already allocated but don’t way why and make no reference. If no, 
I go for option A.

Dino


On Dec 14, 2017, at 2:58 AM, Luigi Iannone  wrote:

His All,

happy to see so much consensus :-)



As a chair I have to point out that if you add text in 6830bis to allocate the 
last bit and refer to draft-lewis-lisp-gpe you are creating an authoritative 
dependency on a to a document that as for now is not even WG item.
This will block the publication of 6830bis as RFC (remember the intro 
document…….).

There are two possible solutions:

A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future 
use. draft-lewis-lisp-gpe will than allocate this last bit and detail the 
operations.

B. We merge the two documents.

I do not have a preference, up to the WG to decide, but better to avoid 
document dependencies that will block publication.



Ciao

L.




On 29 Nov 2017, at 23:32, Fabio Maino  wrote:

I would like to suggest a way to address mutiprotocol support in RFC6830bis, 
that may address what was discussed in Singapore.
This is based on using the last reserved bit in the LISP header as P bit to 
indicate support for multiprotocol encapsulation, as specified in the LISP-GPE 
draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol|
 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 S / | Instance ID/Locator-Status-Bits   |
 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be replaced by:

 P: The P-bit is the Next Protocol bit. When this bit is set to
1, the V-bit MUST be set to 0 and the Nonce length, when used, is
limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
The P-bit is set to 1 to indicate the presence of the 8 bit Next
Protocol field encoded as:

   x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |N|L|E|V|I|P|K|K|   Nonce   

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

On 12/14/17 10:11 AM, Joel M. Halpern wrote:

Let's separate things:

1) We can have a call for adoption of LISP GPE.  Meetings are not 
special in terms of working group formal actions.
agree. Doing it seems to be helpful whatever the WG decides to do with 
6830bis.




2) My personal read is that if we assign the bit a meaning in 6830bis, 
then the reference has to be normative, as a reader seeking to 
understand the RFC would need to read the other document to know what 
the bit meant.  (My thanks to Luigi for catching this.)


Sounds reasonable, the reference should be normative then.

Now, there are other drafts in the normative section: once GPE is 
adopted we would be in the same situation, and we could deal with it in 
the same way we do for the others.


2') I see no reason why the bit should be assigned in 6830bis.  As 
long as we leave it reserved in 6830bis, LISP-GPE can assign it. That 
is what RFCs and registries are for.


It would be helpful to document all the LISP  dataplane features in 
6830bis. I think this  was one of the goals of having a dataplane document.


Since we are so close, and there's consensus, if 1 and 2 above makes 
sense the WG could start the call for adoption of GPE asap. If that 
works the WG could then proceed with the last call for 6830bis.


Fabio




So my personal preference would be to leave the protocol 
identification bit out of 6830bis.


Yours,
Joel

On 12/14/17 12:59 PM, Fabio Maino wrote:
Since there seem to be consensus, can we ask for WG adoption of 
LISP-GPE and include it as an informative reference as the other 
drafts that are in 6830bis?


Can the chairs open a call for adoption in the mailing list, or do we 
need to wait the next IETF?


This might be similar to what Dino proposes below.

Thanks,
Fabio

On 12/14/17 9:01 AM, Dino Farinacci wrote:
I would prefer to not merge the two documents. Should we say in 
RFC6830bis that the R-bit is already allocated but don’t way why and 
make no reference. If no, I go for option A.


Dino


On Dec 14, 2017, at 2:58 AM, Luigi Iannone  wrote:

His All,

happy to see so much consensus :-)



As a chair I have to point out that if you add text in 6830bis to 
allocate the last bit and refer to draft-lewis-lisp-gpe you are 
creating an authoritative dependency on a to a document that as for 
now is not even WG item.
This will block the publication of 6830bis as RFC (remember the 
intro document…….).


There are two possible solutions:

A. 6830bis remains unchanged, leaving the P-bit marked as reserved 
for future use. draft-lewis-lisp-gpe will than allocate this last 
bit and detail the operations.


B. We merge the two documents.

I do not have a preference, up to the WG to decide, but better to 
avoid document dependencies that will block publication.




Ciao

L.




On 29 Nov 2017, at 23:32, Fabio Maino  wrote:

I would like to suggest a way to address mutiprotocol support in 
RFC6830bis, that may address what was discussed in Singapore.
This is based on using the last reserved bit in the LISP header as 
P bit to indicate support for multiprotocol encapsulation, as 
specified in the LISP-GPE draft 
(https://tools.ietf.org/html/draft-lewis-lisp-gpe).

The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol    |
    I \ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    S / | Instance 
ID/Locator-Status-Bits   |
    P 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



and the text in section 5.3 that reserves the 6th bit would be 
replaced by:


    P: The P-bit is the Next Protocol bit. When this bit is set to
   1, the V-bit MUST be set to 0 and the Nonce length, when 
used, is
   limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for 
more details.
   The P-bit is set to 1 to indicate the presence of the 8 bit 
Next

   Protocol field encoded as:

  x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |N|L|E|V|I|P|K|K|   Nonce   | 
Next-Protocol |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Instance 
ID/Locator-Status-Bits   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the 
allocations of the KK bits according to RFC8061 and Nonce. One of 
the K bits was used by LISP-GPE to indicate OAM packets, but that 
same functionality can be done using the Next-Protocol field.


The use of the P-bit is not compatible with the Map-Versioning 
feature, but an equivalent function can be specified (if needed) 
with a Next-Protocol shim header. I can add text to the LISP-GPE 
draft to reflect that.


This would address the multiprotocol working item included in the 
current charter.


I can very quickly upda

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

Since there seem to be consensus, can we ask for WG adoption of LISP-GPE 
and include it as an informative reference as the other drafts that are 
in 6830bis?


Can the chairs open a call for adoption in the mailing list, or do we 
need to wait the next IETF?


This might be similar to what Dino proposes below.

Thanks,
Fabio

On 12/14/17 9:01 AM, Dino Farinacci wrote:

I would prefer to not merge the two documents. Should we say in RFC6830bis that 
the R-bit is already allocated but don’t way why and make no reference. If no, 
I go for option A.

Dino


On Dec 14, 2017, at 2:58 AM, Luigi Iannone  wrote:

His All,

happy to see so much consensus :-)



As a chair I have to point out that if you add text in 6830bis to allocate the 
last bit and refer to draft-lewis-lisp-gpe you are creating an authoritative 
dependency on a to a document that as for now is not even WG item.
This will block the publication of 6830bis as RFC (remember the intro 
document…….).

There are two possible solutions:

A. 6830bis remains unchanged, leaving the P-bit marked as reserved for future 
use. draft-lewis-lisp-gpe will than allocate this last bit and detail the 
operations.

B. We merge the two documents.

I do not have a preference, up to the WG to decide, but better to avoid 
document dependencies that will block publication.



Ciao

L.




On 29 Nov 2017, at 23:32, Fabio Maino  wrote:

I would like to suggest a way to address mutiprotocol support in RFC6830bis, 
that may address what was discussed in Singapore.
This is based on using the last reserved bit in the LISP header as P bit to 
indicate support for multiprotocol encapsulation, as specified in the LISP-GPE 
draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L   |N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol|
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits   |
P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be replaced by:

P: The P-bit is the Next Protocol bit. When this bit is set to
   1, the V-bit MUST be set to 0 and the Nonce length, when used, is
   limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
   The P-bit is set to 1 to indicate the presence of the 8 bit Next
   Protocol field encoded as:

  x x x 0 x 1 x x
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |N|L|E|V|I|P|K|K|   Nonce   | Next-Protocol |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Instance ID/Locator-Status-Bits   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations of the 
KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE 
to indicate OAM packets, but that same functionality can be done using the 
Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning feature, but an 
equivalent function can be specified (if needed) with a Next-Protocol shim 
header. I can add text to the LISP-GPE draft to reflect that.

This would address the multiprotocol working item included in the current 
charter.

I can very quickly update the LISP-GPE draft to reflect this, but I wanted to 
hear what the group thinks first.

Thanks,
Fabio








___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support]

[Fabio Maino]

Thanks Dino.

Fabio


On 12/13/17 3:02 PM, Dino Farinacci wrote:

After I go through Alberto’s response for RFC6833bis and one comment from 
Albert regarding RFC6830bis, I’ll document the P-bit and reference this spec in 
RFC6830bis. I plan to send email this week with both updates at one time.

This should be the final updates to both specs. I’d like to request last call 
and possibly complete it before year-end. Is that possible chairs?

Dino


On Dec 13, 2017, at 2:57 PM, Fabio Maino  wrote:

I have refreshed the LISP-GPE draft 
(https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit compatible 
with the data plane encoding in RFC6830bis, as discussed in the thread started 
on Nov. 29 
(https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19).
As a summary of the long thread:
- bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next 
Protocol field

- the Next Protocol field shares 8 bits with the Nonce/Map-Version field

- when the P-bit is set, the Nonce/Map-Version features are still available 
with shorter (16-bit vs 24-bit) Nonce/Map-Version fields

Thanks,

Fabio


 Forwarded Message 

Subject:[lisp] RFC6830bis and multiprotocol support
Date:   Wed, 29 Nov 2017 14:32:40 -0800
From:   Fabio Maino 
To: lisp@ietf.org 

I would like to suggest a way to address mutiprotocol support in RFC6830bis, 
that may address what was discussed in Singapore.
This is based on using the last reserved bit in the LISP header as P bit to 
indicate support for multiprotocol encapsulation, as specified in the LISP-GPE 
draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L   |N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol|
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits   |
P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be replaced by:

P: The P-bit is the Next Protocol bit. When this bit is set to
   1, the V-bit MUST be set to 0 and the Nonce length, when used, is
   limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more details.
   The P-bit is set to 1 to indicate the presence of the 8 bit Next
   Protocol field encoded as:

  x x x 0 x 1 x x
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |N|L|E|V|I|P|K|K|   Nonce   | Next-Protocol |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Instance ID/Locator-Status-Bits   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations of the 
KK bits according to RFC8061 and Nonce. One of the K bits was used by LISP-GPE 
to indicate OAM packets, but that same functionality can be done using the 
Next-Protocol field.

The use of the P-bit is not compatible with the Map-Versioning feature, but an 
equivalent function can be specified (if needed) with a Next-Protocol shim 
header. I can add text to the LISP-GPE draft to reflect that.

This would address the multiprotocol working item included in the current 
charter.

I can very quickly update the LISP-GPE draft to reflect this, but I wanted to 
hear what the group thinks first.

Thanks,
Fabio









___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] multi-protocol support in RFC6830bis [ Was: RFC6830bis and multiprotocol support]

[Fabio Maino]

I have refreshed the LISP-GPE draft 
(https://tools.ietf.org/html/draft-lewis-lisp-gpe) to be bit-to-bit 
compatible with the data plane encoding in RFC6830bis, as discussed in 
the thread started on Nov. 29 
(https://mailarchive.ietf.org/arch/msg/lisp/Dq18xxxQoDUkLX1Z_MCKaHZC1I4/?qid=a7da0673ad7ed2a161aa5f4334f96f19). 



As a summary of the long thread:

- bit 5 is allocated as P-bit to indicate the presence of an 8-bit Next 
Protocol field


- the Next Protocol field shares 8 bits with the Nonce/Map-Version field

- when the P-bit is set, the Nonce/Map-Version features are still 
available with shorter (16-bit vs 24-bit) Nonce/Map-Version fields



Thanks,

Fabio



 Forwarded Message 

Subject:[lisp] RFC6830bis and multiprotocol support
Date:   Wed, 29 Nov 2017 14:32:40 -0800
From:   Fabio Maino 
To: lisp@ietf.org 



I would like to suggest a way to address mutiprotocol support in 
RFC6830bis, that may address what was discussed in Singapore.


This is based on using the last reserved bit in the LISP header as P bit 
to indicate support for multiprotocol encapsulation, as specified in the 
LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).


The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L|N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol|
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / |Instance ID/Locator-Status-Bits|
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be replaced by:

P: The P-bit is the Next Protocol bit. When this bit is set to
1, the V-bit MUST be set to 0 and the Nonce length, when used, is
  limited to 16 bits. Refer to[draft-lewis-lisp-gpe] for more details.
  The P-bit is set to 1to indicate the presence of the 8 bit Next
  Protocol field encoded as:

x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| Nonce | Next-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Instance ID/Locator-Status-Bits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations 
of the KK bits according to RFC8061 and Nonce. One of the K bits was 
used by LISP-GPE to indicate OAM packets, but that same functionality 
can be done using the Next-Protocol field.


The use of the P-bit is not compatible with the Map-Versioning feature, 
but an equivalent function can be specified (if needed) with a 
Next-Protocol shim header. I can add text to the LISP-GPE draft to 
reflect that.


This would address the multiprotocol working item included in the 
current charter.


I can very quickly update the LISP-GPE draft to reflect this, but I 
wanted to hear what the group thinks first.


Thanks,
Fabio







___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] draft-kouvelas-lisp-map-server-reliable-transport working group adoption

[Fabio Maino]

On 12/5/17 10:12 AM, Dino Farinacci wrote:

draft-kouvelas-lisp-map-server-reliable-transport are looking for working-group 
adoption of the draft. The proposed solution replaces the UDP based control

Augments. We cannot remove UDP since there is too much deployment. And TCP is 
not always needed. And there is startup latency with the 3 way TCP handshake. 
This will slow mobile handoffs.


Right, augment rather than replace. I believe there's no intention to 
replace UDP. The draft actually relies on UDP registration to bootstrap 
the TCP channel, and to ensure backward compatibility.




I also brought up at the WG that we should consider other transport layers that 
are more secure than TCP by itself. Since your draft doesn’t spec how to use 
TLS with TCP, QUIC may be a more lightweight, efficient and secure alternative.


QUIC would be an interesting option as well, probably worth of another 
draft and possibly not limited to registration messages only.


I see this as a point optimization to the registration protocol, that 
might be orthogonal to other transport-related mechanisms. In my 
experience this has proved to be very effective in scalability of large 
LISP deployments, especially with the increased volume of registration data.



Fabio




plane LISP communication between xTRs and Map-Servers with a reliable transport 
session. This is done to eliminate the periodic messaging and improve scaling by

You can eliminate the periodic overhead by sending Map-Registers less often and 
solicited Map-Notifies as acks. And you can test for map-server reachability 
with RLOC-probes.

The only reason I bring this up is to disclose that we have existing mechanisms 
to provide reliability.

And rather than have a completely new message parsing format, we could make 
this proposal simpler by using existing messages that are sent over ANY 
transport.  I have made this comment before.

Note we did this in the PIM WG where existing messages are sent over TCP or 
SCTP.

Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

On 11/30/17 10:49 AM, Dino Farinacci wrote:

100% agree Dino.

The proposed changes to RFC6830bis, as discussed so far, are:
- allocate the last reserved bit in RFC6830bis as a P-bit,
- use the last 8-bit of the first word as nonce, and

I think you mean the Next Protocol field and not the nonce.


yes!




- use 16 bits only to allocate nonce and versioning fields (when used).

LISP-GPE will reflect the KK bits and will be bit-aligned with RFC6830bis 
(including NLEV bits). This will mean that the OAM bit in LISP-GPE will not be 
there anymore.

What Frank is saying is that this will enable the IOAM use case with LISP, 
because IOAM doesn't actually use the OAM bit, but relies only on the Next 
Protocol field.

Agree. Ack.

Dino




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

100% agree Dino.

The proposed changes to RFC6830bis, as discussed so far, are:
- allocate the last reserved bit in RFC6830bis as a P-bit,
- use the last 8-bit of the first word as nonce, and
- use 16 bits only to allocate nonce and versioning fields (when used).

LISP-GPE will reflect the KK bits and will be bit-aligned with 
RFC6830bis (including NLEV bits). This will mean that the OAM bit in 
LISP-GPE will not be there anymore.


What Frank is saying is that this will enable the IOAM use case with 
LISP, because IOAM doesn't actually use the OAM bit, but relies only on 
the Next Protocol field.



Thanks,
Fabio




On 11/30/17 8:32 AM, Dino Farinacci wrote:
I strongly suggest that the proponents for the P-bit do not couple 
this with IOAM because there is a lot more machinery to be described 
which may be too late for 6830bis.


When RFC 8061 LISP-crypto was written, the authors anticipated the 
P-bit and hence why the two low-order bits in the flags filed was 
selected.


We are now out of flag bits.

Dino

On Nov 30, 2017, at 7:36 AM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:



Fabio,

extending LISP encap with multiprotocol support would be beneficial. 
It would also give us a way to introduce IOAM into LISP – along very 
similar lines to what we discussed in Singapore as part of the IOAM 
with VXLAN-GPE encap discussion.


Thanks, Frank

*Subject: *



[lisp] RFC6830bis and multiprotocol support

*Date: *



Wed, 29 Nov 2017 14:32:40 -0800

*From: *

    

Fabio Maino  <mailto:fma...@cisco.com>

*To: *



lisp@ietf.org <mailto:lisp@ietf.org>  
<mailto:lisp@ietf.org>


I would like to suggest a way to address mutiprotocol support in 
RFC6830bis, that may address what was discussed in Singapore.


This is based on using the last reserved bit in the LISP header as P 
bit to indicate support for multiprotocol encapsulation, as specified 
in the LISP-GPE draft 
(https://tools.ietf.org/html/draft-lewis-lisp-gpe).


The header, as specified in section 5.1, would look like:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next-Protocol    |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / | Instance ID/Locator-Status-Bits   |
   P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be 
replaced by:


   P: The P-bit is the Next Protocol bit. When this bit is set to
  1, the V-bit MUST be set to 0 and the Nonce length, when used, is
  limited to 16 bits. Refer to [draft-lewis-lisp-gpe] for more 
details.

  The P-bit is set to 1 to indicate the presence of the 8 bit Next
  Protocol field encoded as:

 x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|P|K|K| Nonce   | Next-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Instance ID/Locator-Status-Bits   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the 
allocations of the KK bits according to RFC8061 and Nonce. One of the 
K bits was used by LISP-GPE to indicate OAM packets, but that same 
functionality can be done using the Next-Protocol field.


The use of the P-bit is not compatible with the Map-Versioning 
feature, but an equivalent function can be specified (if needed) with 
a Next-Protocol shim header. I can add text to the LISP-GPE draft to 
reflect that.


This would address the multiprotocol working item included in the 
current charter.


I can very quickly update the LISP-GPE draft to reflect this, but I 
wanted to hear what the group thinks first.


Thanks,
Fabio







___
lisp mailing list
lisp@ietf.org <mailto:lisp@ietf.org>
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

sounds good.

Fabio

On 11/29/17 3:13 PM, Dino Farinacci wrote:

I’d also add before the last sentence:

If the N-bit and V-bit are 0 when the P-bit is set, the middle 16-bits are set 
to 0.

Dino


On Nov 29, 2017, at 3:07 PM, Fabio Maino  wrote:

On 11/29/17 3:05 PM, Dino Farinacci wrote:

How about this wording Fabio:

P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is used 
for the Next Protocol field. When the N-bit is also set with the P-bit, the 
Nonce field is the middle 16 bits. When the V bit is also set with the P-bit, 
the Version field is the middle 16 bits. Details on Next Protocol field usage 
are described in [draft-lewis-lisp-gpe].

Comments?

much better.

Thanks,
Fabio


Dino


On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:

Definition of the P bit will look like:

P: The P-bit is the Next Protocol bit. When this bit is set to
   1, Nonce length, when used, is limited to 16 bits and the lenght
   of the Source and Destination Map-Version fields, when used, is limited
   to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
   The P-bit is set to 1 to indicate the presence of the 8 bit Next 
Protocol field encoded as:



Do you think the overall proposed extension makes sense?

Thanks,
Fabio

On 11/29/17 2:38 PM, Fabio Maino wrote:

On 11/29/17 2:36 PM, Dino Farinacci wrote:

The use of the P-bit is not compatible with the Map-Versioning feature, but an 
equivalent function can be specified (if needed) with a Next-Protocol shim 
header. I can add text to the LISP-GPE draft to reflect that.

Well it could be. Just like you did with the Nonce field. Make the Version 
field the middle 16-bits. So V and P can be set at the same as well as N and P.

Dino


Good point, shortening versions to 8 bits...

Seems fine to me.


Fabio




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

On 11/29/17 3:05 PM, Dino Farinacci wrote:

How about this wording Fabio:

P: The P-bit is the Next Protocol bit. When set, the low-order 8 bits is used 
for the Next Protocol field. When the N-bit is also set with the P-bit, the 
Nonce field is the middle 16 bits. When the V bit is also set with the P-bit, 
the Version field is the middle 16 bits. Details on Next Protocol field usage 
are described in [draft-lewis-lisp-gpe].

Comments?


much better.

Thanks,
Fabio



Dino


On Nov 29, 2017, at 2:49 PM, Fabio Maino  wrote:

Definition of the P bit will look like:

P: The P-bit is the Next Protocol bit. When this bit is set to
   1, Nonce length, when used, is limited to 16 bits and the lenght
   of the Source and Destination Map-Version fields, when used, is limited
   to 8 bits. Refer to [draft-lewis-lisp-gpe] for more details.
   The P-bit is set to 1 to indicate the presence of the 8 bit Next 
Protocol field encoded as:



Do you think the overall proposed extension makes sense?

Thanks,
Fabio

On 11/29/17 2:38 PM, Fabio Maino wrote:

On 11/29/17 2:36 PM, Dino Farinacci wrote:

The use of the P-bit is not compatible with the Map-Versioning feature, but an 
equivalent function can be specified (if needed) with a Next-Protocol shim 
header. I can add text to the LISP-GPE draft to reflect that.

Well it could be. Just like you did with the Nonce field. Make the Version 
field the middle 16-bits. So V and P can be set at the same as well as N and P.

Dino


Good point, shortening versions to 8 bits...

Seems fine to me.


Fabio




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

Definition of the P bit will look like:

P: The P-bit is the Next Protocol bit. When this bit is set to
1, Nonce length, when used, is limited to 16 bits and the lenght
  of the Source and Destination Map-Version fields, when used, is 
limited

  to 8 bits. Refer to[draft-lewis-lisp-gpe] for more details.
  The P-bit is set to 1to indicate the presence of the 8 bit Next 
Protocol field encoded as:




Do you think the overall proposed extension makes sense?

Thanks,
Fabio

On 11/29/17 2:38 PM, Fabio Maino wrote:

On 11/29/17 2:36 PM, Dino Farinacci wrote:
The use of the P-bit is not compatible with the Map-Versioning 
feature, but an equivalent function can be specified (if needed) 
with a Next-Protocol shim header. I can add text to the LISP-GPE 
draft to reflect that.
Well it could be. Just like you did with the Nonce field. Make the 
Version field the middle 16-bits. So V and P can be set at the same 
as well as N and P.


Dino


Good point, shortening versions to 8 bits...

Seems fine to me.


Fabio




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

On 11/29/17 2:36 PM, Dino Farinacci wrote:

The use of the P-bit is not compatible with the Map-Versioning feature, but an 
equivalent function can be specified (if needed) with a Next-Protocol shim 
header. I can add text to the LISP-GPE draft to reflect that.

Well it could be. Just like you did with the Nonce field. Make the Version 
field the middle 16-bits. So V and P can be set at the same as well as N and P.

Dino


Good point, shortening versions to 8 bits...

Seems fine to me.


Fabio




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] RFC6830bis and multiprotocol support

[Fabio Maino]

I would like to suggest a way to address mutiprotocol support in 
RFC6830bis, that may address what was discussed in Singapore.


This is based on using the last reserved bit in the LISP header as P bit 
to indicate support for multiprotocol encapsulation, as specified in the 
LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).


The header, as specified in section 5.1, would look like:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L|N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol|
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / |Instance ID/Locator-Status-Bits|
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


and the text in section 5.3 that reserves the 6th bit would be replaced by:

P: The P-bit is the Next Protocol bit. When this bit is set to
1, the V-bit MUST be set to 0 and the Nonce length, when used, is
  limited to 16 bits. Refer to[draft-lewis-lisp-gpe] for more details.
  The P-bit is set to 1to indicate the presence of the 8 bit Next
  Protocol field encoded as:

x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| Nonce | Next-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Instance ID/Locator-Status-Bits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I will have to refresh the LISP-GPE draft, and reflect the allocations 
of the KK bits according to RFC8061 and Nonce. One of the K bits was 
used by LISP-GPE to indicate OAM packets, but that same functionality 
can be done using the Next-Protocol field.


The use of the P-bit is not compatible with the Map-Versioning feature, 
but an equivalent function can be specified (if needed) with a 
Next-Protocol shim header. I can add text to the LISP-GPE draft to 
reflect that.


This would address the multiprotocol working item included in the 
current charter.


I can very quickly update the LISP-GPE draft to reflect this, but I 
wanted to hear what the group thinks first.


Thanks,
Fabio








___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Secdir last call review of draft-ietf-lisp-sec-13

[Fabio Maino]

Hi Takeshi,
thanks for taking the time to review the document.

Please see below for comments. Unless you have objections we plan to 
publish an updated rev by monday.


On 10/10/17 7:58 AM, Takeshi Takahashi wrote:

Reviewer: Takeshi Takahashi
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

I would say this document is ready with nits, but the nits are very minor.

[comments that require chages to the current draft]
1. I guess the authors mix up "reply" and "replay" in Section 6.6. "Reply
attacks" could be "Replay attacks".


fixed, thanks!


[comments that does not necessarily require changes to the current draft]
2. The security aspect of LISP is addressed not only in this draft but also in
RFC6830 and in RFC7835. If I understood correctly, LISP-SEC addressed a part of
the threats mentioned in RFC7835. Then, it would be nice if the authors could
clarify what types of further threats that are not mentioned in LISP-SEC still
exist by referring to RFC6830 and RFC7835.


Section 3 of LISP-SEC provides the cross references with the threat 
model of RFC 7835. LISP-SEC focuses particularly on the threads 
described in section  3.7 and 3.8 of RFC 7835 that describes attacks 
that "target EID-to-RLOC mappings, including manipulations of 
Map-Request and Map-Reply messages, and malicious ETR EID prefix 
overclaiming."


We should change the first sentence of section 3 to read:
"LISP-SEC addresses the control plane threats, described in *Section 3.7 
and 3.8 of* [RFC7835], that target EID-to-RLOC mappings, including 
manipulations of Map-Request and Map-Reply messages, and malicious ETR 
EID prefix overclaiming."




3. DOS/DDoS was mentioned in the introduction section, but it was not discussed
in the later sections. It would be nice if the authors could address DoS/DDoS
issues as well.




Good point. We should add a Section 6.7 that reads:

"6.7 Denial of Service and Distributed Denial of Service Attacks

LISP-SEC mitigates the risks of  Denial of Service and Distributed 
Denial of Service attacks by protecting the integrity and authenticating 
the origin of the Map-Request/Map-Reply messages, and by preventing 
malicious ETRs from overclaiming EID prefixes that could re-direct 
traffic directed to a potentially large number of hosts."



Thanks,

Fabio



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Last Call: (LISP-Security (LISP-SEC)) to Experimental RFC

[Fabio Maino]

Thanks Dino, we will update the text accordingly.

Fabio

On 9/22/17 9:57 PM, Dino Farinacci wrote:

The text looks good. I would just suggest on editorial change, substitute 
“Let’s consider” with “Consider”.

Thanks,
Dino


On Sep 20, 2017, at 11:12 PM, Fabio Maino  wrote:

Hi Dino,
thanks for the comments.

Here is the edited text:




6. Replay Attacks

Replay attacks against LISP-SEC can be mounted by either (1) re-sending a valid 
Map-Reply to the ITR, or (2) re-sending a valid Map-Request to the 
Map-Resolver, Map-Server, or ETR.

In order to understand LISP-SEC protection from replay attacks it's important to note 
that an ITR, upon receiving a valid Map-Reply, MUST discard the  
pair stored at the ITR that corresponds to the nonce in the received valid Map-Reply.

Let's consider first the case when the replay attack is mounted replaying a Map-Reply. The 
ITR, upon receiving the replayed Map-Reply, will try to match the Map-Reply's nonce with 
the list of stored  pairs. Since the  pair was 
removed when the valid Map-Reply arrived at the ITR, the replayed Map-Reply will be 
discarded defeating the replay attack.

Let's consider now the case when the replay attack is mounted replaying a Map-Request 
message to either a Map-Resolver, a Map-Server, or an ETR. The replayed Map-Request message 
will be processed as any other Map-Request message by the Map-Resolver, Map-Server, and 
ETR, and will generate a replayed Map-Reply that eventually reaches the ITR. However, the 
ITR upon receiving the replayed Map-Reply, will try to match the Map-Reply's nonce with the 
list of stored  pairs. Since the  pair was 
removed when the valid Map-Reply arrived at the ITR, the replayed Map-Reply will be 
discarded defeating the replay attack.

Please also note that point (3) is not really an issue, as a valid message and 
a replayed message are indistinguishable by definition. Whichever arrives first 
is the valid message, and all the subsequent ones are replay attacks.

Fabio


On 9/20/17 12:08 PM, Dino Farinacci wrote:

I have a comment on this newly added paragraph:



I don’t think it reads clearly. Here are my comments:

(1) First sentence, I think you mean “replay it” versus “reply it”.

(2) You should talk separately of a replayed Map-Request and then a replayed 
Map-Reply. Combining it makes it confusing on which case the ITR discards a 
Map-Reply. Because a Map-Reply is not responded to by a replayed Map-Reply so 
it can only mean a replayed Map-Reqeust.

(3) And if the replayed Map-Reply returns to the ITR BEFORE the one from the 
non-attacker, it cannot tell if the Map-Reply was from a non-attacker or an 
attacker. So you need to explain what happens in both cases (where the simple 
case is already in the text above).

(4) What is a “LISP-SEC computation”? That needs to be made more clear.

Please clarify this section. It needs it.

Dino



On Sep 20, 2017, at 10:54 AM, The IESG  wrote:


The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP-Security (LISP-SEC)'
   as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2017-10-04. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This memo specifies LISP-SEC, a set of security mechanisms that
   provides origin authentication, integrity and anti-replay protection
   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
   process.  LISP-SEC also enables verification of authorization on EID-
   prefix claims in Map-Reply messages.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ballot/


No IPR declarations have been submitted directly on this I-D.




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] [ERRATA] Call for WG Adoption of Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00.txt]

[Fabio Maino]

support.

Fabio

On 7/26/17 4:16 AM, Luigi Iannone wrote:

The call ends August 10th 2017 !

Luigi

On 26 Jul 2017, at 11:41, Luigi Iannone > wrote:


Hi All,

During the 99th IETF authors of the 
document draft-rodrigueznatal-lisp-vendor-lcaf-00.txt

[https://tools.ietf.org/html/draft-rodrigueznatal-lisp-vendor-lcaf-00]
asked for WG adoption. Meeting participants expressed consensus on 
adoption.


This message begins the two weeks call for WG adoption to confirm the 
meeting outcome.

The call ends on  August 3rd 2017.

Please respond to the LISP mailing list with any statements of 
approval or disapproval.


Recall that:

- This is not WG Last Call. The document is not final, and the WG is 
expected to
  modify the document’s content until there is WG consensus that the 
content is solid.
  Therefore, please don’t oppose adoption just because you want to 
see changes to its content.


- If you have objections to adoption of the document, please state 
your reasons why,

  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those 
issues and we can

  begin a dialog about how best to address them.
Luigi and Joel




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] [ERRATA] Call for WG Adoption of LISP Anonymity [draft-farinacci-lisp-eid-anonymity-02.txt]

[Fabio Maino]

support.

Fabio

On 7/26/17 4:16 AM, Luigi Iannone wrote:

The call ends August 10th 2017 !

Luigi


On 26 Jul 2017, at 11:41, Luigi Iannone > wrote:


Hi All,

During the 99th IETF authors of the 
document draft-farinacci-lisp-eid-anonymity-02.txt

[https://tools.ietf.org/html/draft-farinacci-lisp-eid-anonymity-02]
asked for WG adoption. Meeting participants expressed consensus on 
adoption.


This message begins the two weeks call for WG adoption to confirm the 
meeting outcome.

The call ends on  August 3rd 2017.

Please respond to the LISP mailing list with any statements of 
approval or disapproval.


Recall that:

- This is not WG Last Call. The document is not final, and the WG is 
expected to
  modify the document’s content until there is WG consensus that the 
content is solid.
  Therefore, please don’t oppose adoption just because you want to 
see changes to its content.


- If you have objections to adoption of the document, please state 
your reasons why,

  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those 
issues and we can

  begin a dialog about how best to address them.
Luigi and Joel




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-predictive-rlocs-02.txt

[Fabio Maino]

support


On 5/19/17 2:06 AM, Luigi Iannone wrote:

Hi All,

Authors of the document draft-farinacci-lisp-predictive-rlocs-02.txt
[https://datatracker.ietf.org/doc/draft-farinacci-lisp-predictive-rlocs/]
asked for WG adoption.

This message begins the two weeks call for WG adoption.
The call ends on  June 2nd 2017.

Please respond to the LISP mailing list with any statements of 
approval or disapproval.


Recall that:

- This is not WG Last Call. The document is not final, and the WG is 
expected to
  modify the document’s content until there is WG consensus that the 
content is solid.
  Therefore, please don’t oppose adoption just because you want to see 
changes to its content.


- If you have objections to adoption of the document, please state 
your reasons why,

  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues 
and we can

  begin a dialog about how best to address them.
Luigi and Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-meyer-lisp-mn-16.txt

[Fabio Maino]

support

On 4/12/17 2:30 AM, Luigi Iannone wrote:

Hi All,

During the 98th IETF authors of the document draft-meter-lisp-mn-16.txt
[https://tools.ietf.org/html/draft-meyer-lisp-mn-16]
asked for WG adoption. Meeting participants expressed consensus on 
adoption.


This message begins the two weeks call for WG adoption to confirm the 
meeting outcome.

The call ends on  April 27th 2017.

Please respond to the LISP mailing list with any statements of 
approval or disapproval.


Recall that:

- This is not WG Last Call. The document is not final, and the WG is 
expected to
  modify the document’s content until there is WG consensus that the 
content is solid.
  Therefore, please don’t oppose adoption just because you want to see 
changes to its content.


- If you have objections to adoption of the document, please state 
your reasons why,

  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues 
and we can

  begin a dialog about how best to address them.
Luigi and Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-moreno-lisp-vpn-00.txt

[Fabio Maino]

support

On 4/12/17 2:29 AM, Luigi Iannone wrote:

Hi All,

During the 98th IETF authors of the document draft-moreno-lisp-vpn-00.txt
[https://tools.ietf.org/html/draft-moreno-lisp-vpn-00]
asked for WG adoption. Meeting participants expressed consensus on 
adoption.


This message begins the two weeks call for WG adoption to confirm the 
meeting outcome.

The call ends on  April 27th 2017.

Please respond to the LISP mailing list with any statements of 
approval or disapproval.


Recall that:

- This is not WG Last Call. The document is not final, and the WG is 
expected to
  modify the document’s content until there is WG consensus that the 
content is solid.
  Therefore, please don’t oppose adoption just because you want to see 
changes to its content.


- If you have objections to adoption of the document, please state 
your reasons why,

  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues 
and we can

  begin a dialog about how best to address them.
Luigi and Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-portoles-lisp-eid-mobility-02.txt

[Fabio Maino]

support

On 4/12/17 2:28 AM, Luigi Iannone wrote:

Hi All,

During the 98th IETF authors of the 
document draft-portoles-lisp-eid-mobility-02.txt

[https://tools.ietf.org/html/draft-portoles-lisp-eid-mobility-02]
asked for WG adoption. Meeting participants expressed consensus on 
adoption.


This message begins the two weeks call for WG adoption to confirm the 
meeting outcome.

The call ends on  April 27th 2017.

Please respond to the LISP mailing list with any statements of 
approval or disapproval.


Recall that:

- This is not WG Last Call. The document is not final, and the WG is 
expected to
  modify the document’s content until there is WG consensus that the 
content is solid.
  Therefore, please don’t oppose adoption just because you want to see 
changes to its content.


- If you have objections to adoption of the document, please state 
your reasons why,

  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues 
and we can

  begin a dialog about how best to address them.
Luigi and Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for Agenda Items

[Fabio Maino]

Hi Dino,
I think it's a good idea.

Thanks for bringing it up,
Fabio

On 3/16/17 10:33 AM, Dino Farinacci wrote:

You know draft-meyer-lisp-mn has been published and refreshed for nearly 8 
years. Can I present it after Victor presents draft-portoles-lisp-eid-mobility? 
I only need 10 minutes. Its time to ask the working group if we should adopt it 
I think.

Dino


On Mar 16, 2017, at 5:03 AM, Luigi Iannone  wrote:

Hi All,

the draft agenda is now online: https://datatracker.ietf.org/doc/agenda-98-lisp/

We have still unallocated time, hence, do not hesitate to request a slot.
Send your request to  lisp-cha...@tools.ietf.org

Ciao

L



On 8 Mar 2017, at 11:10, Luigi Iannone  wrote:

Hi All,

We have a time slot during the next IETF in Chicago so it is time to fix the 
agenda for our WG.
The LISP WG  is scheduled to meet on Thursday, March 30th, 2017, from 13:00 to 
15:00 (2 hours)

Please send your requests for agenda items (Presenter’s name, ppt title, slot 
duration)
to lisp-cha...@tools.ietf.org by Wednesday 15th March, 2017.

Thanks

Joel & Luigi


On 4 Mar 2017, at 00:55, IETF Secretariat  wrote:

Dear Luigi Iannone,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

lisp Session 1 (2:00:00)
Thursday, Afternoon Session I 1300-1500
Room Name: Zurich C size: 100
-



Request Information:


-
Working Group Name: Locator/ID Separation Protocol
Area Name: Routing Area
Session Requester: Luigi Iannone

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 50
Conflicts to Avoid:
First Priority: rtgwg nvo3 i2rs sidr grow sfc nfvrg pim intarea
Second Priority: mboned icnrg irtfopen idr spring bier maprg
Third Priority: l2tpext bess


People who must be present:
  Joel M. Halpern
  Wassim Haddad
  Deborah Brungard
  Luigi Iannone

Resources Requested:
  Meetecho support in room

Special Requests:

-


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-ietf-lisp-sec-12.txt

[Fabio Maino]

As discussed this morning we would like to propose this document for 
last call.


Thanks,
Fabio

On 11/16/16 9:08 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol of the IETF.

 Title   : LISP-Security (LISP-SEC)
 Authors : Fabio Maino
   Vina Ermagan
   Albert Cabellos
   Damien Saucez
Filename: draft-ietf-lisp-sec-12.txt
Pages   : 22
Date: 2016-11-16

Abstract:
This memo specifies LISP-SEC, a set of security mechanisms that
provides origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
process.  LISP-SEC also enables verification of authorization on EID-
prefix claims in Map-Reply messages.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-lisp-sec-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-sec-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis

[Fabio Maino]

I support adoption.

Fabio


On 11/16/16 11:58 AM, Luigi Iannone wrote:

Folks,

The chairs received a request for the following document to be
adopted as a WG item:

_https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/_

Here starts a 14 day call for adoption, this call will end on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, 
please
also indicate if you are able and willing to either contribute to, 
or review, (or both) the draft.


Sitting in silence does not indicate support, please respond 
appropriately.



The Chairs
Joel & Luigi


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis

[Fabio Maino]

I support adoption of this draft.

Fabio

On 11/16/16 11:57 AM, Luigi Iannone wrote:

Folks,

The chairs received a request for the following document to be
adopted as a WG item:

_https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/_

Here starts a 14 day call for adoption, this call will end on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, 
please
also indicate if you are able and willing to either contribute to, 
or review, (or both) the draft.


Sitting in silence does not indicate support, please respond 
appropriately.



The Chairs
Joel & Luigi


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP-SEC review (finally)

[Fabio Maino]

On 11/2/16 9:02 AM, Luigi Iannone wrote:

Hi Fabio,

I went through the last version of the document.

I still think that in a few place SHOULD should be replaced by MUST. 
But it is just  my point of view. You can leave SHOULD.


There are just few residual issues:

- Introduction: The second sentence is not coherent with the first 
one. The concept of EID-to-RLOC mappings as not been introduced so 
starting the sentence with “These EID-to-RLOC mapping s…” is pretty 
unclear. I would suggest you add another sentence.


- Section 7 IANA Considerations: For almost all of the registries the 
value “0” has a special meaning that this demo is defining, hence the 
“defined in” field should state “this memo”


- - Section 7 IANA Considerations: The section is not yet 5226 
compliant. More specifically, you have to state for each registry how 
new values are allocated (e.g. FCFS, expert review, etc..)


Thanks Luigi,
do you have any suggestion for the best policy to use for allocation of 
unassigned values?


It seems to me that given the experimental nature of the draft, for all 
of the registries created, we could require that 'unassigned values are 
to be assigned according to the "Specification Required" policy defined 
in [RFC5226].'




Fabio






Check again the nits:

  Checking nits according tohttp://www.ietf.org/id-info/checklist  :
   

   == There are 10 instances of lines with non-RFC6890-compliant IPv4
  addresses in the document.  If these are example addresses, they should
  be changed.

   Checking references for intended status: Experimental
   

   == Missing Reference: 'RFC4634' is mentioned on line 840, but not defined

   ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)


The above nits reminds me of another issue that the IESG will 
certainly raise: can we have all the examples in IPv6 only?
The latest directives are that either you use both v4 and v6 or 
v6-only, but NOT v4-only.


Thanks

ciao

L.




On 27 Oct 2016, at 23:48, Fabio Maino <mailto:fma...@cisco.com>> wrote:


Luigi,
I agree with all the comments.

The document attached should reflect all your suggestions.

A few notes below, just to explicitly ack the changes you suggested.


On 10/26/16 2:13 AM, Luigi Iannone wrote:

Hi Fabio,

Yes we are converging, very few points are left.

Inline are my comments, I snipped everything that we already agreed 
up on.


L.

On 26 Oct 2016, at 02:14, Fabio Maino <mailto:fma...@cisco.com>> wrote:




[snip]






Also, what is the MS stubbornly insists in using an algorithm that 
the ITR does not support?


The MS might not have alternatives, as it might only support one 
algorithm.




Sure

The question is: can we have situations in which MS replies always 
with the same algorithm (because has no alternatives) and the ITR is 
never able to understand that reply (because has no alternatives).


From my understanding this can happen, right?

LISP-SEC has no way to prevent it, right?

What is needed is a policy like “ITR tries using all of the 
algorithm it supports and then gives up”, right?


If the answer to those questions is yes, then IMO this should be 
spelled out somewhere.





got it. Agreed.






[snip]








The KDF ID field, specifies the suggested key derivation function to
be used by the Map-Server to derive the MS-OTK.


What happens if the MS will choose a KDF ID not supported by the 
ITR?
Can you clarify how to solve this situation or explain why this 
will never happen?


This is described a few paragraphs below:
"
If the KDF ID in the Map-Reply does not match the
KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
Reply and send, at the first opportunity it needs to, a new Map-
Request with a different KDF ID, according to ITR's...
"



This does not guarantee that the MS will reply with something the 
ITR understands….


For some local ITR's policy it may not be guaranteed. It's a 
balance between reachability and security that the ITR will have to 
choose.




I am not sure I understand your reply.

My point was the same as above: what if MS and ITR are not able to talk?


ok. So this is addressed by the same fix used for the previous 
comment. I'll specify that the ITR will stop re-sending map-requests 
once all HMAC IDs supported by the ITR have been attempted.

















The EID-AD length is set to 4 bytes, since the Authentication Data
does not contain EID-prefix Authentication Data, and the EID-AD
contains only the KDF ID field.

In response to an encapsulated Map-Request that has the S-bit set, an
ITR MUST receive a Map-Reply with the S-bit set, that includes an
EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
ITR M

Re: [lisp] LISP-SEC review (finally)

[Fabio Maino (fmaino)]

perfect.

thanks Dino,


Fabio




Sent with OOR.Mobile (OpenOverlayRouter.org)


 Original message 
From: Dino Farinacci 
Date: 10/24/16 10:58 AM (GMT-08:00)
To: "Fabio Maino (fmaino)" 
Cc: Luigi Iannone , "Vina Ermagan 
(vermagan)" , Albert Cabellos , Damien 
Saucez , lisp-cha...@ietf.org, LISP mailing list list 

Subject: Re: [lisp] LISP-SEC review (finally)


>> Why are you re-defining ECM?
>> You do not specify other packets, e.g., Map-Reply, so why ECM?
>> I would drop it.
>
> It is not defined in the Definitions section of 6830. One would need to go 
> through the body of 6830 to find it.
>
> I'll drop it, but we need to make sure that ECM gets into the definition 
> section of 6830bis.
>
> Albert: are you looking into that document? Can you take care of this?

>From the Berlin presentation, we had planned to put all control-plane messages 
>in 6833bis and did plan to include all flags (as well as the S-bit in the ECM 
>header). So we got this covered.

In 6833bis we can refer to lisp-sec if we can progress it sooner than 6833bis. 
And from a current perspective, it is looking that way.

Comments?

Dino


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] LISP-SEC review (finally)

[Fabio Maino]

Thanks Joel,
sounds fair. I'll then add text that provides the rationale for this 
choice.



Fabio

On 10/21/16 4:35 PM, Joel M. Halpern wrote:
The usual practice, although there are exceptions, is to indicate 
along with the SHOULD the kinds of circumstances that would justify 
not complying with that SHOULD while implementing (most of) the rest 
of the RFC.


Yours,
Joel

On 10/21/16 7:23 PM, Fabio Maino wrote:

Ciao Luigi,
below I have replied to each comment. I'm working to the updated text,
that I will send as soon as it is ready. ideally we might be able to
publish a new version before draft deadline.

Just a note on the most recurring comment: SHOULD vs. MUST.

The use of SHOULD across the document is according to RFC 2119:


SHOULD

 This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.



There are use cases where, carefully weighing the implications, some of
the security services of LISP-SEC can be turned-off. We want to leave
implementors the freedom to allow this flexibility.

For example, in a DC deployment it may make sense to turn off OTK
decryption between XTR and MS/MR, as MiTM is very unlikely.

Similarly, an ITR may decide to implement a loose policy on accepting an
AD authenticated with an algorithm different from the preferred
authentication algorithm expressed by the ITR. Using a MUST would force
support of a given authentication algorithm across each and every MS and
ETR, that might not be the case when incrementally deploying LISP-SEC
(or while upgrading routers).

Using a MUST would prevent this flexibility, that we would like to leave
to the implementors.





On 10/19/16 8:06 AM, Luigi Iannone wrote:

Dear Authors of the LISP-SEC document,

hereafter my review of the document.
This was long overdue, sorry for being so late.

I really like the solution and the majority of my comments are just
clarification questions.
Let me know if my comments are clear.

ciao

L.




1.  Introduction

   The Locator/ID Separation Protocol [RFC6830] defines a set of
   functions for routers to exchange information used to map from non-
   routable Endpoint Identifiers (EIDs) to routable Routing Locators
   (RLOCs).

I find the above sentence confusing. Wouldn’t be better to specify
that we are talking about IP addresses?


That's how LISP is described in RFC6830, section 1. If you start using
the term IP address then you need to qualify if you are talking about
Identity-IP or Locator-IP, so the sentence gets complicated pretty 
quickly.


I would leave this one unchanged.




If these EID-to-RLOC mappings, carried through Map-Reply
   messages, are transmitted without integrity protection, an 
adversary

   can manipulate them and hijack the communication, impersonate the
   requested EID, or mount Denial of Service or Distributed Denial of
   Service attacks.  Also, if the Map-Reply message is transported
   unauthenticated, an adversarial LISP entity can overclaim an EID-
   prefix and maliciously redirect traffic directed to a large 
number of

   hosts.  A detailed description of "overclaiming" attack is provided
   in [RFC7835].

   This memo specifies LISP-SEC, a set of security mechanisms that
   provides origin authentication, integrity and anti-replay 
protection

   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
   process.


I would put s forward reference to section 3 stating that the reader
will find details about the threat model.


OK. We can replace the sentence

A detailed description of "overclaiming" attack is provided
   in [RFC7835]

with

The LISP-SEC threat model, described in Section 3, is built on top of 
the LISP threat model defined in RFC7835, that includes a detailed 
description of "overclaiming" attack.







LISP-SEC also enables verification of authorization on EID-
   prefix claims in Map-Reply messages, ensuring that the sender of a
   Map-Reply that provides the location for a given EID-prefix is
   entitled to do so according to the EID prefix registered in the
   associated Map-Server.  Map-Register security, including the right
   for a LISP entity to register an EID-prefix or to claim presence at
   an RLOC, is out of the scope of LISP-SEC.  Additional security
   considerations are described in Section 6.

2.  Definition of Terms

  One-Time Key (OTK): An ephemeral randomly generated key that 
must

  be used for a single Map-Request/Map-Reply exchange.



 ITR-OTK: The One-Time Key generated at the ITR.

 MS-OTK: The One-Time Key generated at the Map-Server.


Why are you considering ITR-OTK and MS-OTK sub-terms?
I would elevate them at full terms, hence avoiding spacing and
indentation.


Ok.



  Encapsulated Control Message (ECM): A LISP control mes

Re: [lisp] LISP-SEC review (finally)

[Fabio Maino]

Ciao Luigi,
below I have replied to each comment. I'm working to the updated text, 
that I will send as soon as it is ready. ideally we might be able to 
publish a new version before draft deadline.


Just a note on the most recurring comment: SHOULD vs. MUST.

The use of SHOULD across the document is according to RFC 2119:


   SHOULD

 This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.



There are use cases where, carefully weighing the implications, some of 
the security services of LISP-SEC can be turned-off. We want to leave 
implementors the freedom to allow this flexibility.


For example, in a DC deployment it may make sense to turn off OTK 
decryption between XTR and MS/MR, as MiTM is very unlikely.


Similarly, an ITR may decide to implement a loose policy on accepting an 
AD authenticated with an algorithm different from the preferred 
authentication algorithm expressed by the ITR. Using a MUST would force 
support of a given authentication algorithm across each and every MS and 
ETR, that might not be the case when incrementally deploying LISP-SEC 
(or while upgrading routers).


Using a MUST would prevent this flexibility, that we would like to leave 
to the implementors.






On 10/19/16 8:06 AM, Luigi Iannone wrote:

Dear Authors of the LISP-SEC document,

hereafter my review of the document.
This was long overdue, sorry for being so late.

I really like the solution and the majority of my comments are just 
clarification questions.

Let me know if my comments are clear.

ciao

L.




1.  Introduction

The Locator/ID Separation Protocol [RFC6830] defines a set of
functions for routers to exchange information used to map from non-
routable Endpoint Identifiers (EIDs) to routable Routing Locators
(RLOCs).
I find the above sentence confusing. Wouldn’t be better to specify 
that we are talking about IP addresses?


That's how LISP is described in RFC6830, section 1. If you start using 
the term IP address then you need to qualify if you are talking about 
Identity-IP or Locator-IP, so the sentence gets complicated pretty quickly.


I would leave this one unchanged.




If these EID-to-RLOC mappings, carried through Map-Reply
messages, are transmitted without integrity protection, an adversary
can manipulate them and hijack the communication, impersonate the
requested EID, or mount Denial of Service or Distributed Denial of
Service attacks.  Also, if the Map-Reply message is transported
unauthenticated, an adversarial LISP entity can overclaim an EID-
prefix and maliciously redirect traffic directed to a large number of
hosts.  A detailed description of "overclaiming" attack is provided
in [RFC7835].

This memo specifies LISP-SEC, a set of security mechanisms that
provides origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
process.


I would put s forward reference to section 3 stating that the reader 
will find details about the threat model.


OK. We can replace the sentence

A detailed description of "overclaiming" attack is provided
   in [RFC7835]

with

The LISP-SEC threat model, described in Section 3, is built on top of the LISP threat 
model defined in RFC7835, that includes a detailed description of 
"overclaiming" attack.






LISP-SEC also enables verification of authorization on EID-
prefix claims in Map-Reply messages, ensuring that the sender of a
Map-Reply that provides the location for a given EID-prefix is
entitled to do so according to the EID prefix registered in the
associated Map-Server.  Map-Register security, including the right
for a LISP entity to register an EID-prefix or to claim presence at
an RLOC, is out of the scope of LISP-SEC.  Additional security
considerations are described in Section 6.

2.  Definition of Terms

   One-Time Key (OTK): An ephemeral randomly generated key that must
   be used for a single Map-Request/Map-Reply exchange.



  ITR-OTK: The One-Time Key generated at the ITR.

  MS-OTK: The One-Time Key generated at the Map-Server.


Why are you considering ITR-OTK and MS-OTK sub-terms?
I would elevate them at full terms, hence avoiding spacing and 
indentation.


Ok.




   Encapsulated Control Message (ECM): A LISP control message that is
   prepended with an additional LISP header.  ECM is used by ITRs to
   send LISP control messages to a Map-Resolver, by Map-Resolvers to
   forward LISP control messages to a Map-Server, and by Map-
   Resolvers to forward LISP control messages to an ETR.


Why are you re-defining ECM?
You do not specify other packets, e.g., Map-Reply, so why ECM?
I would drop it.


It is not defined in the Definitions sect

Re: [lisp] LISP-SEC review (finally)

[Fabio Maino]

14, RFC 2119,
   DOI 10.17487/RFC2119, March 1997,
   <http://www.rfc-editor.org/info/rfc2119>.

[RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
   (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
   September 2002, <http://www.rfc-editor.org/info/rfc3394>.

[RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
   "Randomness Requirements for Security", BCP 106, RFC 4086,
   DOI 10.17487/RFC4086, June 2005,
   <http://www.rfc-editor.org/info/rfc4086>.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
   IANA Considerations Section in RFCs", BCP 26, RFC 5226,
   DOI 10.17487/RFC5226, May 2008,
   <http://www.rfc-editor.org/info/rfc5226>.

[RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
   Key Derivation Function (HKDF)", RFC 5869,
   DOI 10.17487/RFC5869, May 2010,
   <http://www.rfc-editor.org/info/rfc5869>.

[RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
   Locator/ID Separation Protocol (LISP)", RFC 6830,
   DOI 10.17487/RFC6830, January 2013,
   <http://www.rfc-editor.org/info/rfc6830>.

[RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
   Protocol (LISP) Map-Server Interface", RFC 6833,
   DOI 10.17487/RFC6833, January 2013,
   <http://www.rfc-editor.org/info/rfc6833>.




Maino, et al. Expires April 6, 2017[Page 18]

Internet-Draft  LISP-SECOctober 2016


[RFC7835]  Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
   Separation Protocol (LISP) Threat Analysis", RFC 7835,
   DOI 10.17487/RFC7835, April 2016,
   <http://www.rfc-editor.org/info/rfc7835>.

Authors' Addresses

Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, California  95134
USA

Email:fma...@cisco.com <mailto:fma...@cisco.com>


Vina Ermagan
Cisco Systems
170 Tasman Drive
San Jose, California  95134
USA

Email:verma...@cisco.com <mailto:verma...@cisco.com>


Albert Cabellos
Technical University of Catalonia
c/ Jordi Girona s/n
Barcelona  08034
Spain

Email:acabe...@ac.upc.edu <mailto:acabe...@ac.upc.edu>


Damien Saucez
INRIA
2004 route des Lucioles - BP 93
Sophia Antipolis
France

Email:damien.sau...@inria.fr <mailto:damien.sau...@inria.fr>










Maino, et al. Expires April 6, 2017[Page 19]










___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-type-iana-00.txt

[Fabio Maino]

I support moving this document forward.

Fabio

On 8/17/16 1:58 PM, Luigi Iannone wrote:

Hi All,

The authors of the LISP Experimental Message & IANA Registry for LISP 
Packet
Type Allocations 
[https://tools.ietf.org/html/draft-ietf-lisp-type-iana-00] asked for 
WG Last Call.


This email starts the usual two weeks WG Last Call, to end August 
31st, 2016.


Please review this WG document and let the WG know if you agree that 
it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain 
what it would take to address your concerns.


Thanks

Luigi & Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for adoption of draft-boucadair-lisp-type-iana-01

[Fabio Maino]

I support creating a registry for LISP message types, and I think it 
would be useful to have an experimental type.


Fabio

On 7/15/16 1:56 PM, Luigi Iannone wrote:

His All,

the chairs have review the WG discussion during the adoption call.

We are concerned by the low level of support.
We also observed significant discussion around the experimental 
allocation.
So we are re-issuing and clarifying the call, to finish one week afte 
rthe end of IETF 96.


Please comment on two separate issues:

1) Do you think we should create a registry for LISP message types

2) If yes to (1), do you think that registry should include reserving 
an entry for Experimentation?


As indicated in the first mail silence does not indicate support, 
please respond to the call.


Yours,

Joel
Luigi

On 28 Jun 2016, at 11:37, Luigi Iannone > wrote:



Folks,

The chairs received a request for the following document to be
adopted as a WG item:

_https://tools.ietf.org/html/draft-boucadair-lisp-type-iana-01_
_
_Here starts a 14 day call for adoption, this call will end on
Tuesday the 12th July, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, 
please
also indicate if you are able and willing to either contribute to, 
or review, (or both) the draft.


Sitting in silence does not indicate support, please respond 
appropriately.



The Chairs
Joel & Luigi





___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call for draft-ietf-lisp-lcaf-12

[Fabio Maino]

This draft has been around for quite some time, and went through 
multiple reviews and editing cycles.


I support handing it to the AD.

Thanks,
Fabio

On 4/8/16 6:27 AM, Luigi Iannone wrote:

Hi All,

During our meeting yesterday, the authors of the LISP LCAF document 
 [https://tools.ietf.org/html/draft-ietf-lisp-lcaf-12]
asked for Last Call. The room showed consensus and no objections were 
raised.


This email starts the usual two weeks WG Last Call, to end April 22nd, 
2016.


Please review this WG document and let the WG know if you agree that 
it is ready for handing to the AD.
If you have objections, please state your reasons why, and explain 
what it would take to address your concerns.


Thanks

Luigi & Joel


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Fwd: New Version Notification for draft-maino-gpe-vpn-00.txt

[Fabio Maino]

We have put together a draft on programmable GPE-based VPNs with the 
goal to provide context and rationale, for the VPN use case, to some of 
the LISP extensions that have been proposed so far.


Please send your comments to the list.

We have asked for some agenda time, so we might also be able to discuss 
this in Buenos Aires.


Thanks,
Fabio




 Forwarded Message 
Subject:New Version Notification for draft-maino-gpe-vpn-00.txt
Date:   Mon, 21 Mar 2016 15:30:30 -0700
From:   internet-dra...@ietf.org
To: 	Vina Ermagan , Fabio Maino , 
John Evans , Horia Miclea 




A new version of I-D, draft-maino-gpe-vpn-00.txt
has been successfully submitted by Fabio Maino and posted to the
IETF repository.

Name:   draft-maino-gpe-vpn
Revision:   00
Title:  GPE-VPN: Programmable LISP-based Virtual Private Networks
Document date:  2016-03-21
Group:  Individual Submission
Pages:  15
URL:https://www.ietf.org/internet-drafts/draft-maino-gpe-vpn-00.txt
Status: https://datatracker.ietf.org/doc/draft-maino-gpe-vpn/
Htmlized:   https://tools.ietf.org/html/draft-maino-gpe-vpn-00


Abstract:
   GPE-VPN is an architecture for programmable SD-WAN solutions that
   leverages the Generic Protocol Encapsulation (GPE) overlay.

   GPE-VPN uses an extended LISP-based map-assisted control plane to
   dynamically lookup forwarding policies on demand.  A northbound
   programmable mapping system is used to store and retrieve mappings
   and forwarding policies.

   The GPE-VPN data plane is secured with IPsec based encryption.

   Overlay tunnels, as well as cryptographic parameters, are provisioned
   on demand.


  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Update Proposed CHarter

[Fabio Maino]

Looks good Luigi.

Thanks,
Fabio


On 1/6/16 6:42 AM, Luigi Iannone wrote:

Hi All,

Hereafter a new version of the charter with the comments received so far.

Please send more feedback. Would be good if we can send the charter to our AD 
by next week.

ciao

L.

%%%


The LISP WG has completed the first set of Experimental RFCs describing the 
Locator/ID Separation Protocol (LISP). LISP supports a routing architecture 
which decouples the routing locators and identifiers, thus allowing for 
efficient aggregation of the routing locator space and providing persistent 
identifiers in the identifier space. LISP requires no changes to end-systems or 
to routers that do not directly participate in the LISP deployment. LISP aims 
for an incrementally deployable protocol. The scope of the LISP techology is 
recognized to range from unicast and multicast overlays at Layer 2 as well as 
at Layer 3, including NAT traversal, VPNs,  and supporting mobility as a 
general feature, independently of wheter it is a mobile user or a migrating VM, 
hence being applicable in both Data Centers and public Internet environments.


The LISP WG is chartered to continue work on the LISP base protocol with the 
main objective to develop a standard solution based on the completed 
Experimental RFCs and the experience gained from early deployments.

This work will include reviewing the existing set of Experimental RFCs and 
doing the necessary enhancements to support a base set of standards track RFCs. 
The group will review the current set of Working Group documents to identify 
potential standards-track documents and do the necessary enhancements to 
support standards-track. It is recognized that some of the work will continue 
on the experimental track, though the group is encouraged to move the documents 
to standards track in support of network use, whereas the work previously was 
scoped to experimental documents.

Beside this main focus, the LISP WG work on the following items:

·   Multi-protocol support: Specifying the required extensions to support 
multi-protocol encapsulation (e.g.,   L2 or NSH – Network Service Headers). 
Rather than developing new encapsulations the work will aim at using existing 
well-established encapsulations or emerging from other Working Grops such as  
NVO3 and SFC.

·   Alternative Mapping System Design. By extenting LISP with  new 
protocols support it is also necessary to develop the required mapping function 
and control plane extensions to operate LISP map-assisted  networks (which 
might include Hierarchical Pull, Publish/Subscribe, or Push models, 
independednt mapping systems interconnection, security extensions, or 
alternative transports of the LISP control protocol).

·   Mobility

·   Multicast: Support for overlay multicast by means of replication as 
well as interfacing with existing underlay multicast support.

·   Data-Plane Encryption

·   NAT-Traversal

·   Models for managing the LISP protocol and deployments that include data 
models, as well as allowing for programmable management interfaces. These 
managament methods should be considered for both the data-plane, control-plane, 
and mapping system components.

  


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Update Proposed CHarter

[Fabio Maino]

Hi Luigi,
it looks good to me.

One item that was mentioned at the last meeting was to include the work 
done so far on map server reliable transport.


One possible way to include it is to change the very last bullet to 
something like:


- Alternative Mapping System Design. By extending LISP with  new 
protocols support it is also necessary to develop the required mapping 
function extensions to operate LISP map-assisted  networks (which might 
include Hierarchical Pull, Publish/Subscribe, or Push models and related 
security extensions, *or alternative transports of the LISP control 
protocol*).


Thanks,
Fabio





On 1/4/16 4:44 AM, Luigi Iannone wrote:

Hi and Happy 2016 to All,

time to restart our WG activity in this new year. ;-)

We tried to include all comments received via mail and stated during the last 
meeting in Japan into an updated charter.
Changes are relatively minor, showing that the WG has almost converged to a 
proposal.
Yet, before pushing the new charter to the IESG for approval, we would like to 
have a last short iteration in the WG.
Hereafter you can find the updated text.

If the text looks good for you, please state so in the mailing list.

If you think something is missing or can be improved, please state so in the 
mailing list.

Thanks

Joel and Luigi


 Updated Proposed Charter 

LISP WG has completed the first set of Experimental RFCs
describing the Locator/ID Separation Protocol (LISP).
LISP supports a routing architecture which decouples
the routing locators and identifiers, thus allowing for
efficient aggregation of the routing locator space and
providing persistent identifiers in the identifier space.
LISP requires no changes to end-systems or to routers
that do not directly participate in the LISP deployment.
LISP aims for an incrementally deployable protocol.
The scope of the LISP techology is recognized to range
from unicast and multicast overlays at Layer 2 as well
as at Layer 3, including NAT traversal, VPNs, and
supporting mobility as a general feature, independently
of wheter it is a mobile user or a migrating VM, hence
being applicable in both Data Centers and public Internet
environments.

The LISP WG is chartered to continue work on the LISP base
protocol with the main objective to develop a standard
solution based on the completed Experimental RFCs and the
experience gained from early deployments.

This work will include reviewing the existing set of
Experimental RFCs and doing the necessary enhancements to
support a base set of standards track RFCs. The group will
review the current set of Working Group documents to
identify potential standards-track documents and do the
necessary enhancements to support standards-track. It is
recognized that some of the work will continue on the
experimental track, though the group is encouraged to
move the documents to standards track in support of network
use, whereas the work previously was scoped to experimental
documents.

Beside this main focus, the LISP WG work on the following items:

-   NAT-Traversal

-   Mobility

-   Data-Plane Encryption

-   Multicast: Support for overlay multicast by means of
 replication as well as interfacing with existing
 underlay multicast support.

-   Models for managing the LISP protocol and deployments
 that include data models, as well as allowing for
 programmable management interfaces. These managament
 methods should be considered for both the data-plane,
 control-plane, and mapping system components

-   Multi-protocol support: Specifying the required
 extensions to support multi-protocol encapsulation
 (e.g.,   L2 or NSH – Network Service Headers). Rather
 than developing new encapsulations the work will aim
 at using existing well-established encapsulations or
 emerging from other Working Grops such as  NVO3 and SFC.

-   Alternative Mapping System Design. By extenting LISP
 with  new protocols support it is also necessary to
 develop the required mapping function extensions to
 operate LISP map-assisted  networks (which might
 include Hierarchical Pull, Publish/Subscribe, or Push
 models and related security extension).

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Adopting draft-farinacci-lisp-signal-free-multicast?

[Fabio Maino]

support.

Fabio

On 12/5/15 6:14 AM, Joel M. Halpern wrote:
This is a call for adoption  of 
draft-farinacci-lisp-signal-free-multicast.
Please speak up if you support or oppose adoption of this document.  
It has been presented multiple times to the working group, generally 
to positive reception as far as I can tell.


This call will last two weeks, until CoB 21-December-2015.

Yours,
Joel

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Way forward on 6830bis

[Fabio Maino]

On 11/5/15 11:06 AM, Damien Saucez wrote:

On 05 Nov 2015, at 10:48, Dino Farinacci  wrote:


On 05 Nov 2015, at 10:33, Dino Farinacci  wrote:

Hello,

By seeing Alberts presentation on SFC today I was just thinking that we could
split 6830 in two documents.

One document to present the data-plane (mostly Sec 5).

One document to present the control-plane (mostly Sec 6).

As Albert said the mapping system is generic (with LCAF).  Therefore it would
make it more logical (to me at least) to have a document to strictly talk about
the mapping system and it would increase the appeal of the mapping system by
not requiring people to care about the LISP encapsulation if they only need the
mapping system function.

The mapping system is in a separate document and spread across alt, ddt, and ms 
specs. The control-plane text in RFC6830 is defining an API to the mapping 
system. And I think you want it all in one place for completeness.


When  I was talking about mapping system, I was talking about the
“API” (Map-Request, Map-Reply, Map-Register… ).

I understand that it is not straightforward to make it in a nice way, but
the as LISP is about decoupling control-plane and data-plane it would
make sense to also decouple control and data-plane definition.

Imagine you want someone to only implement the control-plane, how
does he know what to implement exactly to be fully compliant?

This is clearly stated in RFC6830. That is, you can send a Map-Request for any 
reason. It doesn’t have to be invoked by arrival of a packet on an 
ITR/RTR/PITR. Tools like lig and rig are examples of this.



Of course for someone who knows LISP it is trivial that it is separated.  The
issue is how to move forward and ensure that LISP control plane is not bound at
all to a particular data-plane.  Actually, since the beginning we say LISP is
map-and-encap so it means two components mapping and encapsulation, that seems
thus very logical to me to have to documents, one for "mapping", one for
“encapsulation".

At a first glance it could look like just being marketing but actually splitting
would allow both planes to be developed (and updated) in parallel.



Damien,
I think this could be a good idea. Too many people still associate LISP 
mostly with the encap (and it looks like too many don't read past the 
title of the RFC... :-(


We should also do a better work of explaining that LISP CP can be used 
as generic mapping service for overlays (not only for on-demand LISP 
tunnel provisioning).


In retrospective we should have presented the LISP/NSH draft in SFC as 
well.There might be more SFC use cases that can be addressed by the LISP 
CP. It'd be helpful to have the people in SFC give a thought to the 
concept of map assisted overlays.


Fabio




Damien Saucez


Dino


Damien Saucez


Dino


Cheers,

Damien Saucez

On 27 Oct 2015, at 01:25, Joel M. Halpern  wrote:


It seemed to us that there was likely some confusiona bout how we expect to 
handle the revision of RCC 6830.  The following is what we currently expect.

Once we have a new charter approved, the chairs will appoint an editor for the 
revision of rfc6830.  That may be one of the existing authors, or a new person. 
 We will ask for volunteers.

Once we have an author, they will submit a starting ID called 
draft-ietf-lisp-rfc6830bis-00 which will be identical in content to the 
existing RFC.  That may require assistance from the RFC Editor to ensure that 
we get all the changes they made during final edit.

At that point, we will use the trouble ticket system to record issues that 
people bring up.  We will also discuss on the list what changes we wish to make 
according to the charter.  Things will tehn proceed in the usual fashion, using 
the trouble ticket system to help make sure we do not drop any of the issues.

Yours,
Joel & Luigi

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp