Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6830bis-27: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updating for the -27 by removing points that are fully addressed but leaving points that I still want to have further discussion on. It may be most expedient to continue discussion on my -26 ballot thread. Please also note that the COMMENT section was entirely refreshed for the -26 and had a few additions as I read the -27. 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. [ed. I have noted offlist to the authors some specific locations] 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. [ed. these previous two items are rather poorly described; another thread is ongoing to try to clarify both my concerns and how they might be addressed] 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. 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. [We're getting closer to something that's possible to properly analyze, but I haven't done that analysis yet] ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? Also in Section 3 (moved from Discuss, since probably editorial): 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. 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 [...] 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a I guess maybe clarifying that LSB 0 is the last bit in the field is worthwhile? Ah, we have an example down in Section 10. 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. When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) MUST be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. I'm not sure how to do this check when doing initial encapsulation; there's no outer header then. 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. (This shows up in several places.) 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 The Map-Cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated nit: comma splice. 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 8 There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. (Note that earlier we state that EIDs must be unique...) 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 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. Maybe note that this only conveys "up" information, which is necessary but not sufficient for reachability. 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"? 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. 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 15 o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC Isn't the outer destination address an RLOC? How do EIDs come into play? Section 20.2 Maybe throw us a bone and include the string "draft-iannone-openlisp-implementation" in the [OPENLISP] entry? _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
