Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Sat, 13 October 2018 02:47 UTC
Return-Path: <ekr@rtfm.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 C7CA6130DC3 for <lisp@ietfa.amsl.com>; Fri, 12 Oct 2018 19:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 xbXoYgndzkne for <lisp@ietfa.amsl.com>; Fri, 12 Oct 2018 19:47:42 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A302128CF3 for <lisp@ietf.org>; Fri, 12 Oct 2018 19:47:41 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id j4-v6so12895390ljc.12 for <lisp@ietf.org>; Fri, 12 Oct 2018 19:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d2JG7mDtfRFA7o9sPoIhts1tZfun+5eIc7j97d24H7A=; b=Ezm/PW/g5GgpXB2yI4LbNzXAvhVZILQpSEGHFUZe9TQyykMVAf8OEe1MoZlPYJbX8B G8wb/2t1LGKIWI0FJAcynkWMcBzstDnWScJdghDwbwKPBbNgQu6hFS+7AUML+BacRIgE ul1nYcQSsosyLVqDOQqgCtZ5EZ9Ctts6Xy2nCTl18VU+hye5dQgYmajDhdBWSyH5HNvM sjkGtyuCJ8I+DWydbCGztpiB5k+hQp4FiKE9+MNX07D0E+lP2NZvaNj9kEYhzRY2k0BS ty98D5/KzzwRZ2QuPupEucBYIznZ0mNwCRTdGHUlglHXSFtCMAQkBW00bqBiUXYsyAXY TF5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d2JG7mDtfRFA7o9sPoIhts1tZfun+5eIc7j97d24H7A=; b=hzH7PtHLF10hSfhv7wI+HjMQhCHpcqW7uBwZSWy5gviV/yxAlZr5/ZDFTWoJ+T1xnL rj0hvaxYX0MlQOg0M8ULJldENhy60tkAy5itCSHLHHFVh6NeTlbSQPy9yOh2dHHyRJx9 wCnAHz0nI0CkSqtAi2kPzX478LXfghg8ABv6A8VPvnQeeJfrYkTjNj3tTbHDFWM+SiTl RyyNKxhJK+A+Mlmbvv4KjB05NB+4HTrTIcW+XwrBqKlOCmE1kdpWOuOQSvuf6PVlHsq+ vppUjjn1Vg2ihlH8TMFzjcNP8KTq/34/5VT63emY45SlJ0FizGEhk7f1tV2zHF2c+u3H qWWw==
X-Gm-Message-State: ABuFfoh2n8lNph1nznpTR3zOQqo93EHlYEmvvZO4c5CV9oxKIX5X834w 4MzY4U8K9ymImPd9wB5pGOOr7m6KCZpZxMC8WQxiXg==
X-Google-Smtp-Source: ACcGV60uA8u8g+TryNCBcOocqcsnLl8KS+xLgRmrCKcMbHGYUfQcMfDk/bjGCTanyANW86SEToFbSfubbdfamdXMId8=
X-Received: by 2002:a2e:94c4:: with SMTP id r4-v6mr5538378ljh.68.1539398859392; Fri, 12 Oct 2018 19:47:39 -0700 (PDT)
MIME-Version: 1.0
References: <153805068062.26427.10428634331947404660.idtracker@ietfa.amsl.com> <ACFD874F-113E-4AD4-9056-CD3CFA9BA477@gmail.com>
In-Reply-To: <ACFD874F-113E-4AD4-9056-CD3CFA9BA477@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 12 Oct 2018 19:47:02 -0700
Message-ID: <CABcZeBM4XotbW6BYbCzHq7SJW7NdVK+fJZom8J=AHwi+dkL5Wg@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, IESG <iesg@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, albert.cabellos@gmail.com, "BRUNGARD, DEBORAH A" <db3546@att.com>, fmaino@cisco.com, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002e9bb60578133a88"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/z5MoELDLlIIlnzquZ_Qq4piLSTk>
Subject: Re: [lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (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: Sat, 13 Oct 2018 02:47:50 -0000
> There are diff files attach for revisions 68830bis-24 and 6833bis-18. They have not been posted yet. > > > S 4.1. > >> RLOC (outer-header source IP address) in a received LISP packet. > >> Such a cache entry is termed a "glean mapping" and only contains > >> a single RLOC for the EID in question. More complete information > >> about additional RLOCs SHOULD be verified by sending a LISP Map- > >> Request for that EID. Both the ITR and the ETR MAY also > >> influence the decision the other makes in selecting an RLOC. > > > > This seems like it introduces an immediate overclaiming problem. > > It does not, if the gleaner wants to add this to the cache, it is > /32 EID with the source RLOC. So it is not overclaimed. If the > gleaner wants to verify the mapping, it does a lookup to the mapping > system on the source EID and then can get a coarser EID-prefix with > an authorized list of RLOCs. OK, thanks. > > S 10. > >> When an ETR decapsulates a packet, it will check for any change in > >> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > >> ETR, if acting also as an ITR, will refrain from encapsulating > >> packets to an RLOC that is indicated as down. It will only resume > >> using that RLOC if the corresponding Locator-Status-Bit returns to a > >> value of 1. Locator-Status-Bits are associated with a Locator-Set > > > > This seems to enable a pretty obvious denial of service attack in > > which you send a message with all LSBs set to 0. > > The LSBs are a hint and usually used for “idling down RLOCs”. I will > add text that ETR will rate-limit how often it reacts to LSB > changes. And note that its RLOC-probing cache will tell the rule > truth about if the RLOC is reachable. Sounds good. > > S 10. > >> list returned by the last Map-Reply will be set to zero for that > >> particular EID-Prefix. Refer to Section 16 for security related > >> issues regarding Locator-Status-Bits. > >> > >> When an ETR decapsulates a packet, it knows that it is reachable from > >> the encapsulating ITR because that is how the packet arrived. In > > > > It doesn't even know this. It just knows that that's been claimed by > > someone who can generate traffic to it. > > Well this is true, but 6833bis discusses RLOC-reachability and there > is a RLOC-probe cache that will tell the ITR when it last heard from > the RLOC. Just to be clear, it's not "last heard from" that you need, but rather "last verifiably responded". > > S 16. > >> Map-Versioning is a Data-Plane mechanism used to signal a peering xTR > >> that a local EID-to-RLOC mapping has been updated, so that the > >> peering xTR uses LISP Control-Plane signaling message to retrieve a > >> fresh mapping. This can be used by an attacker to forge the map- > >> versioning field of a LISP encapsulated header and force an excessive > >> amount of signaling between xTRs that may overload them. > > > > Can't I also set a super-high version number, thus gagging updates? > > It doesn’t matter the value. All that matters is that it changed and you should do to the mapping system to get an updated RLOC-set. Hmm... S 5.1 of 6834-bis suggests that you can just discard it. On Thu, Oct 11, 2018 at 3:39 PM Dino Farinacci <farinacci@gmail.com> wrote: > Eric/Ben, I am following up with responses and changes to address the > security comments in 6830bis. I have both of your comments enclosed and > indented in this email. Eric’s comments come first then Ben’s second. > > There are diff files attach for revisions 68830bis-24 and 6833bis-18. They > have not been posted yet. > > > S 4.1. > >> RLOC (outer-header source IP address) in a received LISP packet. > >> Such a cache entry is termed a "glean mapping" and only contains > >> a single RLOC for the EID in question. More complete information > >> about additional RLOCs SHOULD be verified by sending a LISP Map- > >> Request for that EID. Both the ITR and the ETR MAY also > >> influence the decision the other makes in selecting an RLOC. > > > > This seems like it introduces an immediate overclaiming problem. > > It does not, if the gleaner wants to add this to the cache, it is /32 EID > with the source RLOC. So it is not overclaimed. If the gleaner wants to > verify the mapping, it does a lookup to the mapping system on the source > EID and then can get a coarser EID-prefix with an authorized list of RLOCs. > > > S 10. > >> When an ETR decapsulates a packet, it will check for any change in > >> the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > >> ETR, if acting also as an ITR, will refrain from encapsulating > >> packets to an RLOC that is indicated as down. It will only resume > >> using that RLOC if the corresponding Locator-Status-Bit returns to a > >> value of 1. Locator-Status-Bits are associated with a Locator-Set > > > > This seems to enable a pretty obvious denial of service attack in > > which you send a message with all LSBs set to 0. > > The LSBs are a hint and usually used for “idling down RLOCs”. I will add > text that ETR will rate-limit how often it reacts to LSB changes. And note > that its RLOC-probing cache will tell the rule truth about if the RLOC is > reachable. > > > > > > > S 10. > >> list returned by the last Map-Reply will be set to zero for that > >> particular EID-Prefix. Refer to Section 16 for security related > >> issues regarding Locator-Status-Bits. > >> > >> When an ETR decapsulates a packet, it knows that it is reachable from > >> the encapsulating ITR because that is how the packet arrived. In > > > > It doesn't even know this. It just knows that that's been claimed by > > someone who can generate traffic to it. > > Well this is true, but 6833bis discusses RLOC-reachability and there is a > RLOC-probe cache that will tell the ITR when it last heard from the RLOC. > > > > > > > S 10.1. > >> NOT use the lack of return traffic as an indication that the ETR is > >> unreachable. Instead, it MUST use an alternate mechanism to > >> determine reachability. > >> > >> 10.1. Echo Nonce Algorithm > >> > > > > This mechanism seems sufficient to verify unreachability but is not a > > secure test of reachability because the nonce is way too short. > > The nonce can remain the same value for a certain amount of time to > timeout reachability or when it receives the echo to the nonce. The nonce > need not be incremented for every packet. The nonce in the LISP header is > not used for security purposes, even though many want to use it that way. > But as you say, it is too width-short for that. > > > > > S 16. > >> Map-Versioning is a Data-Plane mechanism used to signal a peering xTR > >> that a local EID-to-RLOC mapping has been updated, so that the > >> peering xTR uses LISP Control-Plane signaling message to retrieve a > >> fresh mapping. This can be used by an attacker to forge the map- > >> versioning field of a LISP encapsulated header and force an excessive > >> amount of signaling between xTRs that may overload them. > > > > Can't I also set a super-high version number, thus gagging updates? > > It doesn’t matter the value. All that matters is that it changed and you > should do to the mapping system to get an updated RLOC-set. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 5.3. > >> header. > >> > >> When doing ETR/PETR decapsulation: > >> > >> o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > >> the case of IPv6) SHOULD be copied from the outer-header 'Time to > > > > This should probably be a MUST because there are other protocols that > > assume that TTLs get decremented. > > This was changed in a previous version post your comments. > > > > > S 7.1. > >> destination site. The two fragments are reassembled at the > >> destination host into the single IP datagram that was originated by > >> the source host. Note that reassembly can happen at the ETR if the > >> encapsulated packet was fragmented at or after the ITR. > >> > >> This behavior MAY be performed by the ITR only when the source host > > > > Nit: I think you want to say MUST be, assuming you mean that you can > > perform it only if…. > > This was changed in a previous version post your comments. > > > > > > > S 7.2. > >> 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet > >> with the DF bit set to 1, exceeds what the core network can > >> deliver, one of the intermediate routers on the path will send an > >> ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ > >> Fragmentation-Needed to the ITR, respectively. The ITR will > >> parse the ICMP message to determine which Locator is affected by > > > > What if you are in an environment where ICMP is blocked? > > I replied in previous email. > > > > > > > S 9. > >> outside of the subset list if it determines that the subset list > >> is unreachable (unless RLOCs are set to a Priority of 255). Some > >> sharing of control exists: the server-side determines the > >> destination RLOC list and load distribution while the client-side > >> has the option of using alternatives to this list if RLOCs in the > >> list are unreachable. > > > > How would you obtain alternative RLOCs? > > I said in a previous email, you do a lookup in the mapping system. > > > > > > > S 10. > >> also acting as an ITR and has traffic to return to the original > >> ITR site, it can use this status information to help select an > >> RLOC. > >> > >> 2. When an ETR receives an encapsulated packet from an ITR, the > >> source RLOC from the outer header of the packet is likely up. > > > > What does "is likely up" mean? > > > This was changed in a previous version post your comments. > > Ben’s comments: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have grave concerns about the suitability of LISP as a whole, in its > > present form, for advancement to the Standards-Track. While some of my > > concerns are not specific to this document, as the core protocol > > (data-plane) spec, it seems an appropriate place to attach them to. > > If you look at 6830bis-24 and 6833bis-18, we think we have addressed your > security concerns. > > > Section 3 defines the EID-to-RLOC Datbaase: > > > > EID-to-RLOC Database: The EID-to-RLOC Database is a global > > distributed database that contains all known EID-Prefix-to-RLOC > > mappings. Each potential ETR typically contains a small piece of > > the database: the EID-to-RLOC mappings for the EID-Prefixes > > "behind" the router. These map to one of the router's own > > globally visible IP addresses. Note that there MAY be transient > > conditions when the EID-Prefix for the site and Locator-Set for > > each EID-Prefix may not be the same on all ETRs. This has no > > negative implications, since a partial set of Locators can be > > used. > > > > No compelling architecture for a trustworthy global distributed database > > has been presented that I've seen so far, and LISP relies heavily on the > > mapping system's database for its functionality. I am concerned that so > > many requirements are placed on the mapping system so as to be in effect > > unimplementable, in which case it would seem that the architecture as a > > whole (that is, for a global Internet-scale system) is not fit for > purpose. > > The DNS naming system and the BGP routing system are distributed > databases. But in any event, we removed the term “global” from both the > data-plane and control-plane documents. > > > Section 4.1's Step (6) only mentions parsing "to check for format > > validity". I think it is appropriate to mention (and refer to) source > > authentication checks as well, since bad Map-Reply data can allow all > sorts > > of attacks to occur. > > Well by now you should see that we have them. And one has to be careful to > not have a downgrade attack by continually doing source checks at > data-plane time. > > > There are some fairly subtle ordering requirements between the order of > > entries in Map-Reply messages and the Locator-Status-Bits in data-plane > > It is not subtle. It is explicitly explained in section 10., > > > The usage of the Instance ID does not seem to be adequately covered; from > > what I've been able to pick up so far it seems that both source and > > destination participants must agree on the meaning of an Instance ID, and > > They do not have to agree. It is the ITR that decides when a packet > arrives which instance-ID an EID belongs to. This is discuss in quite a lot > of detail in draft-ietf-lisp-vpn. > > > the source and destination EIDs must be in the same Instance. This does > > not seem like it is compatible with Internet scale, especially if there > are > > only 24 usable bits of Instance ID. > > draft-ietf-lisp-vpn explains how 24-bits can be used in the data-plane but > 32-bits of instance-ID is available in the control-plane. And that is > 32-bits *per* mapping system. ITRs can use other criteria to decide which > of many mapping systems it uses for lookups at data-plane time. > > > There seems to be a lot of intra-site synchronization requirements, > notably > > with respect to Map-Version consistency, the contents and ordering of > > There is absolutely, and conscienciosuly no *intra* site sync requirements. > > > locator sets for EIDs in the site, etc.; the actual hard requirements for > > synchronization within a site should be clearly called out, ideally in a > > single location. > > > > The security considerations attempt to defer substantially to the > > threat-analysis in RFC 7835, which does not really seem like a complete > > threat analysis and does not provide analysis as to what requirements are > > placed on the boundaries between the different components of LISP (data > > plane, control plane, mapping system, various extensions, etc.). The > > secdir reviewer had some good thoughts in this space. > > This should be fixed now in both 6830bis-24 and 6833bis-18. > > > The security considerations throughout the LISP documents place a heavy > > focus on the risk of over-claiming for routing EID-prefixes. This is a > > real concern, to be clear, but it should not overshadow the risk of an > > attacker who is able to move traffic around at will, strip security > > protections, cause denial of service, alter data-plane payloads, etc. > > Similarly, this document's security considerations call out denial of > > service as a risk from Map-Cache insertion/spoofing, but the risks from > an > > attacker being able to read and modify the traffic, perhaps even without > > detection, seems a much greater threat to me. > > This should be fixed now in both 6830bis-24 and 6833bis-18. > > > I am not convinced that this protocol meets the current IETF requirements > > for the security properties of Standards-Track Protocols without at least > > LISP-SEC as a mandatory-to-implement component, and possibly additional > or > > stronger requirements. (I did not do a full analysis of the system in > the > > presence of those security mechanisms, since that is not what is being > > presented for review.) > > We have made draft-ietf-lisp-sec mandatory. Or at least, we have asked the > working group and there have been no objections so far. > > > Having an EID that is associated to user-correlatable devices has severe > > privacy considerations, but I could not find this mentioned anywhere in > all > > of the LISP documents I've read so far. > > This should be fixed now in both 6830bis-24 and 6833bis-18. > > > The instance ID provides for organizational correlation, another privacy > > exposure. > > It is an opaque value and even though when LISP-crypto is used the LISP > header does travel in the clear, you do not know who uses it unless you > have access to the mapping system and authorized to do lookups on that > instance-ID. There are many keys required to get access to it (we have a > sort of MFA implemented). > > > Is there anything different between an "EID-to-RLOC Map-Request" and > just a > > "Map-Request"? (Same question for "Map-Reply", too.) > > I have removed the single occurence of "EID-to-RLOC Map-Request” to > “Map-Request”. > > > There's a lot of stuff that seems to work best if there is symmetric > > bidirectional traffic, with inline signalling of map version and > > reachability changes, though clearly everything is designed to also work > > with asymmetric connectivity or unidirectional traffic. It would be nice > > to have a high-level summary in or near the introduction about what kinds > > of behavior/performance differences are expected for bidirectional vs. > > unidirectional traffic. > > Nothing requires one or the other at the data-plane. I would prefer to not > mention this. Because it may introduce comments not covered yet in the > document or are control-plane related that don’t belong in 6830bis. > > > Section 2 > > > > That's not the 8174 boilerplate; it's more than just adding a cite to the > > 2119 boilerplate. > > This was changed in a previous version post your comments. > > > > > Section 3 > > > > nit: "An address family that pertains to the Data-Plane." is a sentence > > fragment. > > > > Ingress Tunnel Router (ITR): An ITR is a router that resides in a > > [...] > > mapping lookup in the destination address field. Note that this > > destination RLOC MAY be an intermediate, proxy device that has > > better knowledge of the EID-to-RLOC mapping closer to the > > > > This doesn't seem like a 2119 MAY is necessary, but rather a statement of > > fact that may not be known to the encapsulating ITR. > > > > Specifically, when a service provider prepends a LISP header for > > Traffic Engineering purposes, the router that does this is also > > regarded as an ITR. The outer RLOC the ISP ITR uses can be based > > on the outer destination address (the originating ITR's supplied > > RLOC) or the inner destination address (the originating host's > > supplied EID). > > > > I'm confused here, perhaps in multiple ways. Are there now *two* LISP > > headers on the packet? Is the "outer RLOC the ISP ITR uses" the source > > RLOC or the destination RLOC? > > > > Negative Mapping Entry: A negative mapping entry, also known as a > > negative cache entry, is an EID-to-RLOC entry where an EID-Prefix > > is advertised or stored with no RLOCs. That is, the Locator-Set > > for the EID-to-RLOC entry is empty or has an encoded Locator count > > of 0. > > > > Is "empty" a distinct representation from "locator count of zero”? > > All fixed in a previous version post your comments. > > > Perhaps something of an aside, but the check described for > > Route-Returnability is a somewhat weak check, and in some cases could > still > > be spoofed. (I don't expect this to surprise anyone, of course, but > > perhaps some more qualifiers could be added to the text.) > > > > Section 4 > > > > An additional LISP header MAY be prepended to packets by a TE-ITR > > when re-routing of the path for a packet is desired. A potential > > use-case for this would be an ISP router that needs to perform > > Traffic Engineering for packets flowing through its network. In such > > a situation, termed "Recursive Tunneling", an ISP transit acts as an > > additional ITR, and the RLOC it uses for the new prepended header > > would be either a TE-ETR within the ISP (along an intra-ISP traffic > > engineered path) or a TE-ETR within another ISP (an inter-ISP traffic > > engineered path, where an agreement to build such a path exists). > > > > "the RLOC it uses for the new prepnded header", again, this is as the > > destination RLOC (vs. source RLOC)? > > Fixed in a previous version post your comments. > > > Section 4.1 > > > > o Map-Replies are sent on the underlying routing system topology > > using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. > > > > Just to check my understanding: is the "underlying routing system > topology" > > the same as the "underlay"? > > > > Is step (3) just describing more of what step (2) says is "not described > in > > this example”? > > All fixed in a previous version post your comments. > > > Section 5.3 > > > > The word "nonce" is normally used for something used exactly once. > > E.g., with some AEAD algorithms, if the same "nonce" input is used for > > different encryptions, the entire security of the system is compromised. > > It would be better to refer to this field with a different term, given > > that "the same nonce can be used for a period of time when encapsulating > to > > the same ETR". "Uniquifier" or "random value" might be reasonable > choices. > > We can’t change this. There is too much deployment and terminology based > on it. It is a random number, a relatively small one but a random number. > > > Why is there no discussion of the Map-Version or Instance-ID fields > > in this section? > > > > When doing ETR/PETR decapsulation: > > > > o The inner-header 'Time to Live' field (or 'Hop Limit' field, in > > the case of IPv6) SHOULD be copied from the outer-header 'Time to > > Live' field, when the Time to Live value of the outer header is > > less than the Time to Live value of the inner header. Failing to > > perform this check can cause the Time to Live of the inner header > > to increment across encapsulation/decapsulation cycles. This > > check is also performed when doing initial encapsulation, when a > > packet comes to an ITR or PITR destined for a LISP site. > > > > Er, what is "this check" that is also performed for initial > encapsulation? > > How are there multiple TTL values to compare? > > > > o The inner-header 'Differentiated Services Code Point' (DSCP) field > > (or the 'Traffic Class' field, in the case of IPv6) SHOULD be > > copied from the outer-header DSCP field ('Traffic Class' field, in > > the case of IPv6) to the inner-header. > > > > nit: the first "inner-header" seems like an editing remnant? > > All fixed in a previous version post your comments. > > > > > Section 7.1 > > > > How is this stateless if it invovles knowledge about the routers between > > the ITR and all possible ETRs (i.e., a set that could change over time)? > > > > Section 8 > > > > This 32-bit vs 24-bit thing is pretty hokey for a standards-track > > specification (yes, I know that LISP-DDT is not standards track at the > > moment). > > Already explained. See draft-ietf-lisp-vpn. It isn’t hokey, we want to > have a large space and not spend the cost of it in the data-plane. So we > have to compress the value. > > > Section 9 > > > > Alternatively, RLOC information MAY be gleaned from received tunneled > > > > What is this an alternative to? The list of four options above? > > > > packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache > > entry, one learned from the source RLOC of a received encapsulated > > packet, is only stored and used for a few seconds, pending > > verification. Verification is performed by sending a Map-Request to > > the source EID (the inner-header IP source address) of the received > > encapsulated packet. > > > > The source EID is some random end system, right? So this relys on some > > magic in the ETR to detect that there's a Map-Request and reply directly > > instead of passing it on to the EID that won't know what to do with it? > > I hope by now, you understand this. > > > Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and > > might benefit from an explicit section reference to the other document. > > That was fixed. > > > Section 10 > > > > What is the "CE" of "CE-based ITRs"? Presumably Customer Edge, but it > > is not marked as well-known at > > https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion > is > > probably in order. > > Answered. We have it in the Definition of Terms section. > > > Again, when we are talking about the internal structure of the > Map-Reply, a > > detailed section refernce to 6833bis is useful. > > > > Modifying LSBs seems like a fine DoS attack vector for an on-path > attacker. > > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > per EID-Prefix. Therefore, when a Locator becomes unreachable, the > > Locator-Status-Bit that corresponds to that Locator's position in the > > list returned by the last Map-Reply will be set to zero for that > > particular EID-Prefix > > See comments above to Eric. > > > Doesn't this imply a stateful relationship between the ordering of > > Map-Replys and data-plane traffic? > > > > Section 10.1 > > > > Note that "ITR" and "ETR" are relative terms here. Both devices MUST > > be implementing both ITR and ETR functionality for the echo nonce > > mechanism to operate. > > Answered previously. I believe you understand this now. > > > Perhaps they could be given actual names so as to disambiguate which > steps > > are performed with ITR vs. ETR role? > > > > The echo-nonce algorithm is bilateral. That is, if one side sets the > > E-bit and the other side is not enabled for echo-noncing, then the > > echoing of the nonce does not occur and the requesting side may > > erroneously consider the Locator unreachable. An ITR SHOULD only set > > the E-bit in an encapsulated data packet when it knows the ETR is > > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > > probe Map-Reply message. > > > > Why is this even optional? If it was mandatory to use, then there would > > not be a question. But at least clarify that the "this" that is conveyed > > is whether the peer supports the echo-nonce algorithm. (Also, subject to > > downgrade.) > > It is optional because you can use RLOC-probing in the control-plane. > > > Section 13 > > > > When a Locator record is removed from a Locator-Set, ITRs that have > > the mapping cached will not use the removed Locator because the xTRs > > will set the Locator-Status-Bit to 0. So, even if the Locator is in > > the list, it will not be used. For new mapping requests, the xTRs > > can set the Locator AFI to 0 (indicating an unspecified address), as > > well as setting the corresponding Locator-Status-Bit to 0. This > > forces ITRs with old or new mappings to avoid using the removed > > Locator. > > > > The behavior describe here seems like it would be better described as > "when > > a Locator is taken out of service" than "removed from a Locator-Set", > since > > if it is not in the set at all, it has no index, and no LSB or AFI to > set. > > Should actually depopulating it like this be forbidden? > > Answered above and new text added. > > > I guess the Map Versioning is supposed to help with this, but we need to > > nail down the semantics more and/or give a clearer reference to it. > > That was done for you. > > > Section 13.1 > > > > An ITR, when it encapsulates packets to ETRs, can convey its own Map- > > Version Number. This is known as the Source Map-Version Number. > > > > Replacing "its own Map-Version Number" with something like "the > Map-Version > > numer for the LISP site of which it is a part". Writing this causes me > to > > note that the semantics of the Map-Version are unclear, here -- what is > it > > scoped to? An EID-Prefix? An RLOC? Oh, you say that in the next > > paragraph (EID-Prefix). > > > > A Map-Version Number can be included in Map-Register messages as > > well. This is a good way for the Map-Server to assure that all ETRs > > for a site registering to it will be synchronized according to Map- > > Version Number. > > > > Huh? I must be confused how this works. (Also, wouldn't this be better > in > > the control plane document which covers Map-Register?) > > The reference to draft-ietf-lisp-rfc68934bis should help this. > > > Section 15 > > > > o When a tunnel-encapsulated packet is received by an ETR, the outer > > destination address may not be the address of the router. This > > makes it challenging for the control plane to get packets from the > > hardware. This may be mitigated by creating special Forwarding > > Information Base (FIB) entries for the EID-Prefixes of EIDs served > > by the ETR (those for which the router provides an RLOC > > translation). These FIB entries are marked with a flag indicating > > that Control-Plane processing SHOULD be performed. > > > > I assume this is just my lack of background showing, but I'm confused how > > it makes sense to mark these for control-plane processing. Isn't the > > control plane much slower, and we're not putting all of the LISP > data-plane > > traffic onto the slow path? > > Answered in previous email. I think you understand this now. > > > Section 18 > > > > o Data-Plane gleaning for creating map-cache entries has been made > > optional. If any ITR implementations depend or assume the remote > > ETR is gleaning should not do so. > > > > nit: this is ungrammatical; "they should not" or "Any ITR implementations > > that depend on or assume that" would fix it. > > That was fixed pre -24. > > > Section 19.1 > > > > Presumably IANA also updated the reference column to point to this > > document? > > Yes, it is now. > > Thanks all, > Dino > > > >
- [lisp] Eric Rescorla's Discuss on draft-ietf-lisp… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Luigi Iannone
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Luigi Iannone
- Re: [lisp] Eric Rescorla's Discuss on draft-ietf-… Dino Farinacci