--- 1/draft-ietf-roll-efficient-npdao-15.txt 2019-09-05 21:13:12.404896019 -0700 +++ 2/draft-ietf-roll-efficient-npdao-16.txt 2019-09-05 21:13:12.456897336 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: January 9, 2020 Cisco +Expires: March 8, 2020 Cisco R. Sahoo Z. Cao Huawei - July 8, 2019 + September 5, 2019 Efficient Route Invalidation - draft-ietf-roll-efficient-npdao-15 + draft-ietf-roll-efficient-npdao-16 Abstract This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 9, 2020. + This Internet-Draft will expire on March 8, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,41 +68,41 @@ previous parent . . . . . . . . . . . . . . . . . . . . . 6 3.2. Req#2: Dependent nodes route invalidation on parent switching . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Req#3: Route invalidation should not impact data traffic 7 4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7 4.2. Transit Information Option changes . . . . . . . . . . . 8 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 - 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 + 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 11 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 - 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 12 + 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 13 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 - 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 + 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 14 4.6.3. Considerations for DCO retry . . . . . . . . . . . . 14 4.6.4. DCO with multiple preferred parents . . . . . . . . . 15 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Registry for the Destination Cleanup Object (DCO) Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 - Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19 + Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 20 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20 A.2. Example DCO Messaging with multiple preferred parents . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction RPL [RFC6550] (Routing Protocol for Low power and lossy networks) specifies a proactive distance-vector based routing scheme. RPL has optional messaging in the form of DAO (Destination Advertisement Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo @@ -340,25 +340,26 @@ Every RPL message is divided into base message fields and additional Options as described in Section 6 of [RFC6550]. The base fields apply to the message as a whole and options are appended to add message/use-case specific attributes. As an example, a DAO message may be attributed by one or more "RPL Target" options which specify the reachability information for the given targets. Similarly, a Transit Information option may be associated with a set of RPL Target options. This document specifies a change in the Transit Information Option to - contain the "Invalidate previous route" (I) flag. This I-flag + contain the "Invalidate previous route" (I) flag. This 'I' flag signals the common ancestor node to generate a DCO on behalf of the - target node. The I-flag is carried in the Transit Information Option + target node with a RPL Status of 130 indicating that the address has + moved. The 'I' flag is carried in the Transit Information Option which augments the reachability information for a given set of RPL - Target(s). Transit Information Option with I-flag set should be + Target(s). Transit Information Option with 'I' flag set should be carried in the DAO message when route invalidation is sought for the corresponding target(s). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 | Option Length |E|I| Flags | Path Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Sequence | Path Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -368,38 +369,38 @@ I (Invalidate previous route) flag: The 'I' flag is set by the target node to indicate to the common ancestor node that it wishes to invalidate any previous route between the two paths. [RFC6550] allows the parent address to be sent in the Transit Information Option depending on the mode of operation. In case of storing mode of operation the field is usually not needed. In case of DCO, the parent address field MUST NOT be included. The common ancestor node SHOULD generate a DCO message in response to - this I-flag when it sees that the routing adjacencies have changed - for the target. The I-flag is intended to give the target node + this 'I' flag when it sees that the routing adjacencies have changed + for the target. The 'I' flag is intended to give the target node control over its own route invalidation, serving as a signal to request DCO generation. 4.3. Destination Cleanup Object (DCO) A new ICMPv6 RPL control message code is defined by this specification and is referred to as "Destination Cleanup Object" (DCO), which is used for proactive cleanup of state and routing information held on behalf of the target node by 6LRs. The DCO message always traverses downstream and cleans up route information and other state information associated with the given target. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | + | RPLInstanceID |K|D| Flags | RPL Status | DCOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... @@ -423,22 +424,27 @@ sender does not set the 'K' flag it is an indication that the sender does not expect a response, and the sender SHOULD NOT retry the DCO. D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: The 6 bits remaining unused in the Flags field are reserved for future use. These bits MUST be initialized to zero by the sender and MUST be ignored by the receiver. - Reserved: 8-bit unused field. The field MUST be initialized to zero - by the sender and MUST be ignored by the receiver. + RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550]. + Indicative of the reason why the DCO happened, the RPL Status MUST + NOT be changed as the DCO is propagated down the route being + invalidated. This value is informative and does not affect the + behavior of the receiver. In particular, unknown values are ignored + by the receiver. Only Rejection Codes (values of 128 and above) are + expected in a DCO. DCOSequence: 8-bit field incremented at each unique DCO message from a node and echoed in the DCO-ACK message. The initial DCOSequence can be chosen randomly by the node. Section 4.4 explains the handling of the DCOSequence. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present if 'D' flag is not set. DODAGID is used when a local RPLInstanceID is in use, in order to identify @@ -482,21 +488,21 @@ 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) The DCO-ACK message SHOULD be sent as a unicast packet by a DCO recipient in response to a unicast DCO message with 'K' flag set. If 'K' flag is not set then the receiver of the DCO message MAY send a DCO-ACK, especially to report an error condition. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RPLInstanceID |D| Flags | DCOSequence | Status | + | RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -507,29 +513,28 @@ D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from the DCOSequence received in the DCO message. - Status: Indicates the completion. Status 0 is defined as unqualified - acceptance in this specification. Status 1 is defined as "No - routing-entry for the Target found". The remaining status values are - reserved as rejection codes. + DCO-ACK Status: Indicates the completion. A value of 0 is defined as + unqualified acceptance in this specification. A value of 1 is + defined as "No routing-entry for the Target found". The remaining + status values are reserved as rejection codes. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present when 'D' flag is not set. - DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. 4.3.5. Secure DCO-ACK A Secure DCO-ACK message follows the format in [RFC6550] Figure 7, where the base message format is the DCO-ACK message shown in Figure 4. 4.4. DCO Base Rules @@ -589,29 +594,29 @@ 4.6. Other considerations 4.6.1. Dependent Nodes invalidation Current RPL [RFC6550] does not provide a mechanism for route invalidation for dependent nodes. This document allows the dependent nodes invalidation. Dependent nodes will generate their respective DAOs to update their paths, and the previous route invalidation for those nodes should work in the similar manner described for switching - node. The dependent node may set the I-flag in the Transit + node. The dependent node may set the 'I' flag in the Transit Information Option as part of regular DAO so as to request invalidation of previous route from the common ancestor node. Dependent nodes do not have any indication regarding if any of their parents in turn have decided to switch their parent. Thus for route invalidation the dependent nodes may choose to always set the 'I' flag in all its DAO message's Transit Information Option. Note that - setting the I-flag is not counterproductive even if there is no + setting the 'I' flag is not counterproductive even if there is no previous route to be invalidated. 4.6.2. NPDAO and DCO in the same network The current NPDAO mechanism in [RFC6550] can still be used in the same network where DCO is used. The NPDAO messaging can be used, for example, on route lifetime expiry of the target or when the node simply decides to gracefully terminate the RPL session on graceful node shutdown. Moreover, a deployment can have a mix of nodes supporting the DCO and the existing NPDAO mechanism. It is also @@ -730,21 +735,21 @@ | | | document | | TBD2 | Destination Cleanup Object Acknowledgment | This | | | | document | | TBD3 | Secure Destination Cleanup Object | This | | | | document | | TBD4 | Secure Destination Cleanup Object | This | | | Acknowledgment | document | +------+---------------------------------------------+--------------+ IANA is requested to allocate bit 1 from the Transit Information - Option Flags registry for the I-flag (Section 4.2) + Option Flags registry for the 'I' flag (Section 4.2) 6.1. New Registry for the Destination Cleanup Object (DCO) Flags IANA is requested to create a registry for the 8-bit Destination Cleanup Object (DCO) Flags field. This registry should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities: @@ -815,41 +820,47 @@ +------------+------------------------------+---------------+ | 0 | DODAGID field is present (D) | This document | +------------+------------------------------+---------------+ DCO-ACK Base Flags 7. Security Considerations This document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. The common ancestor - node could be directed to do so by the target node using the I-flag + node could be directed to do so by the target node using the 'I' flag in DCO's Transit Information Option. However, the common ancestor node is in a position to unilaterally initiate the route invalidation since it possesses all the required state information, namely, the Target address and the corresponding Path Sequence. Thus a rogue common ancestor node could initiate such an invalidation and impact the traffic to the target node. - This document also introduces an I-flag which is set by the target + The DCO carries a RPL Status value, which is informative. New Status + values may be created over time and a node will ignore an unknown + Status value. This enables RPL Status field to be used as a cover + channel. But the channel only works once since the message destroys + its own medium, that is the existing route that it is removing. + + This document also introduces an 'I' flag which is set by the target node and used by the ancestor node to initiate a DCO if the ancestor sees an update in the route adjacency. However, this flag could be spoofed by a malicious 6LR in the path and can cause invalidation of an existing active path. Note that invalidation will happen only if the other conditions such as Path Sequence condition is also met. Having said that, such a malicious 6LR may spoof a DAO on behalf of - the (sub) child with the I-flag set and can cause route invalidation - on behalf of the (sub) child node. Note that, using existing - mechanisms offered by [RFC6550], a malicious 6LR might also spoof a - DAO with lifetime of zero or otherwise cause denial of service by - dropping traffic entirely, so the new mechanism described in this - document does not present a substantially increased risk of + the (sub) child with the 'I' flag set and can cause route + invalidation on behalf of the (sub) child node. Note that, using + existing mechanisms offered by [RFC6550], a malicious 6LR might also + spoof a DAO with lifetime of zero or otherwise cause denial of + service by dropping traffic entirely, so the new mechanism described + in this document does not present a substantially increased risk of disruption. This document assumes that the security mechanisms as defined in [RFC6550] are followed, which means that the common ancestor node and all the 6LRs are part of the RPL network because they have the required credentials. A non-secure RPL network needs to take into consideration the risks highlighted in this section as well as those highlighted in [RFC6550]. All RPL messages support a secure version of messages which allows