A method for delivery of SMTP messages over Bundle Protocol networks.
draft-johnson-dtn-interplanetary-smtp-00

Internet Engineering Task Force                          S. Johnson, Ed.
Internet-Draft                                      Spacely Packets, LLC
Intended status: Informational                          8 September 2024
Expires: 12 March 2025

 A method for delivery of SMTP messages over Bundle Protocol networks.
                draft-johnson-dtn-interplanetary-smtp-00

Abstract

   Delay and disruption tolerant networks are a foundational component
   of Interplanetary Internet communications.  This document will treat
   several methods and modes of operation of Mail Transfer Agents in
   concert with Bundle Protocol Agents which allow SMTP interoperability
   between discrete IP networks bridged by DTNs.

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 12 March 2025.

Copyright Notice

   Copyright (c) 2024 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.

Johnson                   Expires 12 March 2025                 [Page 1]
Internet-Draft            Interplanetary Email            September 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Modes of Operation  . . . . . . . . . . . . . . . . . . . . .   2
     3.1.  IP-BP-IP  . . . . . . . . . . . . . . . . . . . . . . . .   2
       3.1.1.  Planet to Planet Use Case . . . . . . . . . . . . . .   3
     3.2.  IP-BP . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  Planet to Free Ranging Spacecraft Use Case  . . . . .   4
     3.3.  BP-BP . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  Spacecraft to Spacecraft Use Case . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This document is predicated upon the concepts of IP networks deployed
   on multiple worlds, DTN networks which relay traffic between worlds,
   and implementation of [I-D.johnson-dtn-interplanetary-dns] to provide
   cohesive multi-world DNS.  Given these prerequisites, it is
   reasonable to conclude that both multi-world interoperability and
   interoperability with free ranging spacecraft are desirable features
   for many popular Internet services.  Herein, we will examine several
   use cases, modes of operation, and the former's methods of
   implementation in order to satisfy the requirements of the use cases
   as respects SMTP.

2.  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.

3.  Modes of Operation

3.1.  IP-BP-IP

Johnson                   Expires 12 March 2025                 [Page 2]
Internet-Draft            Interplanetary Email            September 2024

