Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
** Section 1.1. The applicability statement of “large set of cooperating entities seeking to communicate over the public Internet or other large underlay IP infrastructures” seems inconsistent with many of the protocol mechanics described. Specifically, most of the capabilities in the LISP header (Locator-Status-Bits, Echo-nonce mechanism, Map-Versioning, Instance ID) and the “Gleaning mechanism” are explicitly noted as not being suitable for Internet use. This section needs to be explicit that only a subset of the protocol is suitable for the Internet. Likewise, it should be clearer about what is assumed elements of the closed network are trusted for what particular behaviors. ** Section 16. Per “Locator-Status-Bits, echo-nonce and map-versioning SHOULD NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments” -- not disagreement. However, under what circumstances would they be used on the internet to warrant a SHOULD NOT instead of a stronger MUST NOT? ** Section 8. Per “Participants within a LISP deployment must agree on the meaning of Instance ID values. The source and destination EIDs MUST belong to the same Instance ID.” Could parties agree that the Instance ID is 802.1Q tags and send those across the internet? Recommend stronger cautionary language on using Instance ID.
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. ** Section 4.0. Per “… this document recommends that a maximum of two LISP headers …”, should a normative RECOMMENDED be used here instead? ** Section 5.3. Per “However, the same nonce can be used for a period of time when encapsulating to the same ETR.”, should this be bounded, even qualitatively? ** Section 9. A "gleaned" Map-Cache entry 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. -- Is there any more precision that could be provided about the cache lifetime beyond “a few seconds” -- Should normative language be provided that this cache should be aged and verification performed? ** Editorial Nit -- Section 13.2. Typo s/synzhronization/ synchronization/
Having read this document front to back for the first time, I found it quite hard to figure out what can actually safely done over the public internet, and what can be only be done in trusted environments. I realize that this is probably because the no-internet provisions entered late in the game. If it were my document, I might reorganize it to make the distinction more clear (i.e. present the internet-safe dataplane spec and then have additional sections about insecure add-ons). That said, at this stage in the game I'd be happy to have a new section that clarified what is what. For example (assuming I'm reading it correctly, which is my point) NEW: " Section 4 and a half. Deployment on the Public Internet Many of the mechanisms in this document are intended for deployment in controlled, trusted environments, and are insecure for use over the public internet. In particular, on the public internet xTRs: * SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero; * SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9); * SHOULD NOT use any data plane methods described in Section 10 for Routing Locator Reachability, instead relying solely on control plane methods; * SHOULD NOT use any data plane methods described in Section 13 to update the EID-to-RLOC mapping, instead relying solely on control plane methods. " END Perhaps my text is inaccurate, but something to that effect would be very helpful. Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are zero? Sec 7.2 The stateful MTU design does not incorporate any security measures against ICMP spoofing. At the very least, the ITR needs to make sure that some fields in the outer IP and UDP headers are hard to guess, and that this information is stored to verify that the ICMP message came from on-path. If this is not possible, the design is not safe to use over IPv4. If hard-to-guess information is not available to be stored deeper in the packet, then it is not safe over IPv6 either. Sec 7.2 There is a fourth situation which can arise. If the ETR receives an ICMP packet from an EID in its network. I have a couple of questions about what should happen in this case: - How is this communicated to the sender of the flow that triggered the message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source EID, both, or neither? - Is the ETR responsible for enforcing the MTU to that EID for subsequent flows? Sec 9. I don't understand what this sentence means: "The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic." This would appear to be the inverse of the "Routing Locator Hashing" discussion in Section 12, which provides a technique for switching destination RLOC. Is this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e. each flow uses only one source RLOC)? If not, would this involve potentially sending packets for one flow on different interfaces with different path characteristics, causing packet reordering. Or perhaps you mean each packet is sent from the same interface with a spoofed source RLOC, which creates interesting issues for ICMP returns and the like.
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.
[ section 8 ] * I think the currently architecture of IPv6 is such that at a minimum this doc should say that instances SHOULD NOT be used when the inner traffic is IPv6 as overlapping IPv6 prefixes are best and fairly easily avoided and folks should be encouraged to avoid recreating some of the limitations that were unavoidable in IPv4. [ section 12 ] * When the outer header is IPv6, the flow label may also be set a la RFC 6438. * When the inner header is IPv6, the flow label may also be a factor in the hashing (6348, if the flow label is non-zero a la 6437). [ section 16 ] * Is it worth adding an extra warning about gleaning mappings for EIDs that the ETR would otherwise have routed internally via the IGP? * In addition to basic uRPF, can an ETR do LISP-specific uRPF, i.e. look up the source EID in the mapping system and check that the source RLOC is within the set returned? If so, the document might mention it. If not, it might be good state explicitly that LISP does not afford this kind of uRPF check.
[ section 4.1 ] * Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. Suggest: Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly as it would if the site was not was not using LISP. * (6) "Subsequent packets"? Can you say here what happens to the first packet that caused the mapping lookup to happen? Ah, I see it's in section 6... Up to you if you want drop a forward reference here to that. [ section 7.x ] * Still another options is for the tunnel to generate fragments at the outer header layer. Even though may not be standard or recommended practice, a few words saying why this shouldn't be considered seems good; recommend pointing to https://tools.ietf.org/html/rfc4459#section-3.1 for a summary of the badness. [ section 9 ] * "multiple RLOC" -> "multiple RLOCs"
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.
1) In sec 7.1 I would recommend to provide a pointer to RFC4459 and align the language to more what RFC4459 recommends: OLD "This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0." MAYBE: "This behavior MAY be performed by the ITR only when the source host originates a packet with the 'DF' field of the IP header set to 0. 2) Sec 4: "...this document recommends that a maximum of two LISP headers can be prepended to a packet." MAYBE: "it is RECOMMENDED that a maximum of two LISP headers can be prepended to a packet." ?
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?
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. 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.... 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? 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? 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?
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.
I support the Security ADs DISCUSS positions. (I was unfortunately not able to do more than a cursory review due to external time constraints.)
I support Roman's first two DISCUSS points.
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.
Thanks for addressing my DISCUSS.
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 considering and addressing my DISCUSS concerns.
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.
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.
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".
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