Ballot for draft-ietf-lisp-rfc6830bis
Discuss
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
[[ nits ]] [ section 12 ] * "When the inner header is IPv6 then the flow label is not zero, it MAY be used to compute the hash." Perhaps: * "When the inner header is IPv6 and the flow label is not zero, it MAY be used when computing the hash."
I support Roman's DISCUSS specifically with respect to Section 16. I also support Martin's and Roman's DISCUSSes with respect to being explicit about what's safe for use on the public Internet.
Thank you for being responsive to the prior security feedback from the SECDIR (and thanks to Kyle Rose for performing it) and Security ADs in the return of this document to the telechat. I support Martin Duke’s DISCUSS position and endorse the creation of a dedicated section covering which protocol features should not be used on the internet. Thanks for addressing my other DISCUSS and COMMENTS points. This ballot is now pruned down to the remaining issues under discussion.
Thank you for considering and addressing my DISCUSS concerns.
Thank you for the work put into this document. This is really useful work and the document is easy to read. I also appreciate the way the document handles IPv6 and IPv4 at the same level. Selecting the UDP source port for ECMP based on the inner 5-tuple is smart . Please find below a couple of non-blocking COMMENTs. I also support Martin Duke's DISCUSS on ICMP. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I find the use of "prepending a LISP header" unusual. Why not using the word "encapsulating" in a LISP packet? Or did I miss something? It may also slightly be confusing when parts of the text use "prepending" and others use "encapsulating". -- Section 3 -- In "Egress Tunnel Router (ETR): ", is it required to be a 'server' to be able to do "A server host can be the endpoint of a LISP tunnel as well.". I would assume that any host can do it as well. In "Ingress Tunnel Router (ITR):" per symmetry with ETR, can a server/client host also be the encapsulating endpoint of a LISP tunnel? -- Section 4 -- I STRONGLY suggest to remove the "telnet" example and keep only "SSH". Cosmetic: suggest to add reference to SSH, BGP, SNMP, ... -- Section 5.3 -- For "outer header", there is specific text for the IPv4 DF-bit, DSCP, ... but what about specific IPv6 fields such as "flow label"? Beside the convenience of making a bis document reflecting the original, defining the "R" bit as reserved when at the same IESG telechat there is the GPE document is really a missed opportunity IMHO. Side comment (no need to reply), I am also puzzled why the outer DSCP is copied to the inner DSCP on decapsulation. -- Section 10 -- Is it on purpose that IPv6 is ignored in "This is typically done when a /32 address is configured on a loopback interface." ? -- Section 12 -- What is meant by "flow" in "The Source port SHOULD be the same for all packets belonging to the same flow." Probably worth defining it as packets with identical 5-tuple ? I also suggest not to limit the load-balancing text to LAG but also to any topology where ECMP occurs. Is there a reason why the hashing for LAG/load balancing is under the title of "Routing Locator Hashing"? The UDP source port selection is vaguely related but different than RLOC hashing. -- Section 15 -- Unsure whether this performance section is still relevant in 2020, there are many similar overlay techniques. == NITS == -- Section 1 -- There are some repetitions in this section such as "[I-D.ietf-lisp-rfc6833bis] specifies the LISP control plane. " -- Section 3 -- When defining "anycast", I find that "An EID or RLOC can be an anycast address in each of their own address spaces." is more a property of EID/RLOC than adding anything to "anycast".
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3126 See my DISCUSS on 6833bis for overall issues. This is just detailed issues on 6830bis as I went through it. DETAIL 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. 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. 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. 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. 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?
I have a couple of smaller discuss points with should be straight-forward to address and one more high-level discussion point that might not have a solution (depending on the deployment status of LISP I guess) but I would like to at least have a discussion. I start with the straight-forward onces: 1) Unfortunately ECN decapsulation is slightly more complicated than described in section 5.3. Please check section 3.2 in rfc6040 and revise accordingly (maybe also provide a pointer to rfc6040 instead or in addition to rfc3168)! (Also it seems like the text on ECN is simply just twice in sec 5.3; not sure that is helpful). 2) Further, also in sec 5.3: "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) considering the exception listed below." However, I didn't find any exceptions listed later in the doc. However, setting the DSCP field might also be matter of local policy. E.g. if DSCP is not used for a different purpose in the receiver side LISP network, it could make sense to restore/keep the original value in the inner header. 3) Sec 7.1. only takes about ICMPv6 "Packet Too Big" packets while "IPv4-encapsulated packet with the DF bit set to 1" should be addressed as well. 4) I would like to see another sentence in section 12 explicitly stating that the source port SHOULD be the same for all packet belong to the same flow. 5) Sec 5.3 says "Both N- and V-bits MUST NOT be set in the same packet." What happens if both bits are set? The 'Nonce/Map-Version' is just ignored, or maybe the packet should be dropped or something? Please clarify in the doc! 6) And now the more-discussion-needed point: So my underlying concern is the same as brought up by the TSV-ART review that lisp information are not end-to-end integrity protected or authenticated. However, while briefly thinking about how this could be eventually realized, I noticed that there is actually no mechanism to extend the LISP header in any way. There is no version, no option and the LISP header seems to have a fixed, implicitly specified length without an explicit length field. This seems too late to add any kind of extensibility mechanism at this stage of the protocols lifetime, however, I would still like to discuss if there was any discussion about extensibility, what was the reason to chose this approach, and potential if some background about the choice should be given in the doc.
I share many of the security related concerns raised by Benjamin. The document is otherwise readable. I have one specific question: 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the Map-Cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. Ok, maybe this is just me, but you don't actually define how to hash these things, you are only talking about what needs to be covered by the hash. I appreciate that picking a specific hashing algorithm is probably not relevant for interoperability, but I feel adding a specific algorithm (as an example or via a pointer) would improve the document.
I support Roman's first two DISCUSS points.
Thanks for the work on this document! I have some relatively minor comments/nits: (1) §18: s/RFC8060/RFC8061 (2) §1: "Finally, [I-D.ietf-lisp-introduction] describes the LISP architecture." First of all, it would seem to me that the Architecture should be a Normative reference...but I-D.ietf-lisp-introduction says that it "is used for introductory purposes, more details can be found in RFC6830, the protocol specification." This document obsoletes rfc6830...so it seems to me that there is a failed circular dependency. (3) References to rfc2119/rfc8174 and rfc8126 should be Normative.
I support the Security ADs DISCUSS positions. (I was unfortunately not able to do more than a cursory review due to external time constraints.)
Thanks for addressing my previous Discuss points. I have some notes locally for an analysis of the security considerations at the boundaries of the various components in the ecosystem, and hope to have some text soon. That said, I'm balloting No Objection now anyway, to make my other comments (from a fresh reread of the document) available now. Section 1 LISP is an overlay protocol that separates control from Data-Plane, this document specifies the Data-Plane as well as how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. [...] nit: comma splice Section 3 EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. nit(?): this definition might be artifically narrow. E.g., there might be other cases when a prefix can be broken up, including when different RLOC sets are to be assigned to sub-blocks of the larger EID-Prefix. End-System: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating outside of its routing domain. An end- Just to check: when would an end-system supply a destination address that is not an EID (i.e., what requires the "when communicating outside of its routing domain" caveat)? (This is in a mindset that assumes for non-LISP systems the EID and RLOC collapse to the same value usable as either EID or RLOC depending on context.) Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to zero or more RLOCs. Typically, RLOCs are numbered from blocks that are assigned to a site at each point to which it attaches to the underlay network; where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned nit: the bit after the semicolon is not a complete sentence; probably just replacing it with a comma is best. Section 4 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 destination RLOC it uses for the new nit: "Recursive Tunneling" is a defined term now, so we don't need quite as much of an in-band definition. Perhaps "in such a Recursive Tunneling situation". Section 4.1 Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. It might be worth a bit more detail on how the one xTR influences the decision of the other. Section 5.3 LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to nit: s/also// ? Section 6 The Map-Cache is a local cache of mappings, entries are expired based on the associated Time to live. [...] nit: comma splice Section 7.1 When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the This seems to be the only indication that the mechanism described in this subsection is an IPv4-only mechanism; it's probably worth being a little more clear and up-front about that. Section 9 corresponding to the EID's topological location. Each RLOC in the Locator-Set is associated with a 'Priority' and 'Weight', this information is used to select the RLOC to encapsulate. nit: comma splice. Section 10 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is 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. Since we said earlier that LSBs are "a hint to convey up/down router status and not path reachability status", so I'd suggest rephrasing this in terms of "use this status information to avoid selecting routers that are down". When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: Similarly, we might clarify that this "reachability for all ETRs at the site" reflects local reachability from the ITR in question, and may not be indicative of reachability from the ETR receiving the LSBs. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. "/32 address" seems IPv4-specific. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. It might be worth a forward-reference to § 13.2 to mention that, in line with map versioning, the ITRs at the site already need to know the Map-Reply contents and to also note that, per Section 5.5 of 6833bis, the list of locators is sorted in a specific order. Section 10.1 When data flows bidirectionally between Locators from different sites, a Data-Plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. I do note the title of RFC 4086 and the resulting implication, but since a generic "nonce" is just a "number used once" and can in such cases be a simple counter, I think we really need to say "random nonce" (or "selected from a uniform random distribution" or similar), since we do rely on the unpredictability inherent in a random nonce. For reference, 6833bis says "[t]he nonce MUST be generated by a properly seeded pseudo-random source, see as an example [RFC4086]." The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. draft-ietf-tcpm-rto-consider, also on this week's telechat, might be an interesting reference here. 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 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 Map-Reply message. Do we want a corresponding "SHOULD NOT set the E-bit when [...]" here? Also, this could be a good place to note that the Map-Reply E-bit is spoofable in the absence of LISP-SEC. Many implementations default to not advertising they are echo-nonce capable in Map-Reply messages and so RLOC-probing tends to be used for RLOC reachability. Do we want to hedge this with an "at the time of this writing" in case it ages badly? Section 13 which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. nit: missing word (maybe s/need/there remains a need/?) Section 13.1 or down). The specific value for the 'use-LSB' timer depends on the LISP deployment, the 'use-LSB' timer needs to be large enough for the destination xTR to retreive the updated EID-to-RLOC mappings. A nit: comma splice. Section 16 For example of such attacks, an off-path attacker can exploit the echo-nonce mechanism by sending data packets to an ITR with a random nonce from an ETR's spoofed RLOC. Note the attacker must guess a valid nonce the ITR is requesting to be echoed within a small window of time. [...] I suggest noting that "the nonce echoing mechanism defined in this document has only a 24-bit nonce, which is small enough that randomly guessing a nonce will succeed with some regularity". That would also give an opportunity to mention the idea, introduced in lisp-gpe, that a dedicated shim header could be used to provide a longer nonce that is strong enough to be reliable for route-returnability checks (though I concede it's a bit far afield since it's a reference to a reference to future work). 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. I'd suggest adding at the end ", or prevent updates from being processed". LISP implementations and deployments which permit outer header fragments of IPv6 LISP encapsulated packets as a means of dealing with MTU issues should also use implementation techniques in ETRs to prevent this from being a DoS attack vector. Limits on the number of fragments awaiting reassembly at an ETR, RTR, or PETR, and the rate of admitting such fragments may be used. I note that draft-ietf-intarea-frag-fragile might be a relevant reference (and is in the RFC Editor's queue). Section 20.1 How can RFC 6830 be a normative reference when this document Obsoletes it? It's not really clear that RFCs 6831 or 8378 need to be normative; we mostly just mention that they exist but don't require implementing or using them. Section 20.2 In addition to what idnits picked up, I note that RFC 1918 is only referenced from the changelog entry saying that it's not referenced anymore :) I could see an argument that RFC 6936 should be normative, but defer to my TSV-area colleagues. I'm slightly surprised to see that Mirja did not insist upon RFC 8085 being a normative reference.
As a (mostly happy) user of the specified technology for a proof that it works I am inclined to ballot a YES. For practical purposes it is not expected that LISP will be deployed globally end to end, it is a localized mechanism for (mostly) controlled environments. This, however, does not mean that security concerns raised are to be ignored, therefore I do have sympathy for DISCUSSes raised by SEC ADs. The industry needs to continue experimenting with LISP, trying to build it ideal at the first try is not realistic. Therefore NO OBJECTION.
Thank you for addressing my DISCUSS. Old Comment: Sec 5.3. In the DSCP discussion, please add an information reference to RFC 2983, which provides guidance for DSCP and tunneling. It is not quite as simple as simply always copying DSCP to the outer packet. Sec 9. I don't understand what this sentence means: "The value of the 'Weight' represents the relative weight of the total packets that match the maping entry." (s/maping/mapping, obviously) What is the "relative weight" of packets? Is this the number of packets, the cumulative number of bytes, or something else? Sec 16. "If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim's RLOC, potentially overloading it." This not the only problem. The attacker could also DoS by directing traffic to an unreachable RLOC.
Given that this document is an update to an existing RFC and has already been through one IESG ballot, I have not read the entirety of this draft in detail. A couple of minor comments: 8. Using Virtualization and Segmentation with LISP For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. Standard 802.1Q VLAN identifiers are only 12 bits (unless an I-SID is being used), so possibly you might want to slightly elaborate here. E.g. do you potentially mean a pair of 802.1Q VLAN tags? 17. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. Given that SNMP is on its way out, having an informative reference to the work-in-progress LISP YANG model may be helpful here. Regards, Rob
Thanks for addressing my DISCUSS.