One document matched: draft-eastlake-ip-mime-07.txt

Differences from draft-eastlake-ip-mime-06.txt

INTERNET-DRAFT                                           D. Eastlake 3rd
Expires: October 2003                                         April 2003



                              IP over MIME
                              -- ---- ----
                    <draft-eastlake-ip-mime-07.txt>




Status of This Document

   Distribution of this document is unlimited. Comments should be sent
   to the author.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Abstract

   The MIME encoding of IP packets is standardized enabling them to be
   sent via MAIL, HTTP, etc.  This may be convenient for transmitting
   packets for analysis or for creating application level SP tunnels.



Acknowledgement

   Helpful suggestions from Matt Crawford, Mike Ditto, and Stanislav
   Shalunov have been incorporated herein.







D. Eastlake 3rd                                                 [Page 1]


INTERNET-DRAFT                IP over MIME                  January 2002


Table of Contents

      Status of This Document....................................1
      Abstract...................................................1
      Acknowledgement............................................1

      Table of Contents..........................................2

      1. Introduction............................................3
      2. MIME Type Specification.................................4
      3. Security Considerations.................................6

      Normative References.......................................7
      Informative Referecnes.....................................7
      Author's Address...........................................8
      Expiration and File Name...................................8




































D. Eastlake 3rd                                                 [Page 2]


INTERNET-DRAFT                IP over MIME                  January 2002


1. Introduction

   The Internet Protocol (IP [RFC 791]) has been profiled for
   transmission over a wide variety of media including Ethernet [RFC
   894], point to point circuits [RFC 1661], FDDI [RFC 1390], and even
   avian carriers [RFC 1149], etc.  And one of the most popular encoding
   and labeling (AKA, tagging and bagging) techniques defined for the
   TCP/IP protocol suite is the MIME encoding [RFC 2045, 2046] used, for
   example, in email, the web, and net news. This document specifies how
   to transmit IP over MIME.

   An unambiguous MIME encoding for IP datagrams is useful in their
   transmission for monitoring, analysis, debugging, or illustrative
   purposes.

   In addition, IP over MIME can be effective as one component in
   creating application level tunnels.  With the aid of cooperative
   software IP connectivity can be established tunneling the packets
   through a MIME channel.  The following diagram shows such a possible
   tunnel configuration:

                                Internet/Firwalls
                  SMTP/HTTP/...     |
                      +-------------|------------+
                      |             |            |
          Host A      |h/w          |         h/w|       Host B
         +------------|----------+  |  +---------|-------------+
         |            |          |  |  |         |             |
         |            v          |  |  |         v             |
         |  +-----------------+  |  |  |  +-----------------+  |
         |  | Real IP | Stack |  |     |  | Real | IP Stack |  |
         |  +-----------------+  |     |  +-----------------+  |
         |    ^s/w    ^          |     |         ^     s/w^    |
         |    :       |          |     |         |        :    |
         |    :       v          |     |         v        :    |
         |    :  +------------+  |     |  +------------+  :    |
         |    :.>| Application|  |     |  |Application |<.:    |
         |       +------------+  |     |  +------------+       |
         +-----------------------+     +-----------------------+

   Hosts A and B have hardware network interface (h/w) by which they can
   communicate using IP.  Applications capable of MIME encoding IP exist
   on both Hosts.  Through proper registry by the applications with
   their local IP stack (which may require special privileges), real IP
   stack to real IP stack IP connectivity can be established.  Depending
   on the addressing environments of Host A and B, incorporation of NAT
   [RFC 3022] technology into these applications may also be helpful.





D. Eastlake 3rd                                                 [Page 3]


INTERNET-DRAFT                IP over MIME                  January 2002


2. MIME Type Specification

   MIME media type name: APPLICATION

   MIME subtype name: IP

   Required parameters: version

      version=n
         This parameter exposes the IP Version number [RFC 791] in the
         MIME Content-Type.

   Optional parameters: dilation, address

      dilation=nnn
         Typically IP packets will be MIME labeled for transmission over
         email or other application level protocols.  Such transmission
         is normally slower than lower level network protocols.  While
         this is not much of a concern if a packet is just being
         communicated for analysis, if such transmission is used to
         establish connectivity, the sender of a datagram may wish to
         advise the recipient of the estimated time dilation factor.
         For example, if datagrams typically take around a second and
         occasionally up to ten seconds end-to-end but it is more like a
         minute and occasionally up to ten minutes if they are MIME
         encoded in email, a "dilation=60" parameter would be
         reasonable.

         Impelementation Note: Although IP and TCP are defined as timing
         independent protocols, many implementations actually have
         timeouts built in.  In some cases, an effective technique to
         defeat these timeouts is to repeatedly resend the last packet
         received.  This is, if a MIME encoded TCP packet is being sent
         from Host A to Host B in the figure above where the
         applications are gatewaying the packets to the real IP stack,
         repeated transmission of this packet by the application on Host
         B to the stack may stave off timeouts.  Similarly, the repeated
         transmission to the real IP stack on Host A of the last reply
         TCP packet may stave off timeouts there.

      address=xxxx
         Full, if slow, IP connectivity via an application level
         protocol such as SMTP [RFC 2821, 2822] might require that
         routing, tunneling, and/or interface entries be installed at
         each end. Routing entries would be best created or updated by
         routing protocol messages and the establishment of tunnels is
         beyond the scope of this MIME type. However, the "address="
         parameter enables the sender to optionally indicate an IP
         address for itself.  This may only be useful in cases where the
         sender knows an address that is available for itself in the


