idnits 2.17.1 draft-welzl-icmp-text-middleboxes-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 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 (June 30, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- 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 Internet Area Working Group M. Welzl 3 Internet-Draft University of Oslo 4 Intended status: Experimental J. You 5 Expires: January 1, 2016 Huawei 6 June 30, 2015 8 Text messaging to middlebox administrators using ICMP 9 draft-welzl-icmp-text-middleboxes-00 11 Abstract 13 This document describes the use of an ICMP message to send text 14 messages to on-path middleboxes from the endpoints. The text message 15 is sent towards a destination but meant to be read by administrators 16 of middleboxes along the path to the destination. The goal is to 17 improve the user's experience with simple middlebox cooperation. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 1, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 Middleboxes such as firewalls do often not cooperate with endpoints. 71 Sometimes, services that are important to users at endpoints can be 72 unavailable because the necessary communication is blocked as a 73 result of a simple policy decision such as "block everything that is 74 unknown". This can unnecessarily degrade the user experience. 76 The common way for a user to deal with this problem is to use offline 77 methods to determine the administrator (e.g. via a phone directory) 78 and then use other means of communication (e.g. a phone call or an 79 email). However, sometimes, the person in charge of the middlebox 80 that created the problem is not known to the user. In this case, 81 being able to send a text message that at least reaches the 82 problematic device is perhaps better than nothing. 84 This document defines a new ICMP message called "Plaintext" in order 85 to support the transmission and identification of such text messages. 86 These messages can, for example, be generated by a ping-like tool, or 87 automatically generated by an application when a requested 88 communication does not work. The goal is to improve the user 89 experience via simple middlebox cooperation. The message is sent to 90 a destination IP address -- preferrably the address with which 91 communication did not work as intended -- and meant to be read by 92 middleboxes along the path. The hope is that, if a middlebox drops 93 the packet, it is the middlebox that the message was meant to reach 94 anyway. 96 2. Specification 98 The source host creates an ICMP Plaintext message, encapsulates it in 99 an IP packet having source address = IP address of the source host, 100 destination address = IP address of the destination host and forwards 101 it. 103 Upon receipt of this message from the source host, on-path 104 middleboxes might read the content, forward the packet without 105 reading the content, or drop the packet. Middleboxes SHOULD forward 106 ICMP packets carrying an ICMP Plaintext message towards the 107 destination. At a middlebox, the information carried in the message 108 can be recorded in a log file. The administrator of the middleboxes 109 might read the log file at a suitable time and adjust policies for 110 some services on its basis, or just ignore the information without 111 doing anything. 113 If a Plaintext message passes all the way to the destination, the 114 destination may log or just ignore the message; it is not the 115 intended recipient. 117 No reply is expected to be sent in response to a Plaintext message. 119 The format of the ICMPv6 [RFC4443] Plaintext message is defined as 120 follows: 121 0 1 2 3 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type | Code | Checksum | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Data ... 127 +-+-+-+-+- 129 IPv6 Fields: 131 Destination address: IP address of the destination host. 133 ICMPv6 Fields: 135 Type: TBD1 137 Code: Set to 0 by the originator and ignored by the receiver. 139 Checksum: Used to detect data corruption in the ICMPv6 message and 140 parts of the IPv6 header. 142 Data: Zero or more octets of arbitrary data in the ASCII format. 144 XXX Author's note: future versions of this draft will specify the 145 ICMPv4 message. XXX 147 3. Use Cases 149 Usually ICMP is used by nodes to report errors encountered in 150 processing packets, and to perform other internet-layer functions, 151 such as diagnostics. In this document, ICMP is extended to allow 152 text messages from the endpoints to be communicated to on-path 153 middleboxes. 155 Rather than providing a long-winded description of possible use 156 cases, we present some example messages that an ICMP Plaintext 157 message might contain and assume that they are self-explanatory about 158 the actual usage scenario: 160 "This is Michael Welzl, sitting in office 4164 at IFI. I want to run 161 videoconferencing software XY that I need for a project I'm in, but 162 it doesn't seem to work. I think you blocked some UDP ports there. 163 Not good, please fix and get back to me." 165 "Hello, I like the WiFi that's being provided at this airport! But 166 did you notice that there is almost no reception near the C gates in 167 terminal 3?" 169 "Dear ISP, I'm trying to run native SCTP here but packets won't pass 170 through your network it seems. I'm paying a fortune, please let my 171 packets pass!" 173 "The lady at the reception said it's fine to use VoIp in this hotel, 174 but my phone software xy can't connect. Else the network seems to 175 work fine. Please fix; room 302." 177 4. IANA Considerations 179 This document defines a new ICMPv6 informational messages: 180 Type: TBD1 Plaintext (see Section 2) 182 5. Security Considerations 184 The ICMP plaintext message is meant to be advisory in nature, and 185 known to be unreliable. There is no authentification of the origin 186 of the message, meaning that administrators of middleboxes should not 187 automatically trust its content. For example, a request to open a 188 port to support a specific application could originate from a 189 malicious source. 191 6. Acknowledgement 193 TBD. 195 7. Normative References 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 201 Message Protocol (ICMPv6) for the Internet Protocol 202 Version 6 (IPv6) Specification", RFC 4443, March 2006. 204 Authors' Addresses 206 Michael Welzl 207 University of Oslo 208 PO Box 1080 Blindern 209 Oslo N-0316 210 Norway 212 Email: michawe@ifi.uio.no 214 Jianjie You 215 Huawei 216 101 Software Avenue, Yuhua District 217 Nanjing 210012 218 China 220 Email: youjianjie@huawei.com