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

[[ nits ]]

[ section 12 ]

* "When the inner header is IPv6 then the flow label is not zero,
   it MAY be used to compute the hash."

  Perhaps:

* "When the inner header is IPv6 and the flow label is not zero,
   it MAY be used when computing the hash."

I support Roman's DISCUSS specifically with respect to Section 16.  I also support Martin's and Roman's DISCUSSes with respect to being explicit about what's safe for use on the public Internet.

Thank you for being responsive to the prior security feedback from the SECDIR (and thanks to Kyle Rose for performing it) and Security ADs in the return of this document to the telechat. 

I support Martin Duke’s DISCUSS position and endorse the creation of a dedicated section covering which protocol features should not be used on the internet.

Thanks for addressing my other DISCUSS and COMMENTS points.  This ballot is now pruned down to the remaining issues under discussion.

Thank you for considering and addressing my DISCUSS concerns.

Thank you for the work put into this document. This is really useful work and the document is easy to read. I also appreciate the way the document handles IPv6 and IPv4 at the same level. Selecting the UDP source port for ECMP based on the inner 5-tuple is smart .

Please find below a couple of non-blocking COMMENTs.

I also support Martin Duke's DISCUSS on ICMP.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
I find the use of "prepending a LISP header" unusual. Why not using the word "encapsulating" in a LISP packet? Or did I miss something? It may also slightly be confusing when parts of the text use "prepending" and others use "encapsulating".


-- Section 3 --
In "Egress Tunnel Router (ETR): ", is it required to be a 'server' to be able to do "A server host can be the endpoint of a LISP tunnel as well.". I would assume that any host can do it as well.
In "Ingress Tunnel Router (ITR):" per symmetry with ETR, can a server/client host also be the encapsulating endpoint of a LISP tunnel?

-- Section 4 --
I STRONGLY suggest to remove the "telnet" example and keep only "SSH".

Cosmetic: suggest to add reference to SSH, BGP, SNMP, ...

-- Section 5.3 --
For "outer header", there is specific text for the IPv4 DF-bit, DSCP, ... but what about specific IPv6 fields such as "flow label"?

Beside the convenience of making a bis document reflecting the original, defining the "R" bit as reserved when at the same IESG telechat there is the GPE document is really a missed opportunity IMHO.

Side comment (no need to reply), I am also puzzled why the outer DSCP is copied to the inner DSCP on decapsulation.

-- Section 10 --
Is it on purpose that IPv6 is ignored in "This is typically done when a /32 address is configured on a loopback interface." ?

-- Section 12 --
What is meant by "flow" in "The Source port SHOULD be the same for all packets belonging to the same flow." Probably worth defining it as packets with identical 5-tuple ?

I also suggest not to limit the load-balancing text to LAG but also to any topology where ECMP occurs.

Is there a reason why the hashing for LAG/load balancing is under the title of "Routing Locator Hashing"? The UDP source port selection is vaguely related but different than RLOC hashing.


-- Section 15 --
Unsure whether this performance section is still relevant in 2020, there are many similar overlay techniques.

== NITS ==


-- Section 1 --
There are some repetitions in this section such as "[I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. "

-- Section 3 --
When defining "anycast", I find that "An EID or RLOC can be an anycast address in each of their own address spaces." is more a property of EID/RLOC than adding anything to "anycast".

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.

I support Roman's first two DISCUSS points.

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.

I support the Security ADs DISCUSS positions.

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

Thanks for addressing my previous Discuss points.  I have some notes
locally for an analysis of the security considerations at the boundaries of
the various components in the ecosystem, and hope to have some text
soon.  That said, I'm balloting No Objection now anyway, to make my other
comments (from a fresh reread of the document) available now.

Section 1

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

nit: comma splice

Section 3

   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(?): this definition might be artifically narrow.  E.g., there might
be other cases when a prefix can be broken up, including when different
RLOC sets are to be assigned to sub-blocks of the larger EID-Prefix.

   End-System:   An end-system is an IPv4 or IPv6 device that originates
      packets with a single IPv4 or IPv6 header.  The end-system
      supplies an EID value for the destination address field of the IP
      header when communicating outside of its routing domain.  An end-

