idnits 2.17.1 draft-ietf-core-hop-limit-06.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 (September 27, 2019) is 1671 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 277, 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: March 30, 2020 McAfee 6 J. Shallow 7 September 27, 2019 9 Constrained Application Protocol (CoAP) Hop-Limit Option 10 draft-ietf-core-hop-limit-06 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 March 30, 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 . . . . . . . . . . . . . . . . . . 7 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 involved application agents. For example, 74 [I-D.ietf-dots-signal-channel] specifies how CoAP is used as a 75 signaling protocol between domains under distributed denial-of- 76 service (DDoS) attacks and DDoS mitigation providers. In such 77 contexts, a CoAP client can communicate directly with a server or 78 indirectly via proxies. 80 When multiple proxies are involved, infinite forwarding loops may be 81 experienced (e.g., routing misconfiguration, policy conflicts). To 82 prevent such loops, this document defines a new CoAP option, called 83 Hop-Limit (Section 3). Also, the document defines a new CoAP 84 Response Code (Section 6.1) to report loops together with relevant 85 diagnostic information to ease troubleshooting (Section 4). 87 1.1. Intended Usage 89 The Hop-Limit option has originally been designed for a specific use 90 case [I-D.ietf-dots-signal-channel]. However, its intended usage is 91 general: CoAP proxies that do not have specific knowledge that proxy 92 forwarding loops are avoided in some other way, are expected to 93 implement this option and have it enabled by 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. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119][RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 Readers should be familiar with the terms and concepts defined in 109 [RFC7252]. 111 3. Hop-Limit Option 113 The properties of the Hop-Limit option are shown in Table 1. In this 114 table, the C, U, N, and R columns indicate the properties Critical, 115 Unsafe, NoCacheKey, and Repeatable defined in Section 5.4 of 116 [RFC7252]. 118 +--------+---+---+---+---+-----------+--------+--------+---------+ 119 | Number | C | U | N | R | Name | Format | Length | Default | 120 +--------+---+---+---+---+-----------+--------+--------+---------+ 121 | TBA2 | | | | | Hop-Limit | uint | 1 | 16 | 122 +--------+---+---+---+---+-----------+--------+--------+---------+ 124 Table 1: CoAP Hop-Limit Option Properties 126 The Hop-Limit option (Section 6.2) is an elective option used to 127 detect and prevent infinite loops when proxies are involved. The 128 option is not repeatable. Therefore, any message carrying multiple 129 Hop-Limit options MUST be handled following the procedure specified 130 in Section 5.4.5 of [RFC7252]. 132 The value of the Hop-Limit option is encoded as an unsigned integer 133 (see Section 3.2 of [RFC7252]). This value MUST be between 1 and 255 134 inclusive. CoAP messages received with a Hop-Limit option set to '0' 135 or greater than '255' MUST be rejected by a CoAP server/proxy using 136 4.00 (Bad Request). 138 The Hop-Limit option is safe to forward. That is, a CoAP proxy which 139 does not understand the Hop-Limit option should forward it on. The 140 option is also part of the cache key. As such, a CoAP proxy which 141 does not understand the Hop-Limit option must follow the 142 recommendations in Section 5.7.1 of [RFC7252] for caching. Note that 143 loops which involve only such proxies will not be detected. 144 Nevertheless, the presence of such proxies will not prevent infinite 145 loop detection if at least one CoAP proxy which support the Hop-Limit 146 option is involved in the loop. 148 A CoAP proxy which understands the Hop-Limit option MAY be 149 instructed, using a configuration parameter, to insert a Hop-Limit 150 option when relaying a request which do not include the Hop-Limit 151 option. 153 The initial Hop-Limit value should be configurable. If no initial 154 value is explicitly provided, the default initial Hop-Limit value of 155 16 MUST be used. This value is chosen to be sufficiently large to 156 guarantee that a CoAP request would not be dropped in networks when 157 there were no loops, but not so large as to consume CoAP proxy 158 resources when a loop does occur. Lower values should be used with 159 caution and only in networks where topologies are known by the CoAP 160 client (or proxy) inserting the Hop-Limit option. 162 Because forwarding errors may occur if inadequate Hop-Limit values 163 are used, proxies at the boundaries of an administrative domain MAY 164 be instructed to remove or rewrite the value of Hop-Limit carried in 165 received messages (i.e., ignore the value of Hop-Limit received in a 166 message). This modification should be done with caution in case 167 proxy-forwarded traffic repeatedly crosses the administrative domain 168 boundary in a loop and so Hop-Limit detection gets broken. 170 Otherwise, a CoAP proxy which understands the Hop-Limit option MUST 171 decrement the value of the option by 1 prior to forwarding it. A 172 CoAP proxy which understands the Hop-Limit option MUST NOT use a 173 stored TBA1 (Hop Limit Reached) error response unless the value of 174 the Hop-Limit option in the presented request is less than or equal 175 to the value of the Hop-Limit option in the request used to obtain 176 the stored response. Otherwise, the CoAP proxy follows the behavior 177 in Section 5.6 of [RFC7252]. 179 Note: If a request with a given value of Hop-Limit failed to reach 180 a server because the hop limit is exhausted, then the same failure 181 will be observed if a less value of the Hop-Limit option is used 182 instead. 184 CoAP messages MUST NOT be forwarded if the Hop-Limit option is set to 185 '0' after decrement. Messages that cannot be forwarded because of 186 exhausted Hop-Limit SHOULD be logged with a TBA1 (Hop Limit Reached) 187 error response sent back to the CoAP peer. It is RECOMMENDED that 188 CoAP implementations support means to alert administrators about loop 189 errors so that appropriate actions are undertaken. 191 4. Debugging & Troubleshooting 193 To ease debugging and troubleshooting, the CoAP proxy which detects a 194 loop includes its information in the diagnostic payload under the 195 conditions detailed in Section 5.5.2 of [RFC7252]. That information 196 MUST NOT include any space character. The information inserted by a 197 CoAP proxy can be, for example, a proxy name (e.g., p11.example.net), 198 proxy alias (e.g., myproxyalias), or IP address (e.g., 2001:db8::1). 200 Each intermediate proxy involved in relaying a TBA1 (Hop Limit 201 Reached) error message prepends its own information in the diagnostic 202 payload with a space character used as separator. Only one 203 information per proxy should appear in the diagnostic payload. Doing 204 so allows to limit the size of the TBA1 (Hop Limit Reached) error 205 message, and to ease correlation with hops count. Note that an 206 intermediate proxy prepends its information only if there is enough 207 space as determined by the Path MTU (Section 4.6 of [RFC7252]). If 208 not, an intermediate proxy forwards the TBA1 (Hop Limit Reached) 209 error message to the next hop without updating the diagnostic 210 payload. 212 5. HTTP-Mapping Considerations 214 This section focuses on the HTTP mappings specific to the CoAP 215 extension specified in this document. As a reminder, the basic 216 normative requirements on HTTP/CoAP mappings are defined in 217 Section 10 of [RFC7252]. The implementation guidelines for HTTP/CoAP 218 mappings are elaborated in [RFC8075]. 220 By default, the HTTP-to-CoAP Proxy inserts a Hop-Limit option 221 following the guidelines in Section 3. The HTTP-to-CoAP Proxy MAY be 222 instructed by policy to insert a Hop-Limit option only if a Via 223 (Section 5.7.1 of [RFC7230]) or CDN-Loop header field [RFC8586] is 224 present in the HTTP request. 226 The HTTP-to-CoAP Proxy uses 508 (Loop Detected) as the HTTP response 227 status code to map TBA1 (Hop Limit Reached). Furthermore, it maps 228 the diagnostic payload of TBA1 (Hop Limit Reached) as per Section 6.6 229 of [RFC8075]. 231 By default, the CoAP-to-HTTP Proxy inserts a Via header field in the 232 HTTP request if the CoAP request includes a Hop-Limit option. The 233 CoAP-to-HTTP Proxy MAY be instructed by policy to insert a CDN-Loop 234 header field instead of the Via header field. 236 The CoAP-to-HTTP Proxy maps the 508 (Loop Detected) HTTP response 237 status code to TBA1 (Hop Limit Reached). Moreover, the CoAP-to-HTTP 238 Proxy inserts its information following the guidelines in Section 4. 240 When both HTTP-to-CoAP and CoAP-to-HTTP proxies are involved, the 241 loop detection may get broken if the proxy-forwarded traffic 242 repeatedly crosses the HTTP-to-CoAP and CoAP-to-HTTP proxies. 243 Nevertheless, if the loop is within the CoAP or HTTP legs, the loop 244 detection is still functional. 246 6. IANA Considerations 248 Editorial Note: Please update TBA1/TBA2 statements within the 249 document with the assigned codes. 251 6.1. CoAP Response Code 253 IANA is requested to add the following entry to the "CoAP Response 254 Codes" sub-registry available at https://www.iana.org/assignments/ 255 core-parameters/core-parameters.xhtml#response-codes: 257 +------+------------------+-----------+ 258 | Code | Description | Reference | 259 +------+------------------+-----------+ 260 | TBA1 | Hop Limit Reached| [RFCXXXX] | 261 +------+------------------+-----------+ 263 Table 2: CoAP Response Codes 265 This document suggests 5.08 as a code to be assigned for the new 266 response code. 268 6.2. CoAP Option Number 270 IANA is requested to add the following entry to the "CoAP Option 271 Numbers" sub-registry available at https://www.iana.org/assignments/ 272 core-parameters/core-parameters.xhtml#option-numbers: 274 +--------+------------------+-----------+ 275 | Number | Name | Reference | 276 +--------+------------------+-----------+ 277 | TBA2 | Hop-Limit | [RFCXXXX] | 278 +--------+------------------+-----------+ 280 Table 3: CoAP Option Number 282 This document suggests 16 as a value to be assigned for the new 283 option number. 285 7. Security Considerations 287 Security considerations related to CoAP proxying are discussed in 288 Section 11.2 of [RFC7252]. 290 The diagnostic payload of a TBA1 (Hop Limit Reached) error message 291 may leak sensitive information revealing the topology of an 292 administrative domain. To prevent that, a CoAP proxy which is 293 located at the boundary of an administrative domain MAY be instructed 294 to strip the diagnostic payload or part of it before forwarding on 295 the TBA1 (Hop Limit Reached) response. 297 8. Acknowledgements 299 This specification was part of [I-D.ietf-dots-signal-channel]. Many 300 thanks to those who reviewed DOTS specifications. 302 Thanks to Klaus Hartke, Carsten Bormann, Peter van der Stok, Jim 303 Schaad, Jaime Jimenez, Roni Even, and Scott Bradner for the reviews. 305 Carsten Bormann provided the "Intended Usage" text. 307 9. References 309 9.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 317 Protocol (HTTP/1.1): Message Syntax and Routing", 318 RFC 7230, DOI 10.17487/RFC7230, June 2014, 319 . 321 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 322 Application Protocol (CoAP)", RFC 7252, 323 DOI 10.17487/RFC7252, June 2014, 324 . 326 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 327 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 328 the Constrained Application Protocol (CoAP)", RFC 8075, 329 DOI 10.17487/RFC8075, February 2017, 330 . 332 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 333 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 334 May 2017, . 336 9.2. Informative References 338 [I-D.ietf-dots-signal-channel] 339 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 340 Teague, "Distributed Denial-of-Service Open Threat 341 Signaling (DOTS) Signal Channel Specification", draft- 342 ietf-dots-signal-channel-37 (work in progress), July 2019. 344 [RFC8586] Ludin, S., Nottingham, M., and N. Sullivan, "Loop 345 Detection in Content Delivery Networks (CDNs)", RFC 8586, 346 DOI 10.17487/RFC8586, April 2019, 347 . 349 Authors' Addresses 351 Mohamed Boucadair 352 Orange 353 Rennes 35000 354 France 356 Email: mohamed.boucadair@orange.com 358 Tirumaleswar Reddy 359 McAfee, Inc. 360 Embassy Golf Link Business Park 361 Bangalore, Karnataka 560071 362 India 364 Email: kondtir@gmail.com 366 Jon Shallow 367 United Kingdom 369 Email: supjps-ietf@jpshallow.com