idnits 2.17.1 draft-shore-icmp-aup-10.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 (January 28, 2014) is 3740 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Shore 3 Internet-Draft No Mountain Software 4 Intended status: BCP C. Pignataro 5 Expires: August 1, 2014 Cisco Systems, Inc. 6 January 28, 2014 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-10 11 Abstract 13 In this document we provide a basic description of ICMP's role in the 14 IP stack and some guidelines for future use. 16 This document is motivated by concerns about lack of clarity 17 concerning when to add new Internet Control Message Protocol (ICMP) 18 types and/or codes. These concerns have highlighted a need to 19 describe policies for when adding new features to ICMP is desirable 20 and when it is not. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 1, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Acceptable use policy . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Classification of existing message types . . . . . . . . . 3 59 2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . . 5 60 2.1.2. A few notes on RPL . . . . . . . . . . . . . . . . . . 6 61 2.2. Applications using ICMP . . . . . . . . . . . . . . . . . . 6 62 2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . . 6 64 3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 7 65 4. Security considerations . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. Informative references . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 There has been some recent concern expressed about a lack of clarity 74 around when to add new message types and codes to ICMP (including 75 ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a description of 76 when (and when not) to move functionality into ICMP. 78 This document is the result of discussions among ICMP experts within 79 the OPS area's IP Diagnostics Technical Interest Group [1] and 80 concerns expressed by the OPS area leadership. 82 Note that this document does not supercede the IANA Allocation 83 Guidelines for Values in the Internet Protocol and Related Headers, 84 RFC 2780 [RFC2780], which specifies best practices and processes for 85 the allocation of values in the IANA registries but does not describe 86 the policies to be applied in the standards process. 88 2. Acceptable use policy 90 In this document we describe an acceptable use policy for new ICMP 91 message types and codes, and provide some background behind the 92 policy. 94 In summary, any future message types added to ICMP should be limited 95 to two broad categories: 97 1. to inform a datagram's originator that a forwarding plane anomaly 98 has been encountered downstream. The datagram originator must be 99 able to determine whether or not the datagram was discarded by 100 examining the ICMP message 101 2. to discover and convey dynamic information about a node (other 102 than information usually carried in routing protocols), to 103 discover and convey network-specific parameters, and to discover 104 on-link routers and hosts. 106 Normally, other uses such as implementing a general-purpose routing 107 or network management protocol are not advisable. However, ICMP does 108 have a role to play in conveying dynamic information about a network, 109 which would belong in category 2 above. 111 2.1. Classification of existing message types 113 This section provides a rough breakdown of existing message types 114 according to the taxonomy described in Section 2 at the time of 115 publication. 117 IPv4 forwarding plane anomaly reporting: 119 3: Destination unreachable 120 4: Source quench (deprecated) 121 6: Alternate host address (deprecated) 122 11: Time exceeded 123 12: Parameter problem 124 31: Datagram conversion error (deprecated) 125 41: ICMP messages utilized by experimental mobility protocols, 126 such as Seamoby 128 IPv4 router or host discovery: 130 0: Echo reply 131 5: Redirect 132 8: Echo 133 9: Router advertisement 134 10: Router solicitation 135 13: Timestamp 136 14: Timestamp reply 137 15: Information request (deprecated) 138 16: Information reply (deprecated) 139 17: Address mask request (deprecated) 140 18: Address mask reply (deprecated) 141 30: Traceroute (deprecated) 142 32: Mobile host redirect (deprecated) 143 33: IPv6 Where-Are-You (deprecated) 144 34: IPv6 I-Am-Here (deprecated) 145 35: Mobile registration request (deprecated) 146 36: Mobile registration reply (deprecated) 147 37: Domain name request (deprecated) 148 38: Domain name reply (deprecated) 149 39: SKIP (deprecated) 150 40: Photuris 151 41: ICMP messages utilized by experimental mobility protocols, 152 such as Seamoby 154 Please note that some ICMP message types were formally deprecated by 155 [RFC6918]. 157 IPv6 forwarding plane anomaly reporting: 159 1: Destination unreachable 160 2: Packet too big 161 3: Time exceeded 162 4: Parameter problem 163 150: ICMP messages utilized by experimental mobility protocols, 164 such as Seamoby 166 IPv6 router or host discovery: 168 128: Echo request 169 129: Echo reply 170 130: Multicast listener query 171 131: Multicast listener report 172 132: Multicast listener done 173 133: Router solicitation 174 134: Router advertisement 175 135: Neighbor solicitation 176 136: Neighbor advertisement 177 137: Redirect message 178 138: Router renumbering 179 139: ICMP node information query 180 140: ICMP node information response 181 141: Inverse neighbor discovery solicitation message 182 142: Inverse neighbor discovery advertisement message 183 143: Version 2 multicast listener report 184 144: Home agent address discovery request message 185 145: Home agent address discovery reply message 186 146: Mobile prefix solicitation 187 147: Mobile prefix advertisement 188 148: Certification path solicitation message 189 149: Certification path advertisement message 190 150: ICMP messages utilized by experimental mobility protocols, 191 such as Seamoby 192 151: Multicast router advertisement 193 152: Multicast router solicitation 194 153: Multicast router termination 195 154: FMIPv6 messages 196 155: RPL control message 198 2.1.1. ICMP Use as a Routing Protocol 200 As mentioned in Section 2, using ICMP as a general-purpose routing or 201 network management protocol is not advisable. 203 ICMP has a role in the Internet as an integral part of the IP layer, 204 and not as a transport protocol for other layers including routing 205 information. From a more pragmatic perspective, some of the key 206 characteristics of ICMP do not support using it as a routing 207 protocol. Those include that ICMP is frequently filtered, is not 208 authenticated, and is easily spoofed. 210 2.1.2. A few notes on RPL 212 RPL, the IPv6 Routing protocol for low-power and lossy networks (see 213 [RFC6550]) uses ICMP as a transport. It is something of an outlier 214 among the existing ICMP message types, as the expansion of its 215 acronym appears to be an actual routing protocol. 217 This should be considered anomalous and is not a model for future 218 ICMP message types. That is, ICMP is not intended as a transport for 219 other protocols and should not be used in that way in future 220 specifications. In particular, while it is adequate to use ICMP as a 221 discovery protocol, this does not extend to full routing 222 capabilities. 224 2.2. Applications using ICMP 226 Some applications make use of ICMP error notifications, or even 227 deliberately create anomalous conditions in order to elicit ICMP 228 messages, to then use those ICMP messages to generate feedback to the 229 higher layer. Some of these applications include most widespread 230 examples such as TRACEROUTE and Path MTU Discovery (PMTUD). These 231 uses are considered acceptable as they do not add new message types 232 to ICMP. 234 2.3. Extending ICMP 236 ICMP multi-part messages are specified in [RFC4884] by defining an 237 extension mechanism for selected ICMP messages. This mechanism 238 addresses a fundamental problem in ICMP extensibility. An ICMP 239 multi-part message carries all of the information that ICMP messages 240 carried previously, as well as additional information that 241 applications may require. 243 Some currently defined ICMP extensions include ICMP extensions for 244 Multiprotocol Label Switching [RFC4950] and ICMP extensions for 245 interface and next-hop identification [RFC5837]. 247 Extensions to ICMP should follow [RFC4884]. 249 2.4. ICMPv4 vs. ICMPv6 251 Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 252 routers, IPv6-capable security gateways, and IPv6-capable firewalls 253 normally support administrator configuration of how specific ICMPv6 254 message types are handled. By contrast, deployed IPv4 routers, IPv4- 255 capable security gateways, and IPv4-capable firewalls are less likely 256 to allow an administrator to configure how specific ICMPv4 message 257 types are handled. So, at present, ICMPv6 messages usually have a 258 higher probability of travelling end-to-end than ICMPv4 messages. 260 3. ICMP's role in the internet 262 ICMP was originally intended to be a mechanism for gateways or 263 destination hosts to report error conditions back to source hosts in 264 ICMPv4 [RFC0792], and ICMPv6 [RFC4443] is modeled after it. The word 265 "control" in the protocol name did not describe ICMP's function (i.e. 266 it did not "control" the internet), but rather that it was used to 267 communicate about the control functions in the internet. For 268 example, even though ICMP included a redirect message type that 269 affects routing behavior in the context of a LAN segment, it was and 270 is not used as a generic routing protocol. 272 ICMP is defined to be an integral part of IP, and must be implemented 273 by every IP module. This is true for ICMPv4 as an integral part of 274 IPv4 (see the Introduction of [RFC0792]), and for ICMPv6 as an 275 integral part of IPv6 (see Section 2 of [RFC4443]). When first 276 defined, ICMP messages were thought of as IP messages that didn't 277 carry any higher layer data. It could be conjectured that the term 278 'control' was used given that ICMP messages were not 'data' messages. 280 Most likely because of the presence of the word "control" in the 281 protocol name, ICMP is often understood to be a control protocol, 282 borrowing some terminology from circuit networks and the PSTN. That 283 is probably not correct - it might be more correct to describe it as 284 being closer to a management plane protocol, given the data plane/ 285 control plane/ management plane taxonomy often used in describing 286 telephony protocols. However, layering in IP networks is not very 287 clean and there's often some intermingling of function that can tend 288 to lead to confusion about where to place new functions. 290 In the following section we provide some background on the 291 differences between control and management traffic. 293 4. Security considerations 295 This document describes a high-level policy for adding ICMP types and 296 codes. While special attention must be paid to the security 297 implications of any particular new ICMP type or code, this 298 recommendation presents no new security considerations. 300 From a security perspective, ICMP plays a part in the Photuris 301 [RFC2521] protocol. But more generally, ICMP is not a secure 302 protocol, and does not include features to be used to discover 303 network security parameters or to report on network security 304 anomalies in the forwarding plane. 306 Additionally, new ICMP functionality (e.g., ICMP extensions, or new 307 ICMP types or codes) needs to consider potential ways of how ICMP can 308 be abused (e.g., Smurf IP DoS [CA-1998-01]). 310 5. IANA considerations 312 There are no actions required by IANA. 314 6. Acknowledgments 316 This document was originally proposed by, and received substantial 317 review and suggestions from, Ron Bonica. Discussions with Pascal 318 Thubert helped clarify the history of RPL's use of ICMP. We are very 319 grateful for the review, feedback, and comments from Ran Atkinson, 320 Tim Chown, Joe Clarke, Ray Hunter, Hilarie Orman, Eric Rosen, JINMEI 321 Tatuya, and Wen Zhang, which resulted in a much improved document. 323 7. Informative references 325 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 326 RFC 792, September 1981. 328 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 329 Values In the Internet Protocol and Related Headers", 330 BCP 37, RFC 2780, March 2000. 332 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 333 Message Protocol (ICMPv6) for the Internet Protocol 334 Version 6 (IPv6) Specification", RFC 4443, March 2006. 336 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 337 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 338 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 339 Lossy Networks", RFC 6550, March 2012. 341 [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some 342 ICMPv4 Message Types", RFC 6918, April 2013. 344 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 345 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 346 April 2007. 348 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 349 Extensions for Multiprotocol Label Switching", RFC 4950, 350 August 2007. 352 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 353 Rivers, "Extending ICMP for Interface and Next-Hop 354 Identification", RFC 5837, April 2010. 356 [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures 357 Messages", RFC 2521, March 1999. 359 [CA-1998-01] 360 CERT, "Smurf IP Denial-of-Service Attacks", CERT 361 Advisory CA-1998-01, January 1998, 362 . 364 [1] 366 Authors' Addresses 368 Melinda Shore 369 No Mountain Software 370 PO Box 16271 371 Two Rivers, AK 99716 372 US 374 Phone: +1 907 322 9522 375 Email: melinda.shore@nomountain.net 377 Carlos Pignataro 378 Cisco Systems, Inc. 379 7200-12 Kit Creek Road 380 Research Triangle Park, NC 27709 381 US 383 Email: cpignata@cisco.com