Internet Engineering Task Force S. Johnson, Ed.
Internet-Draft Spacely Packets, LLC
Intended status: Informational 18 March 2025
Expires: 19 September 2025
A method for delivery of SMTP messages over Bundle Protocol networks.
draft-johnson-dtn-interplanetary-smtp-01
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, via Application Layer
Gateways.
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 19 September 2025.
Copyright Notice
Copyright (c) 2025 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 19 September 2025 [Page 1]
Internet-Draft Interplanetary Email March 2025
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 . . . . . . . . . . 6
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 19 September 2025 [Page 2]
Internet-Draft Interplanetary Email March 2025
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 foo.mars. An MX record for
foo.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 a 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 and optional
acknowldgement bundle. Upon receipt, the Mars BPA/MTA gateway parses
the bundle payload, 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. "Batch model email", or BSMTP
encoding of email messages sent via BP MUST be implemented to ensure
interoperability.
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. Such transmit
side shim applications may employ MTA "pipe" transports/routers or
other means to inject BSMTP formatted messages into the bundle
network. Receive side shims accept data from the BPA and output
BSMTP encoded email to stdout to pipe into the MTA, or by other means
to interface with the MTA. A sample shim implementation flowchart
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 the original data is not
retained intact. 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 the mail-carrying bundle. Upon receipt of such an
inclusion, 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
Johnson Expires 19 September 2025 [Page 3]
Internet-Draft Interplanetary Email March 2025
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.
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
Johnson Expires 19 September 2025 [Page 4]
Internet-Draft Interplanetary Email March 2025
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
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 provide service, 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
Johnson Expires 19 September 2025 [Page 5]
Internet-Draft Interplanetary Email March 2025
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.
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>.
Johnson Expires 19 September 2025 [Page 6]
Internet-Draft Interplanetary Email March 2025
[I-D.johnson-dtn-interplanetary-dns]
Johnson, S. M., "An Interplanetary DNS Model", Work in
Progress, Internet-Draft, draft-johnson-dtn-
interplanetary-dns-03, 2 March 2025,
<https://datatracker.ietf.org/doc/html/draft-johnson-dtn-
interplanetary-dns-03>.
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 19 September 2025 [Page 7]