[lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-rfc6830bis-32: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-32: No Objection

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/



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

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.