The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-32

Ballot deferred by Eric Rescorla on 2018-09-11.

Summary: Has a DISCUSS. Needs 5 more YES or NO OBJECTION positions to pass.

Benjamin Kaduk Discuss

Discuss (2020-01-12 for -29)
[Someone (me?) still owe some analysis on the security considerations at the boundaries
of the various components in the ecosystem.  Deborah putting this back on an IESG
telechat as a returning item might be the most expedient way to get this to happen, sadly.]
Comment (2019-12-30 for -29)
No email
send info
Thank you for the discussion of Map-Version synchronization requirements!
I'm not in a position to assess whether the current 1-minute window is
adequate for the expected usage, and trust that you picked something reasonable.

We had a good exchange off-list about my comments on the -26/-27; I'm going
to keep a couple of the points from that but expand on them when the original was
unclear.

Section 10.1

Some side discussion: in some sense, the echo nonce functionality is the
most reliable method for determining reachability, and yet we say that it
MAY be overridden by other methods.
There's also some potential conflict between the "will set the E-bit and
N-bit for every packet it sends while in the echo-nonce-request state" and
the later text about echoing the peer's nonce when both ETR and ITR go into
the echo-nonce-request state at the same time, since if the E-bit and N-bit
are sent on literally every packet sent, then it's not possible to send packets
that echo the peer's nonce (which would just set the N-bit but not the E-bit,
if I understand correctly).

   erroneously consider the Locator unreachable.  An ITR SHOULD only set
   the E-bit in an encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
   probe Map-Reply message.

Is this only in RLOC-probe Map-Reply messages (and not generic, including
mapping-driven, Map-Reply messages)?   Specifically, my understanding was that
any Map-Reply could set the E-bit to indicate support for echo noncing, and so
there's not much point in us specifically qualifying that the E-bit is set in an
*RLOC-probe* Map-Reply (as opposed to just "a Map-Reply"). If this behavior
is specific to the RLOC-probe replies, I think that 6833bis needs
some clarification in Section 5.4.

(Mirja Kühlewind) Discuss

Discuss (2018-09-11 for -16)
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 (2018-09-11 for -16)
No email
send info
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."
?

(Eric Rescorla) Discuss

Discuss (2018-09-27 for -20)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3126

See my DISCUSS on 6833bis for overall issues. This is just detailed issues
on 6830bis as I went through it.


DETAIL
S 4.1.
>          RLOC (outer-header source IP address) in a received LISP packet.
>          Such a cache entry is termed a "glean mapping" and only contains
>          a single RLOC for the EID in question.  More complete information
>          about additional RLOCs SHOULD be verified by sending a LISP Map-
>          Request for that EID.  Both the ITR and the ETR MAY also
>          influence the decision the other makes in selecting an RLOC.

This seems like it introduces an immediate overclaiming problem.


S 10.
>      When an ETR decapsulates a packet, it will check for any change in
>      the 'Locator-Status-Bits' field.  When a bit goes from 1 to 0, the
>      ETR, if acting also as an ITR, will refrain from encapsulating
>      packets to an RLOC that is indicated as down.  It will only resume
>      using that RLOC if the corresponding Locator-Status-Bit returns to a
>      value of 1.  Locator-Status-Bits are associated with a Locator-Set

This seems to enable a pretty obvious denial of service attack in
which you send  a message with all LSBs set to 0.


S 10.
>      list returned by the last Map-Reply will be set to zero for that
>      particular EID-Prefix.  Refer to Section 16 for security related
>      issues regarding Locator-Status-Bits.
>   
>      When an ETR decapsulates a packet, it knows that it is reachable from
>      the encapsulating ITR because that is how the packet arrived.  In

It doesn't even know this. It just knows that that's been claimed by
someone who can generate traffic to it.


S 10.1.
>      NOT use the lack of return traffic as an indication that the ETR is
>      unreachable.  Instead, it MUST use an alternate mechanism to
>      determine reachability.
>   
>   10.1.  Echo Nonce Algorithm
>   

This mechanism seems sufficient to verify unreachability but is not a
secure test of reachability because the nonce is way too short.


S 16.
>      Map-Versioning is a Data-Plane mechanism used to signal a peering xTR
>      that a local EID-to-RLOC mapping has been updated, so that the
>      peering xTR uses LISP Control-Plane signaling message to retrieve a
>      fresh mapping.  This can be used by an attacker to forge the map-
>      versioning field of a LISP encapsulated header and force an excessive
>      amount of signaling between xTRs that may overload them.

Can't I also set a super-high version number, thus gagging updates?
Comment (2018-09-27 for -20)
No email
send info
S 5.3.
>         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

This should probably be a MUST because there are other protocols that
assume that TTLs get decremented.


