DTN Research Group B. Gernert, S. Schildt INTERNET-DRAFT IBR, TU Braunschweig Intended Status: Experimental Expires: September 12, 2013 March 11, 2013 Delay Tolerant Networking Email Convergence Layer Protocol draft-gernert-dtnrg-mailcl-00.txt 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 September 12, 2013. Abstract This document describes the protocol for the Email-based Convergence (MCL) Layer for Delay Tolerant Networking (DTN). Copyright and License Notice Copyright (c) 2013 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 (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. B. Gernert, S. Schildt Expires September 12, 2013 [Page 1] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in this Document . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of the Protocol . . . . . . . . . . . . . . . . . . . 5 3.1 Example Communication . . . . . . . . . . . . . . . . . . . 5 4. Email Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1 MCL mail headers . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Encoding of the Primary Bundle Block . . . . . . . . . . . . 8 4.2 Encoding the Bundle Payload Block . . . . . . . . . . . . . 9 4.2.1 The Payload Block . . . . . . . . . . . . . . . . . . . 9 4.3 Encoding Extension Blocks . . . . . . . . . . . . . . . . . 10 4.4 Encoding a Status Report Block . . . . . . . . . . . . . . . 11 4.5 Encoding a Custody Signal Block . . . . . . . . . . . . . . 12 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 B. Gernert, S. Schildt Expires September 12, 2013 [Page 2] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 1. Introduction This document describes the Mail-based convergence layer protocol for Delay Tolerant Networking (MCL). MCL is based on SMTP and IMAP. Delay Tolerant Networking is an end-to-end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in the Delay-Tolerant Network Architecture RFC [RFC4838]. An important goal of the DTN architecture is to accommodate a wide range of networking technologies and environments. The protocol used for DTN communications is the Bundling Protocol (BP) [RFC5050], an application-layer protocol that is used to construct a store-and- forward overlay network. As described in the bundle protocol specification, it requires the services of a "convergence layer adapter" (CLA) to send and receive bundles using the service of some "native" link, network, or Internet protocol. This document describes one such convergence layer adapter that uses SMTP and IMAP to transmit Bundles between BP nodes. With the MCL a BP node can have a mailbox, allowing for asynchronous DTN communication across the Internet when communication partners are not online at the same time. This allows leveraging legacy Internet services, without the need to deploy a native BP router in the Internet. The locations of the MCL and the BP in the Internet model protocol stack are shown in Figure 1. 1.1. Conventions Used in this Document 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 RFC 2119. [RFC2119] B. Gernert, S. Schildt Expires September 12, 2013 [Page 3] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +-------------------------+ | DTN Application | -\ +-------------------------| | | Bundle Protocol (BP) | | +-------------------------+ |-> Application Layer | Email Conv. Layer (MCL) | | +-------------------------+ | | SMTP / IMAP | -/ +-------------------------+ | TCP | ---> Transport Layer +-------------------------+ | IP | ---> Network Layer +-------------------------+ | Link-Layer Protocol | ---> Link Layer +-------------------------+ | Physical Medium | ---> Physical Layer +-------------------------+ Figure 1: The location of the BP and the MCL in the Internet protocol stack 2. Definitions The following set of definitions are abbreviated versions of those which appear in the Bundle Protocol Specification [RFC5050]. To the extent in which terms appear in both documents, they are intended to have the same meaning. Bundle A bundle is a protocol data unit of the DTN bundle protocol. Bundle payload A bundle payload (or simply "payload") is the application data whose conveyance to the bundle's destination is the purpose for the transmission of a given bundle. Bundle node A bundle node (or simply a "node") is any entity that can send and/or receive bundles. The particular instantiation of this entity is deliberately unconstrained, allowing for implementations in software libraries, long-running processes, or even hardware. One component of the bundle node is the implementation of a convergence layer adapter. Bundle endpoint and EID B. Gernert, S. Schildt Expires September 12, 2013 [Page 4] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 A bundle endpoint (or simply "endpoint") is a set of zero or more bundle nodes that all identify themselves for BP purposes by some single text string, called a "bundle endpoint ID" (EID). The special case of an endpoint that never contains more than one node is termed a "singleton" endpoint; every bundle node must be a member of at least one singleton endpoint. Extension Blocks "Extension blocks" are all blocks other than the primary and payload blocks. 3. Overview of the Protocol This specification provides a means to exchange bundles through an E-mail server. It specifies how to encode Bundles within a mail. To be able to use the MCL a node needs its own email address and access to a mail server. A node will download received bundles from the mail server and use it to send bundles to other nodes supporting the MCL. How to find the correct mail address for a BP EID is out of scope of this specification. The mail address for an EID may be configured statically, retrieved using existing discovery mechanism such as IPND or BT-DHT or for MCL-only nodes a new EID scheme encoding the mail address into the EID can be devised. A bundle that has been successfully transmitted to a mail server will be considered delivered by the sending node. To ensure end-to-end acknowledgement of reception BP Bundle Status Reports can be used as normal. 3.1 Example Communication Figure 2 shows the communication between two nodes using the MCL. Once node A's BP implementation comes into possession of a bundle destined for node B it will search for suitable forwarding opportunities. If node A gets to know B's MCL email address it will encode the bundle into a mail and submit it to its SMTP server. No the standard Internet mail system and protocols take over, finally delivering the bundle to the inbox of node B's MCL email address. Once B's MCL compliant BP implementation notices a new mail in its MCL email address' inbox, it will retrieve the mail and decode the contained bundle and deliver it to an application or forward it further according to the BP [RFC5050]. B. Gernert, S. Schildt Expires September 12, 2013 [Page 5] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 Node A SMTP/IMAP servers Node B ====== ================= ====== +-----------------+ | Receives bundle | | destined for B | +-----------------+ || \/ +-----------------+ | Retrieve email | | address of B | +-----------------+ || \/ +-----------------+ | Encode bundle | | in email | +-----------------+ || \/ +-----------------+ +--------------------+ | Send mail via | -> | Accept email | | SMTP | -> | send to mailserver | +-----------------+ | responsible for B | +--------------------+ || \/ +--------------------+ +-----------------+ | Store email in | <- | Check for new | | INBOX of Node B | -> | mails via IMAP | +--------------------+ +-----------------+ || \/ +--------------------+ +-----------------+ | INBOX of Node B | -> | Receive mails | | | -> | via IMAP | +--------------------+ +-----------------+ || \/ +-----------------+ | Decode Bundle | | from email | +-----------------+ Figure 2: Communication between two nodes using MCL B. Gernert, S. Schildt Expires September 12, 2013 [Page 6] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 4. Email Format This section describes how to encode a bundle into a mail messages compliant with [RFC5322]. A mail consists of two parts: The header and the body. Additional data can be attached to a mail encoded as MIME parts ([RFC2045], [RFC2046], [RFC2047], [RFC2048], [RFC2049]). A BP Bundle consists of the Primary Bundle Block, a Bundle Payload Block and an arbitrary number of Extension Blocks and administrative blocks (Bundle Status Reports, Custody Signals). The MCL encodes fields from the Primary Bundle Block in the mail headers. This allows a MCL implementation to decide whether to accept a bundle by only fetching the headers from the IMAP server without the need to download the whole bundle. The header fields form the Bundle Payload Block will also be written to the [RFC5322] mail header. The mail header also contains references to the payload data as well as to all Extension Blocks and Administrative blocks. These blocks will be attached as MIME Parts. There must be one MIME part of the type application/octet-stream for each block. The mails subjects field and the message body should contain some text explaining that this mail contains a bundle. Information about the bundle may be given in human-readable form. Unless otherwise noted all fields have the same meaning content as described in [RFC5050]. Regardless of type, all fields are encoded as strings in the mail header. For INTs and SDNVs a decimal representation is used. Thus The STRING "somestring" is encoded as "somestring" The SDNV with the bit pattern 10000001 00001111 is encoded as "143" The INT with the bit pattern 10000001 00001111 is encoded as "33039" 4.1 MCL mail headers Table 1 shows the additional MCL headers that are not derived from [RFC5050]. B. Gernert, S. Schildt Expires September 12, 2013 [Page 7] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +--------------------------------------------+--------+----------+ | Header-Field | Type | Optional | +============================================+========+==========+ | Bundle-EMailCL-Version | INT | | +--------------------------------------------+--------+----------+ | Bundle-Additional-Block-Count | INT | x | +--------------------------------------------+--------+----------+ | Bundle-Additional-Block-1 | STRING | x | +--------------------------------------------+--------+----------+ | Bundle-Additional-Block-... | STRING | x | +--------------------------------------------+--------+----------+ | Bundle-Additional-Block-n | STRING | x | +--------------------------------------------+--------+----------+ Table 1: MCL specific header fields Bundle-EMailCL-Version: Version of the MCL specification. A "1" denotes the version of the MCL described in this document. Other values are reserved for further use. Bundle-Additional-Block-Count: If a bundle contains any blocks besides the Primary Bundle Block or the Payload Block, such as extension blocks or administrative blocks, the total number of blocks is given by the Bundle- Additional-Block-Count header. If this header is missing, it implies that the bundle has no additional blocks except the Primary Bundle Block. Bundle-Additional-Block-n: If Bundle-Additional-Block-Count is not zero, the headers Bundle- Additional-Block-1 up to Bundle-Additional-Block-n where n=Bundle- Additional-Block-Count must exist in the header. The value for a Bundle-Additional-Block header is the name of the MIME Part containing the data for that block. 4.1 Encoding of the Primary Bundle Block Table 2 shows the header fields of the Primary Bundle Block that will be put into the mail header. Except the fields marked as optional, all fields are required in a valid MCL mail. B. Gernert, S. Schildt Expires September 12, 2013 [Page 8] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +--------------------------------------------+--------+----------+ | Header-Field | Type | Optional | +============================================+========+==========+ | Bundle-Flags | INT | | +--------------------------------------------+--------+----------+ | Bundle-Destination | EID | | +--------------------------------------------+--------+----------+ | Bundle-Source | EID | | +--------------------------------------------+--------+----------+ | Bundle-Report-To | EID | | +--------------------------------------------+--------+----------+ | Bundle-Custodian | EID | | +--------------------------------------------+--------+----------+ | Bundle-Creation-Time | SDNV | | +--------------------------------------------+--------+----------+ | Bundle-Sequence-Number | SDNV | | +--------------------------------------------+--------+----------+ | Bundle-Lifetime | INT | | +--------------------------------------------+--------+----------+ | Bundle-Fragment-Offset | SDNV | x | +--------------------------------------------+--------+----------+ Table 2: MCL header fields from the Primary Bundle Block Bundle-Flags: Processing flags for the Primary Bundle Block. This is a SDNV in [RFC5050], which is limited to 19 bits. The MCL encodes a INT representation of this value 4.2 Encoding the Bundle Payload Block Encoding the Bundle Payload Block is similar to encoding the Primary Bundle Block. Table 3 list the header fields related to the Bundle Payload Block. The actual payload data will be attached as MIME part. 4.2.1 The Payload Block B. Gernert, S. Schildt Expires September 12, 2013 [Page 9] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +---------------------------------------+--------+----------+ | Header-Fields | Value | Optional | +=======================================+========+==========+ | Bundle-Payload-Flags | INT | | +---------------------------------------+--------+----------+ | Bundle-Payload-Block-Length | SDNV | x | +---------------------------------------+--------+----------+ | Bundle-Payload-Data-Name | STRING | | +---------------------------------------+--------+----------+ Table 3: Header fields from the Payload Block Bundle-Flags: Processing flags for the Payload Block. This is a SDNV in [RFC5050], which is limited to 19 bits in [RFC5050]. The MCL encodes a INT representation of this value. Bundle-Payload-Block-Length: Length of the payload data in bytes. Bundle-Payload-Data-Name: Name of the MIME part which contains the payload data. Similar to Bundle-Additional-Block-n fields. 4.3 Encoding Extension Blocks Other Bundle Blocks (Extension Blocks, Status Reports, Custody Signals) must be attached as MIME parts. The headers for Extension Blocks are listed in table 4. These headers must be encoded in the headers of the MIME part and not in the general mail header. Every extension block MUST be referenced in the mail header using the Bundle-Additional-Block-n and Bundle-Additional-Block-count fields. B. Gernert, S. Schildt Expires September 12, 2013 [Page 10] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +---------------------------------------+---------+----------+ | Header-Fields | Value | Optional | +=======================================+=========+==========+ | Block-Type | STRING | | +---------------------------------------+---------+----------+ | Block-Processing-Flags | INT | | +---------------------------------------+---------+----------+ | Block-EID-Count | INT | x | +---------------------------------------+---------+----------+ | Block-EID-1 | EID | x | +---------------------------------------+---------+----------+ | Block-EID-... | EID | x | +---------------------------------------+---------+----------+ | Block-EID-n | EID | x | +---------------------------------------+---------+----------+ Table 4: MIME-part header fields for Extension Blocks Block-Type: Bundle Block type code as specified in [RFC5050]. Block-Processing-Flags: Processing flags for the Payload Block. This is a SDNV in [RFC5050], which is limited to 19 bits. The MCL encodes a INT representation of this value. Block-EID-Count: The number of Block-EID-n fields. If this header is missing, it implies that there are no Block-EID-n fields. Block-EID-n: If the Block-EID-Count is not zero, the headers Block-EID-1 up to Block-EID-n where n=Block-EID-Count must exist in the header. If the block references EID from the Primary Bundle Block Dictionary, the EIDs will be directly encoded to Block-EID fields. 4.4 Encoding a Status Report Block The encoding of a Status Report Block is similar to the general encoding of Extension Blocks with some additional fields shown in table 5. B. Gernert, S. Schildt Expires September 12, 2013 [Page 11] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +---------------------------------------+---------+----------+ | Header-Fields | Value | Optional | +=======================================+=========+==========+ | Block-Type | STRING | | +---------------------------------------+---------+----------+ | Block-Processing-Flags | INT | | +---------------------------------------+---------+----------+ | Block-EID-Count | INT | x | +---------------------------------------+---------+----------+ | Block-EID-1 | EID | x | +---------------------------------------+---------+----------+ | Block-EID-... | EID | x | +---------------------------------------+---------+----------+ | Block-EID-n | EID | x | +---------------------------------------+---------+----------+ | Status-Flags | INT | | +---------------------------------------+---------+----------+ | Status-Reason-Code | INT | | +---------------------------------------+---------+----------+ | Status-Fragment-Offset | SDNV | x | +---------------------------------------+---------+----------+ | Status-Fragment-Length | SDNV | x | +---------------------------------------+---------+----------+ | Status-Receipt-Time | DTNTIME | x | +---------------------------------------+---------+----------+ | Status-Acceptance-Time | DTNTIME | x | +---------------------------------------+---------+----------+ | Status-Forwarding-Time | DTNTIME | x | +---------------------------------------+---------+----------+ | Status-Delivery-Time | DTNTIME | x | +---------------------------------------+---------+----------+ | Status-Deletion-Time | DTNTIME | x | +---------------------------------------+---------+----------+ | Status-Creation-Time | DTNTIME | x | +---------------------------------------+---------+----------+ | Status-Sequence-Number-Time | DTNTIME | | +---------------------------------------+---------+----------+ | Status-Source-EID | EID | | +---------------------------------------+---------+----------+ Table 5: MIME-part header fields for Status Report Blocks 4.5 Encoding a Custody Signal Block The encoding of a Custody Signal Block is similar to the general encoding of Extension Blocks with some additional fields shown in table 6. B. Gernert, S. Schildt Expires September 12, 2013 [Page 12] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 +---------------------------------------+---------+----------+ | Header-Fields | Value | Optional | +=======================================+=========+==========+ | Block-Type | STRING | | +---------------------------------------+---------+----------+ | Block-Processing-Flags | INT | | +---------------------------------------+---------+----------+ | Block-EID-Count | INT | x | +---------------------------------------+---------+----------+ | Block-EID-1 | EID | x | +---------------------------------------+---------+----------+ | Block-EID-... | EID | x | +---------------------------------------+---------+----------+ | Block-EID-n | EID | x | +---------------------------------------+---------+----------+ | Custody-Reason-Code | SDNV | | +---------------------------------------+---------+----------+ | Custody-Fragment-Offset | SDNV | x | +---------------------------------------+---------+----------+ | Custody-Fragment-Length | SDNV | x | +---------------------------------------+---------+----------+ | Custody-Signal-Time | DTNTIME | | +---------------------------------------+---------+----------+ | Custody-Creation-Time | DTNTIME | | +---------------------------------------+---------+----------+ | Custody-Creation-Sequence-Number | SDNV | | +---------------------------------------+---------+----------+ | Custody-Source-EID | EID | | +---------------------------------------+---------+----------+ Table 6: MIME-part header fields for Custody Signal Blocks 5. Example The following example shows a correctly encoded mail with just a payload block. This bundle comes from "dtn://second/eid" with the mail address "sender@server" and was delivered to "dtn://some/eid" with the mail address "recv@server". The payload can be found in the attachment named "payload.data". B. Gernert, S. Schildt Expires September 12, 2013 [Page 13] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 Return-path: Envelope-to: recv@server Delivery-date: Wed, 23 Jan 2013 19:44:25 +0100 From: sender@server To: recv@server Subject: Bundle for dtn://some/eid Bundle-EMailCL-Version: 1 Bundle-Flags: 144 Bundle-Destination: dtn://some/eid Bundle-Source: dtn://second/eid Bundle-Report-To: dtn:none Bundle-Custodian: dtn:none Bundle-Creation-Time: 412281870 Bundle-Sequence-Number: 1 Bundle-Lifetime: 3600 Bundle-Fragment-Offset: 0 Bundle-Total-Application-Data-Unit-Length: 0 Bundle-Payload-Flags: 8 Bundle-Payload-Block-Length: 35 Bundle-Payload-Data-Name: payload.data Content-Type: multipart/mixed; boundary="=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6" Bundle-Additional-Block-Count: 0 This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6 --=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=payload.data VGVzdA== --=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6-- 7. IANA Considerations This document has no actions for IANA at the moment. 8. Security Considerations To secure the transmission to and from an emailserver you can use SMTP and IMAP over TLS [RFC3207] and [RFC2595]. However it is still possible that an outstanding person sends manipulated mails to an inbox of one node. Therefore additional tasks to secure the inbox of a node may be required. B. Gernert, S. Schildt Expires September 12, 2013 [Page 14] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 9. References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. B. Gernert, S. Schildt Expires September 12, 2013 [Page 15] INTERNET-DRAFT DTN Email Convergence Layer March 11, 2013 Authors' Addresses Bjoern Gernert Technische Uninversitaet Braunschweig Institute of Operating Systems and Computer Networks Muhlenpfordtstr. 23 38106 Braunschweig Germany Email: mail@bjoern-gernert.de Sebastian Schildt Technische Uninversitaet Braunschweig Institute of Operating Systems and Computer Networks Muhlenpfordtstr. 23 38106 Braunschweig Germany Phone +49 531 391 3285 Email: schildt@ibr.cs.tu-bs.de B. Gernert, S. Schildt Expires September 12, 2013 [Page 16]