[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/