Subject: Re: [lisp] Fwd: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Mon, 1 Oct 2018 18:58:53 +0000

(A) Desirable, because LISP-SEC provides improved security for the
protocol, and depending on the deployment scenario and its threat model,
one should have the option of using it, so MtI would be a welcome
improvement.

I am an author of LISP-SEC.

Best,
Vina

On 9/28/18, 3:38 PM, "lisp on behalf of Joel M. Halpern"
<[email-masked] on behalf of [email-masked]> wrote:

>As co-chair, I would like to hear from the working group as to whether
>making LISP-SEC mandatory to Implement (not Mandatory to Use) for
>LISP6830bis and 6833bis implementations is
>a) desirable
>b) acceptable
>c) undesirable but livable
>d) unacceptable or worse.
>
>Please, do not just pick a letter.  Include explanation of your opinion.
>This is not a decision the ADs and Authors can make for the working group.
>
>Yours,
>Joel
>
>
>-------- Forwarded Message --------
>Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20:
>(with DISCUSS and COMMENT)
>Date: Fri, 28 Sep 2018 17:03:40 -0500
>From: Benjamin Kaduk <[email-masked]>
>To: Joel M. Halpern <[email-masked]>
>CC: The IESG <[email-masked]>, [email-masked], Luigi
>Iannone <[email-masked]>, [email-masked], [email-masked]
>
>Hi Joel,
>
>
>On Wed, Sep 26, 2018 at 11:53:02PM -0400, Joel M. Halpern wrote:
>> Is there text we can add about the scoping that will change your
>>discuss 
>> into a series of useful comments?
>
>I had attempted to structure my Discuss points so that they would either
>be
>useful comments as is, or rendered moot by a reduced scope.  I guess I can
>try to clarify those below.  (To be clear, reducing the scope is only
>going
>to move from "has potentially existentially bad problems" to "has
>substantial issues that likely require reengineering to resolve".)
>
>> If so, Some indication of how you would like that phrased would help us
>> address these.
>
>I think Ekr's ballot position on 6833bis has a good summary of the
>architecture assumptions that the reduced scope allows us to make.
>In order to have the document be able to plausibly make those claims, it
>looks like we'd need to at least:
>(1) update the Abstract/Introduction to clarify that the EID namespace is
>     only defined within a single administrative domain.
>(2) (optionally, if it makes sense) mention in the introduction that this
>     administrative domain can include transport over other networks in
>the
>     same way that a VPN would function[*], without requiring cooperation
>     from or interaction with the other networks' administrators
>(3) remove the "global" text from the EID-to-RLOC Database and Map-Cache
>     definitions
>(4) update the EID-Prefix definition to talk about the local site or
>     administrative domain's "address allocation authority"
>(5) Take a look at the EID definition to consider whether references to
>"on
>     the public Internet" are still valid, and the text about assignment
>     in a hierarchical manner should be revised for the new scope as well.
>     Likewise for EID-internal structure that is "not visible to the
>global
>     routing system"
>
>(I stopped skimming and looking for problematic text around section 6)
>
>[*] Ideally this would be done without using the term "VPN" itself, since
>I'd like to get a movement going to restrict "VPN" to include
>confidentiality (i.e., privacy) protection.  "virtual network" or "overlay
>network" may or may not be good candidate replacement terms.
>
>> If not, we seem to have a larger problem.
>
>Well, we appear to have five ADs that are supporting making LISP-SEC a
>normative reference and thus MTI; I don't know if that scale of change
>meets your threshold for a "larger problem".
>
>> Yours,
>> Joel
>> 
>> On 9/26/18 11:44 PM, Benjamin Kaduk wrote:
>> > Benjamin Kaduk has entered the following ballot position for
>> > draft-ietf-lisp-rfc6830bis-20: Discuss
>> > 
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut
>>this
>> > introductory paragraph, however.)
>> > 
>> > 
>> > Please refer to
>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>> > for more information about IESG DISCUSS and COMMENT positions.
>> > 
>> > 
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
>> > 
>> > 
>> > 
>> > ----------------------------------------------------------------------
>> > 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.
>> > 
>> > I am told, out of band, that the intended deployment model is no
>>longer to
>> > cover the entire Internet (c.f. the MISSREF-state
>> > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet
>>and the
>> > core can be logically separated and interconnected by LISP-capable
>> > routers", etc.), and that full Internet-scale operation is no longer a
>> > goal.  However, since that does not seem to be reflected in the
>>current
>> > batch of documents up for IESG review, I am forced to ballot on them
>> > "as-is", namely as targetting global Internet deployment.  The
>>requirements
>> > placed on the mapping system are so stringent so as to be arguably
>> > unachievable at Internet-scale, though that arguably has more of an
>> > interaction with the control-plane than the data-plane.  It's still in
>> > scope here, though, as part of the overall description of the protocol
>> > flow.
>
>(rendered moot by scope reduction)
>
>> > There are an almost innumerable number of downgrade attacks possible,
>>and
>> > the control-plane and data-plane security mechanisms are not normative
>> > dependencies of the current corpus of documents, and as such are not
>>up for
>> > consideration as mitigating the security concerns with the core
>>documents.
>
>The downgrade attacks will probably require some further analysis;
>LISP-SEC
>would protect a lot of the header bits but I think there may be some other
>data flows to be looked at.
>
>> > 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.
>
>(rendered moot by scope reduction)
>
>> > 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.
>
>(not affected by scope reduction)
>
>> > There are some fairly subtle ordering requirements between the order
>>of
>> > entries in Map-Reply messages and the Locator-Status-Bits in
>>data-plane
>> > traffic (so that the semantic meaning of the status bits are
>>meaningful),
>> > which is only given a minimal treatment in the control-plane
>>document.  The
>> > need for synchronization in interpreting these bits should be
>>mentioned
>> > more prominently in the data-plane document as well.
>
>(not affected by scope reduction)
>
>> > 
>> > 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
>> > 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.
>
>(not affected by scope reduction)
>
>> > 
>> > There seems to be a lot of intra-site synchronization requirements,
>>notably
>> > with respect to Map-Version consistency, the contents and ordering of
>> > 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.
>
>(not affected by scope reduction, since ETRs are affected and not just
>Map-Servers)
>
>> > 
>> > 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.
>
>(not affected by scope reduction)
>
>> > 
>> > 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.
>
>(not affected by scope reduction)
>
>> > 
>> > 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.)
>
>(noting that LISP-SEC needs to be MTI and analysis performed under the new
>assumptions)
>
>> > 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.
>
>(not affected by scope reduction)
>
>-Benjamin
>
>> > 
>> > 
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> > 
>> > I apologize for the somewhat scattered nature of these comments;
>>there are
>> > a lot of them and I was focusing my time more on trying to understand
>>the
>> > broader system, and the intended security posture, so they did not
>>get as
>> > much clean-up as I would have liked.  (Most of my review was
>>performed on the
>> > -18, though I have tried to update to the -20 as relevant.)
>> > 
>> > 
>> > The instance ID provides for organizational correlation, another
>>privacy
>> > exposure.
>> > 
>> > Is there anything different between an "EID-to-RLOC Map-Request" and
>>just a
>> > "Map-Request"?  (Same question for "Map-Reply", too.)
>> > 
>> > 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.
>> > 
>> > Section 2
>> > 
>> > That's not the 8174 boilerplate; it's more than just adding a cite to
>>the
>> > 2119 boilerplate.
>> > 
>> > 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"?
>> > 
>> > 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)?
>> > 
>> > 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"?
>> > 
>> > 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.
>> > 
>> > 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?
>> > 
>> > 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).
>> > 
>> > 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?
>> > 
>> > 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.
>> > 
>> > 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.
>> > 
>> > 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
>> > 
>> > 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.
>> > 
>> > 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.)
>> > 
>> > 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?
>> > 
>> > 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.
>> > 
>> > 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?)
>> > 
>> > 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?
>> > 
>> > 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.
>> > 
>> > Section 19.1
>> > 
>> > Presumably IANA also updated the reference column to point to this
>> > document?
>> > 
>> > 
>> > 
>
>_______________________________________________
>lisp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lisp

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 1 Oct 2018 11:59:25 -0700

