Encapsulation of Email over Delay-Tolerant Networks(DTN) using the Bundle Protocol
draft-blanchet-dtn-email-over-bp-00

Internet Engineering Task Force                              M. Blanchet
Internet-Draft                                           17 January 2023
Intended status: Standards Track                                        
Expires: 21 July 2023

   Encapsulation of Email over Delay-Tolerant Networks(DTN) using the
                            Bundle Protocol
                  draft-blanchet-dtn-email-over-bp-00

Abstract

   This document describes the encapsulation of emails using RFC5322
   format in the payload of bundles of the Bundle Protocol for the use
   case of Delay-Tolerant Networks(DTN) such as in space communications.

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 https://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 21 July 2023.

Copyright Notice

   Copyright (c) 2023 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Blanchet                  Expires 21 July 2023                  [Page 1]
Internet-Draft         Email over Bundle Protocol           January 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
     1.2.  Vocabulary  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Description . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Encapsulation . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   An important use case of Delay-Tolerant Networks(DTN) using the
   Bundle Protocol[RFC9171] is in space communications.  Current
   scenarios by space agencies involves the use of an IP network on the
   planetary body and the use of the Bundle Protocol between planetary
   bodies, including Earth.  Therefore, there are IP endpoints at both
   ends, and then bundles could be used as a transport of Internet
   related application payload.  This document describes the
   encapsulation of emails over bundles so that end-users on the remote
   end (aka on a planetary body such as Moon or Mars) or processes can
   use typical Internet Email software and tools to use emails, while
   the emails when transiting in space is encapsulated into bundles of
   the Bundle Protocol.

   It should be noted that in DTNs, delays may be very large compared to
   normal delays on (Earth) Internet.  Therefore, the SMTP [RFC5321]
   "conversation" between the two SMTP peers should be avoided since it
   will take many round-trips over long delays networks to achieve the
   delivery.  Therefore, this document proposes to encapsulate the whole
   Email using the Internet Message Format[RFC5322] as a single file
   into bundles of the Bundle Protocol.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Blanchet                  Expires 21 July 2023                  [Page 2]
Internet-Draft         Email over Bundle Protocol           January 2023

1.2.  Vocabulary

   *  Internet: identifies the global IP network on Earth as we know it

   *  Planetary body: describes Moon, Mars and others.  In this
      document, we only care about ones that would have some IP
      networking installed

2.  Description

   In a typical scenario, the email would be created on (Earth)
   Internet, sent using regular delivery (DNS MX records, SMTP, ...) to
   a destination address that points to a location on a planetary body.
   That email would arrive to an SMTP server which is connected to the
   Bundle agent[RFC9171] capable of routing bundles to the final Bundle
   agent on the other planetary body, who has also a connection to an
   SMTP server.  That SMTP server on the other planetary body is
   responsible for final delivery on that planetary body network.  The
   target bundle protocol service number contained in the bundle is the
   one allocated by IANA per this document.

   TBD: artwork representation

   This document assumes that there is a close interaction between a
   Mail Transfer Agent(MTA) and a Bundle protocol agent, in, for
   example, the form of interprocess communication.  However, the
   specific interaction is outside the scope of this document and is
   left to the implementation.

3.  Encapsulation

   The payload of the bundle [RFC9171] is an Internet Message Format
   [RFC5322].  A bundle can only contain a single email.

   If the email is too large to fit in a single bundle, then the bundle
   agent uses bundle fragmentation as described in section 5.8 of
   RFC9171 to slice the email into multiple bundles.  It is the
   responsability of the receiving bundle agent to properly reassemble
   the multiple bundle payloads into the source email.

   The receiving bundle agent will receive the email-containing
   bundle(s) on this document specifically assigned IANA service number.
   The agent transfers the email in [RFC5322] format to a Mail Transfer
   Agent(MTA) that will deliver to the appropriate location as normal
   practice on Internet.

Blanchet                  Expires 21 July 2023                  [Page 3]
Internet-Draft         Email over Bundle Protocol           January 2023

4.  Considerations

   Configuring and deploying an isolated IP network on a planetary body
   with local mail servers, DNS servers and email client needs careful
   consideration.  For example, emails sent between two end-users on the
   same planetary body should not go through space links down to Earth
   and back to the planetary body.  This operational consideration is
   not described here and is outside the scope of this document.

   By using the encapsulation of emails using the [RFC5322] format,
   there is no negotiation and no declaration of capabilities as it is
   done in normal SMTP[RFC5321].  Therefore, the source endpoint has no
   way by this solution to know the capabilities of the other endpoint.
   Therefore, on the target planetary bodies MTAs should be properly
   configured to receive the appropriate kind of emails sent from
   another planetary body.  As with SMTP, it is very possible that
   either improper configuration or other reasons cause the destination
   MTA to reject the email.  In this case, it should send an error using
   the same technique on the reverse path, if at least the From address
   is parsable.  If the email is not parsable on the destination MTA,
   then normal operational logging shall be used.  Similarly to the
   previous paragraph, this consideration of non-negotiation of
   capabilities is not described here and is outside the scope of this
   document.  It is however expected that this environment will be
   highly configured and managed ans such issues shall not be typical.

5.  IANA Considerations

   This document requests IANA to allocate a new Bundle Protocol service
   number under the current CBHE Service Numbers and assign it to this
   document.  Description should be: "RFC5322 content (aka Email)"

   Note to IANA (to be removed by the RFC editor): prefer 25 to relate
   to the Internet email service, but not a big deal if not.

6.  Security Considerations

   Sending any payload with bad data over a space link is a somewhat DOS
   attack.  It is expected that this environment will be highly managed
   and controlled, therefore, before a bundle is sent, the payload is
   properly verified and access control to the space network will be
   tightly controlled.

7.  References

7.1.  Normative References

Blanchet                  Expires 21 July 2023                  [Page 4]
Internet-Draft         Email over Bundle Protocol           January 2023

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
              Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
              January 2022, <https://www.rfc-editor.org/info/rfc9171>.

7.2.  Informative References

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

Acknowledgements

   TBD

Author's Address

   Marc Blanchet
   Email: marc.blanchet@viagenie.ca

Blanchet                  Expires 21 July 2023                  [Page 5]