[lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT))

[Benjamin Kaduk <[e-mail]>]

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