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
- [lisp] Benjamin Kaduk's Discuss on draft-ietf-lis… Benjamin Kaduk
- [lisp] incremental transition to LISP-SEC (was Re… Benjamin Kaduk
- Re: [lisp] incremental transition to LISP-SEC (wa… Fabio Maino
- Re: [lisp] incremental transition to LISP-SEC (wa… Fabio Maino
- [lisp] Deriving Map-Register/Notify authenticatio… Fabio Maino
- Re: [lisp] Deriving Map-Register/Notify authentic… Benjamin Kaduk
- Re: [lisp] Deriving Map-Register/Notify authentic… Fabio Maino
- Re: [lisp] Deriving Map-Register/Notify authentic… Dino Farinacci
- Re: [lisp] Deriving Map-Register/Notify authentic… Benjamin Kaduk
- Re: [lisp] Deriving Map-Register/Notify authentic… Benjamin Kaduk
- Re: [lisp] Deriving Map-Register/Notify authentic… Dino Farinacci
- Re: [lisp] Deriving Map-Register/Notify authentic… Benjamin Kaduk
- Re: [lisp] Deriving Map-Register/Notify authentic… Benjamin Kaduk