Internet DRAFT - draft-gernert-dtnrg-mailcl
draft-gernert-dtnrg-mailcl
DTN Research Group B. Gernert, S. Schildt
INTERNET-DRAFT IBR, TU Braunschweig
Intended Status: Experimental
Expires: October 25, 2013 April 23, 2013
Delay Tolerant Networking Email Convergence Layer Protocol
draft-gernert-dtnrg-mailcl-01.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 October 25, 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 October 25, 2013 [Page 1]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 . . . . . . . . . . . . . 10
4.2.1 The Payload Block . . . . . . . . . . . . . . . . . . . 10
4.3 Encoding Extension Blocks . . . . . . . . . . . . . . . . . 11
4.4 Encoding a Status Report/Custody Signal Block . . . . . . . 12
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
B. Gernert, S. Schildt Expires October 25, 2013 [Page 2]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 architecture providing communications
in challenging networking environments, including those with
intermittent connectivity, long and/or variable delays, and high bit
error rates. A more complete characterization of these networks and
their respective challenges can be found in the Delay-Tolerant
Network Architecture [RFC4838].
An important goal of the DTN architecture is to accommodate a wide
range of networking technologies and environments. A protocol used
for DTN communications is the Bundle Protocol (BP) [RFC5050], an
application-layer protocol that is used to construct a store-and-
forward overlay network. The Bundle Protocol requires the services
of a "convergence layer adapter" (CLA) to send and receive bundles
using some underlying network 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 October 25, 2013 [Page 3]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 October 25, 2013 [Page 4]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 2013
A bundle endpoint (or simply "endpoint") is a set of zero or more
bundle nodes that all identify themselves for BP purposes by the
same URI [RFC3986], 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 directly 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 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.
Now 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 October 25, 2013 [Page 5]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 October 25, 2013 [Page 6]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 from 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 October 25, 2013 [Page 7]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 2013
+--------------------------------------------+--------+----------+
| Header-Field | Type | Optional |
+============================================+========+==========+
| Bundle-EMailCL-Version | INT | |
+--------------------------------------------+--------+----------+
| Bundle-Additional-Block | 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:
If a bundle contains any blocks besides the Primary Bundle Block
or the Payload Block, such as extension blocks, for each of these
blocks a separate mail attachment must be created. Each
attachment will have its own unique name. For each of these
attachments one "Bundle-Additional-Block" header field must be
created. Therefore this header field may occur multiple times in
the header.
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 October 25, 2013 [Page 8]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 | SDNV | |
+--------------------------------------------+--------+----------+
| Bundle-Fragment-Offset | SDNV | x |
+--------------------------------------------+--------+----------+
| Bundle-Total-Application-Data-Unit-Length | 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
encoding the different flags as described in [RFC5050], which is
limited to 19 bits. The MCL encodes an INT representation of this
value.
Bundle-Destination:
The destination of the bundle. This is an EID in [RFC5050]. The
MCL encodes the STRING representation of this value
Bundle-Source:
The source of the bundle. This is an EID in [RFC5050]. The MCL
encodes the STRING representation of this value.
Bundle-Report-To:
The node to which status reports pertaining to the forwarding and
delivery of this bundle are to be transmitted. This is an EID in
[RFC5050]. The MCL encodes the STRING representation of this
value.
B. Gernert, S. Schildt Expires October 25, 2013 [Page 9]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 2013
Bundle-Custodian:
The node which is the current custodian of this bundle. This is
an EID in [RFC5050]. The MCL encodes the STRING representation of
this value.
Bundle-Creation-Time:
The creation time of the bundle. This is a SDNV in [RFC5050].
The MCL encodes an INT representation of this value.
Bundle-Sequence-Number:
The sequence number of the bundle. This is a SDNV in [RFC5050].
The MCL encodes an INT representation of this value.
Bundle-Lifetime:
The lifetime of the bundle. This is a SDNV in [RFC5050]. The MCL
encodes an INT representation of this value.
Bundle-Fragment-Offset:
If this bundle is a fragment this header field must be set. This
is a SDNV in [RFC5050], indicating the offset from the start of
the original application data unit. The MCL encodes an INT
representation of this value.
Bundle-Total-Application-Data-Unit-Length:
If this bundle is a fragment this header field must be set. This
is a SDNV in [RFC5050], indicating the total length of the
original application data unit of which this bundle's payload is a
part. The MCL encodes an 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 October 25, 2013 [Page 10]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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. The MCL encodes an INT
representation of this value.
Bundle-Payload-Block-Length:
Length of the payload data in bytes. This field is optional as it
is possible to calculate the size directly from the attachment.
Bundle-Payload-Data-Name:
Name of the MIME part which contains the payload data.
4.3 Encoding Extension Blocks
Other Bundle Blocks (Extension Blocks) 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 field.
B. Gernert, S. Schildt Expires October 25, 2013 [Page 11]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 2013
+---------------------------------------+---------+----------+
| Header-Fields | Value | Optional |
+=======================================+=========+==========+
| Block-Type | STRING | |
+---------------------------------------+---------+----------+
| Block-Processing-Flags | INT | |
+---------------------------------------+---------+----------+
| Block-EID-Reference | 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 encoding
the different flags as described in [RFC5050], which is limited to
19 bits. The MCL encodes an INT representation of this value.
Block-EID-Reference:
Each extension block may include one or more reference EIDs. For
each of these EIDs a header field "Block-EID-Reference" will be
created. The value of this field is the string representation of
the specific EID. As an extension block may contain more than one
EID reference, this header field will occur multiple times.
4.4 Encoding a Status Report/Custody Signal Block
The Status Report/Custody Signal Block are contained within the
payload of the bundle. A specific bundle processing control flag
will be set by the BP implementation to indicate that the payload is
containing such an administrative record. Therefore no additional
measures need to be taken to transmit an administrative record with
MCL.
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
B. Gernert, S. Schildt Expires October 25, 2013 [Page 12]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 2013
attachment named "payload.data".
Return-path: <sender@server>
Envelope-to: recv@server
Delivery-date: Wed, 23 Jan 2013 19:44:25 +0100
From: sender@server
To: recv@server
Subject: Bundle for mail://sender@server
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-Payload-Flags: 8
Bundle-Payload-Block-Length: 35
Bundle-Payload-Data-Name: payload.data
Content-Type: multipart/mixed;
boundary="=_f-20r0xUuORzjAo2CVz1bGFWJK1irHf4t+jNIoYURaTVkAY6"
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 email server you can use
SMTP and IMAP over TLS [RFC3207] and [RFC2595]. However it is still
possible that an attacker sends manipulated mails to an inbox of one
node. As the MCL can encode the full BP feature set, the Bundle
Security protocol extensions [RFC6257] can be used to secure the
system against malicious bundles.
B. Gernert, S. Schildt Expires October 25, 2013 [Page 13]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
B. Gernert, S. Schildt Expires October 25, 2013 [Page 14]
INTERNET-DRAFT DTN Email Convergence Layer April 23, 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 October 25, 2013 [Page 15]
