idnits 2.17.1 draft-ietf-core-hop-limit-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2018) is 2041 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 184, but not defined == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-25 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 21, 2019 McAfee 6 J. Shallow 7 NCC Group 8 September 17, 2018 10 Constrained Application Protocol (CoAP) Hop Limit Option 11 draft-ietf-core-hop-limit-00 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 March 21, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 7.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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, which is inserted in particular by on-path 80 proxies. Also, the document defines a new CoAP Response Code to 81 report loops together with relevant diagnostic information to ease 82 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 89 [RFC2119]. 91 Readers should be familiar with the terms and concepts defined in 92 [RFC7252]. 94 Within this document, CoAP agent refers to both CoAP client and CoAP 95 proxy. 97 3. Hop-Limit Option 99 Hop-Limit option (see Section 4.2) is an elective option used to 100 detect and prevent infinite loops when proxies are involved. Only 101 one single instance of the option is allowed in a message. 102 Therefore, any message carrying multiple Hop-Limit option instances 103 MUST be rejected using 4.00 (Bad Request) error message. 105 The value of the Hop-Limit option is encoded as an 8-bit unsigned 106 integer (see Section 3.2 of [RFC7252]). This value MUST be between 1 107 and 255 inclusive. CoAP messages received with a Hop-Limit option 108 set to '0' or greater than '255' MUST be rejected by a CoAP agent 109 using 4.00 (Bad Request). 111 The Hop-Limit option is safe to forward. That is, a CoAP proxy which 112 does not understand the Hop-Limit option should forward it on. 114 If a CoAP proxy receives a request which does not include a Hop-Limit 115 option, it SHOULD insert a Hop-Limit option when relaying the request 116 to a next hop (absent explicit policy/configuration otherwise). 118 The initial Hop-Limit value SHOULD be configurable. If no initial 119 value is explicitly provided, the default initial Hop-Limit value of 120 16 MUST be used. This value is chosen to be sufficiently large to 121 guarantee that a CoAP request would not be dropped in networks when 122 there were no loops, but not so large as to consume CoAP proxy 123 resources when a loop does occur. Lower values should be used with 124 caution and only in networks where topologies are known by the CoAP 125 agent inserting the Hop-Limit option. 127 Because forwarding errors may occur if inadequate Hop-Limit values 128 are used, proxies at the boundaries of an administrative domain MAY 129 be instructed to remove or rewrite the value of Hop-Limit carried in 130 received messages (i.e., ignore the value of Hop-Limit received in a 131 message). This modification should be done with caution in case 132 proxy-forwarded traffic repeatedly crosses the administrative domain 133 boundary in a loop and so Hop-Limit detection gets broken. 135 Otherwise, each intermediate proxy, which understands the Hop-Limit 136 option, involved in the handling of a CoAP message MUST decrement the 137 Hop-Limit option value by 1 prior to forwarding upstream if this 138 parameter exists. 140 CoAP messages MUST NOT be forwarded if the Hop-Limit option is set to 141 '0' after decrement. Messages that cannot be forwarded because of 142 exhausted Hop-Limit SHOULD be logged with a TBA1 (Hop Limit Reached) 143 error message sent back to the CoAP peer. It is RECOMMENDED that 144 CoAP agents support means to alert administrators about loop errors 145 so that appropriate actions are undertaken. 147 To ease debugging and troubleshooting, the CoAP proxy which detects a 148 loop SHOULD include its information (e.g., proxy name, proxy alias, 149 IP address) in the diagnostic payload under the conditions detailed 150 in Section 5.5.2 of [RFC7252]. 152 Each intermediate proxy involved in relaying a TBA1 (Hop Limit 153 Reached) error message SHOULD prepend its own information in the 154 diagnostic payload with a space character used as separator. Only 155 one information per proxy SHOULD appear in the diagnostic payload. 156 Doing so allows to limit the size of the TBA1 (Hop Limit Reached) 157 error message, and to ease correlation with hops count. 159 4. IANA Considerations 161 4.1. CoAP Response Code 163 IANA is requested to add the following entries to the "CoAP Response 164 Codes" sub-registry available at https://www.iana.org/assignments/ 165 core-parameters/core-parameters.xhtml#response-codes: 167 +------+------------------+-----------+ 168 | Code | Description | Reference | 169 +------+------------------+-----------+ 170 | TBA1 | Hop Limit Reached| [RFCXXXX] | 171 +------+------------------+-----------+ 173 Table 1: CoAP Response Codes 175 4.2. CoAP Option Number 177 IANA is requested to add the following entry to the "CoAP Option 178 Numbers" sub-registry available at https://www.iana.org/assignments/ 179 core-parameters/core-parameters.xhtml#option-numbers: 181 +--------+---+---+---+---+------------------+-----------+ 182 | Number | C | U | N | R | Name | Reference | 183 +--------+---+---+---+---+------------------+-----------+ 184 | TBA2 | | | x | | Hop-Limit | [RFCXXXX] | 185 +--------+---+---+---+---+------------------+-----------+ 186 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 188 Table 2: CoAP Option Number 190 5. Security Considerations 192 Security considerations related to CoAP proxying are discussed in 193 Section 11.2 of [RFC7252]. 195 The diagnostic payload of a TBA1 (Hop Limit Reached) error message 196 may leak sensitive information revealing the topology of an 197 administrative domain. To prevent that, a CoAP proxy which is 198 located at the boundary of an administrative domain MAY be instructed 199 to strip the diagnostic payload or part of it before forwarding on 200 the TBA1 response. 202 6. Acknowledgements 204 This specification was part of [I-D.ietf-dots-signal-channel]. Many 205 thanks to those who reviewed DOTS specifications. 207 Thanks to Klaus Hartke, Carsten Bormann, Peter van der Stok, and Jim 208 Schaad for the review. 210 7. References 212 7.1. Normative References 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, 216 DOI 10.17487/RFC2119, March 1997, 217 . 219 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 220 Application Protocol (CoAP)", RFC 7252, 221 DOI 10.17487/RFC7252, June 2014, 222 . 224 7.2. Informative References 226 [I-D.ietf-dots-signal-channel] 227 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 228 Teague, "Distributed Denial-of-Service Open Threat 229 Signaling (DOTS) Signal Channel Specification", draft- 230 ietf-dots-signal-channel-25 (work in progress), September 231 2018. 233 Authors' Addresses 234 Mohamed Boucadair 235 Orange 236 Rennes 35000 237 France 239 Email: mohamed.boucadair@orange.com 241 Tirumaleswar Reddy 242 McAfee, Inc. 243 Embassy Golf Link Business Park 244 Bangalore, Karnataka 560071 245 India 247 Email: kondtir@gmail.com 249 Jon Shallow 250 NCC Group 251 United Kingdom 253 Email: jon.shallow@nccgroup.com