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 <fmaino@cisco.com> Wed, 06 March 2019 18:01 UTC

Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CC2130FE5; Wed, 6 Mar 2019 10:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beKM7QCxEWos; Wed, 6 Mar 2019 10:01:21 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5476C12EB11; Wed, 6 Mar 2019 10:01:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46318; q=dns/txt; s=iport; t=1551895281; x=1553104881; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=7o5mnmiuzGt+hRIza+cmIpFOSLshaFYoBgi9peRxbaU=; b=CD0jKzua/KcJx+Fg8+/A4dJ5nk2uhOd4k3Ej78AQXhZo4sUHbGOXZSar RhZQle5VTXmZv1WecmrnnpDA7xU+ZIRIctuZhDFn0RTO8eNT3whzU7lr2 GcXlkMe/JGRmkyTWlwtH+vVVR0Xb4rYOl1ZwXIZQJ6DT595Mr3Y28eBmH U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAACzCYBc/4wNJK1kDgwBAQEBAQIBAQEBBwIBAQEBgVEFAQEBAQsBgWAvaIEDJ4QIiBqNKy18lycUgWMEDRgBCoFUgnUChDEiNAkNAQEDAQEDAQMCbRwMhUsBAQEDAQEYAQhLGwkCGCABAgcCAicwBgEMBgIBAYMeAYF1D49Em2aBLx+DZQGBP4RfBYEvAYsLHReBQD+BESeBbUk1gx4BAYEuARIBCQmDF4JXAooSBC+HK5IfCYtDhzcGGYF2hlKCNogxim+BEpFGgUc4ZXEzGggbFTuCbIIWFxOITIUEBAFXHgMwi0kNF4InAQE
X-IronPort-AV: E=Sophos;i="5.58,448,1544486400"; d="scan'208,217";a="520117509"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2019 18:01:18 +0000
Received: from [10.32.222.199] ([10.32.222.199]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTP id x26I1H5F030850; Wed, 6 Mar 2019 18:01:18 GMT
To: lisp@ietf.org, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "draft-ietf-lisp-sec@ietf.org" <draft-ietf-lisp-sec@ietf.org>, "draft-ietf-lisp-rfc6833bis@ietf.org" <draft-ietf-lisp-rfc6833bis@ietf.org>
References: <154954743968.23471.9935733647283605722.idtracker@ietfa.amsl.com> <20190209221334.GA23225@kduck.mit.edu> <4723572b-1883-1bba-852d-b24014d987a3@cisco.com>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <5d91ab1e-a960-603c-eb7b-10ca62174921@cisco.com>
Date: Wed, 06 Mar 2019 10:01:17 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <4723572b-1883-1bba-852d-b24014d987a3@cisco.com>
Content-Type: multipart/alternative; boundary="------------04317DAF529353E2B96B12CB"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.32.222.199, [10.32.222.199]
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/WdLvZR0RX9qU1szqpTR8Qrr_6Rw>
Subject: Re: [lisp] incremental transition to LISP-SEC (was Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-24: (with DISCUSS and COMMENT))
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 18:01:26 -0000

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