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

["Joel M. Halpern" <[e-mail]>]

Thank you Benjamin.  This response helps me understand the situation.
I have sent a note to the WG about making LISP-SEC MTI.  That kind of 
change needs WG support.

Yours,
Joel

On 9/28/18 6:03 PM, Benjamin Kaduk wrote:
> 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?
>>>
>>>
>>>
>