Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-rfc6833bis-16: 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-rfc6833bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- See my ballot position on rfc6830bis for some more general notes. I did most of my review on the -15, though I attempted to note when the -16 has changed the text. I am concerned about the handling procedures for Map-Requests that are encapsulated with the 'S' bit present. In particular, the ITR is required to discard non-secure responses, which is necessary in order to avoid a downgrade attack (in the current architecture). However, it seems that ETRs are not required to enable security in their registrations, and Map-Servers are supposed to strip the security flag when forwarding Map-Requests to ETRs that do not register as supporting LISP-SEC, and the resulting Map-Reply messages would thus not be secured, and dropped by the initiating ITR. So support for LISP-SEC would need to be mandatory for all ETRs in order for any ITR to be able to enforce the downgrade-protection behavior, which is a pretty bad deployment story. Making LISP-SEC mandatory everywhere would, of course, avoid this issue. I do not understand the procedure for allocation of EIDs. In a global mapping database, there needs to be some authoritative procedure for determining what ETRs and/or Map-Servers are authoritative for a given subset of EID space. All I've seen so far to do this effectively boils down to manual configuration, whether explicitly on a Map-Server or just as a mapping of what keys are authorized to advertise which EIDs. A 64-bit (or in some cases 24-bit) nonce is used, apparently as a request/response correlator, but the actual (cryptographic?) properties required from the nonce in the protocol are not clearly covered. In some cryptographic contexts a 64-bit nonce may be too short; I do not believe that this is the case here, but without a clear picture of what the requirements are it's hard to say for sure. 24 bits, on the other hand, is quite small. The layout of the document is somewhat confusing, in a way that could arguably lead to noninteroperable implemnetations. For example, the section on the Map-Register message format includes descriptions of the fields in the records and locators therein, and the section on Map-Notify reuses that portion of the structure, incorporating the field descriptions by reference. But the Map-Register section does not indicate that its descriptions are to apply in both cases, leading to confusing text that talks about values being set or cases that are not possible for a Map-Register (i.e., the section nominally being described). It would be most clear to have a dedicated subsection for the portion of the structure(s) that is being reused, which would allow for the per-field descriptions to clearly indicate in which scope they are defined. But the more minimal change of just indicating that the primary definition will be "dual use" would probably suffice as well. The Map-Reply record/locator descriptions are reused similarly; I made a comment on section 5.4 that lists a specific instance, though I believe the phenomenon is more general. Similarly, there are many instances (some noted in my Comment) where a bidirectional interaction between two xTRs is described, yet the peers are identified as "ITR" and "ETR". This is very confusing when the entity named as "ITR" is described as performing ETR functionality, or vice versa; pedagogically, it would be much better to use non-role-based names for the entities while describing these exchanges. While I see that there is an entire document dedicated to Map-Versioning and thus we do not need to fully cover everything here, I think it is critically important to be clear that there are consistency requirements attached to map versions, as relating to the stability of membership of RLOCs in a given record, etc. (I cannot be very clear hear since I am not entirely confident of the details of the consistency requirements yet.) The Map-Register message format field descriptions includes: Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages if no Map-Notify message is expected to acknowledge it. Since the Map-Register message is authenticated, the 'Nonce' field is not currently used for any security function but may be in the future as part of an anti-replay solution. Having the map registrations subject to replay seems like a critical flaw that would allow an attacker to disrupt any sort of mobility situation, even in the presence of LISP-SEC. I cannot see how this protocol could be suitable for Proposed Standard status with such a susceptibility to replay. I think we need more details on the expected Map-Register/Map-Notify and Map-Notify/Map-Notify-Ack message flows. In what cases is the ack not needed, and why? I think we need greater clarity on the 'E' and 'M' bits in the ECM format; more in the Comment section. I am concerned that the extensibility mechanism for ECM encapsulation is insufficiently well specified. Is a registry needed? Will new message types need to Update: this document to indicate the extension? What attributes make a message (un)suitable for encapsulation? Section 8.1 says: o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific ID-prefix. This document provides no mechanism to establish that a Map-Server is authoritative for a given EID-Prefix, so this entire case is non-actionable. Section 8.2 says: An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes 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. This cannot be a SHOULD if things are to work properly; it has to be MUST. Section 8.2 also says: As developers and operators gain experience with the mapping system, additional, stronger security measures may be added to the registration process. This kind of language for forward-looking guidance indicates that the current security properties are not well-understood by the authors and is inconsistent with Proposed Standard status. Perhaps I am misunderstanding the desired behavior but when Section 8.4 says: To do this, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system. [...] doesn't this carry substantial risk of running afoul of BCP 38 filtering? I think the MUST and SHOULD requirements for implementing cryptographic primitives are generally swapped; the more-secure ones (e.g., HMAC-SHA-256-128) should be MUST, and the legacy algorithms needed for compatibility with existing deployments would be SHOULD. Section 9 currently states: [a]s noted in Section 8.2, a Map-Server SHOULD verify that all EID- Prefixes registered by an ETR match the configuration stored on the Map-Server. I think we need a MUST-level requirement for verifying authorization for a given EID-Prefix, with one way of satisfying the requirement being checking configuration, but allowing for other means as well. In the -15, Section 9 also stated: The currently defined authentication mechanism for Map-Register messages does not provide protection against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area. I don't understand how this sort of statement can be present in a document targetting Proposed Standard status, in effect admitting that there are grave deficiencies in the security posture of the protocol. The -16 has gained some language indicating that LISP-SEC mitigates many attacks in this space, but that is hardly of much use when LISP-SEC is not a mandatory protocol feature. I'm disappointed that there is no Privacy Considerations section, though given that RFC 7835 seems to attempt to disclaim privacy considerations entirely, perhaps I should not be surprised. Tying devices to persistent Endpoint IDentifiers and using them in mobility situations inherently raises privacy concerns. These are not necessarily fatal to a protocol, but they do need to be discussed and the benefits weighed against the costs. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I apologize for the somewhat scattered nature of these comments; there are a lot of them and I was focusing my time more on trying to understand the broader system, and the intended security posture, so they did not get as much clean-up as I would have liked. Map-Reply will typically forward a packet that got a negative reply onto the public internet, adding extra latency to all flows through a LISP-enabled ITR; is that correct? Section 1 Note this document doesn't assume any particular database mapping infrastructure to illustrate certain aspects of Map-Server and Map- Resolver operation, the Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves. nit: This looks like a comma splice, though I'm not sure I'm parsing everything correctly. Section 2 Use the actual boilerplate from RFC 8174; don't just tack on a new reference to the existing (and without errata fix!) RFC 2119 boilerplate. Section 3 Should the Map-Register message's definition also mention that the Map-Server returns the registered RLOCs in normal Map-Replys? 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 find an ETR that can answer with the set of RLOCs for an EID-Prefix. My understanding from the intro document, etc., was that the ITR generally was not sending Map-Requests directly to Map-Servers, and that rather there was some triangle routing, with the Map-Request going from ITR to Map-Resolver to Map-Server, and the Map-Reply directly from Map-Server to ITR (so "typically one initiated by an ITR" or similar). It's also odd language (to me) to have the Map-Server "consult the mapping database" when the Map-Server comprises part of the mapping database and has local authoritative data. Section 5 Are we really just duplicating the IPv4+UDP and IPv6+UDP packet headers here? Section 5.1 Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]. Documents that request for a new LISP packet type may indicate a preferred value. 8126 has lots of procedures; generally we use a name to indicate which one is to be followed. Section 5.2 Using the same letter with different case for different flag bits sounds confusing. Lots of potential fun tampering with these flag bits, whether downgrade attacks on features or otherwise mucking around. Source EID address in Map-Request has privacy considerations. If the multiple ITR-RLOC Addresses is soleyl "to give the ETR the option of selecting the destination address from any address family" then there should be a restriction to one ITR address per AFI. (But it's not, so this text should be tweaked to avoid suggesting that it is.) When an EID mask-len smaller than the full length of the given address type is used, what are the values of the bits in the EID-Prefix field that are "masked away"? Leaving unspecified bits like this makes for an easy covert channel, especially so when the protocol messages are not covered by any integrity protection scheme and subject to on-path tampering. Section 5.3 A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. 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. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. I seem to be confused by the "destination IP address" bits here. Are we really sending Map-Request UDPgrams from an ITR to the EID destination address that we failed to look up, hoping that some magic in the network will cause it to end up at an ETR or Map-Server that can reply? Or is this talking about how we set the EID-Prefix portion of the Map-Request? The latter two cases do seem to be using RLOCs in a way that I expect, which makes me think I'm confused. Where is the term "Map-Replier" defined? [...] If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- Request. It's unclear how the Map-Replier would detect this, as opposed to just blindly trying to interpret the start of the request records as an ITR-RLOC. An ITR that is configured with mapping database information (i.e., it is also an ETR) MAY optionally include those mappings in a Map- Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the Map-Cache, it MAY originate a "verifying Map-Request", addressed to the map-requesting ITR and the ETR MAY add a Map-Cache entry. [...] This seems like a place where naming the xTRs not by role would help clarify the flows and the role in which each entity is acting, at each point. [...] If the ETR has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the 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. It's probably worth disambiguating that "the RLOC" is the cached RLOC for the EID in the "piggybacked" Map-Reply record. (Of course, there could be more than one cached RLOC for a given EID, so "the" is not really right anyway.) Similarly, "the Locator-Set" could become "the Locator-Set in the piggybacked Map-Reply record". Additionally, and this may just be my confusion, but is "send ... to the piggybacked EID" the right terminology? In my mental model at least, "perform a fresh mapping lookup for the EID in order to send a verifying Map-Request" would be better. Section 5.4 'S' bit, so clearing that bit and dropping the AD trailer allows an attacker to modify the contents. We would perhaps only saved by the bit in 6830bis where if you ask for a secure resolution you have to get one back, but that's not deployable. 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. Just a 6830bis reference isn't quite enough to describe this case, I think; don't you need to say that the other 40 bits are used by the mapping implementation? In the ACT field, is the "No-Action" value ever used for Negative Map-Replies? If so, I'm confused what the semantics are supposed to be. Differentiating between Drop/policy and Drop/authentication may open up a side channel for an attacker to learn about authentication or policy information. (But maybe not; this needs more analysis) A: The Authoritative bit, when sent, is always set to 1 by an ETR. What does "when sent" mean? The field is part of the structure; it's always sent. Or is this supposed to be "has value 1 if and only if the Map-Reply is sent by an ETR"? The EID-Prefix entry should probably reuse (or refer to) the text from the Map-Request field, covering length for other AFIs. Also, say what goes on for the bits that are "masked out". I feel like perhaps less could be said about the 'M' priority and weight fields, as what's currently there just leaves me confused about ETR vs. ITR vs. xTR and how this information flow is consumed. p: When this bit is set, an ETR informs the RLOC-Probing ITR that the locator address for which this bit is set is the one being RLOC- probed and may be different from the source address of the Map- Reply. An ITR that RLOC-probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more Exactly one or at most one? than one p-bit erroneously, the receiver of the Map-Reply MUST select the first Locator. The p-bit MUST NOT be set for Locator- First overall or first that sets the p bit? Set records sent in Map-Request and Map-Register messages. Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID. This is the section on the contents of the Map-Reply message. Why are we talking about source RLOCs? Oh, we're going to refer back to this from other sections for just the "EID-record" portion (a term which is not properly defined). It would be good to mention that up front at the start of this section or the list of fields in the EID-record. Section 5.5 A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID- Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note filling out the /24 with more-specifics that exist in the mapping system. nit: This last sentence is a sentence fragment. Requiring numerical sort of the locators seems to make the "inserted in the middle" case very difficult to reason about, especially relating to synchronization with the data plane and LSBs in data-plane messages. [...] The source address of the Map-Reply is one of the local IP addresses chosen to allow Unicast Reverse Path Forwarding (uRPF) checks to succeed in the upstream service provider. nit: should there be a comma before "chosen"? Section 5.6 Huh, why did I think that Map-Register was always sent encapsulated? The key-ID description is a great example of how to best describe the security properties of a field; thanks! Authentication Data: This is the message digest used from the output "digest" is a term of art and is not appropriate here. Probably best to just say "This is the output of the MAC algorithm." 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. It's probably good to explictly clarify that "entire payload" means "from and including the LISP message type field through the end of the last record and its locators". Also, the MUST/RECOMMENDED status seems backwards. I guess referring back to Section 5.4 for the duplicated fields is probably okay, but I would suggest calling out the portions that are only applicable or uniquely handled for the Map-Register message. Section 5.7 [...] An implementation SHOULD retransmit up to 3 times at 3 second retransmission intervals, after which time the retransmission interval is exponentially backed-off for another 3 retransmission attempts. This is underdefined without specifying the exponent base for the exponential backoff. Why is it allowed to Map-Register without requesting a Map-Notify? Section 5.8 An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system. Please be explicit about whether all such messages are encapsulated or only some of them. 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]. Could there be some indication of "optional security fields" in the figure? It's a bit odd to have the 'D' bit in the encapsulation as opposed to directly in the Map-Request, though I guess it's a bit late to be changing that. E: This is the to-ETR bit. When set to 1, the Map-Server's intention is to forward the ECM to an authoritative ETR. I think this needs to say more about which message flows this bit is defined for. Presumably the ITR will never use it for sending an encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of places where ECM wrapping is used. M: This is the to-MS bit. When set to 1, a Map-Request is being sent to a co-located Map-Resolver and Map-Server where the message can be processed directly by the Map-Server versus the Map-Resolver using the LISP-DDT procedures in [RFC8111]. How does the sender know that its configured Map-Resolver is also a Map-Server? It's unclear to me why this needs a bit in the message as opposed to just happening based on the attributes of the receiving Map-Server. LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages are allowed to be Control-Plane (ECM) encapsulated. In the future, PIM Join/Prune messages [RFC6831] might be allowed. Encapsulating other types of LISP control messages is for further study. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages. This type of forward-looking language seems unusuabl for a PS document; I would expect to not see predictions on what might happen, but rather the specification of what procedure is used to allow new message types. Section 6.1 Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. [...] Nothing *prevents* ETRs from doing this tracking; they're just not required to do so. So it would be better to say something like "Since ETRs are not required to keep track of [...]". [...] In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data. This can only occur when both ITR and ETR functionality reside in the same router. Having just come from the section on the "encapsulated control message", perhaps the reader could use an extra hint that the "encapsulated data" is just "LISP-tunneled data-plane traffic". Also, is this intended to be a normative requirement (with the use of "will")? 1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches. Map-Cache is an ITR function; this is probably another case where naming the routers would allow for a more clear description of the protocol exchanges. Also, this seems in disagreement with the previous text about sending data in the previous minute, since Map-Cache entries can persist for longer than a minute. 5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages. Perhaps a nit, but the "site with the changed mapping" doesn't make sense -- the map applies to the EID, and in principle the EID could have moved to a different site. So this could be "the site sending SMR messages" perhaps. Also, I think there needs to be greater clarity about which Locator-Status bits are being described. Finally, the cessation of sending SMR messages is presumably scoped to those targetted to the sender of the Map-Request in question and not a global property? For security reasons, an ITR MUST NOT process unsolicited Map- Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR 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. The only verification possible in this set of documents does not constitute a security mechanism worthy of the name. Also, allowing off-path attackers to induce requests to the mapping system seems like a DoS vector only partially mitgiated by rate limiting. Section 7 One could perhaps quibble as to whether (1) through (3) constitute "control-plane", vs. "out-of-band" given that this documents the LISP Control-Plane as specific UDP messages. Section 7.1 When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in [I-D.ietf-lisp-rfc6830bis]. Please provide a detailed section reference; 6830bis does not specifically cover source address selection for probes. [...] The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. nit: "greatest benefit ... handle many failure scenarios" is a strange wording to me. Presumably the failures are not failures of the probing, but rather network failures of some form? Section 8.1 o An immediate Negative Map-Reply (with action code of "Natively- Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. [...] This seems to be attempting to instill a normative requirement of setting the 15-minute TTL for this case; please use normative language to that effect. [...] If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. [...] (Same comment as above about normative language) 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. I think there also needs to be some text about the ETR and associated Map-Server being part of a single administrative domain. Failure to implement such a check would leave the mapping system vulnerable to trivial EID-Prefix hijacking attacks. As developers As described here, this is essentially relying on local configuration for information about who is authoritative for what EID prefixes, which is prone to becoming stale and does not scale. Section 8.3 If there is no match, the Map- Server returns a Negative Map-Reply with action code "Natively- Forward" and a 15-minute TTL. [...] In light of my comments in section 8.2, perhaps we can consolidate the normative requirements to just one location and have a pointer from the other(s)? If the EID-prefix is either registered or not registered to the mapping system and there is a policy in the Map-Server to have the requestor drop packets for the matching EID-prefix, then a Drop/ Policy-Denied action is returned. [...] In a Map-Server state machine or flow chart, it seems like this policy application would come before even the above checks for negative responses. Should the document reflect that ordering as well? If the EID-prefix is registered or not registered and there is a authentication failure, then a Drop/ Authentication- failure action is returned. [...] I'm confused what kind of authentication failure is possible here -- there does not seem to be any end-to-end client authentication of mapping requests that I have seen in any LISP documents I've read so far. Section 9 To publish an authoritative EID-to-RLOC mapping with a Map-Server, an ETR includes authentication data that is a hash of the message using a pair-wise shared key. [...] "hash" is a term of art and is not appropriate here; please use "MAC". [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin authentication, integrity, anti-replay protection, and prevention of man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- Reply exchange. Work is ongoing on this and other proposals for resolving these open security issues. It only partially mitigates some of those, and for others relies on the mapping system to provide some properties that are not clearly achievable. It is unwise to claim that they are possible absent further clarity on what behavior mapping systems can currently provide. [edit: this text changed in the -16] Section 11.3 In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA. How will a prospective implementor know that they have found all defined flags fields? Are documents allocating new ones supposed to Update: this one? Section 11.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]. [...] nit: comma splice Section 11.5 I would suggest Expert Review rather than FCFS, for such a scarce codepoint space with only 256 total values. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
