[lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-rfc6830bis-32: (with COMMENT)
Benjamin Kaduk via Datatracker <email@example.com> Thu, 09 July 2020 04:20 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D45793A00B3; Wed, 8 Jul 2020 21:20:01 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk via Datatracker <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Luigi Iannone <email@example.com>, firstname.lastname@example.org
Reply-To: Benjamin Kaduk <email@example.com>
Date: Wed, 08 Jul 2020 21:20:01 -0700
Subject: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-rfc6830bis-32: (with COMMENT)
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 04:20:02 -0000
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.
- [lisp] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker