INTERNET-DRAFT D. Eastlake 3rd Expires: December 2000 June 2000 IP over MIME -- ---- ---- 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 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 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 so they can conveniently be sent via MAIL, HTTP, etc. This may be convenient for transmitting packets for analysis or for creating application level tunnels. Acknowledgement Helpful suggestions from Matt Crawford and Mike Ditto have been incorporated herein. D. Eastlake 3rd [Page 1] INTERNET-DRAFT IP over MIME June 2000 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.................................5 References.................................................6 Author's Address...........................................6 Expiration and File Name...................................7 D. Eastlake 3rd [Page 2] INTERNET-DRAFT IP over MIME June 2000 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] used, for example, in email, the web, and net news. This document rectifies the omission that IP over MIME has not previously been specified. 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 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 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 1631] technology into these applications may also be helpful. D. Eastlake 3rd [Page 3] INTERNET-DRAFT IP over MIME June 2000 2. MIME Type Specification MIME media type name: APPLICATION MIME subtype name: IP Required parameters: (none) 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 occsionally 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. 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 timeouts there. address=xxx/length Full, if slow, IP connectivity via an application level protocol such as SMTP [RFC 821, 822], in the absence of NAT technology, might require that routing and/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 interface tables at the receiver host or site so as to accomplish this. It requests that return traffic matching the length number of upper bits of address would be routed back to the sender 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 whom they would install routing on behalf of. For example, they could ignore address= parameters unless the APPLICATION/IP object was wrapped in an acceptable D. Eastlake 3rd [Page 4] INTERNET-DRAFT IP over MIME June 2000 MULTIPART/SIGNED [RFC 1847] authentication. Examples: address="10.100.1.10/32" address="1080:0:0:0:8:800:200C:4171/116" Encoding considerations: Becasue 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 [RFC 1847] may be used to further disguise 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. 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 3. Security Considerations See security considerations in Section 2 above. 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. 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 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 June 2000 References RFC 791 - "Internet Protocol.", J. Postel, Sep-01-1981. RFC 821 - "Simple Mail Transfer Protocol", J. Postel, Aug-1982. RFC 822 - "Standard For The Format Of ARPA Internet Text Messages", D. Crocker, Aug-13-1982. 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. RFC 2046 - " Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed, N. Borenstein, November 1996. Author's Address Donald E. Eastlake, 3rd 140 Forest Avenue Hudson, MA 01749 USA Telephone: +1 978-562-2827 (h) +1 508-261-5434 (w) fax: +1 508-261-4447 (w) email: dee3@torque.pothole.com D. Eastlake 3rd [Page 6] INTERNET-DRAFT IP over MIME June 2000 Expiration and File Name This draft expires December 2000. Its file name is draft-eastlake-ip-mime-03.txt. D. Eastlake 3rd [Page 7]