Just to check: when would an end-system supply a destination address
that is not an EID (i.e., what requires the "when communicating outside
of its routing domain" caveat)?  (This is in a mindset that assumes for
non-LISP systems the EID and RLOC collapse to the same value usable as
either EID or RLOC depending on context.)

   Routing Locator (RLOC):   An RLOC is an IPv4 [RFC0791] or IPv6
      [RFC8200] address of an Egress Tunnel Router (ETR).  An RLOC is
      the output of an EID-to-RLOC mapping lookup.  An EID maps to zero
      or more RLOCs.  Typically, RLOCs are numbered from blocks that are
      assigned to a site at each point to which it attaches to the
      underlay network; where the topology is defined by the
      connectivity of provider networks.  Multiple RLOCs can be assigned

nit: the bit after the semicolon is not a complete sentence; probably
just replacing it with a comma is best.

Section 4

   when re-routing of the path for a packet is desired.  A potential
   use-case for this would be an ISP router that needs to perform
   Traffic Engineering for packets flowing through its network.  In such
   a situation, termed "Recursive Tunneling", an ISP transit acts as an
   additional ITR, and the destination RLOC it uses for the new

nit: "Recursive Tunneling" is a defined term now, so we don't need quite
as much of an in-band definition.  Perhaps "in such a Recursive
Tunneling situation".

Section 4.1

       Request for that EID.  Both the ITR and the ETR MAY also
       influence the decision the other makes in selecting an RLOC.

It might be worth a bit more detail on how the one xTR influences the
decision of the other.

Section 5.3

   LISP Locator-Status-Bits (LSBs):  When the L-bit is also set, the
      'Locator-Status-Bits' field in the LISP header is set by an ITR to

nit: s/also// ?

Section 6

   The Map-Cache is a local cache of mappings, entries are expired based
   on the associated Time to live.  [...]

nit: comma splice

Section 7.1

   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

This seems to be the only indication that the mechanism described in
this subsection is an IPv4-only mechanism; it's probably worth being a
little more clear and up-front about that.

Section 9

   corresponding to the EID's topological location.  Each RLOC in the
   Locator-Set is associated with a 'Priority' and 'Weight', this
   information is used to select the RLOC to encapsulate.

nit: comma splice.

Section 10

   1.  An ETR MAY examine the Locator-Status-Bits in the LISP header of
       an encapsulated data packet received from an ITR.  If the ETR is
       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.

Since we said earlier that LSBs are "a hint to convey up/down router
status and not path reachability status", so I'd suggest rephrasing this
in terms of "use this status information to avoid selecting routers that
are down".

   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.  CE-based ITRs at the source
   site can determine reachability relative to each other using the site
   IGP as follows:

Similarly, we might clarify that this "reachability for all ETRs at the
site" reflects local reachability from the ITR in question, and may not
be indicative of reachability from the ETR receiving the LSBs.

   When ITRs at the site are not deployed in CE routers, the IGP can
   still be used to determine the reachability of Locators, provided
   they are injected into the IGP.  This is typically done when a /32
   address is configured on a loopback interface.

"/32 address" seems IPv4-specific.

   RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1.  The
   Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0
   to n-1 starting with the least significant bit.  For example, if an
   RLOC listed in the 3rd position of the Map-Reply goes down (ordinal
   value 2), then all ITRs at the site will clear the 3rd least
   significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for
   the packets they encapsulate.

It might be worth a forward-reference to § 13.2 to mention that, in line
with map versioning, the ITRs at the site already need to know the
Map-Reply contents and to also note that, per Section 5.5 of 6833bis,
the list of locators is sorted in a specific order.

Section 10.1

   When data flows bidirectionally between Locators from different
   sites, a Data-Plane mechanism called "nonce echoing" can be used to
   determine reachability between an ITR and ETR.  When an ITR wants to
   solicit a nonce echo, it sets the N- and E-bits and places a 24-bit
   nonce [RFC4086] in the LISP header of the next encapsulated data
   packet.

I do note the title of RFC 4086 and the resulting implication, but since
a generic "nonce" is just a "number used once" and can in such cases be
a simple counter, I think we really need to say "random nonce" (or
"selected from a uniform random distribution" or similar), since we do
rely on the unpredictability inherent in a random nonce.  For reference,
6833bis says "[t]he nonce MUST be generated by a properly seeded
pseudo-random source, see as an example [RFC4086]."

   The ITR will set the E-bit and N-bit for every packet it sends while
   in the echo-nonce-request state.  The time the ITR waits to process
   the echoed nonce before it determines the path is unreachable is
   variable and is a choice left for the implementation.

draft-ietf-tcpm-rto-consider, also on this week's telechat, might be an
interesting reference here.

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   erroneously consider the Locator unreachable.  An ITR SHOULD 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 Map-Reply
   message.

