Summary: Has 2 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
Per Section 11: [RFC2473] suggests that tunnel entry and exit points can be secured, via the "Use IPsec". The suggested solution has all the problems that [RFC5406] goes into. In an LLN such a solution would degenerate into every node having a tunnel with every other node. It would provide a small amount of origin address authentication at a very high cost; doing BCP38 at every node (linking layer-3 addresses to layer-2 addresses, and to already present layer-2 cryptographic mechanisms) would be cheaper should RPL be run in an environment where hostile nodes are likely to be a part of the LLN. ** I'm having trouble understanding what recommendation this text was making. The first sentence seems to suggest IPSec, the second sentence seems to discount that advice; and the third seems to suggest BCP38 as an alternative. Could you please clarify. ** Please be explicit on which challenges in RFC5406 are being cited (e.g., which sections)
(1) Abstract. Per “Additionally, this document updates RFC 6550 to indicate about this change …”, this sentence didn’t parse for me in explaining the relationship with RFC6550. (2) Section 1. Typo. s/implementors/implementers/ (3) Section 2. Editorial Nit. s/header refers to:/header refers to/ (4) Section 3. A few editorial comments on how these updates are presented: ** Inconsistent spacing in Section 3 title: s/Updates to RFC6553, RFC6550 and RFC 8138/ Updates to RFC6553, RFC6550 and RFC8138/ ** Section 3.1 and Section 3.3 open with the motivation for the change. Section 3.2 does not. ** Section 3.3 title describes the proposed change. Section 3.1 and 3.2 simple state “Updates to RFCxxx” ** Section 3.1 – 3 titles include a space in the RFC names (i.e., RFC-space-number). The Section 3 title does not. (5) Section 3.1. Editorial Nit. ** s/[RFC6553] states as shown below/[RFC6553] states as shown in Figure 1/ ** Recommend citing the relevant page and section number from RFC6553 too. (6) Section 3.2. Please use more explicit language to describe how this section updates RFC8138. (7) Section 3.2. Figure 3 is depicted in this section but not referenced in the text. (8) Section 4. Typo. s/A RPL Stack is shown in Figure 5/A RPL Stack is shown in Figure 6/ (9) Section 5. Editorial Nit. s/these nodes are/These nodes are/ (10) Section 5. A few editorial recommendations for this paragraph: The uses cases describe the communication between RPL-aware-nodes, with the root (6LBR), and with Internet. This document also describe the communication between nodes acting as leaves that do not understand RPL, but are part of the LLN. these nodes are named as not-RPL-aware-leaf, mentioned previously. (e.g. Section 6.1.4 Flow from not-RPL-aware-leaf to root) This document describes also how is the communication inside of the LLN when it has the final destination addressed outside of the LLN e.g. with destination to Internet. (e.g. Section 6.2.3 Flow from not-RPL-aware-leaf to Internet) ** s/these nodes are/These nodes are/ ** The sentence “This document describes also how …” doesn’t parse. ** The use of “(e.g. …)” as a standalone sentence doesn’t parse. (11) Section 5. Per “There is some possible security risk when the RPI information is released on the internet …”, I recommend reframing this text around the fact that the leak of RPI info would not present an issue. As is, the impact reads ambiguously to me. (12) Section 6. The meaning of “root” in Figure 7 is not explained in the text above it. (13) Section 6.1.4. Typo. s/encapsuladed/encapsulated/ (14) Section 9. Editorial Nit. s/ During bootstrapping the node get the DIO with the information of RPL Option Type/ During bootstrapping the node gets the DIO with the information of RPL Option Type/ (15) Section 11. Make BCP38 a reference (i.e., [BCP38])
There are several internal inconsistencies that needs to be resolved before publication, specifically for: (1) the destination address of the IPv6-in-IPv6 tunnel used for flows from the Internet to a ~Raf -- Section 6.2.4 says addressed to the ~Raf, but Figure 7 says "hop". (2) the destination address of the IPv6-in-IPv6 tunnel used for flows from a ~Raf to a ~Raf -- Section 6.3.4 says addressed to the ~Raf, but Figure 7 says "hop" (3) Table 14 says "(opt: RPI)" which, though not defined, I take to mean as indicating that the insertion of the RPI is optional, but the body text in Section 7.1.2 is unconditional that the 6LBR inserts an RPI header (4) Section 7.2.1 does not mention adding v6-in-v6 encapsulation, but Figure 8 has a "must" in that column. (5) Section 7.3.1 only has descriptive text that "[t]he originating node should put the RPI into an IPv6-in-IPv6 header", but Figure 8 lists this behavior as "must" (though there would also be a second v6-in-v6 encapsulationi from root to destination, which is clearly a must). (Note that Section 7.3.2 covers essentially the same flow, but uses "which must be in an IPv6-in-IPv6 header addressed to the root".) (6) In Section 5, we say that the DODAG root "SHOULD force [rank information] to zero" but then that "[t]he Internet will therefore not see any SenderRank information", and a SHOULD-level requirement is not enough to guarantee this statement as fact. Additionally, there are some terminology inconsistencies in Figures 7 and 8 that need to be cleaned up or explained. For example, in Figure 7, what is the difference between "Yes" and "must" in the "IPv6-in-IPv6" column, and in the "v6-in-v6 dst" column, what does "root" mean? In Figure 8, what does "Opt" mean in the "RPI" column?
Section 1 An interim meeting went through the 24 cases defined here to discover if there were any shortcuts, and this document is the result of that discussion. This document clarifies examples that intend to illustrate the result of the normative language in RFC8200 and RFC6553. In other words, the examples are intended to be normative explanation of the results of executing that language. I agree with the GenART reviewer that this language is hard to parse into useful expectations, and I'm not sure that the suggestion in https://mailarchive.ietf.org/arch/msg/gen-art/FnrfXDQ4ZmGniUpa2y-qKA6bkOg helps very much. In particular, what does it mean for an example to be a "normative explanation"? Section 2 As noted by the rtgdir reviewer, the volume of new terminology introduced is rather extensive, and hard for a newcomer to overcome. Flag Day: A transition that involves having a network with different values of RPL Option Type. Thus the network does not work correctly. This does not match up with what I understood the colloquial definition of "flag day" to be (i.e., the specific act of cutting over from old to new, designed to minimize the duration of the transient period when the network does not work correctly, with extensive planning and coordination needed to effectuate a scheduled, as opposed to rolling, cutover). It seems that the later usage of the term "flag day" in this document is internally consistent with the definition here, at least. Hop-by-hop IPv6-in-IPv6 headers: The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header that originates from a node to an adjacent node, using the addresses (usually the GUA or ULA, but could use the link-local addresses) of each node. If the packet must traverse multiple hops, then it must be decapsulated at each hop, and then re-encapsulated again in a similar fashion. I'm not seeing where in the description the "IPv6-in-IPv6" nature is used -- couldn't this description equally apply to regular hop-by-hop IPv6 headers? Is the distinction that the added header is specifically on the *inner* IPv6 representation? Section 3.1 Based on that, if an IPv6 (intermediate) node (RPL-not-capable) receives a packet with an RPL Option, it should ignore the HBH RPL option (skip over this option and continue processing the header). This is relevant, as it was mentioned previously, in the case that there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). Thus, this document updates the Option Type field to: the two high order bits MUST be set to '00' and the third bit is equal to '1'. I am not sure that the "Thus" is appropriate -- as the secdir reviewer notes, the logical connection is a bit tenuous, and the main connection here seems to just be that 8200 endorses the concept of skipping over some things, which gives us cover to use an option type that is skippable. But I'm probably misunderstanding here, and would welcome an explanation of the nature of my confusion. The non-storing mode case does not require the type change from 0x63 to 0x23, as the root can always create the right packet. The type change does not adversely affect the non-storing case. This section doesn't seem to explicitly call out the storing case for special discussion. Is there anything useful to say about it? Section 3.2 The node will know which to use based upon the presence of the DODAG Configuration Option described in the next section. [...] nit: is it the mere *presence* of the DODAG Configuration Option, or the information contained therein, that is relevant for this decision? There are potential significant advantages to having a single code path that always processes IPv6-in-IPv6 headers with no options. nit(?): There seems to be potential ambiguity about whether "no options" means "no IPv6 options" or "no conditional branches in the processing flow". I'm also not entirely sure how this sentence is supposed to tie in to the rest of the section. Figure 3 is pretty sparsely annotated. Section 4 In Figure 5, why does the line from D to B have an arrowhead but none of the other lines do? Section 5 NOTE: There is some possible security risk when the RPI information is released to the Internet. At this point this is a theoretical situation; no clear attack has been described. At worst, it is clear that the RPI option would waste some network bandwidth when it escapes. This is traded off against the savings in the LLN by not having to encapsulate the packet in order to remove the artifact. The risk seems open-ended given the potential for sub-TLVs in the RPI. Where would a potential author of a new sub-TLV look to get guidance on the potential security risks from having the sub-TLV contents released to the internet? Is there something useful we could add via this document? Also, I agree with the secdir reviewer that "at worst" should be "at a minimum". Despite being legal to leave the RPI artifact in place, an intermediate router that needs to add an extension header (RH3 or RPI Option) MUST still encapsulate the packet in an (additional) outer IP header. The new header is placed after this new outer IP header. I didn't think that "RH3 or RPI Option" was an exhaustive list, and isn't this duplicating a requirement from another specification anyway? (That is, the "MUST" is probably not appropriate.) RPI MUST be present in every single RPL data packet. There is one exception in non-storing mode: when a packet is going down from the root the RPI MAY be omitted. The rational is that in a downward non- This "MUST be present [...] one exception" is not a great way to phrase things. Collapsing into the same sentence with a comma "MUST be present [...], with one execption: [...]" would help some, but it may even be possible to use descriptive rather than normative language. nit: s/rational/rationale/ Section 6 The following table (Figure 7) itemizes which headers are needed in each of the following scenarios. It indicate if an IPv6-in-IPv6 header must be inserted, and whether the destination address of the IPv6-in-IPv6 header is the next hop, or the final target address. There are these possible situations: hop-by-hop necessary (indicated by "hop"), or final target address possible (indicated by "tgt"). In all cases hop by hop may be used rather than the final target address. nit: we could probably make a stronger rhetorical connection betweeen "the destination address is the next hop" and "hop-by-hop necessary" -- these tables are pretty complicated as-is, so every bit helps! In each case, 6LR_i are the intermediate routers from source to destination. "1 <= i <= n", n is the number of routers (6LR) that the packet go through from source (6LN) to destination. nit: singular/plural mismatch with "packet" and "go through" Section 6.1.1 For example, a communication flow could be: Node F --> Node E --> Node B --> Node A root(6LBR) I think maybe a directorate reviewer already noted, but it seems that node D was intended rather than node E. Section 6.2.2 Should we say what the IPv6-in-IPv6 destination address is set to in this case? Section 6.2.3 Why does the 6LBR not remove headers in the the IPv6-in-IPv6(RPI)(2) case? Section 6.2.4 I'm not sure how to interpret the Table. Does the IPv6 node remove the RPI or ignore it? Section 6.3.1 While the 6LR nodes will update the RPI, no node needs to add or remove the RPI, so no IPv6-in-IPv6 headers are necessary. This may be done regardless of where the destination is, as the included RPI will be ignored by the receiver. I'm not sure what variation in the receiver location this is supposed to allow, given that we have already specified it to be a Raf in the same RPL Domain. Section 6.3.4 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LR_id --> not- RPL-aware 6LN (IPv6 dst) Is the root considered to be a 6LR_ia or a 6LR_id? Note that this flow is identical to Section 6.3.3, except for where the IPv6-in-IPv6 header is inserted. I'm still not seeing a difference in where the IPv6-in-IPv6 header is inserted. Section 7 The following table (Figure 8) summarizes what headers are needed in the following scenarios, and indicates when the RPI, RH3 and IPv6-in- IPv6 header are to be inserted. There are these possible situations: target destination address possible (indicated by "tgt"), to a 6LR, to a 6LN or to the root. In cases where no IPv6-in-IPv6 header is needed, the column states as "No". "There are these possible situations" seems overly broad; if I understand correctly, it is discussing only the last ("v6-in-v6 dst") column's possible values. Is the "to a 6LR" case always going to be "the last 6LR before the 6LN or 6LBR"? It may be worth a few words to clarify that. The leaf can be a router 6LR or a host, both indicated as 6LN (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], where the instanceID portion of the RPI header may still be needed to pick an appropriate priority or channel at each hop. This wording seems to imply that it is possible to cherry-pick just the instanceID portion of the RPI header without (e.g.) the SenderRank, which does not match my understanding of what is possible. Perhaps "where the RPI header may still be needed for the instanceID to be available for priority/channel selection at each hop" is better wording? Section 7.1.2 The destination is known to RPL-aware because, the root knows the whole topology in non-storing mode. nits: "to be", and no comma is needed. Section 7.1.3 I think I would prefer if the body text mentioned that an RPI is optionally added (for the 6tisch case where the instanceID is needed). I'm not sure that I understand why the RPI is marked as being modified by the 6LR_i in this case but not in Section 7.1.2. Table 15 should probably keep the parentheses around "(opt: RPI)" in the column for the ~Raf. Section 7.2.4 It seems that Table 20 could coalesce the 6LR_1 column into the 6LR_i column, and instead break out a 6LR_n column as is done in (e.g.) Section 7.1.3. Section 7.3.1 The conventions established previously in this document would seem to have us include the "IPv6-in-IPV6()" indicator in the "Modified headers" row. Section 7.3.2 I think the Table 22 column header is better as 6LR_ia than 6LR_1. It would be nice to be able to distinguish the generic 6LR_id and 6LR_m cases, but I'm not sure if there's enough horizontal space for that. Some textual discussion in the Table legend would be very helpful, though. Section 7.3.3 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN Is there a separate 6LR_1 step to be mentioned here? It's unclear if there's enough room for it in Table 23, but presumably the generic 6LR_ia are modifying the IPv6-in-IPv6(RPI_1) headers? Section 7.3.4 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6 dst) Are there separate 6LR_1 and 6LR_m steps to mention here? As for 7.3.3, Table 24 seems to be missing some columns for intermediate 6LRs that merely modify the RPI headers, though I recognize space concerns. Section 8 The above case occurs whenever traffic originates from the outside the LLN (the "Internet" cases above), and non-storing mode is used. In non-storing mode, the RPL root knows the exact topology (as it must be create the RH3 header), and therefore knows what the 6LR prior to the leaf --- the 6LR_n. nit: "what the 6LR prior to the leaf is" or "which 6LR is immediately prior to the leaf" or similar Section 9 During bootstrapping the node get the DIO with the information of RPL Option Type, indicating the new RPI in the DODAG Configuration Option Flag. The DODAG root is in charge to configure the current network to the new value, through DIO messages and when all the nodes are set with the new value. [...] Perhaps a reminder of how "all the nodes are set with the new value" is detected by the root would be helpful. The migration path to the change from 0x63 to 0x23 in networks that accepts both values is changed when the DIO is sent with the flag indicating the new RPI value. Namely, it remains at 0x63 until it is nit: How is it the *migration path* that is changed when the DIO with flag is sent? That seems to be making the migration happen, but the path is the same as it ever was. Section 11 While a typical LLN may be a very poor origin for attack traffic (as the networks tend to be very slow, and the nodes often have very low duty cycles) given enough nodes, they could still have a significant impact, particularly if the attack was on another LLN! Additionally, I agree with the secdir reviewer that "target of the attack was another LLN!" (or similar) would be clearer. With the above precautions, an attack using IPv6-in-IPv6 tunnels will be by a node within the LLN on another node within the LLN. Such an nit: I'd suggest s/will be/can only be/ to emphasize the restrictive nature of the precautions. The RH3 header usage described here can be abused in equivalent ways with an IPv6-in-IPv6 header to add the needed RH3 header. As such, I don't think I understand what this is trying to say. What are the things that are equivalent? The RPI header, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different RPLInstanceID, perhaps one with a higher energy cost, for instance. It could also be that not all nodes are reachable in an LLN using the default instanceID, but a change of instanceID would permit an attacker to bypass such filtering. Like the RH3, a RPI header is to be inserted by the RPL root on traffic entering the LLN by first inserting an IPv6-in-IPv6 header. The attacker's RPI header therefore will not be seen by the network. Upon reaching the destination node the RPI header has no further meaning and is just skipped; the presence of a second RPI header will have no meaning to the end node as the packet has already been identified as being at it's final destination. This text does not really convince me that it considers the non-storing case where a packet is directed to a non-6LR-aware leaf, and the last 6LR removes the IPv6-in-IPv6 encapsulation prior to sending the packet on to the IPv6 node. Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an attack on another part of the LLN, while disguising the origin of the attack. The mechanism can even be abused to make it appear that the attack is coming from outside the LLN, and unless countered, this could be used to mount a Distributed Denial Of Service attack upon nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of such attacks already seen in the real world. It's not really clear to me that [DDOS-KREBS] is illustrative of IPv6-in-IPv6 spoofing from a LLN. If an attack comes from inside of LLN, it can be alleviated with SAVI (Source Address Validation Improvement) using [RFC8505] with [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source with nit: is "source with" a common term? an address that is not registered, and the registration checks for nit: "registration process"? topological correctness. Notice that there is an L2 authentication in most of the cases. If an attack comes from outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, but RH3 is protected by its definition. Protected from what? How? Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic through the RPL root to perform this attack. To counter, the RPL root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the simpler solution), or it SHOULD do a deep packet inspection wherein it walks the IP header extension chain until it can inspect the upper-layer-payload as described in [RFC7045]. In particular, the RFC 7045 does not use the term "deep packet inspection", that term has negative connotations for many people, and it's not entirely clear that it's the right term to describe the process of fully parsing the IPv6 headers, either.
= Section 1 = "An interim meeting went through the 24 cases defined here to discover if there were any shortcuts, and this document is the result of that discussion." These details seem unnecessary to include in an archival document. = Section 3.1 = "[RFCXXXX] represents this document." This is not necessary to include. = Section 9 = "Related to the deployment of RPL, there are no known multivendor deployments outside of the research groups! All known deployments of RPL are in market verticals, with a single vendor providing all components. Research groups typically are using Contiki, RiotOS, or OpenWSN, and these are easily adapted to 0x23 functionality." It seems like this text should be dropped or marked for removal once the RFC is published, since it will likely become out-of-date soon enough.
I strongly support Roman's DISCUSS - the scaling *seems* like it would end poorly, and I'm a bit confused about what exactly is being recommended. I'm not 100% sure I understand how the deployment will actually occur, and so perhaps the IPSEC scaling doesn't cause an issue?
I only did a quick read of this document but I would like to echo the TSV-ART review (Thanks Colin!) that a pointer to RFC6040 could be good in order to highlight support of ECN for any tunnelling solutions. Also there is draft-ietf-intarea-tunnels which could be a good pointer/read for this spec.
Thanks to everyone who worked on this document. I have only one minor comment. I'm a bit perplexed by the interplay between sections 3.1 and 3.3. Section 3.1 says: > This change creates a flag day for existing networks which are > currently using 0x63 as the RPI value. And then section 3.3 says: > In order to avoid a Flag Day caused by lack of interoperation between > new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag > in the DIO Configuration Option... Which leaves me wondering whether the net effect of this document does or does not create a flag day for networks. Please consider updating these sections to be consistent with each other.
The revised ID has fixed all my DISCUSS points. Thank you to the authors.