D. Eastlake 3rd                                                 [Page 4]


INTERNET-DRAFT                IP over MIME                  January 2002


         recipient's addressing environment. It can be viewed as a
         replacement for ARP [RFC 826] on the possible path to the
         source of the APPLICATION/IP object via the same application
         level protocol.  (A receiver of such an APPLICATION/IP object
         with an "address=" parameter might reasonably require that it
         be authenticated as meeting their policy as to from whom they
         would accept such information.  For example, they could ignore
         "address=" parameters unless the APPLICATION/IP object was
         wrapped in an acceptable MULTIPART/SIGNED [RFC 1847]
         authentication, although that implies some trust relationship
         between the parties.)

         Examples:

            address="10.100.1.10"

            address="1080:0:0:0:8:800:200C:4171"

   Encoding considerations: Because of the binary nature of the body,
         BASE64 transfer encoding should normally be used.

   Security considerations: Care should be taken under any circumstance
         where APPLCIATION/IP content can be treated as a "live" packet.
         MULTIPART/ENCRYPTED and MULTIPART/SIGNED [RFC 1847] may be used
         to protect and/or authenticate MIME packaged IP traffic.

   Interoperability considerations: See [draft-eastlake-ip-mime-*.txt].

      MULTIPART/MIXED [RFC 2046] may be used to package multiple IP
         datagrams together.

   Published specification: See [draft-eastlake-ip-mime-*.txt].

   Applications which use this media type: Not yet in use.  See also
         [RFC 3093].

   Additional information: (none)

   Person & email address to contact for further information:
      Donald E. Eastlake 3rd, dee3@torque.pothole.com

   Intended usage: LIMITED USE

   Author/Change controller: IETF








D. Eastlake 3rd                                                 [Page 5]


INTERNET-DRAFT                IP over MIME                  January 2002


3. Security Considerations

   Because most systems are configures to allow MIME labeled SMTP [RFC
   2821] and HTTP [RFC 2616] payloads through their firewalls, care
   should be taken concerning the posibility of APPLICATION/IP payloads
   thereby bypassing firewall protection and being treated as a live
   packet.  It would require a possibly privileged accomplice or some
   other weakness to install code within a security perimeter that would
   actually process incoming APPLICATION/IP data; however, once this is
   done, general, if slow, IP connectivity could be established.

   See also security considerations in Section 2 above.








































D. Eastlake 3rd                                                 [Page 6]


INTERNET-DRAFT                IP over MIME                  January 2002


Normative References

   [RFC 791] - "Internet Protocol", J. Postel, Sep-01-1981.

   [RFC 894] - "Standard for the transmission of IP datagrams over
   Ethernet networks", C. Hornig, Apr-01-1984.

   [RFC 1847] - "Security Multiparts for MIME: Multipart/Signed and
   Multipart/Encrypted", J. Galvin, S. Murphy, S. Crocker, N. Freed,
   October 1995.

   [RFC 2045] - "Multipurpose Internet Mail Extensions (MIME) Part One:
   Format of Internet Message Bodies", N. Freed & N. Borenstein,
   November 1996.

   [RFC 2046] - "Multipurpose Internet Mail Extensions (MIME) Part Two:
   Media Types", N. Freed, N. Borenstein, November 1996.



Informative Referecnes

   [RFC 826] - Ethernet Address Resolution Protocol, D.C. Plummer,
   Nov-01-1982.

   [RFC 1149] - "Standard for the transmission of IP datagrams on avian
   carriers", D.  Waitzman, Apr-01-1990.

   [RFC 1390] - "Transmission of IP and ARP over FDDI Networks", D.
   Katz, January 1993.

   [RFC 1661] - "The Point-to-Point Protocol (PPP)", W. Simpson, July
   1994.

   [RFC 2616] - "Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding,
   J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-
   Lee, June 1999.

   [RFC 2821] - "Simple Mail Transfer Protocol", J. Klensin, April 2001.

   [RFC 2822] - "Internet Message Format", P. Resnick, April 2001.

   [RFC 3022] - "Traditional IP Network Address Translator (Traditional
   NAT)", P. Srisuresh, K. Egevang, January 2001.

   [RFC 3093] - "Firewall Enhancement Protocol (FEP)", M. Gaynor, S.
   Bradner, 1 April 2001.





D. Eastlake 3rd                                                 [Page 7]


INTERNET-DRAFT                IP over MIME                  January 2002


Author's Address

   Donald E. Eastlake, 3rd
   155 Beaver Street
   Milford, MA 01757 USA

   Telephone:   +1 508-634-2066 (h)
                +1 508-851-8280 (w)
   email:       dee3@torque.pothole.com



Expiration and File Name

   This draft expires October 2003.

   Its file name is draft-eastlake-ip-mime-07.txt.



































D. Eastlake 3rd                                                 [Page 8]