--- 1/draft-ietf-roll-turnon-rfc8138-11.txt 2020-09-02 07:13:41.032701312 -0700 +++ 2/draft-ietf-roll-turnon-rfc8138-12.txt 2020-09-02 07:13:41.056701919 -0700 @@ -1,19 +1,19 @@ ROLL P. Thubert, Ed. Internet-Draft L. Zhao Updates: 8138 (if approved) Cisco Systems -Intended status: Standards Track 27 August 2020 -Expires: 28 February 2021 +Intended status: Standards Track 2 September 2020 +Expires: 6 March 2021 A RPL DODAG Configuration Option for the 6LoWPAN Routing Header - draft-ietf-roll-turnon-rfc8138-11 + draft-ietf-roll-turnon-rfc8138-12 Abstract This document updates RFC 8138 by defining a bit in the RPL DODAG Configuration Option to indicate whether compression is used within the RPL Instance, and specify the behavior of RFC 8138-capable nodes when the bit is set and reset. Status of This Memo @@ -23,21 +23,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 28 February 2021. + This Internet-Draft will expire on 6 March 2021. Copyright Notice Copyright (c) 2020 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 carefully, as they describe your rights @@ -61,39 +61,41 @@ 5.3. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction - The packet compression technique defined in [RFC8138] can only be - activated in a RPL [RFC6550] network when all the nodes support it. - Otherwise, if acting as a leaf, a node that does not support the - compression would fail to communicate; if acting as a router it would - drop the compressed packets and black-hole a portion of the network. + The design of Low Power and Lossy Networks (LLNs) is generally + focused on saving energy, which is the most constrained resource of + all. The routing optimizations in the "Routing Protocol for Low + Power and Lossy Networks" [RFC6550] (RPL) such as routing along a + Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node + and the associated packet compression technique [RFC8138] derive from + that primary concern. - The original idea was to use a flag day but that proved impractical - in a number of situations such as a large metering network that is - used in production and incurs financial losses when interrupted. + Enabling [RFC8138] requires a Flag Day where the network is upgraded + and rebooted. Otherwise, if acting as a Leaf, a node that does not + support the compression would fail to communicate; if acting as a + router it would drop the compressed packets and black-hole a portion + of the network. This specification enables a hot upgrade where a + live network is migrated. During the migration, the compression + remains inactive, until all nodes are upgraded. - This specification is designed for the scenario where a live network - is upgraded to support [RFC8138]. During the migration, the - compression should remain inactive, until all nodes are upgraded. This document complements [RFC8138] and dedicates a flag in the RPL DODAG Configuration Option to indicate whether the [RFC8138] - compression should be used within the RPL DODAG. - - The setting of this new flag is controlled by the Root and propagates - as is in the whole network as part of the normal RPL signaling. + compression should be used within the RPL DODAG. The setting of this + new flag is controlled by the Root and propagates as is in the whole + network as part of the normal RPL signaling. The flag is cleared to maintain the compression inactive during the migration phase. When the migration is complete (e.g., as known by network management and/or inventory), the flag is set and the compression is globally activated in the whole DODAG. 2. Terminology 2.1. References @@ -277,48 +279,45 @@ are upgraded to support this specification. 5.3. Rolling Back When turning [RFC8138] compression off in the network, the Network Administrator MUST wait until all nodes have converged to the "T" flag reset before allowing nodes that do not support the compression in the network. To that effect, whether the compression is active in a node SHOULD be exposed the node's management interface. - It is RECOMMENDED to only deploy nodes that support [RFC8138] in a - network where the compression is turned on. A node that does not - support [RFC8138] MUST only be used as a RUL. + Nodes that do not support [RFC8138] SHOULD NOT be deployed in a + network where the compression is turned on. If that is done, the + node can only operate as a RUL. 6. IANA Considerations IANA is requested to assign a new option flag from the Registry for the "DODAG Configuration Option Flags" that was created for [RFC6550] as follows: +---------------+---------------------------------+-----------+ | Bit Number | Capability Description | Reference | +---------------+---------------------------------+-----------+ | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC | +---------------+---------------------------------+-----------+ Table 1: New DODAG Configuration Option Flag 7. Security Considerations - First of all, it is worth noting that with [RFC6550], every node in - the LLN that is RPL-aware can inject any RPL-based attack in the - network. A trust model is REQUIRED in an effort to exclude rogue - nodes from participating to the RPL and the 6LoWPAN signaling, as - well as from the data packet exchange. This trust model could at a - minimum be based on a Layer-2 Secure joining and the Link-Layer - security. This is a generic RPL and 6LoWPAN requirement, see Req5.1 - in Appendix of [RFC8505]. + It is worth noting that with RPL [RFC6550], every node in the LLN + that is RPL-aware can inject any RPL-based attack in the network. + This document applies typically to an existing deployment and does + not change its security requirements and operations. It is assumed + that the security mechanisms as defined for RPL are followed. Setting the "T" flag before all routers are upgraded may cause a loss of packets. The new bit is protected as the rest of the configuration so this is just one of the many attacks that can happen if an attacker manages to inject a corrupted configuration. Setting and resetting the "T" flag may create inconsistencies in the network but as long as all nodes are upgraded to [RFC8138] support they will be able to forward both forms. The source is responsible for selecting whether the packet is compressed or not, and all @@ -332,23 +331,24 @@ "T" flag, so that nodes located downstream would compress when that it is not desired, potentially resulting in the loss of packets. In a tree structure, the attacker would be in position to drop the packets from and to the attacked nodes. So the attacks above would be more complex and more visible than simply dropping selected packets. The downstream node may have other parents and see both settings, which could raise attention. 8. Acknowledgments - The authors wish to thank Meral Shirazipour, Nagendra Kumar Nainar, - Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique Barthel and - Rahul Jadhav for their in-depth reviews and constructive suggestions. + The authors wish to thank Meral Shirazipour, Barry Leiba, Nagendra + Kumar Nainar, Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique + Barthel and Rahul Jadhav for their in-depth reviews and constructive + suggestions. Also many thanks to Michael Richardson for being always helpful and responsive when need comes. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .