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. Network > operartors should carefully weight how the LISP-SEC threat model > applies 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 is > mandatory 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-sec > is allowed. There seem to be several possibilities for how one might > construct such a signal; two that came to mind to me would be (1) to define a > new ACT value for "repeat without lisp-sec" that could be returned as a > negative Map-Response directly from the mapping system wherever the mapping > system 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 an > optional 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 that > indicates lisp-sec non-support and binds to the nonce in the request. > Whether these are workable ideas seems to depend on aspects of the mapping > system 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 that many 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 there are existing RFC 6833 deployments that want to migrate to 6833bis when it is finalized, we should consider what steps would be needed to safely deploy LISP-SEC without disruption. In particular, it seems a useful goal to try to get the security benefit of LISP-SEC for those machines/sites that have LISP-SEC capability without waiting for the entire administrative domain's deployment to get updated software/firmware, which I assume is at least 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 inherently require 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 more contained set of devices and does not need to handle data-plane levels of traffic. Once that's done, though, we still have the question of "which ETRs are updated to be registering themselves as LISP-SEC-capable?". For any given ITR/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-SEC capable. If the ITR is not capable, this is easy, as the Map-Request will never 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 all Map-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 system that the ETR it's being mapped to is not LISP-SEC-capable, and it should try again without LISP-SEC. This signal needs to be authenticated not just for security reasons (though an insecure downgrade would render LISP-SEC useless against an active attacker until the entire deployment disabled non-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 to repackage 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 pretty lousy 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 "retry with 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 that the 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 and proposed remediation. -Benjamin _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
