Internet Area Working Group M. Welzl Internet-Draft University of Oslo Intended status: Experimental J. You Expires: January 1, 2016 Huawei June 30, 2015 Text messaging to middlebox administrators using ICMP draft-welzl-icmp-text-middleboxes-00 Abstract This document describes the use of an ICMP message to send text messages to on-path middleboxes from the endpoints. The text message is sent towards a destination but meant to be read by administrators of middleboxes along the path to the destination. The goal is to improve the user's experience with simple middlebox cooperation. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 1, 2016. Copyright Notice Copyright (c) 2015 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 Welzl & You Expires January 1, 2016 [Page 1] Internet-Draft Text messaging with ICMP June 2015 (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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Welzl & You Expires January 1, 2016 [Page 2] Internet-Draft Text messaging with ICMP June 2015 1. Introduction Middleboxes such as firewalls do often not cooperate with endpoints. Sometimes, services that are important to users at endpoints can be unavailable because the necessary communication is blocked as a result of a simple policy decision such as "block everything that is unknown". This can unnecessarily degrade the user experience. The common way for a user to deal with this problem is to use offline methods to determine the administrator (e.g. via a phone directory) and then use other means of communication (e.g. a phone call or an email). However, sometimes, the person in charge of the middlebox that created the problem is not known to the user. In this case, being able to send a text message that at least reaches the problematic device is perhaps better than nothing. This document defines a new ICMP message called "Plaintext" in order to support the transmission and identification of such text messages. These messages can, for example, be generated by a ping-like tool, or automatically generated by an application when a requested communication does not work. The goal is to improve the user experience via simple middlebox cooperation. The message is sent to a destination IP address -- preferrably the address with which communication did not work as intended -- and meant to be read by middleboxes along the path. The hope is that, if a middlebox drops the packet, it is the middlebox that the message was meant to reach anyway. 2. Specification The source host creates an ICMP Plaintext message, encapsulates it in an IP packet having source address = IP address of the source host, destination address = IP address of the destination host and forwards it. Upon receipt of this message from the source host, on-path middleboxes might read the content, forward the packet without reading the content, or drop the packet. Middleboxes SHOULD forward ICMP packets carrying an ICMP Plaintext message towards the destination. At a middlebox, the information carried in the message can be recorded in a log file. The administrator of the middleboxes might read the log file at a suitable time and adjust policies for some services on its basis, or just ignore the information without doing anything. If a Plaintext message passes all the way to the destination, the destination may log or just ignore the message; it is not the Welzl & You Expires January 1, 2016 [Page 3] Internet-Draft Text messaging with ICMP June 2015 intended recipient. No reply is expected to be sent in response to a Plaintext message. The format of the ICMPv6 [RFC4443] Plaintext message is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- IPv6 Fields: Destination address: IP address of the destination host. ICMPv6 Fields: Type: TBD1 Code: Set to 0 by the originator and ignored by the receiver. Checksum: Used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. Data: Zero or more octets of arbitrary data in the ASCII format. XXX Author's note: future versions of this draft will specify the ICMPv4 message. XXX 3. Use Cases Usually ICMP is used by nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics. In this document, ICMP is extended to allow text messages from the endpoints to be communicated to on-path middleboxes. Rather than providing a long-winded description of possible use cases, we present some example messages that an ICMP Plaintext message might contain and assume that they are self-explanatory about the actual usage scenario: "This is Michael Welzl, sitting in office 4164 at IFI. I want to run videoconferencing software XY that I need for a project I'm in, but Welzl & You Expires January 1, 2016 [Page 4] Internet-Draft Text messaging with ICMP June 2015 it doesn't seem to work. I think you blocked some UDP ports there. Not good, please fix and get back to me." "Hello, I like the WiFi that's being provided at this airport! But did you notice that there is almost no reception near the C gates in terminal 3?" "Dear ISP, I'm trying to run native SCTP here but packets won't pass through your network it seems. I'm paying a fortune, please let my packets pass!" "The lady at the reception said it's fine to use VoIp in this hotel, but my phone software xy can't connect. Else the network seems to work fine. Please fix; room 302." 4. IANA Considerations This document defines a new ICMPv6 informational messages: Type: TBD1 Plaintext (see Section 2) 5. Security Considerations The ICMP plaintext message is meant to be advisory in nature, and known to be unreliable. There is no authentification of the origin of the message, meaning that administrators of middleboxes should not automatically trust its content. For example, a request to open a port to support a specific application could originate from a malicious source. 6. Acknowledgement TBD. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. Welzl & You Expires January 1, 2016 [Page 5] Internet-Draft Text messaging with ICMP June 2015 Authors' Addresses Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Email: michawe@ifi.uio.no Jianjie You Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China Email: youjianjie@huawei.com Welzl & You Expires January 1, 2016 [Page 6]