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
>
>
>
>