idnits 2.17.1 draft-ietf-core-hop-limit-07.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 (October 17, 2019) is 1646 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) == Missing Reference: 'RFCXXXX' is mentioned on line 291, but not defined ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-37 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: April 19, 2020 McAfee 6 J. Shallow 7 October 17, 2019 9 Constrained Application Protocol (CoAP) Hop-Limit Option 10 draft-ietf-core-hop-limit-07 12 Abstract 14 The presence of Constrained Application Protocol (CoAP) proxies may 15 lead to infinite forwarding loops, which is undesirable. To prevent 16 and detect such loops, this document specifies the Hop-Limit CoAP 17 option. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 19, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Intended Usage . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Hop-Limit Option . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Debugging & Troubleshooting . . . . . . . . . . . . . . . . . 5 58 5. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. CoAP Response Code . . . . . . . . . . . . . . . . . . . 6 61 6.2. CoAP Option Number . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 9.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 More and more applications are using the Constrained Application 72 Protocol (CoAP) [RFC7252] as a communication protocol between 73 application agents. For example, [I-D.ietf-dots-signal-channel] 74 specifies how CoAP is used as a signaling protocol between domains 75 under distributed denial-of-service (DDoS) attacks and DDoS 76 mitigation providers. In such contexts, a CoAP client can 77 communicate directly with a server or indirectly via proxies. 79 When multiple proxies are involved, infinite forwarding loops may be 80 experienced (e.g., routing misconfiguration, policy conflicts). To 81 prevent such loops, this document defines a new CoAP option, called 82 Hop-Limit (Section 3). Also, the document defines a new CoAP 83 Response Code (Section 6.1) to report loops together with relevant 84 diagnostic information to ease troubleshooting (Section 4). 86 1.1. Intended Usage 88 The Hop-Limit option was originally designed for a specific use case 89 [I-D.ietf-dots-signal-channel]. However, its intended usage is 90 general: 92 New CoAP proxies MUST implement this option and have it enabled by 93 default. 95 Note that this means that a server that receives requests both via 96 proxies and directly from clients may see otherwise identical 97 requests with and without the Hop-Limit option included; servers with 98 internal caching will therefore also want to implement this option, 99 since understanding the Hop-Limit option will improve caching 100 efficiency. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119][RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Readers should be familiar with the terms and concepts defined in 111 [RFC7252]. 113 3. Hop-Limit Option 115 The properties of the Hop-Limit option are shown in Table 1. The 116 formatting of this table follows the one used in Table 4 of [RFC7252] 117 (Section 5.10). The C, U, N, and R columns indicate the properties 118 Critical, Unsafe, NoCacheKey, and Repeatable defined in Section 5.4 119 of [RFC7252]. None of these properties is marked for the Hop-Limit 120 option. 122 +--------+---+---+---+---+-----------+--------+--------+---------+ 123 | Number | C | U | N | R | Name | Format | Length | Default | 124 +--------+---+---+---+---+-----------+--------+--------+---------+ 125 | TBA2 | | | | | Hop-Limit | uint | 1 | 16 | 126 +--------+---+---+---+---+-----------+--------+--------+---------+ 128 Table 1: CoAP Hop-Limit Option Properties 130 The Hop-Limit option (Section 6.2) is an elective option used to 131 detect and prevent infinite loops of CoAP requests when proxies are 132 involved. The option is not repeatable. Therefore, any request 133 carrying multiple Hop-Limit options MUST be handled following the 134 procedure specified in Section 5.4.5 of [RFC7252]. 136 The value of the Hop-Limit option is encoded as an unsigned integer 137 (see Section 3.2 of [RFC7252]). This value MUST be between 1 and 255 138 inclusive. CoAP requests received with a Hop-Limit option set to '0' 139 or greater than '255' MUST be rejected by a CoAP server/proxy using 140 4.00 (Bad Request). 142 The Hop-Limit option is safe to forward. That is, a CoAP proxy that 143 does not understand the Hop-Limit option should forward it on. The 144 option is also part of the cache key. As such, a CoAP proxy that 145 does not understand the Hop-Limit option must follow the 146 recommendations in Section 5.7.1 of [RFC7252] for caching. Note that 147 loops that involve only such proxies will not be detected. 148 Nevertheless, the presence of such proxies will not prevent infinite 149 loop detection if at least one CoAP proxy that supports the Hop-Limit 150 option is involved in the loop. 152 A CoAP proxy that understands the Hop-Limit option SHOULD be 153 instructed, using a configuration parameter, to insert a Hop-Limit 154 option when relaying a request that does not include the Hop-Limit 155 option. 157 The initial Hop-Limit value should be configurable. If no initial 158 value is explicitly provided, the default initial Hop-Limit value of 159 16 MUST be used. This value is chosen so that in the majority of 160 cases it is sufficiently large to guarantee that a CoAP request would 161 not be dropped in networks when there were no loops, but not so large 162 as to consume CoAP proxy resources when a loop does occur. The value 163 is still configurable to accommodate unusual topologies. Lower 164 values should be used with caution and only in networks where 165 topologies are known by the CoAP client (or proxy) inserting the Hop- 166 Limit option. 168 Because forwarding errors may occur if inadequate Hop-Limit values 169 are used, proxies at the boundaries of an administrative domain MAY 170 be instructed to remove or rewrite the value of Hop-Limit carried in 171 received requests (i.e., ignore the value of Hop-Limit received in a 172 request). This modification should be done with caution in case 173 proxy-forwarded traffic repeatedly crosses the administrative domain 174 boundary in a loop rendering ineffective the efficacy of loop 175 detection through the Hop-Limit option. 177 Otherwise, a CoAP proxy that understands the Hop-Limit option MUST 178 decrement the value of the option by 1 prior to forwarding it. A 179 CoAP proxy that understands the Hop-Limit option MUST NOT use a 180 stored TBA1 (Hop Limit Reached) error response unless the value of 181 the Hop-Limit option in the presented request is smaller than or 182 equal to the value of the Hop-Limit option in the request used to 183 obtain the stored response. Otherwise, the CoAP proxy follows the 184 behavior in Section 5.6 of [RFC7252]. 186 Note: If a request with a given value of Hop-Limit failed to reach 187 a server because the hop limit is exhausted, then the same failure 188 will be observed if a smaller value of the Hop-Limit option is 189 used instead. 191 CoAP requests MUST NOT be forwarded if the Hop-Limit option is set to 192 '0' after decrement. Requests that cannot be forwarded because of 193 exhausted Hop-Limit SHOULD be logged with a TBA1 (Hop Limit Reached) 194 error response sent back to the CoAP peer. It is RECOMMENDED that 195 CoAP implementations support means to alert administrators about loop 196 errors so that appropriate actions are undertaken. 198 4. Debugging & Troubleshooting 200 To ease debugging and troubleshooting, the CoAP proxy that detects a 201 loop includes an identifier for itself in the diagnostic payload 202 under the conditions detailed in Section 5.5.2 of [RFC7252]. That 203 identifier MUST NOT include any space character (ASCII value 32). 204 The identifier inserted by a CoAP proxy can be, for example, a proxy 205 name (e.g., p11.example.net), proxy alias (e.g., myproxyalias), or IP 206 address (e.g., 2001:db8::1). 208 Each intermediate proxy involved in relaying a TBA1 (Hop Limit 209 Reached) error message prepends its own identifier in the diagnostic 210 payload with a space character used as separator. Only one 211 identifier per proxy should appear in the diagnostic payload. This 212 approach allows to limit the size of the TBA1 (Hop Limit Reached) 213 error message, ease correlation with hops count, and detect whether a 214 proxy was involved in the forwarding of the TBA1 (Hop Limit Reached) 215 error message. Note that an intermediate proxy prepends its 216 identifier only if there is enough space as determined by the Path 217 MTU (Section 4.6 of [RFC7252]). If not, an intermediate proxy 218 forwards the TBA1 (Hop Limit Reached) error message to the next hop 219 without updating the diagnostic payload. 221 An intermediate proxy MUST NOT forward a TBA1 (Hop Limit Reached) 222 error message if it detects that its identifier is included in the 223 diagnostic payload. Such messages SHOULD be logged and appropriate 224 alerts sent to the administrators. 226 5. HTTP-Mapping Considerations 228 This section focuses on the HTTP mappings specific to the CoAP 229 extension specified in this document. As a reminder, the basic 230 normative requirements on HTTP/CoAP mappings are defined in 231 Section 10 of [RFC7252]. The implementation guidelines for HTTP/CoAP 232 mappings are elaborated in [RFC8075]. 234 By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option 235 following the guidelines in Section 3. The HTTP-to-CoAP Proxy may be 236 instructed by policy to insert a Hop-Limit option only if a Via 237 (Section 5.7.1 of [RFC7230]) or CDN-Loop header field [RFC8586] is 238 present in the HTTP request. 240 The HTTP-to-CoAP Proxy uses 508 (Loop Detected) as the HTTP response 241 status code to map TBA1 (Hop Limit Reached). Furthermore, it maps 242 the diagnostic payload of TBA1 (Hop Limit Reached) as per Section 6.6 243 of [RFC8075]. 245 By default, the CoAP-to-HTTP Proxy inserts a Via header field in the 246 HTTP request if the CoAP request includes a Hop-Limit option. The 247 CoAP-to-HTTP Proxy may be instructed by policy to insert a CDN-Loop 248 header field instead of the Via header field. 250 The CoAP-to-HTTP Proxy maps the 508 (Loop Detected) HTTP response 251 status code to TBA1 (Hop Limit Reached). Moreover, the CoAP-to-HTTP 252 Proxy inserts its information following the guidelines in Section 4. 254 When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the 255 loop detection may get broken if the proxy-forwarded traffic 256 repeatedly crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies. 257 Nevertheless, if the loop is within the CoAP or HTTP legs, the loop 258 detection is still functional. 260 6. IANA Considerations 262 Editorial Note: Please update TBA1/TBA2 statements within the 263 document with the assigned codes. 265 6.1. CoAP Response Code 267 IANA is requested to add the following entry to the "CoAP Response 268 Codes" sub-registry available at https://www.iana.org/assignments/ 269 core-parameters/core-parameters.xhtml#response-codes: 271 +------+------------------+-----------+ 272 | Code | Description | Reference | 273 +------+------------------+-----------+ 274 | TBA1 | Hop Limit Reached| [RFCXXXX] | 275 +------+------------------+-----------+ 277 Table 2: CoAP Response Codes 279 This document suggests 5.08 as a code to be assigned for the new 280 response code. 282 6.2. CoAP Option Number 284 IANA is requested to add the following entry to the "CoAP Option 285 Numbers" sub-registry available at https://www.iana.org/assignments/ 286 core-parameters/core-parameters.xhtml#option-numbers: 288 +--------+------------------+-----------+ 289 | Number | Name | Reference | 290 +--------+------------------+-----------+ 291 | TBA2 | Hop-Limit | [RFCXXXX] | 292 +--------+------------------+-----------+ 294 Table 3: CoAP Option Number 296 This document suggests 16 as a value to be assigned for the new 297 option number. 299 7. Security Considerations 301 Security considerations related to CoAP proxying are discussed in 302 Section 11.2 of [RFC7252]. 304 A CoAP endpoint can probe the topology of a network into which it is 305 making requests by tweaking the value of the Hop-Limit option. Such 306 probing is likely to fail if proxies at the boundaries of that 307 network rewrite the value of Hop-Limit carried in received requests 308 (see Section 3). 310 The diagnostic payload of a TBA1 (Hop Limit Reached) error message 311 may leak sensitive information revealing the topology of an 312 administrative domain. To prevent that, a CoAP proxy that is located 313 at the boundary of an administrative domain MAY be instructed to 314 strip the diagnostic payload or part of it before forwarding on the 315 TBA1 (Hop Limit Reached) response. 317 8. Acknowledgements 319 This specification was part of [I-D.ietf-dots-signal-channel]. Many 320 thanks to those who reviewed DOTS specifications. 322 Thanks to Klaus Hartke, Carsten Bormann, Peter van der Stok, Jim 323 Schaad, Jaime Jimenez, Roni Even, Scott Bradner, Thomas Fossati, 324 Radia Perlman, Eric Vyncke, Suresh Krishnan, Roman Danyliw, Barry 325 Leiba, Christer Holmberg, Benjamin Kaduk, and Adam Roach for their 326 review and comments. 328 Carsten Bormann provided the "Intended Usage" text. 330 9. References 331 9.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 339 Protocol (HTTP/1.1): Message Syntax and Routing", 340 RFC 7230, DOI 10.17487/RFC7230, June 2014, 341 . 343 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 344 Application Protocol (CoAP)", RFC 7252, 345 DOI 10.17487/RFC7252, June 2014, 346 . 348 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 349 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 350 the Constrained Application Protocol (CoAP)", RFC 8075, 351 DOI 10.17487/RFC8075, February 2017, 352 . 354 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 355 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 356 May 2017, . 358 9.2. Informative References 360 [I-D.ietf-dots-signal-channel] 361 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 362 Teague, "Distributed Denial-of-Service Open Threat 363 Signaling (DOTS) Signal Channel Specification", draft- 364 ietf-dots-signal-channel-37 (work in progress), July 2019. 366 [RFC8586] Ludin, S., Nottingham, M., and N. Sullivan, "Loop 367 Detection in Content Delivery Networks (CDNs)", RFC 8586, 368 DOI 10.17487/RFC8586, April 2019, 369 . 371 Authors' Addresses 373 Mohamed Boucadair 374 Orange 375 Rennes 35000 376 France 378 Email: mohamed.boucadair@orange.com 379 Tirumaleswar Reddy 380 McAfee, Inc. 381 Embassy Golf Link Business Park 382 Bangalore, Karnataka 560071 383 India 385 Email: kondtir@gmail.com 387 Jon Shallow 388 United Kingdom 390 Email: supjps-ietf@jpshallow.com