idnits 2.17.1 draft-jadhav-roll-storing-rootack-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 November 2021) is 889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-roll-rpl-observations-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R.A. Jadhav, Ed. 3 Internet-Draft 9 November 2021 4 Intended status: Standards Track 5 Expires: 13 May 2022 7 RPL Storing Root-ACK 8 draft-jadhav-roll-storing-rootack-03 10 Abstract 12 This document explains problems with DAO-ACK handling in RPL Storing 13 MOP and provides updates to RFC6550 to solve those problems. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 13 May 2022. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Requirements Language and Terminology . . . . . . . . . . 3 50 2. Problems with DAO-ACK in Storing MOP . . . . . . . . . . . . 3 51 2.1. End to End Path Establishment Indication . . . . . . . . 4 52 2.2. Target node is unaware if it needs to retry the DAO . . . 5 53 2.3. RPL node acting as router for RULs . . . . . . . . . . . 6 54 3. Requirements for Root-ACK handling in Storing MOP . . . . . . 6 55 4. Root-ACK from Root . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Transit Information Option update in DAO message . . . . 6 57 4.2. Root sends Root-ACK addressed to Target . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 7.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 RPL [RFC6550] specifies a proactive distance-vector routing scheme 68 designed for LLNs (Low Power and Lossy Networks). RPL enables the 69 network to be formed as a DODAG and supports storing mode and non- 70 storing mode of operations. Non-storing mode allows reduced memory 71 resource usage on the nodes by allowing non-BR nodes to operate 72 without managing a routing table and involves use of source routing 73 by the Root to direct the traffic along a specific path. In storing 74 mode of operation the routing happens on hop-by-hop basis and 75 intermediate routers need to maintain routing tables. 77 DAO messaging helps to install downstream routing paths in the DODAG. 78 DAOs are generated on hop-by-hop basis. DAO may contain multiple RPL 79 Control Options. The Target Option identifies the address prefix for 80 which the route has to be installed and the corresponding Transit 81 Information Option identifies the parameters (such as lifetime, 82 freshness-counter, etc) for the target. The DAO base object contains 83 the 'K' flag indicating that a DAO-ACK is sought by the sender. The 84 DAO, DAO-ACK progresses on hop-by-hop basis all the way till Root. 85 In non-storing MOP, the DAO from the target node is directly 86 addressed to the Root and the Root responds with a DAO-ACK indicating 87 path establishment status. However, in storing MOP, the DAO-ACK is 88 immediately sent by the upstream parent. Thus in case of storing 89 MOP, the target node cannot rely on DAO-ACK as an indication that the 90 end to end (from the target node to Root) path has been established. 92 This draft highlights various issues with RPL DAO-ACK handling in 93 Storing MOP. Section 4 of [I-D.ietf-roll-rpl-observations] provides 94 more context to the problem statement. The draft provides 95 requirements to solve the issues and provides an updates to RFC6550 96 based on these requirements. 98 1.1. Requirements Language and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 MOP: Mode of Operation 106 NS-MOP: RPL Non-Storing Mode of Operation 108 S-MOP: RPL Storing Mode of Operation 110 Root-ACK: The Root-ACK syntax is same as DAO-ACK except that the 111 Root-ACK is addressed directly to the peer who owns the target 112 prefix. DAO-ACK in contrast is always sent using link-local IPv6 113 address in storing MOP. 115 DelayDAO: Section 9.5 of RFC6550 introduces a delay before the DAO 116 transmission is initiated. 118 TIO: (Transit Information Option) Section 6.7.8 of RFC6550. TIO is 119 an option usually carried in DAO message and augments control 120 information for the advertised Target. 122 RUL: (RPL Unaware Leaf) [I-D.ietf-roll-unaware-leaves] 124 This document uses terminology described in [RFC6550]. 126 2. Problems with DAO-ACK in Storing MOP 128 Consider the following topology for the subsequent description: 130 (Root) 131 | 132 | 133 | 134 (A) 135 / \ 136 / \ 137 / \ 138 (B) -(C) 139 | / | 140 | / | 141 | / | 142 (D)- (E) 143 \ ; 144 \ ; 145 \ ; 146 (F) 147 / \ 148 / \ 149 / \ 150 (G) (H) 152 Figure 1: Sample topology 154 2.1. End to End Path Establishment Indication 156 Nodes need to know whether the end to end path till the Root has been 157 established before they can initiate application traffic. In case of 158 NS-MOP, the DAO is addressed to the Root from the Target node and the 159 Root sends DAO-ACK directly addressed back to the target node. Thus 160 in case of NS-MOP, the node can make use of this DAO-ACK as an 161 indication whether the necessary routes have been installed. 162 However, in case of Storing MOP, the DAO/DAO-ACK signaling happens at 163 every hop. 165 Non-Storing MOP 167 | D ======== B ======== A ======== (Root) 168 | ---------------DAO------------> 169 | <-----------DAO-ACK------------ 170 | 171 V 172 time 174 Figure 2: NS-MOP DAO/DAO-ACK handling 176 Storing MOP 178 | D ======== B ======== A ======== (Root) 179 | ---DAO---> 180 | <-DAO-ACK- 181 | ---DAO---> 182 | <-DAO-ACK- 183 | ---DAO---> 184 | <-DAO-ACK- 185 V 186 time 188 Figure 3: Storing MOP DAO/DAO-ACK handling 190 Note that in Storing-MOP, the DAO/DAO-ACK signaling happens on hop- 191 by-hop basis and a DelayDAO timer is used before intermediate 6LRs 192 generate the DAO. This would mean that the DAO reaching the Root may 193 take several seconds. The target node should not generate the 194 application traffic unless the end to end path is established. 196 Consider Figure 1, when node D sends a DAO, the node B receives the 197 DAO and instantly sends back DAO-ACK. Node B then subsequently 198 generates the DAO with Target as Node D and sends it to node A. The 199 DAO with Target as Node D may take time (since the DAO is scheduled 200 with DelayDAO timer by every node) to finally reach the Root at which 201 point the end to end path is established. There is no way for node D 202 to know when the end to end path is established. This information is 203 needed for node D to initiate its application traffic. Initiating 204 application traffic prior to this might almost certainly lead to 205 application packet retries causing congestion in the network. 207 2.2. Target node is unaware if it needs to retry the DAO 209 It is possible that the intermediate 6LR goes down while attempting 210 to generate DAO on behalf of the target node. In this case, the 211 target node has no way of knowing to retry the DAO, in which case the 212 route installation may not happen until the target node's DAO 213 lifetime expires. 215 Consider Figure 1, assume that node A was generating DAO with Target 216 node D and sending it to Root. Node A reboots before attempting to 217 send DAO to Root. Node A has already sent DAO-ACK downstream to node 218 B. In this case, the target node D is not aware that sending DAO has 219 failed somewhere upstream. Note that as per RFC6550 upstream DAO is 220 scheduled based on DelayDAO but DAO-ACK is sent instantaneously on 221 DAO reception from downstream node. 223 2.3. RPL node acting as router for RULs 225 An RPL node may act as a router for RPL unware leaves as described in 226 [I-D.ietf-roll-unaware-leaves]. Ideally an RPL node should start 227 accepting RULs solicitation only after making sure that it has 228 established itself in the network first. In Storing-MOP, there is no 229 way to ascertain this. 231 3. Requirements for Root-ACK handling in Storing MOP 233 Following are the requirements: 235 Indicate end to end path establishment The Target node must know 236 when to initiate the application traffic based on end to end path 237 establishment. 239 Handle multiple targets in DAOs A DAO message may contain multiple 240 Target Options. The Root-ACK mechanism must handle multiple 241 targets in DAO. 243 Handle DAOs with address prefix RPL DAO Target Option may contain an 244 address prefix i.e., not the full address. 246 Provide suitable way for target node to retry The Target node must 247 have a way to know and retry the DAO in case the DAO transmission 248 fails enroute. 250 Backward compatible with current DAO-ACK The current per hop DAO-ACK 251 must function as it is. Legacy nodes should be able to operate 252 without any changes. 254 4. Root-ACK from Root 256 The draft defines a way for the RPL Root to send the Root-ACK back 257 directly addressed to the Target node. The Target node can receive 258 the Root-ACK directly thus getting an indication that the end to end 259 path till the Root has been successfully established. The Root-ACK 260 uses the same syntax and message code as DAO-ACK. The only 261 difference is that the Root-ACK is directly addressed to the Target 262 node who owns the advertised prefix in the Target Option. 264 4.1. Transit Information Option update in DAO message 266 The Target node indicates that it wishes to receive Root-ACK directly 267 from Root by setting the newly defined 'K' flag in Transit 268 Information Option. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type = 0x06 | Option Length |E|I|K| Flags | Path Control | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Path Sequence | Path Lifetime | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 4: Updated Transit Information Option (New K flag added) 280 The K flag indicates that the Root of the RPLInstance MUST send a 281 Root-ACK directly to the target node. 283 4.2. Root sends Root-ACK addressed to Target 285 On receiving a DAO with Transit Information Option with 'K' flag set, 286 the Root MUST respond with a Root-ACK immediately to the address 287 extracted from the corresponding Target Option. 289 The Root-ACK MUST contain the Transit Information Option with 290 parameters copied from the DAO's Transit Information Option based on 291 which this Root-ACK was generated. The PathSequence in the Transit 292 Information Option helps the Target node to identify for which DAO it 293 generated it has received the Root-ACK. The DAOSequence in the base 294 Root-ACK(DAO-ACK) base object is ignored by the Target node. 296 5. IANA Considerations 298 IANA is requested to allocate bit 2 from the Transit Information 299 Option Flags registry for the 'K' flag (Section 4.1). 301 6. Security Considerations 303 This node introduces a new flag in response to which the Root of the 304 DODAG would send a Root-ACK which serves as an indication for the 305 target node that the end to end route/path is established. The Root- 306 ACK indication eventually would be used by the end node for 307 application layer processing such as initiating the application 308 traffic. A malicious node could generate the Root-ACK pre-maturely 309 i.e, before the end-to-end path is established and cause the 310 application to do some processing pre-maturely. However, the 311 application layer would always account for application layer failures 312 and thus shouldn't result in any security issues. This could result 313 in more control overhead which is currently the case where nodes do 314 not support this specification. 316 A malicious 6LR or 6LN could set the 'K' flag indicating the Root to 317 send a Root-ACK. The Root would generate a Root-ACK for the 318 indicated target. The Root need not keep any additional state for 319 handling the 'K' flag. 321 This document assumes that the security mechanisms as defined in 322 [RFC6550] are followed, which means that all the nodes are part of 323 the RPL network because they have the required credentials. A non- 324 secure RPL network needs to take into consideration the risks 325 highlighted in this section as well as those highlighted in 326 [RFC6550]. 328 7. References 330 7.1. Normative References 332 [I-D.ietf-roll-unaware-leaves] 333 Thubert, P. and M. C. Richardson, "Routing for RPL 334 (Routing Protocol for Low-Power and Lossy Networks) 335 Leaves", Work in Progress, Internet-Draft, draft-ietf- 336 roll-unaware-leaves-30, 22 January 2021, 337 . 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 346 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 347 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 348 Low-Power and Lossy Networks", RFC 6550, 349 DOI 10.17487/RFC6550, March 2012, 350 . 352 7.2. Informative References 354 [I-D.ietf-roll-rpl-observations] 355 Jadhav, R. A., Sahoo, R. N., and Y. Wu, "RPL 356 Observations", Work in Progress, Internet-Draft, draft- 357 ietf-roll-rpl-observations-06, 3 June 2021, 358 . 361 Author's Address 362 Rahul Arvind Jadhav (editor) 363 Marathahalli 364 Bangalore 560037 365 Karnataka 366 India 368 Email: rahul.ietf@gmail.com