Internet DRAFT - draft-ek-dtn-ethernet
draft-ek-dtn-ethernet
Delay/Disruption Tolerant Networking E. Kline
Internet-Draft Aalyria Technologies, Inc.
Intended status: Experimental 10 July 2023
Expires: 11 January 2024
Support for the Delay- and Disruption-Tolerant Networking (DTN) Bundle
Protocol (BP) Datagrams over Ethernet
draft-ek-dtn-ethernet-00
Abstract
This memo describes a mechanism for the transmission of Bundle
Protocol (BP) Bundles over Ethernet links (BP-over-Ethernet),
describes limitations and operational considerations, and requests
some dedicated Ethernet parameters.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ekline.github.io/draft-dtn-ethernet/draft-ek-dtn-
ethernet.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ek-dtn-ethernet/.
Discussion of this document takes place on the Delay/Disruption
Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/dtn/.
Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.
Source for this draft and an issue tracker can be found at
https://github.com/ekline/draft-dtn-ethernet.
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."
Kline Expires 11 January 2024 [Page 1]
Internet-Draft BP-over-Ethernet July 2023
This Internet-Draft will expire on 11 January 2024.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. General Recommendation . . . . . . . . . . . . . . . . . . . 3
3.1. Bundle Protocol Versions . . . . . . . . . . . . . . . . 3
3.2. Destination MAC Address . . . . . . . . . . . . . . . . . 4
3.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Operational Considerations . . . . . . . . . . . . . . . . . 5
4.1. Fragmentation and Reassembly . . . . . . . . . . . . . . 5
4.2. Congestion Control . . . . . . . . . . . . . . . . . . . 5
4.3. Checksums . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. EtherType . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Multicast MAC Address . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
When two Bundle nodes are connected by an Ethernet link, or by a
logical link that emulates Ethernet, it may be possible for a Bundle
Protocol Agent to transmit Bundles directly in the payload of an
Ethernet frame, without higher layer Convergence Layer (CL) overhead.
Kline Expires 11 January 2024 [Page 2]
Internet-Draft BP-over-Ethernet July 2023
This memo describes a mechanism for the transmission of Bundle
Protocol (BP) Bundles over Ethernet links (BP-over-Ethernet),
describes limitations and operational considerations, and requests
some dedicated Ethernet parameters.
The mechanism described here acts like a datagram CL, specifically
the BP over UDP CL documented in §3.2.2 of [DGRAMCL], ableit suitable
for use only among directly connected nodes (i.e. on-link
communications only).
While hypothetically applicable to a physical Ethernet LAN, it may
find more use within Virtual Private Cloud (VPC) networks, which
allow novel software-define connectivity among a set of cooperating
Bundle processing cloud compute nodes (i.e. VMs).
2. Conventions and Definitions
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. General Recommendation
Paraphrasing [DGRAMCL], in order to transmit Bundles ([BPv6], [BPv7])
across the Internet it is necessary to encapsulate them in a
Convergence Layer that utilizes one of the standard versions of the
Internet Protocols (e.g., [TCPCL]).
When two Bundle nodes are directly connected via an Ethernet link,
however, it is possible for Bundle Protocol Agents to forego Internet
CL encapsulations and instead place Bundles directly in the payload
of an Ethernet frame. Section 6.1 lists the IEEE-assigned EtherType
used to indicate the Ethernet payload is a [BPv6] or [BPv7] Bundle
(or Bundle fragment; section 3.3).
This Ethernet Convergence Layer (ETHCL) avoids incurring the IP and
UDP header overhead (28 to 48 bytes, depending on Internet Protocol
version and assuming no other headers or options). These savings
may, however, be offset by overhead introduced if Bundle
fragmentation is necessary (see sections 3.3 and 4.1).
3.1. Bundle Protocol Versions
A single EtherType suffices for both [BPv6] and [BPv7] payloads.
Current Bundle Protocol versions are readily distinguishable by the
first byte of the payload.
Kline Expires 11 January 2024 [Page 3]
Internet-Draft BP-over-Ethernet July 2023
Encoding of [BPv6] bundles begins with the Version field of the
Primary Bundle Block, which has a fixed value of 0x06 (§4 and §4.5.1
of [BPv6]).
Encoding of [BPv7] bundles "SHALL be a concatenated sequence of at
least two blocks, represented as a CBOR indefinite-length array..."
(§4.1 of [BPv7]). Per [CBOR], an indefinite-length array begins with
the octet value 0x9f.
All other first octet values indicate some other content. Bundle
Protocol over Ethernet receivers MUST NOT attempt to interpret such
payloads as bundles and SHOULD log an error for administrator review.
3.2. Destination MAC Address
When transmitting a Bundle directly in the payload of an Ethernet
frame a suitable destination MAC address must be selected.
Provisioning the sending Bundle node with the correct destination MAC
address of the recipient Bundle node is out of scope for this
document. There is no Bundle Protocol equivalent of [ARP] or
[IPv6ND].
It is possible for a sender to address all BP-over-Ethernet listeners
within the broadcast domain should the destination Bundle Endpoint ID
refer to "all of a group of nodes" (§3.2 and §3.4 of [ARCH]). How a
sending Bundle node determines when this is appropriate is out of
scope of this document.
This document does not prohibit the use of the broadcast MAC address
for this function, but section 6.2 requests the allocation of a
multicast MAC address to represent "all Bundle Protocol over Ethernet
capable stations" within a given Ethernet broadcast domain. This may
help reduce the number of stations awakened by multicast BP-over-
Ethernet frames.
3.3. MTU
In the absence of Ethernet-layer fragmentation, no payload exceeding
the local Ethernet MTU can be transmitted. Consequently, the
contents of the Ethernet payload MUST be a complete Bundle, employing
Bundle fragmention at the sender as necessary ([BPv6] §5.8, [BPv7]
§5.8).
In practice the need for fragmentation may be reduced if the local
Ethernet MTU can be increased beyond the typical 1500 bytes, e.g. by
operator-configured use of "jumbo frames" or cloud management tuning
of a virtual Ethernet network.
Kline Expires 11 January 2024 [Page 4]
Internet-Draft BP-over-Ethernet July 2023
How a sending Bundle node learns the size of the local Ethernet MTU
connected to a given interface is out of scope of this document.
4. Operational Considerations
Conceptually, this Ethernet Convergence Layer (ETHCL) is analogous to
the BP over UDPCL in §3.2.2 of [DGRAMCL], with many of the same
limitations and considerations.
4.1. Fragmentation and Reassembly
Transmission of Bundles exceeding the transmitting interface's
Ethernet MTU MUST be fragmented by the sending node (3.3). If
excessive fragmentation proves problematic, network operators may
need to consider alternate Convergence Layers.
4.2. Congestion Control
Just as with BP over UDPCL, there is no congestion control that can
be relied upon with this Ethernet CL.
Ethernet flow control mechanisms exist but, even if in use, they may
not be sufficient to avoid significant loss of Bundles in all
situations. Additionally, a Bundle Protocol Agent may not be able to
easily determine whether any Ethernet-level flow control mechanism is
available; at best it may only be able to infer excessive Bundle
delivery failures from the absence of requested status report Bundles
and adapt according to local policy.
If congestion control is an operational concern, network operators
should to consider alternate Convergence Layers.
4.3. Checksums
To reiterate the observation in §3.5 of [DGRAMCL], the Bundle
Protocol specifications assume that Bundles "are transmitted over an
erasure channel, i.e., a channel that either delivers packets
correctly or not at all".
Ethernet's Frame Check Sequence (FCS) minimally meets this
requirement to ensure Bundles are not corrupted in transmission.
However, use of stronger integrity checks are RECOMMENDED, especially
the integrity provided by use of Bundle Protocol Security (BPSec)
([BPv6Sec] and [BPv7Sec]).
Kline Expires 11 January 2024 [Page 5]
Internet-Draft BP-over-Ethernet July 2023
Note that for [BPv7] Bundles, inclusion of a CRC covering the Primary
Block is mandatory ([BPv7] §4.3.1) whenever a Bundle Integrity Block
(BIB) ([BPv7Sec] §3.7) covering the Primary Block is not present.
There is no analogous requirement for [BPv6] Bundles.
4.4. Filtering
A common security paradigm is to "defaul deny" all traffic patterns
that, broadly, do not conform to operator expectations. In such
environments it may be that this document's new EtherType needs to be
added to an allowlist or otherwise explicitly permitted to be used on
a given Ethernet segment before Bundles can be successfully
delivered.
5. Security Considerations
This specification describes the transmission of Bundles as payloads
in Ethernet frames. Without the use of Bundle Protocol Security
(BPSec) ([BPv6Sec] and [BPv7Sec]) there are no integrity,
confidentiality, nor authentication guarantees. The CRC field
available in [BPv7] blocks is not sufficient to maintain integrity
when an attacker has the ability to modify frames in transit.
How a sender is configured with the correct destination MAC address
for delivery of any given Bundle is out of scope for this document
(see 3.2). Relatedly, there is also no mechanism to configure
receivers with knowledge of authorized sender source MAC addresses
nor any in-scope mechanism to require restriction of source Bundle
Endpoint IDs (EIDs) to specifc source MAC addresses. These control
and management plane issues are left to implementations, and to
future work.
Any attacker with access to the link, or with sufficient knowledge of
local Bundle fordwarding configuration so as to inject Bundles and
cause them to be sent to an Ethernet peer may overwhelm the receiver
to the point of Denial of Service to any other legitimate onlink
senders.
IEEE standards include several security mechanisms that may be used
in Ethernet networks. Examples of recommended Ethernet-level
security mechanisms include: IEEE 802.1X (TODO: reference), which may
be used restrict access to the link to authorized participants, and
IEEE 802.1AE (TODO: reference), which offers confidentiality of the
entire Ethernet payload (even if BPSec provides integrity and
confidentiality of a Bundle, several header fields are readily
observable).
Kline Expires 11 January 2024 [Page 6]
Internet-Draft BP-over-Ethernet July 2023
6. IANA Considerations
Allocation of the following Ethernet parameters is requested.
6.1. EtherType
IANA is requested to work its IEEE liaison magic to request
allocation of an EtherType for this document's description of Bundle
Protocol over Ethernet (BPoE).
6.2. Multicast MAC Address
In order to identify "all Bundle Protocol over Ethernet capable
stations" within the broadcast domain, IANA is requested to allocate
one 48-bit multicast MAC address, presumably from the 01-00-5E OUI.
The stated Usage is "Bundle Protocol over Ethernet" and the Reference
is this document.
7. References
7.1. Normative References
[ARCH] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/rfc/rfc4838>.
[BPv6] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/rfc/rfc5050>.
[BPv7] 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/rfc/rfc9171>.
[CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[DGRAMCL] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122,
DOI 10.17487/RFC7122, March 2014,
<https://www.rfc-editor.org/rfc/rfc7122>.
Kline Expires 11 January 2024 [Page 7]
Internet-Draft BP-over-Ethernet July 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/rfc/rfc2119>.
[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/rfc/rfc8174>.
7.2. Informative References
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/rfc/rfc826>.
[BPv6Sec] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/rfc/rfc6257>.
[BPv7Sec] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
[IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[TCPCL] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence-Layer Protocol Version
4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/rfc/rfc9174>.
Acknowledgments
Thanks to Wes Eddy for discussions, advice, and early reviews.
Author's Address
Erik Kline
Aalyria Technologies, Inc.
Email: ek@aalyria.com
Kline Expires 11 January 2024 [Page 8]
