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

[Fabio Maino <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp