LISP Generic Protocol Extension
draft-ietf-lisp-gpe-07

Summary: Has 3 DISCUSSes. Needs 3 more YES or NO OBJECTION positions to pass.

Alissa Cooper Discuss

Discuss (2018-09-27 for -06)
In the thread with the Gen-ART reviewer, the rationale that was given for advancing this document now even though rfc6834bis is nascent was:

"We do not expect big changes in any bis document, since they are just the PS version of deployed technology."

This seems somewhat less likely given the feedback received on the LISP documents on the telechat this week, so I'd like to discuss whether it really makes sense to advance this one now given its normative dependencies on 6834bis and 6830bis.

Benjamin Kaduk Discuss

Discuss (2018-09-27 for -06)
[Unlike for the 683xbis documents, this is a more mundane Discuss, with one
process issue and one issue of clarity with respect to randomness
requirements, that should be fairly easy to resolve.]

I think that 8060 needs to be a normative reference; it seems to be needed to
implement the Multiple Data-Planes LCAF type.  Arguably 6040 also should
be, though that seems less clear-cut to me.
(8060 would be a new normative downref and require another IETF LC, IIUC.)

Section 3 notes:
      The encoding of the Nonce field in LISP-GPE, compared with the one
      used in [I-D.ietf-lisp-rfc6830bis] for the LISP data plane
      encapsulation, reduces the length of the nonce from 24 to 16 bits.
      As per [I-D.ietf-lisp-rfc6830bis], Ingress Tunnel Routers (ITRs)
      are required to generate different nonces when sending to
      different Routing Locators (RLOCs), but the same nonce can be used
      for a period of time when encapsulating to the same Egress Tunnel
      Router (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.
That seems to be missing the point of the nonce -- it's not just for unique 
identification but also to prevent off-path attackers from guessing a
valid value and spoofing a bogus map-reply!  Using the entire 64k of nonce
space means that such a spoofing attack can succeed pretty reliably (e.g.,
by over-claiming so that the response EID-prefix contains whatever the
request was for).  I think it's important to accurately describe what
properties are required of indivdiual nonces and the combined set of active
nonces, which this text seems to mischaracterize.
Comment (2018-09-27 for -06)
No email
send info
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
case be sent via triangle-routing, in which case the establishment and
selection of IPsec security associations is somewhat nontrivial and
probably does not quality as "typical", based on my limited experience.
I think a more general scheme for providing integrity protection for
mapping messages is needed as a mandatory mechanism, but that's a topic for
the control-plane document so I will not belabor it here.

Mirja Kühlewind Discuss

Discuss (2018-09-19 for -05)
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?

Also, I'm not an expert for that part, but I guess there also is further guidance needed on HOW to map the VID...?
Comment (2018-09-19 for -05)
No email
send info
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.

Deborah Brungard Yes

Ignas Bagdonas No Objection

Suresh Krishnan No Objection

Comment (2018-09-27 for -06)
No email
send info
This draft needs to update RFC6830 since it takes the last reserved bit away from there. As a side question, since 6830 is being bised right now should this flag be acknowledged in the bis draft?

I am also interested to see the resolution to Mirja's DISCUSS point about the PCP and VID mappings.

Warren Kumari No Objection

Comment (2018-09-23 for -06)
No email
send info
This review is incomplete -- I'm traveling and hope to be able to get back to it later, but for now I have a comment:

Section 1. Introduction:
"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."

I'm unable to parse the above, especially around the "that has allocated all by defining" but.

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2018-09-25 for -06)
No email
send info
3.1.1.  Payload Specific Transport Interactions for Ethernet
        Encapsulated Payloads

   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.

3.1.2.  Payload Specific Transport Interactions for NSH Encapsulated
        Payloads

   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).

Not being a specialist in this technology it is not clear to me whether "MAY be mapped" above (in 2 places)
provides enough details to implement. Are there any extra references that you should insert above?

Alvaro Retana No Objection

Comment (2018-09-25 for -06)
No email
send info
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.

(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.

(3) §3: For clarity, it would be nice to add a figure showing the header with the P and V bits 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.

(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.

Martin Vigoureux No Objection

Roman Danyliw No Record

Barry Leiba No Record

Adam Roach No Record

Éric Vyncke No Record

Magnus Westerlund No Record