Summary: Has 4 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
** The applicability statement in Section 1.1. notes that this will be used on the “public Internet”. Therefore, I think we need to consider the use of “secure defaults”. Making lisp-sec and a strong MAC-KDF mandatory to implement is helpful. However, it’s use must also be normatively specified. Specifically, stronger guidance needs to be given when communicating over the public Internet. My thinking would be something like: -- lisp-sec SHOULD (MUST?) be used in for Map-Reply, Map-Notify, Map-Notify-Ack and ECM (i.e. SHOULD/MUST set S=1) -- Map-Register SHOULD (MUST?) use HMAC-SHA256-128+HKDF-SHA256 -- MUST NOT use Algorithm ID = 0 and 1
I support Ben Kaduk’s DISCUSS position on the MTI MAC-KDF and LISP-SEC clarity. Per the issues of the MTI MAC-KDF, I recommend Section 9 (“An implementation MUST support HMAC-SHA256-128+HKDF-SHA256 [RFC4868]”) I support Martin Duke’s DISCUSS position. ** Section 5.3. Per “After 10 retransmits without receiving the corresponding Map-Reply must wait 30 seconds.”, should this be a normative MUST? ** Section 5.6. Per “If a Map-Register is received with a nonce value that is not greater than the saved nonce, it drops the Map-Register message and logs the fact a replay attack could have occurred”, should normative language used here – “… it MUST drop the Map-Register message and SHOULD log the fact that a replay attack …”? ** Section 9. The assumption that “The ETRs have a pre-configured trust relationship with the Mapping System, which includes some form of shared secret … [and] establishment is out of scope of this document.” seems like a significant unaddressed hurdle at scale. ** Section 9. Per assumption 2 that a “… Mapping System is aware of which EIDs an ETR can advertise.”, what behavior should the mapping system take when it gets a Map-Register whose scope does not match this information? ** Editorial Nits -- Section 5.4. Typo. s/encapsualted/encapsulated/ -- Section 5.6. Typo. s/the the/the/ -- Section 5.6. Typo. s/section Section/Section/ -- Section 9. Typo. s/operartors/operators/ -- Section 9. Typo. s/eavesdroping/eavesdropping/
Two issues rise to DISCUSS level, IMO: Sec 5.7. Is the intent that the Map-Notifies are only retransmitted if they are unsolicited? If not, repeated Map-Registers could result in a storm of Map-Notifies. Sec 7.1. I very well may have missed something, but it doesn't look like the Map-Request is authenticated. So how can the ETR safely update its Map Cache based on the information in the Map-Reply?
Sec. 5. Please clarify that the 576B and 1280B limits include the entire IP packet. Sec 5.4. Does the "weight" refer to the percentage of packets or bytes? Sec 5.5. The first sentence should suggest that the Map Reply could return multiple EID prefixes.
(1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per my ballot on the -26, but left unchanged section 9, so we still have a SHOULD vs. MUST inconsistency w.r.t. implementing HMAC-SHA256-128+HKDF-SHA256. (I would of course prefer the same resolution of the inconsistency that Roman does, but have forgotten to what extent we have to defer to the deployed reality.) (2) It looks like the update in Section 5.7 is attempting to address my point about only terminating Map-Notify retransmission when the authentication data of the Map-Notify-Ack validates, but the added text is either misplaced or malformed. Perhaps CURRENT: The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify and for the sender to stop retransmitting a Map-Notify with the same nonce and the authentication data validates. [...] NEW: The Map-Notify-Ack message has the same contents as a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify and, once the the authentication data is validated, allows for the Map-Notify sender to stop retransmitting a Map-Notify with the same nonce. [...] (3) I think that Eric Rescorla's concern about a misbehaving ETR being able to prevent an ITR from learning that the ETR is no longer the appropriate ETR for a given prefix remains unaddressed. I wrote up a longer description at https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/ but in short, we only require the ITR to send its Map-Request through the mapping system (vs. directly to the ETR) when SMR is sent from an address not in the current mapping data for that prefix -- if the SMR is sent from an address in the current mapping data, we allow sending Map-Request directly to the ETR, outside the mapping system. I don't see a mechanism that guarantees that such a "revocation" event is noticed by the ITR. (4) The specification of the MAC+KDF algorithms doesn't seem detailed enough to be implementable. RFC 4868 is attempted to be used as a reference for both HMAC-SHA256-128 (er, and the one-character-off HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I think it can only work as a reference for the MAC algorithm. Presumably we need RFC 5869 or such for the KDF part (5) This is probably my fault, but we're missing a step with how we describe the Map-Notify/Map-Notify-Ack per-message authentication. Specifically, while we do say that the authentication data needs to be recomputed each time, we don't clearly state that this is because the correct per-message key is different, because we are using a different 's' input to the KDF function for the different messages. In line with the "Map-Register Authentication" used for Map-Register, this would presumably be "Map-Notify Authentication" and "Map-Notify-Ack Authentication", but neither of those strings appear in this document. We might be able to localize the change to Section 5.6, akin to OLD: 4: The derived per-message key is computed as: per-msg- key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in the Nonce field of the Map-Register and 's' is a string equal to "Map-Register Authentication". [...] NEW: 4: The derived per-message key is computed as: per-msg- key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in the Nonce field of the Map-Register and 's' is a string that corresponds to the message type being authenticated. For Map-Register messages, it is equal to "Map-Register Authentication". Similarly, for Map-Notify and Map-Notify-Ack messages, it is "Map-Notify Authentication" and "Map-Notify-Ack Authentication", respectively. However, I think the rhetoric would be more robust if we also modified Section 5.7 to mention the existence of the different 's' values (or, rather, the different per-message key) when we say that the authentication data is recomputed. Perhaps, s/is recomputed/is recomputed using the corresponding per-message key/ (twice).
Abstract database designs. Since these devices implement the "edge" of the LISP Control-Plane infrastructure, connecting EID addressable nodes of a LISP site, their implementation and operational complexity reduces the overall cost and effort of deploying LISP. I think there might be a "simplifying" or "reducing" missing here (w.r.t. "their implementation and operational complexity"). Section 1 Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) [RFC1035] servers; likewise, Map-Resolvers are conceptually similar I suggest adding "authoritative" to the DNS servers of the analogy. Section 3 Map-Resolver: A network infrastructure component that accepts LISP Encapsulated (ECM) Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system. This could perhaps be misread as implying that the Map-Resolver returns the appropriate EID-to-RLOC mapping to the requestor directly, whereas IIRC the reply is sent directly from the ETR/Map-Server. Section 4 A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to I feel like I said this already but forgot the answer; sorry for the duplication: the Map-Server is not getting the request directly from the ITR, but rather from the mapping system or a Map-Resolver. Do we want to say something like "originating from an ITR" to clarify? Section 5.2 A: This is an authoritative bit, which is set to 0 for UDP-based Map- Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system returning a Map-Reply. I'm not sure this paints a clear picture of when the bit is/isn't set. Are Map-Requests sent by an ITR that want the destination site to reply (rather than the mapping database) sent over some non-UDP-based scheme? Do ECM messages count as UDP-based? (I would make this a Discuss for lack of clarity but that would be double-jeopardy.) p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request. It might be worth saying something about what the recipient would do with the knowledge that the Map-Request was PITR-generated (rather than ITR-generated?). L: This is the local-xtr bit. It is used by an xTR in a LISP site to tell other xTRs in the same site that it is part of the RLOC-set for the LISP site. The L-bit is set to 1 when the RLOC is the sender's IP address. I'm not sure which RLOC is "the" RLOC -- the message format seems to allow multiple ITR-RLOC entries. D: This is the dont-map-reply bit. It is used in the SMR procedure described in Section 6.1. When an xTR sends an SMR Map-Request message, it doesn't need a Map-Reply returned. When this bit is Should this get s/SMR Map-Request message/SMR message/ as was done elsewhere in response to my comments on a previous version? EID-Prefix: This prefix address length is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the address length varies and for the LCAF AFI the format is defined in [RFC8060]. [...] Just to check: if I get a Map-Request that uses an AFI I don't recognize, I have to abort parsing the packet since I don't know how many bytes to skip? It seems like this might negatively affect the ability to introduce new AFIs. Map-Reply Record: When the M-bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so. We could perhaps mention something about whether the ETR believes the message is trustworthy, too, since it does not have the benefit of having gone through mapping system validation. Section 5.3 Map-Requests MUST be rate-limited to 1 per second per EID-prefix. After 10 retransmits without receiving the corresponding Map-Reply must wait 30 seconds. nit: incomplete sentence. a Map-Cache entry. If the ETR (when it is an xTR co-located as an ITR) has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the cached entry, then it MAY send the "verifying Map-Request" directly to the originating Map-Request source. If the RLOC is not in the Locator-Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in the "piggybacked" mapping data. side note: Does it make much practical difference to send the Map-Request to the EID as the destination address vs. just consulting the mapping system to look up that EID? It seems like the former is strictly more work, and I'm not sure what additional benefit is gained from that additional work. I guess, reachability information for the EID in question. Section 5.4 P: This is the probe-bit, which indicates that the Map-Reply is in response to a Locator reachability probe Map-Request. The 'Nonce' field MUST contain a copy of the nonce value from the original Map-Request. [...] The description of the nonce field says that it's always copied from the Map-Request; is this MUST adding any additional requirements? Record Count: This is the number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count. We say earlier that the record count in a Map-Request is (artificially) limited to 1 for this document; we might note here that the reply count can be larger than the request count, e.g., when there's a need to return more-specifics that are carved out from the best match to the requested EID. Locator Count: This is the number of Locator entries in the given Record. A Locator entry comprises what is labeled above as 'Loc'. The Locator count can be 0, indicating that there are no Locators for the EID-Prefix. Do we want to say "also known as a negative Map-Reply"? (0) No-Action: The Map-Cache is kept alive, and no packet encapsulation occurs. (1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded. It might be worth a few words about how these two differ, as the "no encapsulation" part is superficially similar. A: The Authoritative bit MAY only be set to 1 by an ETR. A Map- Server generating Map-Reply messages as a proxy MUST NOT set the A-bit to 1 by an ETR, and not a Map-Server generating Map-Reply messages as a proxy. This bit indicates to requesting ITRs that nit: looks like a botched edit, with the "and not a Map-Server generating Map-Reply messages as a proxy" sticking around when it should have been removed. the Map-Reply was not originated by a LISP node managed at the site that owns the EID-Prefix. Please confirm that the "not" is correct, here. 12.5% of the traffic. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a "equal" or "equal to zero"? Just "equal" seems like it needlessly overloads the semantics for uniform balancing. (Similarly for the multicast weight.) R: This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record. This receiver may find this useful to know if the Locator is up but not necessarily reachable from the receiver's point of view. See also EID-Reachability Section 7.1 for another way the R-bit may be used. I'm not finding mention of the R-bit in Section 7.1; am I missing something? The Record format, as defined here, is used both in the Map-Reply and Map-Register messages, this includes all the field definitions. (We also mentioend in the previous section that a single record in this format can be present in the Map-Request.) Section 5.5 either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are nit(?): "EID of a record of a Map-Request"? invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen, to allow Unicast Reverse Path Something seems amiss here. It might just be that the comma is misplaced (after chosen vs. before it), but that hinges on the nature of the choice in question. Section 5.6 E: This is the Map-Register EID-notify bit. This is used by a First- Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify based Map-Register is sent by the FHR to the same site xTR that propogates the Map-Register to the mapping system. The site xTR nit(???): I think maybe s/the same site/a same-site/, though that nominally changes the meaning. 4: The derived per-message key is computed as: per-msg- key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in There's some notational quirks to handle here, since a KDF() function is typically represented as taking two inputs, an input key material and a salt, and depending on context an output length as well. (Though resolving this may depend on how discuss point (4) is resolved.) We should probably also say that '+' is used to represent concatenation. Section 5.7 procedure defined in the previous section. For an unsolicited Map- Notify, the fields of a Map-Notify used for publish/subscribe are specified in [I-D.ietf-lisp-pubsub]. We probably want to tweak how we make this reference to avoid a perceived need to make pubsub a normative reference. Perhaps something like "the Map-Notify message can also used, outside the scope of this specification, in an unsolicited manner, such as is specified in [pubsub]". Also, there are other ways to get an unsolicited Map-Notify, right? This text doesn't really make that clear. A Map-Server sends an unsolicited Map-Notify message (one that is not used as an acknowledgment to a Map-Register message) in only nit: s/in only/only in/ (my fault, sorry) conformance the Congestion Control And Relability Guideline sections of [RFC8085]. A Map-Notify is retransmitted until a Map-Notify-Ack nit: s/conformance/conformance with/ Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the receiver verifies the authentication data. I suggest adding "If the authentication data fails to validate, the message is dropped without further processing". Section 5.8 LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the 'Reserved' field. [...] S: This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following Authentication Data format and follow the procedures from [I-D.ietf-lisp-sec]. So is it the IP version or the authentication data that follows the Reserved field? Section 6.1 mapping data. Please note that this procedure does not result in cryptographic or strongly authenticated verification. "in the absence of [LISP-SEC]". When an ITR receives an SMR-based Map-Request for which it does not One more s/SMR-based Map-Request/SMR message/, I think (I missed it in my review of the -26). Section 7 4. An ITR may receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR. I note that in the analogous text in 6830bis (Section 10), we have a furthe statement "Please note that in some scenarios the RLOC [from the outer header] can be an spoofable field." When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map- Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages. I think there is also some level of unreliability in the other direction -- even when following draft-ietf-opsec-icmp-filtering and validating the echoed contents, the contents could in some cases be sufficiently predictable that an attacker could spoof them. Having random nonces/ports be in use helps, of course, but the ICMP message could be generated in response to arbitrary traffic, not all of which will necessarily have all of those. The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate- nit: I think we haven't been using the bare forms of "Requests" and "Replies" (in favor of the "Map-" prefixed forms). Section 8.1 o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative (within the LISP deployment Section 1.1) for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific EID- prefix. In this case, the requested EID is said to match a "hole" Presumably the more-specific prefix still needs to match the requested EID? Section 9 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network operartors should carefully weight how the LISP-SEC threat model nit: s/operartors/operators The Map-Request/Map-Reply message exchange to inject forged mappings directly in the ITR EID-to-RLOC map-cache. This can lead to traffic nit: the grammar's a bit off, maybe s/to inject/can inject/? attacks. In this case, attackers can claim to own an EID-prefix that is larger than the prefix owned by the ETR. Such attacks can be I'd consider adding ", since the Map-Reply is sent directly from ETR to ITR without a chance for validation by the mapping system". addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC protocol defines a mechanism for providing origin authentication, integrity, protection, and prevention of 'man-in-the-middle' and nit: s/integrity,/integrity/ (spurious comma) replay attacks by a man-in-the-middle. However, a compromised ETR can overclaim the prefix it owns and successfully register it on its corresponding Map-Server. To mitigate this and as noted in The "can overclaim" is a little weird since we go on to describe the mandatory mitigation against this attack. Maybe something with "could" or a more drastic rewording to "there is a potential attack where a compromised ETR could"? Section 11 [I did not attempt to double-check that the listed changes match the actual differences between RFC 6833 and this document, but do note that it looks like the authors did so at some point since my initial review.] o This document is incorporating the codepoint for the Map-Referral message from the LISP-DDT specification [RFC8111] to indicate that a Map-Server must send the final Map-Referral message when it participates in the LISP-DDT mapping system procedures. It's pretty hard to claim that RFC 8111 is only an informative reference in light of statements like this that a Map-Server needs to do something from it when a flag bit defined by this document is set. Section 12.3 New ACT values can be allocated through IETF review or IESG approval. Four values have already been allocated by [RFC6830], IANA is requested to replace the [RFC6830] reference for this registry with the RFC number assigned to this document and the [RFC6830]. Action nit: comma splice. values references with the RFC number assigned to this document. nit: incomplete sentence (lingering remnants of a previous edit that should just get removed?) Section 12.4 The IANA registry "LISP Canonical Address Format (LCAF) Types" is used for LCAF types. The registry for LCAF types use the Specification Required policy [RFC8126]. Initial values for the "Specification Required" includes review by designated experts. Do we want to give any guidance to the experts for reviewing new submissions? (Similarly for other registries; I note that the LISP Bit Flags section doesn't use the "Specification Required" keyword.) Section 13.1 We don't currently cite RFC 6347 in a way that requires a normative reference. Though I for one wouldn't mind if we made DTLS mandatory somewhere :) Section 13.2 We nominally have a "MUST" for behavior from RFC 1071, that would make it a normative reference, but this is pretty foundational so it seems a bit like overkill.
[ __all__ ] * Is there somewhere a broad prohibition for all IPv6 EID addresses and IPv6 EID prefixes that they MUST NOT be IPv6 link-local addresses? Related: are there any use cases for an IPv6 link-local RLOC? Perhaps in some IXP scenarios? [ section 5.5 ] * Are these example prefixes correct? 2001:db8::/16 is really just 2001::/16, right? Similarly, I think /24 should be /48 and /32 should be /64, yes? I feel like I must be misunderstanding something important...
[ section 5.2 ] * Can the ITR-RLOC Address be the same as the source of the packet containing the Map Request? [ section 5.4 ] * I think the EID-Prefix field in the packet layout diagram needs a ... or ~'s to indicate variable length? (Same in 5.6, 5.7 and also for Locator field)? * Can this S bit be cleared by an on-path attacker without consequence? * ACT values of 4 and 5: should an ICMP admin prohibited be sent back to the EID source? * Weight: "...the 2nd and 3rd Locators will *each* get 25% of the traffic..." * WRT the recommended once per 3 seconds: is that per-query source or across all querying clients?
1) Versioning and backward compatibility Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol." However, there is no versioning mechanism for this protocol specified. How is versioning supposed to work? Further given there is no new version, I wonder if the changes as outlined in section 10 are all backward-compatible? Especially for the introduction of the Message-Notify-Ack message, I guess there is no problem if a server sends it, however, as the sender of the Message-Notify message might not know if the other end supports sending of the Message-Notify-Ack it can't rely on it. This should be further discussed in the doc! Or is there another strategy to achieve backward compatibility? 2) Size and MTU As outlined in the TSV-ART review (Thanks Colin!) this document does not discuss fragmentation or Path MTU discovery. RFC8085 recommends to either perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280 bytes for IPv6 (minus any static header). As this seems to be an appropriate size for LISP messages, I would recommend this approach. Relying on IP fragmentation (as indicated in the reply to the TSV-ART review) is not recommended by RFC8085 as this would lead to IP packet without a UDP header, in the case of LISP, which can cause problem and loss when NATs are involved. In any case the chosen approach needs to be further discussed in the doc. 3) Rate-limiting and congestion control Sec 5.3: "Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Request for the same EID-Prefix be sent no more than once per second." As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually recommends to not send more the one packet per 3 seconds, and that is a restriction for all traffic not on a per-receiver base, or implement congestion control. This limit is meant to not only protect the receiver but also the network from overloading. Why do you use a smaller interval here? Also if (appropriate) rate limiting is used, this should either be a MUST or more explanation when it is okay to use a smaller rate limit should be provided. However, after all, I don't think you those the right approach here for rate limiting. A Map-Request is always expected to be followed by some reply. For these kind of communication pattern, RFC8085 recommends to limit the number of outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per RTT), also for all traffic and not only per receiver. However, this would also require to implement some simple mechanism to detect a message as lost (see also further below in point 4). Similarly I'm not sure about the intent of this requirement in section 5.5: "Map-Replies SHOULD be sent for an EID-Prefix no more often than once per second to the same requesting router. " My understanding is that Replies are only sent when a request is received. Why is this additional rate limit needed? Again if used it should be 3 seconds for all traffic to be inline with RFC8085. Also again, why is that not a MUST? Further recommendation are needed here. Further section 6.1 say "Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination." This seems to be the same rate limit as mention above, or not...? It would probably make sense to rate limit the SMR even further. Please clarify and provide more guidance, e.g. what should the value of a potential additional rate limit for SMR be? Respectively the following sentence in section 6.1 is also unclear: "The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply" Why is the rate-limit as currently proposed depend on the fact if a Map-Reply is received? Is the ITR supposed to retransmit the Map-Request...? And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not seem to have any rate-limits. Recommendations inline with RFC8085 should be provided for the total traffic and not only for a few message types. Again, Map-Notify and Map-Notify-Ack messages should be send only once per RTT as there is a feedback mechanism. For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from an ETR to a Map- Server with a suggested interval between messages of one minute." However, this a rather a low bound than an upper bound. A required (MUST) rate limit is still needed. 4) Loss detection and retransmission As also mention by the TSV-ART review (Once more thanks to Colin!), this spec has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it does not specify what to do if the ACK is not received (loss detection and retransmission scheduling). This makes the spec incomplete and needs to be further specified in the doc (and also has a relation to the point 3 above of course).
Further comments: 1) The example given in 5.5 should probably used IPv6 addresses and use the IP address space that is reserved for documentation purposes. 2) I find the security requirements in this doc very unsatisfying. Most important the doc requires the support of authentication mechanism but not the use of it. I would like to see more clear MUST requirements here. Further, today and at this stage of the protocol (moving from exp to PS) I find it not acceptable anymore to have certain security feature as optional and outsourced into a different work-in-process draft. However, I leave further discussion to the SEC ADs. 3) Given the following statement: "Note that while this document assumes a LISP-ALT database mapping infrastructure to illustrate certain aspects of Map-Server and Map- Resolver operation..." it seems that RFC6836 should be a normative reference, as it might not be possible to understand all details explained in this doc with knowing ALT. 4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub should be normative references as the meaning of the respective bits it not further specified in this doc. Or can these bits just be ignored if I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that should be stated. Clarification questions: 1) Sec 5.3.: "For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure." Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on the IP version used by the initial message from the EID. Is that always the case or just for this initial message? I would assume that for all other cases this is actually independent...? Because otherwise there would be a constraint on what needs to be requested. I would like t see further clarification about this in the doc. 2) In section 5.3: "The ITR MAY include all locally configured Locators in this list or just provide one locator address from each address family it supports." Would it make sense to include a SHOULD requirement to at least the address family that is used to send the Request is included (to increase chance to enable a communication/get a reply)...? 3) Sec 5.4: "If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. " Shouldn't the receiver in this case split the traffic equally? Otherwise how would you signal that the traffic should be split equally? Maybe use all zero instead to let the receiver decide...? 4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it may not send an SMR-invoked Map-Request." I guess this should be normative and probably also a MUST NOT or at least SHOULD NOT. 5) Section 7 seems to imply that if it is detected that no route is available, the ITR should basically do nothing and just drop any incoming packets for that ETR. Would it make sense for incremental deployability, to just forward the packet to the IP address of the EID instead...? This way the source host would not benefit in mobility cases but still gets connectivity otherwise. Or is that anyway not the implication? If that is the case, that should be further clarified in the doc. 6) Section 8.2 says: "Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port specified in the original Map-Register message." Actually why is that? Some minor editorial comments: 1) First sentence in intro: the pointer to ietf-lisp-introduction as currently introduced, makes this reference look very normative: "The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] specifies..." I would recommend the following wording: "The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also [I-D.ietf-lisp-introduction]) specifies..." 2) Also in intro: Given that 6830bis is a normative reference "LISP RFC 6830bis" should be replaced with the new RFC number in the text. This should be noted to the RFC editor; probably this is more obvious if RFCXXX is used instead. 3) Sec 5.4: "...for another way the R-bit MAY be used." This looks like a lower case may would be more appropriate.
This DISCUSS is somewhat arbitratrily on 6833bis, but many of the same issues apply to 6830bis. I concur with Ben's DISCUSS. I do not believe that these documents have adequate security to advance to Proposed Standard. I thought it might be helpful for me to lay out my starting assumptions and threat model and what I think the appropriate standard is here. That gives us an opportunity to discuss them prior to getting into the specific security issues I raise below. SYSTEM ARCHITECTURE Per offline discussion, I understand that despite some of the introductory material, LISP is not currently intended to be Internet scale but rather to run in what seem to be fairly tightly controlled environments. Thus, I am assuming the following facts about the system: - The Mapping Service itself is secure and trusted. For the purposed of this discussion, I'm modelling all the entities in the services as one trusted element. - The ETRs have a preconfigured relationship with the Mapping Service, which includes some sort of shared key and an ACL on the Mapping Service which tells it which EIDs anm ETR can advertise. How this gets established is out of scope of this discussion. Note that neither of these assumptions would be reasonable in an Internet scale system, but I'm assuming that the text about that in these documents will be removed. Because it's not in the document set before us, nor is it a normative reference, I am disregarding LISP-SEC and only analyzing the system as specified in these documents. THREAT MODEL I'm assuming the usual RFC 3552 threat model, I.e., - All non-Map Server elements in the system (specifically, endpoints and the xTRs are potentially malicious). - Aside from the links between the Map Server elements, the network is controlled by the attacker. Against this background, my expectation is that the attacker should not be able to affect traffic in any fashion significantly more effective than tampering with the data plane. For instance, it's clearly the case that an on-path attacker between two xTRs can drop all the packets or forward them to some third xTR, but it should not be able to send a small number of packets which would then affect the routing of a large number of packets. I do not expect that the data plane should have better security than native (non-IPsec) traffic. Given the nature of LISP and the existence of a mapping system, it seems like it's kind of a missed opportunity to deploy a credentials system that would support IPsec-style data plane security, but given that this isn't a generally safe assumption for IP traffic, and therefore you need to provide some sort of transport or application security anyway, I don't think it's the right standard to hold LISP to. ATTACKS LISP appears to be vulnerable to a number of routing attacks that I claim above it should not be subject to. For example: 1. An on-path attacker can forge Map Replys to the ITR, thus redirecting traffic. 2. An ETR can perform an "overclaiming" attack in which it claims to be responsible for EIDs which it is not actually responsible for. 3. An off-path attacker can temporarily reroute traffic by exploiting the "gleaning" feature to cache poison an ITR. In addition, the "echo noncing" feature does not appear to have a sufficiently strong nonce to protect against forgery, and thus turning this into a long-term attack 4. An attacker may be able to perform a number of cache invalidation and contamination attacks by exploiting the Map-Version and Locator-Status bits. This may lead to DoS. 5. An attacker who was at time T responsible for an EID block can probably prolong its ability to respond for that block even after it is no longer responsible. 6. A number of the components appear to be subject to various replay attacks. I note that many of these attacks are documented in the Security Considerations for these documents. Also, I doubt this list is exhaustive. As noted above, I have spent no time on the data plane protocol. DEFENSES When looking at attacks, it's important to determine whether there are plausible defenses. For most of these, I believe that the answer is "yes", at varying levels of cost. As noted above, LISP-SEC appears to be intended to address a number of these issues, so it's possible that requiring LISP-SEC would go a fair ways towards addressing these issues. A cursory look at LISP-SEC turns up some somewhat concerning design choices, so I would have to examine it more closely to give a real opinion. I do not believe that LISP-SEC will address the attacks that do not involve the Mapping Server. For instance, the gleaning contamination/nonce attacks (3) would not appear to be fixed by LISP-SEC. However, it's probably possible to fix them by lengthening the nonce. With that said, I tend to think that the overall authentication architecture here would benefit from a rethink. At a high level, the source of most of these problems is the "non-transferability" of the mapping information from the Map Server. If the Map Server instead had an asymmetric key pair which it used to sign mappings, then almost all of these attacks would not work. Specifically: - The map server could send signed Map Replys so forgery wouldn't work - Map Replys from ETRs would be signed, so you couldn't overclaim - Gleaning attacks would sort of work, but because the probe would elicit a Map Reply, you couldn't persist them - Map Versions could be tied to signed objects, so you couldn't do cache invalidation by version. You'd probably need some other approach for Locator Status bits. And so on. Detailed review below, with some duplication.... Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4115 IMPORTANT S 5.2. > s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is > sending a Map-Request in response to a received SMR-based Map- > Request. > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs that > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. This would appear to create a normative reference to this document. To avoid that, you need to specify how I behave if I receive it but I don't implement lisp-mn. S 5.2. > m: This is the LISP mobile-node m-bit. This bit is set by xTRs that > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > I: This is the xTR-ID bit. When this bit is set, what is appended to > the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage > procedures in [I-D.ietf-lisp-pubsub] for details. here too you seem to be creating a normative reference. S 5.5. > is being mapped from a multicast destination EID. > > 5.5. EID-to-RLOC UDP Map-Reply Message > > A Map-Reply returns an EID-Prefix with a prefix length that is less > than or equal to the EID being requested. The EID being requested is How do I behave if I receive an EID-Prefix that is less than any of my mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 and someone asks me for 10.0.0.0/8? Also, when you talk about prefix length, I assume you mean the length fo the mask? S 5.6. > Authentication Data: This is the message digest used from the output > of the MAC algorithm. The entire Map-Register payload is > authenticated with this field preset to 0. After the MAC is > computed, it is placed in this field. Implementations of this > specification MUST include support for HMAC-SHA-1-96 [RFC2404], > and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. What prevents replay attacks here? I'm guessing it's the Map-Version- Number, but as I understand it, I can set this to 0. S 6.1. > receives an SMR-based Map-Request and the source is not in the > Locator-Set for the stored Map-Cache entry, then the responding Map- > Request MUST be sent with an EID destination to the mapping database > system. Since the mapping database system is a more secure way to > reach an authoritative ETR, it will deliver the Map-Request to the > authoritative source of the mapping data. If I'm understanding this correctly, this allows an ETR to prevent an ITR from learning that it is no longer the appropriate ETR for a prefix. The way this attack works is that before the topology shift, I send SMRs, thus causing Map-Requests, which, because my entry is cached, refresh the cache on the ITR past the topology shift. I can keep doing this indefinitely. Am I missing something S 8.2. > authentication data, so prior to sending a Map-Register message, the > ETR and Map-Server SHOULD be configured with a shared secret or other > relevant authentication information. A Map-Server's configuration > SHOULD also include a list of the EID-Prefixes for which each ETR is > authoritative. Upon receipt of a Map-Register from an ETR, a Map- > Server accepts only EID-Prefixes that are configured for that ETR. How does it know?
S 5. > \ | UDP Length | UDP Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | LISP Message | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What do these two diagrams correspond to? v4 and v6? This needs explanation. S 5.2. > Type: 1 (Map-Request) > > A: This is an authoritative bit, which is set to 0 for UDP-based Map- > Requests sent by an ITR. It is set to 1 when an ITR wants the > destination site to return the Map-Reply rather than the mapping > database system. I don't understand this sentence, as literally it would say that you should not return "the mapping database system" but that doesn't make any sense. S 5.2. > P: This is the probe-bit, which indicates that a Map-Request SHOULD > be treated as a Locator reachability probe. The receiver SHOULD > respond with a Map-Reply with the probe-bit set, indicating that > the Map-Reply is a Locator reachability probe reply, with the > nonce copied from the Map-Request. See RLOC-Probing Section 7.1 > for more details. How am I supposed to handle this if I am a Map Server. S 5.2. > receipt. > > L: This is the local-xtr bit. It is used by an xTR in a LISP site to > tell other xTRs in the same site that it is part of the RLOC-set > for the LISP site. The L-bit is set to 1 when the RLOC is the > sender's IP address. Is the xTR supposed to filter this on exiting the site. S 5.2. > > Nonce: This is an 8-octet random value created by the sender of the > Map-Request. This nonce will be returned in the Map-Reply. The > security of the LISP mapping protocol critically depends on the > strength of the nonce in the Map-Request message. The nonce > SHOULD be generated by a properly seeded pseudo-random (or strong This seems like it needs to be a MUST. S 5.3. > originating Map-Request source. If the RLOC is not in the Locator- > Set, then the ETR MUST send the "verifying Map-Request" to the > "piggybacked" EID. Doing this forces the "verifying Map-Request" to > go through the mapping database system to reach the authoritative > source of information about that EID, guarding against RLOC-spoofing > in the "piggybacked" mapping data. This text here doesn't seem compatible with either of the two cases listed in "EID-prefix" above. S 5.4. > > Nonce: This is a 24-bit value set in a Data-Probe > [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request > is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit > value is supplied, it resides in the low-order 64 bits of the > 'Nonce' field. Nit: a 64-bit quantity doesn't really have low-order bits if it's not numeric. Do you mean "rightmost"? Also, what are the other bits. S 5.4. > 'Nonce' field. > > Record TTL: This is the time in minutes the recipient of the Map- > Reply will store the mapping. If the TTL is 0, the entry MUST be > removed from the cache immediately. If the value is 0xffffffff, > the recipient can decide locally how long to store the mapping. Am I supposed to merge this with previous mappings? REmove them? S 8.3. > of the mapping database protocols. > > 8.3. Map-Server Processing > > Once a Map-Server has EID-Prefixes registered by its client ETRs, it > can accept and process Map-Requests for them. This section is confusing because the introduction says that this function is only performed by Map-Resolvers: ' "The LISP Mapping Service defines two new types of LISP-speaking devices: the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database; and the Map-Server, which learns authoritative EID- to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database."
This has been resolved.
NO OBJECTION for the same reasoning as for 6830bis.
I support the Security ADs DISCUSS positions. I agree with Alexey that [I-D.ietf-lisp-sec] should be a normative reference. It seems to me that the full security considerations depend upon it. (I was unfortunately not able to do more than a cursory review due to external time constraints.)
I support Roman's DISCUSS.
This is the final document in a long queue, so I did only a cursory review. Having gone over my colleague's DISCUSS positions and other comments, and the change history since its first pass through the IESG, I doubt I'd be able to add much, so I'm balloting No Objection.
I support the DISCUSSES - I was going to say "especially X's", but I support them all...
Thank you for addressing my DISCUSS.
(1) s/rfc8113/draft-ietf-lisp-rfc8113bis (2) §5.1: "Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]." This sentence is out of place because it doesn't specify which procedure...and the action is already specified in rfc8113bis anyway. (3) s/Not assigned/Unassigned To match what the registry says.
Thank you for the work put into this document. Due to time contraints, I had no time to do a deep review of this document. But, I support Erik Kline's DISCUSS points and also extend it to 2001:db8:1:2::/32 that is a /64 (cfr section 5.5) I hope that this helps to improve the document, Regards, -éric