Hi Benjamin,here is how we plan to update LISP-SEC to address this according to what anticipated in my previous email. Let me know if it fits what you were suggesting.
We add the ETR-Cant-Sign E-bit to the EID-AD: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECM AD Type |V| Reserved | Requested HMAC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | OTK Length | OTK Encryption ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | One-Time-Key Preamble ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD | ... One-Time-Key Preamble | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ One-Time Key (128 bits) ~/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | EID-AD Length | KDF ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record Count |E| Reserved | EID HMAC ID |EID-AD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | | Reserved | EID mask-len | EID-AFI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | ~ EID-prefix ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | ~ EID HMAC ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ LISP-SEC ECM Authentication Data [...] E: ETR-Cant-Sign bit. This bit is set to 1 to signal to the ITR that at least one of the ETRs authoritative for the EID prefixes of this Map-Reply has not enabled LISP-SEC. This allows the ITR to securely downgrade to non LISP-SEC requests, as specified in Section 5.7, if so desired. And then we update Map-Server processing accordingly in Section 5.7: 5.7. Map-Server Processing Upon receiving an ECM encapsulated Map-Request with the S-bit set to 1, the Map-Server process the Map-Request according to the value of the security-capable S-bit and of the proxy map-reply P-bit contained in the Map-Register sent by the ETRs authoritative for that prefix during registration. Processing of the Map-Request MUST proceed in the order described in the table below, applying the processing corresponding to the first rule that matches the conditions indicated in the first column: +------------------+------------------------------------------------+ | Matching | Processing | | Condition | | +------------------+------------------------------------------------+ | 1. At least one | The Map-Server MUST generate a LISP-SEC | | of the ETRs | protected Map-Reply as specified in Section | | authoritative | 5.7.2. The ETR-Cant-Sign E-bit in the EID | | for the EID | Authentication Data (EID-AD) MUST be set to 0. | | prefix included | | | in the Map- | | | Request | | | registered with | | | the P-bit set to | | | 1 | | | | | | 2. At least one | The Map-Server MUST generate a LISP-SEC | | of the ETRs | protected Encapsulated Map-Request (as | | authoritative | specified in Section 5.7.1), to be sent to one | | for the EID | of the authoritative ETRs that registered with | | prefix included | the S-bit set to 1 (and the P-bit set to 0). | | in the Map- | The ETR-Cant-Sign E-bit of the EID-AD MUST be | | Request | set to 1 to signal the ITR that a non LISP-SEC | | registered with | Map-Request might reach additional ETRs that | | the S-bit set to | have LISP-SEC disabled. | | 1 | | | | | | 3. All the ETRs | The Map-Server MUST send a Negative Map-Reply | | authoritative | protected with LISP-SEC, as described in | | for the EID | Section 5.7.2. The ETR-Cant-Sign E-bit MUST be | | prefix included | set to 1 to signal the ITR that a non LISP-SEC | | in the Map- | Map-Request might reach additional ETRs that | | Request | have LISP-SEC disabled. | | registered with | | | the S-bit set to | | | 0 | | +------------------+------------------------------------------------+ In this way the ITR that sent a LISP-SEC protected Map-Request always receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach additional ETRs that have LISP-SEC disabled. This mechanism allows the ITR to securely downgrade to non LISP-SEC requests, if so desired. 5.7.1. Generating a LISP-SEC Protected Encapsulated Map-Request The Map-Server decapsulates the ECM and generates a new ECM Authentication Data. The Authentication Data includes the OTK-AD and the EID-AD, that contains EID-prefix authorization information, that are eventually received by the requesting ITR. The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from the ITR-OTK received with the Map-Request. MS-OTK is derived applying the key derivation function specified in the KDF ID field. If the algorithm specified in the KDF ID field is not supported, the Map-Server uses a different algorithm to derive the key and updates the KDF ID field accordingly. The Map-Server and the ETR MUST be configured with a pre-shared key for mapping registration according to [I-D.ietf-lisp-rfc6833bis]. If MS-OTK confidentiality is required, then the MS-OTK SHOULD be encrypted, by wrapping the MS-OTK with the algorithm specified by the OTK Encryption ID field as specified in Section 5.5. The Map-Server includes in the EID-AD the longest match registered EID-prefix for the destination EID, and an HMAC of this EID-prefix. The HMAC is keyed with the ITR-OTK contained in the received ECM Authentication Data, and the HMAC algorithm is chosen according to the Requested HMAC ID field. If The Map-Server does not support this algorithm, the Map-Server uses a different algorithm and specifies it in the EID HMAC ID field. The scope of the HMAC operation covers the entire EID-AD, from the EID-AD Length field to the EID HMAC field, which must be set to 0 before the computation. The Map-Server then forwards the updated ECM encapsulated Map- Request, that contains the OTK-AD, the EID-AD, and the received Map- Request to an authoritative ETR as specified in [I-D.ietf-lisp-rfc6833bis]. 5.7.2. Generating a Proxy Map-Reply LISP-SEC proxy Map-Reply are generated according to [I-D.ietf-lisp-rfc6833bis], with the Map-Replay S-bit set to 1. The Map-Reply includes the Authentication Data that contains the EID-AD, computed as specified in Section 5.7.1, as well as the PKT-AD computed as specified in Section 5.8. Thanks, Fabio On 2/28/19 3:46 PM, Fabio Maino wrote:
Hi Benjamin, thanks for bringing this up.I think it makes sense to have a mechanism for secure downgrade, and it should indeed simplify adoption and transition to LISP-SEC.I discussed what you proposed here with the LISP-SEC authors and with Dino and Alberto. We agree to the principles of what you are proposing.I'll send detailed text, but here is a brief description of what we plan to do.The Map-Register has already the capability to encode ETR's support for LISP-SEC. We will change the behavior of the MS to signal to the ITR when the ETR is not LISP-SEC capable.This will happen when - the ITR is sending a LISP-SEC Map-Request, AND - the corresponding ETR has not registered as LISP-SEC capable, AND- the ETR is in "non-proxy mode" (that is the mode in which the Map-reply should be originated at the ETR. (MS/ITR behavior won't change if the ETR is in "proxy mode")In this case the MS will send a Negative Map-Reply, protected by LISP-SEC, that includes an ETR-Cant-Sign bit that informs the ITR that the ETR doesn't support LISP-SEC. The integrity of the ECS bit is protected by LISP-SEC, as the rest of the Map-Reply. This will work without changes to the ETR.In this way the ITR has the option to choose to downgrade to non LISP-SEC if it wants to favor reachability.Thanks, Fabio On 2/9/19 2:14 PM, Benjamin Kaduk wrote:Splitting off a sub-thread for one fairly narrow point that AFAICT needs further discussion to clarify the path forward: On Thu, Feb 07, 2019 at 05:50:39AM -0800, Benjamin Kaduk wrote:---------------------------------------------------------------------- DISCUSS: ----------------------------------------------------------------------[...]3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Networkoperartors should carefully weight how the LISP-SEC threat modelapplies to their particular use case or deployment. If they decide to ignore a particular recommendation, they should make sure the risk associated with the corresponding threats is well understood.I'm concerned enough about the risk of having a "ITR requests lisp-sec but ETR didn't use it" case that causes complete breakage, that I want to talk about this a bit more. We currently in this document say that lisp-sec ismandatory to implement (which presumably covers at least ITRs, ETRs,Map-Resolvers, and Map-Servers). LISP-SEC itself says that "and ETR that supports LISP-SEC MUST set the S bit in its Map-Register messages". Is it possible that an ETR might "implement" but then not "support" LISP-SEC? If so, then we should consider the possibility that we need an authenticated signal (from the mapping system to the ITR) that downgrading from lisp-secis allowed. There seem to be several possibilities for how one mightconstruct such a signal; two that came to mind to me would be (1) to define anew ACT value for "repeat without lisp-sec" that could be returned as anegative Map-Response directly from the mapping system wherever the mappingsystem is able to discern that the ETR in question does not support lisp-sec (I don't actually know if this could happen at Map-Resolver or would need to be delayed until the final Map-Server) and (2) to have anoptional Map-Request field that the ETR is required to copy unchanged to the Map-Reply; this could then include a message HMAC'd in the ITR-OTK thatindicates lisp-sec non-support and binds to the nonce in the request.Whether these are workable ideas seems to depend on aspects of the mappingsystem to which I cannot speak.In terms of some background assumptions I've been making (that of course could be false, so I'm trying to make them explicit), I am assuming thatmany or most current LISP deployments do not utilize LISP-SEC at runtime.It's less clear to me how many deployments/implementations simply do not have LISP-SEC capabilities at all, or how easy it is to get software/firmware updates to the needed devices. Regardless, if thereare existing RFC 6833 deployments that want to migrate to 6833bis when itis finalized, we should consider what steps would be needed to safelydeploy LISP-SEC without disruption. In particular, it seems a useful goalto try to get the security benefit of LISP-SEC for those machines/sitesthat have LISP-SEC capability without waiting for the entire administrative domain's deployment to get updated software/firmware, which I assume is atleast a 5-year lead time in many sites.Given that at this point my analyses are mostly treating the mapping system as something of a closed "magic box" that takes Map-Requests as input and emits them to the appropriate ETRs (or internal proxy function), I'm forced to conclude that any incremental update to using LISP-SEC will inherentlyrequire the entire mapping system to upgrade first, before any concrete usage of LISP-SEC should be expected. Hopefully that's less of a burden than upgrading entire deployments, since the mapping system is a morecontained set of devices and does not need to handle data-plane levels oftraffic. Once that's done, though, we still have the question of "which ETRs areupdated to be registering themselves as LISP-SEC-capable?". For any givenITR/ETR pair, if both are LISP-SEC capable, we want them to be using LISP-SEC, while still allowing traffic if one or both are not LISP-SECcapable. If the ITR is not capable, this is easy, as the Map-Request willnever attempt to use LISP-SEC. But if the ITR is capable and the ETR is not, the ITR is going to either attempt to use LISP-SEC for allMap-Requests or need some out-of-band knowledge of whether the target ETR is capabable. Now, the whole point of the mapping system is that the ITR doesn't know what ETR it's going to talk to when it sends the Map-Request, so this "out-of-band" setup seems pretty hard to fulfil. My current best thought (not expected to be perfect) in this scenario is that the ITR that is LISP-SEC capable (and configured to use it, I suppose) will always try to use LISP-SEC, but needs an authenticated signal from the mapping systemthat the ETR it's being mapped to is not LISP-SEC-capable, and it shouldtry again without LISP-SEC. This signal needs to be authenticated not justfor security reasons (though an insecure downgrade would render LISP-SEC useless against an active attacker until the entire deployment disablednon-LISP-SEC exchanges), but also for performance concerns. As currently specified, the Map-Server that gets a LISP-SEC Map-Request but is going to forward it to an ETR that did not register as LISP-SEC capable is going torepackage the Map-Request into a non-LISP-SEC Map-Request to send to the ETR in question. That ETR will produce a normal Map-Reply, that the ITR will proceed to drop without processing, since it does not use LISP-SEC.IIUC, that leaves the ITR in "wait to timeout" territory, which is a prettylousy situation to be in. I know there are only a couple values left for ACT values, but it seems that this may be a big enough issue to justify allocating one for "retrywith downgrade", so that the final Map-Server can send a negative Map-Reply that does use LISP-SEC, and the ITR can have this authenticated signal thatthe destination ETR is not LISP-SEC capable at the moment. There are of course other ways to generate an authenticated downgrade signal, but the only other ones I've been able to come up with seem less architecturally pleasing (and may not in fact work when the destination ETR is running original RFC 6833 code).I'm interested in hearing what other people think about this scenario andproposed remediation. -Benjamin _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