S 7.1.
>      destination site.  The two fragments are reassembled at the
>      destination host into the single IP datagram that was originated by
>      the source host.  Note that reassembly can happen at the ETR if the
>      encapsulated packet was fragmented at or after the ITR.
>   
>      This behavior MAY be performed by the ITR only when the source host

Nit: I think you want to say MUST be, assuming you mean that you can
perform it only if....


S 7.2.
>      2.  When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
>          with the DF bit set to 1, exceeds what the core network can
>          deliver, one of the intermediate routers on the path will send an
>          ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/
>          Fragmentation-Needed to the ITR, respectively.  The ITR will
>          parse the ICMP message to determine which Locator is affected by

What if you are in an environment where ICMP is blocked?


S 9.
>         outside of the subset list if it determines that the subset list
>         is unreachable (unless RLOCs are set to a Priority of 255).  Some
>         sharing of control exists: the server-side determines the
>         destination RLOC list and load distribution while the client-side
>         has the option of using alternatives to this list if RLOCs in the
>         list are unreachable.

How would you obtain alternative RLOCs?


S 10.
>          also acting as an ITR and has traffic to return to the original
>          ITR site, it can use this status information to help select an
>          RLOC.
>   
>      2.  When an ETR receives an encapsulated packet from an ITR, the
>          source RLOC from the outer header of the packet is likely up.

What does "is likely up" mean?

Deborah Brungard Yes

(Ignas Bagdonas) No Objection

Comment (2019-02-07 for -26)
No email
send info
As a (mostly happy) user of the specified technology for a proof that it works I am inclined to ballot a YES. For practical purposes it is not expected that LISP will be deployed globally end to end, it is a localized mechanism for (mostly) controlled environments. This, however, does not mean that security concerns raised are to be ignored, therefore I do have sympathy for DISCUSSes raised by SEC ADs. The industry needs to continue experimenting with LISP, trying to build it ideal at the first try is not realistic. Therefore NO OBJECTION.

(Ben Campbell) No Objection

Comment (2018-09-27 for -20)
No email
send info
I support the Security ADs DISCUSS positions.

(I was unfortunately not able to do more than a cursory review due to external time constraints.)

Alissa Cooper No Objection

Comment (2019-02-06 for -26)
No email
send info
I find the SEC ADs' DISCUSS positions concerning and support the resolution of their security concerns.

(Spencer Dawkins) No Objection

(Suresh Krishnan) (was Discuss) No Objection

Comment (2018-10-01 for -22)
No email
send info
Thanks for addressing my DISCUSS.

Warren Kumari (was Discuss) No Objection

Comment (2019-06-17 for -27)
No email
send info
Thank you for considering and addressing my DISCUSS concerns.

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2018-09-27 for -20)
No email
send info
I share many of the security related concerns raised by Benjamin.

The document is otherwise readable. I have one specific question:

12.  Routing Locator Hashing

   When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
   that is stored in the Map-Cache of a requesting ITR, the Locator-Set
   for the EID-Prefix MAY contain different Priority and Weight values
   for each locator address.  When more than one best Priority Locator
   exists, the ITR can decide how to load-share traffic against the
   corresponding Locators.

   The following hash algorithm MAY be used by an ITR to select a
   Locator for a packet destined to an EID for the EID-to-RLOC mapping:

   1.  Either a source and destination address hash or the traditional
       5-tuple hash can be used.  The traditional 5-tuple hash includes
       the source and destination addresses; source and destination TCP,
       UDP, or Stream Control Transmission Protocol (SCTP) port numbers;
       and the IP protocol number field or IPv6 next-protocol fields of
       a packet that a host originates from within a LISP site.  When a
       packet is not a TCP, UDP, or SCTP packet, the source and
       destination addresses only from the header are used to compute
       the hash.

Ok, maybe this is just me, but you don't actually define how to hash these things, you are only talking about what needs to be covered by the hash. I appreciate that picking a specific hashing algorithm is probably not relevant for interoperability, but I feel adding a specific algorithm (as an example or via a pointer) would improve the document.

Alvaro Retana No Objection

Comment (2018-09-10 for -16)
No email
send info
Thanks for the work on this document!

I have some relatively minor comments/nits:

(1) §18: s/RFC8060/RFC8061

(2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture."  First of all, it would seem to me that the Architecture should be a Normative reference...but I-D.ietf-lisp-introduction says that it "is used for introductory purposes, more details can be found in RFC6830, the protocol specification."  This document obsoletes rfc6830...so it seems to me that there is a failed circular dependency.

(3) References to rfc2119/rfc8174 and rfc8126 should be Normative.

(Adam Roach) No Objection

Martin Vigoureux No Objection

Roman Danyliw No Record

Martin Duke No Record

Erik Kline No Record

Murray Kucherawy No Record

Barry Leiba No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record