draft-ietf-roll-turnon-rfc8138-12.txt   draft-ietf-roll-turnon-rfc8138-13.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft L. Zhao Internet-Draft L. Zhao
Updates: 8138 (if approved) Cisco Systems Updates: 8138 (if approved) Cisco Systems
Intended status: Standards Track 2 September 2020 Intended status: Standards Track September 7, 2020
Expires: 6 March 2021 Expires: March 11, 2021
A RPL DODAG Configuration Option for the 6LoWPAN Routing Header A RPL DODAG Configuration Option for the 6LoWPAN Routing Header
draft-ietf-roll-turnon-rfc8138-12 draft-ietf-roll-turnon-rfc8138-13
Abstract Abstract
This document updates RFC 8138 by defining a bit in the RPL DODAG This document updates RFC 8138 by defining a bit in the RPL DODAG
Configuration Option to indicate whether compression is used within Configuration Option to indicate whether compression is used within
the RPL Instance, and specify the behavior of RFC 8138-capable nodes the RPL Instance, and specify the behavior of RFC 8138-capable nodes
when the bit is set and reset. when the bit is set and reset.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 March 2021. This Internet-Draft will expire on March 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 45 skipping to change at page 3, line 45
2.2. Glossary 2.2. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
6LoRH: 6LoWPAN Routing Header 6LoRH: 6LoWPAN Routing Header
DIO: DODAG Information Object (a RPL message) DIO: DODAG Information Object (a RPL message)
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
OF: RPL Objective Function SubDAG: Subset of a DAG that is a child of a node
OCP: RPL Objective Code Point
MOP: RPL Mode of Operation MOP: RPL Mode of Operation
RPI: RPL Packet Information RPI: RPL Packet Information
RAL: RPL-Aware Leaf RAL: RPL-Aware Leaf
RAN: RPL-Aware Node RAN: RPL-Aware Node
RUL: RPL-Unaware Leaf RUL: RPL-Unaware Leaf
SRH: Source Routing Header SRH: Source Routing Header
2.3. Requirements Language 2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 21 skipping to change at page 7, line 21
+---------------+---------------------------------+-----------+ +---------------+---------------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+---------------------------------+-----------+ +---------------+---------------------------------+-----------+
| 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC | | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC |
+---------------+---------------------------------+-----------+ +---------------+---------------------------------+-----------+
Table 1: New DODAG Configuration Option Flag Table 1: New DODAG Configuration Option Flag
7. Security Considerations 7. Security Considerations
It is worth noting that with RPL [RFC6550], every node in the LLN It is worth noting that in RPL [RFC6550], every node in the LLN that
that is RPL-aware can inject any RPL-based attack in the network. is RPL-aware and has access to the RPL domain can inject any RPL-
This document applies typically to an existing deployment and does based attack in the network, more in [RFC7416]. This document
not change its security requirements and operations. It is assumed applies typically to an existing deployment and does not change its
that the security mechanisms as defined for RPL are followed. 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 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 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 configuration so this is just one of the many attacks that can happen
if an attacker manages to inject a corrupted configuration. if an attacker manages to inject a corrupted configuration.
Setting and resetting the "T" flag may create inconsistencies in the Setting and resetting the "T" flag may create inconsistencies in the
network but as long as all nodes are upgraded to [RFC8138] support network but as long as all nodes are upgraded to [RFC8138] support
they will be able to forward both forms. The source is responsible they will be able to forward both forms. The source is responsible
for selecting whether the packet is compressed or not, and all for selecting whether the packet is compressed or not, and all
routers must use the format that the source selected. So the result routers must use the format that the source selected. So the result
of an inconsistency is merely that both forms will be present in the of an inconsistency is merely that both forms will be present in the
network, at an additional cost of bandwidth for packets in the network, at an additional cost of bandwidth for packets in the
uncompressed form. uncompressed form.
An attacker in the middle of the network may reset the "T" flag to An attacker in the middle of the network may reset the "T" flag to
cause extra energy spending in its subDAG. Conversely it may set the cause extra energy spending in the subset of the DODAG formed by its
"T" flag, so that nodes located downstream would compress when that descendants (its subDAG). Conversely it may set the "T" flag, so
it is not desired, potentially resulting in the loss of packets. In that nodes located downstream would compress when that it is not
a tree structure, the attacker would be in position to drop the desired, potentially resulting in the loss of packets. In a tree
packets from and to the attacked nodes. So the attacks above would structure, the attacker would be in position to drop the packets from
be more complex and more visible than simply dropping selected and to the attacked nodes. So the attacks above would be more
packets. The downstream node may have other parents and see both complex and more visible than simply dropping selected packets. The
settings, which could raise attention. downstream node may have other parents and see both settings, which
could raise attention.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Meral Shirazipour, Barry Leiba, Nagendra The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry
Kumar Nainar, Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant,
Barthel and Rahul Jadhav for their in-depth reviews and constructive Carles Gomez, and especially Alvaro Retana, Dominique Barthel and
suggestions. Rahul Jadhav for their in-depth reviews and constructive suggestions.
Also many thanks to Michael Richardson for being always helpful and Also many thanks to Michael Richardson for being always helpful and
responsive when need comes. responsive when need comes.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 51 skipping to change at page 8, line 51
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[UNAWARE-LEAVES] [UNAWARE-LEAVES]
Thubert, P. and M. Richardson, "Routing for RPL Leaves", Thubert, P. and M. Richardson, "Routing for RPL Leaves",
Work in Progress, Internet-Draft, draft-ietf-roll-unaware- Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
leaves-18, 12 June 2020, <https://tools.ietf.org/html/ leaves-18, June 12, 2020, <https://tools.ietf.org/html/
draft-ietf-roll-unaware-leaves-18>. draft-ietf-roll-unaware-leaves-18>.
10. Informative References 10. Informative References
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
[USEofRPLinfo] [USEofRPLinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Work in IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40,
25 June 2020, <https://tools.ietf.org/html/draft-ietf- June 25, 2020, <https://tools.ietf.org/html/draft-ietf-
roll-useofrplinfo-40>. roll-useofrplinfo-40>.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis
France France
 End of changes. 10 change blocks. 
25 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/