The Locator/ID Separation Protocol (LISP)
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
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]
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?
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
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.