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

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-16: 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 a couple of smaller discuss points with should be straight-forward to
address and one more high-level discussion point that might not have a solution
(depending on the deployment status of LISP I guess) but I would like to at
least have a discussion. I start with the straight-forward onces:

1) Unfortunately ECN decapsulation is slightly more complicated than described
in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly
(maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)!
(Also it seems like the text on ECN is simply just twice in sec 5.3; not sure
that is helpful).

2) Further, also in sec 5.3:
"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."
However, I didn't find any exceptions listed later in the doc. However, setting
the DSCP field might also be matter of local policy. E.g. if DSCP is not used
for a different purpose in the receiver side LISP network, it could make sense
to restore/keep the original value in the inner header.

3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while
"IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well.

4) I would like to see another sentence in section 12 explicitly stating that
the source port SHOULD be the same for all packet belong to the same flow.

5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet."
What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or
maybe the packet should be dropped or something? Please clarify in the doc!

6) And now the more-discussion-needed point:
So my underlying concern is the same as brought up by the TSV-ART review that
lisp information are not end-to-end integrity protected or authenticated.
However, while briefly thinking about how this could be eventually realized, I
noticed that there is actually no mechanism to extend the LISP header in any
way. There is no version, no option and the LISP header seems to have a fixed,
implicitly specified length without an explicit length field. This seems too
late to add any kind of extensibility mechanism at this stage of the protocols
lifetime, however, I would still like to discuss if there was any discussion
about extensibility, what was the reason to chose this approach, and potential
if some background about the choice should be given in the doc.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the
language to more what RFC4459 recommends: OLD "This behavior is performed by
the ITR when the source host originates
   a packet with the 'DF' field of the IP header set to 0."
MAYBE:
"This behavior MAY be performed by the ITR only when the source host originates
   a packet with the 'DF' field of the IP header set to 0.

2) Sec 4: "...this document recommends that a maximum of two
   LISP headers can be prepended to a packet."
MAYBE:
"it is RECOMMENDED that a maximum of two
   LISP headers can be prepended to a packet."
?