3.1.1.  Planet to Planet Use Case

   This use case considers an email sent from Earth to Mars, for
   example.  This requires, on Earth, an SMTP transaction between an MTA
   with a "gateway" MTA which interfaces with a BPA.  This initial SMTP
   transaction can be secured by TLS, with authenticity and integrity
   provided by DMARC components SPF and DKIM.  The initial SMTP
   transaction can be considered complete at this time, although it is
   RECOMMENDED that it return an autoreply to the sender indicating the
   potentially delayed final delivery and response.  The gateway MTA
   should be configured to accept mail for *.mars.  An MX record for
   *.mars should exist in the stub zone file for .mars in the Earth DNS.
   The MTA delivers the SMTP message to the BPA, possibly through an
   intermediary shim, for bundling and delivery to the node on the
   remote world responsible for BPA/MTA operations.  The BPA (or shim)
   SHOULD implement Delay Tolerant Payload Conditioning (DTPC) to ensure
   in-order reassembly of fragmented mail application data.  Upon
   receipt, the Mars BPA/MTA gateway parses the bundle payload and any
   associated extension blocks, and creates a new email delivered by
   SMTP to the Mars-local MX for the appropriate .mars domain, having
   found it's IPv6 address in the Mars DNS network.  The new mail's
   transit of the Mars IP network can be secured by TLS.

   The MTA/BPA interface can occur via a variety of methods, including
   the implementation of a "BP Transport" in the MTA to deeply integrate
   with the BPA API directly, or"shim" applications which exist between
   the MTA and the BPA for both sent and received mails, employing MTA
   "pipe" transport and BP enabled MUAs.  An example implementation
   flowchart for a shim method can be found here
   (https://www.spacelypackets.com/smtp.jpg).  No matter the interface
   method for sending, the following SMTP header components, along with
   the body MUST be preserved during any parsing in preparation for
   bundle encoding: From, To, Subject, Content Type, Date and Message
   ID.  This allows the construction of a new email once the bundle
   exits the BP network.  If end-to-end integrity is required, the DMARC
   components, specifically the DNS DKIM TXT record lookup result for
   the sending domain (containing the public key for the DKIM signer)
   MAY be included in an extension block of the mail-carrying bundle.
   Upon receipt of such an extension block, the BPA interfacing
   application MUST publish a record in the local stub for the sending
   domain before the mail is sent to it's ultimate destination, such
   that the local recipient MTA can query the key as normal from local
   DNS resources.  Such end to end integrity requires that the entire
   mail header and body MUST be retained intact to pass the remote
   integrity test, which significantly increases the network capacity
   used.

Johnson                   Expires 12 March 2025                 [Page 3]
Internet-Draft            Interplanetary Email            September 2024

   Alternatively, a segmented integrity approach requires much less
   network overhead, at the expense of trusting the MTA/BPA stack on the
   interplanetary email gateway.  Practically, integrity is supplied by
   native protocols in each network segment with this approach; DKIM
   protects the originating and final remote delivery SMTP over IP
   transactions, while BPSEC BIB protects the mail data while in transit
   of the BP network.  As regards the final delivery SMTP transaction
   using this segmented integrity technique, the DKIM signature and
   hence integrity originates at the gateway BPA/MTA.  As a result, only
   those SMTP header and body components listed above need be included
   in the bundle.

3.2.  IP-BP

3.2.1.  Planet to Free Ranging Spacecraft Use Case

   This use case considers an email sent from Earth to a mining craft in
   transit between the Moon and an asteroid to be mined, as an example.
   In this case, there is no reliable, accurate DNS service which the
   spacecraft can viably access, nor does it's have a top level domain
   designated for it's sole use.  A TLD dedicated to general use for
   free ranging spacecraft is RECOMMENDED, to enable simpler routing of
   mail by disambiguated destination TLD; i.e. there is no doubt that a
   mail addressed to user@foo.spacecraft is intended to be delivered to
   a free ranging spacecraft whose method of connectivity is via BP
   transit.  Notwithstanding the previous sentence, this writing
   provides a solution in which the existence of such a TLD does not
   exist.  The concepts presented remain the same in either case.  The
   craft's MTA can be represented, however, in any world's DNS using the
   IPN RRTYPE to associate a Node Number with a domain.  As the craft
   has no IP connectivity, A BPA/MTA is required on Earth to send/
   receive mail to/from the craft.  This IP connected BPA/MTA can be
   accessed by IP based MUAs using a variety of existing methods.  The
   BPA/MTA can also be configured by existing means to relay mail for
   specified domains, allowing wider reach of the ability to contact the
   craft, if desired.  If a domain published in the Earth DNS has no A
   or AAAA and does have an IPN record, the sending BPA/MTA SHOULD
   process the Node Number in the IPN record for the domain as the
   destination of the email, and reflect it in the appropriate headers.
   The IP address of a suitable BPA/MTA SHOULD be published in an MX
   record for the (sub)domain representing the spacecraft.  This allows
   correct interoperability with non-BP enabled terrestrial MTAs.  Such
   free ranging craft SHOULD deploy a DNS root server with stub entries
   for all valid top level domains.  Such stub zones in the craft's
   nameserver(s) SHOULD include wildcard entries in each tld's zone
   listing the node number of a BPA/MTA on the world on which they are
   deployed in an IPN record.  Alternatively, a craft MAY employ a
   similar mechanism to that of /etc/hosts to record hostname to Node

Johnson                   Expires 12 March 2025                 [Page 4]
Internet-Draft            Interplanetary Email            September 2024

   Number naming and provide local resolution source.  The RECOMMENDED
   location for this local file is /etc/nodes, which BP enabled
   applications MAY query for node number to hostname indentification
   information.

   In this fashion, a mail destined for spacecraft.foo.org (or
   foo.spacecraft) can be processed as follows: An MUA, or MTA from a
   domain for which the BPA/MTA will relay, makes an initial SMTP
   transaction with the BPA/MTA, which accepts the mail and queries the
   local DNS for an IPN entry for the destination hostname.  A custom
   transport and router in the MTA can accomplish this function without
   modification to the MTA codebase by employing the pipe transport
   infrastructure to pass the mail to an external application for
   parsing and bundling, or these functions can be integrated into the
   MTA along with a deep integration with the BPA via it's API.  The
   bundles produced can be properly directed to the correct EID for the
   spacecraft, using the queried Node Number component in this fashion.
   The former is predicated upon a well known Service Number component
   to the EID allocated for SMTP transit of BP networks.  These bundles,
   upon receipt on the spacecraft, are parsed into emails, which are
   delivered locally on the spacecraft BPA/MTA host, to be accessed by
   the users by standard MUAs using existing means.

   A mail originating from spacecraft.foo.org (or foo.spacecraft)
   destined for a user of bar.org, a terrestrial organization, can be
   processed in the following way: An MUA on the spacecraft makes an
   initial SMTP transaction with the BPA/MTA, which accepts the mail and
   queries the local DNS (or /etc/nodes) for an IPN entry for the
   destination hostname.  The wildcard record in the local DNS stub for
   the destination hostname's TLD returns the Node Number of a BPA/MTA
   gateway on the world to which that TLD is native.  The mail is parsed
   as in the IP-BP-IP use case, and bundled for delivery via the BP
   network to the terrestrial BPA/MTA gateway.  Upon receipt, the
   terrestrial BPA/MTA parses the bundle, and delivers to the addresses
   domain, performing a normal lookup of it's IP address, and initiating
   a normal terrestrial SMTP transaction with the MTA of the addressed
   recipient.

3.3.  BP-BP

3.3.1.  Spacecraft to Spacecraft Use Case

   This use case considers email communication between two free ranging
   spacecraft with no access to a DNS network communicating through
   fixed relays.  In this case the spacecraft MUST have pre-knowledge of
   one another in the form of an /etc/nodes entry or an entry in the
   local nameserver's stub for the domain in question, and have
   occasional contact with other relay nodes to forward its bundles.

Johnson                   Expires 12 March 2025                 [Page 5]
Internet-Draft            Interplanetary Email            September 2024

   Direct craft to craft communication via means of a neighbor discovery
   mechanism is beyond the scope of this writing.  We presume the
   existance of an unroutable IP network deployed on the spacecraft, as
   in the previous use case.  With the exception of node number
   discovery mechanism, this process is identical to the previous use
   case, in that the sending BPA/MTA performs a local query, and finding
   an IPN number associated with the destination hostname, addresses the
   bundles appropriately for delivery.  The recieving BPA/MTA accepts
   these bundles, and delivers them to the local mail spool for the
   addressed user.

4.  IANA Considerations

   This memo includes no request to IANA.

5.  Security Considerations

   Significant security considerations must always be made when making
   network connections to assets in space or on other worlds.  Email
   abuse in the form of spam traffic presents potential denial of
   service effects upon store and forward DTN networks unless particular
   attention is paid to originating network integrity and authenticity,
   such as provided by DMARC.  Whitelisting of networks for which the
   BPA/MTA will process and forward mail could be employed to further
   guarantee legitimate traffic sources for mails entering the
   interplanetary network.

6.  References

6.1.  Normative References

   [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>.

   [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>.

   [I-D.johnson-dtn-interplanetary-dns]
              Johnson, S. M., "An Interplanetary DNS Model", Work in
              Progress, Internet-Draft, draft-johnson-dtn-
              interplanetary-dns-02, 6 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-johnson-dtn-
              interplanetary-dns-02>.

Johnson                   Expires 12 March 2025                 [Page 6]
Internet-Draft            Interplanetary Email            September 2024

Author's Address

   Scott M. Johnson (editor)
   Spacely Packets, LLC
   46 High Ridge Road
   Daytona Beach, FL 32117
   United States of America
   Phone: 386-888-7311
   Email: scott@spacelypackets.com

Johnson                   Expires 12 March 2025                 [Page 7]