idnits 2.17.1 draft-shore-icmp-aup-11.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 1, 2014) is 3737 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 5, 2014 Cisco Systems, Inc. 6 February 1, 2014 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-11 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 5, 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 This is not as a routing protocol, or as a transport protocol for 205 other layers including routing information. From a more pragmatic 206 perspective, some of the key characteristics of ICMP do not support 207 using it as a routing protocol. Those include that ICMP is 208 frequently filtered, is not authenticated, is easily spoofed, and 209 that specialist hardward processing of ICMP would disrupt the 210 deployment of an ICMP-based routing or management protocol.. 212 2.1.2. A few notes on RPL 214 RPL, the IPv6 Routing protocol for low-power and lossy networks (see 215 [RFC6550]) uses ICMP as a transport. It is an exception among the 216 existing ICMP message types, as the expansion of its acronym appears 217 to be an actual general routing protocol. 219 This should be considered anomalous and is not a model for future 220 ICMP message types. That is, ICMP is not intended as a transport for 221 other protocols and should not be used in that way in future 222 specifications. In particular, while it is adequate to use ICMP as a 223 discovery protocol, this does not extend to full routing 224 capabilities. 226 2.2. Applications using ICMP 228 Some applications make use of ICMP error notifications, or even 229 deliberately create anomalous conditions in order to elicit ICMP 230 messages, to then use those ICMP messages to generate feedback to the 231 higher layer. Some of these applications include most widespread 232 examples such as PING, TRACEROUTE and Path MTU Discovery (PMTUD). 233 These uses are considered acceptable as they use existing ICMP 234 message types and do not change ICMP functionality. 236 2.3. Extending ICMP 238 ICMP multi-part messages are specified in [RFC4884] by defining an 239 extension mechanism for selected ICMP messages. This mechanism 240 addresses a fundamental problem in ICMP extensibility. An ICMP 241 multi-part message carries all of the information that ICMP messages 242 carried previously, as well as additional information that 243 applications may require. 245 Some currently defined ICMP extensions include ICMP extensions for 246 Multiprotocol Label Switching [RFC4950] and ICMP extensions for 247 interface and next-hop identification [RFC5837]. 249 Extensions to ICMP should follow [RFC4884]. 251 2.4. ICMPv4 vs. ICMPv6 253 Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 254 routers, IPv6-capable security gateways, and IPv6-capable firewalls 255 normally support administrator configuration of how specific ICMPv6 256 message types are handled. By contrast, deployed IPv4 routers, IPv4- 257 capable security gateways, and IPv4-capable firewalls are less likely 258 to allow an administrator to configure how specific ICMPv4 message 259 types are handled. So, at present, ICMPv6 messages usually have a 260 higher probability of travelling end-to-end than ICMPv4 messages. 262 3. ICMP's role in the internet 264 ICMP was originally intended to be a mechanism for gateways or 265 destination hosts to report error conditions back to source hosts in 266 ICMPv4 [RFC0792], and ICMPv6 [RFC4443] is modeled after it. ICMP is 267 also used to perform IP-layer functions, such as diagnostics (e.g., 268 "PING"). 270 ICMP is defined to be an integral part of IP, and must be implemented 271 by every IP module. This is true for ICMPv4 as an integral part of 272 IPv4 (see the Introduction of [RFC0792]), and for ICMPv6 as an 273 integral part of IPv6 (see Section 2 of [RFC4443]). When first 274 defined, ICMP messages were thought of as IP messages that didn't 275 carry any higher layer data. It could be conjectured that the term 276 "control" was used given that ICMP messages were not "data" messages. 278 The word "control" in the protocol name did not describe ICMP's 279 function (i.e. it did not "control" the internet), but rather that it 280 was used to communicate about the control functions in the internet. 281 For example, even though ICMP included a redirect message type that 282 affects routing behavior in the context of a LAN segment, it was and 283 is not used as a generic routing protocol. 285 4. Security considerations 287 This document describes a high-level policy for adding ICMP types and 288 codes. While special attention must be paid to the security 289 implications of any particular new ICMP type or code, this 290 recommendation presents no new security considerations. 292 From a security perspective, ICMP plays a part in the Photuris 293 [RFC2521] protocol. But more generally, ICMP is not a secure 294 protocol, and does not include features to be used to discover 295 network security parameters or to report on network security 296 anomalies in the forwarding plane. 298 Additionally, new ICMP functionality (e.g., ICMP extensions, or new 299 ICMP types or codes) needs to consider potential ways of how ICMP can 300 be abused (e.g., Smurf IP DoS [CA-1998-01]). 302 5. IANA considerations 304 There are no actions required by IANA. 306 6. Acknowledgments 308 This document was originally proposed by, and received substantial 309 review and suggestions from, Ron Bonica. Discussions with Pascal 310 Thubert helped clarify the history of RPL's use of ICMP. We are very 311 grateful for the review, feedback, and comments from Ran Atkinson, 312 Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric 313 Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much 314 improved document. 316 7. Informative references 318 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 319 RFC 792, September 1981. 321 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 322 Values In the Internet Protocol and Related Headers", 323 BCP 37, RFC 2780, March 2000. 325 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 326 Message Protocol (ICMPv6) for the Internet Protocol 327 Version 6 (IPv6) Specification", RFC 4443, March 2006. 329 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 330 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 331 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 332 Lossy Networks", RFC 6550, March 2012. 334 [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some 335 ICMPv4 Message Types", RFC 6918, April 2013. 337 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 338 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 339 April 2007. 341 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 342 Extensions for Multiprotocol Label Switching", RFC 4950, 343 August 2007. 345 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 346 Rivers, "Extending ICMP for Interface and Next-Hop 347 Identification", RFC 5837, April 2010. 349 [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures 350 Messages", RFC 2521, March 1999. 352 [CA-1998-01] 353 CERT, "Smurf IP Denial-of-Service Attacks", CERT 354 Advisory CA-1998-01, January 1998, 355 . 357 [1] 359 Authors' Addresses 361 Melinda Shore 362 No Mountain Software 363 PO Box 16271 364 Two Rivers, AK 99716 365 US 367 Phone: +1 907 322 9522 368 Email: melinda.shore@nomountain.net 370 Carlos Pignataro 371 Cisco Systems, Inc. 372 7200-12 Kit Creek Road 373 Research Triangle Park, NC 27709 374 US 376 Email: cpignata@cisco.com