Return-Path: 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: =?us-ascii?q?A0AEAACzCYBc/4wNJK1kDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgWAvaIEDJ4QIiBqNKy18lycUgWMEDRgBCoF?= =?us-ascii?q?UgnUChDEiNAkNAQEDAQEDAQMCbRwMhUsBAQEDAQEYAQhLGwkCGCABAgcCAic?= =?us-ascii?q?wBgEMBgIBAYMeAYF1D49Em2aBLx+DZQGBP4RfBYEvAYsLHReBQD+BESeBbUk?= =?us-ascii?q?1gx4BAYEuARIBCQmDF4JXAooSBC+HK5IfCYtDhzcGGYF2hlKCNogxim+BEpF?= =?us-ascii?q?GgUc4ZXEzGggbFTuCbIIWFxOITIUEBAFXHgMwi0kNF4InAQE?= 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 , The IESG , "lisp-chairs@ietf.org" , "draft-ietf-lisp-sec@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 Message-ID: <5d91ab1e-a960-603c-eb7b-10ca62174921@cisco.com> Date: Wed, 6 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 18:01:26 -0000 This is a multi-part message in MIME format. --------------04317DAF529353E2B96B12CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------04317DAF529353E2B96B12CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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


--------------04317DAF529353E2B96B12CB--