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

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

Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.

Benjamin Kaduk Discuss

Discuss (2019-02-07 for -26)
Section 3 still contains text:

   EID-to-RLOC Database:   The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC

that indicates that the mapping database is a single, global, distributed
database; we had previously agreed that the target scope was much more
narrow.  I could perhaps charitably assume that this instance was missed as an
editing error because the phrase "global distributed database" spans a line
break, but given that this specific instance was called out in my previous
discuss position, it is fairly hard to do so.

Also in Section 3:
   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

The various places where we mention "gleaming" or similar unauthenticated
(un-path-verified?) schemes for learning mapping information should all
mention at their description that they are susceptible to spoofing and link
to the security considerations.

I'm still concerned about the synchronization requirements between
map-version changes and LSB usage; with the currently described technology
it seems almost inevitable for race conditions around RLOC changes to cause
ITRs to make incorrect routing decisions due to misinterpreted status bits.
It's unclear whether it's even worth trying to tackle this problem before
the map-versioning document is more advanced along in the process, though.
(Several comments throughout are relevant, especially those on Section
13.1.)

I agree with Warren that clarity on whether traffic is buffered or dropped
during the lookup process is needed (e.g., in Section 6).

Also in the vein of Warren's comments, in Section 7.1 I was expecting (from
our previous discussions) that some text would be added about the
determination of L being something that is "performed once by the
administrator of the LISP deployment and treated as a constant across the
deployment".

The discussion of Instance IDs remains incomplete, with no discussion of
within what scope their values must be unique (as truncated to 24 bits).

Similarly (also Section 8),
                                                              Multiple
   Data-Planes can use the same 32-bit space as long as the low-order 24
   bits don't overlap among xTRs.

That's a pretty lousy property to have in a PS specification.

Section 13

   When a Locator record is removed from a Locator-Set, ITRs that have
   the mapping cached will not use the removed Locator because the xTRs
   will set the Locator-Status-Bit to 0.  So, even if the Locator is in
   the list, it will not be used.  For new mapping requests, the xTRs
   can set the Locator AFI to 0 (indicating an unspecified address), as
   well as setting the corresponding Locator-Status-Bit to 0.  This

I do not remember there being an ordering (or even consistency) requirement
on the ITR-RLOC entries in the Map-Request, so it's unclear that just
replacing one entry with an AFI-0 entry would convey this information.  I
suppose that using only a single ITR-RLOC entry, with AFI 0, would provide
a usable signal to the ETR, but that does not seem to be what is being
described here.  (Also, on a rhetorical point, please clarify that the "as
well as" is for setting the LSB to 0 in data packets; Map-Requests do not
include any LSBs.)

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the Locator-Set and new
   records appended to the Locator-Set. At some point, it would be
   useful to compact the Locator-Set so the Locator-Status-Bit settings
   can be efficiently packed.

This text, implying that compactification must wait for some unspecified
later event, seems to be assuming some requirement to preserve order of
Locator-Set entries that I cannot find a description of in either 6830bis
or 6833bis.

Do RFCs 6831 and 8378 need to be normative references for how to do
multicast as an optional protocol feature (recalling that
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
clarifies that references that are relevant only for optional features are
still classified as normative)?

In Section 16:

   A complete LISP threat analysis can be found in [RFC7835].  In what

RFC 7835 remains an incomplete analysis; please stop referring to it as
such.

   of time.  The goal is to convince the ITR that the ETR's RLOC is
   reachable even when it may not be reachable.  If the attack is

I think Warren is correct that there is also an attack that lies in
convincing an ITR that an ETR is not reachable even when it is reachable.


The following items were present in my original DISCUSS position and still
have not been resolved.  Note that I copy below the previous ballot text
even for some issues that are described above already in different words.

Section 4.1's Step (6) only mentions parsing "to check for format
validity".  I think it is appropriate to mention (and refer to) source
authentication checks as well, since bad Map-Reply data can allow all sorts
of attacks to occur.

There are some fairly subtle ordering requirements between the order of
entries in Map-Reply messages and the Locator-Status-Bits in data-plane
traffic (so that the semantic meaning of the status bits are meaningful),
which is only given a minimal treatment in the control-plane document.  The
need for synchronization in interpreting these bits should be mentioned
more prominently in the data-plane document as well.

The usage of the Instance ID does not seem to be adequately covered; from
what I've been able to pick up so far it seems that both source and
destination participants must agree on the meaning of an Instance ID, and
the source and destination EIDs must be in the same Instance.  This does
not seem like it is compatible with Internet scale, especially if there are
only 24 usable bits of Instance ID.

