idnits 2.17.1 draft-shore-icmp-aup-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 'Intended status' indicated for this document; assuming Proposed Standard 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 (July 9, 2012) is 4302 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: 'SLA' is mentioned on line 122, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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 Expires: January 10, 2013 C. Pignataro 5 Cisco Systems, Inc. 6 July 9, 2012 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-00 11 Abstract 13 Some recent proposals to add new Internet Control Message Protocol 14 (ICMP) types and/or codes have highlighted a need to describe 15 policies for when adding new features to ICMP is desirable and when 16 it is not. In this document we provide a basic description of ICMP's 17 role in the IP stack and some guidelines for the future. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 10, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. ICMP's role in the internet . . . . . . . . . . . . . . . . . 4 55 3. Management vs control . . . . . . . . . . . . . . . . . . . . 5 56 4. Where ICMP fits . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 58 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7. Informative references . . . . . . . . . . . . . . . . . . . . 9 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 62 1. Introduction 64 There have been some recent proposals to add new message types and 65 codes to ICMP [RFC792] (see, for example, [templin]). Not all of 66 these proposal are consistent with the design and intent of ICMP, and 67 so we attempt to lay out a description of when (and when not) to move 68 functionality into ICMP. 70 This document is the result of discussions within the IETF Operations 71 area "ICMP Society," and concerns expressed by the OPS area 72 leadership. 74 2. ICMP's role in the internet 76 ICMP was originally intended to be a mechanism for routers to report 77 error conditions back to hosts [RFC792]. The word "control" in the 78 protocol name did not describe ICMP's function (i.e. it did not 79 "control" the internet), but rather that it was used to communicate 80 about the control functions in the internet. For example, even 81 though ICMP included a redirect message type, it was and is not used 82 as a routing protocol. 84 Most likely because of the presence of the word "control" in the 85 protocol name, ICMP is often understood to be a control protocol, 86 borrowing some terminology from circuit networks and the PSTN. That 87 is probably not correct - it might be more correct to describe it as 88 being closer to a management plane protocol, given the data plane/ 89 control plane/ management plane taxonomy often used in describing 90 telephony protocols. However, layering in IP networks is not very 91 clean and there's often some intermingling of function that can tend 92 to lead to confusion about where to place new functions. 94 This document provides some background on the differences between 95 control and management traffic, and finishes by proposing that any 96 future additional ICMP types or codes be limited to what in telephony 97 networks would be considered management plane traffic. 99 3. Management vs control 101 In this section we attempt to draw a distinction between management 102 and control planes, acknowledging in advance that this may serve to 103 muddle the differences even further. Ultimately the difference may 104 not matter that much for the purpose of creating a policy for adding 105 new types to ICMP, but because that terminology has become 106 ubiquitous, even in IETF discussions, and because it has come up in 107 prior discussions of ICMP policies, it seems worthwhile to take a few 108 paragraph to describe what they are and what they are not. 110 The terms "management plane" and "control plane" came into use to 111 describe one aspect of layering in telecommunications networks. It 112 is particularly important, in the context of this discussion, to 113 understand that "control plane" in telecomm networks almost always 114 refers to 'signaling,' or call control and network control 115 information. This includes "call" establishment and teardown, route 116 establishment and teardown, requesting QoS or other parameters, and 117 so on. 119 "Management," on the other hand, tends to fall under the rubric 120 "OAM," or "Operations, Administration, and Management." typical 121 functions include fault management and performance monitoring 122 (Service Level Agreement [SLA] compliance), discovery, etc. 124 4. Where ICMP fits 126 The correct answer to the question of where ICMP fits into the 127 management/control/data taxonomy is that it doesn't, at least not 128 neatly. While some of the message types are unambiguously management 129 message (ICMP type 3, or "unreachable" messages), others are less 130 clearly identifiable. For example, the "redirect" (ICMP type 5) 131 message can be construed to contain control (in this case, routing) 132 information, even though it is in some very real sense an error 133 message. 135 At this time, 137 o there are many, many other protocols that can be (and are) used 138 for control traffic, whether they're routing protocols, telephony 139 signaling protocols, QoS protocols, middlebox protocols, AAA 140 protocols, etc. 142 o the transport characteristics needed by control traffic can be 143 incompatible with the ICMP protocol standard -- for example, they 144 may require reliable delivery, very large payloads, or have 145 security requirements that cannot be met. 147 and because of thiswe propose that any future message types added to 148 ICMP must stay within the "management plane" domain, and in 149 particular that it would not be appropriate or desirable for control 150 (or signaling) messages to be conveyed by ICMP. 152 5. Security considerations 154 This document attempts to describe a high-level policy for adding 155 ICMP types and codes. While special attention must be paid to the 156 security implications of any particular new ICMP type or code, 157 specific security considerations are outside the scope of this paper. 159 6. IANA considerations 161 There are no actions required by IANA. 163 7. Informative references 165 [RFC792] Postel, J., "INTERNET CONTROL MESSAGE PROTOCOL", RFC 792, 166 September 1981. 168 [templin] Templin, F., "Asymmetric Extended Route Optimization 169 (AERO)", draft-templin-aero-08 (work in progress), 170 February 2012. 172 Authors' Addresses 174 Melinda Shore 175 No Mountain Software 176 PO Box 16271 177 Two Rivers, AK 99716 178 US 180 Phone: +1 907 322 9522 181 Email: melinda.shore@nomountain.net 183 Carlos Pignataro 184 Cisco Systems, Inc. 185 7200-12 Kit Creek Road 186 Research Triangle Park, NC 27709 187 US 189 Email: cpignata@cisc.com