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. 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
