Network Working Group M. Shore Internet-Draft No Mountain Software Expires: January 10, 2013 C. Pignataro Cisco Systems, Inc. July 9, 2012 An Acceptable Use Policy for New ICMP Types and Codes draft-shore-icmp-aup-00 Abstract Some recent proposals to add new Internet Control Message Protocol (ICMP) types and/or codes have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not. In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for the future. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 10, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Shore & Pignataro Expires January 10, 2013 [Page 1] Internet-Draft ICMP AUP July 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ICMP's role in the internet . . . . . . . . . . . . . . . . . 4 3. Management vs control . . . . . . . . . . . . . . . . . . . . 5 4. Where ICMP fits . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Informative references . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Shore & Pignataro Expires January 10, 2013 [Page 2] Internet-Draft ICMP AUP July 2012 1. Introduction There have been some recent proposals to add new message types and codes to ICMP [RFC792] (see, for example, [templin]). Not all of these proposal are consistent with the design and intent of ICMP, and so we attempt to lay out a description of when (and when not) to move functionality into ICMP. This document is the result of discussions within the IETF Operations area "ICMP Society," and concerns expressed by the OPS area leadership. Shore & Pignataro Expires January 10, 2013 [Page 3] Internet-Draft ICMP AUP July 2012 2. ICMP's role in the internet ICMP was originally intended to be a mechanism for routers to report error conditions back to hosts [RFC792]. The word "control" in the protocol name did not describe ICMP's function (i.e. it did not "control" the internet), but rather that it was used to communicate about the control functions in the internet. For example, even though ICMP included a redirect message type, it was and is not used as a routing protocol. Most likely because of the presence of the word "control" in the protocol name, ICMP is often understood to be a control protocol, borrowing some terminology from circuit networks and the PSTN. That is probably not correct - it might be more correct to describe it as being closer to a management plane protocol, given the data plane/ control plane/ management plane taxonomy often used in describing telephony protocols. However, layering in IP networks is not very clean and there's often some intermingling of function that can tend to lead to confusion about where to place new functions. This document provides some background on the differences between control and management traffic, and finishes by proposing that any future additional ICMP types or codes be limited to what in telephony networks would be considered management plane traffic. Shore & Pignataro Expires January 10, 2013 [Page 4] Internet-Draft ICMP AUP July 2012 3. Management vs control In this section we attempt to draw a distinction between management and control planes, acknowledging in advance that this may serve to muddle the differences even further. Ultimately the difference may not matter that much for the purpose of creating a policy for adding new types to ICMP, but because that terminology has become ubiquitous, even in IETF discussions, and because it has come up in prior discussions of ICMP policies, it seems worthwhile to take a few paragraph to describe what they are and what they are not. The terms "management plane" and "control plane" came into use to describe one aspect of layering in telecommunications networks. It is particularly important, in the context of this discussion, to understand that "control plane" in telecomm networks almost always refers to 'signaling,' or call control and network control information. This includes "call" establishment and teardown, route establishment and teardown, requesting QoS or other parameters, and so on. "Management," on the other hand, tends to fall under the rubric "OAM," or "Operations, Administration, and Management." typical functions include fault management and performance monitoring (Service Level Agreement [SLA] compliance), discovery, etc. Shore & Pignataro Expires January 10, 2013 [Page 5] Internet-Draft ICMP AUP July 2012 4. Where ICMP fits The correct answer to the question of where ICMP fits into the management/control/data taxonomy is that it doesn't, at least not neatly. While some of the message types are unambiguously management message (ICMP type 3, or "unreachable" messages), others are less clearly identifiable. For example, the "redirect" (ICMP type 5) message can be construed to contain control (in this case, routing) information, even though it is in some very real sense an error message. At this time, o there are many, many other protocols that can be (and are) used for control traffic, whether they're routing protocols, telephony signaling protocols, QoS protocols, middlebox protocols, AAA protocols, etc. o the transport characteristics needed by control traffic can be incompatible with the ICMP protocol standard -- for example, they may require reliable delivery, very large payloads, or have security requirements that cannot be met. and because of thiswe propose that any future message types added to ICMP must stay within the "management plane" domain, and in particular that it would not be appropriate or desirable for control (or signaling) messages to be conveyed by ICMP. Shore & Pignataro Expires January 10, 2013 [Page 6] Internet-Draft ICMP AUP July 2012 5. Security considerations This document attempts to describe a high-level policy for adding ICMP types and codes. While special attention must be paid to the security implications of any particular new ICMP type or code, specific security considerations are outside the scope of this paper. Shore & Pignataro Expires January 10, 2013 [Page 7] Internet-Draft ICMP AUP July 2012 6. IANA considerations There are no actions required by IANA. Shore & Pignataro Expires January 10, 2013 [Page 8] Internet-Draft ICMP AUP July 2012 7. Informative references [RFC792] Postel, J., "INTERNET CONTROL MESSAGE PROTOCOL", RFC 792, September 1981. [templin] Templin, F., "Asymmetric Extended Route Optimization (AERO)", draft-templin-aero-08 (work in progress), February 2012. Shore & Pignataro Expires January 10, 2013 [Page 9] Internet-Draft ICMP AUP July 2012 Authors' Addresses Melinda Shore No Mountain Software PO Box 16271 Two Rivers, AK 99716 US Phone: +1 907 322 9522 Email: melinda.shore@nomountain.net Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: cpignata@cisc.com Shore & Pignataro Expires January 10, 2013 [Page 10]