Subject: Re: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT))
From: Fabio Maino <[email-masked]>
To: [email-masked], Benjamin Kaduk <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 6 Mar 2019 10:01:17 -0800
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>

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