There seems to be a lot of intra-site synchronization requirements, notably
with respect to Map-Version consistency, the contents and ordering of
locator sets for EIDs in the site, etc.; the actual hard requirements for
synchronization within a site should be clearly called out, ideally in a
single location.

The security considerations attempt to defer substantially to the
threat-analysis in RFC 7835, which does not really seem like a complete
threat analysis and does not provide analysis as to what requirements are
placed on the boundaries between the different components of LISP (data
plane, control plane, mapping system, various extensions, etc.).  The
secdir reviewer had some good thoughts in this space.

I am not convinced that this protocol meets the current IETF requirements
for the security properties of Standards-Track Protocols without at least
LISP-SEC as a mandatory-to-implement component, and possibly additional or
stronger requirements.  (I did not do a full analysis of the system in the
presence of those security mechanisms, since that is not what is being
presented for review.)
[ed. even though LISP-SEC has been promoted to MTI, it remains difficult to
be confident in the results of a full system analysis due to the number of
other outstanding issues with the core documents.  Consider the risk Ekr
noted yesterday in email about tampering with the Map-Request causing
apparently-valid repsonses that convey incorrect results with respect to
the original query.]
Comment (2019-02-07 for -26)
I note as a preface that in many places in this (and other) review, I ask
questions.  The ones that indicate I actually don't understand are
generally accompanied by text like "just to confirm" or provide some option
for possible interpretation.  Others are intended as rhetorical devices,
indicating that the text locally at this point in the document is unclear
and the question posed should be addressed in the document, in-line.

Section 1

                                                         LISP
   encapsulation uses a dynamic form of tunneling where no static
   provisioning is required or necessary.

Do I interpret this correctly as meaning that no static provisioning is
necessary on end-hosts?  It seems that ETRs and the mapping system
entities definitely need static configuration.  But do end sites need to
know what lisp site/administrative domain they are part of?

   LISP is an overlay protocol that separates control from Data-Plane,
   this document specifies the Data-Plane, how LISP-capable routers
   (Tunnel Routers) exchange packets by encapsulating them to the
   appropriate location.  [...]

nit: this is a comma splice

Section 3

   Anycast Address:  Anycast Address is a term used in this document to

How does this definition differ from the one in RFC 8499?

   Data-Probe:   A Data-Probe is a LISP-encapsulated data packet where
      the inner-header destination address equals the outer-header
      destination address used to trigger a Map-Reply by a decapsulating
      ETR.  [...]

nit: is this better as two sentences?  ("...is a LISP-encapsulated data
packet where the inner-header destination address equals the outer-header
destination address.  It is used to trigger...")

I would also say something in this paragraph about how this behavior blurs
the distinction between EID and RLOC.

                    When using Data-Probes, by sending Map-Requests on
      the underlying routing system, EID-Prefixes must be advertised.

I don't understand why the one follows from the other (in fact, there seem
to be three not-particularly-related concepts in this sentence).

(I also note that "Data-Probe" is not mentioned anywhere in this document
other than its own definition, which would suggest that it could be moved
to 6833bis, which does mention them.)

   EID-to-RLOC Database:   The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC

I thought we had agreed to remove this "global distributed database"
language.

      addresses that are routable on the underlay.  Note that there MAY
      be transient conditions when the EID-Prefix for the site and
      Locator-Set for each EID-Prefix may not be the same on all ETRs.

nit: we haven't indicated a definite site for "the site" to be meaningful.

   EID-to-RLOC Map-Cache:   The EID-to-RLOC Map-Cache is generally
      short-lived, on-demand table in an ITR that stores, tracks, and is
      responsible for timing out and otherwise validating EID-to-RLOC
      mappings.  This cache is distinct from the full "database" of EID-
      to-RLOC mappings; it is dynamic, local to the ITR(s), and
      relatively small, while the database is distributed, relatively
      static, and much more global in scope to LISP nodes.

"global" caught my eye again here; perhaps "global in scope to a LISP
deployment"?

   EID-Prefix:   An EID-Prefix is a power-of-two block of EIDs that are
      allocated to a site by an address allocation authority.  EID-
      Prefixes are associated with a set of RLOC addresses.  EID-Prefix
      allocations can be broken up into smaller blocks when an RLOC set
      is to be associated with the larger EID-Prefix block.

nit: I think the causality here is backwards -- the breaking up does not
occur at the moment that you associate an RLOC set to a larger EID-Prefix
block.

   Endpoint ID (EID):   An EID is a 32-bit (for IPv4) or 128-bit (for
      IPv6) value used in the source and destination address fields of
      the first (most inner) LISP header of a packet.  [...]

6833bis says (section 5.8) that the inner header can use either RLOC or EID
addresses in the header address fields, which contradicts this statement.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's

Er, that the ISP ITR uses as source or as destination?

   Negative Mapping Entry:   A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty, one with an encoded Locator
      count of 0.  This type of entry could be used to describe a prefix
      from a non-LISP site, which is explicitly not in the mapping
      database.  There are a set of well-defined actions that are
      encoded in a Negative Map-Reply.

This bit about Negative Map-Replys comes out of the blue; is it really
needed in this paragraph?

   TE-ETR:   A TE-ETR is an ETR that is deployed in a service provider
      network that strips an outer LISP header for Traffic Engineering
      purposes.

nit: is it really the act of stripping the header that is done for TE
purposes?

Section 4.1

   2.  The LISP ITR must be able to map the destination EID to an RLOC
       of one of the ETRs at the destination site.  The specific method
       used to do this is not described in this example.  See
       [I-D.ietf-lisp-rfc6833bis] for further information.

   3.  The ITR sends a LISP Map-Request as specified in
       [I-D.ietf-lisp-rfc6833bis].  Map-Requests SHOULD be rate-limited.

At risk of repeating myself, isn't (3) just doing what (2) says the ITR
must be able to do?  I don't see why both items are needed.

   5.  The ETR looks at the destination EID of the Map-Request and
       matches it against the prefixes in the ETR's configured EID-to-
       RLOC mapping database.  This is the list of EID-Prefixes the ETR
       is supporting for the site it resides in.  If there is no match,
       the Map-Request is dropped.  Otherwise, a LISP Map-Reply is

Isn't this (1) something that 6833bis should be authoritative on, and (2)
a recipe for random hangs if the mapping system ever misdirects a
map-request?

   7.  Subsequent packets from host1.abc.example.com to
       host2.xyz.example.com will have a LISP header prepended by the

The use of "subsequent" implies that he original IP packet does not receive
this treatment.  But we don't say anywhere that it gets dropped, leaving us
guessing as to what is supposed to happen to it.

   9.  In order to defer the need for a mapping lookup in the reverse
       direction, an ETR can OPTIONALLY create a cache entry that maps
       the source EID (inner-header source IP address) to the source
       RLOC (outer-header source IP address) in a received LISP packet.
       Such a cache entry is termed a "glean mapping" and only contains

This gleaming seems susceptible to spoofing.

Section 5.3

   L: The L-bit is the 'Locator-Status-Bits' field enabled bit.  When
      this bit is set to 1, the Locator-Status-Bits in the second
      32 bits of the LISP header are in use.

What happens to those bits when the L-bit is set to zero?

   E: The E-bit is the echo-nonce-request bit.  This bit MUST be ignored
      and has no meaning when the N-bit is set to 0.  When the N-bit is
      set to 1 and this bit is set to 1, an ITR is requesting that the

Do we need to say what to do when N is 1 and E is 0?

   LISP Locator-Status-Bits (LSBs):  When the L-bit is also set, the
      [...]
      the ETRs at the same site.  When a site has multiple EID-Prefixes
      that result in multiple mappings (where each could have a
      different Locator-Set), the Locator-Status-Bits setting in an
      encapsulated packet MUST reflect the mapping for the EID-Prefix
      that the inner-header source EID address matches.  If the LSB for

I don't think there is guaranteed to be a single unique EID-Prefix that
matches the inner source EID; we need to say longest-match here.

   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 outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) to the inner-header.

IPv6 is a first-class IP protocol; it should not be relegated to a
parenthetical.

   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.

Where is the decrementing of the TTL documented?  I just see "copy" in the
above text.

Is the last paragraph adding anything that was not already said previously?
It seems pretty redundant on first read.

Section 6

             Finally, the Map-Cache also contains reachability
   information about EIDs and RLOCs, and uses LISP reachability
   information mechanisms to determine the reachability of RLOCs, see
   Section 10 for the specific mechanisms.

nit: The Map-Cache performs reachability discovery?  That seems incongruous with
a cache nature; perhaps it is better to say that it is updated with the
results of such procedures.

Section 7.1

                     Note that reassembly can happen at the ETR if the
   encapsulated packet was fragmented at or after the ITR.

Why would an ETR want to take on this additional state-keeping burden
instead of relegating it to the end host?

   When the 'DF' field of the IP header is set to 1, or the packet is an
   IPv6 packet originated by the source host, the ITR will drop the
   packet when the size is greater than L and send an ICMPv4 ICMP

Which size?

Section 9

   o  Either side (more likely the server-side ETR) decides not to send
      a Map-Request.  For example, if the server-side ETR does not send
      Map-Requests, it gleans RLOCs from the client-side ITR, giving the