Do we want a corresponding "SHOULD NOT set the E-bit when [...]" here?

Also, this could be a good place to note that the Map-Reply E-bit is
spoofable in the absence of LISP-SEC.

   Many implementations default to not advertising they are echo-nonce
   capable in Map-Reply messages and so RLOC-probing tends to be used
   for RLOC reachability.

Do we want to hedge this with an "at the time of this writing" in case
it ages badly?

Section 13

   which ITRs requested its mappings.  For scalability reasons, it is
   desirable to maintain this approach but need to provide a way for
   ETRs to change their mappings and inform the sites that are currently
   communicating with the ETR site using such mappings.

nit: missing word (maybe s/need/there remains a need/?)

Section 13.1

   or down).  The specific value for the 'use-LSB' timer depends on the
   LISP deployment, the 'use-LSB' timer needs to be large enough for the
   destination xTR to retreive the updated EID-to-RLOC mappings.  A

nit: comma splice.

Section 16

   For example of such attacks, an off-path attacker can exploit the
   echo-nonce mechanism by sending data packets to an ITR with a random
   nonce from an ETR's spoofed RLOC.  Note the attacker must guess a
   valid nonce the ITR is requesting to be echoed within a small window
   of time.  [...]

I suggest noting that "the nonce echoing mechanism defined in this
document has only a 24-bit nonce, which is small enough that randomly
guessing a nonce will succeed with some regularity".
That would also give an opportunity to mention the idea, introduced in
lisp-gpe, that a dedicated shim header could be used to provide a longer
nonce that is strong enough to be reliable for route-returnability
checks (though I concede it's a bit far afield since it's a reference to
a reference to future work).

   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.

I'd suggest adding at the end ", or prevent updates from being processed".

   LISP implementations and deployments which permit outer header
   fragments of IPv6 LISP encapsulated packets as a means of dealing
   with MTU issues should also use implementation techniques in ETRs to
   prevent this from being a DoS attack vector.  Limits on the number of
   fragments awaiting reassembly at an ETR, RTR, or PETR, and the rate
   of admitting such fragments may be used.

I note that draft-ietf-intarea-frag-fragile might be a relevant
reference (and is in the RFC Editor's queue).

Section 20.1

How can RFC 6830 be a normative reference when this document Obsoletes
it?

It's not really clear that RFCs 6831 or 8378 need to be normative; we
mostly just mention that they exist but don't require implementing or
using them.

Section 20.2

In addition to what idnits picked up, I note that RFC 1918 is only
referenced from the changelog entry saying that it's not referenced
anymore :)

I could see an argument that RFC 6936 should be normative, but defer to
my TSV-area colleagues.

I'm slightly surprised to see that Mirja did not insist upon RFC 8085
being a normative reference.

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.

Thank you for addressing my DISCUSS.

Old Comment:

Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. It is not quite as simple as simply always copying DSCP to the outer packet.

Sec 9. I don't understand what this sentence means:

"The value of the 'Weight'  represents the relative weight of the total packets that match the maping entry." (s/maping/mapping, obviously)

What is the "relative weight" of packets? Is this the number of packets, the cumulative number of bytes, or something else?

Sec 16. "If  the attacker spoofs the source RLOC, it can mount a DoS attack by  redirecting traffic to the spoofed victim's RLOC, potentially  overloading it."

This not the only problem. The attacker could also DoS by directing traffic to an unreachable RLOC.

Given that this document is an update to an existing RFC and has already been through one IESG ballot, I have not read the entirety of this draft in detail.

A couple of minor comments:

8.  Using Virtualization and Segmentation with LISP

   For example, an 802.1Q VLAN tag or VPN identifier could be used as a
   24-bit Instance ID.  See [I-D.ietf-lisp-vpn] for LISP VPN use-case
   details.

Standard 802.1Q VLAN identifiers are only 12 bits (unless an I-SID is being used), so possibly you might want to slightly elaborate here.  E.g. do you potentially mean a pair of 802.1Q VLAN tags?

17.  Network Management Considerations

   Considerations for network management tools exist so the LISP
   protocol suite can be operationally managed.  These mechanisms can be
   found in [RFC7052] and [RFC6835].

Given that SNMP is on its way out, having an informative reference to the work-in-progress LISP YANG model may be helpful here.
 
Regards,
Rob

Thanks for addressing my DISCUSS.