I would say "(a) desirable". I agree with Dino that the more secure, the
better.

Also, thanks for gathering the WG opinion on this Joel. I think that it may
help if you re-send this question with a more explicit subject line.
Hopefully that will catch the attention of those at the WG that may not be
following this discussion in detail.

Thanks,
Alberto

On Fri, Sep 28, 2018 at 3:38 PM Joel M. Halpern <[email-masked]> wrote:

> > Is there text we can add about the scoping that will change your discuss
> I had attempted to structure my Discuss points so that they would either be
> try to clarify those below.  (To be clear, reducing the scope is only going
>      administrative domain can include transport over other networks in the
> (5) Take a look at the EID definition to consider whether references to "on
>      Likewise for EID-internal structure that is "not visible to the global
>      routing system"
>
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > present form, for advancement to the Standards-Track.  While some of my
> > > draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and
> the
> > > goal.  However, since that does not seem to be reflected in the current
> The downgrade attacks will probably require some further analysis; LISP-SEC
> > >        globally visible IP addresses.  Note that there MAY be transient
> > > unimplementable, in which case it would seem that the architecture as a
> > > There are some fairly subtle ordering requirements between the order of
> > > entries in Map-Reply messages and the Locator-Status-Bits in data-plane
> > > need for synchronization in interpreting these bits should be mentioned
> > > synchronization within a site should be clearly called out, ideally in
> a
> > > single location.
>
> > > threat-analysis in RFC 7835, which does not really seem like a complete
> > > placed on the boundaries between the different components of LISP (data
> > > The security considerations throughout the LISP documents place a heavy
> > > focus on the risk of over-claiming for routing EID-prefixes.  This is a
> > > stronger requirements.  (I did not do a full analysis of the system in
> the
> > > I apologize for the somewhat scattered nature of these comments; there
> are
> > > broader system, and the intended security posture, so they did not get
> as
> > > much clean-up as I would have liked.  (Most of my review was performed
> on the
> > > 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
> > > This doesn't seem like a 2119 MAY is necessary, but rather a statement
> of
> > >        Specifically, when a service provider prepends a LISP header for
> > >        on the outer destination address (the originating ITR's supplied
> > > headers on the packet?  Is the "outer RLOC the ISP ITR uses" the source
> > >     Negative Mapping Entry:   A negative mapping entry, also known as a
> > >        is advertised or stored with no RLOCs.  That is, the Locator-Set
> > >     would be either a TE-ETR within the ISP (along an intra-ISP traffic
> > >        check is also performed when doing initial encapsulation, when a
> > >        copied from the outer-header DSCP field ('Traffic Class' field,
> in
> > >     packets or EID-to-RLOC Map-Request messages.  A "gleaned" Map-Cache
> > >     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
> > > instead of passing it on to the EID that won't know what to do with it?
> > >
> > > might benefit from an explicit section reference to the other document.
> > >
> > > Section 10
> > >
> > >     per EID-Prefix.  Therefore, when a Locator becomes unreachable, the
> > > is whether the peer supports the echo-nonce algorithm.  (Also, subject
> to
> > > downgrade.)
> > >
> > > Section 13
> > >
> > >     When a Locator record is removed from a Locator-Set, ITRs that have
> > >     for a site registering to it will be synchronized according to Map-
> > >     Version Number.
> > >
> > >     o  Data-Plane gleaning for creating map-cache entries has been made

---

From: Joel Halpern <[email-masked]>
Date: Mon, 1 Oct 2018 15:08:25 -0400

[Alberto usefully suggested I resend this with a clearer subject line, 
so folks notice it.  So I am doing so.  There is no need to answer 
twice.  Just answer one of the two email requests.  Please.]

Yours,
Joel