[in the next paragraph we talk about sending Map-Requests to verify gleamed
mappings, which doesn't mesh very well with "does not send Map-Requests"
here]

      client-side ITR responsibility for bidirectional RLOC reachability
      and preferability.  Server-side ETR gleaning of the client-side
      ITR RLOC is done by caching the inner-header source EID and the
      outer-header source RLOC of received packets.  [...]

Isn't this susceptible to spoofing?

   Instead of using the Map-Cache or mapping system, RLOC information
   MAY be gleaned from received tunneled packets or Map-Request
   messages.  A "gleaned" Map-Cache entry, one learned from the source

To double-check, this is describing the same behavior described in the iast
bullet point?

   RLOC of a received encapsulated packet, is only stored and used for a
   few seconds, pending verification.  Verification is performed by
   sending a Map-Request to the source EID (the inner-header IP source
   address) of the received encapsulated packet.  A reply to this

As I commented on 6833bis, I'd appreciate mention that this
"verification" is akin to reverse-routability verification and does not
involve any cryptographic assurances.

                    This "gleaning" mechanism is OPTIONAL, refer to
   Section 16 for security issues regarding this mechanism.

nit: comma splice

Section 10

   2.  When an ETR receives an encapsulated packet from an ITR, the
       source RLOC from the outer header of the packet is likely to be
       reachable.

Liktely to, but not guaranteed, since that's a spoofable field and we rely
on the ITR to fill it with something useful.

   When determining Locator up/down reachability by examining the
   Locator-Status-Bits from the LISP-encapsulated data packet, an ETR
   will receive up-to-date status from an encapsulating ITR about
   reachability for all ETRs at the site.  [...]

This ("up-to-date") wording concerns me, relating to the interaction
between map-versioning, addition/removal of locators from a mapping, and
propagation to values in the LSBs.  I do not think there is currently a
strong consistency guarantee in place that would justify the "up-to-date"
wording, and 6834bis has not received IETF (or IESG) review yet.  My
current understanding is that the status information provided via this
mechanism could be characterized as "best-effort" or "accurate in the
steady-state".

   The security considerations of Section 16 related with data-plane
   reachability applies to the data-plane RLOC reachability mechanisms

nit: I think this is "related to", not "related with".

Section 10.1

   When this packet is received by the ETR, the encapsulated packet is
   forwarded as normal.  When the ETR is an xTR (co-located as an ITR),
   it next sends a data packet to the ITR (when it is an xTR co-located

nit: I don't think this is grammatical; maybe "when it next sends"?

   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)?  If so, I think that 6833bis needs
some clarification in Section 5.4.  (If not, I think that "RLOC-probe"
should be removed from here.)

Section 13

   ignores them.  However, this can only happen for locator addresses
   that are lexicographically greater than the locator addresses in the
   existing Locator-Set.

(It might be apropos to explicitly remind the reader that the entries in the
locator-set are sorted by IP address.)

   When a Locator record is removed from a Locator-Set, ITRs that have
   the mapping cached will not use the removed Locator because the xTRs
   will set the Locator-Status-Bit to 0.  So, even if the Locator is in

Why will the xTRs set the Locator-Status-Bit to 0?  Won't they just use
the updated mapping and have a smaller number of LSBs in their data
packets?

   If many changes occur to a mapping over a long period of time, one
   will find empty record slots in the middle of the Locator-Set and new
   records appended to the Locator-Set. At some point, it would be

How can this happen when the Locator-Set is required to be sorted?  Or does
the sorting requirement not apply to the "Map-Reply Record" field of the
Map-Request?

Section 13.1

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Server to assure that all ETRs
   for a site registering to it will be synchronized according to Map-
   Version Number.

This seems vastly underspecified not just to the detailed semantics (for
which the 6834bis reference is probably a suitable replacement) but also
the goals of the synchronization that is to be obtained.  It's unclear to
me that it's appropriate to mention Map-Register and versions at all in
this document; instead we might just note that 6834bs provides for version
synchronization for the ETRs within a site.  (If that's what it does; I
haven't yet read it in detail.)

Section 14

   Just like it would if the destination EID was a unicast address.

nit: this is a sentence fragment; I suggest joining to the previous
sentence with a comma.

Section 20.2

Maybe throw us a bone and include the string
"draft-iannone-openlisp-implementation" in the [OPENLISP] entry?

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)
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)
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)
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)
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)
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)
Thanks for addressing my DISCUSS.

Warren Kumari (was Discuss) No Objection

Comment (2019-06-17)
Thank you for considering and addressing my DISCUSS concerns.

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2018-09-27 for -20)
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)
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

Barry Leiba No Record

Éric Vyncke No Record

Magnus Westerlund No Record