idnits 2.17.1 draft-ietf-core-hop-limit-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 (February 26, 2019) is 1879 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 206, but not defined == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-28 Summary: 0 errors (**), 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: August 30, 2019 McAfee 6 J. Shallow 7 NCC Group 8 February 26, 2019 10 Constrained Application Protocol (CoAP) Hop Limit Option 11 draft-ietf-core-hop-limit-03 13 Abstract 15 The presence of Constrained Application Protocol (CoAP) proxies may 16 lead to infinite forwarding loops, which is undesirable. To prevent 17 and detect such loops, this document specifies the Hop-Limit CoAP 18 option. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 30, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Hop-Limit Option . . . . . . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. CoAP Response Code . . . . . . . . . . . . . . . . . . . 4 59 4.2. CoAP Option Number . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 7.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 More and more applications are using Constrained Application Protocol 70 (CoAP) [RFC7252] as a communication protocol between involved 71 application agents. For example, [I-D.ietf-dots-signal-channel] 72 specifies how CoAP is used as a distributed denial-of-service (DDoS) 73 attack signaling protocol seeking for help from DDoS mitigation 74 providers. In such contexts, a CoAP client can communicate directly 75 with a server or indirectly via proxies. 77 When multiple proxies are involved, infinite forwarding loops may be 78 experienced. To prevent such loops, this document defines a new CoAP 79 option, called Hop-Limit (Section 3), which is inserted in particular 80 by on-path proxies. Also, the document defines a new CoAP Response 81 Code (Section 4.1) to report loops together with relevant diagnostic 82 information to ease troubleshooting. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in BCP 89 14 [RFC2119][RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 Readers should be familiar with the terms and concepts defined in 93 [RFC7252]. 95 3. Hop-Limit Option 97 The Hop-Limit option (see Section 4.2) is an elective option used to 98 detect and prevent infinite loops when proxies are involved. The 99 option is not repeatable. Therefore, any message carrying multiple 100 Hop-Limit options MUST be rejected using 4.00 (Bad Request) error 101 message. 103 The value of the Hop-Limit option is encoded as an 8-bit unsigned 104 integer (see Section 3.2 of [RFC7252]). This value MUST be between 1 105 and 255 inclusive. CoAP messages received with a Hop-Limit option 106 set to '0' or greater than '255' MUST be rejected by a CoAP server/ 107 proxy using 4.00 (Bad Request). 109 The Hop-Limit option is safe to forward. That is, a CoAP proxy which 110 does not understand the Hop-Limit option should forward it on. The 111 option is also part of the cache key. As such, a CoAP proxy which 112 does not understand the Hop-Limit option must follow the 113 recommendations in Section 5.7.1 of [RFC7252] for caching. Note that 114 loops which involve only such proxies won't be detected. 115 Nevertheless, the presence of such proxies won't prevent infinite 116 loop detection if at least one CoAP proxy which support the Hop-Limit 117 option is involved in the loop. 119 A CoAP proxy which understands the Hop-Limit option MAY be 120 instructed, using a configuration parameter, to insert a Hop-Limit 121 option when relaying a request which do not include the Hop-Limit 122 option. 124 The initial Hop-Limit value SHOULD be configurable. If no initial 125 value is explicitly provided, the default initial Hop-Limit value of 126 16 MUST be used. This value is chosen to be sufficiently large to 127 guarantee that a CoAP request would not be dropped in networks when 128 there were no loops, but not so large as to consume CoAP proxy 129 resources when a loop does occur. Lower values should be used with 130 caution and only in networks where topologies are known by the CoAP 131 client (or proxy) inserting the Hop-Limit option. 133 Because forwarding errors may occur if inadequate Hop-Limit values 134 are used, proxies at the boundaries of an administrative domain MAY 135 be instructed to remove or rewrite the value of Hop-Limit carried in 136 received messages (i.e., ignore the value of Hop-Limit received in a 137 message). This modification should be done with caution in case 138 proxy-forwarded traffic repeatedly crosses the administrative domain 139 boundary in a loop and so Hop-Limit detection gets broken. 141 Otherwise, a CoAP proxy which understands the Hop-Limit option MUST 142 decrement the value of the option by 1 prior to forwarding it. A 143 CoAP proxy which understands the Hop-Limit option MUST NOT use a 144 stored TBA1 (Hop Limit Reached) error response unless the value of 145 the Hop-Limit option in the presented request is less than or equal 146 to the value of the Hop-Limit option in the request used to obtain 147 the stored response. Otherwise, the CoAP proxy follows the behavior 148 in Section 5.6 of [RFC7252]. 150 Note: If a request with a given value of Hop-Limit failed to reach 151 a server because the hop limit is exhausted, then the same failure 152 will be observed if a less value of the Hop-Limit option is used 153 instead. 155 CoAP messages MUST NOT be forwarded if the Hop-Limit option is set to 156 '0' after decrement. Messages that cannot be forwarded because of 157 exhausted Hop-Limit SHOULD be logged with a TBA1 (Hop Limit Reached) 158 error response sent back to the CoAP peer. It is RECOMMENDED that 159 CoAP implementations support means to alert administrators about loop 160 errors so that appropriate actions are undertaken. 162 To ease debugging and troubleshooting, the CoAP proxy which detects a 163 loop SHOULD include its information (e.g., proxy name, proxy alias, 164 IP address) in the diagnostic payload under the conditions detailed 165 in Section 5.5.2 of [RFC7252]. That information MUST NOT include any 166 space character. 168 Each intermediate proxy involved in relaying a TBA1 (Hop Limit 169 Reached) error message SHOULD prepend its own information in the 170 diagnostic payload with a space character used as separator. Only 171 one information per proxy SHOULD appear in the diagnostic payload. 172 Doing so allows to limit the size of the TBA1 (Hop Limit Reached) 173 error message, and to ease correlation with hops count. 175 4. IANA Considerations 177 4.1. CoAP Response Code 179 IANA is requested to add the following entry to the "CoAP Response 180 Codes" sub-registry available at https://www.iana.org/assignments/ 181 core-parameters/core-parameters.xhtml#response-codes: 183 +------+------------------+-----------+ 184 | Code | Description | Reference | 185 +------+------------------+-----------+ 186 | TBA1 | Hop Limit Reached| [RFCXXXX] | 187 +------+------------------+-----------+ 189 Table 1: CoAP Response Codes 191 This document suggests 5.06 as a code to be assigned for the new 192 response code. 194 Editorial Note: Please update TBA1 statements within the document 195 with the assigned code. 197 4.2. CoAP Option Number 199 IANA is requested to add the following entry to the "CoAP Option 200 Numbers" sub-registry available at https://www.iana.org/assignments/ 201 core-parameters/core-parameters.xhtml#option-numbers: 203 +--------+---+---+---+---+------------------+-----------+ 204 | Number | C | U | N | R | Name | Reference | 205 +--------+---+---+---+---+------------------+-----------+ 206 | TBA2 | | | | | Hop-Limit | [RFCXXXX] | 207 +--------+---+---+---+---+------------------+-----------+ 208 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 210 Table 2: CoAP Option Number 212 5. Security Considerations 214 Security considerations related to CoAP proxying are discussed in 215 Section 11.2 of [RFC7252]. 217 The diagnostic payload of a TBA1 (Hop Limit Reached) error message 218 may leak sensitive information revealing the topology of an 219 administrative domain. To prevent that, a CoAP proxy which is 220 located at the boundary of an administrative domain MAY be instructed 221 to strip the diagnostic payload or part of it before forwarding on 222 the TBA1 response. 224 6. Acknowledgements 226 This specification was part of [I-D.ietf-dots-signal-channel]. Many 227 thanks to those who reviewed DOTS specifications. 229 Thanks to Klaus Hartke, Carsten Bormann, Peter van der Stok, and Jim 230 Schaad for the reviews. 232 7. References 234 7.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, 238 DOI 10.17487/RFC2119, March 1997, 239 . 241 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 242 Application Protocol (CoAP)", RFC 7252, 243 DOI 10.17487/RFC7252, June 2014, 244 . 246 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 247 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 248 May 2017, . 250 7.2. Informative References 252 [I-D.ietf-dots-signal-channel] 253 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 254 Teague, "Distributed Denial-of-Service Open Threat 255 Signaling (DOTS) Signal Channel Specification", draft- 256 ietf-dots-signal-channel-28 (work in progress), January 257 2019. 259 Authors' Addresses 261 Mohamed Boucadair 262 Orange 263 Rennes 35000 264 France 266 Email: mohamed.boucadair@orange.com 268 Tirumaleswar Reddy 269 McAfee, Inc. 270 Embassy Golf Link Business Park 271 Bangalore, Karnataka 560071 272 India 274 Email: kondtir@gmail.com 276 Jon Shallow 277 NCC Group 278 United Kingdom 280 Email: jon.shallow@nccgroup.com