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

[Dino Farinacci <[e-mail]>]

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