Internet DRAFT - draft-eastlake-mime-ip

draft-eastlake-mime-ip



INTERNET-DRAFT                                           D. Eastlake 3rd
Expires: February 2000                                       August 1999



                              IP over MIME
                              -- ---- ----

                        Donald E. Eastlake, 3rd




Status of This Document

   This draft is file name draft-eastlake-ip-mime-00.txt.  It is
   intended to become a Proposed Standard RFC.  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 RFC2026.  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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``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.





















D. Eastlake 3rd                                                 [Page 1]


INTERNET-DRAFT                IP over MIME                   August 1999


Abstract

   The MIME encoding of IP packets is standardized so they can
   conveniently be sent via MAIL, HTTP, etc.  This may be convenient for
   transmitting packets for analysis or monitoring and for creating
   covert channels.



Table of Contents

      Status of This Document....................................1

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

      1. Introduction............................................3
      2. Specification...........................................4
      3. Security Considerations.................................5

      References.................................................6
      Author's Address...........................................6
      Expiration and File Name...................................6





























D. Eastlake 3rd                                                 [Page 2]


INTERNET-DRAFT                IP over MIME                   August 1999


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].  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] used in email, the
   web, and net news. This document rectifies the omission that IP over
   MIME has not previously been profiled.

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

   In addition, IP over MIME is particularly effective as one component
   in creating covert channels that bypass firewall protections.  With
   the aid of cooperative software running within a firewall,
   unrestricted, if slow, IP connectivity can be established.

   The following diagram such a possible covert channel configuration:

                           Internet/Barrier
            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, incorporate of NAT
   [RFC 1631] technology into these applications may also be helpful.






D. Eastlake 3rd                                                 [Page 3]


INTERNET-DRAFT                IP over MIME                   August 1999


2. Specification

   Type/subtype:

      APPLICATION/IP

   Transfer Encoding:

      Becasue of the binary nature of the body, BASE64 transfer encoding
         should normally be used.

   Parameters:

      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.  If such
         transmission is being used to establish connectivity, the
         sender of a datagram may wish to advice the recipient of the
         estimated time dilation factor.  For example, if datagrams
         typically take around a second and occsionally up to ten
         seconds end-to-end but its more like a minute and occasionally
         up to ten minutes if they are MIME encoded in email, a
         "dilation=60" parameter would be reasonable.  Although IP and
         TCP are defined as timing idependent protocols, many
         implementations actually have timeouts built in.  An effective
         technique in some cases 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 transmisison 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 time outs
         there.

      address=xxx,mmm
         Full, if slow, IP connectivity via an application level
         protocol such as RFC 822 email, in the absence of NAT
         technology, would require that routing nad/or interface entries
         be installed at each end.  This parameter enables the sender to
         indicate what address mask and value it wishes to have
         installed in routing and/or interfacetables at the receiver
         host so as to accomplish this. Return traffic matching this
         address/mask should be routed as indicated for specific
         protocols below.  A ficticious example would be
         "address=10.9.8.0,255.255.255.0".





D. Eastlake 3rd                                                 [Page 4]


INTERNET-DRAFT                IP over MIME                   August 1999


   Other:

      MULTIPART/MIXED may be used to package multiple IP datagrams
         together.

      MULTIPART/ENCRYPTED [RFC 1847] may be used to further disguise IP
         cover channels.



3. Security Considerations

   The APPLICATION/IP MIME type is particularly suitable as an
   illustration of the weakness of the "crunchy outside, soft interior"
   security model which places undue dependence on firewalls or similar
   perimeter security.  While it would require a possibly privileged
   accomplice or some other weakness to install code within a security
   perimeter that would actually process income APPLICATION/IP data,
   once this is done, general, if slow, IP connectivity can normally be
   established because HTTP, email, and the like are typically given
   free passage through firewalls.































D. Eastlake 3rd                                                 [Page 5]


INTERNET-DRAFT                IP over MIME                   August 1999


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 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 1631 - "The IP Network Address Translator (NAT)", K. Egevang, P.
   Francis, May 1994

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

   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.



Author's Address

   Donald E. Eastlake, 3rd
   IBM
   65 Shindegan Hill Road
   Carmel, NY 10512 USA

   Telephone:   +1 914-276-2668 (h)
                +1 914-784-7913 (w)
   fax:         +1 914-784-3833 (w)
   email:       dee3@torque.pothole.com



Expiration and File Name

   This draft expires February 2000.

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




D. Eastlake 3rd                                                 [Page 6]