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